ARI: No hangup event when originating a call via POST /channels

[TJNII]

Not sure if this is a bug or user error yet, too green on ARI. I’m working on making outbound calls via the REST API, and I’m seeing the following:

• Call is created by making a POST to /ari/channels
  – Exact example: POST http://127.0.0.1:8088/ari/channels?app=hello-world&channelId=MOHCalling.789cd73a-9fd1-47c3-add7-711b6058260c&endpoint=PJSIP/1230&timeout=15
• PJSIP device rings
• Callee answers and hangs up
• No hangup event is registered, and the channel remains up

From the console logs:

[Feb 17 00:14:02]   == WebSocket connection from '127.0.0.1:49554' closed
[Feb 17 00:14:04]  Creating Stasis app 'hello-world'
[Feb 17 00:14:04]   == WebSocket connection from '127.0.0.1:37202' for protocol '' accepted using version '13'
[Feb 17 00:14:07]     -- Called 1230
[Feb 17 00:14:07]     -- PJSIP/1230-00000002 is ringing
[Feb 17 00:14:10]     -- PJSIP/1230-00000002 answered

[Answer call and hang up]

*CLI> Core show channels
Channel                                                          Location                         State   Application(Data)             
PJSIP/1230-00000002                                              s@user_context_1200:1            Up      Stasis(hello-world)           
1 active channel
0 active calls
0 calls processed

The last event I get over the websocket is "type": "StasisStart". No event when the callee hangs up. Since I’m still in the early phases of writing a client my app doesn’t really do much yet, I’ve tried 3 actions when the Stasis app starts:

• Nothing
• Answer
• Start MOH

All 3 behave the same. If I don’t put a timeout in my app to explicitly hangup the channel then the channel appears to stay open forever.

Is there something special I should know here I’m not seeing in the docs, or is this a bug? Asterisk 20.6.0.

[TJNII]

Pretty sure I’m calling the same endpoint as https://github.com/asterisk/ari-examples/blob/master/bridge-dial/example.py#L56-L59 so I don’t think I’m too far off track.

[TJNII]

I figured it out. It wasn’t a ARI problem, it was a SIP signalling problem caused by a stackup of factors, almost all of which were due to my testing config.

The reason the call wasn’t hanging up was due to my test network config stacking up in a way where when my softphone received a call from Asterisk reply signalling was misrouted. Asterisk wasn’t hanging up the call because it never got the hangup message from the softphone.

I don’t think too much detail on the issue/config is needed as I’m way off in a corner case due to:

• Running a prod config that includes a real external IP locally for test
• Having Docker, and therefore multiple interfaces in the mix
• The multiple interfaces being on different RFC1918 ranges (Common with Docker), and only one marked as a local_net in pjsip.conf
• The softphone registering to the host docker0 IP, which nats locally.

The local nat is only relevant as it allowed calls originating from the softphone to work, which gave me the false impression this was a ARI issue and not a SIP/network configuration issue.

I fixed my registration on my softphone and it worked. If you see something like this this check the softphone logs. When I did that I saw a 4xx on BYE from the real server on the public IP and the knot unraveled.