TL;WR: SIP Provider changed their 1xx-rel implementation and removed an SDP from the final invite (Closer to RFC now). Shoregear switches can’t deal with that apparently (pfft-RFC? hah!). Suggested Matching: Earl-Grey & Baileys.
Update: The Allstream tech’s enabled repeat SDP and outbound calls started working again, I changed our Ingate sip rules to set the CID in From instead of leaving it in P-Asserted-Ident. Shannon gave more details on the specifics of the upgrade in the comment section.
Is this relevant? If your packet cap shows invite, 100 trying, then a 183 session progress with “Require: 100rel” in the header. If your voice switch is sending ACK sip:… BYE sip:… after a 200 OK with an invite and no sdp.
Shoretel Voice Switch (SG-90, Director 14.2)
Ingate Siparator SBC (5.0.11)
Whelp, I’ve finally cracked, I got tired of digging through an endless stream of bookmarks and old tickets. What better way to document a descent into madness than starting with a SIP issue!
My current employers SIP provider decided that there was no way upgrading their SBC would affect their customers… so of course at 00:00 UTC January 18th 2017 all of our outbound calls started failing.
Outbound calls will fail after the far end answers. Sometimes a few second of media will get through before the call ends. This can happen because of a delay between the SG-90 sending bye and the media stream ending. Occasionally a call will work. We’ll go into why in a second.
In our case the provider’s upgrade actually brought them closer to the RFC (https://tools.ietf.org/html/rfc6337#section-3.1.1).
You’ll see on their ascii flow diagram the following at packet F12:
SDP should not be included in the final response once offer/answer has been completed.
Now our provider was sending an SDP in packet F12. RFC says you shouldn’t without good reason but they were anyway. Not that I mind. After their upgrade they removed the redundant SDP. In my case the useful SDP’s were being sent in packet F1 and F6.
The SG-90 behind my Ingate was flowing as follows.
F1: Outbound Invite (With SDP)
F2: Inbound 100 Trying
F6: Inbound 183 Session Progress (with SDP & Require 100rel)
F7: Outbound PRACK
F8: Inbound 200 PRACK
F12: Inbound 200 Invite (now with no SDP)
F13: Outbound ACK
On packet F12 the far end has answered and the provider is asking me to join the media session. Unfortunately Shoretel isn’t a fan of not having the SDP on the invite. The SG-90 will dutifully Ack the Invite, then promptly send Bye and end the session.
If you console onto the SG-90 (here) you shouldn’t even need to do a sip trace (although you can here). At the end of the call you’ll see the following two errors:
ERROR : SIPIntf_sip.c:1828 : errorCode:(-13)Not_Found (sipintf_sip_dvc_call_answer)
WARNING : SIPIntf_RvCallLeg.c:781 : errorCode:(-13)Not_Found (SIPIntf_CallLegStateChangedEvHandler)
At the time of this writing (Jan 19th 2017) I can’t help you much further. I’m currently engaging Shoretel and the SIP provider for some further answers but I can’t Interop-magic my way out of this one without breaking some features. This isn’t a case where I can tell the SBC to just swallow a message or handle it on its own, the SG90 apparently needs an SDP on packet F12 and I can’t just generate one with an ingate.
Here’s where it stands: Allstream got bought by Zayo, Upgraded their SBC
(which now conveniently no longer honors P-Asserted-Identity), and decided to change their SIP implementation. I doubt either of those is going to change soon. It’s not great when the alternative is to wait for Shoretel to make a firmware
I am not alone though, my lovely friend at Allstream tells me it’s quietly going to hell over there, so who knows.
Update 2019-02-21: After some recent changes I was speaking to an engineer and they now honor PAI again.