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.