Solved: SIP Dialing International Numbers - Call Cannot be Completed as dialed

Steve Baker · ‎06-30-2017

Hi,

I'm trying to get international dialing working through SIP. Whenever we try and dial am international number we get a response from call manager saying "the call cannot be completed as dialed". It looks to be trying to push the call out correctly so I'm not sure where the issue lies. I have attached a couple of debugs and the config.

Any help much appreciated.

Thanks

Steve

Brandon Buffin · ‎06-30-2017

Looks like the called number is 18006098731? I see this presented to the carrier as 0018006098731 and 90018006098731. Is this the format your carrier is expecting? The disconnect code 404 is indicating an unallocated number. I would recommend that you open a ticket with the carrier to see what digits they are expecting and what they see on their end when you make the call.

Brandon

View solution in original post

Slavik Bialik · ‎06-30-2017

So,

It seems like the changes I suggested are working, you can see that after GW recieved the invite, it is sending the INVITE without the '900' to GAMMA (10.128.0.89), and you even get a reply with 100 Trying, and then you get your first 404 Not Found message, without the "No matching outgoing dial-peer" because it did match. Still not a correct route though, so I agree with Brandon, you'll need to speak with your ITSP and ask them how they expect you to send them the international numbers. For example here in Israel, I cannot send E164 numbers to my ITSP, they expect me to dial first the 3 digits of the international provider I want to use in order to dial out. So if you have the same concept in the UK, just rewrite the translation rule to be:
voice translation-rule 2
rule 1 /^900\(.*\)/ /123\1/
rule 2 /^9\(.*\)/ /\1/
Instead of '123', of course, put the international provider access code.
As you can see, you've got a second INVITE message towards the GW, and it returned you 404 not found with the "No matching outgoing dial-peer".
I'm guessing that you have on your CUCM in a the route group / route list a second route, that routes to the same GW (from some reason).
Therefore, CUCM gets the first 404 Not found message from the GW, and triggers another INVITE based on its routing selection. But because the GW knows that it already failed on dial-peer 101, it won't try it again, otherwise it'll trigger a loop. And because you don't have any other dial-peer that matches this pattern, it is failing with the "No matching outgoing dial-peer" error.

View solution in original post

Brandon Buffin · ‎06-30-2017

Looks like the called number is 18006098731? I see this presented to the carrier as 0018006098731 and 90018006098731. Is this the format your carrier is expecting? The disconnect code 404 is indicating an unallocated number. I would recommend that you open a ticket with the carrier to see what digits they are expecting and what they see on their end when you make the call.

Brandon

Slavik Bialik · ‎06-30-2017

Hi,

It is because you're using translation profile "To-GAMMA" that is only removing leading 9 from the number. But when you're calling to international number, you must send to the ITSP an e.164 number, and you're sending it with leading 00, which is wrong.

Anyway, I think you can remove dial-peer 102, it is pointless, as you already have dial-peer 101 that is already catching all the dialed numbers starting with 9.

And just change translation-rule 2 to be:

voice translation-rule 2
rule 1 /^900\(.*\)/ /\1/
rule 2 /^9\(.*\)/ /\1/

And it should work :)

Steve Baker · ‎06-30-2017

Thanks for the quick replies guys.

I've updated the voice translation-rule 2 as per the above but still seems to be the same issue.

I've run a debug on CCSIP Messages and it's saying "No matching outgoing dial-peer"

Debug attached.

Don't know if this helps or already obvious but we are dialing from UK to US.

Slavik Bialik · ‎06-30-2017

So,

It seems like the changes I suggested are working, you can see that after GW recieved the invite, it is sending the INVITE without the '900' to GAMMA (10.128.0.89), and you even get a reply with 100 Trying, and then you get your first 404 Not Found message, without the "No matching outgoing dial-peer" because it did match. Still not a correct route though, so I agree with Brandon, you'll need to speak with your ITSP and ask them how they expect you to send them the international numbers. For example here in Israel, I cannot send E164 numbers to my ITSP, they expect me to dial first the 3 digits of the international provider I want to use in order to dial out. So if you have the same concept in the UK, just rewrite the translation rule to be:
voice translation-rule 2
rule 1 /^900\(.*\)/ /123\1/
rule 2 /^9\(.*\)/ /\1/
Instead of '123', of course, put the international provider access code.
As you can see, you've got a second INVITE message towards the GW, and it returned you 404 not found with the "No matching outgoing dial-peer".
I'm guessing that you have on your CUCM in a the route group / route list a second route, that routes to the same GW (from some reason).
Therefore, CUCM gets the first 404 Not found message from the GW, and triggers another INVITE based on its routing selection. But because the GW knows that it already failed on dial-peer 101, it won't try it again, otherwise it'll trigger a loop. And because you don't have any other dial-peer that matches this pattern, it is failing with the "No matching outgoing dial-peer" error.

Steve Baker · ‎07-01-2017

Thanks Slavik,

I've thrown it back to the telco provider who seem to think everything is fine at their end but they are checking again.

In terms of how the outgoing call should be presented, the dial code for the number we are testing is 001. So the outbound call would need to show as 0018006098731 which as far as I can see it does?

I've also tried calling Ireland. Code for that region is 00353 with the local number being 16772222. So for us to dial it would need to present 0035316772222. Again this looks to present correctly but we are getting the same error.

Debug attached

Dennis Mink · ‎07-01-2017

The other thing you might be considering is the caller ID that you are presenting, I am saying this because some SIP providers are funny about that, I see you are using E164 as caller ID and not using that for the called number (00353....), but like Brandon mentions throw it back to your provider, their are bouncing the call so they should be able to tell you why.

To: <sip:0035316772222@10.128.0.89>;tag=3707886281-411287
From: <sip:+442072093000@10.0.13.146>;tag=12423608-22CE

Please remember to rate useful posts, by clicking on the stars below.

Steve Baker · ‎07-02-2017

Thanks for the help guys. The provider finally got back to me and the fault was with them. Amazingly they managed to fix it by resetting the trunk at there end. Gotta love it when people don't even try the most basic fixes first.

Slavik Bialik · ‎07-02-2017

I'm glad it's working now.

But out of curiosity, do you now sending the international number with leading 00 and it is working or with some access code of the provider, or just a simple E164 number?

Steve Baker · ‎07-03-2017

Just sending the international number with the leading 00. Not sure what was stopping it from working at their end before.