On Fri, Jul 21, 2017 at 08:42:38AM +0200, Harald Welte wrote:
my suggestion here would be a set of optional, vendor-specific TLVs that we can introduce in the A interface to convey related information.
Would be easy to include information about the actual physical channel from BSC -> MSC, such as BTS number (maybe CGI=MCC+MNC+LAC+CID), ARFCN, timeslot/sub-slot (rsl chan_nr)...
This is generally useful for all kinds of debugging.
In a similar manner I would tranasport some kind of subscriber name/identification from the MSC to the BSC so the BSC can still show who has allocated a given channel. In its most generic form it could be as simple as a string TLV that the MSC can add to whatever downlink A interface message, and which the BSC accepts in every such message to talloc_replace_string() a field in its lchan, which can then be printed by various code (particularly logging) or used as log filter, or whatever else.
Agreed.
For the code review this means: we cannot sensibly add those kinds of TLVs before we actually have the A-interface in the MSC. So the MSCSPLIT stage of the code review in osmo-msc.git will drop the code and we shall re-add once we have osmocom-specific TLVs added to our A-interface code. I tend towards leaving the '#if BEFORE_MSCSPLIT' markings there to disable the code instead of dropping it, to be able to easily find it later and see what it was supposed to do.
- Add Osmocom specific TLVs to SMPP
Could be handled the same way, but should be yet another option, as it adds a lot of verbosity to the A interface which it otherwise doesn't need. Not the highest priority, but definitely doable with reasonable effort.
I notice that this uses lchan measurement reports... not sure whether / when we want to send those to the MSC, but am not familiar enough. OS#2390
- Siemens BS11 MRPCI
this has to be moved to the BSC.
OS#2389 -- also makes sense to drop in initial split and re-add in osmo-bsc after AoIP.
- In libmsc, gsm_04_08.c, we connect libbsc handle_abisip_signal(); the same is done in osmo_bsc_audio.c in osmo_bsc_audio_init(), so I assume it can be dropped from libmsc.
well, who are the usrers of the signal?
OsmoMSC no longer has an Abis interface, so it does not make sense to handle that signal. Anyway, in osmo-nitb, the consumer was handle_abisip_signal() in gsm_04_08.c, which apparently does RTP stream handling: - receives S_ABISIP_CRCX_ACK to connect an RTP socket; and flush pending pending tch_recv_mncc requests (which I don't fully understand, guess it's RTP also stream related) - receives S_ABISIP_DLCX_IND and frees an RTP socket. Since RTP is now handled via osmo-bsc_mgcp, I conclude that this is indeed obsolete.
~N