Re: LCLS

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?