BSC side of LCLS (local call local switching) as per the 3GPP specs
Some deployments use OsmoBSC with its support to connect to multiple MSCs simultaneously in order to have local call switching.
Let's study the 3GPP LCLS feature and see how that can help us in that regard, maybe it has a better/cleaner/more standard way to do it?
- Status changed from New to In Progress
- Assignee changed from neels to laforge
- % Done changed from 0 to 20
- http://git.osmocom.org/osmo-bsc/log/?h=laforge/lcls for the BSC, as well as
- http://git.osmocom.org/osmo-ttcn3-hacks/log/?h=laforge/lcls on the test side.
both need quite some more work, but I think I've figured out the state machine with all of its transitions by now.
I've made significant progress on the testing side, although I hit a Titan compiler bug (see https://www.eclipse.org/forums/index.php/t/1093530/) as well as some shortcomings in our *_Emulation components, see https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/9403/
- Checklist item prevent LCLS enabling on calls of different codecs added
- % Done changed from 30 to 70
the tests for LCLS related signaling are rather complete now, and they all pass with my latest version of the OsmoBSC LCLS FSM.
The only missing bit now is to actually implement the body of the functions that enable/disable the local switching of the voice, i.e. that issue the MGCP commands.
Thinking about it:
- enable LCLS for a given call
- Issue MGCP MDCX on MSC-side connection on MGCP endpoint of call A to point to IP/Port of call B
- Issue MGCP MDCX on MSC-side connection on MGCP endpoint of call B to point to IP/Port of call A
- disable LCLS for a given call
- Issue MGCP MDCX on MSC-side connection on MGCP endpoint of call A to point back to MSC/MGW
- Issue MGCP MDCX on MSC-side connection on MGCP endpoint of call B to point back to MSC/MGW
So we have to cache the ip/port information of the MGW/MSC during ongoing local switching, as we don't receive that information [again] once we switch back.
Known limitation: Until the MGW can perform transcoding, calls with mis-matching codecs will break. We should add some provision into OsmoBSC that would prevent activating LCLS on two calls of different codecs until the MGW can transcode.
There will also be LCLS implications at the time we do inter-BSC hand-over. This will have to be looked into once inter-BSC HO is merged.
- % Done changed from 70 to 90
https://gerrit.osmocom.org/#/c/osmo-bsc/+/9416 has been updated. It now actually performs local switching via MGCP MDCX re-configuration of OsmoMGW.
The test suite in https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/9412 has equally been extended to verify the actual MGCP user plane switching functionality.
- Checklist item jenkins / CI integration of test suite set to Done
Jenkins integration of test suite: https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test/test_results_analyzer/
#22 Updated by laforge about 1 month ago
- Assignee changed from laforge to dexter
the only remaining bit is to ensure LCLS is not enabled on calls that have different codecs on both legs (at least until we have working transcoding in osmo-mgw).
As I'm leaving on holidays soon, it would be good if dexter could take care of this last missing bit, including related TTCN3 tests
#23 Updated by dexter about 1 month ago
I have now added a check that tests the two call legs for different codec/rate. If codec/rate is different, then LCLS will be avoided. However, I am a bit unsure about the status codes here. At the moment the status code I see is LCLS_STS_not_yet_ls. I am not sure if this is right, but it must be the same as with the other conditions in lcls_enable_possible()
https://gerrit.osmocom.org/#/c/osmo-bsc/+/9940 lcls: do not LCLS call legs with different codecs
https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/9941 BSC_Tests_LCLS: try call legs with different codec/rate