<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=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@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.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#404040;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@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"><span style="font-family:"Courier New";color:#404040">FYI – Looks like a defect… CSCts85879 & CSCts05812<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New";color:#404040">Symptom from an external user perspective is continuous ring back (assuming annunciator is successfully selected). Upgrading to M7 and hopefully that resolves it.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#404040"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> cisco-voip [mailto:cisco-voip-bounces@puck.nether.net]
<b>On Behalf Of </b>Daniel Pagan<br>
<b>Sent:</b> Friday, October 18, 2013 4:36 PM<br>
<b>To:</b> cisco-voip@puck.nether.net<br>
<b>Subject:</b> [cisco-voip] CUBE/SIP Issues on Blind Xfer<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Folks:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I’m working an issue where blind transfers into UnityCx result in ring back followed by a disconnect. Grabbed detailed CCM traces and ccsip debugs off CUBE and the issue seems to be caused by CUBE and its call-leg to the ITSP. All call-legs
except those for the IP phone and Annunciator devices utilize SIP.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">In a nutshell, the issue I’m seeing is that CUBE fails to continue transmitting the appropriate SIP transactions to the provider. I know this sounds vague so I’ll diagram it below:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b><span style="font-size:12.0pt">::: UnityCx receives the transferred call – replies to CUCM with 100 then 180 Ringing.<o:p></o:p></span></b></p>
<p class="MsoNormal"><b><span style="font-size:12.0pt">::: MediaMgr invokes an annunciator successfully to provide CUBE w/ ringing – transactions to connect CUBE to ANN below:<o:p></o:p></span></b></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b>CUCM======CUBE=======ITSP<o:p></o:p></b></p>
<p class="MsoNormal">INVITE------->
<o:p></o:p></p>
<p class="MsoNormal">TRYING<------ <o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in;text-indent:.5in">INVITE------> ||<b>CSeq #110</b><o:p></o:p></p>
<p class="MsoNormal"> 200<--------- ||SDP<o:p></o:p></p>
<p class="MsoNormal">200<---------- ||SDP<o:p></o:p></p>
<p class="MsoNormal">ACK----------> ||SDP w/ c= …. <Annun_ip_addr><o:p></o:p></p>
<p class="MsoNormal"> <b><span style="color:#C00000">###NO ACK HERE###</span><o:p></o:p></b></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b><span style="font-size:12.0pt">::: UnityCx answers the call – CUCM attempts to disconnect CUBE/ANN<o:p></o:p></span></b></p>
<p class="MsoNormal"><b><span style="font-size:12.0pt">::: Transactions for this are below:<o:p></o:p></span></b></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b><span style="color:#002060">UNITYCx</span></b>=====<b>CUCM</b>======<b><span style="color:#002060">CUBE</span></b>=======<b>ITSP<o:p></o:p></b></p>
<p class="MsoNormal">200-----------><o:p></o:p></p>
<p class="MsoNormal"> INVITE--------> ||SDP w/ a= inactive<o:p></o:p></p>
<p class="MsoNormal"> 100<-----------<o:p></o:p></p>
<p class="MsoNormal"> ACK---------> ||<b><span style="color:#C00000">CSeq #110<o:p></o:p></span></b></p>
<p class="MsoNormal"><b><span style="color:#C00000">
</span>##NO reINVITE OUT##<span style="color:#C00000"><o:p></o:p></span></b></p>
<p class="MsoNormal"><b><span style="color:#C00000"><o:p> </o:p></span></b></p>
<p class="MsoNormal"><b><span style="color:#C00000">:: This triggers the MX streaming timeout and MediaMgr deletes the call CIs<o:p></o:p></span></b></p>
<p class="MsoNormal"><b><span style="color:#C00000"><o:p> </o:p></span></b></p>
<p class="MsoNormal">CUBE was upgraded to 15.1(4)M6 a few days ago. Has anyone encountered this problem before? CUBE sends the ACK to close the final response for connection to the Annunciator late on the ITSP side… then no INVITE request is sent to proceed
with the new request after UnityCx connects. SIP transactions remain idle and the MX streaming timeout occurs after 8 seconds. At first, I thought “well… CUBE is still sending the ACK to the provider w/ the correct CSeq.. so it being late in the order of operations
shouldn’t be a problem”, but late or not, CUBE should still reINVITE after the ACK.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks for reading through this. Thoughts?<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>