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