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