<html 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">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<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]-->
</head>
<body 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>
</body>
</html>