02-14-2015 07:39 AM - edited 03-17-2019 01:58 AM
So today I create a sip based ip communicator and pressed the new call button and heard a dial tone. I started typing my telephone number. Half way through, I heard another secondary dial tone (which indicates mis-configured route pattern somewhere) .
However, When I look at the call manager logs, I do not actually see the digits that I was typing. With SCCP, I can see the keypad button press messages in the traces, but here, I cannot see the pressed buttons in my CUCM traces. Can anyone help with telling me how I can see button presses going to call manager . All I can see are the logs below which came up as soon as I got the dial tone and the final sip invite messages. I see nothing in-between.
_____________________________
__________________
|SIPTcp - wait_SdlReadRsp: Incoming SIP TCP message from 10.xx.4.xx on port 56714 index 31809 with 973 bytes:
[6387070,NET]
NOTIFY sip:37184@172.5.x.xx SIP/2.0
Via: SIP/2.0/TCP 10.x.x.66:56714;branch=z9hG4bK00005b1e
To: <sip:37184@17.x.22.xx>
From: <sip:37184@172.x.22.xx>;tag=00ffb00bc50a00340000499f-00006ab4
Call-ID: 00001ab1-0000728b@10.1.2.26
Date: Sat, 14 Feb 2015 14:17:40 GMT
CSeq: 19 NOTIFY
Event: dialog
Subscription-State: active
Max-Forwards: 70
Contact: <sip:ee8b88d5-808c-5446-dac3-92e6077441a0@10.1.x.xx:56714;transport=TCP>
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE
Content-Length: 350
Content-Type: application/dialog-info+xml
Content-Disposition: session;handling=required
<?xml version="1.0" encoding="UTF-8" ?>
<dialog-info xmlns:call="urn:x-cisco:parmams:xml:ns:dialog-info:dialog:callinfo-dialog" version="18" state="partial" entity="sip:37000@10.5.2.xx">
<dialog id="12" call-id="00ffb00b-c50a000e-00004bfe-00004aef@10.xx.1.xx" local-tag="00ffb00bc50a003300006390-00002d4f"><state>trying</state></dialog>
</dialog-info>
______________________________
SIPStationD(12991) - processCommonDialogNotifyInd: Did 12 Sending Notified SIPOffHook to new Cdfc
02-14-2015 09:45 AM
Hi Serenity
Sip phones use NOTIFY in cucm to relay digits to cucm. This is similar to the keypadbutton event on sccp phones. A NOTIFY is generated for each button or digit pressed. From the trace above I can seebthe NOTIFY showing the digits 37184
02-14-2015 12:05 PM
Yes,
I see that notify for my presence state change in my logs but in the same logs, I see no further notify messages for my button presses. This is really odd.
02-14-2015 12:40 PM
Can you attach the full cucm traces? Which cucm version is this? If its <9.X then please send the SDI traces, otherwise send the SDL traces
02-14-2015 04:31 PM
Do you have a personal email.
02-14-2015 04:36 PM
I do but that is not encouraged on the forum so others can benefit from the discussions
02-14-2015 08:56 PM
well I have just made a sip call with my ipcc and i did see all my digits in the trace. just a different process from sccp really- with the kplm subscription after the first digit etc. Using what you said and a little patience, I saw everything. I will now check the client trace and hopefully what i have learnt will help.
Cheers
02-16-2015 02:33 PM
Here is a more detailed explanation of how SIP calls notify cucm when they go off hook to make a call. The digit dialled here is 4080
+++++ Analysis of SIP Phone making a call +++++++++
The user picks up the phone and the IP Phone sends a NOTIFY to CUCM to indicate the start of a new dialog. This dialog begings by an offhook event
00869539.002 |14:58:13.837 |AppInfo |SIPTcp - wait_SdlReadRsp: Incoming SIP TCP message from 10.50.16.1 on port 52910 index 2748 with 976 bytes:
[46240,NET]
NOTIFY sip:9106@10.28.132.111 SIP/2.0
Via: SIP/2.0/TCP 10.50.16.1:52910;branch=z9hG4bK00002531
To: <sip:9106@10.28.132.111>
From: <sip:9106@10.28.132.111>;tag=544e42f26d0b001e000056e7-0000311c
Call-ID: 00001f54-00003e14@10.50.16.1
Date: Mon, 16 Feb 2015 12:58:13 GMT
CSeq: 11 NOTIFY
Event: dialog
Subscription-State: active
Max-Forwards: 70
Contact: <sip:2b75b6a4-32c6-3ef1-d677-d9b56d34e469@10.50.16.1:52910;transport=TCP>
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE
Content-Length: 350
Content-Type: application/dialog-info+xml
Content-Disposition: session;handling=required
<?xml version="1.0" encoding="UTF-8" ?>
<dialog-info xmlns:call="urn:x-cisco:parmams:xml:ns:dialog-info:dialog:callinfo-dialog" version="10" state="partial" entity="sip:9106@10.50.16.1">
<dialog id="6" call-id="544e42f2-6d0b000a-000037bc-00004d00@10.50.16.1" local-tag="544e42f26d0b001d00007cc9-000044a3"><state>trying</state></dialog>
</dialog-info>
++++ CUCM SIP stack processes the new connection for the phone+++++++
00869540.001 |14:58:13.837 |AppInfo |//SIP/Stack/Info/0x0/ccsip_process_sipspi_queue_event: ccsip_spi_get_msg_type returned: 2 (SIP_NETWORK_MSG), for event 1 (SIPSPI_EV_NEW_MESSAGE)
00869540.002 |14:58:13.837 |AppInfo |//SIP/Stack/Transport/0x0/sipTransportProcessNWNewConnMsg: context=(nil)
00869540.003 |14:58:13.837 |AppInfo |//SIP/Stack/Transport/0x0/sipConnectionManagerProcessNewConnMsg: gConnTab=0xe81c0d70, addr=10.50.16.1, port=52910, connid=2748, transport=TCP
++++ Next CUCM allocates a call id for this call +++++
00869546.002 |14:58:13.838 |AppInfo |LineControl(66) - Get call instance=1 for CI=24419584
+++Next CUCM sends a 200 OK to the NOTIFY request for the new dialog ++++
00869555.007 |14:58:13.839 |AppInfo |//SIP/Stack/Transport/0x0xe7df4d48/sipTransportPostSendMessage: Posting send for msg=0xefbe9910, addr=10.50.16.1, port=52910, connId=2748 for
00869555.008 |14:58:13.839 |AppInfo |//SIP/Stack/Info/0x0/act_dialog_pending_resp_event: Changing from State: SUBSCRIBE_STATE_DIALOG_PENDING to state SUBSCRIBE_STATE_ACTIVE
00869556.000 |14:58:13.839 |SdlSig |SIPSPISignal |wait |SIPTcp(1,100,71,1) |SIPHandler(1,100,79,1) |1,100,14,31314.75^10.50.16.1^SEP00909E9D106C |*TraceFlagOverrode
00869556.001 |14:58:13.839 |AppInfo |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 10.50.16.1 on port 52910 index 2748
[46241,NET]
SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.50.16.1:52910;branch=z9hG4bK00002531
From: <sip:9106@10.28.132.111>;tag=544e42f26d0b001e000056e7-0000311c
To: <sip:9106@10.28.132.111>;tag=1822746380
Date: Mon, 16 Feb 2015 12:58:13 GMT
Call-ID: 00001f54-00003e14@10.50.16.1
CSeq: 11 NOTIFY
Server: Cisco-CUCM10.5
Content-Length: 0
++++ The IP Phone sends its connection ID to CUCM, its ip address and its port number+++++++++
00869541.001 |14:58:13.838 |AppInfo |SIPStationInit: connID=2748, SEP00909E9D106C, 10.50.16.1:52910, Routed signal by connection index to (1,100,73,66)
++++ Next CUCM informs us that the NOTIFY message is for an offhook event ++++++
00869542.003 |14:58:13.838 |AppInfo |SIPStationD(66) - processCommonDialogNotifyInd: Notified Dialogs - Did 6 State trying
00869542.004 |14:58:13.838 |AppInfo |SIPStationD(66) - processCommonDialogNotifyInd: Did 6 Sending Notified SIPOffHook to new Cdfc
--
00869542.010 |14:58:13.838 |AppInfo |SIPStationD(66) - processSIPOffHook Primary Call Not-Found
00869543.000 |14:58:13.838 |SdlSig |SIPOffHookInd
+++ The next thing is the USER dials a digit on the phone ++++++
This is where it gets a little complicated. So lets examine this. The first digit that is dialled generates an INVITE to CUCM like this:
In this example the user dialled "4" first so we see an "INVITE sip:4@host-IP"
00869559.002 |14:58:14.064 |AppInfo |SIPTcp - wait_SdlReadRsp: Incoming SIP TCP message from 10.50.16.1 on port 52910 index 2748 with 1445 bytes:
[46242,NET]
INVITE sip:4@10.28.132.111;user=phone SIP/2.0
Via: SIP/2.0/TCP 10.50.16.1:52910;branch=z9hG4bK000015ec
From: "Emre ESEN" <sip:9106@10.28.132.111>;tag=544e42f26d0b001d00007cc9-000044a3
To: <sip:4@10.28.132.111;user=phone>
Call-ID: 544e42f2-6d0b000a-000037bc-00004d00@10.50.16.1
Max-Forwards: 70
Date: Mon, 16 Feb 2015 12:58:14 GMT
CSeq: 101 INVITE
User-Agent: Cisco-SIPIPCommunicator/9.1.1
Contact: <sip:2b75b6a4-32c6-3ef1-d677-d9b56d34e469@10.50.16.1:52910;transport=tcp>
Expires: 180
Accept: application/sdp
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE,INFO
Remote-Party-ID: "Emre ESEN" <sip:9106@10.28.132.111>;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,X-cisco-service-control,X-cisco-srtp-fallback,X-cisco-monrec,X-cisco-config,X-cisco-sis-5.1.0,X-cisco-xsi-8.5.1
Allow-Events: kpml,dialog
Content-Length: 373
Content-Type: application/sdp
Content-Disposition: session;handling=optional
v=0
o=Cisco-SIPUA 21020 0 IN IP4 10.50.16.1
s=SIP Call
t=0 0
m=audio 20250 RTP/AVP 0 8 18 9 116 124 101
c=IN IP4 10.50.16.1
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
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
+++++ NEXT CUCM sends a trying for the INVITE it received +++++++++++
00869562.001 |14:58:14.065 |AppInfo |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 10.50.16.1 on port 52910 index 2748
[46243,NET]
SIP/2.0 100 Trying
Via: SIP/2.0/TCP 10.50.16.1:52910;branch=z9hG4bK000015ec
From: "Emre ESEN" <sip:9106@10.28.132.111>;tag=544e42f26d0b001d00007cc9-000044a3
To: <sip:4@10.28.132.111;user=phone>
Date: Mon, 16 Feb 2015 12:58:14 GMT
Call-ID: 544e42f2-6d0b000a-000037bc-00004d00@10.50.16.1
CSeq: 101 INVITE
Allow-Events: presence
Content-Length: 0
++++NOW CUCM evaluates the DTMF supported by the phone to determine how to inform the phones to send the remaining dtmf digits++++
From the INVITE cucm concludes that KPML and rtp-nte is supported
00869566.009 |14:58:14.066 |AppInfo |setEndpointsDtmfCaps: KPML Supported.
00869566.010 |14:58:14.066 |AppInfo |setEndpointsDtmfCaps: Detected inband DTMF support
Next CUCM generates kpml event pkg which is going to be used to receive the remaining digits from the phone
00869590.001 |14:58:14.067 |AppInfo |SIPEventPkg::SIPEventPkg 0xe4a1d1e0 scbId[16725], event name[kpml; call-id=544e42f2-6d0b000a-000037bc-00004d00@10.50.16.1; from-tag=544e42f26d0b001d00007cc9-000044a3], id[]
+++ Next CUCM sends a SUBSCRIBE to the IP phone for kpml event +++++
00869594.001 |14:58:14.068 |AppInfo |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 10.50.16.1 on port 52910 index 2748
[46244,NET]
SUBSCRIBE sip:9106@10.50.16.1:52910 SIP/2.0
Via: SIP/2.0/TCP 10.28.132.111:5060;branch=z9hG4bKce719b37856
From: <sip:4@10.28.132.111>;tag=480227084
To: <sip:9106@10.50.16.1>
Call-ID: 768fbc80-4e11e966-bed-6f841c0a@10.28.132.111
CSeq: 101 SUBSCRIBE
Date: Mon, 16 Feb 2015 12:58:14 GMT
User-Agent: Cisco-CUCM10.5
Event: kpml; call-id=544e42f2-6d0b000a-000037bc-00004d00@10.50.16.1; from-tag=544e42f26d0b001d00007cc9-000044a3
Expires: 7200
Contact: <sip:4@10.28.132.111:5060;transport=tcp>
Accept: application/kpml-response+xml
Max-Forwards: 70
Content-Type: application/kpml-request+xml
Content-Length: 424
<?xml version="1.0" encoding="UTF-8" ?>
<kpml-request xmlns="urn:ietf:params:xml:ns:kpml-request" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:kpml-request kpml-request.xsd" version="1.0">
<pattern criticaldigittimer="1000" extradigittimer="500" interdigittimer="15000" persist="persist">
<regex tag="Backspace OK">[x#*+]|bs</regex>
</pattern>
</kpml-request>
+++ Next we get a 200 OK to the SUBSCRIBE from the ip phone ++++
00869595.002 |14:58:14.118 |AppInfo |SIPTcp - wait_SdlReadRsp: Incoming SIP TCP message from 10.50.16.1 on port 52910 index 2748 with 459 bytes:
[46245,NET]
SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.28.132.111:5060;branch=z9hG4bKce719b37856
From: <sip:4@10.28.132.111>;tag=480227084
To: <sip:9106@10.50.16.1>;tag=544e42f26d0b001f0000092c-0000070a
Call-ID: 768fbc80-4e11e966-bed-6f841c0a@10.28.132.111
Date: Mon, 16 Feb 2015 12:58:14 GMT
CSeq: 101 SUBSCRIBE
Server: Cisco-SIPIPCommunicator/9.1.1
Contact: <sip:2b75b6a4-32c6-3ef1-d677-d9b56d34e469@10.50.16.1:52910;transport=TCP>
Expires: 7200
Content-Length: 0
+++ NEXT the IP phones sends the remaining digit dialled on the phone to CUCM +++
00869603.002 |14:58:14.183 |AppInfo |SIPTcp - wait_SdlReadRsp: Incoming SIP TCP message from 10.50.16.1 on port 52910 index 2748 with 573 bytes:
[46247,NET]
NOTIFY sip:4@10.28.132.111:5060 SIP/2.0
Via: SIP/2.0/TCP 10.50.16.1:52910;branch=z9hG4bK000045c8
To: <sip:4@10.28.132.111>;tag=480227084
From: <sip:9106@10.50.16.1>;tag=544e42f26d0b001f0000092c-0000070a
Call-ID: 768fbc80-4e11e966-bed-6f841c0a@10.28.132.111
Date: Mon, 16 Feb 2015 12:58:14 GMT
CSeq: 1000 NOTIFY
Event: kpml
Subscription-State: active; expires=7200
Max-Forwards: 70
Contact: <sip:2b75b6a4-32c6-3ef1-d677-d9b56d34e469@10.50.16.1:52910;transport=TCP>
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE
Content-Length: 0
00869608.001 |14:58:14.183 |AppInfo |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 10.50.16.1 on port 52910 index 2748
[46248,NET]
SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.50.16.1:52910;branch=z9hG4bK000045c8
From: <sip:9106@10.50.16.1>;tag=544e42f26d0b001f0000092c-0000070a
To: <sip:4@10.28.132.111>;tag=480227084
Date: Mon, 16 Feb 2015 12:58:14 GMT
Call-ID: 768fbc80-4e11e966-bed-6f841c0a@10.28.132.111
CSeq: 1000 NOTIFY
Server: Cisco-CUCM10.5
Content-Length: 0
+++Next the IP phone sends the next digit. Here its important to note that the NOTIFY doesnt contain the next digit,
the NOTIFY is still the same as the first digit but the next digit is carried in the xml document attached to the NOTIFY.
At this point I will insert a paragraph from the RFC 4730 for SIP KPML
+++++++++++++
The event package uses SUBSCRIBE
messages and allows for XML documents that define and describe filter
specifications for capturing key presses (DTMF Tones) entered at a
presentation-free User Interface SIP User Agent (UA). The event
package uses NOTIFY messages and allows for XML documents to report
the captured key presses (DTMF tones), consistent with the filter
specifications, to an Application Server +++++++++++++++++++++++++++
00869609.002 |14:58:14.209 |AppInfo |SIPTcp - wait_SdlReadRsp: Incoming SIP TCP message from 10.50.16.1 on port 52910 index 2748 with 877 bytes:
[46249,NET]
NOTIFY sip:4@10.28.132.111:5060 SIP/2.0
Via: SIP/2.0/TCP 10.50.16.1:52910;branch=z9hG4bK00003c9d
To: <sip:4@10.28.132.111>;tag=480227084
From: <sip:9106@10.50.16.1>;tag=544e42f26d0b001f0000092c-0000070a
Call-ID: 768fbc80-4e11e966-bed-6f841c0a@10.28.132.111
Date: Mon, 16 Feb 2015 12:58:14 GMT
CSeq: 1001 NOTIFY
Event: kpml
Subscription-State: active; expires=7200
Max-Forwards: 70
Contact: <sip:2b75b6a4-32c6-3ef1-d677-d9b56d34e469@10.50.16.1:52910;transport=TCP>
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
<?xml version="1.0" encoding="UTF-8"?>
<kpml-response xmlns="urn:ietf:params:xml:ns:kpml-response" version="1.0" code="200" text="OK" suppressed="false" forced_flush="false" digits="0" tag="Backspace OK"/>
00869622.001 |14:58:14.210 |AppInfo |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 10.50.16.1 on port 52910 index 2748
[46250,NET]
SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.50.16.1:52910;branch=z9hG4bK00003c9d
From: <sip:9106@10.50.16.1>;tag=544e42f26d0b001f0000092c-0000070a
To: <sip:4@10.28.132.111>;tag=480227084
Date: Mon, 16 Feb 2015 12:58:14 GMT
Call-ID: 768fbc80-4e11e966-bed-6f841c0a@10.28.132.111
CSeq: 1001 NOTIFY
Server: Cisco-CUCM10.5
Content-Length: 0
+++ Again we get the next digit ++++
00869624.002 |14:58:14.262 |AppInfo |SIPTcp - wait_SdlReadRsp: Incoming SIP TCP message from 10.50.16.1 on port 52910 index 2748 with 877 bytes:
[46251,NET]
NOTIFY sip:4@10.28.132.111:5060 SIP/2.0
Via: SIP/2.0/TCP 10.50.16.1:52910;branch=z9hG4bK0000310f
To: <sip:4@10.28.132.111>;tag=480227084
From: <sip:9106@10.50.16.1>;tag=544e42f26d0b001f0000092c-0000070a
Call-ID: 768fbc80-4e11e966-bed-6f841c0a@10.28.132.111
Date: Mon, 16 Feb 2015 12:58:14 GMT
CSeq: 1002 NOTIFY
Event: kpml
Subscription-State: active; expires=7200
Max-Forwards: 70
Contact: <sip:2b75b6a4-32c6-3ef1-d677-d9b56d34e469@10.50.16.1:52910;transport=TCP>
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
<?xml version="1.0" encoding="UTF-8"?>
<kpml-response xmlns="urn:ietf:params:xml:ns:kpml-response" version="1.0" code="200" text="OK" suppressed="false" forced_flush="false" digits="8" tag="Backspace OK"/>
00869637.001 |14:58:14.263 |AppInfo |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 10.50.16.1 on port 52910 index 2748
[46252,NET]
SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.50.16.1:52910;branch=z9hG4bK0000310f
From: <sip:9106@10.50.16.1>;tag=544e42f26d0b001f0000092c-0000070a
To: <sip:4@10.28.132.111>;tag=480227084
Date: Mon, 16 Feb 2015 12:58:14 GMT
Call-ID: 768fbc80-4e11e966-bed-6f841c0a@10.28.132.111
CSeq: 1002 NOTIFY
Server: Cisco-CUCM10.5
Content-Length: 0
+++ Finally we get the last digit ++++
00869638.002 |14:58:14.390 |AppInfo |SIPTcp - wait_SdlReadRsp: Incoming SIP TCP message from 10.50.16.1 on port 52910 index 2748 with 877 bytes:
[46253,NET]
NOTIFY sip:4@10.28.132.111:5060 SIP/2.0
Via: SIP/2.0/TCP 10.50.16.1:52910;branch=z9hG4bK00006c1c
To: <sip:4@10.28.132.111>;tag=480227084
From: <sip:9106@10.50.16.1>;tag=544e42f26d0b001f0000092c-0000070a
Call-ID: 768fbc80-4e11e966-bed-6f841c0a@10.28.132.111
Date: Mon, 16 Feb 2015 12:58:14 GMT
CSeq: 1003 NOTIFY
Event: kpml
Subscription-State: active; expires=7200
Max-Forwards: 70
Contact: <sip:2b75b6a4-32c6-3ef1-d677-d9b56d34e469@10.50.16.1:52910;transport=TCP>
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
<?xml version="1.0" encoding="UTF-8"?>
<kpml-response xmlns="urn:ietf:params:xml:ns:kpml-response" version="1.0" code="200" text="OK" suppressed="false" forced_flush="false" digits="0" tag="Backspace OK"/>
Once digit collection is completed CUCM proceeds to finalise its digit analysis process.
Note that digit analysis is carried out for each digit that is recieved. I have only included the final DA here
00869648.003 |14:58:14.391 |AppInfo |Digit Analysis: star_DaReq: Matching SIP URL, Numeric User, user=4080
00869648.004 |14:58:14.391 |AppInfo |Digit Analysis: getDaRes data: daRes.ssType=[0] Intercept DAMR.sstype=[0], TPcount=[0], DAMR.NotifyCount=[0], DaRes.NotifyCount=[0]
00869648.005 |14:58:14.391 |AppInfo |Digit Analysis: getDaRes - Remote Destination [4080] isURI[0]
00869648.012 |14:58:14.391 |AppInfo |Digit analysis: match(pi="2", fqcn="9106", cn="9106",plv="5", pss="", TodFilteredPss="", dd="4080",dac="0")
00869648.013 |14:58:14.391 |AppInfo |Digit analysis: analysis results
00869648.014 |14:58:14.391 |AppInfo ||PretransformCallingPartyNumber=9106
|CallingPartyNumber=9106
|DialingPartition=
|DialingPattern=4XXX
|FullyQualifiedCalledPartyNumber=4080
|DialingPatternRegularExpression=(4[0-9][0-9][0-9])
|DialingWhere=
+++++Once this is done CUCM then proceeds to send the call out to to the intended destination as configured in the RL ++++
00869701.001 |14:58:14.435 |AppInfo |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 10.250.0.13 on port 5060 index 2754
[46256,NET]
INVITE sip:4080@10.250.0.13:5060 SIP/2.0
Via: SIP/2.0/TCP 10.28.132.111:5060;branch=z9hG4bKce931ee3d74
From: "Emre ESEN" <sip:9106@10.28.132.111>;tag=16726~813ee89e-33db-4d58-9f6a-61542cc840ee-24419585
To: <sip:4080@10.250.0.13>
Date: Mon, 16 Feb 2015 12:58:14 GMT
Call-ID: 768fbc80-4e11e966-bee-6f841c0a@10.28.132.111
Supported: timer,resource-priority,replaces
02-14-2015 08:52 PM
.
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