Category Archives: Shoretel Purgatory

Shoretel Users Can’t Change Call Handling Mode or Agent Status

TL;WR Probably the SG90 acting up again. Those things are weird. Rebooting the SG90 and the Director server fixed it for me. YMMV.

While moving around some VM’s we had a Shoretel Director server running without a network connection for 4 hours during a maintenance window. Afterwards users couldn’t change their Call Handling Modes or change their agent logged in/out status. It failed from both the phones and from communicator. At first I thought it was a CAS problem; however the phone directory, history, options, and speed dial features were all working correctly.

I popped up the IPDSCASCfgTool (see bottom) to set the log levels for the CAS to include all the DB and CAS flags for a start. After that I used powershell to stream the logs with Get-Content. I use Measure-Object first to grab the line count of the file so that we can skip the first 393,000 lines straight to the live output. That’ll work like tail -f in linux and just continuously stream the logs to the console.

Note: You SHOULD be able to use Get-Content -Wait -Tail <Number of Lines> to skip to the end, but that wasn’t working on this particular server. Gremlins…

PS C:\Shoreline Data\Logs> Get-Content .\ipds-190225.000000.Log | measure
Count : 393693
Average :
Sum :
Maximum :
Minimum :
Property :
PS C:\Shoreline Data\Logs> Get-Content .\ipds-190225.000000.Log -Wait | where -Property ReadCount -gt 393700
17:49:28.837 ( 3264: 3512) >SetUserCHM. User: 123. CHM: 2
17:49:28.888 ( 3264: 3512)
15:52:01.574 ( 7508: 5168) >CDBWriter::SetUserCHM::CDBUpdateTable::Update() failed. Error: 0xc1200db5.

SetUserCHM was me (unsuccessfully) changing from CHM 1 (Standard) to CHM 2 (In a Meeting) from communicator (testing from a phone will also log here but it’s noisier). That error sent me off looking for database issues, communications problems, etc. No dice. The evt log showed some interesting output though:

15:55:17.013 ( 4080: 4476) [evtl] (Error) CEventLibImpl::sendReceiveIPC failed - 0xC126100C
15:55:17.029 ( 7508: 4036) [evtl] (Error) CEventLibImpl::sendReceiveIPC failed - 0xC126100C
15:55:17.183 ( 4080: 4436) [evtl] (Error) CEventLibImpl::sendReceiveIPC failed - 0xC126100C
15:55:17.183 ( 2992: 6552) [evtl] (Error) CEventLibImpl::sendReceiveIPC failed - 0xC126100C
15:55:17.183 ( 1764: 1856) [evtl] (Error) CEventLibImpl::sendReceiveIPC failed - 0xC126100C
15:55:17.187 ( 4972: 5232) [evtl] (Error) CEventLibImpl::sendReceiveIPC failed - 0xC126100C

After digging around for named pipe issues and doing traces I tried the same on the voice switch and didn’t see any interesting errors. Theoretically the phone’s button and control traffic hits the voice switch and is making it to the director but I couldn’t verify that because I couldn’t get the switch to start a packet cap. Supposedly that’s because of a cipher mismatch: the director server tries to ssh into the voice switch to start the packet cap but it fails to login using it’s certificate.

Anyway I ran out of ideas and just waited until I could restart the switch and it worked. Everything was fine. Once again the SG90 blew up in my face was behaving unexpectedly and sent me one step closer to trying the vswitch.

Another one of those 1/1 google searches:

Console Access to Shoretel Switches and Phones

SG series switches, T series, and probably others:


  • Connect with a standard serial cable (dte to dce)
  • 19200 N,8,1
  • User: anonymous
  • Password: ShoreTel

Telnet: (Skip this and use SSH for a V switch)

  • Login to your Shoreware Director (it has to be the Shoreware Director, as of version 13.something you could only connect from the SWD. May have changed in 14 but I haven’t bothered to check)
  • command prompt at %PROGRAMFILES(x86)%\Shoreline Communications\ShoreWare Server\
  • ipbxctl.exe -pw ShoreTel [-telneton | -telnetoff] x.x.x.x
  • (Putty: go to the Terminal -> Keyboard settings and change the backspace key to “Control-?”)
  • User: anonymous
  • Password:ShoreTel

On switches with long uptimes (or if you left a debug flag on for a long time, shame!) sometimes this just plain won’t work. Only console will until you reboot.

You should see the console at the bottom.

Entering “gotoshell” will drop you to their VxWorks shell. From here you can set kernel flags. Do so with caution. The most useful one I’ve used is “sip_debug_level = 2”. There are other debug flags but at that point may god have mercy on your soul.

For the brave souls out there, once you realize that it’s just VxWorks that’s been… how do I put this… 𝕔𝕦𝕤𝕥𝕠𝕞𝕚𝕫𝕖𝕕… but in the same way that people 𝕔𝕦𝕤𝕥𝕠𝕞𝕚𝕫𝕖𝕕 MySpace pages (a little harsh maybe). After realizing that you might be tempted to see what commands Shoretel implemented or left on their image. This works on the phones too but others have explored that in much more detail and with more competence than I.

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.