Hi,
I am looking into building a very simple MNCC to SIP bridge to be used with the NITB (and later the CSCN). 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)
The primary design points are:
* Being able to select TCH/F or TCH/H * Decide on the codec very late * Support for AMR parameters through MNCC
I just look at MO and MT Call establishment from a high-level point of view:
MO-Call:
* NITB will send the SETUP indication * MNCC GW will do screening and decide if to proceed * MNCC GW will make TCH/F or TCH/H decision and ask for a source IP, source port * 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. ... * PBX will decide on a codec (ringing or 200 connect) * MNCC GW will ask NITB to reconfigure and audio will flow * (TODO: check ringtone, check default, check codec change)
MT-Call:
* MNCC GW will be presented with a list of codecs already * Depending on that TCH/F or TCH/H can/must be chosen (e.g. for AMR even the codec rate can be in the SDP file that decides which TCH/F or TCH/H to use) * Can decide bearer caps once paging has succeeded and call is progressing * Sets audio codec and waits for call to connect
Handover support:
* IP/port (and then SSRC and timestamp in RTP) will change * MNCC GW could try SIP re-invite with changed parameters * MMCC GW could hope PBX implements RTP annex and re-learns the connection
Do you have comments or remarks? The above will lead to a version update, probably a dedicated assignment command in MNCC, and separating socket creation and codec change. Anyone wants to have a go at that?
have a nice weekend
holger
Hi 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
On 26 Feb 2016, at 19:45, Harald Welte laforge@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?
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@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_1232...)
http://www.3gpp.org/DynaReport/WiCr--430001.htm contains a list of changes made to other 3GPP specs for LCLS support.
Regards, Harald
Hi Holger,
I'm sorry for again making this more complex than neccessary. It's up to you whether you would like to go down that route, of course :)
I found the following specifications that relate to how existing classic GSM/3GPP call control is mapped to SIP and vice versa (unfortunately typically over BICC as intermediate, but BICC is closer to 04.08 CC). In the context of interoperability with IMS this might be worth investigating:
* 3GPP CS interworking with BICC/ISUP and SIP-I networks http://www.3gpp.org/DynaReport/29164.htm http://www.3gpp.org/DynaReport/WiCr--13033.htm heavily based on ITU-T Q.1912.5: SIP <-> BICC/ISUP interworking https://www.itu.int/rec/T-REC-Q.1912.5-200403-I/en
(and as a side-note, ITU-T has actually specified conformance testing procedures for SIP in Q.3946.x)
* NcSIP (SIP Between G-MSCs?) http://www.3gpp.org/DynaReport/29802.htm http://www.3gpp.org/DynaReport/WiCr--320018.htm http://www.3gpp.org/DynaReport/WiCr--360025.htm
On Sat, Feb 27, 2016 at 10:21:56AM +0100, Harald Welte wrote:
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_1232...)
http://www.3gpp.org/DynaReport/WiCr--430001.htm contains a list of changes made to other 3GPP specs for LCLS support.
There's also a follow-up to that in http://www.3gpp.org/DynaReport/WiCr--440021.htm
On 27 Feb 2016, at 12:29, Harald Welte laforge@gnumonks.org wrote:
Hi Holger,
Dear Harald,
I'm sorry for again making this more complex than neccessary. It's up to you whether you would like to go down that route, of course :)
thank you for the pointers. I will have a look and probably still concentrate on the first items that is delaying the point where the audio codec will be picked and to have nice sofia-sip event loop integration without resorting to polling every n-seconds.
kind regards holger
-
Harald Welte -
Holger Freyther