<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; "><div>Closing the loop on this one:</div><div><br></div><div>Defects on CUCM caused this.</div><div> CSCtr99004 , CSCtw91193  and CSCtr79913 is needed to fix this.</div><div><br></div><div>Regards,</div><div><br></div><div>Divin</div><div><br></div><span id="OLK_SRC_BODY_SECTION"><div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span style="font-weight:bold">From: </span> Daniel Pagan <<a href="mailto:dpagan@fidelus.com">dpagan@fidelus.com</a>><br><span style="font-weight:bold">Date: </span> Thursday, 8 August 2013 8:55 PM<br><span style="font-weight:bold">To: </span> "<a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a>" <<a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a>><br><span style="font-weight:bold">Subject: </span> [cisco-voip] DTMF Method Stripped on reINVITE | CUCM 8.6.2<br></div><div><br></div><div xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><meta name="Generator" content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:Wingdings;
        panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
        {mso-style-priority:99;
        mso-style-link:"Balloon Text Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:8.0pt;
        font-family:"Tahoma","sans-serif";}
span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri","sans-serif";
        color:windowtext;}
span.BalloonTextChar
        {mso-style-name:"Balloon Text Char";
        mso-style-priority:99;
        mso-style-link:"Balloon Text";
        font-family:"Tahoma","sans-serif";}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri","sans-serif";}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--><div lang="EN-US" link="blue" vlink="purple"><div class="WordSection1"><p class="MsoNormal">Folks:<o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal">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.<o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal">The transaction flows is as follows (<i>Call-ID header and IP addresses omitted</i>):<o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal"><b>INVITE </b><b><span style="font-family:Wingdings">à</span>SBC – Early Offer in use<o:p></o:p></b></p><p class="MsoNormal">..<o:p></o:p></p><p class="MsoNormal">….<o:p></o:p></p><p class="MsoNormal">t=0 0<o:p></o:p></p><p class="MsoNormal">m=audio 27030 RTP/AVP 0 8 18 <b><span style="background:yellow;mso-highlight:yellow">101</span></b><o:p></o:p></p><p class="MsoNormal">a=rtpmap:0 PCMU/8000<o:p></o:p></p><p class="MsoNormal">a=ptime:20<o:p></o:p></p><p class="MsoNormal">a=rtpmap:8 PCMA/8000<o:p></o:p></p><p class="MsoNormal">a=ptime:20<o:p></o:p></p><p class="MsoNormal">a=rtpmap:18 G729/8000<o:p></o:p></p><p class="MsoNormal">a=ptime:20<o:p></o:p></p><p class="MsoNormal">a=fmtp:18 annexb=no<o:p></o:p></p><p class="MsoNormal">a=rtpmap:101 telephone-event/8000<o:p></o:p></p><p class="MsoNormal"><span style="background:yellow;mso-highlight:yellow">a=fmtp:101 0-15<o:p></o:p></span></p><p class="MsoNormal">==========================<o:p></o:p></p><p class="MsoNormal"><b>200 </b><b><span style="font-family:Wingdings">ß</span> SBC – Containing SDP w/ reordered, preferred codecs<o:p></o:p></b></p><p class="MsoNormal">..<o:p></o:p></p><p class="MsoNormal">…..<o:p></o:p></p><p class="MsoNormal">v=0<o:p></o:p></p><p class="MsoNormal">o=BroadWorks 492305543 1 IN IP4 10.15.5.119<o:p></o:p></p><p class="MsoNormal">s=-<o:p></o:p></p><p class="MsoNormal">c=IN IP4 10.15.5.119<o:p></o:p></p><p class="MsoNormal">t=0 0<o:p></o:p></p><p class="MsoNormal">a=sqn: 0<o:p></o:p></p><p class="MsoNormal">a=cdsc: 1 image udptl t38<o:p></o:p></p><p class="MsoNormal">m=audio 41194 RTP/AVP 0 18 8 <b><span style="background:yellow;mso-highlight:yellow">101</span></b><o:p></o:p></p><p class="MsoNormal">a=ptime:20<o:p></o:p></p><p class="MsoNormal">a=fmtp:18 annexb=no<o:p></o:p></p><p class="MsoNormal">a=rtpmap:101 telephone-event/8000<o:p></o:p></p><p class="MsoNormal"><span style="background:yellow;mso-highlight:yellow">a=fmtp:101 0-15<o:p></o:p></span></p><p class="MsoNormal">==========================<o:p></o:p></p><p class="MsoNormal"><b>CUCM ACK’s the 200 </b><i>(omitted)</i><b> to close the transaction and sends a reINVITE with a single codec but no DTMF method:
<o:p></o:p></b></p><p class="MsoNormal">v=0<o:p></o:p></p><p class="MsoNormal">o=CiscoSystemsCCM-SIP 962515 2 IN IP4 10.15.81.106<o:p></o:p></p><p class="MsoNormal">s=SIP Call<o:p></o:p></p><p class="MsoNormal">c=IN IP4 10.17.66.123<o:p></o:p></p><p class="MsoNormal">b=TIAS:64000<o:p></o:p></p><p class="MsoNormal">b=AS:64<o:p></o:p></p><p class="MsoNormal">t=0 0<o:p></o:p></p><p class="MsoNormal">m=audio 27030 RTP/AVP 0<o:p></o:p></p><p class="MsoNormal">a=rtpmap:0 PCMU/8000<o:p></o:p></p><p class="MsoNormal">a=ptime:20<o:p></o:p></p><p class="MsoNormal">=========================<o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal">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
<u>single</u> 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:<o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal">“For streams marked as sendrecv in the answer,<o:p></o:p></p><p class="MsoNormal">   the "m=" line MUST contain <b><i>at least</i></b> one codec the answerer is willing<o:p></o:p></p><p class="MsoNormal">   to both send and receive, from amongst those listed in the offer.”<o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal">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.<o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal">Thanks ahead of time!<o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal">Daniel<o:p></o:p></p></div></div></div></span></body></html>