FAX Detection
In some deployments, an originator sends inband fax messages through the Oracle Communications Session Border Controller (SBC) 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 SBC 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 SBC 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 SBC 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 SBC 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 SBC toward the terminating endpoint.
If the SBC 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 SBC sends 2 m-lines so the endpoint can pick its preferred codec from the two.
Call Completion
In the typical case, the SBC 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 SBC and be transcoded between the originator’s codec and the terminator’s codec.
The following call flow shows the typical example:
![This image depicts the OCSBC detecting a FAX attempt. This image depicts the OCSBC detecting a FAX attempt.](img/faxreinviteacceptt38-png.png)
When the terminating endpoint rejects the T.38 reINVITE, and the OFDFB is configured as an add-on-egress codec, the SBC sends a G711 offer toward the call terminator.
![This image depicts the OCSBC detecting a FAX attempt. This image depicts the OCSBC detecting a FAX attempt.](img/faxreinviterejectt38-png.png)
Glare Condition
After not receiving a ReINVITE from either of the endpoints after the configured amount of time, the SBC sends a reINVITE toward the terminating endpoint. If the SBC 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 SBC receives user A’s reply which includes V.21 DCS in the realm where tone detection is enabled. The SBC forwards this tone to user B. Upon no response from user B, the SBC 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 theSBC 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:
![This image depicts the OCSBC detecting a FAX attempt in a re-INVITE. This image depicts the OCSBC detecting a FAX attempt in a re-INVITE.](img/reverse-fax-tone-png.png)
Supporting FAX to UAs that Do Not Support Multiple SDP M-Lines
The Oracle Communications Session Border Controller (SBC) 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 SBC to resolve this problem on a per realm basis via transcoding policy.
There are two scenarios within which the SBC 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 SBC 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 SBC. In the former scenario, the caller’s ReINVITE either offers a single media option in the SDP m-line, in which case the SBC adds the other, or the caller offers both options. Note that the SBC must forward a final response to the caller (or callee) in this scenario. In the latter scenario, the SBC simply recognizes the attempt to start in-line FAX and issues a ReINVITE to support that setup.
You can configure the SBC 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 SBC 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 SBC 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 SBC issues its Re-INVITE with fax-single-m-line set to image-first. The terminating station declines image media type, so the SBC retries, offering audio media type. The terminating station accepts this media type. Note that the SBC 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 20-3 Offer Image First
![This image shows the OCSBC performing FAX detection when the offer presents the image first. This image shows the OCSBC performing FAX detection when the offer presents the image first.](img/fax-reinvites-2mlines-example1.png)
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 SBC issues its Re-INVITE with fax-single-m-line set to audio-first. The terminating station declines audio media type, so the SBC retries, offering image media type. The terminating station accepts this media type. Note that the SBC 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 20-4 Offer Audio First
![This image shows the OCSBC performing FAX detection when the offer presents the audio first. This image shows the OCSBC performing FAX detection when the offer presents the audio first.](img/fax-reinvites-2mlines-example2.png)
FAX Detection and Redirect
You can configure the SBC 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 SBC 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 SBC cannot send the fax transaction to this new endpoint. Instead, the SBC 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 SBC 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.
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 SBC 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 SBC:
- Sends a SIP BYE message to terminate the session established with the IVR and waits for the 200 OK.
- When it receives a 200 OK to the BYE, the SBC 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 SBC clears the call resources.
- The SBC does not send a BYE to the caller after terminating a call with an IVR.
- The SBC selects a fax server from your session-group based on your configured selection criteria.
- The SBC sends an INVITE with an SDP offer based on the codec policy configured on the egress realm of selected fax server.
- When it receives a 200 OK response for the INVITE request sent to the fax server, the SBC 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.
- The SBC 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 SBC 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 SBC behavior is based the response from the caller for the reINVITE. If it receives:
- A 200 OK, the SBC replies with an ACK and begins fax media processing.
- No response, the SBC 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 SBC sends a 491 - Request Pending to the caller.
- If it receives a failure response (4xx/5xx/6xx), the SBC sends the ACK and then two BYEs, towards the caller and the fax server to clear both the call legs.
- 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 SBC sends an ACK, and then a BYE to the fax server. Furthermore, the SBC 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 SBC 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 SBC sequentially tries to INVITE the new address(es). If it does not receive a success response from any of these targets, the SBC 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 SBC clears the transaction by sending a BYE with the reason header Exhausted fax servers to the caller.
Feature Interaction
This feature interacts with additional SBC 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 SBC 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 SBC 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 SBC anchors the media flowing between caller and fax server.
- If disabled and the caller and fax server are on the same realm, the SBC 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 SBC detects a fax tone (CNG), the SBC 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 SBC performs the detect and redirect functions of this feature in this flow, with the results unaffected by any codec policy or manipulation.
![This image depicts FAX Handling with Redirect and No FAX media Transcoding. This image depicts FAX Handling with Redirect and No FAX media Transcoding.](img/fax-redirect-noxcode4.png)
Fax Redirect with Transcoding
The next flow uses codec-policy configurations at several points within the SBC, 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 SBC transcodes the fax media using PCMA on the caller side and T.38 on the fax server side.
![This image depicts FAX Handling with Redirect with FAX media transcoding. This image depicts FAX Handling with Redirect with FAX media transcoding.](img/fax-redirect-xcode3.png)
Fax Redirect with Codec Policy Error and Hunt
This next call flow depicts the SBC 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.
![This image depicts FAX Redirect with a codec policy error and a hunt to an alternate fax server. This image depicts FAX Redirect with a codec policy error and a hunt to an alternate fax server.](img/fax-redirect-xcode6.png)
Fax Redirect Providing Reason Header to Caller
This next call flow depicts the SBC 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 SBC providing the caller with a reason header. The value of the reason header could be "exhausted fax servers", depending on your configuration.
![This image depicts FAX Redirect operating with reason header functionality. This image depicts FAX Redirect operating with reason header functionality.](img/fax-redirect-reasonh.png)
Fax Redirect with ReINVITE During Progress
This next call flow depicts the SBC being interrupted by the caller with a ReINVITE. The SBC responds with “491 Request Pending” to this reINVITE.
![This image depicts FAX Redirect handling an ReINVITE during session establishment. This image depicts FAX Redirect handling an ReINVITE during session establishment.](img/fax-redirect-reinvite.png)
Configure Fax Detect and Redirect
This copy presents task steps removed from their target location to make your review process easier.
- Configure a codec-policy to handle fax traffic.
- Assign that codec-policy to the ingress realm. (This could also be on the caller's session-agent.)
- Configure a session-agent for your target IVR.
- Configure a session-group that lists your target fax machines.