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

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 2019-02-21: After some recent changes I was speaking to an engineer and they now honor PAI again.

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

  1. Hello,

    You’re not alone. Thanks for the post!

    I’m having the exact same issue out of my Vancouver office with Allstream.

    My plan is to spin up a ShoreGear virtual trunk switch and route my SBC traffic to it.

    I’ve found the VTS is better suited to handle SIP traffic than the s90s.

    I’ll let you know how it goes.


  2. Hello,

    Allstream fixed this issue for me. They recently upgraded from a Genman/cs2k to a Metaswitch platform.

    The Genman by default resent SDP to the far end. The Metaswitch does not.

    The tech enabled repeat SDP.

    I’m now able to make outbound calls again successfully and see the SDP in the final 200 OK.

    Thanks for pointing me in the right direction.

    Be sure to call Allstream and have them verify repeat SDP is enabled for your sessions as well.


    1. Thanks Shannon! As per the update I got things working again. Allstream enabled repeat SDP (after an ungodly amount of downtime) and all is well. I changed our Ingate trunk settings to replace the from headers and our outbound CID’s are working again. I’m not a fan of abusing from as a CID setting but hey, what’s a tech to do?

Leave a Reply

Your email address will not be published. Required fields are marked *