CUBE ".T" dial peer drops the "+" on outbound E164 calls

[TONY SMITH]

Hi,

These are a couple of gateways that we've inherited from a previous partner and are trying to clean up.  Their ITSP requires most calls in E164, but supports non-E164 service and emergency numbers.  One thing that struck me was that for each ITSP connection they've configured two outbound dial peers, one with destination pattern of "+T" and one is ".T".   My first impulse was to think that the "+T" isn't needed, since ".T" will match it anyway.   However a quick test shows that if an E164 call routes out using the ".T" pattern, the + gets dropped in the outbound INVITE.   Is this expected behaviour?

The two dial peers are exactly the same, aside from destination pattern.

As an aside the gateways could really do with zapping and completely rebuilding, but the customer is resistant to suggestions that their system is grossly wrong, so that limits us at the moment to relatively minor cleanup and optimisation.

Thanks,

Tony S

[HARIS_HUSSAIN]

Can you confirm what is the IOS Version of Voice Gateway.

I believe you are hitting the Bug CSCub65380. In which the + is removed for SIP dial-peer matching.

Below is the description from Cisco Guide.

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/dialpeer/configuration/15-mt/vd-15-mt-book.pdf

destination-pattern + ] string[T]

+ --(Optional) Character indicating an E.164 standard number. With CSCub65380, behavior of dial peers with destination-patterns configured with + symbol was rectified. The + symbol is no longer dropped from the dial peer and matching occurs as expected

[TONY SMITH]

Thanks, that looks similar but not exactly the symptoms.   INVITEs from these gateways don't have "user=phone" in the URI.

Also the leading "+" is dropped when the destination pattern does not contain a "+", rather than when it does.

Gateways are running 15.4(3)S2, which isn't listed as affected (although I know that's not always a complete list).

[HARIS_HUSSAIN]

Can you post output of show call history voice OR show call active voice.

To find out where the + is getting dropped.

Also the Voice Translation Rules you are using.

Please rate and mark correct if helpful

Thanks

Haris

[TONY SMITH]

Cheers, I'd have to put the gateway back into the failed configuration to get the call history, I'll need to do that during a downtime or change window unless I can work out a test configuration.

There are no translation rules in effect on either the inbound of outbound dial peers involved in these call attempts.

On the SIP debugs I could see the INVITE from CUCM with the full E164 number, and the outgoing INVITE to the ITSP with the leading + missing