LCLS

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

Keith keith at rhizomatica.org
Wed Oct 6 02:42:21 UTC 2021


After looking at this a little more today,

I think we need to:

* write a FSM for lcls in the MSC, correct?

* have the msc change lcls states in the bsc in response to INVITES on
the sip side, (as well as signal it's MGW to change IP/Port)

* when using the external mncc, always start lcls in STS_NOT_YET_LS


The thing that I not seeing right now is how the SIP PBX would signal to
change lcls state, the only thing occuring to me is to always run the
PBX on a different IP to the MGW and then the condition when reacting to
reINVITES would be:

if the sdp mediaip != my ip then STS_NO_LONGER_LS , otherwise
conditional on all the other conditions for LCLS....

That is to say, if 172.16.0.0/16 is the RTP subnet, then bind the MGWs
to 172.16.0.1 and

Freeswitch to 172.16.0.2.

So (leaving the ports our of it) initially our MO call would have

c=IN IP4 172.16.0.1

FS would repond c=IN IPV 172.16.0.2

then INVITE the MT call with 172.16.0.2 to which sipconn/msc/mgw
responds with 172.16.01

When the B leg answered, FS invites itself out of the audio stream, with
a re-INVITE with

c=172.16.0.1, this would be our trigger to send ST_LOCALLY_SWITCHED on
the BSS so that bts-loop can kick into action.

when FS wants to intervene (to playback "your credit is about to
expire", for example), then it reINVITES itself back into the stream
with c=172.16.0.2, this would trigger STS_NO_LONGER_LS (or something)
Then the BSC comes out of LCLS bts-loop, informs the BTS to sendrecv to
the MGW, and at the same time the MSC has told the MGW to start sending
and to expect from FS.

 a bit hacky?









More information about the OpenBSC mailing list