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

[letmeinnn]

T.38 and SR140 issue.

We are trying to get T.38 set up on our network and get rid of fax passthrough.

we used the following:

mgcp package-capability fxr-package
mgcp default-package fxr-package
mgcp fax rate 14400
no mgcp fax t38 ecm
no mgcp fax t38 inhibit

we can get a fax tone if we dial but when we debug fax relay t30 it shows the following:

000676: Dec  2 08:37:15.159 PST: 1/0/0:23 (39)  65518954 fr-entered=10(ms)
    timestamp=65520544 fr-msg-tx CSI
    timestamp=65521154 fr-msg-tx DIS
    timestamp=65526964 fr-msg-tx CSI
    timestamp=65527574 fr-msg-tx DIS
    timestamp=65529794 fr-msg-det DCS
    timestamp=65539834 fr-msg-tx CSI
    timestamp=65540444 fr-msg-tx DIS
    timestamp=65542674 fr-msg-det DCS
    timestamp=65552634 fr-msg-tx CSI
    timestamp=65553244 fr-msg-tx DIS
    timestamp=65557864 fr-msg-det DCS

and the faxes fail.

We are using it on a 2811 with MGCP and 12.4.25d

Thanks

[Michael Hanes]

Your MGCP configuration is correct and working fine.

Your debug output is interesting... it appears to show a delay problem. Typically when we see these T.30 negotiation messages repeating themselves in this manner it means that the T4 timer on the fax machine endpoints is expiring and resending the messages before a response is received. Can you provide the call path for your scenario? Obviously, you have a fax server at one end and an MGCP voice gateway somewhere in the path but what other devices and networks are between the fax server and the terminating fax machine?

Regards,

David

[letmeinnn]

We have tried these configurations in a couple different locations.

We tried it at our head office with two 3845 gateways plugged into a 3750 switch and using a tr1034 over a pstn and got similar results after enabling t38.  The first gateway receives calls and the second hosts the t1 for the tr1034.

This issue was intermittent depending on the sending fax machine (one canon would never complete the fax, another one would work fine) and we had to roll back because it was service affecting.  Remove t38 and all faxes come through.  We started to test with a different gateway that we are able to reset without affecting users.

The above debug comes from a 2811 connected to the fax server over a WAN (avg 60ms) into a 3745 router, then a 3750 switch which the fax server and sr140 are plugged into.  Fax machine is at a remote location calling a number on the remote gateway.

Kevin

[Michael Hanes]

Hi Kevin,

Your scenarios sounds pretty basic so I am not sure where you would be picking up so much delay if that is the cause of your problem. Whenever I have seen the debug messages appear like yours, in my experience it has been a delay issue. Either that or something is preventing the fax messages from making it to the other device so both keep repeating their initial negotiation messages over and over until they give up and disconnect the call.

The next step here is probably going to be a PCM capture on the DSP to confirm how these messages are being sent out on the POTS port and what amount of delay is present. Cisco TAC will need to be involved though as they have the ability to decode the capture file that you collect. The problem you are encountering is not seen much and a PCM capture is the best tool for determining the root cause.

A packet capture may also be helpful in seeing if this is a delay issue. It is not as definitive in as the PCM capture but it can provide good information as to what is going on. If you want to make a packet capture of a failing call then I would be happy to take a look.

Regards,

David

[letmeinnn]

I upgraded the remote gateway to 15.1.3 and I was finally able to succesfully receive a fax with the same config.

Kevin

[Michael Hanes]

Hi Kevin,

Good to know. I wish I had an explanation for you here but there was obviously a software defect. I have just never known one to cause the debug output that you were seeing. Thanks for the follow-up!

-David

[aemcomcco]

Hi experts, I've a littel issue in my T.38 fax implementation.
It works fine execpt the fax trasmission from my T.38 server to traditional Brother FAX machines. The trasmission is OK. All pages are sent without problem. The pages received are perfect but all Brother faxes return a communication error.

I use the Imagicle STONEFAX (Cisco Developer Certified). This fax server use H.323 T.38 and is interfaced to a Cisco IAD 2431 PSTN gateway.

I say "all" because I tried with tens of Brother FAXes. The result is the same. Perfect document received but the transmission is closed with communication error only to Brother receiver. My FAX closes the transmisison with OK.

Crazy!

This is a fax debug on Cisco IAD:

1/1:15 (9583)  676202845 fr-entered=10(ms)
    timestamp=676204285 fr-msg-det NSF
    timestamp=676204735 fr-msg-det CSI
    timestamp=676205425 fr-msg-det DIS
    timestamp=676207005 fr-msg-tx TSI
    timestamp=676207715 fr-msg-tx DCS
    timestamp=676212665 fr-msg-det CFR
    timestamp=676244895 fr-msg-tx MPS
    timestamp=676247865 fr-msg-det MCF
    timestamp=676276255 fr-msg-tx EOP
    timestamp=676279245 fr-msg-det MCF
    timestamp=676280765 fr-msg-tx DCN

I don't see what is the problem.

What's your opinion? Thanks in advance.

[Michael Hanes]

In the past when I have seen this sort of problem, the cause was that the last DCN message was not being received by the fax machine before the connection was terminated. Without the DCN message, the fax machine does not see a graceful disconnect and may register an error even though all of the fax pages have been satisfactorily received. What version of IOS are running on your IADs? I know that we had some sort of software defect related to this from a while back but it should be fixed in all of the more recent IOS versions.

Regards,

David

[aemcomcco]

Your suggestions are very helpfull.
This is the IAD IOS version:

Cisco IOS Software, 2400 Software (C2430-IS-M), Version 12.4(24)T4, RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2010 by Cisco Systems, Inc.
Compiled Fri 03-Sep-10 14:51 by prod_rel_team

ROM: System Bootstrap, Version 12.2(15r)ZJ, RELEASE SOFTWARE (fc1)

IAD-FAX-SERVER-GW-2 uptime is 8 weeks, 4 days, 2 hours, 32 minutes
System returned to ROM by power-on
System image file is "flash:c2430-is-mz.124-24.T4.bin"

Cisco IAD2431 (R527x) processor (revision 3.0) with 119808K/11264K bytes of memory.
Processor board ID FHK0826U0G4
R527x CPU at 225MHz, Implementation 40, Rev 3.1
2 FastEthernet interfaces
62 Serial interfaces
2 Channelized/Clear E1/PRI ports
DRAM configuration is 64 bits wide with parity disabled.
63K bytes of non-volatile configuration memory.
System fpga version is 250027
System readonly fpga version is 20001E
Option for system fpga is 'system'.
62592K bytes of ATA System CompactFlash (Read/Write)

I know that latest cisco IOS version is 15.
Do you suggest an upgrade?

Thanks.

[Michael Hanes]

This IOS is fairly recent so it should not have the defect that I am thinking about from years ago. There is a possibility that a new but similar issue has come up again but I am not aware of it.

From a troubleshooting perspective, you have a few options -

- Obtain a packet capture of the problem. You may be able to see the DCN message being sent very late in the transaction which may point to the issue I mentioned.

- Obtain a PCM capture. This is the best way to find root cause as you will confirm exactly when and if the DCN gets sent out by the IAD out the POTS port. You will need to get TAC involved as they have the tool to decode the capture file.

- You can try an upgrade but I am hesitant to recommend IOS upgrades without identifying the issue, especially in production networks. Sometimes you just end up introducing another problem. However, if you have a lab/test environment and you want to try the latest 15.1 mainline release then that could be helpful.

Regards,

David

[philippgrafl]

Hello,

hope i am not too late. :-)

The ATA 186/188 was only supporting modem passthrough. The new ATA187 is supporting T38. Which kind of T.38? protocol-based or NSE-based?

Thanks.

PG

Sorry, just seen that this question has already been answered....

[Michael Hanes]

ATA187 supports protocol-based or standards-based T.38.

Regards,

David