OsMux + MGW + SIP

[Keith]

On 07.09.2018 10:27, Harald Welte wrote:
> Hi Neels,
>
> 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?


>
>> IIUC LCLS happens after bridge.
> ack.
>
>> IIUC we instruct the MS to generate a ringing signal anyway?
> Yes, but it's known that not all phones really like to do that, in violation of the GSM specs.

Yep. I noticed that :-/

>
>> Feels wrong to me to let osmo-sip-connector mess around with the BTS'
>> IPAC_MDCX, I think that's firmly osmo-bsc's realm. And sounds like LCLS is the
>> thing.
> Agreed.
>
>> Currently we need an MGW both from MSC and from BSC. Again it seems to me LCLS
>> is the answer to take out the MSC's MGW, and osmo-bsc's LCLS decision might
>> then end up bypassing the BSC's MGW, if it doesn't do that yet?
> It doesn't do that last step, but it's just some additional logic inside the BSC to do that.
>
>> I think osmo-msc doesn't support LCLS though, only osmo-bsc? And also I think
>> the MSC doesn't need to do much for LCLS anyway.
> It's correct that osmo-bsc implements LCLS, but osmo-msc doesn't enable LCLS yet.  See
> https://osmocom.org/issues/2487
>
> 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.
Just wondering if there would be any reason to have it passed over the MNCC?

>
> 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. 
We could just hang up I suppose, but that's not so nice for the user.


>
>