27 Feb
2016
27 Feb
'16
10:21 a.m.
Hi Holger,
On Fri, Feb 26, 2016 at 09:07:01PM +0100, Holger Freyther wrote:
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.
my question was where exactly would that selection happen? In the remote
SIP PBX?
yes, but a unfortunately perfectly normal case in all bu the simplest
networks :/
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_123…)
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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
On 26 Feb
2016, at 19:45, Harald Welte <laforge(a)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. 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" 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. 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?