SIP Trunk (XO Communications) on CME 7.x - Need help

Unanswered Question
Jul 26th, 2010

I have an existing 2921 CME/CUE version 7.x which currently has a PRI to the PSTN.  I am trying to switch over to a SIP trunk provided by XO Communications.  Right now my 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 I am using a num-exp for each DID number as a translation.  So for the example I just gave I have the following:  num-exp 3305558510 1210.  My 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 I have a few analog stations that I'm connecting to via pots dial-peers.  My 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, I have a default route pointing to the site's main gateway, and I have a more specific route for the carrier's SIP network pointing to the interface whiere my SIP trunk terminates.

I have added all of my VOIP Dial-peers and shutdown my pots dial-peers that were pointing to the PRI.  When I do this and try to make a test call from one of my SCCP phones I get an intercept message from the carrier stating that the device I am using is not registered.  If I add a secondary number to the ephone-dn as the full e.164 number of my test number I can make a call out, and I can make a call back in (on my test number).  However when I 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...I have not ported my existing numbers over yet).

I would like to know what I need to do so that I don'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 I can do so that when my endpoints attempt to register, the SIP header gets re-written from [email protected] to [email protected] going out, and gets inversely translated coming back in?  If I 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 I would need to do for my analog station devices?  Currently I just have a station-id configured on the port, and a pots dial-peer sending the destinantion pattern to the port the fax machine is plugged into.

Any thing you can share that would point me in the right direction would be appreciated!!

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Michael Odom Mon, 07/26/2010 - 10:04

You might try translation-profiles.  I've only used them for PSTN and H.323 voip calls, and I'm pretty sure 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

### I updated a typo on the first translation-rule

Chris Schuerger Wed, 07/28/2010 - 05:48

Yes, but I don't think voice translation-profiles will re-write the SIP headers will they?  In order for me to place a call over the SIP trunk my devices need to register with their full e.164 number, which I think they do by sending a SIP message to the SIP server.  When I do a debug ccsip I see lots of messages with [email protected] and I think I need to somehow re-write those as [email protected]

Maybe there's an easier way to do this, but none of the SIP information I've found tells me how to do this.

Michael Odom Wed, 07/28/2010 - 08:14

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.

Chris Schuerger Wed, 07/28/2010 - 08:31

I get that part, and I appreciate your information thus far, but what I'm looking for is a way to modify my ephone-dn's so that when ext 1110 tries to send

a registation request, or an invite, or whatever, the system modifies [email protected] to [email protected] Is this possible, or is it that the only way to do this is setup my ephone dns like this:

ephone-dn 1

number 1110 secondary 3305558510 no-reg primary

..

I know that way will work, but it is far from elegant.

Also, would I then have to do something similar for my voicemail automated attendants?  Change the trigger to a full e.164 number and change the associated dial-peer's destination pattern from 8000 (in my case) to a full e.164 number?

Same for my analog stations - Rewrite the destination pattern of the pots dial-peer that points to them with a full e.164 number?

What about internal phones that don't have a full e.164 number?  How would they register?

There's got to be a better way.

Michael Odom Wed, 07/28/2010 - 08:54

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.

I did find a good example on CCO, you might want to review http://www.cisco.com/en/US/customer/products/sw/voicesw/ps4625/products_configuration_example09186a00808f9666.shtml

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.

Chris Schuerger Wed, 07/28/2010 - 10:42

Mike,

I think you are correct about the dial-plan pattern.  I ran across that as well.  I think that's the direction I'm going to go.  Thanks much!!

Steven Holl Wed, 07/28/2010 - 08:44

Chris,

Are you sure that your SIP trunk requires registration for all of the DID numbers?  A lot of them will route all DIDs to you if you just register the main number.

Assuming you do need unique DID registrations to the ITSP, SIP normalization is your only way to go other than having secondary numbers configured under the DN.

Take a look at this link:

http://www.cisco.com/en/US/products/sw/voicesw/ps5640/products_configuration_example09186a0080982499.shtml#modify

You will want to be comfortable with regular expressions.  Essentially, you will need to create regular expressions to manipulate the to: and from: headers.

Personally, I think it's a pretty dirty solution, and secondary number configuration is the good way to do things.  If you have outbound CLID concerns with this method, that can be address with an outbound translation rule on the SIP trunk peer.

-Steve

Chris Schuerger Wed, 07/28/2010 - 08:52

I can't seem to call in or out unless I put a secondary dn on my ephones, so I'm not sure that it is a simple matter of just registering the main number...however I did come across this:

In the telephony service configuration,  dialplan-pattern 1 33055585.. extension-length 4 extension-pattern 11..

Prior to putting that command in I get this:

CMECLE-01#sh sip register status
Line          peer           expires(sec)  registered   P-Associated-URI
============  =============  ============  ===========  ================
1121          20002            19            no         
7400          20003            21            no         
7500          20004            40            no         
7501          20005            41            no         
7502          20006            41            no         
7996          20007            41            no         
7997          20008            41            no         
7998....      20009            42            no         
7999....      20010            42            no

AFTER putting that command in I get this:

CMECLE-01#sh sip register status
Jul 28 15:54:59.835: %SYS-5-CONFIG_I: Configured from console by admin on console
Line          peer           expires(sec)  registered   P-Associated-URI
============  =============  ============  ===========  ================
1121          20002            0             no         
3305558520    20015            0             no         
3305558521    20016            0             no         
3305558555    20017            0             no         
7400          20003            0             no         
7500          20004            0             no         
7501          20005            0             no         
7502          20006            0             no         
7996          20007            0             no         
7997          20008            0             no         
7998....      20009            0             no         
7999....      20010            0             no         
CMECLE-01#

You will notice that I now have the full e.164 numbers trying to register.  I think I just need to use this command and set all of my ephone-dn's to no-reg primary

Actions

This Discussion