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.