[cisco-voip] Verizon SIP vs. PRI?

Tue Feb 8 21:08:01 EST 2011

Nice write up Nick. If you can standardize on a few carriers it is best. It is nice when they follow the standards well enough that you do not need to implement MTP's.

Dennis Heim
Network Voice Engineer
CDW  Advanced Technology Services
11711 N. Meridian Street, Suite 225
Carmel, IN  46032

317.569.4255 Single Number Reach
317.569.4201 Fax
dennis.heim at cdw.com<mailto:dennis.heim at cdw.com>
cdw.com/content/solutions/unified-communications/<http://www.cdw.com/content/solutions/unified-communications/>

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Nick Matthews
Sent: Tuesday, February 08, 2011 8:16 PM
To: Paul
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] Verizon SIP vs. PRI?

SIP trunks can be a blessing or a burden.  Things that become important with SIP trunking:

-All of your versions and VOIP applications become points of interoperability.  With PRI's, your interop stopped at the PRI.  This means contact center applications, voicemail, call control, etc.  This even extends out into the provider cloud - sometimes you'll have interop issues with only certain DIDs or companies on the other side of their network.  SIP is open and flexible, which is good and bad.  Sometimes the fixes to these problems are complex and require for people like the SIP provider to take action, which you can't control.  You may find your contact center software, call control software, border element software, and provider have differing levels of interoperability flexibility.

-Sometimes it is a wash.  If you're worried about survivability at the branch, you can take the money you may save by centralizing the PRIs and use it to get another circuit and router at the site.  Now you've got higher branch survivability and more bandwidth as well.  And if you lose two routers and/or two circuits at the site - you've probably got bigger problems.  The easy generalization is that you inherit the flexibility of IP networks and get to work with the equipment you've invested into the network rather than 20+ year old telephony technology.  Since you've got increased flexibility, it may be worth it to just flip the calls from the failed site somewhere else until they've recovered.

-Faxing/911/Modems.  Now that your VOIP domain is extended to the SIP cloud, you have to take care to make sure you're standards based and compliant with the provider.  It's common for people to leave a small percentage of TDM at the branch sites for 911, faxing, and survivability.  Expect trouble here.

-Many choose to co-reside their SIP provider with their MPLS provider.  This prevents having a 'dumb pipe' for your SIP traffic with the capability to distort the traffic without a disincentive.  Imagine calling your cable modem provider at home and telling them "you're causing 20% jitter and a 1% loss on my high priority EF traffic".   That being said - the internet is quite significantly more reliable than many expect for carrying SIP traffic.  Skype, google voice, and a number of others are prime examples.

That being said - it's really cool.  There are a couple places where it's just awesome.  If you've got a remote branch and the only voice offering is a dusty T1 CAS circuit? Forget about that.  If you have highly seasonal or even unpredictably bursty traffic, it can be great.  If you have a lot of offices where you've overprovisioned the phone lines, SIP is a big cost saver.  It's portable, and you are no longer tied down to a single smart jack where your T1 comes in on.  When I travel, I register a SIP agent on my cell phone to a HTTP PBX, which registers to a SIP trunk.  It's the exact same concept and architecture that SIP trunking for enterprises build on, but cool-ified.

If SIP is confusing, just think about how an H.323 gateway works.  Your CUCM points to an IP address in your network.  Now move your gateway out onto the internet.  H.323 and SIP are incredibly similar, so just switch the protocol from H.323 to SIP.  The last step is to place a Session Border Controller (SBC) or in Cisco's terms a Cisco Unified Border Element (CUBE).  This is basically a voice firewall, and makes sure your signaling and voice stays secure and is manageable.  What really happens is that is takes the call, terminates it, and then re-originiates it going outbound.  From your CUCM's perspective - it wouldn't know whether a PRI or another SIP leg was on the other side.

In my opinion, once you get the hang of how SIP works, the troubleshooting can be simpler too.  Call quality problems and resolution can be a pain on TDM circuits - who is to say where the distortion is coming from.   With IP, you can easily prove where the distortion is coming from with a sniffer.  Ever have to troubleshoot ISDN Q.921 messages?  No thank you.  It's a stronger protocol than H.323 - the odd TCP handshake isn't a problem, it isn't inhibited by a large specification, and it's a whole ton easier to read and troubleshoot.

Signaling interoperability problems can be solved by going through the RFCs, which can be muddy and fruitless - Vendor A allows only strictly formed messages and Vendor B refuses to implement such details.  Vendor A knowingly doesn't follow SIP RFC #17, while Vendor B expects compliance.  Vendor A is written by a guy in Russia who quit 3 months ago, and Vendor B doesn't like the way it was written, but Vendor B thinks it's correct.  This was all solved by TDM PRI's which are essentially the lowest common denominator of voice termination.

Hopefully this gives you an idea.  I suppose I'm just full of opinion on this one.

-nick

On Tue, Feb 8, 2011 at 7:08 PM, Paul <asobihoudai at yahoo.com<mailto:asobihoudai at yahoo.com>> wrote:
Are you using CCM session management edition for that customer or is it just one cluster with a lot of centralized SIP trunks? I'm just asking out of curiosity since I've never heard of anyone using session management edition....yet.

________________________________
From: Bob Zanett (US) <bob.zanett at us.didata.com<mailto:bob.zanett at us.didata.com>>
To: Matthew Loraditch <MLoraditch at heliontechnologies.com<mailto:MLoraditch at heliontechnologies.com>>; David Eco <david.eco at msn.com<mailto:david.eco at msn.com>>; "matthew at ciscovoiceguru.com<mailto:matthew at ciscovoiceguru.com>" <matthew at ciscovoiceguru.com<mailto:matthew at ciscovoiceguru.com>>; "notariannil1 at scranton.edu<mailto:notariannil1 at scranton.edu>" <notariannil1 at scranton.edu<mailto:notariannil1 at scranton.edu>>
Cc: "cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>" <cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>>
Sent: Tue, February 8, 2011 1:08:13 PM

Subject: Re: [cisco-voip] Verizon SIP vs. PRI?

I have helped to design, architect and deploy multiple customers with SIP, including SIP trunks carrying contact center calls and also business user calls.  I helped to build out the initial infrastructure of a global medical device firm that almost has all of their US remote offices - literally 100s - migrated onto their centralized SIP trunks.

Are there interoperability issues?  Yes, as each vendor can speak a slightly different dialect.  However, with the onset of some very nice Border Gateways - it is making this a non-issue.  However, as Matthew states below - you need to work with someone who knows what they are doing.

For instance, ROI can be a grey area.  Many times, it is simply a wash and at other times can save a tremendous amount.  Like the example above, each of the remote sites had a least a PRI.  However, many of the offices hardly used 12 b-channels.   By centralizing, they are seeing a very nice savings and they get:

*         Centralized dial plan management

*         Centralized DID control and management

*         On-the-fly call volume adjustment - it is now bandwidth not copper in the ground

*         Economy of scale

http://www.callcentertimes.com/LatestNews/tabid/59/ctl/NewsArticle/mid/407/CategoryID/1/NewsID/173/Default.aspx

Cheers,

Bob

Solutions Architect
Customer Interactive Solutions
Dimension Data

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net]<mailto:mailto:cisco-voip-bounces at puck.nether.net]> On Behalf Of Matthew Loraditch
Sent: Tuesday, February 08, 2011 2:29 PM
To: David Eco; matthew at ciscovoiceguru.com;<mailto:matthew at ciscovoiceguru.com;> notariannil1 at scranton.edu<mailto:notariannil1 at scranton.edu>
Cc: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] Verizon SIP vs. PRI?

The thing I would say is it all depends on your level of comfort with the Carrier and with SIP. I generally don't have a problem with the quality of the service when it works, the problem has been troubleshooting and making it work in the first place. I understand how to debug and troubleshoot a T-1 or PRI and can set one up H.323 or MGCP no problem. SIP just doesn't process for me, Everybody says it's simple, plain text and all that but I don't get it.

My point, If you are going with it make sure you or someone you have understands it.

If you have a smaller install one thing you can do is have the provider put in an IAD and hand off as PRI. Make them responsible and make your side something you understand. Obviously in a large campus environment that may not be feasible and defeats some of the consolidation benefits but in a smaller setup it can make life much easier.

Matthew Loraditch, CCVP, CCNA, CCDA
1965 Greenspring Drive
Timonium, MD 21093
support at heliontechnologies.com<mailto:support at heliontechnologies.com>
(p) (410) 252-8830
(F) (443) 541-1593

Visit us at www.heliontechnologies.com<http://www.heliontechnologies.com/>
Support Issue? Email support at heliontechnologies.com<mailto:support at heliontechnologies.com> for fast assistance!

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net]<mailto:mailto:cisco-voip-bounces at puck.nether.net]> On Behalf Of David Eco
Sent: Tuesday, February 08, 2011 2:47 PM
To: matthew at ciscovoiceguru.com;<mailto:matthew at ciscovoiceguru.com;> notariannil1 at scranton.edu<mailto:notariannil1 at scranton.edu>
Cc: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] Verizon SIP vs. PRI?

with SIP, you may get more capacity of the channel. But in our case, we have to setup IPSEC VPN with Verizon to utilize their SIP Trunk. Network has to be reliable.

David

> From: matthew at ciscovoiceguru.com<mailto:matthew at ciscovoiceguru.com>
> Date: Tue, 8 Feb 2011 13:43:34 -0600
> To: notariannil1 at scranton.edu<mailto:notariannil1 at scranton.edu>
> CC: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
> Subject: Re: [cisco-voip] Verizon SIP vs. PRI?
>
> One of my biggest questions right now regarding SIP trunks has been data circuit issues and usability in SRST mode. If your branch office loses it's network connection, will your SIP trunk go down too? If so, then you're up the creek without a paddle.
>
> Sent from my iPhone
>
> On Feb 8, 2011, at 1:13 PM, Lisa Notarianni <notariannil1 at scranton.edu<mailto:notariannil1 at scranton.edu>> wrote:
>
> > We currently utilize PRI trunks as fail over and backup. They connect to our 6509's.
> >
> > Can anyone share their thoughts on SIP vs. PRI services.
> >
> > Thanks,
> >
> > Lisa
> > --
> > <LNsignature.jpg>
> > _______________________________________________
> > cisco-voip mailing list
> > cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
> > https://puck.nether.net/mailman/listinfo/cisco-voip
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
> https://puck.nether.net/mailman/listinfo/cisco-voip
________________________________
<http://dimensiondata.stream57.com/04141pm/>

Disclaimer: This e-mail communication and any attachments may contain confidential and privileged information and is for use by the designated addressee(s) named above only. If you are not the intended addressee, you are hereby notified that you have received this communication in error and that any use or reproduction of this email or its contents is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. <http://dimensiondata.stream57.com/04141pm/>
 <http://dimensiondata.stream57.com/04141pm/>
<http://dimensiondata.stream57.com/04141pm/>
________________________________
Don't get soaked. Take a quick peak at the forecast
with theYahoo! Search weather shortcut.<http://dimensiondata.stream57.com/04141pm/>

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip<http://dimensiondata.stream57.com/04141pm/>
 <http://dimensiondata.stream57.com/04141pm/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20110208/a79d586b/attachment.html>