Route group number translation not applying when calling party ID not set to originator?
I have an issue right now whereby it seems that a "calling party transformation" set at the route group level is not applied when the calling party ID is set to anything other than originator.
The call flow is this:
External party -> SIP Trunk -> CUBE -> CUCM -> IP phone (CFAll to external number) -> CUBE -> SIP Trunk
Our SIP provider authenticates calls based on calling number. If the calling number is not a number within the DDI Range of our site, the call is rejected.
The users extension for example is #44441234
The route pattern used is pointed at a route group that has a calling party transformation of 0203123XXXX
This works sucessfully when dialling out directly from the handset, the calling number seen in the SIP debugs is 02031231234.
However, it starts to fail with call forward all's from IP Phones.
When you dial into an IP phone that has a CFA to an external party, and the "Calling party ID" field on the SIP trunk configuration is set to "originator", The number is translated sucessfully.
For example, If I dial from my mobile into an IP phone that has call forward all to the users mobile - the call is passed to the sip provider and may nor may not suceeed. For example, lets say the DDI range for the site is 0203 123 1000 -2000. My mobile number is 07777 123 1234.
In this case, the calling number on the SIP invite seen for the call divert is "0203 123 1234" (So 0203 123 and then the last four digits of my mobile number)
In this case, the call forward suceeds, because the calling number is within the DDI range of the site. However, lets say my mobile number is 07777 123 4567.
In this case, the calling number on the SIP invite seen for the call divert is "0203 123 4567" (So 0203 123 and the last four digits of this mobile number)
In this case, the call forward fails, with a SIP declined coming back from the SIP provider because the calling number is not within the DDI range of the site.
If you set the "Calling party" ID to be "First redirecting party" (Or any of the other options available!) at the SIP trunk level, the "Calling party number translation" that is applied at the route group level does not get applied.
So for example, with the calling party ID set to "First redirecting party (External)" and you make the same call as above, the calling party ID on the SIP invite is simply "1234".
In effect, when using anything other than "originator" as the calling party ID, it seems to completely bypass the calling party translations that are applied at the route group level.
Is this expected behaviour? Is there any way to bypass this or translate the calling number in another way? The SIP provider has confirmed that they cannot change the behaviour of their PBX.
Are you getting this error “Installer User Interface Mode Not Supported. The installer cannot run in this UI mode. To specify the interface mode, use the -i command-line option, followed by the UI mode identifier. The value UI mode identifiers...
The below trick might come handy when you have to add a new node to a cluster but you don't have or is unsure of the security password for the publisher. This procedure has been around for ages.
1) Login into the CLI of the Publisher.