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

[STEVEN CASPER]

 From the customer side faxing has definitely been a challenge. Also how about security concerns as a potential pain point. We are fighting a perception that SIP trunking is much more vulnerable to fraud and hacking as opposed to traditional PSTN. We are trialing a service using our private IP network from the same carrier that provides us with our MPLS network and using a CUBE but may still end up having to add a firewall to the design due to Info Sec concerns.
 
Steve
 
Please consider the impact on our environment before printing this e-mail. 


>>> Nick Matthews <matthnick at gmail.com> 5/12/2009 7:23 PM >>>
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 

************************************
This email may contain privileged and/or confidential information that is intended solely for the use of the addressee.  If you are not the intended recipient or entity, you are strictly prohibited from disclosing, copying, distributing or using any of the information contained in the transmission.  If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy.  This communication may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act and the Sarbanes-Oxley Act.  You may not directly or indirectly reuse or disclose such information for any purpose other than to provide the services for which you are receiving the information.
There are risks associated with the use of electronic transmission.  The sender of this information does not control the method of transmittal or service providers and assumes no duty or obligation for the security, receipt, or third party interception of this transmission.
************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20090514/24aa26aa/attachment.html>