]> git.ipfire.org Git - thirdparty/asterisk.git/commit
chan_pjsip: Fix crash on reINVITE before initial INVITE completes. 93/1393/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 16:17:16 +0000 (11:17 -0500)
commitc4f63952fc264f9f6d312ec9a78df0cc8f2f88e4
treed8d9b55232a50a9e796e7e2bc7105897863a7152
parentd61da57428e767036155377d606a322e0cef2d9d
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