Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Using '+' on IOS gateways?

I have been designing / deploying voice solutions for a long time and i have a simple question.  We are all pushing to full e164 numbers in dial plans on CUCM, etc to create a truly global dial plan. I use SIP trunks to gateways all the time and it supports the transport of the '+' whereas H323 does not.  Is there a way to match patterns based on the matching the + at the start of a string rather then matching ending strings, or ignoring the first character with translations rules/profiles?  Will this ever be in the road map on IOS gateways?           

3 REPLIES

Using '+' on IOS gateways?

Hi,

If you can please elaborate your exact requirement...

You don't want to send '+' from gateway through sip trunk to CUCM?

Regards, Nishant Savalia

Using '+' on IOS gateways?

You can use Called Party Transformation patterns to localize output to H.323 gateways - i.e. strip the +

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/9x/dialplan.html#wp1288534

Is this what you were looking for?

VIP Super Bronze

Re: Using '+' on IOS gateways?

Is there a way to match patterns based on the matching the + at the start of a string rather then matching ending strings, or ignoring the first character with translations rules/profiles?

The destination-pattern command does accept a plus character. IOS won't ignore part of a dial string; you would need to remove it on the dial-peer directly (e.g. forward digits) or through a voice translation-profile.

Generically speaking here is how I deal with +E.164 on PSTN/SRST gateways:

  • For incoming calls from the PSTN I use a translation-profile to add the plus on the incoming dial-peer. If you don't do it here and phones failover with SRST incoming calls won't work. Remember that the ephone-dns will be +E.164-formatted.
  • I put the CUCM-facing VoIP dial-peer at preference 1 to allow any registered ephone-dns to receive calls as long as they are registered, even if OPTIONS PING thinks CUCM is back.
  • For outgoing calls to the PSTN I typically localize on the CUCM SIP trunk because IOS has rule limits. In most NANP areas requiring seven-digit dialing there are too many rules for it to fit on IOS. In this direction the call arrives at the gateway prefixed with the offnet access code (e.g. 9) and the number exactly as the PSTN carrier expects it. This also ensures that your outgoing PSTN dial-peers are ready to go during SRST since you're passing the call to the router in the same format a user would dial.
  • I use a voice class sip-profiles to ensure that the Remote-Party-ID header stays in +E.164 format. IOS will attempt to update CUCM with the final localized format in the 183 Session Progress message. I want the phone display to stay globalized so a little regex magic gets the job done here.
  • If you're not careful you can create call loop scenarios with +E.164 dial-peers on a gateway. I have started using CoR as a defacto-ACL on every router as a safeguard.
  • I use the amazing voice class uri feature to match incoming VoIP dial-peers by the Via header instead of the overly generic incoming called-number . So much more precise.

Please remember to rate helpful responses and identify helpful or correct answers.

209
Views
5
Helpful
3
Replies
CreatePlease login to create content