Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

SIP INVITE

Good morning,

Please, could you kindly help me with the following matter?

I have some questions regarding how CUCM builds some fields in a SIP INVITE message. Last week I was reviewing logs and I found the below R-URI when an extension calls another extension:

A number--> 7100 ---(1 SIP invite) ----> CUCM ---- (2 SIP invite) ----> B number 7101

1 SIP invite R-URI: sip:0@192.168.1.3; user=phone

2 SIP invite R-URI: sip:5ea27f5e-033b-880c-e304-0729574bfb1@192.168.1.2:51544;transport=tcp where

5ea27f5e-033b-880c-e304-0729574bfb1 is the user part.

I thought the first invite should be sip:7101@192.168.1.3; user=phone. Concerning the invite from CUCM to B number, how does CUCM build the user part from the B number?

Moreover, what are Contact ang tag fields  used for in a sip message? how does CUCM build them?

Thanks in advance.

Juan.

20 REPLIES
VIP Super Bronze

SIP INVITE

Delgado,

Some of your question will be answered in this document titled understanding sip traces..Please have a read.

https://supportforums.cisco.com/docs/DOC-27105

The request uri ideally will be to a valid extension but in cases where conferencing is involved, the r-uri is usally to some hexadecimal numbers similar to what you have posted.

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"

SIP INVITE

Hi Aokanlawon,

Thanks for your quick response.

I had already read this thread but i didn't find any info regarding the topics i have explained.

In the case i'm facing, conference is not involved, just a basic call between 2 extensions. I have analyzed the complete SIP message and there is no field in the first INVITE (from IP phone to CUCM) where the B number is considered (R-URI sip:0@CUCM IP), so, how CUCM knows where the call has to be progressed? Concerning the 2nd INVITE (from CUCM to IP phone), what does the number indicated (hexadecimal) in the R-URI mean?

Wrt Contact field, why sometimes shows "From" field (A number) and others the hex number?

Thanks,

Juan

VIP Super Bronze

SIP INVITE

Can you please attach the full trace

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"

Re: SIP INVITE

        Hi,

I cannot include the complete trace but a short piece. I hope this help to understand my question.

Thanks¡¡¡

Juan

VIP Super Bronze

SIP INVITE

since I didnt see the full INVITE sent by CUCM to IP Phone2, I can only assume that the INVITE was sent using the contact header rather than the AOR (address of record)

The Contact header says where you are (or rather, where your User Agent is), while the From header says who you are.

You might have several SIP devices all registered to the same Address of Record (the URI you put in the From header).

Further, REGISTER requests use Contact headers to maintain SIP's location service: they let a user agent update a registrar's location information..

Can you check if the contact header for IP Phone 2 matches what you have in the request uri..

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"

SIP INVITE

Hi Aokanlawon,

I have not understood your answer.

I have noticed 2 unexpected behaviours:

- SIP INVITE between IP phone1 and CUCM. R-URI is sent in a strange format (0@CUCM-IP) instead of using B number to complete the R-URI. Why?

- SIP INVITE between CUCM and IP phone2. R-URI is built by adding a large string without sense for me. Why?

In both cases, Contact Header shows A number details. My question regarding Contact Header is why sometimes is complete with a large string as well instead of A number/extension.

BR,

Juan

VIP Super Bronze

SIP INVITE

What version of CUCM is this?

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"

SIP INVITE

CUCM version 8.6.2

VIP Super Bronze

Re: SIP INVITE

I dont know whats going on there..My CUCM 8.6.2 shows the logs in the proper format

INVITE sip:907666930701@10.10.10.32:5060 SIP/2.0

Via: SIP/2.0/UDP 10.10.0.11:5060;branch=z9hG4bK2342979336fbf

From: "Strand" <02065543200>;tag=144360~ffa80926-5fac-4dd6-b405-2dbbc56ae9a2-392166051

To: <907666930701>

Date: Mon, 20 May 2013 15:20:16 GMT

--

--

--

User-Agent: Cisco-CUCM8.6

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
Cisco Employee

Re: SIP INVITE

Hi Juan,

     I can answer the second question for you now:

> When a SIP Phone registered with the CUCM makes a calls, the Contact URI is the PKID; the hex value which the CCM application uses to store PID ( Process Identifiers ) in the database.

To answer your second questions, I need you to let me know if when dialing phone B, were you making an enbloc call or digit by digit?

Regards,

Jagpreet

Re: SIP INVITE

Hi Jagpreet,

I dial the number digit by digit.

Br,

Juan

VIP Super Bronze

SIP INVITE

+5 Jagpreet..I missed the point that these are sip phones

Juan,

If you look down into the trace you will see the remainder of the dialled digits. This is expected with sip phones. Just as with SCCP phones you will see the digits dialled one by one and cucm performing digit analysis. It is very similar. I am sure down in the remainder of the logs you will see the remaining digits dialled..I missed the fact that it was a sip phone

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"

Re: SIP INVITE

Sorry Aokanlawon, I cannot find the dialed digits in the trace. This is what puzzles me. In the original SIP I only find the A number (82052015) and the R-URI and To header completed with a "0". I supposed that perhaps the caller had pressed Recall button, but no. I have dialed B number digit by digit getting the same result.

Jagpreet & Aokanlawon, your help is much appreciate.

Juan

Cisco Employee

Re: SIP INVITE

Juan,

     A complete set of CCM SDI and SDL traces would be helpful here if you can upload it for a test call.

I shall look into this otherwise as well.

Regards,

Jagpreet

Re: SIP INVITE

Hi Jagpreet,

I cannot upload SDI/SDL traces but please, let me know anything I should check on logs in order to clarify/understand the behaviour described above.

Thanks,

Juan.

VIP Super Bronze

SIP INVITE

Look for the call-ID for this invite and use it to trace through the logs...You will see the remianing digits dialled somewhere in there

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"

SIP INVITE

Hi...again... :-)

I have retested the case, and now, the INVITE from IP phone (A number) to CUCM is not 0@device IP but 8@device IP. I have gathered logs and after the INVITE, the device sends a NOTIFY, where I cannot see the B number, but CUCM makes the digit analysis of the B number (i don't know where it catchs the info) and progress the call.

Have you ever seen this behaviour?

Thanks,

Juan

VIP Super Bronze

SIP INVITE

Juan,

I will explain how a sip phone signals to CUCM when making a call...Two major things happen

1. The first digit dialled is sent in the INVITE

2. The remaining digits are sent via NOTIFY (in the NOTIFY, you will see the digits that are dialled

The trace below details what happens when a sip phone makes a call. I stopped this trace after digit=8 was dialled

Called number=918772888362

Here we get INVITE with SDP from the sip phone to CUCM

29/2010 10:36:33.771 |//SIP/SIPTcp/wait_SdlReadRsp: Incoming SIP TCP message from 172.18.159.152 on port

51682 index 2321 with 1717 bytes:

INVITE sip:9@172.18.106.59;user=phone SIP/2.0 (first digit dialled =9)

Via: SIP/2.0/TLS 172.18.159.152:51682;branch=z9hG4bK1636ab61

From: "Test User 1" <89919236>;tag=00260bd9669e07147bcb3aac-3cda8f0c

To: <9>

Call-ID: 00260bd9-669e000b-588c0c2b-2193e2a3@172.18.159.152

Max-Forwards: 70

Date: Mon, 29 Mar 2010 14:36:33 GMT

CSeq: 101 INVITE

User-Agent: Cisco-CP9951/9.0.1

Contact: <4A8A8F91-609E-D655-19EA-44EEDCD7B0D6>

Expires: 180

Accept: application/sdp

Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE,INFO

Remote-Party-ID: "Test User 1" <89919236>;party=calling;id-type=subscriber;privacy=off;screen=yes

Supported: replaces,join,sdp-anat,norefersub,extended-refer,X-cisco-callinfo,X-cisco-serviceuri,X-cisco-escapecodes,Xcisco-

service-control,X-cisco-srtp-fallback,X-cisco-monrec,X-cisco-config,X-cisco-sis-5.0.0,X-cisco-xsi-9.0.1

Allow-Events: kpml,dialog

Content-Length: 632

Content-Type: application/sdp

Content-Disposition: session;handling=optional

v=0

o=Cisco-SIPUA 26964 0 IN IP4 172.18.159.152

s=SIP Call

t=0 0

m=audio 29254 RTP/SAVP 0 8 18 102 9 116 124 101

c=IN IP4 172.18.159.152

a=crypto:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:18 G729/8000

a=fmtp:18 annexb=no

a=rtpmap:102 L16/16000

a=rtpmap:9 G722/8000

a=rtpmap:116 iLBC/8000

a=fmtp:116 mode=20

a=rtpmap:124 ISAC/16000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=sendrecv

m=video 25466 RTP/AVP 97

c=IN IP4 172.18.159.152

b=TIAS:1000000

a=rtpmap:97 H264/90000

a=fmtp:97 profile-level-id=42801E

a=recvonly

+++Next CUCM sends trying++++

03/29/2010 10:36:33.773 |//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to 172.18.159.152 on port

51682 index 2321

SIP/2.0 100 Trying

Via: SIP/2.0/TLS 172.18.159.152:51682;branch=z9hG4bK1636ab61

From: "Test User 1" <89919236>;tag=00260bd9669e07147bcb3aac-3cda8f0c

To: <9>

Date: Mon, 29 Mar 2010 14:36:33 GMT

Call-ID: 00260bd9-669e000b-588c0c2b-2193e2a3@172.18.159.152

CSeq: 101 INVITE

Allow-Events: presence

Content-Length: 0

+++++Unified CM Sends a REFER to play Outside Dialtone++++

03/29/2010 10:36:33.780 |//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to 172.18.159.152 on port 51682

index 2321

REFER sip:89919236@172.18.159.152:51682 SIP/2.0

Via: SIP/2.0/TLS 172.18.106.59:5061;branch=z9hG4bK151511c5f04bf

From: <89919236>;tag=2144536187

To: <89919236>

Call-ID: 7747f400-bb01baf1-14685-3b6a12ac@172.18.106.59

CSeq: 101 REFER

Max-Forwards: 70

Contact: <89919236>

User-Agent: Cisco-CUCM8.0

Expires: 0

Refer-To: cid:1234567890@172.18.106.59

Content-Id: <1234567890@172.18.106.59>

Require: norefersub

Content-Type: application/x-cisco-remotecc-request+xml

Referred-By: <89919236>

Content-Length: 409

00260bd9-669e000b-588c0c2b-2193e2a3@172.18.159.152

97903bc0-a3de-4a15-ba27-44c81fe3adcd-45510542

00260bd9669e07147bcb3aac-3cda8f0c

DtOutsideDialTone

user

++++Unified CM Sends a SUBSCRIBE for KPML++++

03/29/2010 10:36:33.781 |//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to 172.18.159.152 on port 51682 index 2321

SUBSCRIBE sip:89919236@172.18.159.152:51682 SIP/2.0

Via: SIP/2.0/TLS 172.18.106.59:5061;branch=z9hG4bK1515232b4e84f

From: <9>;tag=1976165806

To: <89919236>

Call-ID: 7747f400-bb01baf1-14686-3b6a12ac@172.18.106.59

CSeq: 101 SUBSCRIBE

Date: Mon, 29 Mar 2010 14:36:33 GMT

User-Agent: Cisco-CUCM8.0

Event: kpml; call-id=00260bd9-669e000b-588c0c2b-2193e2a3@172.18.159.152; from-tag=00260bd9669e07147bcb3aac-3cda8f0c

Expires: 7200

Contact: <9>

Accept: application/kpml-response+xml

Max-Forwards: 70

Content-Type: application/kpml-request+xml

Content-Length: 424

http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="urn:ietf:params:xml:ns:kpml-request kpml-request.xsd" version="1.0">

[x#*+]|bs

++++ Phone Sends 200 OK for the REFER and SUBSCRIBE ++++

03/29/2010 10:36:33.802 |//SIP/SIPTcp/wait_SdlReadRsp: Incoming SIP TCP message from 172.18.159.152 on port 51682 index 2321 with 453

bytes:

SIP/2.0 200 OK

Via: SIP/2.0/TLS 172.18.106.59:5061;branch=z9hG4bK151511c5f04bf

From: <89919236>;tag=2144536187

To: <89919236>;tag=00260bd9669e07167c743311-343ee3af

Call-ID: 7747f400-bb01baf1-14685-3b6a12ac@172.18.106.59

Date: Mon, 29 Mar 2010 14:36:33 GMT

CSeq: 101 REFER

Server: Cisco-CP9951/9.0.1

Contact: <4A8A8F91-609E-D655-19EA-44EEDCD7B0D6>

Content-Length: 0

Phone Sends 200 OK for the REFER and SUBSCRIBE

03/29/2010 10:36:33.843 |//SIP/SIPTcp/wait_SdlReadRsp: Incoming SIP TCP message from 172.18.159.152 on port

51682 index 2321 with 465 bytes:

SIP/2.0 200 OK

Via: SIP/2.0/TLS 172.18.106.59:5061;branch=z9hG4bK1515232b4e84f

From: <9>;tag=1976165806

To: <89919236>;tag=00260bd9669e07177ee0d51d-14f56f89

Call-ID: 7747f400-bb01baf1-14686-3b6a12ac@172.18.106.59

Date: Mon, 29 Mar 2010 14:36:33 GMT

CSeq: 101 SUBSCRIBE

Server: Cisco-CP9951/9.0.1

Contact: <4A8A8F91-609E-D655-19EA-44EEDCD7B0D6>

Expires: 7200

Content-Length: 0

03/29/2010 10:36:33.843 |//SIP/SIPTcp/wait_SdlReadRsp: Incoming SIP TCP message from 172.18.159.152 on port

51682 index 2321 with 465 bytes:

SIP/2.0 200 OK

Via: SIP/2.0/TLS 172.18.106.59:5061;branch=z9hG4bK1515232b4e84f

From: <9>;tag=1976165806

To: <89919236>;tag=00260bd9669e07177ee0d51d-14f56f89

Call-ID: 7747f400-bb01baf1-14686-3b6a12ac@172.18.106.59

Date: Mon, 29 Mar 2010 14:36:33 GMT

CSeq: 101 SUBSCRIBE

Server: Cisco-CP9951/9.0.1

Contact: <4A8A8F91-609E-D655-19EA-44EEDCD7B0D6>

Expires: 7200

Content-Length: 0

Unified CM Sends a SUBSCRIBE for KPML

220

++++User Dials a ‘1’, phone sends a NOTIFY to CUCM for the digit++++

NOTIFY sip:9@172.18.106.59:5061 SIP/2.0

Via: SIP/2.0/TLS 172.18.159.152:51682;branch=z9hG4bK1cd529ba

To: <9>;tag=1976165806

From: <89919236>;tag=00260bd9669e07177ee0d51d-14f56f89

Call-ID: 7747f400-bb01baf1-14686-3b6a12ac@172.18.106.59

Date: Mon, 29 Mar 2010 14:36:33 GMT

CSeq: 1001 NOTIFY

Event: kpml

Subscription-State: active; expires=7200

Max-Forwards: 70

Contact: <4A8A8F91-609E-D655-19EA-44EEDCD7B0D6>

Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE

Content-Length: 209

Content-Type: application/kpml-response+xml

Content-Disposition: session;handling=required

forced_flush="false" digits="1" tag="Backspace OK"/>

+++Unified CM Replies to NOTIFY With a 200 OK++++

03/29/2010 10:36:34.352 |//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to 172.18.159.152 on port 51682

index 2321

SIP/2.0 200 OK

Via: SIP/2.0/TLS 172.18.159.152:51682;branch=z9hG4bK1cd529ba

From: <89919236>;tag=00260bd9669e07177ee0d51d-14f56f89

To: <9>;tag=1976165806

Date: Mon, 29 Mar 2010 14:36:34 GMT

Call-ID: 7747f400-bb01baf1-14686-3b6a12ac@172.18.106.59

CSeq: 1001 NOTIFY

Content-Length: 0

++++Unified CM Replies Sends a REFER to Disable Outside Dialtone+++

03/29/2010 10:36:34.353 |//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to 172.18.159.152 on port 51682

index 2321

REFER sip:89919236@172.18.159.152:51682 SIP/2.0

Via: SIP/2.0/TLS 172.18.106.59:5061;branch=z9hG4bK151536ea86ab0

From: <89919236>;tag=1574166193

To: <89919236>

Call-ID: 77e08a80-bb01baf2-14687-3b6a12ac@172.18.106.59

CSeq: 101 REFER

Max-Forwards: 70

Contact: <89919236>

User-Agent: Cisco-CUCM8.0

Expires: 0

Refer-To: cid:1234567890@172.18.106.59

Content-Id: <1234567890@172.18.106.59>

Require: norefersub

Content-Type: application/x-cisco-remotecc-request+xml

Referred-By: <89919236>

Content-Length: 401

00260bd9-669e000b-588c0c2b-2193e2a3@172.18.159.152

97903bc0-a3de-4a15-ba27-44c81fe3adcd-45510542

00260bd9669e07147bcb3aac-3cda8f0c

Dt_NoTone

user

+++Phone Replies With 200 OK to REFER++++

03/29/2010 10:36:34.402 |//SIP/SIPTcp/wait_SdlReadRsp: Incoming SIP TCP message from 172.18.159.152 on port

51682 index 2321 with 453 bytes:

SIP/2.0 200 OK

Via: SIP/2.0/TLS 172.18.106.59:5061;branch=z9hG4bK151536ea86ab0

From: <89919236>;tag=1574166193

To: <89919236>;tag=00260bd9669e07184b08b96b-796ab86f

Call-ID: 77e08a80-bb01baf2-14687-3b6a12ac@172.18.106.59

Date: Mon, 29 Mar 2010 14:36:33 GMT

CSeq: 101 REFER

Server: Cisco-CP9951/9.0.1

Contact: <4A8A8F91-609E-D655-19EA-44EEDCD7B0D6>

Content-Length: 0

++++User Dials a ‘8’, phone sends a NOTIFY to CUCM+++

03/29/2010 10:36:34.944 |//SIP/SIPTcp/wait_SdlReadRsp: Incoming SIP TCP message from 172.18.159.152 on port

51682 index 2321 with 896 bytes:

NOTIFY sip:9@172.18.106.59:5061 SIP/2.0

Via: SIP/2.0/TLS 172.18.159.152:51682;branch=z9hG4bK647d03c1

To: <9>;tag=1976165806

From: <89919236>;tag=00260bd9669e07177ee0d51d-14f56f89

Call-ID: 7747f400-bb01baf1-14686-3b6a12ac@172.18.106.59

Date: Mon, 29 Mar 2010 14:36:34 GMT

CSeq: 1002 NOTIFY

Event: kpml

Subscription-State: active; expires=7195

Max-Forwards: 70

Contact: <4A8A8F91-609E-D655-19EA-44EEDCD7B0D6>

Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE

Content-Length: 209

Content-Type: application/kpml-response+xml

Content-Disposition: session;handling=required

forced_flush="false" digits="8" tag="Backspace OK"/>

+++Unified CM Replies to NOTIFY With a 200 OK+++

03/29/2010 10:36:34.352 |//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to 172.18.159.152 on port 51682

index 2321

SIP/2.0 200 OK

Via: SIP/2.0/TLS 172.18.159.152:51682;branch=z9hG4bK1cd529ba

From: <89919236>;tag=00260bd9669e07177ee0d51d-14f56f89

To: <9>;tag=1976165806

Date: Mon, 29 Mar 2010 14:36:34 GMT

Call-ID: 7747f400-bb01baf1-14686-3b6a12ac@172.18.106.59

CSeq: 1001 NOTIFY

Content-Length: 0

As you can see this is similar to what you are seeing...The first digit dialled is seen in the INVITE, the remaining digits will be seen in NOTIFY.

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"

SIP INVITE

Many thanks¡¡¡

Just the last question. Is it the normal procedure? I mean, I have noticed this behaviour but not in all the calls so, is it known when CUCM follows this method or when the device sends all the digits in the first INVITE?

Thanks again Jagpreet and Aokanlawon

Juan

VIP Super Bronze

SIP INVITE

If you dial the digit one by one..It will follow this method..If you do a redial where the digits are mostly sent enblock then you might not see this.. You will see an INVITE to the full number, since the phone is not doing a digit by digit dialling.

You can mark the thread as aswered to help others identify the correct responses in the future

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
930
Views
15
Helpful
20
Replies