CUCM SIP Trunk DTMF SIP-KPML Only

simon.birtles · ‎02-28-2017

I working in a lab environment and working through various configurations. I have the following setup but have issues with one way DTMF using SIP-KPML.

IPPhone(9971)<----SIP---->CUCM(11.5)<----SIP TRUNK---->SIPGW(2811)<---SIP--->VG(VG202)<-->AnalogPhone

The SIP Trunk is setup to the SIPGW with DTMF (No Preference) and delayed media (though have tried with early)
The SIPGW dial peers have dtmf-relay sip-kpml only for in/out bound peers.
The VG also has a dial peer towards the SIPGW with dtmf-relay sip-kpml only

Calls work fine.
DTMF works from the IPPhone to the AnalogPhone
DTMF does not work from the AnalogPhone to the IPPhone.

I have run some debugs and traces etc. and see the following;

The VG202 sends a SIP subscribe to the VGW (Expected & OK)
The VGW sends a SIP subscribe to the VG202 (Expected & OK)
The VGW sends a SIP subscribe to CUCM (Expected & OK)
CUCM sends a SIP subscribe to the IPPhone (9971) (Expected & OK)
*** CUCM DOES NOT SEND A SIP SUBSCRIBE TO THE VGW ***
The DTMF negotiation between CUCM and VGW is sip-kpml for both call legs.

When I runs debugs/traces I see the end to end DTMF from the IPPhone to the AnalogPhone. When I do the same from the AnalogPhone to the IPPhone, the KMPL notify gets sent from the VG202 to the VGW and then stops. Because CUCM has not subscribed to the VGW for KPML notify.

I am aware that usually we would enable both NTE and SIP-KPML on the VGW dial peer towards CUCM but I want to understand why CUCM is not subscribing to the VGW for SIP-KPML notifications. I have attached the output from "debug ccsip messages" from the VGW from the call setup and the trace from CUCM.

IP Addr's in the traces.

IPPhone .152

VGW .200

VG202 .199

CUCM .40

Any ideas ?

Thanks

Ayodeji Okanlawon · ‎02-28-2017

Simon,

What happens if you hard code the sip trunk to use OOB only. I have not looked at the traces in detail but this is something base don this call flow where everything is OOB, you should try

Please rate all useful posts

simon.birtles · ‎02-28-2017

Hi - Assuming you are referring to the CUCM DTMF Signalling Method; setting this to "OOB and RFC 2833" does not resolve the problem. What I have noticed going through the CUCM traces is the following where CUCM suggests that the VGW only support SIP UnSol. Notify:

"01548133.010 |12:00:30.543 |AppInfo |SIP DTMF Info: mLocalDtmfCaps...UNSOL=1, KPML=1, Inband=1(101) mEndppointsDtmfCaps...UNSOL=1, KPML=0, Inband=0(0) mDefaultTelephonyEvent=101, mDtmfPreference=1, mMtpAllocated=0"

Looking at the VGW dial peers; (all based on IPPhone 9971 calling Analog Phone)

The dial peer for CUCM inbound into the VGW sets SIP-KPML only, but no SIP messages for this call have been sent/recv at this point for this call. So why does CUCM think the VGW supports UNSOL only?

! (VGW)
! inbound to VGW from CUCM
!
dial-peer voice 110 voip
session protocol sipv2
incoming called-number .
voice-class codec 1
dtmf-relay sip-kpml
fax rate disable
no vad
!

! (VGW)
! outbound to VG202 from VGW
!
!
dial-peer voice 120 voip
preference 1
destination-pattern 0034.T
session protocol sipv2
session target ipv4:192.168.0.199
voice-class codec 1
dtmf-relay sip-kpml
fax rate disable
no vad
!

Ayodeji Okanlawon · ‎02-28-2017

Simon I am going to attempt to answer your questions..

To do that we need to take a trip to our beloved RFC ( this time sits RFC3265 we need)

This how Subscribe/Notify works. Its uni-driecttional

  Subscriber          Notifier
       |-----SUBSCRIBE---->|     Request state subscription
       |<-------200--------|     Acknowledge subscription
       |<------NOTIFY----- |     Return current state information
       |--------200------->|
       |<------NOTIFY----- |     Return current state information
       |--------200------->|

Question 1

I am aware that usually we would enable both NTE and SIP-KPML on the VGW dial peer towards CUCM but I want to understand why CUCM is not subscribing to the VGW for SIP-KPML notifications

Based on the RFC, This subscription between ( a subscriber and notifier in our case CUCM and endpoints (ie phones/gateway) is unidirectional. For example in the same trace we are looking at, When CUCM receives INVITE requests from the phone with KPML advertised..

Allow-Events: kpml,dialog

CUCM sends a SUBSCRIBE to the phone for KPML. This is unidirectional. CUCM is the subscriber and the phone is the notifier. You will see in the cucm traces that the phone is the one sending notify to the subscriber (cucm) to inform it of the subscription state.

Similarly, when CUCM sends the outbound request to the gateway, CUCM becomes the notifier and the gateway the subscriber. Since CUCM advertised KPML in its request, hence the subscriber (gateway now) needs to tell CUCM to subscribe to KPML.

Allow-Events: presence, kpml

I am going to analyse the logs and hopefully provide some help if I can.

One thing to point out is this..

You have to be careful on this line here. Its only authoritative if you see the analysis before cucm sends out the ACK (when its computing its SDP to send for the answer). If you see it during the inital leg of the call, then cucm hasn't finished its capabilities negotiation, hence this could be misleading

"01548133.010 |12:00:30.543 |AppInfo |SIP DTMF Info: mLocalDtmfCaps...UNSOL=1, KPML=1, Inband=1(101) mEndppointsDtmfCaps...UNSOL=1, KPML=0, Inband=0(0) mDefaultTelephonyEvent=101, mDtmfPreference=1, mMtpAllocated=0"

From the issue you described now it looks to me that the gateway is not sending the DTMF digits via a NOTIFY to CUCM. And thats what we should focus on. I think we should look at detailed logs on the gateway to see if we can find out why we are not getting the NOTIFY

Do the following

service sequence-numbers
service timestamps debug datetime localtime msec
logging buffered 10000000 debug
no logging console
no logging monitor
default logging rate-limit
default logging queue-limit

Then..

debug ccsip all

<Enable session capture to txt file in terminal program.> (such as Putty)

then do the ff:

terminal length 0
show logging

Please rate all useful posts

simon.birtles · ‎02-28-2017

Attached. Yes, The issue is exactly that.

DTMF works from the IPPhone to the Analog Phone (VG202 connected).
The key press (DTMF) from the Analog phone gets as far as the VGW

So Analog Phone -> VG202 -> VGW

So based on your response about the uni-directional nature of SUBSCRIBE, this is something I was aware of BUT.. you have made me rethink and take another look and something I did not look at / or think about was the IPPhone. So we see CUCM sending a SUBSCRIBE to the IPPhone (all good) but I did not think about the IPPhone sending a SUBSCRIBE to CUCM which is not seen in the traces on CUCM. Is this a issue? In that... if the IPPhone does not SUBSCRIBE to CUCM, then CUCM wont see the need to SUBSCRIBE to the VGW and therefore the VGW will not know it needs to send the NOTIFY to CUCM when it receives it from the VG202?

simon.birtles · ‎02-28-2017

For completeness.. CUCM SIP Trunk & Trunk Profile screen shots

Ayodeji Okanlawon · ‎02-28-2017

Simon,

Apologies for the late replies..

I am trying to put some analysis together but in the meantime.based on what I saw in DTMF negotiation please check " Require DTMF reception" tickbox on the phone and reset it. Then test again and this time provide fresh cucm logs if it doesnt work.

This is what I see..

01548250.001 |12:00:34.471 |AppInfo |SIG-MediaManager-(152)::wait_MediaConnectRequest, CI(29480630,29480631), capCount(7,2), mcNodeId(0,0), xferMode(16,16), reConnectType(0), mrid (0, 0) IFCreated(0 0) proIns(0 0), AC(0,0), party1DTMF(1 3 101 0 0) party2DTMF(1 1 0 1 1)

party1:
dtmf Config = 1 = Best Effort
Supported DTMF Method = 3
rfc2833RecvPayloadNum = 101 =
wantDTMFReception 0 =
provideOOB 0 = false

Party2:
dtmf Config = 1 = Best Effort
Supported DTMF Method = 1
rfc2833RecvPayloadNum = 0
wantDTMFReception = 1 =
provideOOB = 1 = True

Please rate all useful posts

simon.birtles · ‎02-28-2017

Ok, so I enabled "Require DTMF reception" in the 9971 phone configuration and reset and re-tested. The same issue is present. In the traces (attached), the wantDTMFReception is now true (1), but issue still persists.

01735220.001 |22:44:52.446 |AppInfo |SIG-MediaManager-(165)::wait_MediaConnectRequest, CI(29480660,29480661), capCount(7,2), mcNodeId(0,0), xferMode(16,16), reConnectType(0), mrid (0, 0) IFCreated(0 0) proIns(0 0), AC(0,0), party1DTMF(1 3 101 1 0) party2DTMF(1 1 0 1 1),reConnFlag=0, connType(3,3), IFHand(0,0),MTP(0,0),MRGL(8ed05fe5-e874-3978-63f8-acc15b6b146e,8ed05fe5-e874-3978-63f8-acc15b6b146e) videoCap(1 0), mmCallType(0),FS(0,0), IpAddrMode(0 0) aPid(1, 83, 238), bPid(1, 83, 239) EOType(0 0) () honorCodec(0 0)

party1DTMF(1 3 101 1 0)
dtmf Config = 1 = Best Effort
Supported DTMF Method = 3
rfc2833RecvPayloadNum = 101 =
wantDTMFReception 1 (true)
provideOOB 0 = false

party2DTMF(1 1 0 1 1)
dtmf Config = 1 = Best Effort
Supported DTMF Method = 1
rfc2833RecvPayloadNum = 0
wantDTMFReception = 1
provideOOB = 1 = True

Assume the "Supported DTMF Method = 3"; with 3 being RFC2833 & OOB which is from CUCM and for Party2; the "=1" being KPML ? Why would party1 have provideOOB as false ?

Ayodeji Okanlawon · ‎02-28-2017

I will pick this up tomorrow and see what updates I can provide for you. But with the way things are now both parties cant really send DTMF.

The phone says it doesn't support OOB and its DTMF method = 3

The other party only supports OOB and DTMF method = 1

We cant even invoke MTP because we need one party to be on RFC2833 ( DTMF method=2 and the other party to be on OOB) for CUCM to invoke MTP

So I will dig deeper tomorrow and provide some clarity hopefully.

Please rate all useful posts

simon.birtles · ‎02-28-2017

Sure, no worries... Having looked through the traces in some more detail, the NOTIFY is actually being sent to CUCM now from the VGW.

01753675.002 |23:40:34.341 |AppInfo |SIPTcp - wait_SdlReadRsp: Incoming SIP TCP message from 192.168.0.200 on port 28717 index 21206 with 722 bytes:
[147319,NET]
NOTIFY sip:192.168.0.40:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 192.168.0.200:5060;branch=z9hG4bK11C1B5B
From: <sip:0034123456@192.168.0.200>;tag=6DBEE00-26D1
To: "Logged Off Phone - BIRTLES" <sip:70070001@192.168.0.40>;tag=83005~89504e06-fb76-47f2-b276-48cf860496eb-29480670
Call-ID: 46f12d00-8b610a6b-f52a-2800a8c0@192.168.0.40
CSeq: 103 NOTIFY
Max-Forwards: 70
Date: Tue, 28 Feb 2017 23:40:35 GMT
User-Agent: Cisco-SIPGateway/IOS-12.x
Event: kpml
Subscription-State: active
Contact: <sip:192.168.0.200:5060;transport=tcp>
Content-Type: application/kpml-response+xml
Content-Length: 113

<?xml version="1.0" encoding="UTF-8"?><kpml-response version="1.0" code="200" text="OK" digits="9" tag="dtmf"/>

So, one step further on.. It seems that the phone still has not subscribed for KPML events and CUCM is aware of an issue with outbound DTMF (to the IPPhone - SEPACA0166F2173)

01753685.001 |23:40:34.342 |AppInfo |LineCdpc(175): -dispatchToAllDevices-, sigName=CcUserInfoReq, device=SEPACA0166F2173
.....
01753688.001 |23:40:34.342 |AppInfo |SIPCdpc(246) - star_CcUserInfoReq: Outbound DTMF method selected is 0. Digit=9 and isMTPPassingThru2833=0
01753688.002 |23:40:34.342 |AppInfo |SIPCdpc(246) - star_CcUserInfoReq: No outbound DTMF method available yet but both sides support KPML, save digit (9) in the queue

Updated traces from CUCM and VGW for same call attached.

simon.birtles · ‎03-06-2017

Putting conversation back in sync.

Ayodeji,

Firstly, that is a great analysis in the attachment you sent, your time spent going through that and commenting the various sections is very much appreciated and goes a long way to help me (and probably others) understand CUCM traces for calls. So a big thanks for you time and effort spent on that.

I have had my time taken up on a project so been a bit AWOL myself. But back to it...

The commented trace you sent certainly shows the call setup progress and I understand that and even more so now! But I still am not finding the issue where the IP Phone fails to receive DTMF from the Analog phone. In fact if I try this between two IP Phones I get the same result bidirectionally. i.e. pressing a key during a call produces a DTMF tone on the phone the key is being pressed on but the far end IP Phone does not receive the DTMF tone, so this is not an isolated issue with the Analog VG202 connected phone. (Remember the Analog phone connected to the VG202 receives DTMF from the IP Phone)

Referring to your comments on the NOTIFY, I believe this is due to a subscription from CUCM as follows:

01753605.001 |23:40:30.107 |AppInfo  |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 192.168.1.152 on port 50758 index 20950 
[147304,NET]
SUBSCRIBE sip:c309875f-ae5e-963d-9a7a-e229eb10809f@192.168.1.152:50758;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 192.168.0.40:5060;branch=z9hG4bKf84a40a5c9a2
From: <sip:00034123456@192.168.0.40>;tag=83001~89504e06-fb76-47f2-b276-48cf860496eb-29480669
To: "Logged Off Phone - BIRTLES" <sip:70070001@192.168.0.40>;tag=aca0166f2173004978b11ce8-0850d0e8
Call-ID: aca0166f-21730009-4b2944e3-65822841@192.168.1.152
CSeq: 101 SUBSCRIBE
Date: Tue, 28 Feb 2017 23:40:30 GMT
User-Agent: Cisco-CUCM11.5
Event: kpml
Expires: 7200
Contact: <sip:192.168.0.40:5060;transport=tcp>
Accept: application/kpml-response+xml
Max-Forwards: 70
Content-Type: application/kpml-request+xml
Content-Length: 370

<?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 interdigittimer="7260000" persist="persist">
    <regex tag="dtmf">[x*#ABCD]</regex>
  </pattern>

</kpml-request>

This is CUCM subscribing to the IPPhone to "ask" for DTMF from the IPPhone when the user of that phone presses a key during the call. This has always worked as the Analog phone (VG202 connected) has always received DTMF.

It is the IPPhone that is not receiving from the Analog Phone. The IPPhone does not seem to subscribe to CUCM to ask for DTMF from the far end.

When we selected the "Require DTMF ..." on the IPPhone device page this has prompted CUCM to SUBSCRIBE to the VGW for DMTF, from the traces we see this is now happening as this CUCM to VGW subscription was not working before.

But this selection of "Require DTMF ..." on the IPPhone device in CUCM (in my mind) should force the IPPhone to SUBSCRIBE to CUCM to ask for any DTMF tones from the far end device (or at least the next connected device to CUCM) when in fact we see CUCM SUBSCRIBEing to the IPPhone instead. The issue is with the IPPhone receiving DTMF so surely the SUBSCRIBE should be coming from the IPPhone.

Am I missing something here? Unless the IPPhone subscribes to CUCM then it wont recieved DTMF from the far end even if the DTMF is getting as far as CUCM in NOTIFY messages.

Ayodeji Okanlawon · ‎03-06-2017

The DTMF reception field is a true or false field for if you want to do dtmf or not. This doesn't determine the DTMF method to be used. It may be inband or OOB. So it doesnt force the phone to innitiate a subscribe message as far as I know

Like I was trying to explain earlier subscribing for KPML event is a one way event. If CUCM has already sent subscription message to the phone, the phone will send a NOTIFY to indicate the subscription state, As long the subscription is active, then it can receive notification events based on that subscription which in this case is KPML.

If you are not getting tones on a call between two 9971 sip ip phones, then I will first try and update firmware on those phones. These should be sent using rtp-nte and not carried in any NOTIFY message as this will be sent inband (using the same media channel but with payload 101 rather than your regular payload for the codec the call negotiated.

Out of curiosity does DTMF work when you dial out to an IVR based system from any of these phones?

Please rate all useful posts

simon.birtles · ‎03-08-2017

Yes, DTMF works fine with UCCX for example. I have updated the firmware from sip9971.9-4-2SR3-1 to sip9971.9-4-2SR2-2. This is still a problem. I have also tested this 7945/7965 phones and the same result. None of the phones ever receive DTMF, just send fine.

Ayodeji Okanlawon · ‎03-09-2017

Very interesting that they can send but not receive. At this point all I can say now is TAC! I have exhausted my capacity on this one :)

Please rate all useful posts

simon.birtles · ‎03-27-2017

I don't have access to TAC currently but when I do, I will raise an update this thread. 5* for your effort and involvement in this though. Been interesting peeling back all the layers of the onion (well most anyway !!). Thanks...