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

FAX Detection and Redirect

You can configure the ESBC to detect fax signaling within a SIP call and redirect those calls directly to a group of one or more fax servers. By default, the ESBC sends a reINVITE either to a caller or calling party, based on your setting for the reverse-fax-tone-detection-reinvite parameter, when it detects a fax tone from the media stream. There are some call flows, however, that need redirection to the FAX endpoint without using this reINVITE. You can configure this support by setting the fax-servers parameter with the name of an applicable session-agent-group on the applicable session-agent. When enabled, the Fax Redirect feature takes precedence over the above mentioned legacy fax functionality.

Note:

This feature is dependent on specific DSP resources and, therefore, is not available when deployed on platforms that do not support transcoding. Refer to your version's release notes to determine which platforms apply.

Within the context of fax call flows that can use this feature, incoming audio/fax calls are often initially answered by an auto attendant or interactive voice response (IVR) service before going to a target fax server. Without configuring the fax-servers parameter, the ESBC cannot send the fax transaction to this new endpoint. Instead, the ESBC sends a reINVITE to the calling/caller side based on your reverse-fax-tone-detection-reinvite configuration.

To support fax re-direct, you configure:

• A session-agent object for each target fax server. Each session-agent should include:
  • A realm-id to ensure proper routing. The ESBC does not consult local-policy to route the request, instead using the fax server’s information on the IVR’s session-agent.
  • A codec-policy that includes add-codecs-on-egress configured with G711OFD, T.38OFD or both.
• A session-group that includes:
  • The dest parameter configured with the names of each target fax server's session-agent.
  • sag-recursion enabled.
  • Your selected strategy.
• A session-agent for the IVR. This agent needs the name of the applicable session-group configured on the fax-servers parameter.
• A codec-policy on each realm that sends applicable fax traffic. These should include:
  • add-codecs-on-egress configured with G711OFD, T.38OFD or both.
  • tone-detection configured with CNG.
  Use at least one of G711OFD/T.38OFD codecs in this policy to send an offer with faxable codecs to the fax server.

  Note:

  If the policy has no fax codecs, this feature still sends egress offers to the fax server, but the faxes fail.
• A codec-policy on each applicable ingress realm that includes:
  • tone-detection configured with CNG.
  • add-codecs-on-egress configured with G711OFD, T.38OFD or both.

If you enable reverse-fax-tone-detection-reinvite on the ingress codec-policy, you must have at least one tone detection codec (G711OFD/T.38OFD) configured on the egress codec-policy associated with the egress peer. If not, the ESBC cannot detect fax tone.

For example, if you enable reverse-fax-tone-detection-reinvite on the codec-policy in the caller's realm, you must also configure the IVR session agent's codec-policy to add G711OFD, T.38OFD or both using the add-codecs-on-egress parameter .

Each codec-policy discussed above includes additional configuration that you can use to refine your media management of these flows. Consider additional codec-policy configuration, such as adding or removing specific codecs, to enhance your individual deployments.

With this feature configured and triggered by fax tone detection, the ESBC:

1. Sends a SIP BYE message to terminate the session established with the IVR and waits for the 200 OK.
2. When it receives a 200 OK to the BYE, the ESBC deletes both the east and west side flows to release the media resources consumed by the audio call. If there is no reply from IVR before the BYE transaction times out, the ESBC clears the call resources.
3. The ESBC does not send a BYE to the caller after terminating a call with an IVR.
4. The ESBC selects a fax server from your session-group based on your configured selection criteria.
5. The ESBC sends an INVITE with an SDP offer based on the codec policy configured on the egress realm of selected fax server.
6. When it receives a 200 OK response for the INVITE request sent to the fax server, the ESBC creates a new client dialog. It then adds this client dialog to the call session, modifies media flows, and sends an ACK to the fax server.
7. The ESBC sends a reINVITE towards the caller.

This reINVITE provides the caller with the new media IP/port allocated from the steering pool for the new media flows. Although the ESBC uses the SDP originally negotiated with caller side, it updates the media IP/port and session version number in this SDP without consulting the egress codec-policy configured on caller’s realm.

Ensuing ESBC behavior is based the response from the caller for the reINVITE. If it receives:

• A 200 OK, the ESBC replies with an ACK and begins fax media processing.
• No response, the ESBC sends two BYEs, towards the fax server and the caller after the reINVITE transaction times out.
• A reINVITE/UPDATE from the caller while it is creating a session with a fax server, the ESBC sends a 491 - Request Pending to the caller.
• If it receives a failure response (4xx/5xx/6xx), the ESBC sends the ACK and then two BYEs, towards the caller and the fax server to clear both the call legs.

Regarding the selection of a target fax server, enabling sag-recursion on your fax group ensures the ESBC recurses through your entire session-group. Otherwise, the ESBC attempts to reach the first fax server only. When enabled, the ESBC:

• Tries to reach the next fax server in your group if it receives 4xx or 5xx responses from its target.
• Terminates recursion through your group if it receives a 6xx response from any fax server in your group.
• Terminates recursion through your group if it receives any response configured in the stop-sag-recurse parameter.

Additional functionality includes:

• If it receives a 200 OK with a different SDP, the ESBC sends an ACK, and then a BYE to the fax server. Furthermore, the ESBC does not try any other server, instead sending a BYE to the caller with a reason header containing the message Exhausted fax servers.
• If it does not receive any response from a target, the ESBC waits for the transaction timeout, then tries the next target in your session-group.
• If it receives a re-direct (3xx) response from the fax server, the ESBC sequentially tries to INVITE the new address(es). If it does not receive a success response from any of these targets, the ESBC resumes recursion through your session-group.
• If it receives no response, including no 100 Trying, from a specific fax server, the system retransmits this request. Once the transaction times out, the system sends an INVITE request to the next fax server in the list.
• If it receives no successful response from any target in your session-group, the ESBC clears the transaction by sending a BYE with the reason header Exhausted fax servers to the caller.

Feature Interaction

This feature interacts with additional ESBC configuration that affects its behavior, including:

• Transcoding—This feature uses transcoding to support G.711 to T.38 conversion and for detecting fax tones.
• PRACK-interworking—You can use this to handle/respond to any reliable provisional responses received from the fax-server.
• UPDATE-interworking—You can use this to convert any UPDATE received from the fax server to a re-INVITE towards the caller.
• sag-recursion—The ESBC adheres to all recursion configuration affecting your session-group, including stop-sag-recurse, sip-recursion-policy and stop-recurse.
• multiple m-lines on fax codec—Disable the fax-single-m-line parameter in the applicable codec-policy to allow the ESBC to initiate offers with both G711(PCMU) and T.38.
• mm-in-realm:
  • If enabled and the caller and fax-server are on the same realm, the ESBC anchors the media flowing between caller and fax server.
  • If disabled and the caller and fax server are on the same realm, the ESBC releases the media, allowing it to flow directly between the caller and the fax server.

Related Configuration Considerations

Note the following related configurations and their effect within the context of this feature:

• Ensure that you have the fax-continue-session parameter set to none (default ) on both the ingress and egress realm's sip-interface elements.
• Ensure that you have the fax-single-m-line parameter set to disabled (default ) on your codec-policy.
• If you have configured both G711OFD and T.38OFD in the egress codec-policy, the system adds an internal m-line when the SDP has only a single m-line. If the answerer selects this internal m-line, the fax fails.
• You can enable fax tone detection on both sides of your redirect configuration, caller and IVR. If so, you must consider your reverse-fax-tone-detection-reinvite setting. If you enable tone-detection on the IVR, and the ESBC detects a fax tone (CNG), the ESBC honors your reverse-fax-tone-detection-reinvite configuration on IVR's codec-policy and performs its default re-INVITE behavior instead of redirecting the call.

Reporting on FAX Group Statistics

The show fax-group stats command shows the number of successful and unsuccessful fax calls for all fax server groups or on a per-fax server group basis. The system rotates these statistics from the Period to the Lifetime section every 100 seconds

show fax-group stats | [fax-group name]

High Availability

This feature fully supports HA deployments.

Call Flows for Fax with Redirect

This section presents call flows using the Fax with Redirect feature to display the signaling in greater detail.

Fax Redirect without Transcoding

One of the simplest call flows for this FAX Handling with Redirect feature does not include transcoding of the fax media. The ESBC performs the detect and redirect functions of this feature in this flow, with the results unaffected by any codec policy or manipulation.

Fax Redirect with Transcoding

The next flow uses codec-policy configurations at several points within the ESBC, including an ingress policy on the caller's realm, an egress policy on either the IVR realm or session agent configuration, and an egress policy on the selected fax server's session agent configuration. After the initial signaling and fax detection, the ESBC transcodes the fax media using PCMA on the caller side and T.38 on the fax server side.

Fax Redirect with Codec Policy Error and Hunt

This next call flow depicts the ESBC recursing through the fax group to find a second target. There can be many reasons to search the server list. Some issues end the call, but the issue in this flow, The session agent for FAX Server 1 has a codec policy that does not add a faxable codec to it, but the agent for FAX server 2 does. In this case, the error interrupts the flow, but the system continues with the call, ultimately succeeding with FAX Server 2.

Fax Redirect Providing Reason Header to Caller

This next call flow depicts the ESBC recursing through the fax group to find a second target, with both the first and second fax server responding that they are busy. The key functionality here is the ESBC providing the caller with a reason header. The value of the reason header could be "exhausted fax servers", depending on your configuration.

Fax Redirect with ReINVITE During Progress

This next call flow depicts the ESBC being interrupted by the caller with a ReINVITE. The ESBC responds with “491 Request Pending” to this reINVITE.

Configure Fax Detect and Redirect

This copy presents task steps removed from their target location to make your review process easier.

Perform the following tasks before applying this configuration:

1. Configure a codec-policy to handle fax traffic.
2. Assign that codec-policy to the ingress realm. (This could also be on the caller's session-agent.)
3. Configure a session-agent for your target IVR.
4. Configure a session-group that lists your target fax machines.

1. Access your target IVR session-agent configuration element.

   ORACLE# configure terminal
   ORACLE(configure)# session-router
   ORACLE(session-router)# session-agent
   ORACLE(session-agent)# select

2. Select the session-agent you have configured for your target IVR.
3. Use the fax-servers parameter to specify the name of the session-agent-group

   ORACLE(session-agent)# fax-servers SAG:MyFaxGroup
   ORACLE(session-agent)#

   The ESBC uses your configured selection rules to determine which member of the group it sends the fax.

Configure reINVITE and Single M Line Behavior for FAX Calls

This procedure highlights the relevant parameters for enabling FAX Calls on reINVITE, and not necessarily all required parameters.

1. Access the codec-policy configuration element.

   ORACLE# configure terminal
   ORACLE(configure)# media-manager
   ORACLE(media-manager)# codec-policy
   ORACLE(codec-policy)# select

2. Select the codec-policy object to edit.

   ORACLE(codec-policy)# select
   <name>:
   1:  name=cp1
   2:  name=cp2
   
   selection: 2
   ORACLE(codec-policy)#

3. add-codecs-on-egress—Set this parameter to either T.38OFD and/or G711OFD depending on the value the m= line should have on reINVITE. You can additionally add the OFDFB value to this parameter to enable the second fallback case.
4. tone-detect-renegotiate-timer—Set this parameter to a value between 50 and 3200 ms.
5. tone-detection—Set this parameter determine which message in FAX setup is used to start FAX transcoding.
   • fax-cng—start FAX transcoding on CNG message
   • fax-v21—start FAX transcoding on V.21 message
6. reverse-fax-tone-detection-reinvite—Set this parameter to enabled for the system to create a T38-ladden reINVITE and send it into the realm opposite of where tone detection is enabled.
7. fax-single-m-line—Set this parameter to the preferred FAX media type for Re-INVITEs to endstations that do not support multiple m-lines. The ESBC issues Re-INVITEs using the configured media type only. Should the negotiation fail, the ESBC issues another Re-INVITE that offers the other media type.
   • disabled—Do not change the SDP (default)
   • image_first—Sends Re-INVITE with m=image as the only m-line in the SDP.
   • audio_first—Sends Re-INVITE with m=audio as the only m-line in the SDP.
8. Type done to save your configuration.