We were planning to enable T.38 for Fax on a VG224 analog gateway under MGCP control. For various reasons we may not be able to use the Carrier we had been planning on that supported T.38 on SIP Trunks, and may now have to use a Carrier that either does not support T.38, or does not do so reliably. For normal voice traffic we still want the Carrier to default to G.729a. We understand that Fax might now have have to go out via G.711 and that this would not be as reliable as T.38.
"An MGCP gateway cannot be configured in order to initiate upspeed to G.711 for Fax Pass-Through. Therefore, any Fax that uses pass-through on the CUBE that terminates to an MGCP gateway must be routed with G.711 codec."
Our question is: Does this mean that the Carrier SIP trunks must now be G.711 by default for all calls, or can they still be G.729a, but for a Fax call G.711 will be negotiated between the Cisco and the Carrier gateways?
Let me start by saying I'm no FAX expert but let me add my 2 cents here.
Generally speaking FAX G711 passthrough is unreliable, specially over an ITSP. This is because T30 (analog signals) were meant for DS0 TDM circuits with NO LOSS, so very little packet loss (as much as 2 packets in a row) will cause your FAX signal to fail middle transaction. Usually this will annoy the users, since the reliability would be impared. How bad is it going to be? Varies on the packet loss over the ITSP network. This is exactly why T38 with redundancy was invented and standarized and it's the de-facto standard for FAX for most ITSP. Having said that really consider a carrier that doesn't support T38, look at the options for another carrier with T38 support. FAX passthrough can theorically work, in a no loss scenario but usually it would be dissapointing.
Having said that, you could still use another codec for your calls, asuming either side can detect fax tones and start a "switchover to G711". Usually either the TELCO or the GW would be listening for FAX tones and start a switchover of the codec to G711.
Thanks. We weren't particularly happy about the prospect of fax pass-through anyway and have been looking at alternatives. Even with T.38, as we investigate Carriers more closely, there are many caveats.
At the end of that Cisco CUBE configuration note for Fax cited in the original post there is an eye opener regarding Cisco's conclusion about Verizon, as well as Cisco's own inability (for now) to deal with the issue. That's only one Carrier example - other issues such as lack of support for ECM with T.38, maximum connection speed restrictions, incompatibility with certain Fax machine models, etc. cloud the picture.
Layered on top of all this are considerrations regarding the control protocol for the VG224 (SCCP or MGCP) if both Fax and analog phones (with full features) are on the gateway and both are expected to survive in failover to an ISR with SRST or MGCP Fallback. It's posible to program the VG224 on a per port basis for SCCP or MGCP, but that just adds administrative complexity.
Starting to make a PRI look interesting again..........................
Well I'm opinion there's nothing like a good old MGCP PRI, where you have control over your Q931.
SIP trunking becomes interesting for the mass, and mixed with MPLS multiservice delivery it's very interesting. FAX is definetly a tricky aspect and I just can't believe the world has not aged out the faxing by now, come on it's 2013 already we should be having flying cars not arguing about FAX :P.
It's definitely irritating to be constrained by Fax considerations. Unfortunately, we have numerous Fax machines (most not heavily used) with no prospect of reduction in quantity or use of a Fax server. I'd give up the flying cars if Carriers and PBX vendors would all just fully and reliably implement T.38.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...