RFC MNCC to SIP bridge

historical

> On 26 Feb 2016, at 19:45, Harald Welte <laforge at gnumonks.org> wrote:
> 

> It might be good to have at last have a plan what to do with legacy BTSs
> with E1 intrface.  I know it's not the primary goal right now, but we do
> have all the code to convert from TRAU frames to RTP and vice-versa, and
> we use that with the classic non-rtp-bridge MNCC towards LCR.  However,
> we can currently only have one MNCC app registered to the MNCC socket,
> so if you register the new SIP-to-MNCC gateway, then the codec frames
> will end up there.  Any ideas on that?  Split MNCC into separate
> signalling and user plane sockets?  That way an external future gateway
> could actually do that conversion without any change to the SIP
> converter?
> 
> Or get rid of trau frame handling in the NITB when transitioning to
> CSCN, and move all that to the BSC / BSC-mgcp?  Then at least from that
> point upwards it would all be A-over-IP and RTP, even for E1 based BTSs?

Codec frames will not end up at the new GW because the new RTP bridge command will fail and this leads to the call being dropped/not proceeding. Now it is good to have a plan to move forward and not let the conversion code just rot.

a.) We can do the TRAU/RTP conversion inside the NITB. The RTP bridge code would then not ask the BTS to open a socket but open it itself and the SIP-to-MNCC gateway would not have to know the difference.

b.) The SIP-to-MNCC gw can know the difference and we could use some funny Unix feature to send a fd to the timeslot that carries TRAU to the application and the TRAU/RTP code is done in the gateway?

Doing a.) is probably very easy but I don't think anyone used the BS11 in the CCCB for a long time and I don't know any other BS11 (or Nokia or Ericsson) setup right now. 

>> 	* Being able to select TCH/F or TCH/H
> 
> Who would do the selection? The remote SIP PBX?

The MO-Call could select anything it wants or pick "any" and for the MT-Call the GW would ask the NITB to pick something that matches the offered codecs. So if AMR5.9 and HR are offered by the PBX the MT-Call should be using TCH/H (and start to page for this kind of channel and then look for the bearer capabilities to make the decision).

So I think it is feasible but the issue will be with the PBX we are trying to use.

> Also, what about the BSC autonomously handing-over from a TCH/H to a
> TCH/F, in cases where the BTS gets more loaded, or in case there's a
> hand-over and the new target BTS has no slots of the same type
> available?

This is getting hardcore. I know of SIP 're-invite' but this is mostly a measure to check that the other party is still active. In theory one could re-negotiate the codec but I doubt that it will work with proprietary SIP PBXs and even with the FOSS ones it will most likely end up with the requirement to patch it.

> 
>> 	* Based on bearer caps (to be handled by MNCC GW?) and TCH/F,
>> 	TCH/H MNCC GW can offer a SDP file with multiple codecs to the
>> 	PBX.
> 
> What do you mean by the question 'to be handled by MNCC GW?'  I think
> the MNCC interface today already exposes the full MS originated bearer
> capabilities as sent in CC, in a decoded form.  MNCC-SIP-GW then needs
> to translate that into SDP, as you point out.

Yes, I just wondered if bearer capability handling is best done in the MNCC GW or if we want to extend the MNCC interface to just list the possible codecs (already reduced by the traffic channel in use?)

> Sorry for making things more complex, but this might also be the right
> point to look at the 3GPP LCLS (local call local switch) feature, and
> how they have implemented the short-circuit of keeping BTs-local or
> BSC-local calls local without passing the user plane all the way into
> the core network.  I think in many cases one would also want this in a
> MNCC-SIP kind of situation, and it's better to understand all
> constraints now before designign something new that falls short of
> something required for the latter...

Can you point me to the right number for it?