When MGCP-based fax relay is disabled, MGCP networks use passthrough for fax relay transmission. However, when MGCP-based fax relay is enabled, ITU-T T.38 support is added, providing a standardized method of supporting reliable fax transmission in the MGCP network. With MGCP-based fax relay, interworking is allowed between the T.38 application that already exists on Cisco gateways and the MGCP applications on call agents (CAs).
MGCP-based fax relay provides two modes of implementation: gateway-controlled mode and CA-controlled mode. In gateway-controlled mode, a gateway advertises its capabilities using Session Description Protocol (SDP) messages during the establishment of a call, using the call-control protocol that was used to establish the call. After the call is established, the connected gateways negotiate the actual switch from voice to T.38 fax relay by exchanging named signaling event (NSE) or named telephony event (NTE) messages embedded in the RTP stream. That transmission is transparent to the CA, which knows only about the voice call. Gateway-controlled mode allows you to use MGCP-based fax relay (T.38) without upgrading the CA software to support the capability.
In CA-controlled mode, the gateways rely on the MGCP CA to direct the T.38 fax relay call flow.
Gateway-Controlled MGCP T.38 Fax Relay
In gateway-controlled mode, the gateways do not need instruction from the CA to switch to T.38 mode. This mode should be used if the CA has not been upgraded to support T.38 and MGCP interworking or if the CA does not want to manage fax calls.
Gateway-controlled mode can also be used to bypass the message delay overhead caused by CA handling; for example, to meet time requirements for switchover to T.38 mode. If the CA does not specify a mode to the gateway, the gateway defaults to gateway-controlled mode.
In gateway-controlled mode, the gateways exchange NSEs that provide the following services:
- Instruct the peer gateway to switch to T.38 for the call.
- Either acknowledge the switch and a readiness to accept packets or indicate that a gateway cannot accept T.38 packets.
MGCP-based fax relay in gateway-controlled mode uses the following call flow:
- An incoming 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 passthrough is used for fax transmission. If both gateways do 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 that it had as a voice call. If this failure occurs, a fallback to fax passthrough 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 CA instructs the gateway to do otherwise. If the CA has been configured to control fax relay, the CA instructs the gateway on processing the call with the fx: extension of the local connection option (LCO).
CA-Controlled MGCP T.38 Fax Relay
CA-controlled MGCP T.38 fax relay 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. In Cisco IOS Release 12.3(1) and later releases, the feature has been modified. The new method supersedes previous methods for CA-controlled fax relay and introduces the following gateway capabilities to enable this functionality:
- Ability 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.
- Ability to accept a new port when switching from voice to fax transmission during a call. This new ability allows successful T.38 CA-controlled fax between H.323 and MGCP gateways for those occasions in which the H.323 gateway assigns a new port when changing the call type from voice to fax. New ports are assigned in H.323 gateways using Cisco IOS images from Release 12.2(2)T to Release 12.2(7.5)T. Note that gateways in MGCP-to-MGCP fax calls simply reuse the same port. CA-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.
Note |
The CA-controlled mode described in this document makes obsolete the previous method that was described in Media Gateway Control Protocol-Based Fax (T.38) and Dual Tone Multifrequency (IETF RFC 2833) Relay . The previous CA-controlled mode for T.38 fax relay used the ca parameter to communicate with the call agent, and the ca parameter is no longer supported as of Cisco IOS Release 12.3(1). The previous method has been superseded by the CA-controlled mode described in this document. Note that the gateway (GW)-controlled mode that is described in the previous document remains supported and is the same as the GW-controlled mode that is described in this document.
|
The sequence for T.38 CA-controlled fax is as follows:
- The MGCP call agent determines that CA-controlled mode is necessary for fax relay because the far end of the connection is an H.323 gateway or other entity incapable of directly negotiating T.38 with the Cisco IOS MGCP gateway.
- The call agent establishes a voice call with the local MGCP gateway and specifies that any subsequent fax transmissions should take place using T.38 fax relay in CA-controlled mode. The call agent includes an "fxr/fx:t38" or "fxr/fx:t38-loose" parameter in the Local Connection Options parameter of the Create Connection (CRCX) command that it sends to the MGCP gateway. The term "loose" indicates that a description of T.38 capabilities is not required in the resulting Session Description Protocol (SDP) message.
- When the voice call is established between the gateways, the call agent asks the MGCP gateway to notify it of any T.38 events with an "R: fxr/t38" requested event parameter in a Notification Request(RQNT) or Modify Connection (MDCX) command. If the MGCP gateway detects fax transmission during this call, it generates a Notify (NTFY) command with an "O: fxr/t38(start)" observed event parameter and sends it to the call agent.
- The call agent responds with an MDCX containing one or both of the following:
- "a:image/t38" descriptor in the Local Connection Options parameter
- "m=image port udptl t38" line in the included SDP message
Note that port is replaced in the MDCX with the actual port number for the fax transmission. This port number can be the same as or different from the port number negotiated earlier when the voice call was established. T.38 CA-controlled fax supports either using the same port or switching to a new port for fax. Note that if the MGCP gateway does not detect fax first, it may receive the same MDCX prior to sending a NTFY.
- When the fax transmission is complete, the MGCP gateway sends the call agent a NTFY command with an "O: fxr/t38(stop)" parameter. The call agent then has the option of either sending another MDCX to return to voice or using a Delete Connection (DLCX) command to terminate the call.
MGCP T.38 Fax Relay Interworking with Cisco H.323 and SIP Gateways
Some MGCP call agents do not properly pass those portions of Session Description Protocol (SDP) messages that advertise T.38 and NSE capabilities. As a result, gateways that are controlled by these call agents are unable to use NSEs to signal T.38 fax relay to other gateways that use NSEs. As of Cisco IOS Release 12.2(13)T, you can configure gateways to use T.38 fax relay and NSEs even though those gateways may be unable to negotiate those attributes by themselves at the time of call setup.
The mgcp fax t38 gateway force command provides a way to ensure gateway-controlled T.38 fax relay between an MGCP gateway and another gateway. The other gateway in the negotiation can be an H.323, Session Initiation Protocol (SIP), or MGCP gateway. Both gateways must be configured to use NSEs to signal T.38 fax relay mode switchover. On H.323 and SIP gateways, use the fax protocol t38 nse force command to specify the use of NSEs for T.38 fax relay. On MGCP gateways, use the mgcp fax t38 gateway force command.
NSEs are the Cisco-proprietary version of named telephony events (NTEs), which are defined in IETF RFC 2833. NSEs and NTEs are used to communicate telephony signaling events that are normally indicated by the presence of tones, such as dual-tone multifrequency (DTMF) or fax transmissions. NSEs and NTEs do not transmit audible signaling tones across the network, but instead work by sending a binary code that is later used to recreate a tone. NSEs use different values to represent events and tones than NTEs use.
NSEs and NTEs are passed in the media stream. They consist of Real-Time Transport Protocol (RTP) packets that have the same source and destination IP addresses and User Datagram Protocol (UDP) ports as the rest of the media stream. However, NSE and NTE packets use different RTP payload types than the rest of the media stream so that they can stand apart from the audio packets in the stream. NSEs are normally sent with RTP payload type 100.