ASK THE EXPERT - T.38 FAX OVER IP DESIGN

[ciscomoderator]

Join Cisco expert David Hanes, a technical leader in Customer Advanced Engineering who is CCIE certified and the coauthor of the book "Fax, Modem, and Text for IP Telephony" as he covers the Cisco fax technologies over IP. He is a technical expert in the area of fax over IP technologies and assists with network design and troubleshooting for critical fax over IP deployments.  Since joining Cisco in 1997, he has worked as a Technical Assistance Center (TAC) engineer for the WAN, WAN Switching, and Multiservice Voice teams, a team lead for the Multiservice Voice team, and an Escalation Engineer covering a variety of voice and fax technologies. He holds a bachelor of science degree in electrical engineering from North Carolina State University and CCIE certification #3491.  This Ask the Expert session will guide you through the T.38 design best practices and will give you the knowledge to make sure that your T.38 integrations and designs are successful. The T.38 protocol has emerged as the de facto standard for transporting fax traffic in unified communications networks. However, to get the most from T.38 and deploy it effectively, certain design best practices must be followed.

Remember to use the rating system to let David know if you have received an adequate response.

David might not be able to answer each question due to the volume expected  during this event. Our moderators will post many of the unanswered questions in other discussion forums shortly after the event. This event lasts through December 3, 2010. Visit this forum often to view responses to your questions and the questions of other community  members

[Kenan Muharemagic]

Hi Felipe,

I have collected the logs again with the configuration changes.

Thanks for the help.

[Felipe Garrido]

For inbound calls, the ITSP is sending a 488 media not acceptable when the re-invite for switchover to t.38 is sent. For outbound calls, the ITSP is never sending the re-invite to perform the switchover to t.38. This indicates that the ITSP does not support t.38.

-Felipe

[Kenan Muharemagic]

Well some good news... in cooperation with the ITSP we got the FoIP to work.

Thanks for the help guys.

[amirhuskic]

Hello,

I have question about T.38 fax and CUBE. Our setup is:

VG202 <-> SCCP <-> CUCM 7.x <-> SIP <-> CUBE 2821 <-> SIP <-> ITSP

Sending and receiving faxes worked for 2 weeks without problem. Last week it stops without reason. It isn’t possible to send or receive fax. Since begin configuration didn’t changed. Cisco TAC suggested to change SCCP between VG202 and CUCM to H323 but still doesn’t work. Is first setup supported and which one is the recommended? Thank you for your help.

Best regards

[Michael Hanes]

Honestly I am not sure how your initial setup was working for T.38 fax to an ITSP as SCCP does not support standards-based T.38. Only NSE-based T.38 using a Cisco proprietary switchover is supported with SCCP and this would not be supported by the SIP ITSP. Possibly, the T.38 negotiation was failing and G.711 was being used. Is G.711 your voice codec from the VG202 to the ITSP?

The proper configuration here is to use H.323 or SIP on the VG202 instead of SCCP. Both the H.323 and SIP call control protocols support standards-based T.38 that is compatible with SIP ITSP connections. To troubleshoot this you would need to look at the H245 messaging for H.323 using debug h245 asn1 to confirm that the switchover to T.38 is occurring properly. You should see an H.245 Request Mode message being sent and acknowledged requesting a switchover for T.38.

Feel free to post your VG202 configuration and debug capture and I will take a look if you would like.

Regards,

David

[c.hennrich]

Hi,

I have the same setup and I was looking for MGCP instead of SCCP as protocol for the VG224 and T38 with external ITSP. You say one should use SIP or H323 for this. So now my question, is MGCP also an option as long a I use CA controlled mode?

Many thanks!

[Michael Hanes]

Yes, you are correct. I should have been more clear with my previous answer. H.323 and SIP support standards-based T.38 to an ITSP with or without a CA (like CUCM). MGCP only supports standards-based T.38 to an ITSP if a CA is present. In your scenario, with MGCP in CA-controlled mode, standards-based T.38 us supported to an ITSP.

Regards,

David

[amirhuskic]

Hello David,

thank you for quick response. In attachment is VG202 configuration and incoming fax debug trace. On CUCM is configured H323 to VG202. Thank you for help and time.

Best regards,

Amir

[Michael Hanes]

Hi Amir,

Looking at the "debug h245 asn1" messaging, you are encountering a problem switching over from G711alaw to T.38. For whatever reason the ITSP and the Cisco voice gateway are having an interoperability issue during this switchover process. The initial T.38 H.245 Request Mode message is acknowledged by the ITSP and the G.711alaw logical channels are closed but when the T.38 logical channels are being opened, the ITSP sends the following message -

Nov 30 13:30:54.219: H245 MSC INCOMING PDU ::=

value MultimediaSystemControlMessage ::= request : closeLogicalChannel :

    {

      forwardLogicalChannelNumber 2

      source user : NULL

    }

The ITSP has encountered an error of some sort and is requesting that the T.38 logical channel be closed right after it was opened. I did not see a T.38 parameter mismatch in the messaging so I am guessing that the ITSP may not be happy with the H.245 message flow or the order of the messages. In the past I have seen problems where some devices expect a certain message ordering as logical channels are opened and closed. Can you get a packet capture of this problem? This will make the message flow easier to see and also may highlight any message flow problems.

I did not see anything wrong with your configuration. If you can attach a packet capture I will take a look and see if I can figure out what exactly is happening. If I am not able to see why the ITSP is closing the T.38 logical channels, then you will need to contact your ITSP and provide them the packet capture to figure out why they are sending the message above before the T.38 fax call can complete.

-David

[amirhuskic]

Hi David,

Yesterday I did some testing with different configuration settings. After on CUCM H323 GW to VG202 I disabled option MTP Required faxes start to working. Thank you very much for your help, time and support.

Best regards,

Amir

[Michael Hanes]

Hi Amir,

I did not realize that you had an MTP in this call flow. There are issues sometimes with MTPs and transcoders being involved in FoIP switchovers. I am glad to hear that you figured this out and resolved your issue.

Regards,

David

[c.hennrich]

Hi,

question about the ATA-187 and faxing, does the ATA support both flavors of T.38 (NSE based and protocol/standard based)? or just one?

I could not find a hint in the Cisco documentation:

http://www.cisco.com/en/US/prod/collateral/voicesw/ps6788/phones/ps514/ps11026/data_sheet_c78-608596.html

http://www.cisco.com/en/US/partner/docs/voice_ip_comm/cata/187/1_0/english/administration/guide/sip/a187_ag7fax.html

Thank you!

With Best regards!

[Michael Hanes]

The ATA187 supports standards-based or protocol-based T.38. From all of the information that I have seen on the ATA187, it does not support Cisco proprietary NSE-based T.38.

Regards,

David

[PM77]

Hi Davis,

we are implementing a FAX Server over IP connected via SIP to our Cluster Call Manager, the software is provided by IMECOM.

Our CUCM cluster is protected with a Checkpoint firewall (R65 HFA70) configured with voip domains, and it doesn't work with the fax server.

Do you have any suggestion or best practice guide?

Thanks in advance.

PM

[Michael Hanes]

I am not familiar with the IMECOM or the Checkpoint Firewall products so it is hard to know what problems you may be encountering. Here are a few suggestions:

- Make sure that you are using the G.711 codec. All of the fax servers that I have experience with only support this codec when setting up the initial voice call before transitioning to T.38. From an integration standpoint, this tends to be responsible for a lot of the problems.

- Does the IMECOM product use a Dialogic fax engine (like the SR140)? If so, the Cisco Fax Server product also uses a Dialogic fax engine and most of the design docs available for the Cisco Fax Server would be applicable to the IMECOM product as well.

- If you can get a packet capture of the failing fax call, I should be able to see what is happening at a protocol level and this might provide some additional information as to the cause of your problem.

Regards,

David