What is becoming a standard, especially among global companies with cross cluster communication, is Directory Numbers being configured as full +E.164 digits. For some time this has been E.164 (without the leading + due to lack of support with some applications), but finally the 3rd party apps are catching up and supporting the use of the + character.
On a recent project, I was completing a site integration with a Gateway using SIP integration and still thinking in the old way of using Calling and Called Party Transformation Patterns / CSSs for inbound and outbound calls to a Gateway, when it occurred to me – why use them at all?
Cisco IOS SIP Gateways support the + character. Why go to the trouble of globalising all dialled numbers to +E.164 format, and then sending them to the SIP Gateway in a localised format? What about when the phones are registered via SRST and want to dial in +E.164 format and receive calls? That would then require another set of transformations on the Gateway, and if you’re doing that already why not do ALL of the transformations on the Gateway?
I then decided to do completely away with all Calling and Called Transformation Patterns. Yes, I know some customers may like seeing the presented number on their telephones in a regional format – however I tend to steer my clients towards presenting +E.164 numbers directly to the phones. People should be used to this anyway with so many mobile carriers presenting incoming numbers in +E.164. Since making this design move, I’m yet to think of any down-side, and thus wanted to share and see if anyone in the community could foresee any problems.
Scenario 1: Regular Operation
Scenario 2: SRST Operation
In the simplest case, you would need the following outbound dial-peers:
- +T – for all +E.164 dialled patterns (towards PSTN)
- 0T – for all non +E.164 patterns, such as non-geographic service numbers, or in SRST mode all numbers dialled using the regional dialling habits. (towards PSTN)
- +61XXXXXYYYY – Local cluster patterns in +E.164 format (towards CUCM)
If anyone has any glaring issues that I may have missed, please feel free to share 🙂
Hey Mate it's a great point, why would you want to use calling pattern transformations which have a confusing order-of-execution, this makes it easier for sure.
I have thought backwards and forwards about: Is there any patterns that a calling transformation pattern can apply that I can't, and I can't think of any.
The one and only one I can think of is Localized inbound calls
It has one great advantage too, no need to reset sip trunk
Exactly, it would just be a calling party transformation that you wanted to apply directly on a phone, to have the number presented to the user in the way they are accustomed to.
This design idea doesn't preclude that though. You could still create those transformation patterns and apply to a Device Pool (as long as you remember to make sure the SIP Trunk doesn't use the Device Pool Transformation CSSs… which is the default). I personally leave them out and make my customers get used to +E.164. Is a cleaner config and one less thing to troubleshoot!
Good point. You can modify the existing translation rules, or change out entire translation profiles without having to reset anything….