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

[Divin John (dijohn)]

Hi Daniel,

Do you have CUCm traces ? Detailed SDI/SDL traces for Cisco CallManager?

Regards,
Divin

From: Daniel Pagan <dpagan at fidelus.com<mailto:dpagan at fidelus.com>>
Date: Thursday, 8 August 2013 11:25 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/20130808/0ba3fc9a/attachment.html>