]> git.ipfire.org Git - thirdparty/asterisk.git/commit
chan_pjsip: Fix crash on reINVITE before initial INVITE completes. 94/1394/1
authorRichard Mudgett <rmudgett@digium.com>
Mon, 5 Oct 2015 21:53:44 +0000 (16:53 -0500)
committerRichard Mudgett <rmudgett@digium.com>
Tue, 6 Oct 2015 21:10:16 +0000 (16:10 -0500)
commit426263a64dc5dc80a51b6950ee0cb6b46f5f052c
tree87b93e36e874914c0b08059b315c5b25ff703d85
parent41b0e516e226b968ebc1af8b79bf38ede1b8c4a7
chan_pjsip: Fix crash on reINVITE before initial INVITE completes.

Apparently some endpoints attempt to send a reINVITE before completing the
initial INVITE transaction.  In this case PJSIP responds appropriately to
the reINVITE with a 491 INVITE request pending.  Unfortunately chan_pjsip
is using the initial INVITE transaction state to determine if an INVITE is
the initial INVITE or a reINVITE.  Since the initial INVITE transaction
has not been confirmed yet chan_pjsip thinks the reINVITE is an initial
INVITE and starts another PBX thread on the channel.  The extra PBX thread
ensures that hilarity ensues.

* Fix checks for a reINVITE on incoming requests to look for the presence
of a to-tag instead of the initial INVITE transaction state.

* Made caller_id_incoming_request() determine what to do if there is a
channel on the session or not.  After a channel is created it is too late
to just store the new party id on the session because the session's party
id has already been copied to the channel's caller id.

ASTERISK-25404 #close
Reported by: Chet Stevens

Change-Id: Ie78201c304a2b13226f3a4ce59908beecc2c68be
channels/chan_pjsip.c
res/res_pjsip_caller_id.c