<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)">
<!--[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:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@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;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle22
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#404040;}
span.EmailStyle23
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle24
{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="color:black">Certainly makes sense. I’m asking the customer for more information on the fax solution and we’ll hopefully be able to make that change. If not, Fast Start will become the permanent solution. Plus, considering
it’s was already attempting to use outbound FS, my guess is this was somehow disabled for inbound on the trunk during or post-upgrade to 9.1.2; an issue that’s been lingering since its installation but masked by the MTP.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:black">Thanks again.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:black">- Daniel<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""> Brian Meade (brmeade) [mailto:brmeade@cisco.com]
<br>
<b>Sent:</b> Thursday, October 17, 2013 9:25 AM<br>
<b>To:</b> Daniel Pagan; cisco-voip@puck.nether.net<br>
<b>Subject:</b> RE: 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"><span style="color:#1F497D">Daniel,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">That’s sort of similar to what I’m seeing in this other case. The bottom line is the Fax gateway shouldn’t be sending an OLC for chan#5 before receiving the CLCack for chan#4. H.245 can be such a headache with
things like this. Any chance the fax server supports SIP instead? You may see much better results that way,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Brian</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></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""> Daniel Pagan [<a href="mailto:dpagan@fidelus.com">mailto:dpagan@fidelus.com</a>]
<br>
<b>Sent:</b> Thursday, October 17, 2013 9:21 AM<br>
<b>To:</b> Brian Meade (brmeade); <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
<b>Subject:</b> RE: H323/MGCP T.38 Issue & CCM Trace</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><span style="color:#404040">Brian</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#404040"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#404040">Thanks and that’s similar to the behavior I’m seeing in the trace file.
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#404040"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#404040">Call flow is <b>Fax</b>==H.323==<b>CUCM</b>==MGCP=<b>GW</b></span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#404040"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#404040">Here’s what I’m seeing once the two call-legs are connected:</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#404040"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#404040">FAX</span><span style="font-family:Wingdings;color:#404040">à</span><span style="color:#404040">RequestMode</span><span style="font-family:Wingdings;color:#404040">à</span><span style="color:#404040">CUCM</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#404040">FAX</span><span style="font-family:Wingdings;color:#404040">à</span><span style="color:#404040"> CLC (chan#4)
</span><span style="font-family:Wingdings;color:#404040">à</span><span style="color:#404040">CUCM</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#404040">FAX</span><span style="font-family:Wingdings;color:#404040">à</span><span style="color:#404040"> OLC (chan#5)
</span><span style="font-family:Wingdings;color:#404040">à</span><span style="color:#404040">CUCM</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#404040">FAX</span><span style="font-family:Wingdings;color:#404040">ß</span><span style="color:#404040">CLCack (chan#4)
</span><span style="font-family:Wingdings;color:#404040">ß</span><span style="color:#404040"> CUCM</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#404040"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#404040">After this we’re waiting for the terminating gateway to detect fax tones and send the corresponding notify msg. We don’t receive this until 10 seconds later. The NTFY finally arrives and we reply w/ 200, but
never extend a MDCX with the new m= SDP header. </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#404040"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#404040">What confuses me is that the originating gateway (fax server) is sending the request mode instead of the terminating gateway, and the terminating gateway doesn’t send its observed event for T38 until much later.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#404040"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#404040">Does this match what you’re seeing in the case you’re following?</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#595959"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#404040">The fax server is attempting Fast Start but CUCM has this disabled. I enabled inbound Fast Start support and that seems to be working as a temporary solution.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#404040"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#404040">- Daniel</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#404040"> </span><o:p></o:p></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""> Brian Meade (brmeade) [<a href="mailto:brmeade@cisco.com">mailto:brmeade@cisco.com</a>]
<br>
<b>Sent:</b> Thursday, October 17, 2013 8:48 AM<br>
<b>To:</b> Daniel Pagan; <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
<b>Subject:</b> RE: H323/MGCP T.38 Issue & CCM Trace</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Daniel,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">I’ve been following another case with a similar issue detailed below:</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">This is the correct signaling sequence for T.38 switchover FYI:</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">CUCM GW</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> | RequestMode ---------------> |</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> | |</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> | <-----------------RequestModeAck |</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> | |</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> | <-----------------CloseLogicalChannel |</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> | |</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> | CloseLogicalChannelAck-----------------> |</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> | |</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> | <-------------------OpenLogicalChannel |</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> | |</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> | OpenLogicalChannelAck----------------> |</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> | |</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> | CloseLogicalChannel------------------> |</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> | |</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> | <-------------------CloseLogicalChannelAck |</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> | |</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> | OpenLogicalChannel-----------------> |</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> | |</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> | <----------------OpenLogicalChannelAck |</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">In the case I’m working on, here is the behavior we’re seeing.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">CUCM GW Channel no</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> | RequestMode ---------------> |
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> | |</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> | <-----------------RequestModeAck |</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> | |</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> | <-----------------CloseLogicalChannel | 1</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> | |</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> | </span>
<span style="color:#77933C"><-------------------OpenLogicalChannel</span><span style="color:#1F497D"> | 2</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> | |</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">14:54:58.682 |!!ERROR!! -LogicalChannels--
<b>open, try to open an existing channel that is in use</b>:98e876e8,lcn=3|*^*^*</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">14:54:58.682 |DET-H245Interface-(105782)::<b>handleH245OLCIncoming, Failed to open receive channel
</b>3.|5,100,21,105734.8^10.132.56.37^Port 63596</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> | </span>
<span style="color:#953735">CloseLogicalChannelAck-----------------></span><span style="color:#1F497D"> | 1</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> | |</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> | OpenLogicalChannelAck----------------> | 2</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> | |</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">CUCM understands that OLC was rejected so it again tries to do OLC with new channel.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> | OpenLogicalChannel-----------------> | 3</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> | |</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> | CloseLogicalChannel------------------> | 1</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Meanwhile OLC of LCN = 1 gets rejected and so we do not get any answer for the OLC of LCN=3. So call fails.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> | <------------------openLogicalChannelReject | 1</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> | |</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> | <-------------------CloseLogicalChannelAck | 1</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Does this seem to be similar to what you’re observing? Does the gateway send the new OLC before CUCM sends the CLCAck? If so, that is most likely the cause of the problem.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Brian</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></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 [<a href="mailto:cisco-voip-bounces@puck.nether.net">mailto:cisco-voip-bounces@puck.nether.net</a>]
<b>On Behalf Of </b>Daniel Pagan<br>
<b>Sent:</b> Thursday, October 17, 2013 7:26 AM<br>
<b>To:</b> Daniel Pagan; <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
<b>Subject:</b> Re: [cisco-voip] H323/MGCP T.38 Issue & CCM Trace</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New"">A few updates on this one…</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New"">- It seems this became an issue after a recent upgrade to CUCM 9.1.2. May or may not be relevant. Not sure at this point.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New"">- I spoke too soon. Reviewed additional traces and CUCM is receiving an NTFY from the gateway for FXR/t38(start), only it’s being received 10 seconds after the OLC is sent from the
fax server for a T.38 request.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New"">From what I recall, the terminating gateway should be initiating the request for T38 and CUCM should reply with the MDCX with t38 in the m= SDP header, but only a 200 response is
sent to the gateway and then the trace goes cold again. The previous OLC for t38 is never ACKed and, eventually, the ISDN side disconnects and the call is torn down.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New"">At this point I can’t tell if it’s a gateway issue (no t38 switchover attempt for 10 seconds) or CUCM (no MDCX in response to the NTFY for the t38 observed event). The sequence of
events appear out of order, but I can certainly be wrong.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New"">- Daniel</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></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 [<a href="mailto:cisco-voip-bounces@puck.nether.net">mailto:cisco-voip-bounces@puck.nether.net</a>]
<b>On Behalf Of </b>Daniel Pagan<br>
<b>Sent:</b> Wednesday, October 16, 2013 10:04 PM<br>
<b>To:</b> <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
<b>Subject:</b> [cisco-voip] H323/MGCP T.38 Issue & CCM Trace</span><o:p></o:p></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 border="0" width="936" height="271" id="Picture_x0020_7" src="cid:image001.jpg@01CECB20.BE638BF0" 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>