On Thu, Jun 29, 2017 at 11:58:10AM +0200, Philipp Maier wrote:
I see some problems with defining the sccp addresses
in the VTY. An
sccp address also gets an SSN.
So I will have to define the ssn separately via another VTY command.
Not necessarily. Your address book VTY code allows to set only a PC, omitting
an SSN. Later on we can add an SSN according to which protocol is served, by
taking the address book entry, copying the address and adding an SSN.
We can then of course not modify an SCCP address on-the-fly. I believe this
anyway needs a restart of the sccp_user_bind, so I think we should not bother
to support that. (restarting e.g. the BSSAP would allow changes on-the-fly.)
(I notice also that the VTY code "manually" sets the address parts like PC and
SSN, placing presence flags. I guess it would make sense to have API functions
that do this, in the sense of osmo_sccp_addr_set_{pc,ssn}(); and to copy.)
Then we would call the osmo_sccp_simple_client() in
some central place to get
the sccp_instance.
I understand the discussion to conclude differently: we use your SCCP address
book, making it possible to use either a single osmo_sccp_simple_client() or
separate ones, depending on the VTY config. We assign the addresses so defined
to BSSAP and RANAP, with the SSNs hardcoded (by addr copy). That allows two
scenarios depending on vty config, for example something like:
MSC
BSC ---PC=1,SSN=BSSAP---> STP ---> ss7-instance(a)1.2.3.4: PC=1,SSN=BSSAP
BSC --/ 10.9.8.7
-> ss7-instance(a)5.6.7.8: PC=1,SSN=RANAP
HNBGW ---PC=1,SSN=RANAP-> STP -/
6.5.4.3
cs7 instance 1
sccp bind-addr 1.2.3.4 remote-stp 10.9.8.7 ! add simple_client?
sccp-address msc_local_a
point-code 0.0.1
routing-indicator PC
cs7 instance 2
sccp bind-addr 5.6.7.8 remote-stp 6.5.4.3 ! add simple_client?
sccp-address msc_local_iucs
point-code 0.0.1
routing-indicator PC
msc
local-addr a ss7-instance 1 msc_local_a ! SSN added implicitly
local-addr iu ss7-instance 2 msc_local_iucs ! by copying the address book entry
(Could we also omit the 'ss7-instance 1', instead implied by the address name?)
Or this:
MSC
BSC ---PC=1,SSN=BSSAP---> STP ---> ss7-instance@1.2.3.4:--> PC=1,SSN=BSSAP
BSC --/ 10.9.8.7 \-> PC=1,SSN=RANAP
^
/
HNBGW ---PC=1,SSN=RANAP-/
cs7 instance 1
sccp bind-addr 1.2.3.4 remote-stp 10.9.8.7 ! add simple_client?
sccp-address msc_local
point-code 0.0.1
routing-indicator PC
msc
local-addr a ss7-instance 1 msc_local ! same address for both, SSN added implicitly
local-addr iu ss7-instance 1 msc_local ! by copying the address book entry
(Could we also omit the 'ss7-instance 1', instead implied by the address name?)
To allow the above, we need to add an id argument to osmo_sccp_simple_client()
to indicate the ss7 instance id. Possibly, the ss7 instance could be created
automatically by calling osmo_sccp_simple_client() with a before unused id.
Though, the only reason so far to have separate ss7 instances seems to me that
the ss7 instance records its local PC "globally". It seems that an ss7 instance
can have separate AS with separate local bind IP addresses and so forth. So I
guess we will have one ss7 instance per osmo_sccp_simple_client(), but it seems
that's not strictly necessary, besides our missing routing feature? Not sure.
Next an initalizer function would reserve exactly one
sccp_user for the
A-Interface using osmo_sccp_user_bind() and another one for for RANAP
yes.
After that we can add BSCs using a_init() (which I
still think is necessary,
see below)
a_init() should happen only once, e.g. upon above suggested:
msc
local-addr a msc_local
We will not have separate SCCP clients per BSC.
MSC side BSSAP Reset:
I am not sure about this. The specification (3GPP TS
48.008 3.1.4.1.2 Reset
at the MSC) says: "In the event of a failure at the MSC which has resulted
in the loss of transaction reference information, a RESET message is sent to
the BSS. This message is used by the BSS to release affected calls and erase
all affected references and to put all circuits into the idle state."
I do not know how that should work if the MSC has no configuration where to
send the reset. Failure means crash/restart to me. The MSC has lost all
knowledge about the BSS, so that needs to come from somewhere. Do we know
how other vendors handle the problem?
Send a Reset to each BSC that shows up for the first time. I'm also not sure
about this, but Harald sounds pretty certain, so I'm willing to follow that
lead.
~N