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