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 <[email protected]>              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

Reply via email to