Unable to make International call

[Essam Butt]

Hello all!

We have issues calling international numbers only, incoming is working fine as well as the local landline and mobile numbers.

The message flows show a quick bye with a reason: Q.850;cause=65. I know this means some Negotiation Failure but exactly what is failing that's what I am trying to find. 

Attached below is the debug from our CUBE, what should I check and where to check? Please help.

Thanks,

[b.winter]

Have you compared a working national call with an international call?
Which IP's of the trace belong to which system?

[Essam Butt]

yep I did and I still can't tell what is missing to make an international call.

Sorry, here are the IPs descriptions in order:

49.127.96.197 - Phone IP
133.194.16.233 - CUCM
172.25.138.10 - internal SIP Trunk to CUBE
10.17.250.3 - CUBE SIP Trunk to Telco
115.178.182.200 - Telco

[Scott Leport]

Likely to be a codec mismatch. 

If you have separate dial-peers configured for local, national and International patterns, make sure you've got a codec configured on the dial-peer for International calls, either by hard coding the codec or using the voice-class codec command. 

[Essam Butt]

no we have only one dial-peer for all outgoing.

dial-peer voice 100 voip
description OUTBOUND-TELCO
max-conn 80
destination-pattern 0T
modem passthrough nse codec g711alaw
session protocol sipv2
session server-group 1
voice-class codec 2
voice-class sip options-keepalive up-interval 5 down-interval 5 retry 3
voice-class sip bind control source-interface GigabitEthernet0/0/3
voice-class sip bind media source-interface GigabitEthernet0/0/3
dtmf-relay rtp-nte
fax-relay ans-treatment
fax protocol pass-through g711alaw
no vad
!

[Roger Kallberg]

Would you not need to remove the leading 0 (zero) in the called number for the call to succeed to your service provider? You can do that by adding this to your configuration.

voice translation-rule 40
 rule 1 /^0\(.*\)/ /\1/
!
voice translation-profile PSTN-OUT
  translate called 40
!
dial-peer voice 100 voip
 translation-profile outgoing PSTN-OUT

[Essam Butt]

Telco says it's fine to send it with a leading zero, and also calls to local landlines and mobiles are working fine with a  leading zero, just not the international.

[TechLvr]

Essam,
Based on your debug messages, it seems to be a CUBE config issue.

Here is what's happening:
CUBE receives an INVITE from the CUCM (w/ SDP)
CUBE sends a 100 Trying message to CUCM
CUBE sends an INVITE to the carrier (w/ SDP)
Carrier sends a 100 Trying message followed by a 200 OK (choosing g729 codec)
CUBE sends a 101 ACK followed by a 102 BYE message to the Carrier (the call drops)

Now, it is possible that your incoming dial peer, facing CUCM, does not include a g729 codec or g729 is not at the top of the list if you are using a voice class codec. The CUBE drops the call because it can't handle two call legs with mismatched codecs in the absence of a transcoder.

Please share the following info to help you fix the issue.
The CUBE config (you can hide the public IPs and other sensitive info)
Or at least share the inbound/outbound dial peers, and also the voice class codecs.

Also, please see your call flow diagram below.

[Essam Butt]

Hey,

You are correct, it's using a different class of codec for cucm and g729 is not at the top of the list. But does this matter? and if change the order will it affect any other calls, like local landline?

Here are the voice class codecs and the dial peers, how should I change this now?

voice class codec 1
codec preference 1 g722-48
codec preference 2 g722-56
codec preference 3 g722-64
codec preference 4 g711alaw
codec preference 5 g711ulaw
codec preference 6 g729br8
codec preference 7 g729r8
!
voice class codec 2
codec preference 1 g711alaw
codec preference 2 g711ulaw
codec preference 3 g729br8
codec preference 4 g729r8
!

dial-peer voice 1 voip
description Inbound-DialPeer
modem passthrough nse codec g711alaw
session protocol sipv2
incoming called-number 02150300
voice-class codec 2
dtmf-relay rtp-nte
fax-relay ans-treatment
!
dial-peer voice 100 voip
description OUTBOUND-TELCO
max-conn 80
destination-pattern 0T
modem passthrough nse codec g711alaw
session protocol sipv2
session server-group 1
voice-class codec 2
voice-class sip options-keepalive up-interval 5 down-interval 5 retry 3
voice-class sip bind control source-interface GigabitEthernet0/0/3
voice-class sip bind media source-interface GigabitEthernet0/0/3
dtmf-relay rtp-nte
fax-relay ans-treatment
fax protocol pass-through g711alaw
no vad
!
dial-peer voice 200 voip
description outbound-to-uc-cm1
preference 1
max-conn 60
destination-pattern 021
modem passthrough nse codec g711alaw
session protocol sipv2
session target ipv4:133.194.16.233
voice-class codec 1
voice-class sip bind control source-interface Loopback0
voice-class sip bind media source-interface Loopback0
dtmf-relay rtp-nte
fax-relay ans-treatment
!
dial-peer voice 201 voip
description outbound-to-uc-cm2
preference 2
max-conn 60
destination-pattern 021
modem passthrough nse codec g711alaw
session protocol sipv2
session target ipv4:133.194.16.238
voice-class codec 1
voice-class sip bind control source-interface Loopback0
voice-class sip bind media source-interface Loopback0
dtmf-relay rtp-nte
fax-relay ans-treatment
!
dial-peer voice 2 voip
description Inbound-DialPeer
modem passthrough nse codec g711alaw
session protocol sipv2
incoming called-number .T
voice-class codec 1
dtmf-relay rtp-nte
fax-relay ans-treatment
!

[Roger Kallberg]

One thing that I would definitely recommend you to change is to add bind statements on your inbound dial peers and change the match criteria used for these to use information in the VIA header instead of incoming called number. For more details on this check out my absolute most referenced document.
https://www.cisco.com/c/en/us/support/docs/voice/ip-telephony-voice-over-ip-voip/211306-In-Depth-Explanation-of-Cisco-IOS-and-IO.html

Apart from this I would also recommend you to turn off VAD as it’s an absolute abomination to use. To do so you’ll add “no vad” to your dial peers and also remove any codecs that had a “b” in the name from your codec lists and any other place where it could exist, like media resources such as conference bridges, transcoding or media resources.

You can also simplify your setup by using server groups on your dial peers where you now have multiple once, like towards CM. This is also outlined in the shared document.

[TechLvr]

Essam,

Could you please temporarily add the two test dial peers below and try again?
This set of inbound/outbound dial peers only match your test international number "0103361399026011" so you should test outbound calls to this number. Also, don't forget to collect/share logs in case the issue still persists.

dial-peer voice 1000 voip
description Inbound-DialPeer-TEST
modem passthrough nse codec g711alaw
session protocol sipv2
incoming called-number 0103361399026011
codec g729r8
voice-class sip bind control source-interface Loopback0
voice-class sip bind media source-interface Loopback0
dtmf-relay rtp-nte
fax-relay ans-treatment
no vad

dial-peer voice 2000 voip
description OUTBOUND-TELCO-TEST
max-conn 80
destination-pattern 0103361399026011
modem passthrough nse codec g711alaw
session protocol sipv2
session server-group 1
codec g729r8
voice-class sip options-keepalive up-interval 5 down-interval 5 retry 3
voice-class sip bind control source-interface GigabitEthernet0/0/3
voice-class sip bind media source-interface GigabitEthernet0/0/3
dtmf-relay rtp-nte
fax-relay ans-treatment
fax protocol pass-through g711alaw
no vad

[Essam Butt]

Sweet!! that worked. It was a codec issue. I don't understand though, the specific codec is there in the list so why wasn't it being negotiated?

So what do you suggest now, how should I change the codec preference list? and will it affect other national calls if I do? as we have no issue with other calls?

Thanks,

[TechLvr]

Glad to hear that the test dial peers worked.

Here is why call fails using your original dial peers.
CUCM sends an INVITE with early offer to the CUBE offering OPUS, G722, G7221, G711ulaw, G711alaw, and g729r8 codecs in this order.
CUBE sends an INVITE with early offer to the provider offering g711ulaw, g711alaw, g729br8, and g729br8, g729r8 respectively.
Provider responds to the CUBE with g729r8. (This is because g729 is your carrier's preferred codec)
CUBE tries to respond to the CUCM with g722 because g722 is the most preferred codec of the CUBE's incoming dial peer facing CUCM.
CUBE then drops the call due to codec mismatch (g729r8 on the carrier side, and g722 on the CUCM side)

Now, I know you said national outbound calls work fine. Is it possible that the carrier leverages different codecs for national and international calls?
We can only determine this by looking at the traces of a national outbound call as well.

I will provide my recommended solution if you provide the requested info below.
Call traces for a National Outbound call
What are all the codecs that your provider supports? (You can find this from the traces of an inbound call)
Do you have a UCCX server or any other systems that only support one codec. If yes, what codec? Do you use transcoding these systems?

[Essam Butt]

Thank you for looking into it.

That does make sense, however, what's confusing me is that if all the codecs in the list are being offered why does it only pick the first preferred codec? I mean shouldn't the CUBE go through the list and search for the codec that is being requested by the carrier?

Attaching two traces, for a national outbound and an inbound call.

We do have a UCCX and it uses the G711 codec. and we don't have any transcoding on this CUBE.

Thanks again,

[TechLvr · Accepted solution]

Essam,
There are a number of issues with your CUBE config.
1. You are using the same inbound dial peer for the CUCM side and the Carrier side.
2. Your inbound dial peer contains g722. This is not supported by the carrier.
3. All your dial peers contain g729br8. Neither CUCM, nor the Carrier advertises it.
    Your carrier supports g711ulaw, g711alaw, and g729r8. CUBE only needs these three.
4. Your destination patterns are not very specific (0T, and 021). This creates unnecessary call loops.
For example, your logs show you dialed an external number that begins with 021. The CUBE        routes this back to CUCM using dial peers 200, and 201. As it would be expected, CUCM sends a 404 not found. Then the CUBE sends the carrier using dial peer 100 and the call finally connects.

I suggest you test with the dial peers/other configs in the attached text file.

In order to test these changes, shut down all of your exiting dial peers.
Do NOT delete the existing dial peers just in case your need to revert back to the original setup.

Test all inbound/outbound scenarios after you apply the changes.

If there any issues, share more traces here.
To revert the changes, shutdown or delete the new dial peers, then unshut the old dial peers.

Hope this is helpful.