This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi Holger,
On Fri, Feb 26, 2016 at 05:41:38PM +0100, Holger Freyther wrote:
> This will be based on what was learned from adding the RTP bridge
> which means the audio will not flow through the bridge (eventually
> later there will be a UDP proxy for NAT traversal)
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?
> * Being able to select TCH/F or TCH/H
Who would do the selection? The remote SIP PBX?
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?
> * 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.
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...
> * IP/port (and then SSRC and timestamp in RTP) will change
see above, also the codec and even the TCH type could change.
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)