Welcome to the Cisco Networking Professionals Ask the Expert conversation. This is an opportunity to learn about FoIP in UC environments and the growing trend of fax server integrations using products like the Cisco fax server and the AXP-XmediusFAX module.David Hanes is an engineer for the Cisco Customer Assurance Engineering (CAE) group supporting various emerging technologies through product testing and field trials. 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. David is the coauthor of "Fax, Modem, and Text for IP Telephony" from Cisco Press. He holds a bachelor's of science degree in electrical engineering from North Carolina State University and CCIE certification #3491.
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 September 5, 2008. Visit this forum often to view responses to your questions and the questions of other community members.
When looking at the fax passthrough documentation, I have seen this written as passthrough and pass-through. Does this mean that there are two different types of passthrough for faxes?
Yes, you are correct and this is a confusing aspect of transporting fax calls through Cisco voice gateways using passthrough. I will do my best to to explain this without adding any additional confusion.
- the term "passthrough" can mean passing fax calls over an IP network using the G.711 codec in a generic sense. It can also have a more specific meaning in that the configuration command "modem passthrough" is being used to transport the fax call. The key here is that when transporting fax calls using modem passthrough, the switchover from voice mode to G.711 passthrough is accomplished using Cisco proprietary NSE messages. This is also referred to as "NSE-based passthrough".
- the term pass-through refers to fax calls being passed over IP using the G.711 codec as well, except that the switchover occurs in the H.323 or SIP protocol stack instead of through the use of Cisco proprietary NSE messages. This passthrough method is configured using the command "fax protocol pass-through" and is referred to as "protocol-based pass-through".
You should realize that occasionally these terms will be incorrectly interchanged and this adds further confusion. Both of these passthrough methods ultimately leave you with a fax call being transported by a G.711 codec, but the key difference is the switchover mechanism that converts the call from voice mode to G.711 passthrough.
Currenty we are using Right FAX my question is why should I Migrate to Cisco Fax solution if you can provide me few quick benefits thati can gain with Cisco FAX solution
We just installed the Cisco FAX solution and lo and behold! It's Right Fax! Is there something new that Cisco has?
As mentioned in a previous post the Cisco fax server is the Captaris RightFx solution.
The only other faxing solution that Cisco has at this time is the AXP-XMediusFAX solution. This solution is targeted at branches and integrates the XMediusFax server on the AXP module of an ISR voice gateway. Basically this a fax server on a router blade. While XMediusFAX is a full featured fax server, it is targeted at branch applications while the Cisco fax server is targeted at larger, centralized fax server deployments. Both of these solutions offer compatibility with Unified CM and Cisco voice gateways. More information on the AXP-XmediusFAX solution can be found here -
The Cisco fax server is an OEM of the Captaris Rightfax product that is typically loaded on Cisco MCS server hardware platforms. There is nothing additional that you gain from a feature perspective in buying the Cisco fax server versus the Captaris RightFax product. However, many Cisco customers prefer one vendor when implementing a Unified Communications solution and this is probably the main reason that customers choose the Cisco fax server.
In regards to migrating an existing RightFax deployment to the Cisco fax server, I cannot think of a compelling reason to do that at this time unless having a one vendor point of contact is a priority.
How do I know that a Cisco fax server will integrate properly into my current network? I am running CallManager 4.2(3).
The main interoperability consideration for integrating a Cisco fax server (or any other fax server brand) in Cisco UC (Unified Communications) environments is the support of T.38 fax relay. The support for T.38 fax relay in Cisco IOS voice gateways has been available for years so the Cisco fax server interoperating with Cisco voice gateways is rarely a problem.
When it comes to Unified Communications Manager the support of T.38 fax relay has been phased in more recently. Therefore, your version of Unified CM is important as well as the call control protocols that you will use between Unified CM and the fax server and Unified CM and the voice gateways that need to handle T.38 fax calls. The table (Table 5) at the following link is a great reference for determining the T.38 support contained in different versions of Unified CM.
Applying the table at the link above to your version of Unified CM, 4.2(3), you can see that T.38 fax relay is supported for the H.323 and MGCP call control protocols. So, the Cisco fax server in your environment would need to be connected to Unified CM with H.323 and T.38 fax calls from the Cisco fax server could only be routed by Unified CM to H.323 or MGCP endpoints.
Also, be aware that it is recommended to configure the Cisco fax server to use H.323 slow start and and to disable H.245 tunneling as these are not supported by Unified CM 4.2(3) but are enabled by default on the Cisco fax server.
I am running Unified CM 4.2(3) and need to connect analog fax machines at remote locations into my Unified CM environment. The gateways at the remotes are a variety of ISR models. Any tips for getting this working?
A variety of transport options exist for transporting fax traffic on ISR gateways in a Unified Communications environment. However, the de facto standard today is the T.38 protocol and unless there is a compelling reason to use a different transport method (like Cisco fax relay or passthrough), T.38 fax relay is recommended as a design best practice by Cisco for transporting fax over IP.
The configuration of T.38 fax relay on Cisco ISR gateways varies depending on the call control protocol being used. If there is a mixture of H.323, MGCP, SCCP, and/or SIP voice gateways in your network then T.38 with an NSE-based switchover is the simplest configuration:
- For H.323 and SIP voice gateways- "fax protocol t38 nse" under the dial-peer or globally under "voice service voip"
- For MGCP voice gateways - "no mgcp t38 fax inhibit" (should already be enabled by default in 12.4T)
- For SCCP voice gateways - "fax protocol t38 nse" configured globally under "voice service voip"
Here are few tips for ensuring successful T.38 fax calls once you have the gateways configured as shown above.
- Faxes in general are sensitive to packet loss. Whereas voice codecs can compensate for packet loss in some cases using interpolation, gap fill, silence fill, etc., T.38 cannot. However, T.38 does have a robust redundancy mechanism that can be enabled if needed. For H.323, SIP, and SCCP see the following ls-redudnacy and hs-redundancy options for the "fax protocol t38" command -
For redundancy on MGCP voice gateways -
- If you are using a compressed voice codec for your initial voice call then by default the fax bandwidth will not exceed the voice codec bandwidth. For example, if you are using G729, an 8 kbps voice codec, then by default the fax call will be forced down to less than 8 kbps, which results in faxes training at a maximum speed of 7200 bps in this scenario for CAC reasons. If you have the bandwidth available, you can configure "fax rate 14400" under the voice dial peer or "mgcp fax rate 14400" for MGCP voice gateways. This will allow the faxes to train at the their maximum speeds and override the default configuration of "fax rate voice".
- If there are any faxes that will connect via a T1/E1 circuit then make sure that these circuits are not showing slips or any other errors. Errors on digital circuits are the number one cause of fax problems in UC environments.
I apologize for such a long response but there is a lot of information and tips for getting faxes working over IP. I tried to cover just the highlights so if you have more specific questions then please let me know.
When two CCM 4.1(3) clusters route calls via intercluster trunks, and cluster 1 has a fax attached to a VG224 configured for SCCP fax pass-through via the 'fax rate disable' command on the dial peer, and cluster 2 has a fax attached to a VG224 configured for MGCP T.38 fax relay, fax attempts fail. I assume this is because of a fax protocol mismatch? Short of a wholesale change of one of the clusters' fax protocol, is there any interim way to get these fax calls to work?
First of all, I am assuming that regular voice calls work between these voice gateways over the intercluster trunk and only upon trying to send a fax does a problem occur?
If this is the case and voice calls are working, then you can try one of the following solutions.
1) My first choice would T.38 fax relay. I am not sure what version of IOS is running on your SCCP VG224 but beginning in 12.4(11)T, T.38 fax relay is supported. Because you are already running T.38 on the MGCP voice gateway then there is nothing to change there. On the SCCP voice gateway under "voice service voip", configure "fax protocol t38 nse". Also, remember to change your current "fax rate disable" configuration to either "fax rate 14400" or another value if you need the bandwidth of fax calls restricted.
2) An alternative solution would be to use NSE-based passthrough. On the MGCP voice gateway you will need the following command, "mgcp modem passthrough voip mode nse". On the SCCP voice gateway, configure "modem passthrough nse codec g711ulaw".
With both configuration methods above, once the voice call is established between the vg224 and MGCP voice gateway, then NSE messages will be used to switch the call to either T.38 fax relay or passthrough once fax tones are detected by the gateway's DSP. Because T.38 is standards-based, consumes much less bandwidth, and has a robust redundancy mechanism for dealing with network impairments, it is the recommended choice for your scenario.
We are planning on upgrading from CM 4.1.(3) to 6.1(2) by the end of the year and would like to integrade a fax solution. We need a real time fax solution able to receive and send faxes from microsoft outlook. please advise!!
My recommendation for a real-time fax solution with support for Microsoft Outlook would be a fax server. There are a large number of fax server vendors and just about all offer Outlook integration.
Cisco has partnered with two fax server vendors and offers two solutions that may work for you. The first solution is the Cisco fax server. The Cisco fax server is designed for centralized, enterprise deployments and offers direct integration with Microsoft Exchange.
The other solution is the AXP-XMediusFAX solution. Designed for branch applications, this full-featured fax server also offers direct integration with Microsoft Exchange for working with Outlook clients. This solution also has the benefit of being contained on the AXP module mounted inside an ISR router. More information on the AXP-XMediusFAX solution can be found at the following link -
Both of these solutions work with Unified CM version 6.1 and offer the same level of interoperability. I do not think that you can go wrong with either one of them. If you have any additional questions after reading through the information in the links above, then please let me know.
Yes, T.37 can be a viable, low cost fax solution. This solution can be easily accomplished by downloading T.37 onramp and offramp TCL scripts from cisco.com and then configuring a Cisco IOS gateway appropriately. If you already have existing Cisco IOS voice gateways and email in your organization, then this probably will not cost you anything and it will provide desktop faxing to users.
However, you should be aware that T.37 also has some disadvantages that make it unsuitable for many organizations. The main disadvantage is that T.37 breaks the real-time nature of the fax transaction. Therefore, T.37 relies on SMTP DSN and MDN messages to relay status and confirmations. Although these messages are potentially useful, they lack wide-ranging support from mail servers and email clients. This, in turn, makes receiving status or delivery information for fax e-mail potentially unreliable. Another disadvantage with Cisco's T.37 implementation is the lack of Error Correction Mode (ECM) support. ECM ensures perfect page quality and will resend any scan lines with errors. Without ECM, Cisco voice gateways running T.37 cannot correct corrupted portions of a page and in rare cases the fax may be unreadable.
T.37 is always a choice worth considering when deciding on how to handle fax communications in IP networks. Just make sure you consider all of its advantages and disadvantages before proceeding with deployment.
I am interested to know whether CVP can be integrated either with Cisco fax server / AXP-XMediusFAX solution based on centralized / branch topology? If Yes, can the fax request be "on demand" over the call / "fax back"
How can we tell if a platform supports T37? I see that there is some mention of requirements in the T37 guide, but it is not all-inclusive. We had someone request it on a UC520, and we installed it - short faxes work fine, but they had trouble with a 22 page fax - they set the resolution down from fine and increased mailbox sizes, and it works, but can't get it to go with setting on fine. I do not see any mention of this platform in the support doc, but what specs they do describe, it does not look like it should be a problem. We have no slips on the PRI. We have a TAC case, but not moving much, and I would feel better with some official word that it actually was supported on this platform..
Hi Mary Beth,
The UC520 supports T.37 just like pretty much all IOS-based voice gateways.
In regards to troubleshooting the PRI, ruling out T1 level errors is always a first step. If the problem is able to be reproduced, then T.37 debugs should show at what point in the call path the fax is failing. I would expect a disconnect on the fax telephony side or on the SMTP side and then you can troubleshoot further from there. Unfortunately, many of the T.37 debugs are complicated to interpret and this can occasionally delay the resolution of T.37 fax cases by TAC.
If I understand your question correctly, you are wondering if Cisco Unifed Customer Voice Portal (CVP), can be integrated directly with the Cisco fax server or the AXP-XMediusFAX solution? I am guessing that you are looking at a solution where users can access fax documents on demand.
I must admit that I have limited knowledge of CVP but I believe that this product administers IVR functionality in IPT networks. Therefore, I would guess that if CVP could access the fax server through a compatible API, then this integration could work. Both the Cisco fax server (Captaris RightFax) and the XmediusFAX server appear to offer an XML API. I am not sure of the programming capabilities of the CVP and if you could get an integration to work over this API or not. Personally, I have never seen this implemented but it is a compelling idea.
David, (have your book, but haven't thoroughtly digested it yet).
TAC recently recommented we use just G.711 or all our faxing even though we only use Cisco devices. It has impoved things, but the QoS reporting in CDR still reports a lot of jitter in the fax calls from our VG224 and 2821/3825 routers. Does the command: 'playout-delay fax' affect faxes when forcing G711 or is the 'playout-delay nominal' the only command that will affect my jitter problem?
Glad to hear you have a copy of the book and I hope that it is a useful resource!
In regards to your question on setting the playout buffer for passthrough, the command "playout-delay fax" only affects calls that transition to Cisco fax relay or T.38 fax relay. As you mentioned, adjusting the playout buffer for fax passthrough calls is the same as adjusting the buffer for voice calls and involves using commands such as "playout-delay nominal".
That's what I figured. If a FAX is on an FXS port, would you recommend I change it from Adaptive to FIXED? (perhaps 500ms nominal/max)?
To give you a point of reference, the playout buffer gets set to a fixed value of 300 ms for Cisco and T.38 fax relay. I would probably start with that same fixed value in your scenario unless your jitter is exceeding that value. Fortunately, fax calls typically have a good tolerance for delay so setting large jitter buffer values rarely have a negative impact on the fax transmission.
What would be the most cost effictive solution for Fax, after T.37? We are using CCM 6.1 and Unity.
400Faxes inbound daily.
Can you please provide some fax solution?
There are a couple of ways to go here. I am assuming that you currently have standalone fax machines that are using dedicated PSTN lines and not using your UC infrastructure? Your goal is to incorporate some sort of IP fax solution into your existing network? If so, here are a few solutions to look at -
1) Simply migrate your existing standalone fax devices over to the UC infrastructure using fax passthrough or fax relay. My recommendation would be to use T.38 fax relay. From a user perspective, the same fax endpoints would be used but the transport would be over IP and you could drop the dedicated analog fax lines for these devices.
2) A fax server solution would also be recommended here but the costs vary depending on the vendor. With a fax server solution, users would be able to send/receive faxes from their desktops or optionally use Multi Function Peripherals (MFP). MFPs combine copying, printing, scanning, and faxing into one device and most have the ability to interface with a fax server.
T.37 is also an alternative that you have already mentioned. From a cost-effective standpoint, the first solution using T.38 or T.37 are probably the best. The T.38 solution does not give you the email integration that T.37 does but it is more reliable and it does not break the real-time nature of the fax transaction that can lead to problems with confirmation and status notifications. If you need additional features or functionality beyond the T.38 and T.37 solutions, then you will probably need to look at getting a dedicated fax server. I hope this helps.