Search this Blog

Wednesday, July 28, 2010

SIP Trunk (XO Communications) on CME 7.x

We have an existing 2921 CME/CUE version 7.x which currently has a PRI to the PSTN. We are trying to switch over to a SIP trunk provided by XO Communications. Right now our DID numbers only match the last two digits of my ephone-dn number. For example my DID would be something like this 330-555-8510 and my ephone-dn would be 1210 we am using a num-exp for each DID number as a translation. So for the example we have the following: num-exp 3305558510 1210. Our CME router is not the main data router for the site's data network, but it is the default gateway for the phones. I have about 30 SCCP phones, and we have a few analog stations that I'm connecting to via pots dial-peers. Our plan is to plug the sip trunk, which is being delivered on a seperate /30 WAN segment by the carrier, into one of the unused ethernet ports on the CME and setting a route to the carrier's SIP network which will use that interface. For example, we have a default route pointing to the site's main gateway, and we have a more specific route for the carrier's SIP network pointing to the interface where our SIP trunk terminates.

We have added all of my VOIP Dial-peers and shutdown my pots dial-peers that were pointing to the PRI. When we do this and try to make a test call from one of my SCCP phones we get an intercept message from the carrier stating that the device we am using is not registered. If we add a secondary number to the ephone-dn as the full e.164 is our number we can make a call out, and we can make a call back in (on my test number). However when we make a call out, the caller ID shows up as unknown (this may be just because there is no association in the carrier's database with my test number...we have not ported my existing numbers over yet).

We would like to know what we need to do so that we't have to put a secondary dn on all of my ephone-dn's, is there any sort of translation (say, with a sip-profile maybe) that we can do so that when my endpoints attempt to register, the SIP header gets re-written from 1210@ to 3305558510@ going out, and gets inversely translated coming back in? If we do this with a sip-profile, can somebody share with me an example of how this is configred? There seems to be LOTS of SIP headers that can be re-written with a sip-profile and I need some advice on what to do.

Also, is there anything additional we need to do for my analog station devices? Currently We just have a station-id configured on the port, and a pots dial-peer sending the destination pattern to the port the fax machine is plugged into.


You might try translation-profiles. It works for PSTN / H.323 voip calls and it should work for SIP calls too. Here's an example of how you might set it up:

voice translation-rule 1

rule 1 /^33055585\(..\)/ /12\1/

voice translation-rule 2

rule 1 /^12\(..\)/ /33055585\1/

voice transation-profile SIP_Inbound

translate called 1

voice translation-profile SIP_Outbound

translate calling 2

dial-peer voice 1000 voip

translation-profile incoming SIP_Inbound

translation-profile outgoing SIP_Outbound

Updated a typo on the first translation-rule.

The translation-profiles do not modify the SIP headers directly, but they do modify the call information within CME which will affect how CME processes the call. When you apply a translation-profile to a dial-peer, that translation affects the information processed by the dial-peer. I believe the reason you are getting the unregistered error is your SIP provider won't let you place calls unless the calling number is a number that they have configured to your SIP trunk.

Your devices are registering with CME, not your service provider. Translations can sometimes be a little intimidating, but they are worth the effort and leave your solution much more scalable. The major distinction is that everything on the SIP trunk is done on a call-by-call basis, and your provider doesn't know anything about the state of the devices registered to CME.

We did find a good example on CCO, you might want to review this document

In this example they are using the dialplan-pattern command under the telephony-service configuration which automatically creates the expanded dial peers for each of the ephone-dn's. That just leaves your non-DID extensions and dial-peers that you have to build translations for.

Citation - This blog post does not reflect original content from the author. Rather it summarizes content that are relevant to the topic from different sources in the web. The sources might include any online discussion boards, forums, websites and others.

No comments :

Post a Comment

/* Google Analytics begin ----------------------------------------------- */ /* Google Analytics end ----------------------------------------------- */