FAX Detection
In some deployments, an originator sends inband fax messages through the Oracle® Enterprise Session Border Controller (ESBC) to terminating endpoints that do not support uncompressed codecs. Thus the terminating call leg must communicate FAXes either through out of band T.38 or in-band G.711 codecs. In some cases the terminating endpoint can determine that it is being sent a FAX and send a reINVITE to request that it be sent T.38 FAX instead of inband FAX, thereby switching from an audio call to a FAX call. If the ESBC does not receive this reINVITE, it will send its own reINVITE toward the terminating endpoint to establish the FAX session with a codec the endpoint can support.
The ESBC can detect FAX tones based on the receipt of the DIS Preamble V.21 flag or the CNG/CED tones. These tones are embedded in a faxable codec in the RTP media stream. You must set the tone-detection parameter in the codec policy to fax-cng or fax-v21 as necessary.
Note:
Enabling tone-detection steers all faxable calls through the DSPs thus requiring DSP resources.
Renegotiate Timer
Upon detection of the DIS Preamble V.21 flag or CNG tone, the ESBC starts a configurable tone Detect Renegotiate Timer (tone-detect-renegotiate-timer). The tone detect renegotiate timer parameter is configurable per codec policy and defaults to 500ms. If the ESBC receives a ReINVITE from the originating or terminating endpoint, the tone Detect Renegotiate Timer will be reset and no ReINVITE will be sent from the ESBC toward the terminating endpoint.
If the ESBC does not receive a ReINVITE from the called endpoint before this timer expires, it creates and sends an INVITE to the terminating endpoint.
ReINVITE Codecs
There are two codecs that can be inserted into the reINVITE message: T.38 & G711 (defaulting to PCMU). You configure T.38OFD and/or G711OFD in the add codecs on egress parameter in the codec policy configuration element. These codec names are only used for reINVITEs in this feature. Each one is inserted into the reINVITE’s message body on its own m= line. The ESBC sends 2 m-lines so the endpoint can pick its preferred codec from the two.
Call Completion
In the typical case, the ESBC sends a reINVITE toward the terminating endpoint with the specified codecs. The terminating endpoint replies with a 200OK indicating it can use the specified codec. When this call leg is set up, FAX media will flow through the ESBC and be transcoded between the originator’s codec and the terminator’s codec.
The following call flow shows the typical example:

When the terminating endpoint rejects the T.38 reINVITE, and the OFDFB is configured as an add-on-egress codec, the ESBC sends a G711 offer toward the call terminator.

Glare Condition
After not receiving a ReINVITE from either of the endpoints after the configured amount of time, the ESBC sends a reINVITE toward the terminating endpoint. If the ESBC receives a ReINVITE from either endpoints while waiting for the response to its own reINVITE, it will reject the endpoint-sourced reINVITE with a 491 Request Pending error message.
reINVITE Toward Caller Using Compressed Codec
In some scenarios, the network operator configures tone detection in one realm where uncompressed codecs are used by UAs. The other realm, where compressed codecs are used does not have tone detection enabled. After the call is set up, the compressed side initiates a FAX call. The ESBC receives user A’s reply which includes V.21 DCS in the realm where tone detection is enabled. The ESBC forwards this tone to user B. Upon no response from user B, the ESBC creates and sends it a reINVITE that includes T.38 in the SDP. This action prompts User B to accept and use T.38 so that theESBC can transcode from User A’s FAX via PCMA to User B’s T.38 codec.
The pertinent aspect of this scenario is that the reINVITE is created and sent into the realm where tone-detection parameter is not configured. This behavior is enabled by enabling the reverse-fax-tone-detection-reinvite parameter. For example:

Supporting FAX to UAs that Do Not Support Multiple SDP M-Lines
The Oracle® Enterprise Session Border Controller (ESBC) sometimes supports FAX transcoding scenarios using a Re-INVITE that includes two m-lines in the SDP. Some end stations, however, do not support multiple m-lines, causing the FAX setup to fail. You can configure the ESBC to resolve this problem on a per realm basis via transcoding policy.
There are two scenarios within which the ESBC supports FAX setup by issuing a ReINVITE to a caller (or callee):
- The caller (or callee) issues a ReINVITE indicating it wants to change the call to FAX.
- The caller (or callee) embeds FAX tones in the RTP stream.
For both scenarios, the two options for providing the FAX media type include audio or image. In both scenarios, the ESBC may send a Re-INVITE that offers both media options in the SDP. This allows the caller (or callee) to negotiate media type with the ESBC. In the former scenario, the caller’s ReINVITE either offers a single media option in the SDP m-line, in which case the ESBC adds the other, or the caller offers both options. Note that the ESBC must forward a final response to the caller (or callee) in this scenario. In the latter scenario, the ESBC simply recognizes the attempt to start in-line FAX and issues a ReINVITE to support that setup.
You can configure the ESBC to remedy the lack of support for multiple m-lines in some stations by offering one media type at a time using the codec-policy element’s fax-single-m-line parameter. When you configure this parameter, the ESBC offers either audio or image media type in the ReINVITE. Should the callee reject the offer, with a 488 - Not Acceptable Here message for example, the ESBC sends another ReINVITE with the other media type choice. This negotiation may or may not result in a transcoded media stream. That is, if both end stations negotiate to the same codec, no transcoding is needed.
Example 1 - Offer Image First
This example depicts a transcoding scenario that changes a call to FAX. The initial Re-INVITE arrives offering image as the media type. The ESBC issues its Re-INVITE with fax-single-m-line set to image-first. The terminating station declines image media type, so the ESBC retries, offering audio media type. The terminating station accepts this media type. Note that the ESBC sends its response to the originating station, accepting image media type. Subsequently, the first leg operates with image media type and the second with audio, requiring transcoding.
Figure 14-3 Offer Image First

Example 2 - Offer Audio First
This example depicts a transcoding scenario and configuration that changes a call to FAX. The initial Re-INVITE arrives with 2 m-lines. The ESBC issues its Re-INVITE with fax-single-m-line set to audio-first. The terminating station declines audio media type, so the ESBC retries, offering image media type. The terminating station accepts this media type. Note that the ESBC sets its response to the originating station with audio media type set to port 0. Subsequently, both legs operate with image media type, requiring no transcoding.
Figure 14-4 Offer Audio First
