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

[Divin John (dijohn)]

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>
Date:  Thursday, 8 August 2013 8:55 PM
To:  "cisco-voip at puck.nether.net" <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/20131003/f9b5f13c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5533 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20131003/f9b5f13c/attachment.p7s>