sscp-context initalization via VTY

[Philipp Maier]

Hello Neels,

 > (any reason to not discuss this on openbsc@?)
I put it on CC.

 > Still missing in this proposal: how do you tell e.g. the MSC's A and 
IuCS code
 > to use a given SCCP instance, local SSN and remote SCCP address?

I would add a VTY command where the user has to tell on which ss7 instance
the A or IuCS interface should bind. When the IDs for both match up, we know
that we use the same SCCP instance, but I think we do not even have to check
that. Its implicit by the pointers. If the numbers are the same we will end
up with the same sccp instance pointer for both.

The SCCP-Addresses are defined by the addressbook. Which one is used will be
configured via a VTY command seperately. The SSNs are hardcoded, so this is
not a problem currently. If someone wants configurable SSNs and wants two
users with different SSNs but same local point codes (which is mandatory in
this case), then the user would have to define two addressbook entries where
only the SSN is different. Logically this is then a different address 
and look
at postal addresses, there its the same. Two different houses next to each
other  will have different addresses. The only difference is the number 
(SSN).
At some point we have to make the cut.

We could think about unifying the osmo_sccp_user_bind() function as 
well, so we
would get pointers for ready-to-go sccp-users as well, but I think this 
is out
of scope right now. The solution would be similar to the addressbook. We 
would
just define nodes which hold the parameters. The results end up in a 
list and
after parsing is done. The user can call a function that only gets the 
ID that
references the parameter set, the pointer to the sscp instance and the
function pointer for the SAP. e.g.: 
osmo_sccp_user_bind_id(sscp,2,sccp_sap_up)

 > A much simpler soultion to the problem would be to pack the configuration
 > options into struct osmo_ss7_instance. Then when the config file parsing
 > is done, the user must call a function e.g. "osmo_sscp_init()" or so to
 > trigger the call to osmo_sccp_simple_client().

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 do
so we would have to change it for the existing code too to have it 
consistent.

Lets do some practical examples:

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
    prot M3UA
    local-port 1234
    remote-port 5678
    local-ip 1.1.1.1
    remote-ip 2.2.2.2
msc
  cs7-inst-a 1
  cs7-inst-iucs 1
  local-addr msc_local

1) A and IuCS use separate sscp/ss7 instances

cs7 instance 1
  sccp-address msc_local
   point-code 0.0.1
   routing-indicator PC
  sccp
    name a
    pc msc_local
    prot M3UA
    local-port 1230
    remote-port 5670
    local-ip 1.1.1.4
    remote-ip 2.2.2.4
cs7 instance 2
  sccp-address msc_local
   point-code 0.0.2
   routing-indicator PC
  sccp
    name iucs
    pc msc_local
    prot M3UA
    local-port 1234
    remote-port 5678
    local-ip 1.1.1.1
    remote-ip 2.2.2.2
msc
  cs7-inst-a 1
  cs7-inst-iucs 2
  local-addr msc_local

regards.
Philipp

-- 
Philipp Maier <pmaier at sysmocom.de>              http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte