Modem Tone Detection

You can configure the SBC to detect voiceband data (VBD) modem tones. When modem tones are detected on a transcoded audio call, the SBC will switch to a modem call, issuing a reINVITE to negotiate the VBD codec if necessary, and optimizing the session for modems.

Basic Modem Tone Detection Call Flow

When the DSP or software-based transcoding platform detects modem tones, it raises MODEM type events which identify the specific modem tone that was detected. The events are reported to Middlebox Control Daemon (MBCD), and then to sipd. When sipd receives the notification, the SBC sends the reINVITE to whichever side has the modem codecs added on egress. To ensure successful modem calls, Oracle recommends configuring modem codecs on egress for both core and access side.

In typical call flows, MBCD media-flow updates are sent immediately after the reINVITE is sent. However, for modem calls, these updates are not sent until the reINVITEs have been accepted with a 200 OK. If the renegotiation results in an untranscoded call (for example, if both sides use G.711A for the modem tones), the DSP resources are released after the 200 OK.

After the modem call is established with the 200 OK, sipd ignores any subsequent tone detection events, and any subsequent reINVITEs are rejected with a 488 response.

See Call Flows for Modem Tone Detection for detailed call flows.

Modem Optimizations

When a modem call is in session, the SBC makes the following optimizations:

  • Disable:
    • Adaptive noise reduction
    • Adaptive dejittering
    • Packet loss concealment
    • Comfort noise
    • Silence suppression
  • Enable optimized data pass-through

Supported Tones

The SBC supports the following VBD tones:

  • On the answerer side:
    • ANS (2100 Hz)
    • /ANS (phase reversals)
    • ANSam (AM modulated)
    • /ANSam (phase+AM)
    • Bell103 (2225 Hz)
    • V.21 High (1650 Hz)
    • V.23 High (1300 Hz)
    • V.22/V.22bis (2250 Hz)
    • V.22/V.22bis (2250Hz+1800 Hz)
    • V.8bis (Segment-1)
    • V.18 (Baudot FSK)
  • On the originator side:
    • Bell103 (1270 Hz)
    • V.21 Low (980 Hz)
    • V.25 (1300Hz Calling Tone)
    • V.8bis (Segment-1)
    • V.18 (Baudot FSK)

Note:

Software-based transcoding can only detect ANS-family tones.

Reporting on Modem Tone Detection

You can see whether modem tones were detected for a session that remained transcoded by using the show xcode session-byid command on the ACLI.

The command output includes:

  • Media Mode = Audio for audio-only sessions
  • Media Mode = Modem for modem sessions

Note:

If the reINVITE negotiation results in a non-transcoded call (for example, both sides agree on G711A for the modem call), Media Mode information is not available for the non-transcoded call.

Logging and Statistics for Modem Tone Detection

You can review the log.sipd and log.xserv logs for modem tone detection information. The logs identify the tone in the following format:

Modem-direction-name

where direction is Ans or Orig, depending on the direction the tone came from and name is the name of the tone.

For example, a V.22/V.22bis 2250Hz+1800Hz tone detected on the answer side would be logged as Modem-Ans-V22+1800Hz.

The tone information is also captured in the mbcd statistics collection, which you can review with the show mbcd statistics command.

HA Support for Modem Tone Detection

In HA deployments, the codec-policy configurations for modem tone detection are synchronized between the active and standby SBC.

Redundancy journal entries also contain modem call state, indicating whether the reINVITE has been:

  • Sent to the caller
  • Sent to the receiver
  • Completed by the caller (caller sent 200 OK)
  • Completed by the receiver (receiver sent 200 OK)
  • Completed on both sides (both sent 200 OK)

The synchronization between active and standby happens after the first reINVITE for a modem call completes.

In normal call flows, DSP resources are released as soon as the reINVITE is issued. For modem tone detection, however, the DSP resources are not released and further modem tone detection is not disabled until the reINVITE is complete on both sides. In an HA switchover scenario, this allows the newly active SBC to keep listening for modem tones if the switchover happens before the first reINVITE is complete. If more modem tones are detected, the newly active SBC resends the reINVITE. If no more modem tones are detected before the guard timer elapses, the newly active SBC ends the call.

If switchover happens after the modem session has been established, the session continues as normal, with the newly active SBC transcoding if needed.

Modem Tone Detection Limitations

  • This feature is only supported on RTP calls that are already connected and being transcoded.
  • The SBC only listens for modem tones in the first 30 seconds of the call. After 30 seconds, modem tone detection is disabled. If you want to listen for more than 30 seconds, you can set a new timeout value in a custom CSV file. See Customize Modem Tone Detection Settings.
  • For calls with multiple m= lines, this feature is only supported when the first line is audio, with a valid media port. In the reINVITE to negotiate the modem codecs, the first m= line is changed to G.711 (A or U), and all other m= lines are marked as inactive, with the port set to 0.
  • After modem tones are first detected, tone detection is disabled. No further tones will be detected for the duration of the call.
  • You can enable both FAX and modem tone detection at the same time, but whichever tone is detected first in a call will be used. As soon as one type of tone is detected, no further tones will be detected for the duration of the call. This means:
    • If FAX tones are detected first, FAX processing is initiated and subsequent modem tones are ignored.
    • If modem tones are detected first, modem tone transmission is initiated and subsequent FAX tones are ignored.
  • Software-based transcoding can only detect ANS-family tones.
  • You can configure a codec-policy to detect modem tones come from one side at a time, either answerer or originator. The same codec-policy cannot detect both.
  • The SBC will send a=ptime:10 on the reINVITE to negotiate modem tone codecs and both sides are expected to send a=ptime:10 and a=silenceSupp:off - - - - in the 200 OK response to the reINVITE. This ptime applies only to the modem tone portion of the call; the previously-established transcoded call may use different ptimes.
  • Oracle recommends configuring the codec-policy for both core and access sides to add modem tones on egress. This causes the SBC to issue a reINVITE to both sides when modem tones are detected, ensuring that ptime is set correctly on both sides so that the modem call can proceed.
  • The following scenarios are not supported for modem tone detection:
    • SRTP
    • Pooled transcoding (T-SBC)
    • Interaction with add-sdp-invite