Project

General

Profile

Bug #1683

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

osmo-sip-connector: Implement codec selection

Added by zecke over 2 years ago. Updated 4 months ago.

Status:
New
Priority:
High
Assignee:
sysmocom
Target version:
-
Start date:
03/31/2016
Due date:
% Done:

10%

Estimated time:
Resolution:

Description

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 View msc_mncc_mt_sip_mgcp.png 120 KB laforge, 03/24/2018 06:48 PM
msc_mncc_mo_sip_rel18x_mgcp.png View msc_mncc_mo_sip_rel18x_mgcp.png 149 KB proposed MO call with reliable 18x option laforge, 03/26/2018 08:36 PM
msc_mncc_mo_sip_mgcp.png View msc_mncc_mo_sip_mgcp.png 142 KB proposed MO call without reliable 18x option laforge, 03/26/2018 08:36 PM
3028
3036
3037

Related issues

Related to OsmoMSC - Bug #2854: OsmoMSC never updates bearer capability from MNCCResolved2018-01-22

Related to OsmoMSC - Feature #2832: MNCC doesn't include field for "supported codecs"New2018-01-16

Related to OsmoMGW - Bug #3114: libosmo-mgcp doesn't properly deal with SDP containing multiple codecsResolved2018-03-26

Related to OsmoMGW - Bug #3115: libosmo-mgcp_client isn't able to properly encode SDP with multiple codec optionsResolved2018-03-26

History

#1 Updated by laforge about 2 years ago

  • Category set to osmo-sip-connector

#2 Updated by laforge over 1 year ago

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

#3 Updated by laforge 8 months ago

  • Priority changed from Normal to High

#4 Updated by laforge 6 months ago

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

#5 Updated by laforge 5 months ago

  • Assignee changed from zecke to sysmocom

#6 Updated by laforge 4 months ago

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

#7 Updated by laforge 4 months ago

3028
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:

#8 Updated by zecke 4 months ago

A pre-selection could already be made at the time of paging? GSM 08.08 holds "Channel Needed" to indicate if a Full rate or Dual rate channel should be required. This makes it more complicated but maybe it still fits in the design? Otherwise this looks great!

#9 Updated by laforge 4 months ago

  • Related to Bug #3114: libosmo-mgcp doesn't properly deal with SDP containing multiple codecs added

#10 Updated by laforge 4 months ago

  • Related to Bug #3115: libosmo-mgcp_client isn't able to properly encode SDP with multiple codec options added

#11 Updated by laforge 4 months ago

After working on this for another two days, I have identified the following problems:

Policy

The question is what is the operator policy / optimzation target here? It could be

  1. perform as little transcoding as possible. This would possibly mean using more FR (TCH/F) than AMR/HR (TCH/H) assuming that the SIP peer supports FR natively but not AMR
  2. use radio resources as efficiently as possible. In this case we'd prefer AMR/HR over anything else and would then end up transcoding potentially every call if the SIP peer doesn't support AMR.
I guess both cases have their usefullness, so the policy would have to be configurable:
  • case a (avoid transcoding) is useful if the machine running OsmoMGW is cpu constrained (like a deeply embedded system)
  • case b (optimize radio resources) makes sense in all cases where sufficient transcoding capacity is available

MO call: SDP from SIP side will arrive late ("200 OK" to INVITE)

  • in classic SIP, the offer of codecs is made in INVITE, and the response only in "200 OK"
    • this means for MO we couldn't select the least common denominator between GSM and SIP side (to avoid transcoding) until the SIP UA has already picked up the phone.
    • RFC3262 offers the option to send the response SDP in "Reliable 18x" responses. The question is: Who supports this? If support is wide-spread this would be a solution. We would then request reliable 18x responses and wait with the BSSMAP Assignment until we have the "180 Ringing" from the SIP side, at which point we can try to assign a channel with the codec supported by the SIP side to avoid transcoding.

osmo-mgw / libosmo-mgcp[-client] shortcomings

  • libosmo-mgcp_client doesn't seem capable of properly encoding SDP with multiple codec options (rtpmap) :( #3115
  • libosmo-mgcp seems capable of properly parsing SDP with many codec options (rtpmap) but then only passes up to two from the parser upwards :( - see mgcp_rtp_end.codec and mgcp_rtp_end.alt_codec #3114

complete MNCC breakage in OsmoMSC

osmo-msc contains funny bits of code like hard-coding the RTP payload type in the MNCC_RTP_CREATE to "0", rather than using any of the actual codecs, see e.g.

»·······/* FIXME: This has to be set to some meaningful value,
»······· * before the MSC-Split, this value was pulled from
»······· * lchan->abis_ip.rtp_payload */
»·······uint32_t payload_type = 0;

This is absolutely not acceptable and basically breaks functionality of MNCC beyond expectations. In my testing, osmo-sip-connector is never able to find a common codec between the SIP and GSM side, as the SIP side of course is right to accept any re-definition of a non-dynamic RTP payload type "0".

#12 Updated by laforge 4 months ago

3036
3037

proposed MO call with reliable 18x option

proposed MO call with reliable 18x option

proposed MO call without reliable 18x option

proposed MO call without reliable 18x option

#13 Updated by laforge 4 months ago

On Mon, Mar 26, 2018 at 03:48:21PM +0000, zecke [REDMINE] wrote:

A pre-selection could already be made at the time of paging? GSM 08.08 holds "Channel Needed" to indicate if a Full rate or Dual rate channel should be required.

OsmoBSC will to my knowledge ignore that, as we always use late assignment these days.
So it will use the "smallest available" channel to handle the signaling until the cal
goes into alerting state, when the BSSMAP assignment is used.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)