Feature #4092

Osmux: Support dynamic allocation of osmux sockets

Added by pespin over 1 year ago. Updated over 1 year ago.

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


Spec Reference:


Initial idea came from #2551 (no need to read all that):

Right now, we have 1 unique Osmux socket per MGW instance.

Osmux streams (one direction) are identified by tuple: <srcIPaddr, srcPort, dstIPaddr, dstPort, dstCID>
Since we currently only have 1 socket, dstIPaddr and dstPort are constant, so we identify received messages by: <srcIPaddr, srcPort, dstCID>.

if the other peer is behind a NAT, srcIPaddr and srcPort are not really reliable easily, so we can only rely on dstCID to identify streams, and thus we share the CID range against all BSCs or connections.
We actually do something similar for RTP, let's think about it:
tuple identified by: <srcIPaddr, srcPort, dstIPaddr, dstPort, dstCID>, but in this case dstPort changes per-conn, so we actually identify streams per dstPort in this case.

So in Osmux streams, we identify based on dstCID, and in RTP, in dstPort. The problem is that dstCID is actually in range 0..255, which means we can get out of CIDs (not like with ports, were range is a lot higher).

In order to improve this situation (only 255 concurrent call legs in MGW using Osmux), here's my proposal:

VTY specifies an osmux IP (IPmsc) and a port range (PORTmsc1..100), or a port to start counting from, and dynamically allocates/binds and closes ports based on demand. These ports are allocated in MGW based on received MGCP <remoteIP,remotePort> tuple. This way we end up having 256 CIDs per <remoteIP,remotePort> tuple, aka per BSC, and which is the same, per <localPort>. Each BSC can actually open new osmux sockets themselves once the first one is full, meaning each BSC can handle also unlimited CIDs, and MSC will be fine because upon receival of this new <remoteIP,remotePort> tuple, a new osmux socket will be created.

All that also plays well with the fact that we want to group Osmux CIDs under same <remotIP,remotePort>, since the trunk frames need to be sent to that same address.

So summary, in MGW:
  • Add a table to match <remoteIP,remotePort> <-> <localPort>, with extra information like: publicRemoteIP, publicRemotePort, Osmux handler.
  • Upon CRCX/MDCX update table: If an entry <remoteIP,remotePort> doesn't exist, create osmux socket + handler on next empty localPort, and fill the table.
  • Upon receival of Osmux pkt, take <dstPort>, and use it in the table to lookup based on localPort, then we know the private and public <remoteIPaddr,port>, and we know to which Osmux handler we need to send the message.
  • When we need to send on an osmux handler, we know localIp, localPort and publicRemoteIP and publicRemotePort, so we can send osmux frames correctly.

Drawbacks: We need at least 1 Osmux port per BSC.
Wins: We can handle unlimited Osmux call legs per BSC and per MSC (as long as ports are free, each port provides 256 streams). It allows us to support multiple MGWs when using Osmux, since now it's not possible afaict.

Related issues

Related to OsmoMGW - Feature #2551: generalization of OSMUX support in osmo-mgwResolved10/06/2017


#1 Updated by pespin over 1 year ago

  • Related to Feature #2551: generalization of OSMUX support in osmo-mgw added

#2 Updated by pespin over 1 year ago

Forgot to say: There should be a VTY flag to change the behavior explained above in the case there's no NAT in the setup, and remoteIP and remotePort can be used. Then no lookup is needed and localPort can be re-used for each <remoteIP,remotePort> tuple.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)