VoIP Fundamentals (Considering VoIP Design Elements) Part 4

Payload Redundancy

You can enable payload redundancy so the modem pass-through over VoIP switchover causes the gateway to send redundant packets. Redundancy can be enabled in one or both of the gateways. When only a single gateway is configured for redundancy, the other gateway receives the packets correctly, but does not produce redundant packets. When redundancy is enabled, 10 ms sample-sized packets are sent. When redundancy is disabled, 20 ms sample-sized packets are sent.

Note By default, the modem relay over VoIP capability and redundancy are disabled.

Dynamic and Static Jitter Buffers

When gateways detect a data modem, both the originating gateway and the terminating gateway switch from dynamic jitter buffers to static jitter buffers of 200 ms depth. The switch from dynamic to static is designed to compensate for PSTN clocking differences at the originating and terminating gateways. When the modem call is concluded, the voice ports revert to dynamic jitter buffers.

Gateway-Controlled Modem Relay

Beginning with Cisco IOS Release 12.4(4)T, Cisco supports gateway-controlled negotiation parameters for modem relay. This new feature is a non-negotiated, bearer-switched mode for modem transport that does not involve call-agent-assisted negotiation during the call setup. Instead, the negotiation parameters are configured directly on the gateway. These gateway-controlled negotiation parameters use NSEs to indicate the switchover from voice to voice band data to modem relay.

Upon detecting a 2100 Hz tone, the terminating gateway sends an NSE 192 to the originating gateway and switches over to modem pass-through. The terminating gateway also sends an NSE 199 to indicate modem relay. If this event is recognized by the originating gateway, the call occurs as modem relay. If the event is not recognized, the call occurs as modem pass-through.

Because Cisco modem relay uses configured parameters, it removes the signaling dependency from the call agent and allows modem relay support independent of call control. Cisco modem relay can be deployed over any call agent that is capable of setting up a voice connection between gateways, including Cisco Unified Communications Manager, Cisco Unified Communications Manager Express, and the Cisco BTS and PGW soft switches.

The gateway-controlled modem relay parameters are enabled by default when Cisco modem relay is configured. Interestingly, when Cisco modem relay is configured, gateway XID parameter negotiation is always enabled. Gateway XID parameters are negotiated using the SPRT protocol.

Store-and-Forward Fax

The transmitting gateway is referred to as an "on-ramp gateway," and the terminating gateway is referred to as an "off-ramp gateway." Figure 2-8 illustrates the operation of on-ramp and off-ramp gateways.

Store-and-Forward Fax Topology

Figure 2-8 Store-and-Forward Fax Topology

The following are some of the basic characteristics of on- and off-ramp faxing:

■ On-ramp faxing: A voice gateway that handles incoming calls from a standard fax machine or the PSTN converts a traditional G3 fax to an e-mail message with a Tagged Image File Format (TIFF) attachment. The fax e-mail message and attachment are handled by an e-mail server while traversing the packet network and can be stored for later delivery or delivered immediately to a PC or to an off-ramp gateway.

■ Off-ramp faxing: A voice gateway that handles calls going out from the network to a fax machine or the PSTN converts a fax e-mail with a TIFF attachment into a traditional fax format that can be delivered to a standard fax machine or the PSTN.

On-ramp and off-ramp faxing processes can be combined on a single gateway, or they can occur on separate gateways. Store-and-forward fax uses two different interactive voice response (IVR) applications for on-ramp and off-ramp functionality. The applications are implemented in two Toolkit Command Language (TCL) scripts that you can download from Cisco.com.

The basic functionality of store-and-forward fax is facilitated through Simple Mail Transfer Protocol (SMTP), with additional functionality that provides confirmation of delivery using existing SMTP mechanisms, such as Extended Simple Mail Transfer Protocol (ESMTP).

Gateway Signaling Protocols and Fax Pass-Through and Relay

Figure 2-9 illustrates a fax pass-through operation. When a terminating gateway (TGW) detects a called terminal identification (CED) tone from a called fax machine, the TGW exchanges the voice codec that was negotiated during the voice call setup for a G.711 codec and turns off echo cancellation and VAD. This switchover is communicated to the originating gateway (OGW), which allows the fax machines to transfer modem signals as though they were traversing the PSTN. If the voice codec that was configured and negotiated for the VoIP call is G.711 when the CED tone is detected, there is no need to make any changes to the session other than turning off echo cancellation and VAD.

Fax Pass-Through Operation

Figure 2-9 Fax Pass-Through Operation

If pass-through is supported, these events occur:

1. For the duration of the call, the DSP listens for the 2100-Hz CED tone to detect a fax or modem on the line.

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

3. The call control stack on the OGW instructs the DSP to send an NSE to the TGW, informing the TGW of the request to carry out a codec change.

4. If the TGW supports NSEs, it responds to the OGW 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.

Control of fax pass-through is achieved through NSEs that are sent in the RTP stream. NSEs are a Cisco-proprietary version of IETF-standard named telephony events (NTEs), which are specially marked data packets used to digitally convey telephony signaling tones and events. NSEs use different event values than NTEs and are generally sent with RTP payload type 100, whereas NTEs use RTP payload type 101. NSEs and NTEs provide a more reliable way to communicate tones and events using a single packet rather than a series of in-band packets that can be corrupted or partially lost.

Fax pass-through and fax pass-through with up speed use peer-to-peer NSEs within the RTP stream or bearer stream to coordinate codec switchover and the disabling of echo cancellation and VAD. Redundant packets can be sent to improve reliability when the probability of packet loss is high.

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 or not the control protocol can support pass-through.

Cisco Fax Relay

Figure 2-10 illustrates the operation of Cisco Fax Relay.

Cisco Fax Relay Operation

Figure 2-10 Cisco Fax Relay Operation

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:

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 [modified ANSwer tone] 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 (CalliNG) tone, sends a DIS (digital identification signal) 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 High-Level Data Link Control (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. When the DSP on the OGW receives an RTP packet with the payload type set to 96, it triggers an event to inform its own call control stack that a fax changeover has been requested by the remote gateway. The OGW then sends an RTP packet to the TGW with payload type 97 to indicate that the OGW has started the fax changeover. When the TGW receives the payload type 97 packet, the packet serves as an acknowledgement. The TGW starts the fax codec download and is ready for fax relay.

5. After the OGW has completed the codec download, it sends RTP packets with pay-load type 96 to the TGW. The TGW 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.

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

H.323 T.38 Fax Relay

Figure 2-11 illustrates an H.323 T.38 relay operation. The T.38 fax relay feature 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 SIP and H.323 call control protocols.

 H.323 Fax Relay Operation

Figure 2-11 H.323 Fax Relay Operation

Figure 2-11 shows the H.245 message flow:

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 detecting TGW sends a ModeRequest message to the OGW, and the OGW responds with a ModeRequestAck.

5. The OGW sends a closeLogicalChannel message to close its VoIP UDP port, and the TGW responds with a closeLogicalChannelAck message while it closes the VoIP port.

6. The OGW sends an openLogicalChannel message that indicates to which port to send the T.38 UDP information on the OGW, and the TGW responds with an openLogicalChannelAck message.

7. The TGW sends a closeLogicalChannel message to close its VoIP UDP port, and the OGW responds with a closeLogicalChannelAck message.

8. The TGW sends an openLogicalChannel message that indicates to which port to send the T.38 UDP stream, and the OGW responds with an openLogicalChannelAck message.

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

T.38 fax relay uses data redundancy to accommodate packet loss. During T.38 call establishment, voice gateways indicate the level of packet redundancy they incorporate in their transmission of fax UDP transport layer packets. The level of redundancy (the number of times the packet is repeated) can be configured on Cisco IOS gateways.

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

After the VoIP call setup is completed, the DSP continues to listen for a fax tone. When a fax tone is heard, the DSP signals the receipt of the fax tone to the call control layer, which then initiates fax changeover as specified in the T.38 Annex B procedures.

Next post:

Previous post: