Please see last comment - - Page 2

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

simon.birtles · ‎03-01-2017

Seems there is something a little more fundamental at play here. I just checked to make sure that two internal phones can send/recv DTMF. They cant !? Now this was working a little while ago before I adjusted the config which was only regions, device pools etc. I have put 2x9971 in the same DP(REG etc), I actually deleted one then copied the existing 9971 (the one we have been looking at) to create the 2nd 9971 in the same DP, Region etc. This still fails both ways ! Looking at the CUCM traces the bit that stands out is :

00015373.001 |16:05:18.253 |AppInfo |SIG-MediaManager-(5)::wait_MediaConnectRequest, CI(31173922,31173923), capCount(7,7), 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 3 101 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 1), mmCallType(0),FS(0,0), IpAddrMode(0 0) aPid(1, 83, 9), bPid(1, 83, 10) EOType(0 0) () honorCodec(0 0)

party1DTMF(1 3 101 1 0)

party2DTMF(1 3 101 1 1)

This is the same issue we are facing with the other call. now CUCM subscribes to the VGW due to the DTMF Reception change on the phones. But the same problem with mis-matched provideOOB is still the issue even with the same phones in the same regions, DP etc with the same code. I am going to see if there are any other changes I made which could have caused this but from memory there is not.

Ayodeji Okanlawon · ‎03-03-2017

Simon,

I didnt give up on this, I was just too busy and I had to do some more research into this to provide a detailed response.

I have attached my analysis of the call from CUCM traces as it will be too long to copy here.

Here is my Summary..

1. This is not a KPML subscription issue. From the CUCM logs we can see that the phone successfully subscribed to KPML

### Phone has successfully subscribed to KPML ###

Here is the phone sending NOTIFIY to indicate the subscribtiom sate for KPML

01753645.005 |23:40:30.272 |AppInfo |SIPTcp - wait_SdlReadRsp: Incoming SIP TCP message from 192.168.1.152 on port 50758 index 20950 with 666 bytes:
[147314,NET]
NOTIFY sip:192.168.0.40:5060 SIP/2.0
Via: SIP/2.0/TCP 192.168.1.152:50758;branch=z9hG4bK5e9b3e76
To: <sip:00034123456@192.168.0.40>;tag=83001~89504e06-fb76-47f2-b276-48cf860496eb-29480669
From: "Logged Off Phone - BIRTLES" <sip:70070001@192.168.0.40>;tag=aca0166f2173004978b11ce8-0850d0e8
Call-ID: aca0166f-21730009-4b2944e3-65822841@192.168.1.152
Date: Tue, 28 Feb 2017 23:40:29 GMT
CSeq: 102 NOTIFY
Event: kpml
Subscription-State: active; expires=7200
Max-Forwards: 70
Contact: <sip:c309875f-ae5e-963d-9a7a-e229eb10809f@192.168.1.152:50758;transport=tcp>
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE
Content-Length: 0

01753653.001 |23:40:30.273 |AppInfo |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 192.168.1.152 on port 50758 index 20950
[147315,NET]

SIP/2.0 200 OK
Via: SIP/2.0/TCP 192.168.1.152:50758;branch=z9hG4bK5e9b3e76
From: "Logged Off Phone - BIRTLES" <sip:70070001@192.168.0.40>;tag=aca0166f2173004978b11ce8-0850d0e8
To: <sip:00034123456@192.168.0.40>;tag=83001~89504e06-fb76-47f2-b276-48cf860496eb-29480669
Date: Tue, 28 Feb 2017 23:40:30 GMT
Call-ID: aca0166f-21730009-4b2944e3-65822841@192.168.1.152
CSeq: 102 NOTIFY
Server: Cisco-CUCM11.5
Content-Length: 0

2.

Party1: MR=0 CI=29480669
dtm.MTPForDTMF=F
DTMF Caps(1,3,101,1,F)

Party2: MR=0 CI=29480670
dtm.MTPForDTMF
DTMF Caps(1,1,0,1,T)

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

From the caps, the phone is saying that its not going to send its DTMF OOB but it can receive either inband or OOB

The gateway says it can only send and receive OOB

This is also consistent with the log above. The DTMF method for sending DTMF doesnt match on both sides but that should not stop them receiving DTMF

On the issue you raised here.. Why is one side sending DTMF OOB ( are these not SIP phones?)

party1DTMF(1 3 101 1 0)

party2DTMF(1 3 101 1 1)

Please rate all useful posts

simon.birtles · ‎03-06-2017

Please see last comment - some of this conversation has got out of sync, the next one from myself needs to be stepped over.

Ayodeji Okanlawon · ‎03-06-2017

Hi Simon,

I have just gone back to read your last post. So these are the same phones, now that is a little strange. I will suggest to try and upgrade the firmware on at least two of those phones and then test again

Please rate all useful posts

simon.birtles · ‎03-06-2017

Just missed posting the last comment before you posted.. Please see last comment in thread to get back in sync.

Thanks

CUCM SIP Trunk DTMF SIP-KPML Only