[cisco-voip] H323/MGCP T.38 Issue & CCM Trace

[Daniel Pagan]

A few updates on this one...

- 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.
- 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.

>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.

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.

- Daniel


From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Daniel Pagan
Sent: Wednesday, October 16, 2013 10:04 PM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] H323/MGCP T.38 Issue & CCM Trace

Folks:

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.

[cid:image013.jpg at 01CECAB5.7B1B6F90]
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.

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?

Thanks again.

- Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20131017/19ea5225/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 76573 bytes
Desc: image001.jpg
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20131017/19ea5225/attachment.jpg>