Shoretel for Sadists (1xx-rel sip session ending on a SG-90)

3 minute read

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 & Cheap Kentucky Corn Water.

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. Furthermore I begrudgingly admit that state machines are hard.

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.

What’s happening:

In our case the provider’s upgrade actually brought them closer to the RFC (

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 conflagrating over there, so who knows.

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. After getting Allstream to re-enable repeat SDP the issue was resolved!

Update 2017-02-01: After getting repeat SDP enabled and an unconscionable amount of downtime the calls and outbound CID’s are working again. I’m not a fand of abusing FROM as a CID setting but they won’t honour PAI anymore but 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.