<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)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><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:#1F497D;}
.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="color:#1F497D">And your trace interpretation is correct.  MediaExchange is sending a MXInterfaceOpenLogicalChannelIncoming message to MGCPInterface while MGCPInterface is currently in a state of waiting for an MGCP Response.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Brian<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><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> Wednesday, October 16, 2013 10:04 PM<br>
<b>To:</b> cisco-voip@puck.nether.net<br>
<b>Subject:</b> [cisco-voip] H323/MGCP T.38 Issue & CCM Trace<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">Thanks ahead of time for reading this. I’m looking at an issue involving protocol based T.38 between an H323 fax server and MGCP gateway. The call starts as normal: The CRCX/200 contains the appropriate FXR package and caps, audio cut-through
 occurs successfully while first negotiating G711ulaw, the fax server sends CUCM an H245 mode request for T.38, a CLC on the existing channel and then a new OLC for T.38. CUCM ACKs the CLC but never ACKs the new OLC. Instead, after the new OLC is received,
 it appears MediaExchange is waiting for MGCP to proceed (I assume for a MDCX to the gateway w/ a new SDP media header… which I never see); immediately after the OLC is received, traces show “waitForMGCPResponse” for MGCPInterface and transactions for both
 CI’s go completely cold. Only one node is processing this call – screenshot below.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><img width="936" height="271" id="Picture_x0020_7" src="cid:image001.jpg@01CECB16.8B8D37D0" alt="cid:image013.jpg@01CECAB5.7B1B6F90"><o:p></o:p></p>
<p class="MsoNormal">Has anyone seen this before? CUCM not ACKing the OLC and never sending the appropriate MDCX to the gateway? The fax server is attempting to perform Fast Start at the beginning of the call, but not configured for inbound Fast Start support
 at the trunk level. I doubt this is related but figured it wouldn’t hurt to mention.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Follow-up question: The “MGCPInterface” and “MediaExchange” processes listed above on the same trace line… The way I interpreted this entry, based on the fact that each corresponding process number is listed (1209 & 10771), is that MGCPInterface
 is receiving a request from the MediaExchange process. Is this description correct?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks again.<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>