The masquerade supertest frequently fails because either the local channel
chain doesn't completely optimize out or the DTMF handshake doesn't
completely get accross. Local channel optimization requires frames
flowing to trigger when optimization can happen. When optimization
happens the media frame that triggered the optimization is dropped.
Sending DTMF requires frames to flow in the other direction for timing
purposes while sending nothing. If internal timing is not enabled when
MOH is playing, Asterisk switches to received timing when an audio frame
is received. With optimization dropping media frames and MOH not sending
frames unless it receives frames, occasionaly there are no more frames
being passed and the test fails.
* The asterisk command line -I option and the asterisk.conf
internal_timing option are removed. Asterisk now always uses internal
timing when needed if any timing module is loaded. The issue
ASTERISK-14861 did this quite awhile ago in v1.4 but effectively is broken
if other internal timing modules besides DAHDI are used. The
ast_read_generator_actions() now only does received timing if it has no
choice for frame generators like MOH, silence, and playback streaming.
* Cleaned up some code dealing with frame generators in
ast_deactivate_generator(), generator_write_format_change(),
ast_activate_generator(), and ast_channel_stop_silence_generator().
* Removed ast_internal_timing_enabled(), AST_OPT_FLAG_INTERNAL_TIMING, and
ast_opt_internal_timing.
ASTERISK-22846 #close
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3414/
........
Merged revisions 411715 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 411716 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 411717 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@411724 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If update_provisional_keepalive() is called while
send_provisional_keepalive_full() is waiting on the PVT lock, then
pvt->provisional_keepalive_sched_id will be changed to a new sched_id
value by update_provisional_keepalive(), but that new sched_id then may
be overwritten with -1 by send_provisional_keepalive_full(), killing
the pvt's reference to a schedule and "leaking" the reference.
(closes issue ASTERISK-22079)
Review: https://reviewboard.asterisk.org/r/3368/
Reported by: Jamuel Starkey, Matteo, Leif Madsen, Steve Davies
Patches:
provisional_keepalive_fix.diff uploaded by Steve Davies (license 5012)
........
Merged revisions 411088 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 411089 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 411091 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@411092 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When accidentally compiling against a wrong version of
pjsip headers with a different pjsip_inv_session size,
the invite_tsx structure could be null in the answer()
function. This led to a crash because it attempted to
send the session response with an uninitialized packet
pointer. This patch presets packet to null and adds a
diagnostic log message to explain why the call fails.
Review: https://reviewboard.asterisk.org/r/3267/
........
Merged revisions 408970 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@408971 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch moves setting SIP_DEFER_BY_ON_TRANSFER prior to calling
ast_bridge_transfer_blind. This prevents a BYE from being sent prior to the
NOTIFY request that informs the transferor if the transfer succeeded or failed.
This patch also clears said flag from the off nominal NOTIFY paths in the
local_attended_transfer code, as once we've sent the NOTIFY request it is safe
to send by the BYE request.
This was caught by the blind-transfer-accountcode test in the Asterisk Test
Suite.
(closes issue ASTERISK-23290)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3214/
........
Merged revisions 408069 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@408070 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Move route code to sip/route.c + sip/include/route.h
* Rename functions to sip_route_*
* Replace ad-hoc list code with macro's from linkedlists.h
* Create sip_route_process_header() to processes Path and Record-Route headers
(previously done with different code in build_route and build_path)
* Add use of const where possible
* Move struct uriparams, struct contact and contactliststruct from sip.h to
reqresp_parser.h. sip/route.c uses reqresp_parser.h but not sip.h, this was
a problem. These moved declares are not used outside of reqresp_parser.
* While modifying reqprep() the lack of {} caused me trouble. I added them.
* Code outside route.c treats sip_route as an opaque structure, using macro's
or procedures for all access.
(closes issue ASTERISK-22582)
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/3173/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407926 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Establishing an IAX2 call between Asterisk v1.4 and v1.8 (or later)
results in an unexpected call disconnect. The problem happens because
newer values in the enum ast_control_frame_type are not consistent between
the branch versions of Asterisk.
For example:
1) v1.4 calls v1.8 (or later) using IAX2
2) v1.8 answers and sends a connected line update control frame. (on v1.8
AST_CONTROL_CONNECTED_LINE = 22)
3) v1.4 receives the control frame as an end-of-q (on v1.4
AST_CONTROL_END_OF_Q = 22)
4) v1.4 disconnects the call once the receive queue becomes empty.
Several things are done by this patch to fix the problem and attempt to
prevent it from happening again in the future:
* Added a warning at the definition of enum ast_control_frame_type about
how to add new control frame values.
* Made block sending and receiving control frames that have no reason to
go over the wire.
* Extended the connectedline iax.conf parameter to also include the
redirecting information updates.
* Updated the connectedline iax.conf parameter documentation to include a
notice that the parameter must be "no" when the peer is an Asterisk v1.4
instance.
(closes issue AST-1302)
Review: https://reviewboard.asterisk.org/r/3174/
........
Merged revisions 407678 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 407727 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 407729 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407731 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Locking issues in skinny when picking up a call that doesn't exist. Cleaned
up sub locking by fully removing and using the chan lock instead. Also
changed ast_call_pickup to check whether chan was masq'd.
(closes issue ASTERISK-23249)
Reported by: wedhorn
Tested by: snuffy, myself
Patches:
skinny-locking01.diff uploaded by wedhorn (license 5019)
........
Merged revisions 407197 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407198 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Fixes typos of "transfered" instead of "transferred" in various code. Fixes incorrect gosub param help text for app_queue.
Fixes Asterisk man pages containing unquoted minus signs. Adds note about the "textsupport" option in sip.conf.sample.
(issue ASTERISK-23061)
(issue ASTERISK-23028)
(issue ASTERISK-23046)
(issue ASTERISK-23027)
(closes issue ASTERISK-23061)
(closes issue ASTERISK-23028)
(closes issue ASTERISK-23046)
(closes issue ASTERISK-23027)
Reported by: Eugene, Jeremy Laine, Denis Pantsyrev
Patches:
transferred.patch uploaded by Jeremy Laine (license 6561)
hyphen.patch uploaded by Jeremy Laine (license 6561)
sip.conf.sample.patch uploaded by Eugene (license 6360)
........
Merged revisions 405791 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 405792 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 405829 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@405830 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds Path support to chan_pjsip in res_pjsip_path.c with minimal
additions in res_pjsip_registrar.c to store the path and additions in
res_pjsip_outbound_registration.c to enable advertisement of path
support to registrars and intervening proxies.
Path information is stored on contacts and is enabled via Address of
Record (AoRs) and Registration configuration sections.
While adding path support, it became necessary to be able to add SIP
supplements that handled messages outside of sessions, so a framework
for handling these types of hooks was added in parallel to the
already-existing session supplements and several senders of
out-of-dialog requests were refactored as a result.
(closes issue ASTERISK-21084)
Review: https://reviewboard.asterisk.org/r/3050/
........
Merged revisions 405565 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@405566 65c4cc65-6c06-0410-ace0-fbb531ad65f3
dahdi show channels output slices the callerid (which is dnid copied over on
PRI channels). If the channel naming structures look like:
'DAHDI/i1/1408409XXXX-6'
then the output slices 1408409XXXX down to 1408409XXX. This patch just opens
it up to 15 chars so you can see the whole thing.
(closes issue ASTERISK-22918)
Reported by: outtolunc
Patches:
svn_chan_dahdi.c.format12_15.diff.txt uploaded by outtolunc (license 5198)
........
Merged revisions 404784 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 404785 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 404786 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404787 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Channel creation in Asterisk is broken up into two steps: requesting and calling.
In some cases a channel may be requested but never called. This happens in the
ChanIsAvail dialplan application for determining if something is reachable or
not. The PJSIP channel driver did not take this situation into account and
attempted to end a session that was never called out on.
The code now checks the session state to determine if the session has been
called out on and if not terminates it instead of ending it.
(closes issue ASTERISK-23074)
Reported by: Kilburn
........
Merged revisions 404652 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404653 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If ignore_failed_channels is set to "true" for a channel, the channel
will continue to be configured even if configuring it has failed.
This allows Asterisk to start before all the DAHDI initialization is
done and thus not force the starting order dahdi -> asterisk.
Review: https://reviewboard.asterisk.org/r/3063/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404542 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change is in preparation for external MWI support.
Removed code from the system for normal mailbox handling that appends
@default to the mailbox identifier if it does not have a context. The
only exception is the legacy hasvoicemail users.conf option. The legacy
option will only work for app_voicemail mailboxes. The system cannot make
any assumptions about the format of the mailbox identifer used by
app_voicemail.
chan_sip and chan_dahdi/sig_pri had the most changes because they both
tried to interpret the mailbox identifier. chan_sip just stored and
compared the two components. chan_dahdi actually used the box
information.
The ISDN MWI support configuration options had to be reworked because
chan_dahdi was parsing the box@context format to get the box number. As a
result the mwi_vm_boxes chan_dahdi.conf option was added and is documented
in the chan_dahdi.conf.sample file.
Review: https://reviewboard.asterisk.org/r/3072/
........
Merged revisions 404348 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404350 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Moved channel locking into setsubstate so that a process can complete
working on a sub before another starts changing it. The existing code
was causing some Fracks with schedule deletion.
Removed multiple rtp cleanup. Now only cleansup up once, fixing ao2
object cleanup issues.
........
Merged revisions 404306 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404307 65c4cc65-6c06-0410-ace0-fbb531ad65f3
On session registration, if device is already reporting that it is
connected to a device, an innocuous packet (update time) is sent to
the already connected device. If the tcp connection is down, the
device will be unregistered and the new connection allowed.
Without this patch, network issues can see a situation where a device
can not reregister until after 3*timeout.
........
Merged revisions 404292 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404293 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Original commit message by mmichelson (asterisk 12 r403311):
"This adds channel locks around calls to create channel snapshots as well
as other functions which operate on a channel and then end up
creating a channel snapshot. Functions that expect the channel to be
locked prior to being called have had their documentation updated to
indicate such."
The above was initially committed and then reverted at r403398. The problem
was found to be in core_local.c in the publish_local_bridge_message function.
The ast_unreal_lock_all function locks and adds a reference to the returned
channels and while they were being unlocked they were not being unreffed when
no longer needed. Fixed by unreffing the channels.
Also in bridge.c a lock was obtained on "other->chan", but then an attempt was
made to unlock "other" and not the previously locked channel. Fixed by
unlocking "other->chan"
(closes issue ASTERISK-22709)
Reported by: John Bigelow
........
Merged revisions 404237 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404260 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The change contains a slightly adjusted patch that was on the issue
(submitted by kmoore). A fix was made by adding in a bridge lock
while calling bridge_start/stop from the framehook callback. Since
the framehook callback is not called from the bridging core the bridge
is not locked, but needs to be before calling bridge_start.
(closes issue ASTERISK-22749)
Reported by: Kinsey Moore
Review: https://reviewboard.asterisk.org/r/3066/
Patches:
lock_inversion.diff uploaded by kmoore (license 6273)
........
Merged revisions 403767 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403768 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch was intended to eliminate a deadlock that occurs when
masquerades occur in pjsip channels, but has some potential side
effects. Mark Michelson is currently working on addressing this
problem from another angle.
(issue ASTERISK-22936)
Reported by: Jonathan Rose
........
Merged revisions 403705 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403707 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds CHANNEL read support for chan_pjsip. This allows the dialplan
to use the CHANNEL function on a chan_pjsip channel to obtain run-time
information about the channel from the PJSIP channel driver and the PJSIP
stack. This includes:
* RTP information, including source/destination media addresses, whether or
not the media is secure, held, and other properties.
* RTCP information. This includes sets of parseable information, as well as
individual statistic attriutes.
* PJSIP information. This includes URIs, local/remote signalling addresses,
whether or not the signalling is secure, and other properties.
* The endpoint name. This can be used in conjunction with the PJSIP_ENDPOINT
function to obtain more detailed endpoint information.
Review: https://reviewboard.asterisk.org/r/3038/
........
Merged revisions 403618 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403619 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds channel locks around calls to create channel snapshots as well
as other functions which operate on a channel and then end up
creating a channel snapshot. Functions that expect the channel to be
locked prior to being called have had their documentation updated to
indicate such.
........
Merged revisions 403311 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403314 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk will sometimes core dump during caller id read on analog
channels due to a negative return value from the read() in
my_get_callerid that slips through as a negative length argument to
callerid_feed() if the errno returned by DAHDI is ELAST. This change
ensures that the negative return is treated properly even when it is
ELAST.
(closes issue ASTERISK-22746)
Reported by: Michael Walton
Patches:
chan_dahdi_cid_crash_fix.r401410.patch uploaded by Michael Walton (License 6502)
........
Merged revisions 402708 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 402709 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 402710 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402711 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For outbound register requests the tag on the From line was
updated every 20 seconds prior to a successful registration
and also once for each registration renewal. That behavior
can possibly cause the registration to be denied because of
the different tag, and is not aligned with the intention of
RFC 3261 8.1.3.5 "... request constitutes a new transaction
and SHOULD have the same value of the Call-ID, To, and From
of the previous request...". This updates chan_sip to have
a field to keep the local tag in the registration structure
and use that tag for registration requests where the callid
is also unchanged.
(closes issue ASTERISK-12117)
Reported by: Pawel Pierscionek
Review: https://reviewboard.asterisk.org/r/2988/
........
Merged revisions 402604 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 402605 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 402606 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402607 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This started off as a fix for the failing IAX2 acl_call test in the Asterisk
Test Suite. When inspecting why that test was failing, it became clear that all
attempts to bind to any local loopback address was failing:
[Nov 2 15:56:28] VERBOSE[15787] chan_iax2.c: == Binding IAX2 to address
127.0.0.1:4569
[Nov 2 15:56:28] DEBUG[15787] netsock2.c: Splitting '127.0.0.1' into...
[Nov 2 15:56:28] DEBUG[15787] netsock2.c: ...host '127.0.0.1' and port ''.
[Nov 2 15:56:28] ERROR[15787] netsock2.c: getaddrinfo("127.0.0.1", "(null)",
...): ai_family not supported
[Nov 2 15:56:28] WARNING[15787] acl.c: Unable to lookup '127.0.0.1'
While there's conceivably other ways for getaddrino to return EAI_FAMILY, the
most common way is if AF_INET, AF_INET6, or AF_UNSPEC is not provided as the
desired family. The culprit was the call to ast_get_ip, defined in acl.h. This
function uses the family from the passed in addr object (which it will also
populate when it returns!) when it eventually calls getaddrinfo.
This patch fixes the use of ast_get_ip that were not specifying the family in
chan_iax2. This prevents uninitialized use of the structure, so that the
addresses resolve correctly.
Review: https://reviewboard.asterisk.org/r/2991
........
Merged revisions 402505 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402506 65c4cc65-6c06-0410-ace0-fbb531ad65f3
While looking at ASTERISK-22236, Walter Doekes pointed out that when running
"sip show peers", the setting being displayed can be confusing. The display of
"N" used to mean NAT (i.e. yes). The NAT setting has gone through many
different changes resulting in the display of different characters to try and
convey what the current setting is for 'Forcerport' (A for Auto and Forcerport
is currently on, a for Auto but Forcerport is off, Y for yes, and N for no).
During the initial code review to try and clarify these settings (especially
since "N" no longer meant what it used to mean in prior versions of Asterisk),
Mark Michelson suggested using the full space available to display the settings
which helped to make the settings very clear. That was a great suggestion.
Therefore, this patch does the following:
* The column for 'Forcerport' now will show: Auto (Yes), Auto (No), Yes, or No.
* A column for the 'Comedia' setting has been added. It too will display the
setting in a non-cryptic way: Auto (Yes), Auto (No), Yes, or No.
* UPGRADE.txt has been updated to document this change.
(closes issue ASTERISK-22728)
Reported by: Walter Doekes
Tested by: Michael L. Young
Patches:
asterisk-forcerport-display-clarification_v3.diff
uploaded by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2941
........
Merged revisions 402111 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 402112 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402113 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Also covers ast_app_parse_timelen-fail-zero-length.patch, but the patch was
replaced with one of my own.
(issue ASTERISK-22467)
Reported by: Corey Farrell
Patches:
chan_dahdi-cleanup_push.patch uploaded by coreyfarrell (license 5909)
clicompat-r2.patch uploaded by coreyfarrell (license 5909)
codecs-ilbc-doCPLC.patch uploaded by coreyfarrell (license 5909)
data-cleanup-test-registration.patch uploaded by coreyfarrell (license 5909)
main-asterisk-kill-listener.patch uploaded by coreyfarrell (license 5909)
........
Merged revisions 401704 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 401705 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 401706 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@401707 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When reworking chan_iax2 for IPv6, the ability to bind to multiple addresses
was removed by mistake. This patch restores this functionality and adds notes
about IPv6 addresses in the sample config.
(closes issue ASTERISK-22741)
Reported by: Joshua Colp
Tested by: Michael L. Young
Patches:
asterisk-22741-fix-binding-multiple-addr.diff
uploaded by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2945/
........
Merged revisions 401488 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@401489 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A condition was added in a commit to fix ASTERISK-21374, that, if the
SIP_PAGE3_NAT_AUTO_RPORT flag was set, to then copy a peer's SIP_NAT_FORCE_RPORT
flag to the dialog. This condition should not have been there since it assumed
that if Asterisk is in an environment where NAT is involved, that the auto_* nat
settings or force_rport setting would be on in the global settings. If the nat
setting in the global setting is set to 'nat=no' and then turned on for peers
(which is not quite the recommended way, although it is allowed) this flag is
never copied to the dialog resulting in problems like, REGISTER replies going
to the wrong port.
This patch removes this conditional check and will now always use the peer's
flag which by this point in the code the checks on whether the peer is behind
NAT or not (if using auto_force_rport) have already been run.
(closes issue ASTERISK-22236)
Reported by: Filip Frank
Tested by: Michael L. Young
Patches:
asterisk-2236-always-set-rport.diff uploaded
by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2919/
........
Merged revisions 401167 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 401168 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@401169 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a 200 OK for an initial INVITE is received, we were doing
the right thing by ACKing and sending an immediate BYE. However,
we also were doing the wrong thing and queuing an answer frame,
thus causing the call to be answered. This would cause the call
to be hung up by the channel thread, thus resulting in a second
BYE being sent out.
In this fix, I also have set the hangupcause to be correct since
the initial BYE being sent by Asterisk had an unknown hangup
cause. I have changed to using "Bearer capabilty not available"
since the call was hung up due to an SDP offer/answer error.
(closes issue ASTERISK-22621)
reported by Kinsey Moore
........
Merged revisions 400970 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 400971 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 400984 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400998 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Channel snapshots have string representations of the channel's native formats.
Prior to this change, the format strings were re-created on ever channel snapshot
creation. Since channel native formats rarely change, this was very wasteful.
Now, string representations of formats may optionally be stored on the ast_format_cap
for cases where string representations may be requested frequently. When formats
are altered, the string cache is marked as invalid. When strings are requested, the
cache validity is checked. If the cache is valid, then the cached strings are copied.
If the cache is invalid, then the string cache is rebuilt and copied, and the cache
is marked as being valid again.
Review: https://reviewboard.asterisk.org/r/2879
........
Merged revisions 400356 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400363 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r400318 | mmichelson | 2013-10-02 17:08:49 -0500 (Wed, 02 Oct 2013) | 12 lines
Remove unnecessary waits from stasis.
Since caches are updated on publisher threads, there is no need
to wait for the cache updates to occur after a stasis message
is published.
In the case of chan_pjsip device state changes, this set of
changes caused an improvement to performance.
Review: https://reviewboard.asterisk.org/r/2890
........
r400319 | mmichelson | 2013-10-02 17:10:54 -0500 (Wed, 02 Oct 2013) | 3 lines
Remove svn:mergeinfo property.
........
Merged revisions 400318-400319 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400335 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r399887 | dlee | 2013-09-26 10:41:47 -0500 (Thu, 26 Sep 2013) | 1 line
Minor performance bump by not allocate manager variable struct if we don't need it
........
r400138 | dlee | 2013-09-30 10:24:00 -0500 (Mon, 30 Sep 2013) | 23 lines
Stasis performance improvements
This patch addresses several performance problems that were found in
the initial performance testing of Asterisk 12.
The Stasis dispatch object was allocated as an AO2 object, even though
it has a very confined lifecycle. This was replaced with a straight
ast_malloc().
The Stasis message router was spending an inordinate amount of time
searching hash tables. In this case, most of our routers had 6 or
fewer routes in them to begin with. This was replaced with an array
that's searched linearly for the route.
We more heavily rely on AO2 objects in Asterisk 12, and the memset()
in ao2_ref() actually became noticeable on the profile. This was
#ifdef'ed to only run when AO2_DEBUG was enabled.
After being misled by an erroneous comment in taskprocessor.c during
profiling, the wrong comment was removed.
Review: https://reviewboard.asterisk.org/r/2873/
........
r400178 | dlee | 2013-09-30 13:26:27 -0500 (Mon, 30 Sep 2013) | 24 lines
Taskprocessor optimization; switch Stasis to use taskprocessors
This patch optimizes taskprocessor to use a semaphore for signaling,
which the OS can do a better job at managing contention and waiting
that we can with a mutex and condition.
The taskprocessor execution was also slightly optimized to reduce the
number of locks taken.
The only observable difference in the taskprocessor implementation is
that when the final reference to the taskprocessor goes away, it will
execute all tasks to completion instead of discarding the unexecuted
tasks.
For systems where unnamed semaphores are not supported, a really
simple semaphore implementation is provided. (Which gives identical
performance as the original taskprocessor implementation).
The way we ended up implementing Stasis caused the threadpool to be a
burden instead of a boost to performance. This was switched to just
use taskprocessors directly for subscriptions.
Review: https://reviewboard.asterisk.org/r/2881/
........
r400180 | dlee | 2013-09-30 13:39:34 -0500 (Mon, 30 Sep 2013) | 28 lines
Optimize how Stasis forwards are dispatched
This patch optimizes how forwards are dispatched in Stasis.
Originally, forwards were dispatched as subscriptions that are invoked
on the publishing thread. This did not account for the vast number of
forwards we would end up having in the system, and the amount of work it
would take to walk though the forward subscriptions.
This patch modifies Stasis so that rather than walking the tree of
forwards on every dispatch, when forwards and subscriptions are changed,
the subscriber list for every topic in the tree is changed.
This has a couple of benefits. First, this reduces the workload of
dispatching messages. It also reduces contention when dispatching to
different topics that happen to forward to the same aggregation topic
(as happens with all of the channel, bridge and endpoint topics).
Since forwards are no longer subscriptions, the bulk of this patch is
simply changing stasis_subscription objects to stasis_forward objects
(which, admittedly, I should have done in the first place.)
Since this required me to yet again put in a growing array, I finally
abstracted that out into a set of ast_vector macros in
asterisk/vector.h.
Review: https://reviewboard.asterisk.org/r/2883/
........
r400181 | dlee | 2013-09-30 13:48:57 -0500 (Mon, 30 Sep 2013) | 28 lines
Remove dispatch object allocation from Stasis publishing
While looking for areas for performance improvement, I realized that an
unused feature in Stasis was negatively impacting performance.
When a message is sent to a subscriber, a dispatch object is allocated
for the dispatch, containing the topic the message was published to, the
subscriber the message is being sent to, and the message itself.
The topic is actually unused by any subscriber in Asterisk today. And
the subscriber is associated with the taskprocessor the message is being
dispatched to.
First, this patch removes the unused topic parameter from Stasis
subscription callbacks.
Second, this patch introduces the concept of taskprocessor local data,
data that may be set on a taskprocessor and provided along with the data
pointer when a task is pushed using the ast_taskprocessor_push_local()
call. This allows the task to have both data specific to that
taskprocessor, in addition to data specific to that invocation.
With those two changes, the dispatch object can be removed completely,
and the message is simply refcounted and sent directly to the
taskprocessor.
Review: https://reviewboard.asterisk.org/r/2884/
........
Merged revisions 399887,400138,400178,400180-400181 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400186 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When Asterisk receives a 200 OK in response to an invite, that peer should have
sent an SDP at some point by then. If the channel has never received an SDP,
media won't have been set and the remote address won't be known. Endpoints in
general should not be doing this. This patch makes it so that Asterisk will
simply hang up a call if it sends a 200 OK at this point. So far this odd
behavior for endpoints has only been observed in tests which involved manually
created SIP transactions in SIPp.
(closes issue ASTERISK-22424)
Reported by: Jonathan Rose
Review: https://reviewboard.asterisk.org/r/2827/
........
Merged revisions 399939 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 399962 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 399976 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399978 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The PRI and SS7 link control threads are not stopped correctly when the
chan_dahdi.so module is unloaded. The link control threads pri_dchannel()
and ss7_linkset() are not awakened from a poll() to cancel the thread.
* Added a SIGURG signal after requesting the thread cancel to break the
link control thread poll() immediately.
For SS7 it was slightly worse, the link poll() timeout would always be
whatever was the last libss7 scheduled event time used. If no libss7
scheduled event was pending, the thread could run more often than
necessary.
* Set nextms to 60 seconds for the ss7_linkset() poll() if there is no
other libss7 scheduled event.
........
Merged revisions 399818 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 399834 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 399842 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399844 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1st Issue
When a realtime peer sends an un-REGISTER request, Asterisk
un-registers the peer but the database table record still has regseconds and
fullcontact for the peer. This results in calls attempting to be routed to the
peer which is no longer registered. The expected behavior is to get
busy/congested when attempting to call an un-registered peer through the
dialplan.
What was discovered is that we are clearing out the peer's registration in the
database in parse_register_contact() when calling expire_register() but then
upon returning from parse_register_contact(), update_peer() is run which stores
back in the database table regseconds and fullcontact.
2nd Issue
The reporter pointed out that the 200 ok being returned by Asterisk
after un-registering a peer contains a Contact header with ;expires= and the
Expires header is not set to 0. This is actually a regression.
Tests were created for this second issue (ASTERISK-22548). The tests have been
reviewed and a Ship It! was received on those tests.
This patch does the following:
* Do not ignore the Expires header value even when it is set to 0. The patch
sets the pvt->expiry earlier on in the function so that it is set properly and
used.
* If pvt->expiry is 0, do not call update_peer since that means the peer has
already been un-registered and there is no need to update the database record
again since nothing has changed.
(closes issue ASTERISK-22428)
Reported by: Ben Smithurst
Tested by: Ben Smithurst, Michael L. Young
Patches:
asterisk-22428-rt-peer-update-and-expires-header.diff
by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2869/
........
Merged revisions 399794 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 399795 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 399796 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399797 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Richard Mudgett
Matthew Jordan
Corey Farrell
Jonathan Rose
Kinsey Moore
Joshua Colp
Scott Griepentrog
Igor Goncharovskiy
Sean Bright
Damien Wedhorn
Rusty Newton
Kevin Harwell
Tzafrir Cohen
Russell Bryant
David M. Lee
Mark Michelson
Michael L. Young