On 26 Feb 2016, at 19:45, Harald Welte
<laforge(a)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?