Asterisk 12 Crashes On CANCEL Received During ANSWER Handlingl

Home » Asterisk Users » Asterisk 12 Crashes On CANCEL Received During ANSWER Handlingl
Asterisk Users 2 Comments

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?

Thanks, Yaron.

2 thoughts on - Asterisk 12 Crashes On CANCEL Received During ANSWER Handlingl

  • Yaron Nachum wrote:

    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.

  • 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.