Shoretel for Sadists (1xx-rel sip session ending on a SG-90)
TL;WR: SIP Provider changed their 1xx-rel implementation when migrating from a Genman/cs2k platform to Metaswitch and removed the SDP from the final invite (Closer to RFC now). Shoregear switches can’t deal with that apparently (pfft-RFC? hah!). I begrudgingly admit that state machines are hard.
Suggested Pairing: Old Grand-Dad’s Kentucky Corn Water.
Is this relevant?
- Does your packet cap show an invite, 100 trying, then a 183 session progress with “Require: 100rel” in the header?
- Does your voice switch is sending ACK sip:… BYE sip:… after a 200 OK with an invite and no sdp.
- Are you on a Shoretel platform (if no: how did you even get here?) similar to mine?
Shoretel Voice Switch (SG-90, Director 14.2)
Ingate Siparator SBC (5.0.11)
What’s the background?
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 employer’s 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 seconds 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.
What’s happening?
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 (2017-01-19) 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 fabricate 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 update.
I am not alone though, my lovely friend at Allstream tells me it’s quietly conflagrating over there, so who knows what the future will bring.
Time Travelling Post-Scripts
Update 2017-01-27: Another user is running into the same issue with Allstream out of a Vancouver location. They mentioned that they’ve found the VTS to be better suited to SIP traffic than the SG90’s.
Update 2017-01-30: The same user provided some extra background. Allstream migrated from the Genman/cs2k patform to a Metaswitch implementation. The Genman had repeat SDP enabled by default but Metaswitch follows the RFC more closely and does not send unnecessary SDPs.
Update: The Allstream tech’s enabled “repeat SDP” for us and after an unconscionable amount of degraded service the signalling issues cleared up! Unfortunately they stopped honouring PAI so I changed our Ingate SIP rules to set the CID in From instead of leaving it in P-Asserted-Ident. I’m not a fan of abusing FROM as a CID setting but they won’t honour PAI anymore so hey: what’s a tech to do?
Update 2019-02-21: After some recent changes I was speaking to an engineer and Allstream now honors PAI again.