PJSIP ARI application issues hanging up calls

[Javierd]

Hi,
I’m working on a project where I need to use an ARI application on two different use cases:

• On the first one I need to receive two calls and join them on a bridge. When one of both calls hangs up, the other call should hung up too and the bridge should be destroyed.
• On the second one I need to perform a call from Asterisk to an endpoint and put in into a bridge. Again, when one of the bridge participants leave the bridge, the other calls should hang up and the bridge should be destroyed.

The logic is pretty easy in both cases, and I can initiate both kind of calls and communicate, but i’m having some troubles to hung up the calls:

• On the first case, when the call is supposed to be finished I try to remove the channel by using DELETE channel/<channelId> . Here, if the first user who hangs up first is the last one who joined the bridge, the other channel never hangs up (in this case, I have tested with both Zoiper5 and Linphone apps) although the DELETE /channel/<channelId>method is called successfully and in fact the StasisEnd event is received. I have the following log of the Stasis events received from an execution of this type:
  stasis_hangup_fail.txt (14.3 KB)

Note that although the StasisEnd event for the channel 1656425845.61 event is present, the softphone didn’t really hunged up.

• On the second case, I have tried creating the outgoing call with POST /channels and with POST /channels/create (followed by a posterior POST /dial operation), specifying in both cases the endpoint, the ari app name, and the originator. However, when the sip agent receiving this outgoing call is the one which hungs up first, I don’t receive any kind of StasisEnd event on the ARI app, so I cannot hung up the call. Note that previous event are received, like the StasisStart or the JoinBridge ones. The only events I don’t receive are the ones associated with the hunging up process.

Does somebody know where could these problems come from?

Thanks a lot

[jcolp]

Have you confirmed the SIP signaling?

[Javierd]

I’ve just just been testing this again checking Asterisks and both clients SIP logs.
On the second case, when Zoiper/Linphone hangs up, no BYE event is received on Asterisk, which explains why there is also no StasisEnd event created. However, the call is finished on the device, and in fact, on the Zoiper’s logs the BYE message is sent:

zoiper_logs.txt (34.0 KB)

The device which hangs up is the one with id 6002, while the other one is the one called admin.
There are two things that seem a bit strange to me in these logs:

• The first one is that the the message is sent to sip:asterisk@213.37.134.165:5060 where 213.37.134.165 is my public IP, but I’m running Asterisk behind a NAT (as the other two devices) and I have never specified that IP, where did it came from?
• The other one is that the BYE messages include To: <sip:admin@192.168.0.32> but don’t reference the ARI application.
  Could they be related to the problem?
  When other device hungs up (in this case a webrtc client) the events are received.

[jcolp]

The To doesn’t need to reference the ARI application. If Asterisk is behind NAT then it is generally configured in the transport in pjsip.conf with its external IP address and local networks. That could be the cause, but I don’t know as no Asterisk side information has been provided. Ultimately the Bye has to go to Asterisk, otherwise Asterisk has no idea it was hung up.