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
Fri Sep 7 11:29:06 UTC 2018


On Fri, Sep 07, 2018 at 11:54:53AM +0200, Keith wrote:
> On 07.09.2018 10:27, Harald Welte wrote:
> > On Fri, Sep 07, 2018 at 02:27:27AM +0200, Neels Hofmeyr wrote:
> >> Reminds me of the LCLS feature recently implemented -- Local Call Local Switch.
> >> I think the idea of LCLS is to take out the MSC's MGW, and instructing the
> >> BSC's MGW to loop directly back to the BTS. But I guess it's only a tiny step
> >> from there to switching BTS directly back to BTS. osmo-bsc has full control
> >> over that.
> > LCLS actually doesn't specify how far you go inside the RAN.  We chose to
> > simply keep the stream local to the BSC's MGW as this was simple and matched
> > the requirements at the time.  As stated before, it's just some additional logic
> > inside osmo-bsc to take the BSC-MGW out of the local loop entirely.
> 
> OK. So we could compare codecs and endpoints and make a switching
> decision for internal BTS media?

exactly.  At the time the LCLS decision is made in OsmoBSC, you need to
check if the codecs are compatible and then send the IPA MDCX to the two
BTSs without keeping anythin on the MGW.

To be fair, LCLS also contains use cases where the media in either
uplink or downlink is bi-casted (for purposes including lawful
intercept), but I think we can exclude those for now, and I think
OsmoBSC currently doesn't advertise support for those anyway.

> > But indeed, all that's needed in osmo-msc is:
> > * generate a global call reference for each call, include it in the BSSMAP signaling
> 
> In the case of a SIP originated call, you will get a uniq call ref there.

LCLS needs a way to generate unique call references which are

a) unique in the sense that the number space is divided between each
   element that generates GCRs and hence no two elements would ever end up
   generating identical GCRs

b) signaling for *both legs of each call* have to contain that same,
   globally unique call reference.

"elements" is basically anything that could/would ever initiate a call,
so basically MSCs or any other switches (SIP or ISUP or whatever).

> Just wondering if there would be any reason to have it passed over the MNCC?

It's needed if you want to locally switch media for calls whose both
legs aren't handled by the same MSC.  This includes more complex
scenarios such as inbound roaming in classic networks.  I strongly
suggest to read the 3GPP LCLS specs, they have nice, colorful diagrams
of all those use cases.

I don't think it's what we're looking at in this discussion for now, but
maybe only at a later step.

> > The basic use case "switch locally whenever possible" is very easy to achieve.
> > Also, a simple use case "switch locally only after the CC CONNECT" is equally easy to achieve,
> > and that way you get your ringtone from the core network.
> >
> > If you want to switch it on and of conditionally at whatever other
> > points during a call, more logic is needed.  But I think this is not
> > Rhizomatica's use case, is it?
> 
> We do play back "You're credit is about to expire" messages.
> We would have to switch the stream back to do that. 

Who takes those kinds of decisions?  the central switch in the
datacenter? If yes, then we'd need some SIP based signaling to switch
the (downlink) media plane [temporarily] back to the core.  LCLS permits
for that, it's just that we have to implement those bits in OsmoMSC and
osmo-sip-connector.

I don't know the details of how 3GPP specified this for SIP, but I saw
there are SIP related parts among those LCLS specs.

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