Anyone using native SIP?

[ShoreBreak]

Hi All,

Got a client who is gung-ho on getting a ST system (yay). Unfortunately he's also gung-ho on going 100% SIP trunks, with maybe a few BRI's as fallbacks.

I don't want to use the SIPerator for several reasons, including the fact that it sounds like a cross between a kitchen appliance and a sex toy; it's very expensive for what we need it to do; and I think that it's really crap for a platform that touts itself as "Pure IP" to need a 3rd party add-on to perform a major component of IP telephony.

Dismounts from Soapbox :_tt2:

We've done many SIP trunk installations using other platforms, and while I'd much prefer to connect a bulletproof PRI and ride off into the sunset, I realise that SIP trunking is only going to increase.

From what I've read, I've yet to see any need for a 3rd party box. As long as we're happy mucking around with the firewall and doing some stuff like port forwarding etc (which we've had to do with pretty much every other SIP trunk install), then I can't see any insurmountable issues.

Unbridled confidence in oneself, I've learned over the years, is both a blessing and a curse. If anyone could enlighten me as to the bits that I've missed, I will be eternally grateful.

[jasonepowell]

You need the Siperator to allow transfers and conference calls.

Say you have a phone with an IP of 10.10.10.145 and another phone with 10.10.10.150. The shoretel switch is 10.10.10.11.

.145 calls 555-5555. A SIP invite is sent and the outbound call works through your SIP ITSP. Now say .145 wants to transfer the call to .150. The switch is going to send a REFER or another INVITE (I can't remember which) to the ITSP which says, essentially, "Transfer this call to 10.10.10.150". The ITSP doesn't know about 10.10.10.150, so the transfer fails.

The Siperator sits between the Shoretel and the ITSP and basically just replaces the private IP with a public IP so that the ITSP knows where to send traffic.

You can get around this by creating a VPN from your site to your ITSP, so that the ITSP actually DOES know about your private IP addresses. This is essentially Etherspeak's SureTrunk solution in a nutshell.

[ShoreBreak]

Thanks Jason - that makes it clearer.

So without the SIPerator, the initial call would be set up between the Handset and the ITSP with NAT handling the translation of private to public etc, however when the transfer/conference occurs, things go pear-shaped... Correct?

Is this an architectural issue with the ShoreTel? I think that the ShoreGear switch should handle the trunking component, and provide transparency for the endpoints so it's immaterial whether they're using PSTN/BRI/PRI/SIP as their trunk.

Any clarification provided will be greatly appreciated.

[jasonepowell]

Yes, that's correct.

I do think it's an architectural problem right now. Shoretel hasn't really invested in SIP very much and their focus seems to be on making SIP endpoints compatible with their system as opposed to making a out of the box SIP trunking solution.

In our experience, the Siperator works great (although we did need a software patch to work with our particular ITSP) once it's set up, though.

[cburgy]

Etherspeak's SIP Trunking solution works directly with Shoretel (you need version 8.1) without a SIParator.

We've done implementations with them for customers (as secondary paths for dial tone) and it works pretty well.

SureTrunk by EtherSpeak

Neil Darling hangs around the message board and you can find other posts on the topic.

[VJ]

We are using SureTrunk and fighting a losing battle. Jason (above) is correct that ST has invested little in SIP. Every fix suggested is two more things gone wrong. Information in the Knowledge base is incorrect according to Escalation TAC. I personally wish I had never seen SIP trunking.
Funny that when I went to I&M the instructor hinted that SIP was it! The end all to end all! Now 3 TAC calls and 5 answers, non helpful.
I am offering to eat a T-1 switch if the customer will let me put them backon a PRI. His agents are refusing to answer calls because of the poor voice quality.

[Palitto Consulting]

VJ, have you tried talking to SureTrunk's support or only with Shoretel? SureTrunk's support is very helpful and knowledgeable from my experience.

[nddarling01]

SureTrunk and Native SIP

I saw Vance's post and am very familiar with the client he is referring.

Without going into detail - the client had some major pre-existing security issues that weren't addressed until after the install was completed. For one, they had an email server that was infected, hijacked and was doing it's fair share as a SMTP relay, slamming the default gateway with traffic - to fill our inboxes with unwanted spam. I don't think the initial post was a fair representation of this particular IT situation - or SureTrunk's failure - but I will leave it to Vance to fill in some of the blanks if he so chooses to do so.

When the dust settles - I think Vance will be able to report back to the list on how this client is doing with SureTrunks.

In the mean time - we have recently published some case studies that provide a good overview of the value SureTrunks bring - particularly in a tight economy. If you have interest, click through to SureTrunk by EtherSpeak

I will also be representing EtherSpeak at the ShoreTel booth at VoiceCon (we are right next to the Ingate display) in Orlando - if any of you are there, please stop by and say hi.

Respectfully,

Neil D
EtherSpeak
703-221-9999

[flyingdutchmanVa]

We are testing with a local carrier right now. I hope when I get the switch upgraded to 8.1 this week we can test without the Ingate. Carrier seems to think they can do it without. I noticed that SIP trunks don't like being answered by Hunt groups. It seems to lose speech path occasionally. If you point it to an extension alls well. Hello,Vance.

[Mark Dutton]

I can attest that that SIP trunking is not an issue per se. SIP trunks are here to stay and Shoretel needs to get on board. I am surprised that the SIP stack is so limited as a pure IP needs to integrate externall via IP and SIP is the standard for this, like it or not.

Aside from using ITSPs. SIP trunking is necessary to hook into a myriad of third party products, like the 2n SIP mobile gateway, etc.

Other products do SIP trunking exceptionally well. It is simply a matter of refining the SIP stack, putting in more parameters to deal with the various vagueries that causes different vendors to do SIP slightly differently and to hide internal SIP transfers from the ITSP.

I am sure Neil D. will back me up on this.

Regards

Mark Dutton
Datamerge