11-04-2013 05:47 AM - edited 03-16-2019 08:13 PM
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.
11-06-2013 03:50 AM
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.
11-06-2013 04:23 AM
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"
11-07-2013 01:32 AM
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
11-07-2013 02:29 AM
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-3cda8f0c89919236>
To: <9>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>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=yes89919236>
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-3cda8f0c89919236>
To: <9>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=214453618789919236>
To: <89919236>89919236>
Call-ID: 7747f400-bb01baf1-14685-3b6a12ac@172.18.106.59
CSeq: 101 REFER
Max-Forwards: 70
Contact: <89919236>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>89919236>
Content-Length: 409
++++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=19761658069>
To: <89919236>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>9>
Accept: application/kpml-response+xml
Max-Forwards: 70
Content-Type: application/kpml-request+xml
Content-Length: 424
xsi:schemaLocation="urn:ietf:params:xml:ns:kpml-request kpml-request.xsd" version="1.0">
++++ 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=214453618789919236>
To: <89919236>;tag=00260bd9669e07167c743311-343ee3af89919236>
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>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=19761658069>
To: <89919236>;tag=00260bd9669e07177ee0d51d-14f56f8989919236>
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>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=19761658069>
To: <89919236>;tag=00260bd9669e07177ee0d51d-14f56f8989919236>
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>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=19761658069>
From: <89919236>;tag=00260bd9669e07177ee0d51d-14f56f8989919236>
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>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-14f56f8989919236>
To: <9>;tag=19761658069>
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=157416619389919236>
To: <89919236>89919236>
Call-ID: 77e08a80-bb01baf2-14687-3b6a12ac@172.18.106.59
CSeq: 101 REFER
Max-Forwards: 70
Contact: <89919236>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>89919236>
Content-Length: 401
+++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=157416619389919236>
To: <89919236>;tag=00260bd9669e07184b08b96b-796ab86f89919236>
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>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=19761658069>
From: <89919236>;tag=00260bd9669e07177ee0d51d-14f56f8989919236>
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>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-14f56f8989919236>
To: <9>;tag=19761658069>
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"
11-07-2013 03:00 AM
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
11-07-2013 03:05 AM
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"
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide