pjsip_inv_end_session() is documented as being able to return the
passed in tdata parameter set to NULL on success.
Change-Id: I09d53725c49b7183c41bfa1be3ff225f3a8d3047
When shutting down res_pjsip_session will get unloaded before res_pjsip.
The act of unloading unregisters all the PJSIP services and sets
their module IDs to -1. In some cases it is possible for a timer to
occur after this happens which calls into res_pjsip_session. The
res_pjsip_session module can then try to get the session from the
INVITE session using the module ID. Since the module ID is now -1
this fails.
This change stores a copy of the module ID and uses it for the timer
callback scenario. If the module ID is -1 the callback immediately
returns but if the module ID is valid then it continues as normal.
This works as the original ID of the module is guaranteed to still
be valid when used with the INVITE session.
ASTERISK-26127 #close
Change-Id: I88df72525c4e9ef9f19c13aedddd3ac4a335c573
We must continue using the serializer that the original INVITE came in on
for the dialog. There may be retransmissions already enqueued in the
original serializer that can result in reentrancy and message sequencing
problems.
Outgoing call legs create the pjsip/outsess/<endpoint> serializers for
their dialogs.
ASTERISK-26088
Reported by: Richard Mudgett
Change-Id: I24d7948749c582b8045d5389ba3f6588508adbbc
Some SIP devices indicate hold/unhold using deferred SDP reinvites. In
other words, they provide no SDP in the reinvite.
A typical transaction that starts hold might look something like this:
* Device sends reinvite with no SDP
* Asterisk sends 200 OK with SDP indicating sendrecv on streams.
* Device sends ACK with SDP indicating sendonly on streams.
At this point, PJMedia's SDP negotiator saves Asterisk's local state as
being recvonly.
Now, when the device attempts to unhold, it again uses a deferred SDP
reinvite, so we end up doing the following:
* Device sends reinvite with no SDP
* Asterisk sends 200 OK with SDP indicating recvonly on streams
* Device sends ACK with SDP indicating sendonly on streams
The problem here is that Asterisk offered recvonly, and by RFC 3264's
rules, if an offer is recvonly, the answer has to be sendonly. The
result is that the device is not taken off hold.
What is supposed to happen is that Asterisk should indicate sendrecv in
the 200 OK that it sends. This way, the device has the freedom to
indicate sendrecv if it wants the stream taken off hold, or it can
continue to respond with sendonly if the purpose of the reinvite was
something else (like a session timer refresher).
The fix here is to alter the SDP negotiator's state when we receive a
reinvite with no SDP. If the negotiator's state is currently in the
recvonly or inactive state, then we alter our local state to be
sendrecv. This way, we allow the device to indicate the stream state as
desired.
ASTERISK-25854 #close
Reported by Robert McGilvray
Change-Id: I7615737276165eef3a593038413d936247dcc6ed
Per RFC3325, the 'From' header is now anonymized on outgoing calls when
caller id presentation is prohibited.
TID = trust_id_outbound
PRO = Set(CALLERID(pres)=prohib)
USR = endpoint/from_user
DOM = endpoint/from_domain
PAI = YES(privacy=off), NO(not sent), PRI(privacy=full) (assumes send_pai=yes)
Conditions |Result
--------------------|----------------------------------------------------
TID PRO USR DOM |PAI FROM
--------------------|----------------------------------------------------
Y Y abc def.ghi |PRI "Anonymous" <sip:abc@def.ghi>
Y Y abc |PRI "Anonymous" <sip:abc@anonymous.invalid>
Y Y def.ghi |PRI "Anonymous" <sip:anonymous@def.ghi>
Y Y |PRI "Anonymous" <sip:anonymous@anonymous.invalid>
Y N abc def.ghi |YES <sip:abc@def.ghi>
Y N abc |YES <sip:abc@<ip_address>>
Y N def.ghi |YES "Caller Name" <sip:<caller_exten>@def.ghi>
Y N |YES "Caller Name" <sip:<caller_exten>@<ip_address>>
N Y abc def.ghi |NO "Anonymous" <sip:abc@def.ghi>
N Y abc |NO "Anonymous" <sip:abc@anonymous.invalid>
N Y def.ghi |NO "Anonymous" <sip:anonymous@def.ghi>
N Y |NO "Anonymous" <sip:anonymous@anonymous.invalid>
N N abc def.ghi |YES <sip:abc@def.ghi>
N N abc |YES <sip:abc@<ip_address>>
N N def.ghi |YES "Caller Name" <sip:<caller_exten>@def.ghi>
N N |YES "Caller Name" <sip:<caller_exten>@<ip_address>>
ASTERISK-25791 #close
Reported-by: Anthony Messina
Change-Id: I2c82a5ca1413c2c00fb62ea95b0ae8e97af54dc9
The 'reload' mechanism actually involves closing the underlying
socket and calling the appropriate udp, tcp or tls start functions
again. Only outbound_registration, pubsub and session needed work
to reset the transport before sending requests to insure that the
pjsip transport didn't get pulled out from under them.
In my testing, no calls were dropped when a transport was changed
for any of the 3 transport types even if ip addresses or ports were
changed. To be on the safe side however, a new transport option was
added (allow_reload) which defaults to 'no'. Unless it's explicitly
set to 'yes' for a transport, changes to that transport will be ignored
on a reload of res_pjsip. This should preserve the current behavior.
Change-Id: I5e759850e25958117d4c02f62ceb7244d7ec9edf
Attempting to load a transport from realtime was forcing asterisk into an
infinite recursion loop. The first thing transport_apply did was to do a
sorcery retrieve by id for an existing transport of the same name. For files,
this just returns the previous object from res_sorcery_config's internal
container, if any. For realtime, the res_sourcery_realtime driver looks in the
database and finds the existing row but now it has to rehydrate it into a
sorcery object which means calling... transport_apply. And so it goes.
The main issue with loading from realtime (apart from the loop) was that
transport stores structures and pointers directly in the ast_sip_transport
structure instead of the separate ast_transport_state structure. This patch
separates those items into the ast_sip_transport_state structure. The pattern
is roughly the same as res_pjsip_outbound_registration.
Although all current usages of ast_sip_transport and ast_sip_transport_state
were modified to use the new ast_sip_get_transport_state API, the original
items are left in ast_sip_transport and kept updated to maintain ABI
compatability for third-party modules. They are marked as deprecated and
noted that they're now in ast_sip_transport_state.
ASTERISK-25606 #close
Reported-by: Martin Moučka
Change-Id: Ic7a836ea8e786e8def51fe3f8cce855ea54f5f19
Make certain that the pjsip session has not failed to
allocate the format capabilities structure, which can
otherwise cause a crash when referenced.
ASTERISK-25323
Change-Id: I602790ba12714741165e441cc64a3ecde4cb5750
The keepalive support in res_pjsip_sdp_rtp currently assumes
that a stream will only be negotiated once. This is false.
If the stream is replaced and later added back it can be
negotiated again causing multiple keepalive scheduled items
to exist. This change explicitly deletes the existing
keepalive scheduled item before adding the new one.
The res_pjsip_sdp_rtp module also does not stop RTP
keepalives or timeout timer if the stream has been
replaced. This change adds a callback to the session media
interface to allow a media stream to be stopped without
the resources being destroyed. This allows the scheduled
items and RTP to be stopped when the stream no longer
exists.
ASTERISK-25356 #close
Change-Id: Ibe6a7cc0927c87326fd5f1c0d4ad889dbfbea1de
When a BYE request is received the PJSIP invite session implementation
creates and sends a 200 OK response before we are aware of it. This
causes the INVITE session state callback to be called into and ultimately
the session supplements run on the BYE request. Once this response has
been sent the normal transaction state callback is invoked which
invokes the session supplements on the BYE request again. This can
be problematic in particular with res_pjsip_rfc3326 as it may
attempt to update the hangup cause code on the channel while it is
in the process of being hung up.
This change makes it so the session supplements are only invoked
once by the INVITE session state callback.
ASTERISK-25318 #close
Change-Id: I69c17df55ccbb61ef779ac38cc8c6b411376c19a
Modules commonly used the pj_gethostip function for retrieving the
IP address of the host. This function does not cache the result and may
result in a DNS lookup occurring, or additional work. If the DNS
server is unreachable or network issues arise this can cause the
pj_gethostip function to block for a period of time.
This change adds an ast_sip_get_host_ip and ast_sip_get_host_ip_string
function which does the same thing but caches the host IP address at
module load time. This results in no additional work being done each
time the local host IP address is needed.
ASTERISK-25342 #close
Change-Id: I3205deb679b01fa5ac05a94b623bfd620a2abe1e
Two testsuite tests crashed in the same place as a result of an INVITE
being CANCELed.
tests/channels/pjsip/resolver/srv/failover/in_dialog/transport_unspecified
tests/channels/pjsip/resolver/srv/failover/in_dialog/transport_tcp
The session pointer is no longer in the inv->mod_data[session_module.id]
location because the INVITE transaction has reached the terminated state.
ASTERISK-25297 #close
Reported by: Richard Mudgett
Change-Id: Idb75fdca0321f5447d5dac737a632a5f03614427
This change adds support for the 'rtp_timeout' and 'rtp_timeout_hold'
endpoint options. These allow the channel to be hung up if RTP
is not received from the remote endpoint for a specified number of
seconds.
ASTERISK-25259 #close
Change-Id: I3f39daaa7da2596b5022737b77799d16204175b9
This adds an "rtp_keepalive" option for PJSIP endpoints. Similar to the
chan_sip option, this specifies an interval, in seconds, at which we
will send RTP comfort noise frames. This can be useful for keeping RTP
sessions alive as well as keeping NAT associations alive during lulls.
ASTERISK-25242 #close
Reported by Mark Michelson
Change-Id: I3b9903d99e35fe5d0b53ecc46df82c750776bc8d
The crash fix for ASTERISK-25183 backported some code from master to try
to make sure that a BYE response is processed by the same serializer used
by the BYE request. The identified race condition causing that backport
was the BYE request code had not finished processing after sending the BYE
before the BYE response came in for processing under a different thread.
Unfortunately, there is still a race condition. Now the race condition is
between destroying the call session's serializer in
ast_taskprocessor_unreference() and using ast_taskprocessor_get() to get a
reference to the serializer for a BYE response. Even worse, the new race
condition is a design limitation of the taskprocessor implementation that
didn't matter in versions before v12. Back then, taskprocessors were only
destroyed when a module unloaded. Now res_pjsip can destroy them when a
call ends.
However, as noted on the ASTERISK-25183 commit,
session_inv_on_state_changed() is disassociating the dialog from the
session when the invite dialog state becomes PJSIP_INV_STATE_DISCONNECTED.
This is a tad too soon because our BYE request transaction has not
completed yet.
* Split session_end() that is called by session_inv_on_state_changed() to
hold off session destruction until the BYE transaction timeout occurs or a
failed initial INVITE transaction timeout occurs in
session_inv_on_tsx_state_changed().
ASTERISK-25201 #close
Reported by: Matt Jordan
Change-Id: Iaf8dc8485fd8392a2a3ee4ad3b7f7f04a0dcc961
When a caller calls a FAX number and then hangs up right after the call is
answered then the T.38 re-INVITE automatic reject timer may still be
running after the channel goes away.
* Added session NULL channel checks on the code paths that get executed by
t38_automatic_reject() to prevent a crash when the T.38 re-INVITE
automatic reject timer expires.
ASTERISK-25168
Reported by: Carl Fortin
Change-Id: I07b6cd23815aedce5044f8f32543779e2f7a2403
Previously Asterisk did not properly failover to the next resolved DNS
address when a endpoint could not be reached. With this patch, and while
using res_pjsip, SIP requests (both in/out of dialog) now attempt to use
the next address in the list of resolved addresses until a proper response
is received or no more addresses are left.
ASTERISK-25076 #close
Reported by: Joshua Colp
Change-Id: Ief14f4ebd82474881f72f4538f4577f30af2a764
It is possible to receive incoming requests or responses after the channel
on an ast_sip_session has been destroyed and NULLed out. Handlers of these
sorts of requests or responses need to be prepared for the possibility
that the channel is NULL or else they could cause a crash.
While several places have been amended to deal with NULL channels, there
were still a couple of places that needed updating.
res_pjsip_dtmf_info.c: When handling incoming INFO requests, we need to
return early if there is no channel on the session.
res_pjsip_session.c: When handling a 302 response, we need to stop the
redirecting attempt if there is no channel on the session.
ASTERISK-25148 #close
reported by Mark Michelson
Change-Id: Id1a75ffc3d0eaa168b0b28188fb54d6cf9fc47a9
When the remote peer requires authentication for in-dialog requests then
re-INVITEs to the peer cause the call to be disconnected and other
in-dialog requests to the peer like MESSAGE just don't go through.
* Made session_inv_on_tsx_state_changed() handle in-dialog authentication
for re-INVITEs and other methods. Initial INVITEs cannot be handled here
because the INVITE transaction must be restarted earlier.
* Pulled needed code from res/res_pjsip/pjsip_outbound_auth.c in
preparation for removing the file. The generic outbound authentication
code did not work as well as anticipated.
* Created outbound_invite_auth() to only handle initial outbound INVITEs.
Re-INVITEs cannot be handled here. The re-INVITE transaction is still in
progress and the PJSIP library cannot handle the overlapping INVITE
transactions. Other method types should not be handled here as this code
only works on outgoing calls and we need to handle incoming and outgoing
calls.
ASTERISK-25131 #close
Reported by: Richard Mudgett
Change-Id: I12bdd7ddccc819b4ce4b091e826d1e26334601b0
This patch adds support for automatically detecting the type of DTMF that a
PJSIP endpoint supports. When the 'dtmf_mode' endpoint option is set to 'auto',
the channel created for an endpoint will attempt to determine if RFC 4733
DTMF is supported. If so, it will use that DTMF type. If not, the DTMF type
for the channel will be set to inband.
Review: https://reviewboard.asterisk.org/r/4438
ASTERISK-24706 #close
Reported by: yaron nahum
patches:
yaron_patch_3_Feb.diff submitted by yaron nahum (License 6676)
........
Merged revisions 434637 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@434638 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Move most of res_pjsip:module_unload to unload_pjsip to resolve crashes
caused by running PJSIP functions from non-PJSIP threads.
* Remove call to pjsip_endpt_destroy(ast_pjsip_endpoint), it was causing
crashes in some cases. In theory pj_shutdown() should take care of this.
* Mark res_pjsip_keepalive and res_pjsip_session as allowed to unload at
shutdown.
* Resolve leaked config global in res_pjsip_notify.
* Unregister pubsub pjsip service module.
* Implement cleanup for res_pjsip_session.
ASTERISK-24731 #close
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/4498/
........
Merged revisions 433469 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@433470 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A race condition happened between initiating a transfer and requesting
that a dialog termination be delayed. Occasionally, the transferrer
channels would exit the bridge and hangup before the dialog termination
delay was requested.
* Made request dialog termination delay before initiating the transfer
action. If the transfer fails then cancel the delayed dialog termination
request.
ASTERISK-24755 #close
Reported by: John Bigelow
Review: https://reviewboard.asterisk.org/r/4460/
........
Merged revisions 432668 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432669 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A multi-asterisk box setup with direct media enabled would occasionally
crash when two re-INVITE collisions on a call leg happen in a row.
The re-INVITE logic only had one timer struct to defer the re-INVITE.
When the second collision happens the timer struct is overwritten and put
into the timer heap again. Resources for the first timer are leaked and
the heap has two positions occupied by the same timer struct. Now the
heap ordering is potentially corrupted, the timer will fire twice, and any
resources allocated for the second timer will be released twice.
* The solution is to put the collided re-INVITE into the delayed requests
queue with all the other delayed requests and cherry pick the next request
that can come off the queue when an event happens.
* Changed to put delayed BYE requests at the head of the delayed queue.
There is no sense in processing delayed UPDATEs and re-INVITEs when a BYE
has been requested.
* Made the start of a BYE request flush the delayed requests queue to
prevent a delayed request from overlapping the BYE transaction. I saw a
few cases where a delayed re-INVITE got started after the BYE transaction
started.
* Changed the delayed_request struct to use an enum instead of a string
for the request method. Cherry picking the queue is easier with an enum
than string comparisons and the compiler can warn if a switch statement
does not cover all defined enum values.
* Improved the debug output to give more information. It helps to know
which channel is involved with an endpoint. Trunks can have many channels
associated with the endpoint at the same time.
ASTERISK-24727 #close
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/4414/
........
Merged revisions 431734 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431735 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
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
In the past the SDP negotiation within res_pjsip_session was made more tolerant of
certain situations. The only case where SDP negotiation will fail is when a major
error occurs during negotiation. Receiving an already declined media stream is
not considered a major error.
When producing the local SDP the logic took this into account so on the initial INVITE
the declined media stream did not cause an SDP negotiation failure. Unfortunately
the logic for handling media streams with a handler did not mirror this logic and
considered an already declined media stream an error and thus failed the SDP
negotiation.
This change makes the logic between both situations match so only under major
errors will the SDP negotiation fail.
ASTERISK-24607 #close
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/4254/
........
Merged revisions 429407 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429408 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The reviewboard description does a fine job of summarizing this, so here it is:
A reporter discovered that Asterisk would crash when attempting to retransmit
a reinvite that had previously received a 491 response. The crash occurred
because a pjsip_tx_data structure was being saved for reuse, but its reference
count was not being increased. The result was that the pjsip_tx_data was being
freed before we were actually done with it. When we attempted to re-use the
structure when re-sending the reinvite, Asterisk would crash.
The fix implemented here is not to try holding onto the pjsip_tx_data at all.
Instead, when we reschedule sending the reinvite, we create a brand new
pjsip_tx_data and send that instead. Because of this change, there is no need
for an ast_sip_session_delayed_request structure to have a pjsip_tx_data on
it any more. So any code referencing its use has been removed.
When this initial fix was introduced, I encountered a second crash when
processing a subsequent 200 OK on a rescheduled reinvite. The reason was
that when rescheduling the reinvite, we gave the wrong location for a
response callback. This has been fixed in this patch as well.
ASTERISK-24556 #close
Reported by Abhay Gupta
Review: https://reviewboard.asterisk.org/r/4233
........
Merged revisions 429089 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429090 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When an inbound SDP offer is received, Asterisk currently makes a few
incorrection assumptions:
(1) If the offer contains more than a single audio/video stream, Asterisk will
reject the entire stream with a 488. This is an overly strict response;
generally, Asterisk should accept the media streams that it can accept and
decline the others.
(2) If the offer contains a declined media stream, Asterisk will attempt to
process it anyway. This can result in attempting to match format
capabilities on a declined media stream, leading to a 488. Asterisk should
simply ignore declined media streams.
(3) Asterisk will currently attempt to handle offers with AVPF with
use_avpf=No/AVP with use_avpf=Yes. This mismatch results in invalid SDP
answers being sent in response. If there is a mismatch between the media
type being offered and the configuration, Asterisk must reject the offer
with a 488.
This patch does the following:
* Asterisk will accept SDP offers with at least one media stream that it can
use. Some WARNING messages have been dropped to NOTICEs as a result.
* Asterisk will not accept an offer with a media type that doesn't match its
configuration.
* Asterisk will ignore declined media streams properly.
#SIPit31
Review: https://reviewboard.asterisk.org/r/4063/
ASTERISK-24122 #close
Reported by: James Van Vleet
ASTERISK-24381 #close
Reported by: Matt Jordan
........
Merged revisions 425868 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 425879 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@425881 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Performing a directed call pickup resulted in a deadlock when PJSIP
channels were involved.
A masquerade needs to hold onto the channel locks while it swaps channel
information between the two channels involved in the masquerade. With
PJSIP channels, the fixup routine needed to push a fixup task onto the
PJSIP channel's serializer. Unfortunately, if the serializer was also
processing a task that needed to lock the channel, you get deadlock.
* Added a new control frame that is used to notify the channels that a
masquerade is about to start and when it has completed.
* Added the ability to query taskprocessors if the current thread is the
taskprocessor thread.
* Added the ability to suspend/unsuspend the PJSIP serializer thread so a
masquerade could fixup the PJSIP channel without using the serializer.
ASTERISK-24356 #close
Reported by: rmudgett
Review: https://reviewboard.asterisk.org/r/4034/
........
Merged revisions 424471 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 424472 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@424473 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Due to the architecture of how media streams are handled each individual
handler adds connection details (IP address) for it. The first media stream
is then used as the top level SDP connection line. In practice each
line ends up being the same so to reduce the SDP size stream-level connection
information is also added to the SDP if it differs from the top level SDP
connection line.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@424077 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Testsuite tests will occasionally fail because on reception of a 200 OK SIP response,
an AST_CONTROL_ANSWER frame is queued prior to when media has finished being
negotiated. This is because session supplements are called into before PJSIP's
inv_session code has told us that media has been updated. Sometimes the queued answer
frame is handled by the PBX thread before the ensuing media negotiations occur, causing
a test failure.
As it turns out, there is another place that session supplements could be called into, which is
after media has finished getting negotiated. What this commit introduces is a means for session
supplements to indicate when they wish to be called into when handling an incoming SIP response.
By default, all session supplements will be run at the same point that they were prior to this
commit. However, session supplements may indicate that they wish to be handled earlier than
normal on redirects, or they may indicate they wish to be handled after media has been negotiated.
In this changeset, two session supplements have been updated to indicate a preference for when
they should be run: res_pjsip_diversion executes before handling redirection in order to get
information from the Diversion header, and chan_pjsip now handles responses to INVITEs after
media negotiation to fix the race condition mentioned previously.
ASTERISK-24212 #close
Reported by Matt Jordan
Review: https://reviewboard.asterisk.org/r/3930
........
Merged revisions 422536 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422542 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422543 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Richard Mudgett
Joshua Colp
Mark Michelson
George Joseph
Scott Griepentrog
Kevin Harwell
Rodrigo Ramírez Norambuena
Matthew Jordan
Corey Farrell
Kinsey Moore