diff options
| author | Richard Mudgett <rmudgett@digium.com> | 2015-10-05 16:53:44 -0500 |
|---|---|---|
| committer | Richard Mudgett <rmudgett@digium.com> | 2015-10-06 16:10:29 -0500 |
| commit | 8fe9350b688c1e57176cc56ca49682e4789655c0 (patch) | |
| tree | 4f8f2c3e70ed38103e1d59994439fe8a79e21e27 /channels/chan_pjsip.c | |
| parent | 52f413f7096b4c6b9cc577aad60b6442e926508d (diff) | |
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
Diffstat (limited to 'channels/chan_pjsip.c')
| -rw-r--r-- | channels/chan_pjsip.c | 13 |
1 files changed, 8 insertions, 5 deletions
diff --git a/channels/chan_pjsip.c b/channels/chan_pjsip.c index 523a01560..d72a25b61 100644 --- a/channels/chan_pjsip.c +++ b/channels/chan_pjsip.c @@ -2134,7 +2134,8 @@ static int chan_pjsip_incoming_request(struct ast_sip_session *session, struct p return 0; } - if (session->inv_session->state >= PJSIP_INV_STATE_CONFIRMED) { + /* Check for a to-tag to determine if this is a reinvite */ + if (rdata->msg_info.to->tag.slen) { /* Weird case. We've received a reinvite but we don't have a channel. The most * typical case for this happening is that a blind transfer fails, and so the * transferer attempts to reinvite himself back into the call. We already got @@ -2181,8 +2182,9 @@ static int call_pickup_incoming_request(struct ast_sip_session *session, pjsip_r struct ast_features_pickup_config *pickup_cfg; struct ast_channel *chan; - /* We don't care about reinvites */ - if (session->inv_session->state >= PJSIP_INV_STATE_CONFIRMED) { + /* Check for a to-tag to determine if this is a reinvite */ + if (rdata->msg_info.to->tag.slen) { + /* We don't care about reinvites */ return 0; } @@ -2229,8 +2231,9 @@ static int pbx_start_incoming_request(struct ast_sip_session *session, pjsip_rx_ { int res; - /* We don't care about reinvites */ - if (session->inv_session->state >= PJSIP_INV_STATE_CONFIRMED) { + /* Check for a to-tag to determine if this is a reinvite */ + if (rdata->msg_info.to->tag.slen) { + /* We don't care about reinvites */ return 0; } |