Voice Calls

Service Options

SO1 uses RC1, while SO32768 uses the higher-rate RC2 traffic channel. EVRC calls normally use RC3 when the handset supports it and fall back to RC1 when needed. The voice.supported_service_options list in msc.json selects which of these codecs the MSC may propose for mobile-terminated calls. The first implemented option in the list is the default.

Call Flow

Mobile-Originated (MO)

Mobile-Terminated (MT)

If the mobile is idle, the network pages it and assigns a traffic channel:

If the mobile already has an active traffic channel, the BSC starts MT service negotiation on that channel instead of paging again. For a packet-data traffic channel, SO33 can be replaced by the negotiated voice service on connection reference 0; once voice connects, the old packet session is closed through the PCF boundary. If the mobile rejects the voice negotiation, only the proposed voice leg is released and the existing channel can remain active.

Initiate MT calls via the MSC management InitiateCall RPC or the web dashboard. Compatibility routes may still call through the management facade while the management split completes.

Call Routing

When a mobile originates a call, the MSC owns call policy and media orchestration while the BSC executes the radio leg. The BSC sends the mobile’s Layer 3 request over A1; the MSC decides whether to route the call to another mobile, local WAV playback, or the external SIP gateway.

MS-to-MS Bridging

When two mobiles are both registered, the MSC bridges their A2p bearer frames between the two BSC radio legs — mobile-to-mobile calls without external infrastructure. The two handsets may use different supported codecs; the MSC transcodes between them. If the callee already has a traffic channel, the callee leg reuses that channel and starts voice service negotiation in place instead of forcing a new page cycle.

A2p Voice Bearer

The MSC/BSC voice bearer is a per-circuit A2p RTP/UDP session. Assignment Request and Assignment Complete carry bearer session parameters so each circuit gets its own RTP socket pair. Media uses the codec selected for that circuit; QCELP 13K uses the A2p 13K vocoder format, while the EVRC variants use their matching EVRC formats. The BSC adds or removes the CDMA MuxPDU header on the Abis/air-interface side.

This keeps call control and bearer media separate:

SIP Voice Gateway

The voice gateway enables mobile-originated calls to reach the PSTN or SIP peers. It runs as a separate process (cdma-voice-gw) and provides SIP/RTP interop plus QCELP/EVRC↔G.711 transcoding. The MSC owns the gateway client, control stream, and media routing; the BSC only handles the radio leg.

Architecture

CDMA Handset → BTS → BSC ⇄ A1/A2p ⇄ MSC media/control → Voice Gateway → SIP INVITE → PSTN/SIP Peer
                                                   ↕
                                      QCELP/EVRC ↔ G.711 transcoding
                                           RTP send/receive

MO-to-PSTN Flow

Capabilities

MSC Configuration

In config/msc.local.json:

{
  "voice": {
    "gateway": {
      "enabled": true,
      "endpoint": "http://127.0.0.1:17015",
      "fallback_to_wav": true
    }
  }
}

When fallback_to_wav is true and the gateway is unreachable, calls fall back to WAV playback.

See Voice Gateway Setup for full gateway configuration.

Caller ID (AWIM)

The BSC delivers caller ID to the mobile in an Alert With Information Message (AWIM) Calling Party Number record per C.S0005-E 3.7.5.10 / ANSI T1.607. Two fields on the record describe how the mobile should interpret the digits, and both are configurable per subscriber from the subscriber edit page.

Number Type (3 bits)

Numbering Plan (4 bits)

The on-air digits field is always ASCII 0-9; the BSC sanitizes stored phone numbers (stripping any non-digits and truncating to E.164’s 15-digit maximum) before they’re encoded. Defaults Network specific + ISDN / E.164 preserve the previous hardcoded behavior.

Voice Rates

Custom Ringtones

Each subscriber can have a custom ringtone that plays in place of the standard ringback tone when they are called. Upload a WAV file from the subscriber edit page in the web dashboard.

The audio loops until the call connects. If no ringtone is uploaded, or anything goes wrong fetching it, the standard ringback tone is used.

Converting MP3 (or other formats) to WAV

Only WAV is accepted by the upload form. Convert with ffmpeg, downmixing to mono, resampling to 8 kHz, and truncating to 60 seconds. Voice playback is 8 kHz mono anyway, so this matches what the HLR produces internally and keeps the upload comfortably under the 4 MB cap.

ffmpeg -i ringtone.mp3 -t 60 -ac 1 -ar 8000 -sample_fmt s16 \
       -af "silenceremove=start_periods=1:start_silence=0:start_threshold=-50dB" \
       ringtone.wav

-t 60 caps the output at 60 seconds. At 8 kHz mono 16-bit, that’s about 1 MB. A default ffmpeg -i in.mp3 out.wav keeps the source’s sample rate and channels and can easily produce a 50+ MB file.

The silenceremove filter trims leading silence (anything below -50 dB) so playback starts right at the first audible audio. MP3 files almost always have 50–300 ms of encoder padding at the start, which would otherwise show up as a noticeable pause before the ringtone is heard.

WAV Playback

For testing (or when no gateway is configured), MO calls play a WAV file. In config/msc.local.json:

{ "voice": { "wav_file": "path/to/audio.wav" } }