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