[asterisk-users] Asterisk 12 crashes on CANCEL received during ANSWER handlingl

Yaron Nachum nachum.yaron at gmail.com
Wed Nov 12 13:30:06 CST 2014


Hello Joshua,
Thank you for your response. It was important for us to make sure this fix
is harmless.

We will wait for someone to fix it. If you need any assistance we are here.
This issue occurs quite often in our environment.

Yaron.

On Wed, Nov 12, 2014 at 5:16 PM, Joshua Colp <jcolp at digium.com> wrote:

> Yaron Nachum wrote:
>
>> Hello Asterisk users and developers,
>> The last few weeks we had several crashes on live asterisks running
>> versions  12.2.0rc1 / 12.6.1 with PJPROJECT versions 2.1.0 / 2.2.1. We
>> opened a ticket - ASTERISK-24471.
>>
>> After investigating the issue I can say that the scenario is a CANCEL
>> being received while handling ANSWER and before generating the 200OK
>> response.
>>
>> Looking at the core file we see that the problem is in
>> - pjsip/src/pjsip/sip_transaction.c line 3158 :
>>          PJ_ASSERT_RETURN(event->type == PJSIP_EVENT_TX_MSG &&
>> event->body.tx_msg.tdata == tsx->last_tx,
>>                           PJ_EINVALIDOP);
>>
>> After investigating further I came to a conclusion that the second
>> expression fails (marked with yellow), and that causes the Asterisk to
>> crash.
>>
>> I have already removed the expression and logged whenever this
>> expression fails. It seems to work fine. Since the change it the
>> happened several times, the application didn't crash and going over the
>> debug it seems that the call was handled fine.
>>
>> Can anyone tell what is the purpose of this expression? Any explanation
>> why this expression fails in the above scenario?
>>
>
> PJSIP is written with assertions in various places which check various
> conditions to make sure that things are as expected. In the above scenario
> what's happening is that the CANCEL is coming in and changing the
> transaction so when the answer is sent (which occurs after handling the
> CANCEL) it is not in the expected state and it asserts. It's safe to do as
> you've done since the operation will do nothing, but that's not a viable
> fix to push upstream as it's a result of an implementation detail with
> chan_pjsip. The fix will occur in chan_pjsip once the issue is handled.
>
> --
> Joshua Colp
> Digium, Inc. | Senior Software Developer
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US
> Check us out at: www.digium.com & www.asterisk.org
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>               http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20141112/86f3227c/attachment.html>


More information about the asterisk-users mailing list