RFC MNCC to SIP bridge

historical

Hi Holger,

On Fri, Feb 26, 2016 at 09:07:01PM +0100, Holger Freyther wrote:
> > On 26 Feb 2016, at 19:45, Harald Welte <laforge at gnumonks.org> wrote:
> > 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?
> 
> 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.

I like that approach.

This functionality would be at the OsmoBSC level, once we start to use
OsmoCSCN + OsmoBSC as replacement for OsmoNITB.  So the functional split
in the code could already be prepared for that, rather tuan introducing
more TCH/lchan dependencies to the "MSC side" of the code, which Neels
is trying to remoove at this point.

> 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?

I don't really like that idea.  The gateway shouldn't have to know the
differences.

> 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. 

I have a fully wired setup with BS-11, Ericsson RBS2307 and a Nokia
InSite at my home.  Haven't used it in a long time, but it is still
there.  We could also move that to sysmocom and make it part of the
regression testing setup, once that setup is more complete.

> > Who would do the selection? The remote SIP PBX?
> 
> The MO-Call could select anything it wants or pick "any"

my question was where exactly would that selection happen? In the remote
SIP PBX?

> 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).

understood.

What's also required is that the supported codecs of the BTS segment are
understood.

We have the list of codecs supported by the MS inside the CC message,
but we don't know the list of codecs supported by the BTS by this.  Or
the reduced set of codecs as per administrative means (configuration).
I think MNCC should be extended to include that as part of the SETUP
message towards the external MNCC handler, rather than messing around
with the CC level message.

> > 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.

yes, but a unfortunately perfectly normal case in all bu the simplest
networks :/

> 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.

One might want to have a look on how this is done on the SIP side in
LTE/IMS to 2G/3G hand-over cases.  They should have the same problem.

> 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?)

see above, I think it's better to pass through the "raw" information
rather than messing with the Layer3 bearer capability IE content.

> > 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. 
>
> Can you point me to the right number for it?

A high-level description seems to be offered in TS 23.284
(http://www.etsi.org/deliver/etsi_ts/123200_123299/123284/13.00.00_60/ts_123284v130000p.pdf)

http://www.3gpp.org/DynaReport/WiCr--430001.htm contains a list of
changes made to other 3GPP specs for LCLS support.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)