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?
- 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