OsmoNITB - Bug #1604: Easier / more direct SIP integration
osmo-sip-connector: Implement codec selection
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!
#7 Updated by laforge about 3 hours ago
- File msc_mncc_mt_sip_mgcp.png added
- % Done changed from 0 to 10
- 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
- INVITE with SDP is received
- 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
- OsmoMSC triggers paging towards BSC/BTS/...
- OsmoMSC sends the CC SETUP to the MT, including CC bearer capabilities translated from the MNCC bearer capabilities
- the MT MS responds, possibly with negotiated bearer capabilities, based on its own capabilities
- OsmoMSC at some point sends a BSSMAP ASSIGNMENT CMD listing the negotiated codecs
- 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, ...)
- 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: