[cisco-voip] SP VoIP edge options: SIP trunks vs PRIs

Tue May 12 19:36:22 EDT 2009

SIP trunks are only "cheaper" if you are also using the SIP provider as your Internet provider. In our case, we get our internet through a conglomerate (your day is not complete until you use conglomerate in a sentence) of providers and through a remote site via a regional network. It's fast and cheap this way. Those providers don't offer SIP trunks, so we have to go with other providers. They've told us outright, "Forget it. It's not worth it until you buy Internet from us." 

Anyways, just a thought. 

--- 
Lelio Fulgenzi, B.A. 
Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1 
(519) 824-4120 x56354 (519) 767-1060 FAX (JNHN) 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
"Bad grammar makes me [sic]" - Tshirt 

----- Original Message ----- 
From: "Nick Matthews" <matthnick at gmail.com> 
To: "Justin Shore" <justin at justinshore.com> 
Cc: "VoIP" <cisco-voip at puck.nether.net> 
Sent: Tuesday, May 12, 2009 7:23:51 PM GMT -05:00 US/Canada Eastern 
Subject: Re: [cisco-voip] SP VoIP edge options: SIP trunks vs PRIs 

Major pain points for SIP trunks: 
-Faxing. VoIP is complicated enough, and then running another set of 
protocols on top of this just gets hairier. Are you going to support 
T38, G711, both, etc. 
-Voice quality troubleshooting. For a lot of the reasons you've 
listed, trying to troubleshoot this is more difficult with the blame 
game shifting between the customer's equipment, the internet provider 
(and all of it's contracted links), as well as the SIP trunk. A lot 
of packet capture analysis here instead of butt sets, and then 
recreating the voice stream to determine if there is quality problems 
in the call. 
-Interop. Every device and SIP gateway does something different, and 
you'll spend a lot of time over SHOULDs and MAYs and MUSTs in the 15 
different SIP RFCs. Payload types, codecs, header fields, formatting, 
PRACKs and 18x, session refreshes, privacy, all are common problems. 

Benefits: 
-Cheaper. 
-More flexible 
-More features 
-A good portion of problems aren't as prevalent like echo and static 
-Some of the troubleshooting is more 'determinable'. Instead of 
measuring signal levels at the T1 and troubleshooting voltage, you're 
looking at SIP packets and the RFCs. 
-Seemingly inevitable 

Just a few thoughts from someone who troubleshoots with SIP providers 
all day long.. 

-nick 

On Tue, May 12, 2009 at 6:55 PM, Justin Shore <justin at justinshore.com> wrote: 
> I'd like to get everyone's thoughts on whether to hand voice customers SIP 
> trunks or PRIs. We're beginning to offer voice service in a new area that's 
> heavily populated with businesses. Besides selling Internet and ELAN-type 
> services, we're also going to be selling a new voice service. We're selling 
> a basic turnkey VoIP system to the smaller shops that registers back to our 
> MetaSwitches. Our initial plan for bigger customers or those with existing 
> PBXs or key systems was to use IADs to hand off either FXS lines or PRIs as 
> needed. Now the question has been raised as to why we're not handing off 
> SIP trunks directly to the customers. Below is my reasoning for not wanting 
> to do SIP trunks, right or wrong. I'm open to ideas though; I can certainly 
> be looking at this from the wrong viewpoint. 
> 
> While I know the industry is moving towards SIP trunks to the CE, I don't 
> think it's really ready for the prime-time at this point. Every vendor has 
> interpreted the assortment of SIP standards differently (and some not at 
> all), requiring major interop testing before reliable solutions can be 
> signed off on. Interop testing between CCM and MetaSwitch is several 
> revisions behind and the minor revs (with all the bug fixes) seldom if ever 
> get tested. We aren't going to perform a MetaSwitch upgrade just because a 
> user upgraded their CCM to an untested rev to fix an unrelated issue. 
> 
> Providing SIP trunks also creates the opportunity for a finger pointing game 
> between the customer's network admins and us. Without a window into their 
> network they're on their own for QoS and capacity planning. We'll take the 
> blame though if they don't do something right or have something broken in 
> their network (core network hub, anyone?). This is a major concern for me. 
> We manage the small customer's networks in our other deployment scenario 
> which lets us ensure proper QoS settings and capacity planning just like we 
> do for the SP backbone. We're at the customer's mercy if we entrust them to 
> do it. 
> 
> And if/when we do run into problems there aren't exactly a lot of options 
> for testing a SIP trunk on the customer's side to prove that we're not the 
> problem. We could assume the IP of their gateway with some sort of test 
> gateway of our own but that completely takes down their phone system. 
> Whereas with PRIs or FXS lines I can hook up a test set and definitively 
> prove line quality right then and there, thus ending the blame game. FXS 
> lines and PRIs bring far fewer interop issues to the table as well. While 
> getting a SIP trunk to work on Vendor X's gateway may prove entertaining, 
> getting a FXS line or PRI to work usually goes off without a hitch. 
> 
> 
> Overall FXS lines and PRIs seem to be far superior in terms of ongoing 
> support, interoping with other vendors, and minimizing the blame game and 
> finger pointing. The down side is that it adds cost both for us and the 
> customer. So should we be planning on doing SIP trunks to customers today? 
> How would you as a service provider provide voice at the edge if you had 
> your choice? What would you as a customer want the provider to do? 
> 
> Thanks for your insight 
> Justin 
> 
> 
> _______________________________________________ 
> cisco-voip mailing list 
> cisco-voip at puck.nether.net 
> https://puck.nether.net/mailman/listinfo/cisco-voip 
> 
_______________________________________________ 
cisco-voip mailing list 
cisco-voip at puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-voip 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20090512/e15efcff/attachment.html>