OsMux + MGW + SIP

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Sun Sep 9 14:08:00 UTC 2018


Hi Keith,

I'm not sure I'm following your lines of thought completely.

In any case, a media gateway is always co-located to a signaling element
next to it, at the same level of the network.

So the BSC controls its (local) MGW, whith the MSC controls its (local) MGW

The split into call-agent and MGW was introduced conceptually simply to
separate the control from the user plane.  From the outside point of view, it's
still a "MSC" logical network element, even though internally it has been split
into the "MSS" (MSC Server) and the MGW internally.

So any process from another domain / hierarchy controlling a media gateway directly
sounds immediately like "HACK/UNCLEAN" to me.

On Sat, Sep 08, 2018 at 08:10:50PM +0200, Keith wrote:
> When you divide the OSMUX stream again and turn each circuit ID back
> into individual RTP stream you have an associated port and IP, right?
> (on the terrestrial side)

osmux doesn't establish that relationship.  Whoever decapsulates OSMUX
must know where to send it to, and which dynamic payload type was allocated
to it, etc.

> * local msc, with two colocated mgws (we decide which one to signal
> depending on if the call is local or needs the SAT stream)

what's the advantage of having two separate MGWs, compared to having one?

All the parameters related to this call/connection are signaled in the MGCP CRCX/MDCX
commands.  So whether or not a given set of endpoints/calls/connections is on one
MGW or on different MGW doesn't really make a difference, IMHO.

> another point here is I undertand we don't _really_ need two MGWs, so
> maybe just one in the village, shared between bsc/msc and one in the
> datacentre.

OsmoBSC + OsmoMSC can already share a single MGW at this point.

> so in the case of a call that is using sat/ osmux, the MSC in the
> village is signalling the MGW in the datacentre, therefore this MSC
> knows which IP/port combination to tell to osmo-sip-connector and on to
> freeswitch, which then signals whatever SIP UA in the data centre

again, sounds like "hack" to me.  The MSC signals *its* media gateway, and not
"somebody elses".

Sure, it's possible to design a system architecture that way, but it's not
how media gateways are intended to be used, I think - whether in the context
of GSM or not.

> So, the fact that osmux is used at all is completely transparent to the
> SIP UAs

I think if that's the goal, then you'd have to implement a proxy solution that
proxies both the SIP as well as the RTP flows.  At that point the protocol between
the two proxies doesn't matter.

The proxy would then re-write/re-generate any IP/port/payload-type/etc. information
in the SIP/SDP to hide the presence of osmux.  To me, that looks like a last resort
kind of approach.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



More information about the OpenBSC mailing list