Project

General

Profile

Feature #2551

generalization of OSMUX support in osmo-mgw

Added by laforge over 1 year ago. Updated 6 days ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
-
Start date:
10/06/2017
Due date:
% Done:

0%


Description

The goal here is that OSMUX endpoints are just another endpoint type, and that it should be easy for any program at any level of the network (whether BSC, BSC-NAT, MSC, ...) to simply use OSMUX instead of RTP for media transport. Scenarios to keep in mind are:

  • between OsmoBSC and OsmoMSC
  • between OsmoBSC and OsmoBSCNAT
  • future: between OsmoMSCs or even towards external MNCC handlers

OsmoMGW should be able to support conversion between regular RTP and osmux (and vice-versa). We need to find out how exactly we will map this to MGCP endpoint + connection semantics.


Related issues

Related to OsmoBSC - Feature #2552: Support configuring voice via osmo-mgw as OSMUX instead of RTP New2017-10-06

Related to OsmoBSCNAT - Feature #2553: Support configuring voice via osmo-mgw as OSMUX instead of RTPNew2017-10-06

Related to Cellular Network Infrastructure - Feature #2554: Reference/Demo setup + documentation for use of OsmoBSC+OsmoBSCNAT with OSMUXNew2017-10-06

Related to Cellular Network Infrastructure - Feature #2909: Document user plane handling with BSC+MSC co-located OsmoMGW, Osmux, and outlookNew2018-02-06

History

#1 Updated by laforge over 1 year ago

  • Related to Feature #2552: Support configuring voice via osmo-mgw as OSMUX instead of RTP added

#2 Updated by laforge over 1 year ago

  • Related to Feature #2553: Support configuring voice via osmo-mgw as OSMUX instead of RTP added

#3 Updated by laforge over 1 year ago

  • Related to Feature #2554: Reference/Demo setup + documentation for use of OsmoBSC+OsmoBSCNAT with OSMUX added

#4 Updated by laforge over 1 year ago

  • Target version set to OSMUX Generalization

#5 Updated by laforge about 1 year ago

  • Related to Feature #2909: Document user plane handling with BSC+MSC co-located OsmoMGW, Osmux, and outlook added

#6 Updated by laforge 11 months ago

  • Assignee set to sysmocom

#7 Updated by pespin 7 days ago

Some notes/ideas regarding what needs to be implemented.

That's the required steps (in order) to be added during an MOMT call over AoIP (some information may be missing, it's just RFC).

MO part (1st group of steps):
  • BSC => CM Service Request (Speech Codec Element List) => MSC <---- Here we want to announce we support osmux based on osmo-bsc config [NOT REALLY NEEDED]
  • MSC => CM Service Accept / Reject => BSC <---- Here we may want to accept or reject based on osmo-msc cfg policy (ie, reject if we accept osmux only and BSC doesn't advertise osmux) [NOT REALLY NEEDED].
  • BSC => Setup (Supported Codec List) => MSC <--- Here we want to advertise Osmux on an extra TLV after/inside Supported Codec List
  • MSC => CRCX, MDCX => MGW_msc <--- Since BSC already announced use of Osmux, we manage MGW to use Osmux and retrieve Osmux endp information
  • MSC => Assig Request (Speech Codec List MSC Preferred) => BSC <--- Here MSC has to confirm use of Osmux, providing Osmux endp information it got from MGW_msc
  • BSC => CRCX, MDCX => MGW_bsc <----- Since BSC was already confirmed by MSC to use Osmux and it has remote Osmux endp information, configure the local endpoint to use Osmux and retrieve local Osmux endp information
  • BSC => Assig Complete (Speech Codec Chosen) => MSC <--- Here BSC confirms it uses Osmux, providing Osmux endp information it got from MGW_bsc
MT part (2nd group of steps):
  • MSC => Setup => BSC <-- Here MSC announces it wants to use Osmux (based on policy per BSC it can decide to use it or not)
  • BSC => Call Confirmed (Supportd Codec List) => MSC <-- Here BSC announces it wants to use Osmux. Based on policy (osmux only) it can decide to drop the call.
  • MSC => CRCX, MDCX => MGW_msc <--- Since BSC already announced use of Osmux, we manage MGW to use Osmux and retrieve Osmux endp information
  • MSC => Assig Request (Speech Codec List MSC Preferred) => BSC <--- Here MSC has to confirm use of Osmux, providing Osmux endp information it got from MGW_msc
  • BSC => CRCX, MDCX => MGW_bsc <----- Since BSC was already confirmed by MSC to use Osmux and it has remote Osmux endp information, configure the local endpoint to use Osmux and retrieve local Osmux endp information
  • BSC => Assig Complete (Speech Codec Chosen) => MSC <--- Here BSC confirms it uses Osmux, providing Osmux endp information it got from MGW_bsc
TODO / some dangling sutff:
  • What to do with LCLS?
  • Format of TLVs to announce/confirm use of Osmux and pass its endp info through AoIP
  • Format of messages in MGCP to configure stuff
  • SCCPLite

#8 Updated by pespin 7 days ago

  • Assignee changed from sysmocom to pespin

#9 Updated by pespin 6 days ago

Regarding Osmux confirmation during Assignment Request (MSC->BSC), I see two options:

1)
  • IE AoIP Transport Layer Address (MGW) [48.008 3.2.2.102] contains IP addr + port of Osmux endp of MGW_msc
  • IE Codec List (MSC Preferred) [48.008 3.2.2.103] contains only one "Speech Codec Element", defined as us by Osmux and containing the CID as one of the up-to-3 Configuration octets. To define Osmux Codec Type, we use "Codec Type" == 0xf and then use the entire next octet "Extended Codec Type" with some value defined by us, for instance 0xf0.
  • This is fine in the case we announce Osmux by means of an extra T field in BSC->MSC CC Setup, because BSC already announced it supports it.
  • BSC will answer with Assigment Complete with AoIP Transport layer Address IE containing its Osmux Ipv4/v6+port, and IE "Codec Chosen" with the Osmux one sent by MSC to it (patching CID to local one if needed?).
2)
  • We add a new TLV to Assignment Request specific to handle Osmux case, containing IPv4/v6 + port + CID
  • If BSC allows Osmux, it will take this new TLV into account instead of the Speech Codec List ones.
  • Drawback: We still need to allocate a regular RTP endp in MGW_msc and announce it in IE AoIP Transport Layer Address (MGW) [48.008 3.2.2.102].
  • If BSC wants RTP, it will answer with an RTP addr in IE AoIP Transport Layer Address and some RTP codec in "Chosen Codec", and no Osmux
  • If Osmux is wanted, then we don't care about values in IE AoIP Transport Layer Address and IE "Chosen Codec" and we put everything (ipv4+port+CID) into the new Osmux TLV we add.

So far option 1 seems the more elegant one.

#10 Updated by pespin 6 days ago

So after discussing some bits with laforge :

  • It's better to avoid overloading/extending existing IEs/TLVs and add custom ones for osmux (that means not adding a new type in "Extended Codec Type" as mentioned before.
  • Layer3 / DTAP messages shouldn't be patched, those belong to the MS
As a result, best option is, in Assign Request to:
  • Fill IE AoIP Transport Layer Address (MGW) [48.008 3.2.2.102] with osmux MGW_msc endp.
  • Leave "Extended Codec Type" empty, or add only one elem with support for AMR 5.9 (since Osmux uses that AMR type).
  • Add an extra TV Osmux IE containing CID to be used.

Something important to keep in mind: Since MSC announces the AoIP MGW endp addr during Assign Request, it means the MSC must know beforehand whether that BSC wants to use Osmux or wants to use RTP, because those endp are different and MSC must request one to MGW through MGCP. That means BSC needs to "announce" it supports Osmux at some point before doing first call, otherwise MSC doesn't know which type of endpoint to allocate. Harald suggested patching BSSMAP RESET or COMPL_L3_INFO instead to announce Osmux support.

If we patch BSSMAP RESET or COMPL_L3_INFO, we need to be careful with "hotplug changes" in osmux policy in the BSC, for instance disabling osmux support in the VTY while BSC is running. If we want to support this kind of hotplug disabling, we need to announce that to the MSC somehow so next time MSC sends an Assig Request it allocates and announces the proper MGW_msc endpoint.

#11 Updated by laforge 6 days ago

Hi Pau,

On Tue, Apr 16, 2019 at 11:58:31AM +0000, wrote:

If we patch BSSMAP RESET or COMPL_L3_INFO, we need to be careful with "hotplug changes" in osmux policy in the BSC, for instance disabling osmux support in the VTY while BSC is running. If we want to support this kind of hotplug disabling, we need to announce that to the MSC somehow so next time MSC sends an Assig Request it allocates and announces the proper MGW_msc endpoint.

I'd say:

  1. we simply don't execute any change of the BSC behavior as per the VTY setting until the next time a RESET has happened - and
  2. we offer a way to manually trigger the reset from the VTY (if we don't have that, that's a useful feature anyway).

#12 Updated by pespin 6 days ago

  • Status changed from New to In Progress

I pushed some changes I did to osmo-bsc, osmo-mgw and libosmocore, all in branch pespin/osmux. This should help as a good proof of concept.

Current state:
  • osmo-bsc got a new VTY command under "msc" node: osmux (off|on|only)
  • osmo-bsc adds our extension IE GSM0808_IE_OSMO_OSMUX_SUPPORT (0xf0) during BSSMAP RESET (ACK) to announce osmux support to MSC
  • osmo-bsc checks for same extension IE during BSSMAP RESET (ACK) receive (this may actually not be needed because MSC is always the first confirmiming osmux through Assig req)
  • upon receive of Assig Request with our extension IE GSM0808_IE_OSMO_OSMUX_CID (0xf1), which contains the MSC_mgw CID, osmo-bsc instructs its MGW to use Osmux by asking "CRXC osmuxbridge/*@mgw". Answered "*" is going to be the local CID.
  • osmo-mgw still lacks supporting osmuxbrdige and currentlty returns "FAIL": "The transaction could not be executed, because the endpoint is unknown. (500)"
  • osmo-msc still unimplemented, I'm testing by hardcoding use_osmux in osmo-bsc Assig Request after parsing for now. I leave this one for later specially since code bomb there is in process of being merged.

Next step: implement osmuxbridge using libosmo-netif osmux API in osmo-mgw.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)