T.38, Exchange, 200 OK delayed

[thegner]

Hi All,

I'm currently testing with CUCM 7, exchange 2007, and the fax features. My trunk already has the T.38 exchange interoperability box checked in it's sip profile, and my exchange server is detecting the CNG tones inband and issuing the re-invite, with the new image sdp. My CUCM does (eventually) respond to the re-invite with a 200 OK, with an image SDP, but it does so exactly 50 seconds later, and after the test fax machine has given up on the fax. Does anyone know why the response with the image SDP answer is delayed? Does anyone know how to fix/change that?

[edit]

With a different source fax machine, the delay is exactly 55 seconds. but on further inspection, (removed a filter), it appears that my cucm may be immediatly issuing a BYE after receiving an ACK for the 200 OK that it sends late. Any Ideas?

[/edit]

Thanks,

Travis Hegner

Network/Software Engineer

Trillium Staffing Solutions

[Nicholas Matthews · Accepted solution]

This doesn't really add up.

What's on the other side of CUCM?

exchange--SIP--cucm---??

Most likely whatever is on the other side of CUCM is causing the delays. It's possible that it is CUCM, but not nearly as likely that it is just passing through what it is receiving.

-nick

[thegner]

Thanks for the reply.

My cucm takes incoming calls from an internet telephony provider over a different SIP trunk. I hadn't considered the fact that the cucm could be also trying to switch the providers leg of the call to an image session as well. I will explore that possibility tomorrow and post back the results.

Would it be possible to configure the cucm so that the provider's leg of the call could maintain an audio session to the MTP, and the exchange call leg could be an image session on the other side of the MTP? I'm not too familiar with the "image" type of session, so I will have to do some research.

Thanks again!

Travis Hegner

[Nicholas Matthews]

Hi Travis,

'image' sessions are T38. It isn't quite RTP and uses a different SDP format.

If you're using an MTP with T38, you will want to make sure the MTP is on IOS and you have 'codec passthrough' configured under the DSPfarm profile.

I still don't know of any reasons why CUCM would be causing that much delay if it wasn't originated by the other side of the call flow.

-nick

[thegner]

Thanks again nick,

I determined that it is in fact my SIP provider who doesn't support T.38 quite yet. They are working on it though.

My cucm was attempting to renegotiate the call on the provider's leg, and received a "488 Not acceptable here". It would not relay that message back to exchange. This is where I experienced a "delay" because the remaining time is still the fax playing tones over an audio session, waiting for another "fax" to respond. Once the fax machine gives up, my provider sends a BYE, and in order to terminate the exchange leg of the call, my cucm sends a 200 OK response, then immediately relays the providers BYE.

Perhaps future versions of cucm should consider terminating/canceling the exchange leg of the call when it's unable to switch both legs of the call, but there is really no harm either way as both legs do eventually terminate.

Thanks again for the help,

Travis Hegner

[Nicholas Matthews]

No problem - glad I could help.

There are a few prominent SIP providers that still do not support T38 so this is fairly common place.

The configuration used would then be 'fax passthrough g711ulaw'. You would need H323 or SIP for this, as MGCP and SCCP both do not support this method.

-nick