VoIP Fundamentals (Considering VoIP Design Elements) Part 5

SIP T.38 Fax Relay

Figure 2-12 illustrates a SIP T.38 relay operation. 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.

SIP T.38 Fax Relay Operation

Figure 2-12 SIP T.38 Fax Relay Operation

Initially, a normal VoIP call is established using SIP INVITE messages. The DSP needs to be informed that it can support T.38 mode while it is put into voice mode. Then, 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 message mid-call to signal the desire to change the media stream.

The SIP T.38 fax relay call flow is as follows:

1. 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.

2. At anytime during the life of the call, if a fax answer or calling tone (ANSam or CED) is heard, the DSP does not interfere with the speech processing. The ANSam or CED tone causes a switch to modem pass-through, if enabled, to allow the tone to pass cleanly to the remote fax.


3. 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 TGW) 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 OGW

4. The TGW detects a fax V21 flag sequence and sends an INVITE message with T.38 details in the SDP field to the OGW or to the SIP proxy server, depending on the network topology.

5. The OGW receives the INVITE message and sends back a 200 OK message.

6. The TGW acknowledges the 200 OK message and sends an ACK message directly to the OGW.

7. The OGW starts sending T.38 UDP packets instead of VoIP UDP packets across the same ports.

8. At the end of the fax transmission, another INVITE message can be sent to return to VoIP mode.

MGCP T.38 Fax Relay

The MGCP T.38 fax relay feature conforms to ITU-T T.38, "Procedures for real-time Group 3 (G3) facsimile communication over IP networks," which determines procedures for real-time facsimile communication in various External Gateway Control Protocol (XGCP) applications.

MGCP T.38 fax relay provides two modes of implementation:

■ Gateway-controlled mode: Gateways negotiate fax relay transmission by exchanging capability information in SDP messages. Transmission of SDP messages is transparent to the call agent. Gateway-controlled mode allows the use of a MGCP-based T.38 fax without the necessity of upgrading the call agent software to support the feature.

■ Call agent-controlled mode: Call agents use MGCP messaging to instruct gateways to process fax traffic. For MGCP T.38 fax relay, call agents can also instruct gateways to revert to gateway-controlled mode if the call agent is unable to handle the fax control messaging traffic, as is the case in overloaded or congested networks.

MGCP-based T.38 fax relay enables interworking between the T.38 application that already exists on Cisco gateways and the MGCP applications on call agents.

Following is the call flow for an MGCP-based T.38 fax relay:

1. A call is initially established as a voice call.

2. The gateways advertise capabilities in an SDP exchange during connection establishment.

3. 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.

4. 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.

Gateway-Controlled MGCP T.38 Fax Relay

In gateway-controlled mode, a call agent uses the fx: extension of the local connection option (LCO) to instruct a gateway how to process a call. Gateways do not need instruction from the call agent to switch to T.38 mode. This mode is used if the call agent has not been upgraded to support T.38 and MGCP interworking, or if the call agent does not want to manage fax calls. Gateway-controlled mode can also be used to bypass the message delay overhead caused by call agent handling (for example, to meet time requirements for switchover to T.38 mode). If the call agent does not specify the mode to the gateway, the gateway defaults to gateway-controlled mode.

In gateway-controlled mode, the gateways exchange NSEs by performing these steps:

1. Instruct the peer gateway to switch to T.38 for a fax transmission.

2. Either acknowledge the switch and the readiness of the gateway to accept T.38 packets or indicate that the gateway cannot accept T.38 packets.

CA-Controlled MGCP T.38 Fax Relay

In call-agent-controlled mode, the call agent can instruct the gateway to switch to T.38 for a call. In Cisco IOS Release 12.3(1) and later releases, call-agent-controlled mode enables T.38 fax relay interworking between H.323 gateways and MGCP gateways and between two MGCP gateways under the control of a call agent. This feature supersedes previous methods for call-agent-controlled fax relay and introduces these gateway capabilities:

■ The capability to accept the MGCP FXR package, to receive the fxr prefix in commands from the call agent, and to send the fxr prefix in notifications to the call agent.

■ The capability to accept a new port when switching from voice to fax transmission during a call. This new capability allows successful T.38 call-agent-controlled fax communications between H.323 and MGCP gateways in those situations in which the H.323 gateway assigns a new port when changing a call from voice to fax. New ports are assigned in H.323 gateways using images from Cisco IOS Release 12.2(2)T through Cisco IOS Release 12.2(7.5)T. MGCP gateways in MGCP-to-MGCP fax calls reuse the same port, but call-agent-controlled T.38 fax relay enables MGCP gateways to handle both situations, either switching to a new port or reusing the same port, as directed by the call agent.

DTMF Support

DTMF is the tone generated on a touchtone phone when keypad digits are pressed. Gateways send these tones in the RTP stream by default. This default behavior is fine when the voice stream is sent uncompressed, but problems arise when sending voice across slower WAN links using compression algorithms, as illustrated in Figure 2-13.

The Need for DTMF Support

Figure 2-13 The Need for DTMF Support

During a call, DTMF digits might be entered to access IVR systems, such as voice mail or automated banking services. Although DTMF is usually transported accurately when using high-bit-rate voice codecs such as G.711, low-bit-rate codecs such as G.729 and G.723.1 are highly optimized for voice patterns and tend to distort DTMF tones. As a result, IVR systems might not correctly recognize the tones.

DTMF relay solves the problem of DTMF distortion by transporting DTMF tones "out of band," or separate from the RTP voice stream.

H.323 DTMF Support

Cisco gateways currently support four methods of DTMF relay using H.323:

■ Cisco-proprietary: DTMF tones are sent in the same RTP channel as voice data. However, the DTMF tones are encoded differently from the voice samples and are identified as payload type 121, which enables the receiver to identify them as DTMF tones. This method requires the use of Cisco gateways at both the originating and terminating endpoints of the H.323 call.

■ H.245 Alphanumeric: Separates the DTMF digits from the voice stream and sends them through the H.245 signaling channel instead of through the RTP channel. The tones are transported in H.245 User Input Indication messages. The H.245 signaling channel is a reliable channel, so the packets that transport the DTMF tones are guaranteed to be delivered. This method does not send tone length information.

■ H.245 Signal: This method does pass along tone length information, thereby addressing a potential problem with the alphanumeric method. This method is optional on H.323 gateways.

Note All H.323 Version 2 compliant systems are required to support the "h245-alphanumeric" method, whereas support of the "h245-signal" method is optional.

■ NTEs: Transports DTMF tones in RTP packets according to section 3 of RFC 2833. RFC 2833 defines formats of NTE RTP packets used to transport DTMF digits, hook flash, and other telephony events between two peer endpoints. With the NTE method, the endpoints perform per-call negotiation of the DTMF relay method. They also negotiate to determine the payload type value for the NTE RTP packets. As a result, DTMF tones are communicated via RTP packets, using an RTP payload type that prevents the tones from being compressed via the codec being used to encode the voice traffic.

MGCP DTMF Support

The four current implementations of MGCP-based DTMF relay include

■ Cisco proprietary: DSPs on the gateways send and receive DTMF digits in-band in the voice RTP stream but code them differently so they can be identified by the receiver as DTMF tones.

■ NSE: Conforms to RFC 2833 to provide a standardized method of DTMF transport using NTEs in RTP packets. RFC 2833 support is standards-based and allows greater interoperability with other gateways and call agents.

■ NTE: Provides for two modes of implementation:

■ Gateway-controlled mode: In gateway-controlled mode, the gateways negotiate DTMF transmission by exchanging capability information in SDP messages. That transmission is transparent to the call agent. Gateway-controlled mode allows the use of the DTMF relay feature without upgrading the call agent software to support the feature.

■ Call agent-controlled mode: In call-agent-controlled mode, call agents use MGCP messaging to instruct gateways to process DTMF traffic.

■ Out-of-band: Sends the tones as signals to Cisco Unified Communications Manager out-of-band over the control channel. Cisco Unified Communications Manager interprets the signals and passes them on.

SIP DTMF Support

SIP gateways can use Cisco proprietary NOTIFY-based out-of-band DTMF relay. In addition, NOTIFY-based out-of-band DTMF relay can also be used by analog phones attached to analog voice ports on the router.

NOTIFY-based out-of-band DTMF relay sends messages bidirectionally between the originating and terminating gateways for a DTMF event during a call. If multiple DTMF relay mechanisms are enabled on a SIP dial peer and are negotiated successfully, NOTIFY-based out-of-band DTMF relay takes precedence.

The originating gateway sends an Invite message with SIP Call-Info header to indicate the use of the NOTIFY-based out-of-band DTMF relay. The terminating gateway acknowledges the message with an 18x or 200 Response message, also using the Call-Info header. Whenever a DTMF event occurs, the gateway sends a SIP NOTIFY message for that event after the SIP Invite and 18x or 200 Response messages negotiate the NOTIFY-based out-of-band DTMF relay mechanism. In response, the gateway expects to receive a 200 OK message. The NOTIFY-based out-of-band DTMF relay mechanism is similar to the DTMF message format described in RFC 2833.

Next post:

Previous post: