When the monitor thread is stopped, its pthread ID is set to a specific value
(AST_PTHREADT_STOP) so that later portions of the code can determine whether
or not it is safe to manipulate the thread. Unfortunately, __sip_reliable_xmit
failed to check for that value, checking instead only for AST_PTHREAD_STOP.
Passing the invalid yet very specific value to pthread_kill causes a crash.
This patch adds a check for AST_PTHREADT_STOP in __sip_reliable_xmit such that
it doesn't attempt to poke the thread if the thread has already been stopped.
ASTERISK-24800 #close
Reported by: JoshE
........
Merged revisions 432198 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 432199 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432200 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch addresses the following problems:
* ari/resource_channels: In ARI, we currently create a format capability
structure of SLIN and apply it to the new channel being created. This was
originally done when the PBX core was used to create the channel, as there
was a condition where a newly created channel could be created without any
formats. Unfortunately, now that the Dial API is being used, this has two
drawbacks:
(a) SLIN, while it will ensure audio will flows, can cause a lot of
needless transcodings to occur, particularly when a Local channel is
created to the dialplan. When no format capabilities are available, the
Dial API handles this better by handing all audio formats to the requsted
channels. As such, we defer to that API to provide the format
capabilities.
(b) If a channel (requester) is causing this channel to be created, we
currently don't use its format capabilities as we are passing in our own.
However, the Dial API will use the requester channel's formats if none
are passed into it, and the requester channel exists and has format
capabilities. This is the "best" scenario, as it is the most likely to
create a media path that minimizes transcoding.
Fixing this simply entails removing the providing of the format capabilities
structure to the Dial API.
* chan_pjsip: Rather than blindly picking the first format in the format
capability structure - which actually *can* be a video or text format - we
select an audio format, and only pick the first format if that fails. That
minimizes the weird scenario where we attempt to transcode between video/audio.
* res_pjsip_sdp_rtp: Applied the joint capapbilites to the format structure.
Since ast_request already limits us down to one format capability once the
format capabilities are passed along, there's no reason to squelch it here.
* channel: Fixed a comment. The reason we have to minimize our requested
format capabilities down to a single format is due to Asterisk's inability
to convey the format to be used back "up" a channel chain. Consider the
following:
PJSIP/A => L;1 <=> L;2 => PJSIP/B
g,u,a g,u,a g,u,a u
That is, we have PJSIP/A dialing a Local channel, where the Local;2 dials
PJSIP/B. PJSIP/A has native format capabilities g722,ulaw,alaw; the Local
channel has inherited those format capabilities down the line; PJSIP/B
supports only ulaw. According to these format capabilities, ulaw is
acceptable and should be selected across all the channels, and no
transcoding should occur. However, there is no way to convey this: when L;2
and PJSIP/B are put into a bridge, we will select ulaw, but that is not
conveyed to PJSIP/A and L;1. Thus, we end up with:
PJSIP/A <=> L;1 <=> L;2 <=> PJSIP/B
g g X u u
Which causes g722 to be written to PJSIP/B.
Even if we can convey the 'ulaw' choice back up the chain (which through
some severe hacking in Local channels was accomplished), such that the chain
looks like:
PJSIP/A <=> L;1 <=> L;2 <=> PJSIP/B
u u u u
We have no way to tell PJSIP/A's *channel driver* to Answer in the SDP back
with only 'ulaw'. This results in all the channel structures being set up
correctly, but PJSIP/A *still* sending g722 and causing the chain to fall
apart.
There's a lot of difficulty just in setting this up, as there are numerous
race conditions in the act of bridging, and no clean mechanism to pass the
selected format backwards down an established channel chain. As such, the
best that can be done at this point in time is clarifying the comment.
Review: https://reviewboard.asterisk.org/r/4434/
ASTERISK-24812 #close
Reported by: Matt Jordan
........
Merged revisions 432195 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432196 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds a new feature to ARI to redirect a channel to another server,
and fixes a few bugs in PJSIP's handling of the Transfer dialplan
application/ARI redirect capability.
*New Feature*
A new operation has been added to the ARI channels resource, redirect. With
this, a channel in a Stasis application can be redirected to another endpoint
of the same underlying channel technology.
*Bug fixes*
In the process of writing this new feature, two bugs were fixed in the PJSIP
stack:
(1) The existing .transfer channel callback had the limitation that it could
only transfer channels to a SIP URI, i.e., you had to pass
'PJSIP/sip:foo@my_provider.com' to the dialplan application. While this is
still supported, it is somewhat unintuitive - particularly in a world full
of endpoints. As such, we now also support specifying the PJSIP endpoint to
transfer to.
(2) res_pjsip_multihomed was, unfortunately, trying to 'help' a 302 redirect by
updating its Contact header. Alas, that resulted in the forwarding
destination set by the dialplan application/ARI resource/whatever being
rewritten with very incorrect information. Hence, we now don't bother
updating an outgoing response if it is a 302. Since this took a looong time
to find, some additional debug statements have been added to those modules
that update the Contact headers.
Review: https://reviewboard.asterisk.org/r/4316/
ASTERISK-24015 #close
Reported by: Private Name
ASTERISK-24703 #close
Reported by: Matt Jordan
........
Merged revisions 431717 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431718 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There are three CLI commands to stop and restart Asterisk each.
1) core stop/restart now - Hangup all calls and stop or restart Asterisk.
New channels are prevented while the shutdown request is pending.
2) core stop/restart gracefully - Stop or restart Asterisk when there are
no calls remaining in the system. New channels are prevented while the
shutdown request is pending.
3) core stop/restart when convenient - Stop or restart Asterisk when there
are no calls in the system. New calls are not prevented while the
shutdown request is pending.
ARI has made stopping/restarting Asterisk more problematic. While a
shutdown request is pending it is desirable to continue to process ARI
HTTP requests for current calls. To handle the current calls while a
shutdown request is pending, a new committed to shutdown phase is needed
so ARI applications can deal with the calls until the system is fully
committed to shutdown.
* Added a new shutdown committed phase so ARI applications can deal with
calls until the final committed to shutdown phase is reached.
* Made refuse new HTTP requests when the system has reached the final
system shutdown phase. Starting anything while the system is actively
releasing resources and unloading modules is not a good thing.
* Split the bridging framework shutdown to not cleanup the global bridging
containers when shutting down in a hurry. This is similar to how other
modules prevent crashes on rapid system shutdown.
* Moved ast_begin_shutdown(), ast_cancel_shutdown(), and
ast_shutting_down(). You should not have to include channel.h just to
access these system functions.
ASTERISK-24752 #close
Reported by: Matthew Jordan
Review: https://reviewboard.asterisk.org/r/4399/
........
Merged revisions 431692 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431694 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a SIP device that has its registration stored in RealTime unregisters,
the entry for that device is updated with blank values, i.e., "", indicating
that it is no longer registered. Unfortunately, one of those values that is
'blanked' is the device's port. If the column type for the port is not a
string datatype (the recommended type is integer), an ODBC or database error
will be thrown. MariaDB does not coerce empty strings to a valid integer value.
This patch updates the query run from chan_sip such that it replaces the port
value with a value of '0', as opposed to a blank value. This is the value that
other database backends coerce the empty string ("") to already, and the
handling of reading a RealTime registration value from a backend already
anticipates receiving a port of '0' from the backends.
ASTERISK-24772 #close
Reported by: Richard Miller
patches:
chan_sip.diff uploaded by Richard Miller (License 5685)
........
Merged revisions 431673 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 431674 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431675 65c4cc65-6c06-0410-ace0-fbb531ad65f3
RFC 3261 sections 8.1.1.8 and 12.1.1 dictate specific
scenarios when we are required to use SIPS URIs in Contact
headers. Asterisk's non-compliance with this could actually
cause calls to get dropped when communicating with clients
that are strict about checking the Contact header.
Both of the SIP stacks in Asterisk suffered from this issue.
This changeset corrects the behavior in chan_sip.
ASTERISK-24646 #close
Reported by Stephan Eisvogel
Review: https://reviewboard.asterisk.org/r/4346
........
Merged revisions 431423 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 431424 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431425 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When refreshing (with a small expiration) a registration that was sent to
chan_sip the nonce would be considered stale and reject the registration.
What was happening was that the initial registration's "dialog" still existed
in the dialogs container and upon refresh the dialog match algorithm would
choose that as the "dialog" instead of the newly created one. This occurred
because the algorithm did not check to see if the from tag matched if
authentication info was available after the 401. So, it ended up assuming
the original "dialog" was a match and stopped the search. The old "dialog"
of course had an old nonce, thus the stale nonce message.
This fix attempts to leave the original functionality alone except in the case
of a REGISTER. If a REGISTER is received if searches for an existing "dialog"
matching only on the callid. If the expires value is low enough it will reuse
dialog that is there, otherwise it will create a new one.
ASTERISK-24715 #close
Reported by: John Bigelow
Review: https://reviewboard.asterisk.org/r/4367/
........
Merged revisions 431187 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 431194 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431197 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch addresses compilation errors on OS X. It's been a while, so
there's quite a few things.
* Fixed __attribute__ decls in route.h to be portable.
* Fixed htonll and ntohll to work when they are defined as macros.
* Replaced sem_t usage with our ast_sem wrapper.
* Added ast_sem_timedwait to our ast_sem wrapper.
* Fixed some GCC 4.9 warnings using sig*set() functions.
* Fixed some format strings for portability.
* Fixed compilation issues with res_timing_kqueue (although tests still fail
on OS X).
* Fixed menuconfig /sbin/launchd detection, which disables res_timing_kqueue
on OS X).
ASTERISK-24539 #close
Reported by: George Joseph
ASTERISK-24544 #close
Reported by: George Joseph
Review: https://reviewboard.asterisk.org/r/4327/
........
Merged revisions 431092 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431093 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When the SIP registrations were migrated to using ao2 in what was then trunk,
the explicit destruction of the registrations on module reload was removed and
not replaced with an ao2 equivalent. Debugging done by Stefan Engström, the
issue reporter, on ASTERISK-24673 confirmed that the reference in the
registry_list container was being leaked.
Since the purpose of cleanup_all_regs is to prep a registration for
destruction, this function now calls an ao2_callback function callback with the
OBJ_MULTIPLE | OBJ_NODATA | OBJ_UNLINK flags used to remove the registrations.
This cleans up each registration, and also removes it from the registration
container registry_list.
Review: https://reviewboard.asterisk.org/r/4355/
ASTERISK-24640 #close
Reported by: Max Man
ASTERISK-24673 #close
Reported by: Stefan Engström
Tested by: Stefan Engström
........
Merged revisions 430864 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430866 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Calling ast_channel_bridge_peer() cannot be done while holding any channel
locks. The reported issue hit the deadlock in chan_iax2, but an audit of
the ast_channel_bridge_peer() calls found three more locations where the
same deadlock can occur.
* Made CHANNEL(peer), res_fax, and the SNMP agent not call
ast_channel_bridge_peer() with any channel locked. For CHANNEL(peer) I
had to rework the logic to not hold the channel lock.
* Made chan_iax2 no longer call ast_channel_bridge_peer(). It was done
for legacy reasons that no longer apply.
* Removed the iax.conf forcejitterbuffer option. It is now always enabled
when the jitterbuffer option is enabled. If you put a jitter buffer on a
channel it will be on the channel.
ASTERISK-24600 #close
Reported by: Jeff Collell
Review: https://reviewboard.asterisk.org/r/4342/
........
Merged revisions 430817 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430819 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Different clients react differently to being told that a blind transfer
has failed. Some will simply send a BYE and be done with it. Others will
attempt to reinvite themselves back onto the call.
In the latter case, we were creating a new channel and then leaving it to
sit forever doing nothing. With this code change, that new channel will
not be created and the dialog with the transferring channel will be cleaned
up properly.
ASTERISK-24624 #close
Reported by Zane Conkle
Review: https://reviewboard.asterisk.org/r/4339
........
Merged revisions 430714 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430715 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The 'pjsip_get_dest_info' function is used to determine if the signaling transport
of the dialog is secure or not. This function was added in PJSIP 2.3 and does not
exist in earlier versions.
This configure check allows Asterisk to build and run with older versions at the
loss of the 'secure' argument for the PJSIP CHANNEL dialplan function. Usage of
this argument will require upgrading to PJSIP 2.3.
ASTERISK-24665 #close
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/4329/
........
Merged revisions 430546 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430547 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Made the following AMI actions use list API calls for consistency:
Agents
BridgeInfo
BridgeList
BridgeTechnologyList
ConfbridgeLIst
ConfbridgeLIstRooms
CoreShowChannels
DAHDIShowChannels
DBGet
DeviceStateList
ExtensionStateList
FAXSessions
Hangup
IAXpeerlist
IAXpeers
IAXregistry
MeetmeList
MeetmeListRooms
MWIGet
ParkedCalls
Parkinglots
PJSIPShowEndpoint
PJSIPShowEndpoints
PJSIPShowRegistrationsInbound
PJSIPShowRegistrationsOutbound
PJSIPShowResourceLists
PJSIPShowSubscriptionsInbound
PJSIPShowSubscriptionsOutbound
PresenceStateList
PRIShowSpans
QueueStatus
QueueSummary
ShowDialPlan
SIPpeers
SIPpeerstatus
SIPshowregistry
SKINNYdevices
SKINNYlines
Status
VoicemailUsersList
* Incremented the AMI version to 2.7.0.
* Changed astman_send_listack() to not use the listflag parameter and
always set the value to "Start" so the start capitalization is consistent.
i.e., The FAXSessions used "Start" while the rest of the system used
"start". The corresponding complete event always used "Complete".
* Fixed ami_show_resource_lists() "PJSIPShowResourceLists" to output the
AMI ActionID for all of its list events.
* Fixed off-nominal AMI protocol error in manager_bridge_info(),
manager_parking_status_single_lot(), and
manager_parking_status_all_lots(). Use of astman_send_error() after
responding to the original AMI action request violates the action response
pattern by sending two responses.
* Fixed minor protocol error in action_getconfig() when no requested
categories are found. Each line needs to be formatted as "Header: text".
* Fixed off-nominal memory leak in manager_build_parked_call_string().
* Eliminated unnecessary use of RAII_VAR() in ami_subscription_detail().
ASTERISK-24049 #close
Reported by: Jonathan Rose
Review: https://reviewboard.asterisk.org/r/4315/
........
Merged revisions 430434 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430435 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Given the following scenario:
* Three SIP phones (A, B, C), all communicating via a proxy with Asterisk
* A call is established between A and B. B performs a SIP attended transfer of
A to C. B sets the call on hold (A is hearing MOH) and dials the extension of
C. While phone C is ringing, B transfers the call (that is, what we typically
call a 'blond transfer').
* When the transfer completes, A hears the ringing of phone C, while B is idle.
In the SIP messaging for the above scenario, a REFER request is sent to
transfer the call. When "sendrpid=yes" is set in sip.conf, Asterisk may send an
UPDATE request to phone C to update party information. This update is sent
directly to phone C, not through the intervening proxy. This has the unfortunate
side effect of providing route information, which is then set on the sip_pvt
structure for C. If someone (e.g. B) is trying to get the call back (through a
directed pickup), Asterisk will send a CANCEL request to C. However, since we
have now updated the route set, the CANCEL request will be sent directly to C
and not through the proxy. The phone ignores this CANCEL according to RFC3261
(Section 9.1).
This patch updates reqprep such that the route is not updated if an UPDATE
request is being sent while the INVITE state is INV_PROCEEDING or
INV_EARLY_MEDIA. This ensures that a subsequent CANCEL request is still sent
to the correct location.
Review: https://reviewboard.asterisk.org/r/4279
ASTERISK-24628 #close
Reported by: Karsten Wemheuer
patches:
issue.patch uploaded by Karsten Wemheuer (License 5930)
........
Merged revisions 429982 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 429983 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429984 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When the configuration section scheme of chan_dahdi.conf is used (keyword
dahdichan instead of channel) all setvar= options are completely ignored.
No variable defined this way appears in the created DAHDI channels.
* Move the clearing of setvar values to after the deferred processing of
dahdichan.
AST-1378 #close
Reported by: Guenther Kelleter
Patch by: Guenther Kelleter
........
Merged revisions 429825 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 429829 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429830 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For the featdmf signaling mode the incoming MF Caller-ID information is
formatted as follows: *${CALLERID(ani2)}${CALLERID(ani)}#*${EXTEN}#
Rather than discarding the ani2 digits, populate the CALLERID(ani2) value
with what is received instead.
AST-1368 #close
Reported by: Denis Martinez
Patches:
extract_ani2_for_featdmf_v11.patch (license #5621) patch uploaded by Richard Mudgett
........
Merged revisions 429783 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 429784 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429785 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this patch, we were using the PJSIP dialog's secure flag
to determine if a secure transport was being used. Unfortunately,
the dialog's secure flag was only set if a SIPS URI were in use,
as required by RFC 3261 sections 12.1.1 and 12.1.2. What we're interested
in is not dialog security, but transport security. This code change
switches to a model where we use the dialog's target URI to determine
what transport would be used to communicate, and then check if that
transport is secure.
AST-1450 #close
Reported by John Bigelow
Review: https://reviewboard.asterisk.org/r/4277
........
Merged revisions 429739 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429740 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r413586 (1.8) various casts were added to silence gcc 4.10 warnings.
Those fixes included things like:
-out += sprintf(out, "%%%02X", (unsigned char) *ptr);
+out += sprintf(out, "%%%02X", (unsigned) *ptr);
That works for low ascii characters, but for the high range that yields
e.g. FFFFFFC3 when C3 is expected.
This changeset:
- fixes those casts to use the 'hh' unsigned char modifier instead
- consistently uses %02x instead of %2.2x (or other non-standard usage)
- adds a few 'h' modifiers in various places
- fixes a 'replcaes' typo
- dev/urandon typo (in 13+ patch)
Review: https://reviewboard.asterisk.org/r/4263/
ASTERISK-24619 #close
Reported by: Stefan27 (on IRC)
........
Merged revisions 429673 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 429674 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 429675 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429683 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Previously when SRTP was enabled on a channel it was not possible
to switch to T.38 as no crypto attributes would be present.
This change makes it so it is now possible. If a T.38 re-invite
comes in SRTP is terminated since in practice you can't encrypt
a UDPTL stream. Now... if we were doing T.38 over RTP (which
does exist) then we'd have a chance but almost nobody does that so
here we are.
ASTERISK-24449 #close
Reported by: Andreas Steinmetz
patches:
udptl-ignore-srtp-v2.patch submitted by Andreas Steinmetz (license 6523)
........
Merged revisions 429632 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 429633 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429634 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When direct media is enabled and a pjsip channel is answered a race would occur
between the handling of the answer and bridge setup. Sometimes the media
negotiation would take place after the native bridge was setup. This resulted
in a NULL media address, which in turn resulted in Asterisk using its address
as the remote media address when sending a reinvite. This patch makes the
chan_pjsip answer handler synchronous thus alleviating the race condition (the
bridge won't start setting things up until after it returns).
ASTERISK-24563 #close
Reported by: Steve Pitts
Review: https://reviewboard.asterisk.org/r/4257/
........
Merged revisions 429477 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429478 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Given the scenario where a PJSIP channel is in a native RTP bridge with direct
media and the channel is then hung up the code will currently re-INVITE the channel
back to Asterisk and send a BYE at the same time. Many SIP implementations dislike
this greatly.
This change makes it so that if a re-INVITE transaction is in progress the BYE
is queued to occur after the completion of the transaction (be it through normal
means or a timeout).
Review: https://reviewboard.asterisk.org/r/4248/
........
Merged revisions 429409 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429410 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When endpoints with direct_media enabled, behind a firewall (Asterisk on a
separate network) and were bridged sometimes Asterisk would send the ip
address of the firewall in the sdp to one of the phones in the reinvite
resulting in one way audio. When sending the reinvite Asterisk will retrieve
the media address from the associated rtp instance, but if frames were being
read this can be overwritten with another address (in this case the
firewall's). This patch ensures that Asterisk uses the original device
address when using direct media.
ASTERISK-24563
Reported by: Steve Pitts
Review: https://reviewboard.asterisk.org/r/4216/
........
Merged revisions 429195 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 429196 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429197 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this patch, all Stasis subscriptions would receive a dedicated
thread for servicing published messages. In contrast, prior to r400178
(see review https://reviewboard.asterisk.org/r/2881/), the subscriptions
shared a thread pool. It was discovered during some initial work on Stasis
that, for a low subscription count with high message throughput, the
threadpool was not as performant as simply having a dedicated thread per
subscriber.
For situations where a subscriber receives a substantial number of messages
and is always present, the model of having a dedicated thread per subscriber
makes sense. While we still have plenty of subscriptions that would follow
this model, e.g., AMI, CDRs, CEL, etc., there are plenty that also fall into
the following two categories:
* Large number of subscriptions, specifically those tied to endpoints/peers.
* Low number of messages. Some subscriptions exist specifically to coordinate
a single message - the subscription is created, a message is published, the
delivery is synchronized, and the subscription is destroyed.
In both of the latter two cases, creating a dedicated thread is wasteful (and
in the case of a large number of peers/endpoints, harmful). In those cases,
having shared delivery threads is far more performant.
This patch adds the ability of a subscriber to Stasis to choose whether or not
their messages are dispatched on a dedicated thread or on a threadpool. The
threadpool is configurable through stasis.conf.
Review: https://reviewboard.asterisk.org/r/4193
ASTERISK-24533 #close
Reported by: xrobau
Tested by: xrobau
........
Merged revisions 428681 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 428687 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428688 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Due to the serialized architecture of chan_pjsip there exists a race condition where a CANCEL may
be received and processed before responses (such as 180 Ringing, 183 Session Progress, and 200 OK)
are sent. Since the session is in an unexpected state PJSIP will assert when this is attempted.
This change makes it so that these responses are not sent on disconnected sessions.
ASTERISK-24471 #close
Reported by: yaron nahum
........
Merged revisions 428301 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 428302 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428303 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For chan_motif the direct return value of the underlying config options framework
was passed back. This can relay various states which the module loader would not
interpet as success. It has been changed so only on errors will it report back
an error.
For chan_pjsip the code implemented a dummy reload function which always
returned an error. This has been removed as all configuration is held within
res_pjsip instead.
ASTERISK-23651 #close
Reported by: Rusty Newton
........
Merged revisions 427981 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427982 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Configuration of DTLS in the general section will be applied to any users
or peers. If configuration exists at their level it overrides the general
section values.
ASTERISK-24128 #close
Reported by: Michael K.
patches:
dtls_default_settings.patch submitted by Michael K. (license 6621)
Review: https://reviewboard.asterisk.org/r/3867/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427950 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r227276, a while loop was turned into a for loop. Unfortunately, a portion
of the while loop was left in the code such that, when a static gateway is
encountered in the list of MGCP gateways, the next gateway would be skipped.
At best, we would simply flip past a gateway; at worst, this could lead to a
crash.
ASTERISK-24500 #close
Reported by: Xavier Hienne
patches:
chan_mgcp.patch uploaded by Xavier Hienne (License 6657)
........
Merged revisions 427613 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 427614 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427615 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427616 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change adds an option, moh_passthrough, that when enabled will pass
hold and unhold requests through using a SIP re-invite. When placing on
hold a re-invite with sendonly will be sent and when taking off hold a
re-invite with sendrecv will be sent. This allows remote servers to handle
the musiconhold instead of the local Asterisk instance being responsible.
Review: https://reviewboard.asterisk.org/r/4103/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427112 65c4cc65-6c06-0410-ace0-fbb531ad65f3
