Subscribe To CCIERANTS

Tuesday, August 24, 2010

SIP Call-flow troubleshooting

Debugging Voice.

Ok, we all want our CCIE Voice numbers, I imagine that’s why a heck of a lot of you are reading this blog ;). I want mine too believe me… Double CCIE is the goal this year, 4 by 2012. Will I make it? I guess I’ll see.

Moving on, in the CCIE Voice lab we have all already been warned: Expect tons of troubleshooting. Internetworkexpert’s coursework would have you believe that this is limited to simple stuff like phones in the wrong VLAN and stuff like that, IP Expert seem to take a much better approach that chances are it’s going to be more complicated.

Cisco themselves mentioned at Networkers in Las Vegas that the CCIE Voice lab will now have lots of focus on troubleshooting, up to 15 percent! They also specifically mentioned that the days of assuming your PSTN is going to be an E1 connection in the lab are long gone too (i.e. it may entirely be a SIP trunk or H.323 gatekeeper.)

With this in mind, I set out on a journey of discovering voice troubleshooting, what followed was learning some incredibly useful commands that I wanted to share with you all.

We are going to examine some SIP call flows, some H.323 call flows and some DTMF-relay in an effort to understand them all a bit better. I have never seen an absolutely comprehensive collection of all this info in one place. I truly hope this helps someone out there.

This tutorial assumes you have some basic SIP knowledge already, you should know about the different types of SIP messages (invite, OK, ACK) , the fact that its text-based, that it sends back error codes as 400’s or 500’s like a HTTP server (404 not found, 403 unauthorized, that sort of thing.) Its also important to note (and I think Mark snow who used to be at IP expert for clearing this up in his VOD) that the UAC and UAS terminology you always see in SIP makes it sound way more complicated than it is: A UAC is just the “Calling” party and the UAS the called party. Simple as that.

All testing assumes a SIP trunk between a CUCM and a CUCME. Our CUCME has IP address 1.1.1.1 and binds all its SIP media to this address. Our CUCM has the IP address 10.0.0.252. Finally we have a phone with the IP Address 192.168.10.21 registered to our CUCM.

This part might look fairly obvious. We are SENDING an invite to sip:5008@10.0.0.252, one of the key things I wanted to point out in this was the “Sent” command you see at the top, it can get extremely tricky when debugging SIP working out who sent what message, this should help clarify things a little.

Via: SIP/2.0/UDP 1.1.1.1:5060;branch=z9hG4bK3F1C54

The “Via” message helps us work out what IP Address we are sending out FROM, here you can see we have bound our SIP messages to send out as 1.1.1.1 (we used the bind command in our config previously)so this is a great way to work out where exactly your SIP messages are being sourced from.

Here we run into one of those things that makes it tricky to read SIP, you see here that even though we generated this message (the invite message) we have our phone (911) listed as a REMOTE PARTY? Well, to the server (the UAS, the CUCM that we are calling) we ARE the remote party. So again, important to pay attention to that bit right at the top that tells you if your sending or receiving this message. You will also note since we have only just sent this message we don’t have the display name for the number we are calling (5008) shown yet. We also have a “tag” which helps us identify messages related to this call.

Date: Tue, 24 Aug 2010 14:10:45 GMT

Call-ID: 3910C333-AEC011DF-8248B9C0-9A07DD7B@1.1.1.1

Supported: 100rel,timer,resource-priority,replaces,sdp-anat

Min-SE:1800

The “Supported” keyword indicates the SIP features we support, in here we have timer refreshes and a few other bits and bobs. We also have a Min-SE which specifies our session interval and when it needs to be refreshed.

Here we are saying “This is the type of device I am” (user-agent) (essentially, although its not always the case) and the allow shows all the SIP methods that we understand and support. Subscribe for example indicates we support presence.

CSeq: 101 INVITE

Max-Forwards: 70

Timestamp: 1282659045

Contact:

Expires: 180

Here we can see that we are specifying a max forward, this says how many times we will allow this call to be forwarded (how many proxies or gateways in the path) we also have a Contact field, this tells the UAS where to send the message back to when its ready to send return messages.

Allow-Events: telephone-event

Supported: precondition

Content-Type: application/sdp

Content-Disposition: session;handling=required

Content-Length: 206

This is one of the more important parts of the messages and one of the least understood. In SIP some messages will contain SDP information (session description protocol) this is the information SIP that is actually used to control things like codec negotiation, dtmf-relay and also what IP addresses media should actually be sent to (this will become important later.)

v=0

o=CiscoSystemsSIP-GW-UserAgent 391 9124 IN IP4 1.1.1.1

s=SIP Call

c=IN IP4 1.1.1.1

t=0 0

a=rtr

m=audio 17922 RTP/AVP 0 19

c=IN IP4 1.1.1.1

a=rtpmap:0 PCMU/8000

a=rtpmap:19 CN/8000

a=ptime:20

We have a lot of confusing looking attributes here so lets try and go through as many as we can, the “C” attribute you can see listed here tells the system who initiated the call, this will come to be important later. The M indicates what codec we want to use, and the attributes specify our dtmf-relays.

Aug 24 14:10:45.899: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 100 Trying

Date: Tue, 24 Aug 2010 14:10:45 GMT

From: "PSTN Phone" ;tag=A844F80-1FF5

Allow-Events: presence

Content-Length: 0

To:

Call-ID: 3910C333-AEC011DF-8248B9C0-9A07DD7B@1.1.1.1

Via: SIP/2.0/UDP 1.1.1.1:5060;branch=z9hG4bK3F1C54

CSeq: 101 INVITE

Here you see we “RECEIVED” a message back from the other end, the content length is 0, indicating there is no SDP in this message. We also see that it is sending 200 trying, which essentially means its received our request. This is an important message: If the gateway does not receive this message after sending a 101 invite within the “Trying” timeout, it will retry X number of times and if no response is received will inform the gateway. These timers can be changed under SIP-ua with:

Sip-ua

Timers trying

Retry

!

You might need to do this if you have two CUCM’s as I posted in a previous blogpost.

Now we are getting a little further, The other end has successfully found the number we have rung and is proceeding to ring on the handset. This message will be the last message you see until someone picks up the handset, this message times out OR they ignore you, redirect you or heck they just answer the call, whatever the case may be. We can see here at this point that the remote end has also let us know what capabilities (sip methods) this device supports. The content length is again 0 indicating that no SDP is sent with this message.

This is what we have been waiting for! The handset has picked up so we have been sent a 200 OK message with important details for us to connect the media streams up with.

P-Asserted-Identity:

Supported: replaces

Supported: Geolocation

Remote-Party-ID: ;party=called;screen=yes;privacy=off

Content-Length: 155

Require:timer

To: ;tag=bb6a91cf-cec8-42ad-9aa3-7bda337c86c4-30307968

Contact:

Content-Type: application/sdp

Here we can see we have a content length of 155 indicating there is an SDP message waiting and a content-type of application/sdp, we also see above a keyword Supported: replaces, this is one of the many RFC extensions to SIP and is to do with conferencing, these all become more important as we perform call-forwards and other activities.

Call-ID: 4E4D2A57-AEC011DF-824EB9C0-9A07DD7B@1.1.1.1

Via: SIP/2.0/UDP 1.1.1.1:5060;branch=z9hG4bK4019BC

CSeq: 101 INVITE

Session-Expires:1800;refresher=uas

Here we see values for the session expire, 1800, indicating that a session refresh must occur during this time period. The responsibility of the refresher is also shown (the UAS)

v=0

o=CiscoSystemsCCM-SIP 2000 1 IN IP4 10.0.0.252

s=SIP Call

c=IN IP4 192.168.10.21

t=0 0

m=audio 22782 RTP/AVP 0

a=rtpmap:0 PCMU/8000

a=ptime:20

Here we see the SDP sent from the CUCM, as you can see we have less options in the RTP map, and we also have M for the media shown, you will also notice the c= IN IP4 showing the actual IP address of the handset itself. This is very important as this is where we will actually attempt to connect via RTP to. This address would change if you where using an MTP for example. Notice also the bit I have highlighted in red, this is the port number that the RTP will attempt to connect on. If you check the SDP we originally sent in the invite message this is our RTP port too

Aug 24 14:11:32.535: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Sent:

ACK sip:5008@10.0.0.252:5060 SIP/2.0

Via: SIP/2.0/UDP 1.1.1.1:5060;branch=z9hG4bK411AF4

From: "PSTN Phone" ;tag=A84DAAC-1371

To: ;tag=bb6a91cf-cec8-42ad-9aa3-7bda337c86c4-30307968

Date: Tue, 24 Aug 2010 14:11:21 GMT

Call-ID: 4E4D2A57-AEC011DF-824EB9C0-9A07DD7B@1.1.1.1

Max-Forwards: 70

CSeq: 101 ACK

Allow-Events: telephone-event

Content-Length: 0

We send an acknowledgement indicating we received the message and the rtp stream is setup between our two endpoints:

PeterCCIE18371#show voip rtp connection detail

VoIP RTP active connections :

No. CallIddstCallIdLocalRTP RmtRTP LocalIPRemoteIP

1220 21916950227821.1.1.1192.168.10.21

callId 220 (dir=2): called=5008 calling=911 redirect=

dest callId 219: called= calling=911 redirect=

1 context 6998C42C xmitFunc 60A2437C

Found 1 active RTP connections

As you can see the VOIP rtp connections match what we saw in the M output.

Finally here is an extremely useful command to confirm everything we have talked about here.

PeterCCIE18371#show sip-ua calls

SIP UAC CALL INFO

Call 1

SIP Call ID: A06260B3-AEC511DF-8260B9C0-9A07DD7B@1.1.1.1

State of the call: STATE_ACTIVE (7)

Substate of the call: SUBSTATE_NONE (0)

Calling Number: 911

Called Number: 5008

Bit Flags: 0xC04018 0x100 0x80

CC Call ID: 220

Source IP Address (Sig ): 1.1.1.1

Destn SIP Req Addr:Port : [10.0.0.252]:5060

Destn SIP Resp Addr:Port: [10.0.0.252]:5060

Destination Name: 10.0.0.252

Number of Media Streams : 1

Number of Active Streams: 1

RTP Fork Object: 0x0

Media Mode: flow-through

Media Stream 1

State of the stream: STREAM_ACTIVE

Stream Call ID: 220

Stream Type: voice-only (0)

Stream Media Addr Type: 1

Negotiated Codec: g711ulaw (160 bytes)

Codec Payload Type: 0

Negotiated Dtmf-relay: inband-voice

Dtmf-relay Payload Type: 0

Media Source IP Addr:Port: [1.1.1.1]:16950

Media Dest IP Addr:Port: [192.168.10.21]:21026

Options-PingENABLED:NOACTIVE:NO

Number of SIP User Agent Client(UAC) calls: 1

SIP UAS CALL INFO

Number of SIP User Agent Server(UAS) calls: 0

Now in our next example we have forwarded the call onto another number.

Hidden away in all of this, is where we have actually been transfered to, the P-preffered-Identity: shown above shows where the forward is sent, Can you see where we have been transferred to?

If you said 5111, good on you!

Aug 24 14:55:12.063: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 100 Trying

Via: SIP/2.0/UDP 10.0.0.252:5060;branch=z9hG4bK409c848218

From: ;tag=bb6a91cf-cec8-42ad-9aa3-7bda337c86c4-30307978

To: "PSTN Phone" ;tag=AA7B938-2302

Date: Tue, 24 Aug 2010 14:55:12 GMT

Call-ID: A06260B3-AEC511DF-8260B9C0-9A07DD7B@1.1.1.1

CSeq: 107 INVITE

Allow-Events: telephone-event

Server: Cisco-SIPGateway/IOS-12.x

Content-Length: 0

Again we have the extremely confusing thing where the “From: “ listed is actually a separate number to us, it’s very difficult to read if you look at this to try and determine which side has sent the message, use the Sent: or received at the very top to work out who sent what message. Here we are sending a 107 Invite which is a special type of message.

Here we are sending the CUCM our IP address and RTP stream that we will be listening on, the CUCM is responsible for relaying this information to the transferred-to party.

Aug 24 14:55:12.271: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

ACK sip:911@1.1.1.1:5060 SIP/2.0

Date: Tue, 24 Aug 2010 14:55:12 GMT

From: ;tag=bb6a91cf-cec8-42ad-9aa3-7bda337c86c4-30307978

Allow-Events: presence, kpml

Content-Length: 155

To: "PSTN Phone" ;tag=AA7B938-2302

Content-Type: application/sdp

Call-ID: A06260B3-AEC511DF-8260B9C0-9A07DD7B@1.1.1.1

Via: SIP/2.0/UDP 10.0.0.252:5060;branch=z9hG4bK40d3e3b89db

CSeq: 107 ACK

Max-Forwards: 70

v=0

o=CiscoSystemsCCM-SIP 2000 7 IN IP4 10.0.0.252

s=SIP Call

c=IN IP4 192.168.10.30

t=0 0

m=audio 64878 RTP/AVP 0

a=rtpmap:0 PCMU/8000

a=ptime:20

Here we received a message back telling us no problem and where we need to connect to with our RTP stream, can you work out where we will be connecting to?

Here is another hint if you can’t get it from the above:

PeterCCIE18371#show voip rtp connections

VoIP RTP active connections :

No. CallIddstCallIdLocalRTP RmtRTP LocalIPRemoteIP

122021916950648781.1.1.1192.168.10.30

Found 1 active RTP connections

We can finally do our show sip-ua calls for more info, note that annoyingly, even though our display on our phone has updated to indicate we are calling 5111, the number shown in the sip-ua calls is still 5008

PeterCCIE18371#show sip-ua calls

SIP UAC CALL INFO

Call 1

SIP Call ID: A06260B3-AEC511DF-8260B9C0-9A07DD7B@1.1.1.1

State of the call: STATE_ACTIVE (7)

Substate of the call: SUBSTATE_NONE (0)

Calling Number: 911

Called Number: 5008

Bit Flags: 0xC04018 0x10300 0x80

CC Call ID: 220

Source IP Address (Sig ): 1.1.1.1

Destn SIP Req Addr:Port : [10.0.0.252]:5060

Destn SIP Resp Addr:Port: [10.0.0.252]:5060

Destination Name: 10.0.0.252

Number of Media Streams : 1

Number of Active Streams: 1

RTP Fork Object: 0x0

Media Mode: flow-through

Media Stream 1

State of the stream: STREAM_ACTIVE

Stream Call ID: 220

Stream Type: voice-only (0)

Stream Media Addr Type: 1

Negotiated Codec: g711ulaw (160 bytes)

Codec Payload Type: 0

Negotiated Dtmf-relay: inband-voice

Dtmf-relay Payload Type: 0

QoS ID: -1

Local QoS Strength: BestEffort

Negotiated QoS Strength: BestEffort

Negotiated QoS Direction : SendRecv

Local QoS Status: None

Media Source IP Addr:Port: [1.1.1.1]:16950

Media Dest IP Addr:Port: [192.168.10.30]:64878

Options-PingENABLED:NOACTIVE:NO

Number of SIP User Agent Client(UAC) calls: 1

SIP UAS CALL INFO

Number of SIP User Agent Server(UAS) calls: 0

Super quickly, here is the output when we try and make a call to a number that is not actually registered to the CUCM:

There you have it, if you made it this far, well done! I am glad to see your dedication. Why don’t you try debugging with G.729, try with an MTP clicked on your CUCM trunk and you will see things like the IP address for the rtp stream changed, the RTP-map will change depending on what dtmf-relay you want to do and much more.

I think mimicking popular posts on other blogs is one of the best ways to get a good idea which will be popular.Such a lovely blog you have shared here with us. Really nice. Sydney Harbour Corporate Cruises provide Bucks party Sydney cruise and a private unique experience on Sydney harbour for all guests to enjoy.

extraordinary post, especially keen. I ask why another experts of the part genuinely never find this. You will longing to go on your making. I'm confident, you have a limitless perusers' establishment right now!hot woman dating

I think you are effectively right. I was satisfied starting late when I got one of our understudies say, "I like it here in light of the way that your not a pack of eggheads." We without a doubt enlist coaches who can add to a positive loving with the student.Nice to look at that such get prepared focuses are the spot to be, on the grounds that if all else fails, most understudies don't fit the course of action of get ready. Particularly now in the computerized time, schools require better ways to deal with oversee planning. A commitment of gratefulness is all together for the article.Réparation mobile