cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
31643
Views
30
Helpful
56
Replies

ASK THE EXPERT - T.38 FAX OVER IP DESIGN

ciscomoderator
Community Manager
Community Manager

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

56 Replies 56

fatai.oyejobi
Level 1
Level 1

Hi:

I configured 802.1x on a 3560, then about an hour later, it started rebooting every 20 min.  I removed the switch from the stack and replaced it with another.  As I was about to log in to the switch, it won't take the passowrd anymore, and it keeps asking me for password each time I pressed "Enter".  How can I get back to the switch?

I will appreciate your help.

Thanks

Maybe you could try the right thread for this question.

It is a little bit, just a little bit out of the context.

Thank you,

met.

metalium2007
Level 3
Level 3

Hello,

Im implementing a kind of transcoder device between Cisco Fax Relay and T.38.

You have the Cisco Fax Relay world then a gateway with two E1 interfaces and then T.38 world.

Cisco Fax relay world --->gatewayE1 1/0 ---->Virtual PSTN --> gateway E1 1/0 -----> voip to T.38 world

The gateway is the same with a back-to-back connection.

Is this a supported scenario?

Thank you.

met

Met,

The individual parts, Cisco Fax relay, back to back E1 and T.38, are supported configurations. I don't see any reason why this would not work. It's not the most ideal scenario, but it should still work.

-Felipe

I agree with Felipe here that all of the pieces are supported and most of the instances that I recall where this has been implemented have been successful. I would just caution that you are adding extra delay in this solution as every IP to PSTN transition encounters a 300ms playout buffer delay. While this can be adjusted, this increased delay can impact the success rate of faxes if there is already a lot of delay in the fax path.

Regards,

David

Hello David,

My topology is this one:

Fax connected to FXS in Cisco Fax relay in Gateway1 ---> voip -> gateway2 E1 1/0 ---->Virtual PSTN --> gateway2 E1 1/0 -----> voip -> Fax connected to FXS in T.38

When I send a fax from Cisco Fax Relay to T.38 call is getting disconnected 40 seconds with sending incomplete displayed in origin fax.

What can be the issue here? Can you help me?

Keep up the good work!

Thank you

met

hi met,

how do you loop a call from a voip dial-peer through an E1 PRI card and back to a voip dial peer?

Just basic dial-peer routing.

You receive the call...point it to E1 1/0. You'll receive it on  E1 1/1 then  you just point it to another voip dial-peer.

Some voice translation-profiles and rules and you've got it....

Hello David...

I think I solved my problem lowering the fax playout-delay to 100 ms on the voice-ports of my E1-back-to-back connection.

Can you please explain me the exact behaviour of this command?

Thank you!

When dealing with VoIP and FoIP, jitter can be a problem. Packets can take different amounts of time routing through an IP network. The packets can take different paths and encounter different amounts of delay. Packets may even arrive out of order. Therefore, a playout buffer is used for VoIP and FoIP to store up a certain amount of packets to ensure that all have arrived before playing them out the telephony interface.

With VoIP a dynamic buffer is used that can change as network conditions change. However, when this buffer grows or shrinks, voice samples may be lost but this is not a problem for voice as it can tolerate a little loss. FoIP on the other hand is data and cannot tolerate any loss. So, the playout buffer cannot change and it must be static.

With T.38, Cisco sets the playout buffer to a fixed 300ms value. This is a large value and means that T.38 packets can handle network jitter up to 300 ms. Fax has a high tolerance for delay so creating a 300 ms playout buffer is usually not a problem and it prevents T.38 fax from being affected by jitter for the most part. It would be rare to have an IP network with more than 300 ms of jitter.

Occasionally scenarios occur where there are multiple IP to PSTN hops or satellite links and the delay starts to really add up. Every IP to TDM hop with Cisco voice gateways adds an additional 300 ms of roundtrip to delay. Performing the virtual PSTN E1 loop that you have increases round trip delay by an additional 600 ms. This is on top of the 600 ms you already have because of your endpoint voice gateways. You have now easily crossed the 1000 ms mark where fax may begin to have problems negotiating because of too much delay.

By reducing the playout buffer in both directions to 100 ms, you are cutting a total of 400 ms from the roundtrip delay of your fax call.This was obviously enough to bring down your delay budget enough for the faxes to negotiate. Most IP networks I encounter do not have more than 100 ms of jitter so this is more than likely a safe setting but you should realize that if jitter in your network goes above 100ms then your fax calls could start taking a long time to get through or start failing. Adjusting the playout delay lower for your T.38 traffic is not a problem as long as you do not set it below the amount of jitter in your network.

I know that this is a long answer but hopefully it provides the answer that you are looking for.

-David

Thank you for your answer David. It's always a pleasure to talk with someone that know what we are dealing with.

I would just like to understand why faxes doesnt work with the default 300 ms fax playout buffer, and they start to work perfectly with a configured 100 ms fax playout buffer. Problem is solved, but I really would like to understand what is the issue.

Thank you!

met.

Let me see if I can clarify a little further exactly what is going on when your faxes failing with the 300ms setting. Fax machines exchange T.30 messages which need to receive a response by a certain timeout period defined by a T4 timer. This timer is around 3 seconds but in reality we have seen some devices use a shorter timeout period. The T.30 message negotiation that initially occurs when a fax call is being setup is timing out. Messages are exchanged by both sides but responses to these messages are not seen before the message is retransmitted. If you were to run a "debug fax relay t30 all-level-1", when your problem is occurring, you will probably see the critical DIS and DCS messages consistently timing out and being resent. Eventually, the fax endpoints give up trying to setup the call and they disconnect.

Once you lower the playout buffer size, and therefore the amount of delay between these fax endpoints, these T.30 negotiation messages are received in a more timely manner. The negotiation completes and the fax page is sent successfully.

Does the explanation above help you understand the issue a little better?

-David

Hello David,

Thank you very much for your detailed description of the problem.

I won't bother you longer with this issue! (Just tell me where can I buy you a beer!)

Cheers!

met

Hi guys.

I have a question regarding T38 fax with Cisco ISR gateways.

Last few days i have been trying to get a T38 fax server (XMedius) to work over an ITSP SIP trunk without any success.

The setups is something like:

T38 Fax Server (XMedius) <--> SIP <--> Cisco2801 <--> SIP <--> ITSP

First of all is this a supported setup with a T38 FAX server and an ITSP SIP trunk?

For testing purposes i tried this using an analog phone line connected to an FXO port, added a pots dial-peer and the fax was working fine but for some reason it does not work through the SIP trunk.

I have attached the config and a debug output for reference.

The debug messages are getting rate-limited due to the collection method. Please enable logging to the buffer and collect the again. Add the following configuration,

no logging monitor

no logging console

no logging queue-limit

no logging rate-limit

logging buffer 2000000

service sequence-number

Next, enable the following debugs,

debug ccsip message

debug voip ccapi inout


use a telnet program that allows logging to a file.

Issue the clear log command.

Make the test call.

After the call fails, issue the following commands to retreive the debug output.

terminal length 0

show log

My guess, with the current debugs, is that the ITSP doesn't support t.38.

-Felipe

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: