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/.
Neels Hofmeyr nhofmeyr at sysmocom.deOn 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170724/cbc2870e/attachment.bin>