ARI: Phone not hanging up after channel is deleted

Hi all,

after moving my installation to PJSIP I see a strange behavior in my ARI application.
The application is registered and receives channel events properly. At some point the application destroys the channel (delete). Again, after deleting the channel I get a ChannelHangupRequest and a StasisEnd on the websocket but the phone doesn’t hang up. It starts playing some sound “the number you are calling is not reachable”.

I guess it should be mentioned that the phone is calling via some sip trunk. I’m pretty sure that the audio playback doesn’t come from asterisk.
What’s puzzling is that on the old system using the legacy SIP provider this works as expected and the phone is hanging up.

Any ideas what’s going on here?


I have done some more investigation and I see one difference:
on hangup the PJSIP system sends:

SIP/2.0 603 Decline

whereas the legacy SIP sends:

SIP/2.0 603 Declined

apart from this I don’t see any significant difference. Could this be the reason why the two systems behave differently?

You’d need to show actual console output including SIP traffic (pjsip set logger on). You could even use chan_sip and examine the difference. For example in the chan_sip case was the channel answered, but in the chan_pjsip case you aren’t answering.

The text is not relevant to the function.

Neither of these represent hang-ups as you have not yet answered the call. They are rejections. The message is being generated by the upstream system, and if they are going to do in-band announcements for call failures, I would expect them to do so for all failure reasons, and the only way to stop them would be to answer the call before hanging it up, however, in many cases, that would result in the caller being charged for the call.

This is what the legacy SIP sends:

<--- Reliably Transmitting (NAT) to --->
SIP/2.0 603 Declined
Via: SIP/2.0/UDP;branch=z9hG4bK3856.ecb3f9e6bd70a84560b719cd296dce4a.0;received=;rport=5060
Via: SIP/2.0/UDP;rport=5060;branch=z9hG4bK-373732-32efe4dcfef117b0b23f9f3fe553424e
From: "0798727973" <sip:0798727973@>;tag=1623664102314
To: <sip:90703057489@>;tag=as212b4e3b
Call-ID: ca5d2153c0953ba94c3c599bb219ec0f@
Server: FPBX-
Supported: replaces, timer
Content-Length: 0

This is what the PJSIP sends:

<--- Transmitting SIP response (643 bytes) to UDP: --->
SIP/2.0 603 Decline
Via: SIP/2.0/UDP;rport=5060;received=;branch=z9hG4bK7608.8e9e72b412ff376fb59956a6c3dbd95f.0
Via: SIP/2.0/UDP;rport=5060;branch=z9hG4bK-373732-d2d2cb9616d2b26c9def008235da8bb2
Record-Route: <sip:;lr;r2=on;did=03.7b95>
Record-Route: <sip:;lr;r2=on;did=03.7b95>
Call-ID: c8aa31263aebdfb2aa92633fecf32bbd@
From: "0798727973" <sip:0798727973@>;tag=1623663751143
To: <sip:90703057489@>;tag=46bb0295-3998-41b4-b3e8-f293b3056368
Server: FPBX-
Reason: Q.850;cause=16
Content-Length:  0

As mentioned above the only significant difference I see is Decline/Declined

It’s also adding a Reason header. You can disable the Reason header by setting the “suppress_q850_reason_headers” option to “yes” on the endpoint. I don’t know if that will make a difference to the provider.

How do I don that?

I added the following to /etc/asterisk/pjsip.endpoints_custom.conf


reloaded the diaplan but the setting doesn’t take effect

Are you using FreePBX? If so I don’t recall the specific stuff to do for it to take effect in its configuration world.

yes, that’s what I’m using.

I’m not quite sure about the syntax. I followed these instructions:

but i’m not quite sure about the


Firstly, this forum is not the right place for help on configuring FreePBX.

+ with a modifier is a new one on me. pjsip.conf is probably the only place where it is useful, but it is certainly going to be necessary. If you just repeat a section name, it becomes a new section, and either it or the original one might even be ignored completely. (+) says append to the existing section of the name. However, pjsip can have multiple sections of the same name, so I assume that the type= part ensures that you add to the right one of those.

Ok, back to the original topic. That was it. I set “suppress_q850_reason_headers” to yes and now it works. I’m not quire sure why that made the difference but it does.

Thanks very much for your support!

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.