We currently have an issue where we are unable to dial internationally through our SIP trunk via our CUBE. I suspect it is because our CUBE has been incorrectly configured by the ITSP but not familiar enough with Cisco kit to figure it out. When running a debug of ccsip messages I can see the international number gets sent in the invite and then gets translated to remove the leading 00 which then causes the ITSP to reject the call.
I have tried setting up a specific dial peer to test and created a new translation profile and still can't get the call to go out without it stripping the 00.
Here is the dial peer and translation profile:
dial-peer voice 90003 voip
translation-profile outgoing strip_9_test
session protocol sipv2
session target ipv4:x.x.x.x
session transport tcp
voice-class codec 100
voice-class sip profiles 100
voice-class sip options-keepalive
voice-class sip bind control source-interface GigabitEthernet0/0
voice-class sip bind media source-interface GigabitEthernet0/0
CUBE#test voice translation-rule 600 90035796705040
Matched with rule 1
Original number: 90035796705040 Translated number: +0035796705040
Original number type: none Translated number type: none
Original number plan: none Translated number plan: none
Yet when the call goes out debug ccsip shows the first invite to 90035796705040 then 2nd invite the same then 3rd message shows invite to 35796705040 which our ITSP responds with 403.
Any help appreciated. Thanks.
change the translation pattern, to strip both leading 0's and add a plus, or route 0011<country code>+<ANI>
adding a plus would be preferable as its E164, no ITSP should/will(?) reject this.
do your national call work? or just issue with IDD?
We are in the UK. 00357.... is a call to Cyprus. I have tried translation to change 900 to 00 and +00 and neither works. Both end up without the leading 00.
National dialling works fine and I can see on our CUBE it is translating to +44XXXXXXXXXX as it sends SIP messages to our ITSP.
We have been able to dial internationally from our CUCM cluster using a backup ISDN. The calls have been failing at our SIP trunk and our route list contains the ISDN so calls end up going down those.
You would need to provide additional debugs to see what is going on.
debug ccsip messages
debug voice ccapi inout.
Please do not run on terminal if system in production.
Please mark helpful or correct