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.de> In struct osmo_ss7_instance we already have the .cfg sub struct. I think we > should add the items there instead of introducing something new. Also if we My concern was that we might mix scopes that should rather remain independent. I don't know any details or reasons though. Now I noticed that struct osmo_ss7_instance does contain an osmo_sccp_instance pointer as well as the sccp_address_book, i.e. they are already intimately related. So that seems to be the right place after all. These being so closely tied brings me to a simplification of the VTY I'll get to at the end of this mail. Will we ever use osmo_ss7_instance for anything else than SCCP? > 1) A and IuCS use the same sscp/ss7 instance > > cs7 instance 1 > sccp-address msc_local > point-code 0.0.2 > routing-indicator PC > sccp > name iucs_and_a > pc msc_local so this takes just the PC from the msc_local address, ok. Techincally we don't even need to define a separate address, but give only a PC: pc 0.0.2 This is much shorter; should be easy to allow both. (That's because osmo_sccp_simple_client() accepts a PC argument that is set as ss7->cfg.primary_pc. I wonder whether we use a routing indicator of PC in a hardcoded way then? Future plans?) > prot M3UA > local-port 1234 > remote-port 5678 For prot M3UA, the ports should be M3UA_PORT by default, if the port commands are omitted. > msc > cs7-inst-a 1 > cs7-inst-iucs 1 > local-addr msc_local [...] > msc > cs7-inst-a 1 > cs7-inst-iucs 2 > local-addr msc_local Let's allow two separate local SCCP addresses as well. Actually, I think we can drop the local-addr completely: It doesn't make sense to have the same ss7 instance wih two distinct local addresses; at least in the current code state, we can handle only one local PC per ss7 instance. And actually you already define a local PC in 'sccp' above with 'pc msc_local'. All that we need for osmo_sccp_user_bind() is an sccp instance pointer (taken from the osmo_ss7_instance) and an SSN (hardcoded). So this is sufficient: msc cs7-inst-a 1 cs7-inst-iucs 1 or msc cs7-inst-a 1 cs7-inst-iucs 2 One more thing: each ss7_instance will only find those address book entries defined in its own address book list, right? For example this won't work? cs7 instance 1 sccp-address address_on_instance_1 point-code 0.0.2 routing-indicator PC cs7 instance 2 sccp pc address_on_instance_1 That could be a reason to keep the address book separate from osmo_ss7_instance structs, as one global list usable everywhere, and also to place the address book vty commands on its own VTY scope. Can we make 'pc' rather 'local-pc'? If I explore the case of passing the PC directly and using a global SCCP address book, the VTY becomes simpler. We don't actually need an cs7-instance scope anymore, since all we do in it would be defining an SCCP instance: ! global address book would look something like this sccp-address msc_local point-code 0.0.2 sccp-address another_one point-code 0.0.3 ! The number '1' passed as the ss7 instance id. VTY shall disallow passing the ! same id another time. sccp-inst 1 name OsmoMSC local-pc msc_local ! or maybe just 'local-pc 0.0.2' prot M3UA local-ip 1.1.1.4 ! local-port 1230 remote-ip 2.2.2.4 ! remote-port 5670 msc iface-a sccp-inst 1 iface-iucs sccp-inst 1 OR even not needing any address book entries: sccp-inst 1 name OsmoMSC-A local-pc 0.0.2 prot M3UA local-ip 1.1.1.4 remote-ip 2.2.2.4 sccp-inst 2 name OsmoMSC-IuCS local-pc 0.23.0 prot M3UA local-ip 1.1.1.1 remote-ip 2.2.2.2 msc iface-a sccp-inst 1 iface-iucs sccp-inst 2 I like this better because it hides the unneeded duality of ss7-instance and sccp-instance from the config file, and it keeps the address book feature separate and optional. Does this make sense to you? ~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/20170706/d875912a/attachment.bin>