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
Which software based modem do you recommend for use with a fax server? I am currently researching the implementation of a new fax server using T.38 via HylaFax and t38modem with Cisco Hardware and H.323 gateway.
Also, where can I see the video of this presentation?
There are numerous software solutions apart from T38modem with Hylafax, e.g. Cisco Fax Server (RightFax); XMedius from www.sagem-interstar.com; SatisFAXtion Fax Server from www.faxback.com; FaxVoip from www.t38faxvoip.com among others.
It is interesting to know which of those products were tested for T.38 interoperability with Cisco gateways.
Most of those solutions implemented as Exchange connector/ Fax Server would compromise real-time fax experience from the end user point of view, so it is not the same as connecting fax machine via T.38-capable ATA.
In regards to a software based fax/modem, I had had pretty good luck with just about all class 2.0 and above devices. I have not performed a lot of testing in this area so your mileage may vary but I would not expect you to encounter any problems related to a class 2.0 modem when its communications are transported over T.38.
The recorded version of my T.38 webcast will be posted here -
I do not see it here yet so I will follow up and try to get an idea of when exactly it will be available.
Also, thanks for the positive feedback about the book. I am glad that you like it and I hope that you continue to find it useful.
Are you answering Cisco Fax Server design questions too?
I'd like to know, regarding Cisco Fax Server integrated to a Cisco UC solution with CUCM and Cisco h323 gateways, What are the possibilities to create a AutoAttendant solution that could ask to the originator caller the destination user fax number?
The second question is, in a centralized Cisco Fax Server design What should be the fax protocol for remote gateways that use low codec for voice as G729?
The last questios is What is the recommended type of integration with IBM Domino?
Thanks in advance, Sergio.
It's nice to see that there is a special session for FAX over IP. I met you in Person at Cisco Networkers 2010@Vegas and also gone multiple time the great book written by you.
Issue (Refer-Open SR-616076263 specific to the FAX call over IP using CUBE setup). :
1st- With VG224, fax is working but I am clueless how the Fax call is using end to end G728r Codec and the calls are happening as normal Voice Call. Can't see the change between call starting as voice and going to FAX specific setup. Guess is that by default ISR has FAX relay enabled and this call is using the same relay setup.
Looking for a step by step way of debug commands and sh command and what to look for in those debug which will show the call flow. I used debug voip ccapi inout but really can't make out the difference between Voice and a Fax call. It's confusing.
2nd case, I have one ATA connected to remote 2 site and in that case only one way Fax is happening i.e Fax from HQ to ATA connected FAX is happening but other way around that is From ATA connected FAX to HQ PBX fax is not happening. It may be an issue with the FAX passthrough but instead of jumping to conclusion, aim of this Q is what the best step of troubleshooting a FAX call.
Thanks for the positive feedback on the book and thanks for attending our session at Cisco Live!
Viewing a complete FoIP call flow can be confusing. The output from debug voip ccapi can be helpful if you are used to reading this debug and know what to look for. Probably the most comprehensive tool is a Wireshark capture and then you can definitely see what is happening in regards to codec switchovers and so forth.
On the voice gateway, there are some show commands that help you confirm that a codec switchover has occurred and what codecs are being used for the call:
1) The show call active voice brief command provides the most information but you may have to parse through a few pages of call legs and do some CLI filtering if you have a lot of calls occurring at once. Here is an example of show call active voice brief output displaying a g729 voice call -
126C : 58 11411290ms.1 +10520 pid:1 Originate 200 active
dur 00:00:08 tx:112/2154 rx:307/6092
IP 18.104.22.168:17620 SRTP: off rtt:1ms pl:5930/0ms lost:0/0/0 delay:60/60/70ms g729r8
This same call switches over to G.711 when fax tones are detected and you can see the new codec being displayed
126C : 58 11411290ms.1 +10520 pid:1 Originate 200 active
dur 00:00:41 tx:1677/252554 rx:1953/258112
IP 22.214.171.124:17620 SRTP: off rtt:4ms pl:40/0ms lost:1/0/0 delay:60/60/60ms g711ulaw TextRelay: off
media inactive detected:n
2) You can also use the command show voice call summary. Here is an example where the codec shows T.38:
Router#show voice call summary
PORT CODEC VAD VTSP STATE VPM STATE
============== ========= === ==================== ======================
0 t38 n S_FAX FXSLS_CONNECT
3) The command show voice call status also shows the codec during a call. In this example the T.38 fax speed is shown but voice/passthrough codecs are also displayed:
Router#sh voice call status
CallID CID ccVdb Port Slot/DSP:Ch Called # Codec MLPP Dial-peers
0x2B 124D 0x86E26350 0 0/1:1 5000 14400 1/21 active call found
You can repeat the commands above throughout the call and watch the codec settings. This will allow you to determine if switchovers are occurring or not without having to resort to packet captures or debugs.
In regards to troubleshooting your ATA problem, the simplest troubleshooting methodology for FoIP is to first confirm that the initial voice call is set up between the two endpoints. In many cases, this can be easily accomplished by picking up the handset on fax devices and having a conversation. Or you may need to look at a packet capture or the commands listed above. Once you have confirmed that this initial voice call is setting up correctly, then you need to confirm that a proper switchover is occurring. In the case of the ATA186, only an NSE-based passthrough switchover is supported. So you need to make sure that this is configured on the remote device (IOS command modem passthrough under dial peer) and that the NSE messages are being exchanged correctly. You can also confirm again with the show commands above. If the voice call and switchover are all occurring, and faxes are still failing then you need to start investigating the fax media stream for corruption or T.30 negotiation problems. I hope this helps.
Thanks David for your explanation. I was following all the command mentioned in your reply but may be I have to try that throughout the call duration and hope I will be able to find something.
One more clarification:
Whether Clear Channel and T.38 setup for fax transmission co-exist? If yes, then what's the required configuration and what will be the call behaviour? Sometime there are scenario where you have VG224 and ATA's and that makes things little confusing.
Also, any specific design for a scenario where there exist two setup
A normal fax setup which can work with T.38 and
on the other hand, stand-alone secure fax machines which are having a hardware based secure device attached and can't tolerate any change with digitiged FAX media throughout the FAX transmission. I read it in your book regarding Clear Channel or hair pinning but not sure how to achieve it?
Yes, you will need to repeat those commands throughout the call and then you can notice any switchovers/codec changes.
The term "clear channel" is defined differently depending on who you talk to. I have spoke with some who ue this term instead of passthrough using the G.711 codec. Cisco also has a clear channel codec where the DSP performs no signal manipulation (levels, echo cancellation, etc.). I have also seen the term referred to specifically for TDM hairpinning across the backplane of ISR voice gateways. Can you confirm exactly what you mean by "clear channel" because it is not clear to me and I want to make sure I give you the answer that you are looking for?
When you mention T.38 and "clear channel" together then it makes me think that you are talking about having passthrough or the clear channel codec running simultaneously with T.38. I have never run faxes over the clear channel codec as G3 faxes need echo cancellation enabled but if you are referring to passthrough then this can be run with T.38. Specifically you will need to run NSE-based passthrough ("modem passthrough" in IOS configuration). You can configure NSE-based passthrough and T.38 simultaneously.
I have not worked with secure faxes but I am assuming that their transmission methods are similar to secure phones, which use a modem V.32 or V.34 modulation. This modem modulation can be passed via G.711. If the secure fax is actually a STE (Secure Terminal Equipment) then you may be able to implement Cisco's secure modem relay feature to pass the traffic -
If you truly need a "clear channel" for secure fax transmissions, then you can configure the clear channel codec under the voip dial peer if you must transport the call over an IP network. If you want to just pass the transmission between two telephony ports on a ISR then hairpinning is possible by simply routing via POTS dial peers. You will need to have both ports tied to the TDM backplane and the same clock source.
By clear Channel, I was referring a setup where Analog FAX machine is connected to ATA or VG and at the gateway level it's gets modulated and Demodulated and gets transmitted over IP media.IP Media is not doing any packet level changes and just passing whatever information it received without any add on to that information.
Looking for specific configuration and how well this can be scaled where CCM is acting as a calling agent and number of such FAX machine is around 100+ in total?
Thanks and regards
I apologize but I am still a little confused by what you mean by clear channel. In your last post you mention that by clear channel you are referring to, "a setup where Analog FAX machine is connected to ATA or VG and at the gateway level it's gets modulated and Demodulated and gets transmitted over IP media". A modulation and demodulation process only occurs with a fax relay protocol like T.38. Are you talking about T.38 when you refer to clear channel?
You then mention in your next sentence about clear channel that "IP Media is not doing any packet level changes and just passing whatever information it received without any add on to that information." This makes me think that you are talking about passthrough now as the exact fax tones are digitized and simply passed over IP using the G.711 codec with passthrough and no changes are made at all to the fax messaging. Fax relay protocols like T.38 have the ability to manipulate the fax messaging and change negotiation speeds and the ECM setting.
Can you confirm if you are talking specifically about passthrough or T.38 when you refer to clear channel? You have also mentioned my book in previous posts. Is there a specific page or section that discusses what you are trying to accomplish?
I apologize again if I am missing something but I just want to be sure that we are both talking about the same thing. Once we get our terminology synchronized, I will be able to answer your question better about scaling 100+ faxes in a CUCM environment. The short answer is more than likely going to be that 100+ is fine. CUCM can easily handle that and much more with all of the various fax transport mechanisms. Depending on the fax transport mechanism, most limitations are on the voice gateway side.
Sorry for creating confusion but I myself is confused now about which solution will work for the following scenario which co-exist at all location :
1) Normal FAX call from point A to Point B without any external secure device - T38 FAX relay is the solution for this.
2) Analog Fax connected to a Hardware device doing Encryption and then connected to VG or ATA need to send the fax at the other end device which is connected the same way i.e VG/ATA and Encryption device then the FAX machine.
I haven't tested but I was told that it has been observed working over a Layer 2 connectivity or VPN but it was observed not working over an IP link.
So, my thought is- to have this working the only thing needed is :
After encryption device, the stream carrying FAX encrypted detail need to be received as is at the other end
What does that mean in my term is "that the IP media just act as transit path or carrier for the fax message and don't do any changes in the encrypted message"
I am not sure which solution will work for this and need to test out in detail.. At this moment it can be passthrough or T38 or tweaking the HairPin setup.
Though I am still trying to understand the Hairpin calls as stated in your book page 237(Chapter 7) and whether FAX server is necessary..The T1/E1 connection to the FAX server as depicted in the diagram can be a Voice Gateway at the other end of the WAN and in place of FAX server a FAX machine connected to it.
Thanks for the clarifications. It looks like you have a few different scenarios that you are looking at. I agree that T.38 is your best bet for normal faxing between two endpoints across an IP network.
In your scenario with the encryption device, most people have the best luck with the modem passthrough feature on Cisco voice gateways. Most of the encryption devices that I have seen use a modem modulation and modem passthrough is your best bet for passing this type of information. There are different encryption methods and protocols so your mileage will vary but this is where I would start -
If this does not work you may want to try hard coding the dial peer to the clear channel codec and giving this a try. The clear channel codec does not make any changes to the bit stream and this may work better for some encryption methods.
In regards to a hairpin scenario, it is important to remember that the router is just connecting telephony ports. There is not a WAN involved but possibly a PSTN. The gateway is simply joining two POTS ports together and an IP connection is not involved. This would probably work for your encryption devices but I was under the impression that your locations were connected by IP. I hope this explanation makes sense.
Sure, I will be happy to address any questions that are FoIP related.
- The auto attendant solution that you describe is something that I have not seen implemented before but I see no technical reason that it would not work. After playing some sort of announcement asking the user to enter the destination fax digits, the auto attendant could then route the call to a fax server and ask the user to start the fax communication on their end. What I am not sure about is the capabilities of the auto attendant to perform this function as this is not a product I deal with regularly. From a faxing perspective I see no problems implementing this.
- The Cisco Fax Server (and all of the fax servers that I have worked with) require the fax call to initially negotiate with G.711 before switching over to T.38. Fortunately, this G.711 call only last for a few seconds (less than 2 seconds if I remember correctly from my last testing with the Cisco Fax Server). So, you just experience a small spike in bandwidth. Of course, once the switchover to T.38 (without redundancy enabled) is made then the bandwidth drops to around that of a G.729 call or a little less. You also may be able to transcode between G.729 and G.711 as well using CUBE before the T.38 switchover occurs.
- I have not performed a Domino integration with the Cisco Fax Server. Specific Cisco fax server questions such as this are usually best answered by the Open Text experts on the email alias email@example.com.
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.
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?
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.
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.
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!
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....
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?
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.
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.
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?
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!)
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
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
My guess, with the current debugs, is that the ITSP doesn't support t.38.