23/07/2019 International calls failing via Cisco Unified Boarder Element SIP trunk but national calls are

calls are ok: Eventually fixed, but calls didn’t ring …

The Voice Initiate

. . . endless tales of a man seeking to decode his way through a very coded and mysterious sphere of
technology

International calls failing via Cisco Unified Boarder

Element SIP trunk but national calls are ok: Eventually
fixed, but calls didn’t ring before connecting.

Filed under: Cisco Call Manager, Gateways and Trunks, Tales, Tales — 3 Comments
October 13, 2013

i
3 Votes

* Hint:Please note that some of the screenshots and outputs in this post have been recreated in a lab

* Hint:Please double-click the snapshots to zoom into them.

This is another interesting case that I recently worked on with a colleague of mine. The topology
below represents a high level overview of what the client’s network looks like. The complaint was
that users could call local numbers but all international calls were failing to connect. That got us
thinking . . . our first question was, if local calls are working fine, and international call are not, then
what is the difference between both calls

The snap-shot below shows how the sip messages were flowing for the working local calls .

https://voiceinitiate.com/2013/10/13/international-calls-failing-via-cisco-unified-boarder-element-sip-trunk-but-national-calls-are-ok-eventually-fixed… 1/9
23/07/2019 International calls failing via Cisco Unified Boarder Element SIP trunk but national calls are ok: Eventually fixed, but calls didn’t ring …

If you compare the sip messages of the working call above with the non-working international call
below, you will see that the difference is that the messages below contains a ‘ 183 session progress
message‘.

So based on the above, the question that now presents itself is: why did the Cisco Unified Boarder
element send a bye message to the Cisco Call Manager when the remote phone that is out in the
cloud was actually ringing? Does this make sense; Strange isn’t it?

Ok so we know from our experience as Engineers that when a call fails, there is normally some sort
of error message, failure or cause code of some sort. In the trace output below, you will see that I have
actually highlighted the error -code that was in the ‘ bye‘ message that we saw in the call-flow

https://voiceinitiate.com/2013/10/13/international-calls-failing-via-cisco-unified-boarder-element-sip-trunk-but-national-calls-are-ok-eventually-fixed… 2/9
23/07/2019 International calls failing via Cisco Unified Boarder Element SIP trunk but national calls are ok: Eventually fixed, but calls didn’t ring …

diagram above.

As we can see, the sip protocol informs us that the call failed with a cause of: ‘Reason:
Q.850;cause=65‘ . If you do a Google search for cause code 65 will probably find something related to
a codec/capability negotiation issue; which might lead one to think about transcoding. Please have a
try for yourself; do a Google search and see what you come up with.

::::::::::::::::::::::::::::::::::::::::::::::::

Sent:
BYE sip:447578332431@192.168.0.10:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.20.8:5060;branch=z9hG4bK8052F20C7
From: <sip:00412256731@192.168.0.20>;tag=FAA7C024-667
To: “maxwell o” <sip:447578332431@192.168.0.10>;tag=342693~12b9673c-9ebc-4b8c-b0db-
46b8d985386a-34835506
Date: Mon, 30 Sep 2013 12:44:02 gmt
Call-ID: fa88da80-24917212-28046-2212b0a@192.168.0.10
User-Agent: Cisco-SIPGateway/IOS-15.2.4.M1
Max-Forwards: 70
Timestamp: 1380545045
CSeq: 101 BYE
Reason: Q.850;cause=65
P-RTP-Stat: PS=19,OS=4480,PR=25,OR=4000,PL=0,JI=0,LA=0,DU=34270069
Content-Length: 0

::::::::::::::::::::::::::::::::::::::::::::::::

Did you carry out the Google search, did it show something related to codec? if so, then I’m pleased
to inform you that answer is incorrect lol . . . just joking :-). I have been mislead by so many error
codes in the past that I no longer trust them completely.

On a more serious note, lets take a look at what RFC: 3262(click on this link) has to say about this; and I
quote:

If the UAS had placed a session description in any reliable

provisional response that is unacknowledged when the INVITE is
accepted, the UAS MUST delay sending the 2xx until the
provisional
response is acknowledged. Otherwise, the reliability of the 1xx
cannot be guaranteed, and reliability is needed for proper
operation
of the offer/answer exchange.

::::::::::::::::::::::::::::::::::::::::::::::::

So the question is, what does the above mean? Lets start of by explaining what a ‘provisional
response’ is:

https://voiceinitiate.com/2013/10/13/international-calls-failing-via-cisco-unified-boarder-element-sip-trunk-but-national-calls-are-ok-eventually-fixed… 3/9
23/07/2019 International calls failing via Cisco Unified Boarder Element SIP trunk but national calls are ok: Eventually fixed, but calls didn’t ring …

A very simplified definition of provisional responses is that ‘ they are 1xx responses within a Sip
Dialogue/ conversation’. The snap-shot below provides a quick glance at examples of Provisional
Responses.

(source:
h p://en.wikipedia.org/wiki/List_of_SIP_response_codes#1xx.E2.80.94Provisional_Responses)

However, the definition above still does not explain what a ‘ reliable provisional response’ is.

As simplified definition of a ‘ reliable provisional response’ is that : a provisional response becomes

reliable when the Sending User Agent Server (UAS) expects an acknowledgement back from the
receiving User agent (UA)

With these definitions under out belt, it is now easy to understand what the RFC copied above was
trying to say. The RFC is basically pointing out the importance of receiving an acknowledgement
from the remote end when the reliable response mechanism is being used. It can actually stop a call
from completing if not handled properly.

Lets take a time-out to quickly take a look at the SIP-message-flow the copied below. Did you notice
the use of the PRACK? :

(Source: ‘ borrowed’ form Cisco )

https://voiceinitiate.com/2013/10/13/international-calls-failing-via-cisco-unified-boarder-element-sip-trunk-but-national-calls-are-ok-eventually-fixed… 4/9
23/07/2019 International calls failing via Cisco Unified Boarder Element SIP trunk but national calls are ok: Eventually fixed, but calls didn’t ring …

I guess at this point, the Sip-call-flow diagram of the failed international call makes so much more
sense now? I guess we can see the cause of the failure now? Basically, the Cisco Unified boarder
element sent a bye message to the call-manager because the call manager never sent an ACK message
to the ‘183 session progress message‘ it sent to call-manager.

To be honest, this should not have happened though: The Cisco CUBE algorithm was clearly not
following the relevant SIP RFC stipulations. But then again who does? I will not explain why the
Cisco CUBE was not following RFC stipulations because this post would become too long and boring.

Anyway, here is what we did to solve the problem:

We modified the ‘ sip profile’ a ached to the sip trunk so that it would support the sending of RACK
( Provisional Response Acknowledgement)messages to all Provisional Response messages coming
from cube(i.e 18x sip messages).

Here are the steps:

1) go to cucm admin page

2) find the sip profile that your sip trunk is using.

3) then go to device > device Se ing > SIP Profile

4) enable ‘ send PRACK for all 1xx messages

5) reset the sip trunk

https://voiceinitiate.com/2013/10/13/international-calls-failing-via-cisco-unified-boarder-element-sip-trunk-but-national-calls-are-ok-eventually-fixed… 5/9
23/07/2019 International calls failing via Cisco Unified Boarder Element SIP trunk but national calls are ok: Eventually fixed, but calls didn’t ring …

6) make sure your sip dial-peer on the cube that is pointing at cucm has something like this in config
line:

dial-peer voice 20 voip

voice-class sip rel1xx require 100rel

Well as soon as we did this, all the calls started connecting fine.

However, we were having ringing / ring-back issues on international calls such that when an
international call was made, the caller could not hear the remote phone ringing.

If you encounter this in your network, here is what you could do resolve it.

On the cucm:

:::::::::::::::::::::::::::::::::::

1) go to cucm admin page

2) find the sip profile that your sip trunk is using.

3) then go to device > device Se ing > SIP Profile

4) tick the check box for ‘ disable early medial for 180’

5) reset the sip trunk

6 on your Cisco Cube you should have a config on your inbound and outbound dial-peer similar to
this(if you found that the service provider was not sending the audio or media in 183 /180 message):

dial-peer voice 20 voip

voice-class sip block 183 sdp absent
voice-class sip block 180 sdp absent (use this single line with
care)

see the diagram below for further details . . .

https://voiceinitiate.com/2013/10/13/international-calls-failing-via-cisco-unified-boarder-element-sip-trunk-but-national-calls-are-ok-eventually-fixed… 6/9
23/07/2019 International calls failing via Cisco Unified Boarder Element SIP trunk but national calls are ok: Eventually fixed, but calls didn’t ring …

Hope you have found this entry entertaining and contributory to your quest for knowledge and your
day-to-day ba les between Man and Machine.

A special thank you goes out Mike Jones for his contributions to this case which has now led to this
publication.

Mike can be found at uk.linkedin.com/pub/michael-cunliffe-jones/46/6b6/2a6/

All the best folks,

Regards

Maxwell

Advertisements

REPORT THIS AD
Tags: '183 session progress, call, cisco, cube, disable early medial for 180, dissconnect, fail, Protocols,
Reason: Q.850;cause=65, RFC: 3262, Session Initiation Protocol, SIP, sip trunk, Unified
communications, User agent, voice-class sip block, voice-class sip rel1xx
Comments RSS (Really Simple Syndication) feed

https://voiceinitiate.com/2013/10/13/international-calls-failing-via-cisco-unified-boarder-element-sip-trunk-but-national-calls-are-ok-eventually-fixed… 7/9
23/07/2019 International calls failing via Cisco Unified Boarder Element SIP trunk but national calls are ok: Eventually fixed, but calls didn’t ring …

3 Comments:

BELA BACSI
October 3, 2017 at 5:37 pm

i
Rate This

HI

I had the same error message with the same problem:

-incoming calls worked without problem
-outgoing calls failed with: ‘Reason: Q.850;cause=65

After detailed search, it has turned out, the SIP provider (MPLS-VPN) does not support the SRTP
transfer, so needed to fallback to RTP that caused the “NO CODEC” error, and also the “Media
Negotiation failed with no 18x Media” message.

So the solution was simple:

—————————————————————————
> voice service voip
sftp fallback
> voice service voip > sip
srtp negotiate cisco

> dial-peer voice XX voip

srtp fallback
voice-class sip srtp negotiate cisco
—————————————————————————

So after this changes the outgoing calls worked flawlessly.

Best Regars,
BELA BACSI

Maxwell
August 21, 2014 at 7:55 pm

i
Rate This

Lovely. I am happy this post was useful to you .

https://voiceinitiate.com/2013/10/13/international-calls-failing-via-cisco-unified-boarder-element-sip-trunk-but-national-calls-are-ok-eventually-fixed… 8/9
23/07/2019 International calls failing via Cisco Unified Boarder Element SIP trunk but national calls are ok: Eventually fixed, but calls didn’t ring …

Thanks for the feedback.

Cheers

RK
August 20, 2014 at 4:00 pm

i
Rate This

I stumbled upon your post while troubleshooting Ringabck issue on International calls. CUCM
was playing local Dial tone since PRACKs were not acknowledged. Carrier was expecting
response to 18x messages. I created new SIP profile and it worked. Thank you so much.

Create a free website or blog at WordPress.com.

https://voiceinitiate.com/2013/10/13/international-calls-failing-via-cisco-unified-boarder-element-sip-trunk-but-national-calls-are-ok-eventually-fixed… 9/9