Hi All,
I was again looking at advancing with LCLS support.
I've made a couple of proposals, which at least get it to the stage where the global call reference it consistent from the A leg to B leg of a call, with both the internal mncc and external, and therefore osmo-bsc can make use of either the lcls-mode (mgw|bts)-loop.
The implementation in the osmo-sip-connector doing nothing more than passing the GCR from leg to leg, but it's more complicated than this.
We need to allow the PBX to have the audio streams until the PBX itself decides to remove itself from the stream. (as it is you won't even hear ringback)
I know all this is spec-ed somewhere in LCLS, I'm just not sure where/how this SIP re-INVITE processing should be implemented, in the sip conn, or the MSC - which I guess, takes us back again to neels' long standing proposals for parsing SDP inside the MSC. Maybe it' s time to get that merged.
Anyway.. I have some time scheduled to try to move this forward towards a definitive solution, just writing here in case anyone else can help.
Thanks.
k/
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?
On Tue, Oct 05, 2021 at 03:44:52PM -0500, Keith wrote:
sip conn, or the MSC - which I guess, takes us back again to neels' long standing proposals for parsing SDP inside the MSC. Maybe it' s time to get that merged.
+1 :)
The one outstanding point there that I remember is making my SDP handling on sipcon not undo your call-hold handling patch. The osmo-msc patch should be ready for merge as-is.
Anyway.. I have some time scheduled to try to move this forward towards a definitive solution, just writing here in case anyone else can help.
I can help as soon as sysmocom is able to fund my hours spent... Too time stricken ATM to even consider doing it in my free time.
~N
-
Keith -
Neels Hofmeyr