Cisco IOS Voice Troubleshooting and Monitoring -- Fax Call Flow
(Added required metadata template)
|(One intermediate revision not shown)|
|Line 1:||Line 1:|
The following fax call flows are described:
The following fax call flows are described:
Latest revision as of 18:38, 16 October 2012
The following fax call flows are described:
Fax Pass-Through and Fax Pass-Through with Upspeed
Fax pass-through is the simplest technique for sending fax over IP networks, but it is not the default, nor is it the most desirable method of supporting fax over IP. T.38 fax relay provides a more reliable and error-free method of sending faxes over an IP network, but some third-party H.323 and SIP implementations do not support T.38 fax relay. These same implementations often support fax pass-through.
In fax pass-through mode, gateways do not distinguish between a fax call and a voice call. Fax communication between the two fax machines is carried in its entirety in-band over a voice call. Fax upspeed is similar to pass-through in the sense that the fax call is carried in-band over the voice call. The difference is that when you use upspeed, the gateways to some extent react to the fax call. Although relay mechanisms are not employed, with upspeed the gateways do recognize a CED fax tone and automatically change the voice codec to G.711 if necessary (thus the designation upspeed). Turn off echo cancellation (EC) and voice activity detection (VAD) for the duration of the call.
When a DSP is put into voice mode at the beginning of a VoIP call, the DSP is informed by the call control stack whether the control protocol can support pass-through or not. If pass-through is supported, the following events occur during a fax call:
- For the duration of the call, the DSP listens for the 2100-Hz CED tone to detect a fax or modem on the line.
- If the CED tone is heard, an internal event is generated to alert the call control stack that a fax or modem changeover is required.
- The call control stack on the originating gateway instructs the DSP to send an NSE to the terminating gateway, informing the terminating gateway of the request to carry out a codec change.
- If the terminating gateway supports NSEs, it responds to the originating gateway instruction and loads the new codec. The fax machines are able to communicate on an end-to-end basis with no further intervention by the voice gateways.
Fax pass-through call flow is shown in Figure: Fax Pass-Through and Fax Upspeed Call Flow.
Figure: Fax Pass-Through and Fax Upspeed Call Flow
Cisco Fax Relay
Cisco fax relay is the oldest method of supporting fax on Cisco IOS gateways and has been supported since Cisco IOS Release 11.3. Cisco fax relay uses Real-Time Transport Protocol (RTP) as the method of transport. In Cisco fax relay mode, gateways terminate T.30 fax signaling by spoofing a virtual fax machine to the locally attached fax machine. The gateways use a Cisco-proprietary fax-relay RTP-based protocol to communicate between them.
Cisco fax relay is the default operation and, in the absence of any explicit CLI on the dial peer, is used when a fax transmission is detected. If voice calls are being completed successfully between two routers, fax calls should also work. Events that occur during a Cisco fax relay call fall into the following call phases:
Cisco Fax Relay Fax Setup Phase
When a DSP is put into voice mode at the beginning of a VoIP call, the DSP is informed by the call control stack whether fax relay is supported and if it is supported, whether it is Cisco fax relay or T.38 fax relay. If Cisco fax relay is supported, the following events occur:
- Initially a VoIP call is established as if it were a normal speech call. Call control procedures are followed and the DSP is put into voice mode, after which human speech is expected to be received and processed.
|Note:||If a fax answer or calling tone (CED or CNG) is heard at any time during the call, the DSP does not interfere with the speech processing. It allows the tone to continue across the VoIP call leg.|
- A normal fax machine, after generating a CED or hearing a CNG, sends a DIS message with the capabilities of the fax machine.
- The DSP in the Cisco IOS gateway attached to the fax machine that generated the DIS message (normally the terminating gateway) detects the HDLC flag sequence at the start of the DIS message and initiates fax relay switchover.
- The DSP also triggers an internal event to notify the call control stack that fax switchover is required. The call control stack then instructs the DSP to change the RTP payload type to 96 and to send this payload type to the originating gateway.
- When the DSP on the originating gateway receives an RTP packet with payload type set to 96, it triggers an event informing its own call control stack that a fax changeover has been requested by the remote gateway.
- The originating gateway then sends an RTP packet to the terminating gateway with payload type 97 to indicate that the originating gateway has started the fax changeover. When the terminating gateway receives the payload type 97 packet, the packet serves as an acknowledgement. The terminating gateway starts the fax codec download and is ready for fax relay.
- Once the originating gateway has completed the codec download, it sends RTP packets with payload type 96 to the terminating gateway. The terminating gateway responds with an RTP packet with payload type 97, and fax relay can begin between the two gateways. As part of the fax codec download, other parameters such as VAD, jitter buffers, and echo cancellation are changed to suit the different characteristics of a fax call.
Cisco fax relay fax setup is shown in Figure: Cisco Fax Relay Fax Setup Call Flow.
Figure: Cisco Fax Relay Fax Setup Call Flow
Cisco Fax Relay Data Transfer Phase
During fax relay operation, the T.30 analog fax signals are received from the PSTN or from a directly attached fax machine. The T.30 fax signals are demodulated by a DSP on the gateway and then packetized and sent across the VoIP network as data. The terminating gateway decodes the data stream and remodulates the T.30 analog fax signals to be sent to the PSTN or to a destination fax machine.
The messages that are demodulated and remodulated are predominantly the phase B, phase D, and phase E messages of a T.30 transaction. Most of the messages are passed across without any interference, but certain messages are modified according to the constraints of the VoIP network.
During phase B, fax machines interrogate each other's capabilities. They expect to communicate with each other across a 64-kbps PSTN circuit, and they attempt to make best use of the available bandwidth and circuit quality of a 64-kbps voice path. However, in a VoIP network, the fax machines do not have a 64-kbps PSTN circuit available. The bandwidth per call is probably less than 64 kbps, and the circuit is not considered a clear circuit.
Because transmission paths in VoIP networks are more limited than in the PSTN, Cisco IOS CLI is used to adjust fax settings on the VoIP dial peer. The adjusted fax settings restrict the facilities that are available to fax machines across the VoIP call leg and are also used to modify values in DIS and NSF messages that are received from fax machines.
The call flow of the Cisco fax relay data transfer phase is shown in Figure: Cisco Fax Relay Data Transfer Call Flow.
Figure: Cisco Fax Relay Data Transfer Call Flow
T.38 Fax Relay
T.38 provides an ITU-T standards-based method and protocols for fax relay. Data is packetized and encapsulated according to the T.38 standard. The encoding of the packet headers and the mechanism to switch from VoIP mode to fax relay mode are clearly defined in the specification. Annexes to the basic specification include details for operation under Session Initiation Protocol (SIP) and H.323 call control protocols.
T.38 uses data redundancy to compensate for packet loss. During T.38 call establishment, voice gateways indicate the level of packet redundancy that they incorporate in their transmission of facsimile User Datagram Packet Transport Layer packets (UDPTLs). The level of redundancy (the number of times that the packet is repeated) can be configured on Cisco IOS gateways.
There is work under way to implement T.38 fax switchover independently of the call control mechanisms. This is referred to as "bearer level signaling" and makes use of Named Signaling Events (NSEs).
The following sections address call-control-initiated switchover mechanisms:
H.323 T.38 Fax Relay
The T.38 Annex B standard defines the mechanism that is used to switch over from voice mode to T.38 fax mode during a call. The ability to support T.38 must be indicated during the initial VoIP call setup. If the DSP on the gateway is capable of supporting T.38 mode, this information is indicated during the H.245 negotiation procedures as part of the regular H.323 VoIP call setup.
Once the VoIP call setup is completed, the DSP continues to listen for a fax tone. When it hears one, the DSP signals the receipt of fax tone to the call control layer, which then initiates fax changeover as specified in the T.38 Annex B procedures. The H.245 message flow shown in Figure: H.323 T.38 Fax Relay Call Flow contains the following events:
- The detecting terminating gateway sends a ModeRequest message to the originating gateway, and the originating gateway responds with a ModeRequestAck.
- The originating gateway sends a closeLogicalChannel message to close its VoIP UDP port, and the terminating gateway responds with a closeLogicalChannelAck while it closes the VoIP port.
- The originating gateway sends an openLogicalChannel message that indicates to which port to send the T.38 UDP information on the originating gateway, and the terminating gateway responds with an openLogicalChannelAck.
- The terminating gateway sends a closeLogicalChannel message to close its VoIP UDP port, and the originating gateway responds with a closeLogicalChannelAck.
- Finally the terminating gateway sends an openLogicalChannel message that indicates to which port to send the T.38 UDP stream, and the originating gateway responds with an openLogicalChannelAck.
- T.38-encoded UDP packets flow back and forth. At the end of the fax transmission, either gateway can initiate another ModeRequest message to return to VoIP mode.
Figure: H.323 T.38 Fax Relay Call Flow
SIP T.38 Fax Relay
When the call control protocol is SIP, T.38 Annex D procedures are used for the changeover from VoIP to fax mode during a call. Initially, a normal VoIP call is established through the use of SIP INVITEs. The DSP needs to be informed that it can support T.38 mode while it is put into voice mode. During the call, when the DSP detects fax HDLC flags, it signals the detection of the flags to the call control layer, and the call control layer initiates a SIP INVITE mid-call to signal the desire to change the media stream.
The SIP T.38 fax relay call flow shown in Figure: SIP T.38 Fax Relay Call Flow contains the following events:
- The terminating gateway detects a fax V.21 flag sequence and sends an INVITE with T.38 details in the SDP field to the originating gateway or to the SIP proxy server, depending on the network topology.
- The originating gateway receives the INVITE message and sends back a 200 OK message.
- The terminating gateway acknowledges the 200 OK message and sends an ACK message direct to the originating gateway.
- The originating gateway starts sending T.38 UDP packets instead of VoIP UDP packets across the same ports.
- At the end of the fax transmission, another INVITE message can be sent to return to VoIP mode.
Figure: SIP T.38 Fax Relay Call Flow
MGCP T.38 Fax Relay
MGCP T.38 fax relay conforms to ITU-T T.38, Procedures for Real-Time Group 3 Facsimile Communication over IP Networks, which determines procedures for real-time facsimile communication in various gateway control protocol (XGCP) applications.
MGCP-based T.38 fax relay has the following call flow:
- A call is initially established as a voice call.
- The gateways advertise capabilities in an SDP exchange during connection establishment.
- If both gateways do not support T.38 fax relay, fax pass-through is used for fax transmission. If both gateways support T.38, they attempt to switch to T.38 upon fax tone detection. The existing audio channel is used for T.38 fax relay, and the existing connection port is reused to minimize delay. If failure occurs at some point during the switch to T.38, the call reverts to the original settings it had as a voice call. If this failure occurs, a fallback to fax pass-through is not supported.
- Upon completion of the fax image transfer, the connection remains established and reverts to a voice call using the previously designated codec, unless the call agent instructs the gateways to do otherwise.
A fax relay MGCP event allows the gateway to notify the call agent of the status (start, stop, or failure) of T.38 processing for the connection. This event is sent in both call-agent-controlled and gateway-controlled mode.
T.37 Store-and-Forward Fax
T.37 provides an ITU-T standards-based method for store-and-forward fax operation. The fax transmission process is divided into distinct sending and receiving phases with the potential to store the fax between sending and receiving, if necessary.
Cisco recommends that you dedicate a mail server to fax mail and avoid the conflicting configuration requirements of traditional e-mail and fax-mail servers. Optimize each mail server for its individual functions-for example, fax messages should usually retry transmissions every 5 minutes whereas normal e-mail should retry every 30 minutes, and fax messages should give up after 3 to 4 hours whereas normal e-mail should not give up for 4 to 5 days.
A topology for T.37 store-and-forward fax is shown in Figure: T.37 Store-and-Forward Fax Topology.
Figure: T.37 Store-and-Forward Fax Topology
For more information about T.37 store and forward fax, refer to Configuring T.37 Store-and-Forward Fax.