cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
12530
Views
25
Helpful
14
Replies

Moving from PRI to SIP Trunk

ty.masse
Level 1
Level 1

We're looking at replace our PRI's and use SIP Trunks to get to PSTN.

Does a setup like that require Cisco Border Element?  or is there another way it can be done?

What's the confort level from replacing PRI with SIP trunks.  I know PRI's are rock solid and I've never had an issue with them.  How is it for SIP trunking?

thx.                  

2 Accepted Solutions

Accepted Solutions

There is  no difference in connect time between CUBE and PRI. If you experience delay then you need to investigate your call path and call routing. 3 to 4 secs is too long, thats indicative of a netwrok related issue.

Wenqianyu..You need to bear in m ind that there are implications to using a direct sip trunk to your provider.

1. There is no point of demarcation, hence your CUCM infractructure is not secured

2. When you run into interoperability issues with your ITSP, your only way to fix those problems will be using sip normalization rules. If you do not have the expertise, then this could pose a challenge as they are not as easy as sip profiles on a CUBE

3. If for any reason your ITSP is compromised, you are exposed too

4. If your ITSP does not support codecs like G711ulaw as mentioned earlier in the thread, you will need to provision a xcoder or MTP to convert between the codecs. Sicne you only have CUCM you cant do xcoding. If you have a large cluster, invkoking MTP on CUCM could have impacts

5. :Lastly troubleshooting is more difficult without a CUBE. Your only option to troubleshoot will be CUCM traces. Otherwise you will be at the  mercy of your ITSP..

So you need to know where you are before commiting to this solution. Having a CUBE is recommended and you can see the reasons why...

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Please rate all useful posts

View solution in original post

Hi Wengian,

Re. my delay comments above I have looked at some debug ccsip messages and noticed that the SIP invites from the CUBE to my two CUCM subscribers fail (dial peer preferences 1 and 2) and the call only connects when an invite goes to my Publisher (dial peer preference 3). If I change the Publisher dial peer preference to 0 then the call connects alot quicker. I am sure that I can get the Subscribers to respond to invites - probably something daft in my configs - apologies for worrying you with this!

One great resource that I have used when setting this up is the sample configs at the link below:

http://www.cisco.com/en/US/partner/solutions/ns340/ns414/ns728/networking_solutions_products_genericcontent0900aecd805bd13d.html

I have also used the Cisco Press SIP Trunking book which is really useful

http://www.ciscopress.com/store/sip-trunking-9781587059445

There are a couple of features that have been made available since the book was published (e.g. LTI transcoding) but it is a good reference.

When you speak to ITSPs ask them if they can provide a test service so that you can trial it over an extended period.

Also it might be worth reviewing the document below if you need stateful resilience for CUBE failure.

http://www.cisco.com/en/US/products/sw/voicesw/ps5640/products_configuration_example09186a0080b40d82.shtml

Cheers

James

View solution in original post

14 Replies 14

mmoulson1
Level 4
Level 4

You can SIP trunk directly to CUCM (depending on your version) but CUBE is certainly the recommended way to go.

As far as reliability goes. I guess it depends if your connecting via the internet or a dedicated circuit.

I've not setup a new PRI in over 2 years! For price and flexibility you can't beat SIP.

Good luck!

Matty

Sent from Cisco Technical Support Android App

Two quick questions:

How about voice quality with SIP Trunking are you using g711 or 729?

Is border element just a router that has voice IOS on it.  Or is it a special license I have to buy.  In order words, if I have a 2911 router that I use as h323 gateway, is that router already a border element?  The term CUBE confuses me a little.

So what you're saying, you can have a gateway in call manager pointing to the other side without any external router as a gateway device since the destination is just an IP Address?

In terms of licensing for CUBE, it is right to use (paper based), essentially using an inbound and outbound voip dial-peer for a single call classifies an ISR router as using the CUBE function. In terms of call quality, as long as you choose a reputable SIP trunk provider and have QOS configured properly, you shouldn't notice a difference between SIP trunks and a PRI (using g711).

HTH,

Chris

Sent from Cisco Technical Support iPad App

I agree with Chris, g711 quality is fine and 90% of providers will offer this as standard.

You are correct CUBE is just a voice IOS, so yes your 2911 would do the job. As Chris said the license is just a paper trust license. Sorry for the confusion ‘Cisco Unified Border Element’ (CUBE) :-)

Yes you can configure your CUCM to talk directly to the SIP provider but this is not recommended.

We are in similar position. We look at to replace existing PRI/BRI with SIP trunks directly to Service Provider from Voice GW. CUCM use MGCP to talk to Voice GWs at the moment. Do we need to change this part if we move to SIP?

Thanks,

Wenqian

Hi Wenqian,

Yes you need to configure a SIP trunk from your CUCM to your voice gateway.

Matty

James Hawkins
Level 8
Level 8

Hi,

I have just done this for a customer in the UK and there are a few of issues that may be of interest to you.

The codec used by the ITSP is G711alaw - this has caused an issue with UCCX which only seems to like G711ulaw. This should not be an issue for you if you are in North America but for Europe it is worth bearing in mind. I am currently trying to set up transcoding to resolve this issue.

I am not sure if it is just my deployment but inbound calls via CUBE seem to take 3 or 4 seconds more than calls via PRI to connect and hear ringback. Do other people find this? - if yes are there any timers that can be tweaked?

Firewalls - this is an important issue as you need to decide where the CUBE goes. You can just put it on the public Internet but most customers would wat it protected by a firewall. This firewall has to be able to cope with SIP and possibly NAT.

Thanks James. This is really useful.

We use G711ulaw as well as UCCX. I will test it in our test site. It would be unbearable if the CUBE takes  3 or 4 seconds more to connect. Would be interested to see how you get around.

Regards,

Wenqian

There is  no difference in connect time between CUBE and PRI. If you experience delay then you need to investigate your call path and call routing. 3 to 4 secs is too long, thats indicative of a netwrok related issue.

Wenqianyu..You need to bear in m ind that there are implications to using a direct sip trunk to your provider.

1. There is no point of demarcation, hence your CUCM infractructure is not secured

2. When you run into interoperability issues with your ITSP, your only way to fix those problems will be using sip normalization rules. If you do not have the expertise, then this could pose a challenge as they are not as easy as sip profiles on a CUBE

3. If for any reason your ITSP is compromised, you are exposed too

4. If your ITSP does not support codecs like G711ulaw as mentioned earlier in the thread, you will need to provision a xcoder or MTP to convert between the codecs. Sicne you only have CUCM you cant do xcoding. If you have a large cluster, invkoking MTP on CUCM could have impacts

5. :Lastly troubleshooting is more difficult without a CUBE. Your only option to troubleshoot will be CUCM traces. Otherwise you will be at the  mercy of your ITSP..

So you need to know where you are before commiting to this solution. Having a CUBE is recommended and you can see the reasons why...

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Please rate all useful posts

Hi aokanlawon,

My original expectation would be replacing existing PRI connections with SIP connections at Voice Gateways. CUCM would still use MGCP to control those gateways. CUCM does not talk to Service Provider directly. Gateways only pass calls to or from CUCM, and CUCM has all intelligences to make call routing decisions.

It seems it is a lot more complicated than I thought. I will do some readings about the possible changes.

Thanks a lot.

Wenqian

Hi Wengian,

Re. my delay comments above I have looked at some debug ccsip messages and noticed that the SIP invites from the CUBE to my two CUCM subscribers fail (dial peer preferences 1 and 2) and the call only connects when an invite goes to my Publisher (dial peer preference 3). If I change the Publisher dial peer preference to 0 then the call connects alot quicker. I am sure that I can get the Subscribers to respond to invites - probably something daft in my configs - apologies for worrying you with this!

One great resource that I have used when setting this up is the sample configs at the link below:

http://www.cisco.com/en/US/partner/solutions/ns340/ns414/ns728/networking_solutions_products_genericcontent0900aecd805bd13d.html

I have also used the Cisco Press SIP Trunking book which is really useful

http://www.ciscopress.com/store/sip-trunking-9781587059445

There are a couple of features that have been made available since the book was published (e.g. LTI transcoding) but it is a good reference.

When you speak to ITSPs ask them if they can provide a test service so that you can trial it over an extended period.

Also it might be worth reviewing the document below if you need stateful resilience for CUBE failure.

http://www.cisco.com/en/US/products/sw/voicesw/ps5640/products_configuration_example09186a0080b40d82.shtml

Cheers

James

You cannot use MGCP with sip trunks. Once you migrate from your PRI to SIP, your mgcp config will not be relevant to the sip gateway. What you can do is use the existing gateway as a CUBE and configure it for sip to sip connection.

You will set up a sip trunk from your cucm to the gateway and another sip trunk via dial-peers to your ITSP

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Please rate all useful posts

Hello VIP Mentor Ayodeji
I have the same scenario.. but then want to understand , what will happen to analog port.. which are connected to VG as MGCP port..
How fax will work there.. How Analog Phone will work there..
Seems everything will be SIP their now .

Kindly advise.

mattbrown
Level 1
Level 1

The strengths of PRI are uptime and call quality. If they are utilizing PRI, they must either make do with 2 fewer lines or deploy an extra PRI and have 21 superfluous lines. Because PRI is static, if any of its channels are not in use, they can’t be used in a different capacity, they just sit dormant.

SIP trunks aren’t as stable as PRI and call quality, even with Quality of Service, is slightly less than analog call quality. The big advantage SIP has over PRI is its flexibility and that it’s a dynamic service. It was noted by Eastern Management Group that in 2018, 70% of businesses had already converted from PRI to SIP.

 

To know the confort level from replacing PRI with SIP trunks you should know PRI to SIP at first.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: