Just like NSE Passthrough, protocol-based pass-through transports fax communications using the G.711 codec. However, instead of using Named Signaling Event (NSE) packets to handle the switchover from voice mode to passthrough mode, protocol-based pass-through utilizes either the H.323 or SIP call control protocol. This allows fax pass-through to interoperate with some third party devices and proxies.
How Protocol-based Pass-through Works
Protocol-based pass-through uses specific messages within the H.323 or SIP call control protocols to switch a voice call to a G.711 passthrough call. In the case of H.323, a normal voice call is set up first. Then, upon the detection of V.21 fax flags by the terminating voice gateway, a switchover to pass-through occurs. The critical H.323 message that is used to communicate the pass-through switchover is the H.245 Request Mode message. The terminating voice gateway notifies the originating voice gateway using this message once it detects the fax tones. The sending of this H.245 Request Mode message leads to the initial voice logical channels being closed and then new G.711 logical channels being opened to properly transport the fax call. The call flow switchover for fax pass-through using the H.323 call control protocol is shown in Figure 1.

Figure 1: Flow Diagram for Fax Pass-through Using the H.323 Call Control Protocol
In the case of the SIP call control protocol and fax pass-through, the important message that is used to signal the switchover is a SIP INVITE message that in this scenario is often referred to as a re-INVITE or mid-call INVITE message. Functionally this message is equivalent to the H.245 Request Mode message. The SIP re-INVITE message is sent by the terminating voice gateway when it detects the V.21 fax flags. Figure 2 demonstrates the call for fax pass-through with SIP as the call control protocol.

Figure 2: Flow Diagram for Fax Pass-through Using the SIP Call Control Protocol
Protocol-based Pass-through Product Support and Configuration Tips
Fax pass-through is only supported on Cisco IOS voice gateways for the H.323 and SIP call control protocols. The command to enable this feature is fax protocol pass-through, which can be configured directly under the VoIP dial peer or globally under voice service voip. A fax pass-through configuration will always take precedence over an NSE-based passthrough configuration if both happened to be enabled at the same time.
Design and Implementation Best Practices
- For implementing fax passthrough with third party devices, such as voice gateways and proxies, protocol-based pass-through is the recommended solution since its uses standards-based call control protocols for the switchover. NSE-based passthrough is Cisco proprietary.
- Because fax pass-through uses the V.21 fax flags as its trigger, it only works for G3 fax calls. Unlike NSE-based passthrough, which works off of CED tone or ANSam tone detection, modem calls and Super G3 fax calls are not supported with protocol-based pass-through.
- This fax transport method is only supported by H.323 and SIP on IOS voice gateways.
- Unlike NSE-based passthrough, redundancy is not available for fax pass-through.
- Fax pass-through has problems working with Unified CM so NSE-based passthrough should be used for gateways attached to Unified CM.
- All forms of passthrough are very sensitive to packet loss, even with redundancy enabled. As little as .1 and.2% packet loss can cause failures.
Troubleshooting Tips
- Make sure that all digital links in the fax path are free from impairments such as slips.
- Confirm that fax pass-through is configured on both the originating and terminating voice gateways. Make sure that an inbound VoIP dial-peer exists on the TGW that is configured for fax protocol pass-through.
- If the voice call establishes correctly but the switchover to fax pass-through and G.711 is not occurring then make sure that the appropriate H.245 Request Modem message is being sent. You can use the command debug h245 asn1 to confirm that the Request Mode message is being sent/received as shown below.
H.245 Request Mode Message from debug h245 asn1
Jan 10 16:57:17.286: H245 MSC INCOMING PDU ::=
value MultimediaSystemControlMessage ::= request : requestMode : { sequenceNumber 1 requestedModes {
{
{ type audioMode : g711Ulaw64k : NULL } } } } value MultimediaSystemControlMessage ::= response : requestModeAck : { sequenceNumber 1 response willTransmitMostPreferredMode : NULL }
|
- If SIP is the call control protocol, you can confirm the transmission of the re_INVITE to switch the codec to G.711 using the command debug ccsip messages. Below is an example of what this SIP re-INVITE message should look like. The bolded SDP lines at the end of this example show the codec switch to G.711ulaw (RTP payload type of 0) and VAD or silence suppression being disabled.
SIP Re-INVITE Message from debug ccsip messages
Apr 2 20:23:15.039: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent: INVITE sip:100@1.1.1.1:5060 SIP/2.0 Via: SIP/2.0/UDP 1.1.1.2:5060;branch=z9hG4bK2D30 From: <sip:200@1.1.1.2>;tag=108A9C-124F To: <sip:100@1.1.1.1>;tag=10B180-57B Date: Mon, 02 Apr 2007 20:23:15 GMT Call-ID: 780921AE-E05111DB-8017B658-496D56BF@1.1.1.1 Supported: 100rel,timer,resource-priority,replaces Min-SE: 1800 Cisco-Guid: 1971344507-3763409371-2148709976-1231902399 User-Agent: Cisco-SIPGateway/IOS-12.x Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER CSeq: 101 INVITE Max-Forwards: 70 Timestamp: 1175545395 Contact: <sip:200@1.1.1.2:5060> Expires: 180 Allow-Events: telephone-event Content-Type: application/sdp Content-Length: 173 v=0 o=CiscoSystemsSIP-GW-UserAgent 1413 1958 IN IP4 1.1.1.2 s=SIP Call c=IN IP4 1.1.1.2 t=0 0 m=audio 18282 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=silenceSupp:off
|