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?