[cisco-voip] DTMF Method Stripped on reINVITE | CUCM 8.6.2

[Daniel Pagan]

My apologies for resurrecting this thread, but can you confirm if these bug fixes are still targeted for SU4? We'd like to reassure the customer again that SU4 is expected to include these bug fixes, but I'm hoping for official confirmation once more. Also, is the BU still on track for an early 2014 release of the SU? Again, we're just hoping to set realistic expectations with the customer.

Thanks again for looking into this.. it's definitely appreciated.

- Dan

From: Divin John (dijohn) [mailto:dijohn at cisco.com]
Sent: Thursday, October 03, 2013 7:07 PM
To: Daniel Pagan; cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] DTMF Method Stripped on reINVITE | CUCM 8.6.2

Closing the loop on this one:

Defects on CUCM caused this.
 CSCtr99004 , CSCtw91193  and CSCtr79913 is needed to fix this.

Regards,

Divin

From: Daniel Pagan <dpagan at fidelus.com<mailto:dpagan at fidelus.com>>
Date: Thursday, 8 August 2013 8:55 PM
To: "cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>" <cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>>
Subject: [cisco-voip] DTMF Method Stripped on reINVITE | CUCM 8.6.2

Folks:

I'm looking at an interesting issue where CUCM is stripping DTMF method from a reINVITE and I'm wondering if you've seen this before. Topology is pretty simple: CUCM ==SIPTrunk==VerizonSBC. CUBE is not involved in this scenario for this particular environment (different issue, different story). Audio cut-through is successful but no DTMF method is established.

The transaction flows is as follows (Call-ID header and IP addresses omitted):

INVITE -->SBC - Early Offer in use
..
....
t=0 0
m=audio 27030 RTP/AVP 0 8 18 101
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:8 PCMA/8000
a=ptime:20
a=rtpmap:18 G729/8000
a=ptime:20
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
==========================
200 <-- SBC - Containing SDP w/ reordered, preferred codecs
..
.....
v=0
o=BroadWorks 492305543 1 IN IP4 10.15.5.119
s=-
c=IN IP4 10.15.5.119
t=0 0
a=sqn: 0
a=cdsc: 1 image udptl t38
m=audio 41194 RTP/AVP 0 18 8 101
a=ptime:20
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
==========================
CUCM ACK's the 200 (omitted) to close the transaction and sends a reINVITE with a single codec but no DTMF method:
v=0
o=CiscoSystemsCCM-SIP 962515 2 IN IP4 10.15.81.106
s=SIP Call
c=IN IP4 10.17.66.123
b=TIAS:64000
b=AS:64
t=0 0
m=audio 27030 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=ptime:20
=========================

The SIP trunk is configured for DTMF method of No Preference. I also see no MTP allocation attempts from MediaManager in SDI traces which makes me think we're not dealing with a media negotiation failure. Other SBC's in this environment perform an early cut-through of audio via 183s to CUCM resulting in no issues. It seems to me the solution would be to force the SBC to send a 200 answer w/ only a single codec in its SDP, theoretically eliminating the need for a reINVITE. But unfortunately this isn't possible since the provider is adhering to the Answer/Offer Model RFC:

"For streams marked as sendrecv in the answer,
   the "m=" line MUST contain at least one codec the answerer is willing
   to both send and receive, from amongst those listed in the offer."

Any thoughts on why CUCM would be stripping the DTMF method from its reINVITE? Again, I see no MTP allocation requests from MediaManager, so I doubt it's the result of a negotiation failure. Setting the SIP Trunk's DTMF method from No Preference to RFC2833 results in the same problem. Lastly, a bug scrub didn't come back with anything that matched the symptoms spot on. CUCM is 8.6.2.

Thanks ahead of time!

Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20131203/c83597dc/attachment.html>