[Home]

Summary:ASTERISK-28451: chan_pjsip: HANGUPCAUSE(<channel>,tech) fails to get SIP cause for rejected calls
Reporter:Kingsley Tart (skycomltd)Labels:pjsip
Date Opened:2019-06-14 11:56:27Date Closed:2021-10-22 11:11:28
Priority:MinorRegression?
Status:Closed/CompleteComponents:Channels/chan_pjsip
Versions:13.21.0 Frequency of
Occurrence
Related
Issues:
Environment:CentOS 7Attachments:( 0) astlog.gz
( 1) dtmf-test.pcap.gz
( 2) scenario1.txt
( 3) scenario2.txt
( 4) scenario3.txt
( 5) scenario4.txt
Description:Using Asterisk certified/13.21-cert2.

When a destination SIP server rejects a call, a hangup handler running in the outbound PJSIP channel can't get the SIP status message from HANGUPCAUSE(<channel>,tech), and HANGUPCAUSE_KEYS() returns nothing.

The same hangup handler works perfectly on Asterisk 11 using the older SIP engine.

This can be demonstrated with this test dialplan:

{code}
[testdial]
exten => _X.,1,Dial(PJSIP/custom/sip:901@pbx.example.com,,b(testaddhandler^set_handler^1))
same => n,Hangup()

[testaddhandler]
exten => set_handler,1,NoOp(Setting handler)
same => n,Set(CHANNEL(hangup_handler_push)=testhandler,outbound_handler,1)
same => n,Return()

[testhandler]
exten => outbound_handler,1,NoOp(## Hangup handler)
same => n,NoOp(## CHANNEL=${CHANNEL})
same => n,NoOp(## HANGUPCAUSE_KEYS=${HANGUPCAUSE_KEYS()})
same => n,NoOp(## HANGUPCAUSE=${HANGUPCAUSE(${CHANNEL},tech)})
same => n,Return()
{code}


I have outlined 4 scenarios here. The first 3 work fine, but the last one breaks.


*Scenario 1* - the destination (sip:901@pbx.example.com in this example) starts ringing (and sends SIP 180 back) but then the caller hangs up before it's answered. The hangup handler can get the sip status in this scenario; from the Asterisk console:
{code}
   -- Executing [outbound_handler@testhandler:1] NoOp("PJSIP/custom-000000ec", "## Hangup handler") in new stack
   -- Executing [outbound_handler@testhandler:2] NoOp("PJSIP/custom-000000ec", "## CHANNEL=PJSIP/custom-000000ec") in new stack
   -- Executing [outbound_handler@testhandler:3] NoOp("PJSIP/custom-000000ec", "## HANGUPCAUSE_KEYS=PJSIP/custom-000000ec") in new stack
   -- Executing [outbound_handler@testhandler:4] NoOp("PJSIP/custom-000000ec", "## HANGUPCAUSE=SIP 180 Ringing") in new stack
{code}

*Scenario 2* - the destination (sip:901@pbx.example.com in this example) is answered and then the caller hangs up. This is also OK:
{code}
   -- Executing [outbound_handler@testhandler:1] NoOp("PJSIP/custom-000000ee", "## Hangup handler") in new stack
   -- Executing [outbound_handler@testhandler:2] NoOp("PJSIP/custom-000000ee", "## CHANNEL=PJSIP/custom-000000ee") in new stack
   -- Executing [outbound_handler@testhandler:3] NoOp("PJSIP/custom-000000ee", "## HANGUPCAUSE_KEYS=PJSIP/squiresvi-000000ed,PJSIP/custom-000000ee") in new stack
   -- Executing [outbound_handler@testhandler:4] NoOp("PJSIP/custom-000000ee", "## HANGUPCAUSE=SIP 200 OK") in new stack
{code}

*Scenario 3* - the destination (sip:901@pbx.example.com in this example) is answered and then the *callee* hangs up. This is OK as well:
{code}
   -- Executing [outbound_handler@testhandler:2] NoOp("PJSIP/custom-000000f0", "## CHANNEL=PJSIP/custom-000000f0") in new stack
 == Spawn extension (testdial, 01476292507, 1) exited non-zero on 'PJSIP/squiresvi-000000ef'
   -- Executing [outbound_handler@testhandler:3] NoOp("PJSIP/custom-000000f0", "## HANGUPCAUSE_KEYS=PJSIP/custom-000000f0,PJSIP/squiresvi-000000ef") in new stack
   -- Executing [outbound_handler@testhandler:4] NoOp("PJSIP/custom-000000f0", "## HANGUPCAUSE=SIP 200 OK") in new stack
{code}


*Scenario 4* - a call is made to a non-existant SIP address on the destination server (901xxxx@sip.example.com in my attached example) so the remote server sends back SIP 404. *THIS BREAKS*
{code}
   -- Executing [outbound_handler@testhandler:1] NoOp("PJSIP/custom-000000f2", "## Hangup handler") in new stack
   -- Executing [outbound_handler@testhandler:2] NoOp("PJSIP/custom-000000f2", "## CHANNEL=PJSIP/custom-000000f2") in new stack
   -- Executing [outbound_handler@testhandler:3] NoOp("PJSIP/custom-000000f2", "## HANGUPCAUSE_KEYS=") in new stack
[Jun 13 19:47:15] WARNING[19118][C-00000096]: func_hangupcause.c:140 hangupcause_read: Unable to find information for channel PJSIP/custom-000000f2
   -- Executing [outbound_handler@testhandler:4] NoOp("PJSIP/custom-000000f2", "## HANGUPCAUSE=") in new stack
{code}

Note that in my testing, this doesn't just break on SIP 404 responses, but any remote server rejection.
Comments:By: Asterisk Team (asteriskteam) 2019-06-14 11:56:28.611-0500

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur.

By: Kingsley Tart (skycomltd) 2019-06-14 12:00:52.629-0500

I  have uploaded 4 files, one for each test scenario, showing the full Asterisk console output and also the corresponding SIP messages. They can be downloaded from here:

[http://quitebig.com/misc-published/asterisk13-pjsip-hangupcausekeys-bug/scenario1.txt]
[http://quitebig.com/misc-published/asterisk13-pjsip-hangupcausekeys-bug/scenario2.txt]
[http://quitebig.com/misc-published/asterisk13-pjsip-hangupcausekeys-bug/scenario3.txt]
[http://quitebig.com/misc-published/asterisk13-pjsip-hangupcausekeys-bug/scenario4.txt]


By: Joshua C. Colp (jcolp) 2019-06-17 05:16:09.456-0500

Please attach files to the issue in the future instead of linking offsite. This ensures a full record with information is kept in case people will need to revisit this. Additionally if you have a support agreement please contact Digium Technical Support for assistance. If you do not then be aware that if any fixes occur as a result of this they will not be applied to certified.

By: Joshua C. Colp (jcolp) 2019-06-17 05:47:26.984-0500

Using the current mainline version I'm unable to reproduce this problem:

{nocode}
   -- Executing [1000@testdial:1] Dial("PJSIP/blink2-00000000", "PJSIP/mytrunk_endpoint/sip:901@172.16.10.155,,b(testaddhandler^set_handler^1)") in new stack
   -- PJSIP/mytrunk_endpoint-00000001 Internal Gosub(testaddhandler,set_handler,1) start
   -- Executing [set_handler@testaddhandler:1] NoOp("PJSIP/mytrunk_endpoint-00000001", "Setting handler") in new stack
   -- Executing [set_handler@testaddhandler:2] Set("PJSIP/mytrunk_endpoint-00000001", "CHANNEL(hangup_handler_push)=testhandler,outbound_handler,1") in new stack
   -- Executing [set_handler@testaddhandler:3] Return("PJSIP/mytrunk_endpoint-00000001", "") in new stack
 == Spawn extension (from-external, 1000, 1) exited non-zero on 'PJSIP/mytrunk_endpoint-00000001'
   -- PJSIP/mytrunk_endpoint-00000001 Internal Gosub(testaddhandler,set_handler,1) complete GOSUB_RETVAL=
   -- Called PJSIP/mytrunk_endpoint/sip:901@172.16.10.155
   -- PJSIP/mytrunk_endpoint-00000001 Internal Gosub(testhandler,outbound_handler,1) start
   -- Executing [outbound_handler@testhandler:1] NoOp("PJSIP/mytrunk_endpoint-00000001", "## Hangup handler") in new stack
   -- Executing [outbound_handler@testhandler:2] NoOp("PJSIP/mytrunk_endpoint-00000001", "## CHANNEL=PJSIP/mytrunk_endpoint-00000001") in new stack
   -- Executing [outbound_handler@testhandler:3] NoOp("PJSIP/mytrunk_endpoint-00000001", "## HANGUPCAUSE_KEYS=PJSIP/mytrunk_endpoint-00000001") in new stack
   -- Executing [outbound_handler@testhandler:4] NoOp("PJSIP/mytrunk_endpoint-00000001", "## HANGUPCAUSE=SIP 404 Not Found") in new stack
   -- Executing [outbound_handler@testhandler:5] Return("PJSIP/mytrunk_endpoint-00000001", "") in new stack
 == Spawn extension (from-external, 1000, 1) exited non-zero on 'PJSIP/mytrunk_endpoint-00000001'
   -- PJSIP/mytrunk_endpoint-00000001 Internal Gosub(testhandler,outbound_handler,1) complete GOSUB_RETVAL=
 == Everyone is busy/congested at this time (1:0/0/1)
   -- Executing [1000@testdial:2] Hangup("PJSIP/blink2-00000000", "") in new stack
 == Spawn extension (testdial, 1000, 2) exited non-zero on 'PJSIP/blink2-00000000'
{nocode}

If you do the same does it still occur for you?

By: Kingsley Tart (skycomltd) 2019-06-17 06:07:36.363-0500

{quote}Please attach files to the issue in the future instead of linking offsite. This ensures a full record with information is kept in case people will need to revisit this.{quote}

Hi Joshua,

I tried to do that but couldn't see the option to upload files. I've used JIRA elsewhere and to upload I click on the Edit button to edit the task and then there's a file upload option within that, but on this instance of JIRA I don't have that option. I didn't notice there was a separate "Attach Files" button.

We'll have a play with v13.27 or whatever the latest 13 is and let you know how that goes.

By: Joshua C. Colp (jcolp) 2019-06-17 06:09:53.243-0500

Attach Files is under the "More" dropdown.

By: Kingsley Tart (skycomltd) 2019-06-17 10:38:25.504-0500

I have checked with version 13.27 and the problem is fixed on there, so thanks.

By: Asterisk Team (asteriskteam) 2021-10-22 11:08:45.975-0500

This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable.

By: Kingsley Tart (skycomltd) 2021-10-22 11:11:28.125-0500

Accidentally re-opened issue by attaching files to wrong bug report.