asterisk users - Sep 2023 - Asterisk 16.23.0 strange issue where Answer request succeeds and able to perform actions but Asterisk never sent 200 OK to answer call

Some background...
We use AMI and AsyncAGI to be able to receive events about calls (and other
Asterisk details) and control it from our application.
Works great and have about 100 sites (some newer, some older) without issues.


I was notified this morning about a customer who had something strange happen
and I can't explain it.

Asterisk 16.23.0 and PJSIP.

Call comes into Asterisk.
Asterisk sends the Trying.
Via AMI, notified of the call and dial plan has it go to AsyncAGI for our
application to be able to control the call.
Via AMI, we tell Asterisk to Answer.
Asterisk processes it and indicates it was answered.
The Asterisk AMI/AGI indicates call was answered successfully, call state is Up,
etc.
Everything appears to be normal.
We perform various actions on the call, example play a file, music, tones, etc.

However, Asterisk never sent the 200 OK to answer the call.
Seems as though Asterisk is in a bizarre state where it thinks it is handling
the call, but it really isn't.


Reports are this happened to several calls.

Eventually, they restarted the entire VM and everything started working well.


We think this may be caused by something their switch is doing.
Through the grapevine, heard they had some network issue but don't know the
details of their switches and architecture for calls coming into Asterisk.

We noticed we are seeing two INVITEs happen with the same Call-ID, but 2
additional Record-Route header/value pairs and 3 additional Via header/value
pairs.  At least in first glance, the rest seems to be the same.  I see Asterisk
created two different PJSIP calls for each despite same Call-ID, but I am
guessing that's because of the additional Via or Record-Route pairs.

Is it possible multiple of these double INVITEs could cause Asterisk or PJSIP on
this older software to get into a bad state to cause the issues with AMI and
Asterisk state?

Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20230907/ad41ee8a/attachment.html>