CCIE-V Looking at SIP Call Setup from UCM to ITSP

As I mentioned in a previous blog on MGCP Egress Call Setup, I have been studying for the CCIE-V and putting some emphasis on getting cozy with trace files. This is a necessary aspect of the IE voice exam. In what may become a series, I am taking my notes and dumping them in the ol' blog blender. 

In this installment, I want to walk through a SIP call setup scenario.

Background

We want to capture an egress call from Cisco Unified Communications Manager (CUCM) and a pseudo ITSP. Specifically, we want to use Session Initialization Protocol (SIP) "Early Offer" (EO) to establish the call. Using SIP EO isn't required when setting up a SIP call, we are just using this as a parameter in our setup because, well, it is a more common scenario. We'll get back to that.

The Players:

• Cisco IP Phone
• CUCM 7.0 (We are talking about the IE lab here folks)
• A Cisco 2800 ISR emulating the ITSP
• A phone on the 2800 ISR that acts as a PSTN answering station

 The Script:

• Cisco phone goes off hook and dials: 90114402012345678#
• CUCM uses SIP trunk to initiate call setup to ITSP
• PSTN phone rings
• PSTN phone answers
• All is well with the world

Early Offer vs. Delayed Offer

Some folks may ask "what is meant by 'Early Offer' and what, pray tell, is the antithesis of Early Offer?". Ok, ok - people probably won't word the question exactly that way but that isn't the point. It is probably worthwhile to give a brief definition here.

As with any VoIP call setup operation, the final goal is to establish a healthy media stream between two or more endpoints. That media stream is encoded and, as such, we want to make sure that all parties have the ability to encode and decode the packet payload. ("Have you met my friend, CODEC?"). Negotiating the CODEC as well as other parameters/capabilities is a critical part of the call set up process.

As with any negotiation, someone has to start it off and there are rules of engagement for who does what and when.  For SIP it all comes down to when the Session Description Protocol (SDP) information is exchanged. For Early Offer, the originator will send the SDP information in the INVITE message. With Delayed Offer, the originator does not send the SDP information in the INVITE message. Instead, the receiving agent will send SDP in the 200 OK acknowledgement first. Then the originating agent will send an acknowledgement with it's capabilities.

CUCM Configuration Notes
I am going to slide back into CCIE-V prep mode here and bring up a few points to keep in mind. First, it is very important to take note of whether the lab question has put any limits on the CODEC you should use. Since we are looking at Early Offer we will need to nail up a Media Termination Point (MTP) and the CODEC requirements will dictate how you should provision the SIP trunk. If the CODEC requirement is G.711 then you can use the software-based MTPs that the CUCM IP Voice Media Streaming (IPVMS) provides. If your question asks for G.729 then you will need to provision a MTP in IOS.  You will also need to assign that resource to a MRG which is then assigned to a MRGL...you get the picture.  Oh, and don't forget to set the MTP Preferred Originating Codec parameter under the trunk configuration!

Second, you want to pay attention for any clues that indicate which transport you should use for outbound SIP messages. The default is to use TCP (5060). If you need to adjust this then you will want to create a new SIP trunk security profile for your SIP trunk. I actually lean to creating a customer SIP trunk security profile regardless. That's just me.

Finally, pay attention to how calling and called information elements should be presented. There is nothing more frustrating than losing points when you have nailed the question but forgot something like using E.164 for the calling party.

The Walkthrough

We have modified the CUCM Call Manager service trace options as follows:

• Level: Detailed
• Trace Fields:
• Enable SIP Call Processing Trace

Call Setup

The IP phone has gone off hook and has dialed "90114402012345678#". This is matched by a local route pattern (e.g. 9011.!#) where we do some digit manipulation on the route pattern or at the Route List/Route Group level. Let's say that we are the cool kids on the block and are all about E.164. So, we are presenting called and calling party numbers using that super cool "+" we hear so much about (note: sarcasm intended).

09/16/2012 18:13:48.952 CCM|//SIP/SIPUdp/wait_SdlSPISignal: Outgoing SIP UDP message to 10.3.100.2:[5060]:
INVITE sip:+4402012345678@10.3.100.2:5060 SIP/2.0
Date: Sun, 16 Sep 2012 22:13:48 GMT
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
From: "HQ Phone 1" <sip:+12025552001@10.3.120.11>;tag=d235cf7c-c70c-4304-998e-109e730ea978-39266805
Allow-Events: presence
P-Asserted-Identity: "HQ Phone 1" <sip:+12025552001@10.3.120.11>
Supported: timer,resource-priority,replaces
Min-SE:  1800
Remote-Party-ID: "HQ Phone 1" <sip:+12025552001@10.3.120.11>;party=calling;screen=yes;privacy=off
Content-Length: 210
User-Agent: Cisco-CUCM7.0
To: <sip:+4402012345678@10.3.100.2>
Contact: <sip:+12025552001@10.3.120.11:5060>
Expires: 180
Content-Type: application/sdp
Call-ID: c86b3b80-5614f1c-107-b78030a@10.3.120.11
Via: SIP/2.0/UDP 10.3.120.11:5060;branch=z9hG4bKa77d2b4fc2
CSeq: 101 INVITE
Session-Expires:  1800
Max-Forwards: 70

v=0
o=CiscoSystemsCCM-SIP 2000 1 IN IP4 10.3.120.11
s=SIP Call
c=IN IP4 10.3.120.11
t=0 0
m=audio 24604 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

Let's do some dissection:

[Edit: Based on a conversation with a colleague, I realized that my original dissection of the media description section could use some clarification. Special thanks to Anthony Holloway for taking the time to reach out to me.]

• This message is obviously an INVITE message. We can see from the first line that we are using UDP as a transport
• The To: line shows the called party information (+4402012345678@10.3.100.2)
• The left-side of the URI is the destination number
• The right-side is the IP address of our ITSP
• The From: line is giving us the calling party URI and this is where we see the CUCM subscriber IP address (10.3.120.11)
• We know that this call is using Early Offer because the Content-type: line shows "application/sdp" (which means SDP information is being provided) and we see the long set of attributes after the "Max-Forwards" line
• We also see that we are offering G711-ulaw based on the media description section. The media description (in our example) starts with media description line "m=audio 24604 RTP/AVP 0 101". We can use the attribute ("a=") lines that follow to piece the offering together: "a=rtpmap:0 PCMU/8000" is G.711 u-law.

Assuming all is well in the kingdom of the ITSP then the appropriate response to this INVITE would be something like the following.

09/16/2012 18:13:48.978 CCM|//SIP/SIPUdp/wait_UdpDataInd: Incoming SIP UDP message size 410 from 10.3.100.2:[5060]:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.3.120.11:5060;branch=z9hG4bKa77d2b4fc2
From: "HQ Phone 1" <sip:+12025552001@10.3.120.11>;tag=d235cf7c-c70c-4304-998e-109e730ea978-39266805
To: <sip:+4402012345678@10.3.100.2>
Date: Sun, 16 Sep 2012 22:13:48 GMT
Call-ID: c86b3b80-5614f1c-107-b78030a@10.3.120.11
CSeq: 101 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0

09/16/2012 18:13:48.988 CCM|//SIP/SIPUdp/wait_UdpDataInd: Incoming SIP UDP message size 657 from 10.3.100.2:[5060]:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 10.3.120.11:5060;branch=z9hG4bKa77d2b4fc2
From: "HQ Phone 1" <sip:+12025552001@10.3.120.11>;tag=d235cf7c-c70c-4304-998e-109e730ea978-39266805
To: <sip:+4402012345678@10.3.100.2>;tag=2956BDA8-26A1
Date: Sun, 16 Sep 2012 22:13:48 GMT
Call-ID: c86b3b80-5614f1c-107-b78030a@10.3.120.11
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: <sip:4402012345678@10.3.100.2>;party=called;screen=no;privacy=off
Contact: <sip:+4402012345678@10.3.100.2:5060>
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0

In the above example we actually see two messages. The first is a 100 Trying message. This is a provisional response message that means the request has been received by the next-hop server and some unspecified action is being taken. Think of it like an active listener "uh-huh, yeah I'll look into that". The next message is a little more comforting: 180 Ringing. This is another provisional response that says that the User Agent (UA) receiving the INVITE is trying to alert the destination. At this point, both the called party station is ringing and the calling party is hearing the alerting tone (ringback).

Call Connected

The last phase of call setup is that the receiving end needs to bring its demands to the table to complete negotiations. In the following example we are receiving a 200 OK message from the ITSP. We can see that SDP information is being provided since we have a Content-Type: application/sdp line. We can also see that G711 u-law is OK by our ITSP (based on the media description section of the SDP).
 

09/16/2012 18:13:50.530 CCM|//SIP/SIPUdp/wait_UdpDataInd: Incoming SIP UDP message size 1013 from 10.3.100.2:[5060]:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.3.120.11:5060;branch=z9hG4bKa77d2b4fc2
From: "HQ Phone 1" <sip:+12025552001@10.3.120.11>;tag=d235cf7c-c70c-4304-998e-109e730ea978-39266805
To: <sip:+4402012345678@10.3.100.2>;tag=2956BDA8-26A1
Date: Sun, 16 Sep 2012 22:13:48 GMT
Call-ID: c86b3b80-5614f1c-107-b78030a@10.3.120.11
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: <sip:4402012345678@10.3.100.2>;party=called;screen=no;privacy=off
Contact: <sip:+4402012345678@10.3.100.2:5060>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-12.x
Session-Expires:  1800;refresher=uac
Require: timer
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 184

v=0
o=CiscoSystemsSIP-GW-UserAgent 3897 386 IN IP4 10.3.100.2
s=SIP Call
c=IN IP4 10.3.100.2
t=0 0
m=audio 19544 RTP/AVP 0
c=IN IP4 10.3.100.2
a=rtpmap:0 PCMU/8000
a=ptime:20

Being the polite UA, our CUCM responds to the 200 OK with an acknowledgement and our two parties can run up their international phone bill until their hearts content.

09/16/2012 18:13:50.540 CCM|//SIP/SIPUdp/wait_SdlSPISignal: Outgoing SIP UDP message to 10.3.100.2:[5060]:
ACK sip:+4402012345678@10.3.100.2:5060 SIP/2.0
Date: Sun, 16 Sep 2012 22:13:48 GMT
From: "HQ Phone 1" <sip:+12025552001@10.3.120.11>;tag=d235cf7c-c70c-4304-998e-109e730ea978-39266805
Allow-Events: presence
Content-Length: 0
To: <sip:+4402012345678@10.3.100.2>;tag=2956BDA8-26A1
Call-ID: c86b3b80-5614f1c-107-b78030a@10.3.120.11
Via: SIP/2.0/UDP 10.3.120.11:5060;branch=z9hG4bKa87685a762
CSeq: 101 ACK
Max-Forwards: 70

Using this Information

The first step to being able to clearly and concisely answer any troubleshooting question is to understand what a normal call looks like. The example provided above is but one variation. You may need to dissect a Delayed Offer call or deal with G.729 as a CODEC. One of the good things about SIP is that it is relatively simple to decipher. Messages are in plain English. The SDP piece is a tad cryptic but there is some good news: MGCP uses SDP for capabilities negotiation too.

---

Thanks for reading. If you have time, post a comment!