I am running Asterisk 14.6.2 with PJSIP.
This issue came to my attention from a user who complained that her two calls to the same number were unexpectedly dropped, back-to-back. The CDR showed both calls were exactly 30 minutes and 0 seconds. Verizon Enterprise was the outbound provider in this case. I opened a ticket with Verizon and one of their engineers managed to pin-point the problem as a mal-formatted re-invite received from our Asterisk Server at the 30-minute mark. My server was using the default session timers value of 1800. The line in the SIP body that normally should read “c=IN IP4 1.2.3.4” was transmitted as “c=IN IP4”, without any IP. Accordingly, the Verizon session controller responded with “400 Bad Request” along with an “Error-Info:” header containing a message, “SIP syntax error”. As a consequence, Asterisk followed by hanging up the call with a “Bye” message.
My server is behind a static NAT using a static WAN IP and the Verizon endpoint is set to use a transport that has both external_media_address and external_signaling_address set to 1.2.3.4 (Not my actual WAN IP, of course).
Since the issue was identified a few days ago, I have been able to reproduce it many times. Unfortunately, it doesn’t happen on every attempt, and to reproduce it I have to make a phone call and wait for the second session timer heartbeat message to occur. Perhaps half of my attempts have reproduced this SIP Syntax Error glitch, dropping my call, while the other half of the attempts are normal. I began my tests by using the default timers_sess_expires value of 1800. It causes heartbeat re-invites every 15 minutes. So of course I had to wait 30 minutes for each call attempt to try and capture the error. The first heartbeat is always correct. The second heartbeat half the time experiences the SIP syntax error. To help speed up my testing I set the timers_sess_expires value to 300 and basically got the same result. It caused heartbeat re-invites every 2.5 minutes and I observed the first one always correct and the second one half the time mal-formatted.
For the time being I have disabled session timers to my Verizon endpoints using timers=no, which appears to alleviate my sporadic dropped call problem. Nonetheless, this appears to be a bug in how PJSIP formats session timers under certain yet-to-be-discovered circumstances. Before I report this as a bug in the issue tracker, I’d like some assistance from the community on how I might be able to better identify the circumstances that trigger this mal-formatting of SIP re-invite messages related to the session timer.
Incidentally, can anyone tell me why Asterisk chooses to use UPDATE messages for the session timer heartbeats on some of the calls, while it also chooses to use INVITE messages for the other calls? During all my test calls I always saw INVITE, but the Verizon engineer I worked with pointed to some other calls from my endpoint that used UPDATE messages for the heartbeats.