chan_pjsip: Fix crash on reINVITE before initial INVITE completes.
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:29 +0000 (16:10 -0500)
commit8fe9350b688c1e57176cc56ca49682e4789655c0
tree4f8f2c3e70ed38103e1d59994439fe8a79e21e27
parent52f413f7096b4c6b9cc577aad60b6442e926508d
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