* 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 .
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 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:
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: http://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 )
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’ attached 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 Setting > SIP Profile
4) enable ‘ send PRACK for all 1xx messages
5) reset the sip trunk
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 Setting > 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 . . .
Hope you have found this entry entertaining and contributory to your quest for knowledge and your day-to-day battles 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
The Voice Initiate 