Bug #1683

OsmoNITB - Bug #1604: Easier / more direct SIP integration

osmo-sip-connector: Implement codec selection

Added by zecke almost 2 years ago. Updated about 3 hours ago.

Target version:
Start date:
Due date:
% Done:




We need to select codecs.. There were multiple mails on the OpenBSC list. For GSM MO call we need to check the bearer calls and the availability of channels and then can offer different codecs. The FR vs. HR decision needs to be done early but then codec can be changed.

The MNCC protocol needs to change in many still to be defined ways. This includes:

  • NITB needs to inform which TCH/F.. TCH/H are available
  • RTP_CREATE/RTP_CONNECT needs to include AMR mode-sets
  • Need to test switching codec
  • BTS needs to support Payload2 to allow asymentric PayloadType for the same codec!

msc_mncc_mt_sip_mgcp.png (120 KB) laforge, 03/24/2018 06:48 PM


Related issues

Related to OsmoMSC - Bug #2854: OsmoMSC never updates bearer capability from MNCC Resolved 01/22/2018
Related to OsmoMSC - Feature #2832: MNCC doesn't include field for "supported codecs" New 01/16/2018


#1 Updated by laforge almost 2 years ago

  • Category set to osmo-sip-connector

#2 Updated by laforge about 1 year ago

  • Project changed from OsmoNITB to osmo-sip-connector
  • Category deleted (osmo-sip-connector)

#3 Updated by laforge 5 months ago

  • Priority changed from Normal to High

#4 Updated by laforge 2 months ago

  • Related to Bug #2854: OsmoMSC never updates bearer capability from MNCC added

#5 Updated by laforge about 1 month ago

  • Assignee changed from zecke to sysmocom

#6 Updated by laforge about 7 hours ago

  • Related to Feature #2832: MNCC doesn't include field for "supported codecs" added

#7 Updated by laforge about 3 hours ago

The high-level goals are as follows:
  • respect the codec capabilities of all elements, i.e.
    • the external SIP world (as in the SDP)
    • the MS (bearer capabilities)
    • the BTS+BSC (codec lists in BSSMAP ASSIGNMENT related messages)
  • prefer a non-transcoding situation to any that involves transcoding
  • if transcoding is required, it should happen at the bsc-located OsmoMGW

MT call

  1. INVITE with SDP is received
  2. INVITE is translated to MNCC_SETUP_REQ
    • if the SDP included any GSM related codecs (FR/HR/EFR/AMR), then those codecs should be translated to the MNCC bearer capability field. Otherwise, MNCC bearer capability is omitted (equals any codec/bearer)
    • bearer capabilities should indicate a preference for those (in the same order as the SDP, as it also is ordered by preference). All other codecs shall be listed last, i.e. with lower preference
  3. OsmoMSC triggers paging towards BSC/BTS/...
  4. OsmoMSC sends the CC SETUP to the MT, including CC bearer capabilities translated from the MNCC bearer capabilities
  5. the MT MS responds, possibly with negotiated bearer capabilities, based on its own capabilities
  6. OsmoMSC at some point sends a BSSMAP ASSIGNMENT CMD listing the negotiated codecs
  7. OsmoBSC responds with a BSSMAP ASSIGNMENT COMPLETE, indicating the exact channel type + codec that was chosen (based on available chanels, the BTS model, local policy, ...)
  8. the MT MS responds at some point with a CONNECT (when the user picks up)

All in all, I think the ladder diagram should look like this:

Also available in: Atom PDF