Re: Recommendation for SUA modifications

Haresign,

Haresign Lincoln wrote:                                                           (Wed, 12 Oct 2005 14:55:35)
> Brian,
> 
> When an ASP registers with an SG (either via static configuration or
> dynamic configuration), one of the optional parameters is destination
> address.
> 
> IF the ASP has a routing key of destination address and IF the
> destination address contains a point code, then the point can be derived
> from the set of routing keys that define that RC.  (In the case of
> dynamic registration, if the ASP is sending a point code in the
> destination address, the this whole issue is moot since the ASP knows
> the PC).

You told me that your ASPs do not provide a point code on registration.
I suggested making the point code in the address used for registration
mandatory and you objected.

> 
> Else the point code of the ASP is the same as the point code of the SG.

And if the SG has multiple point codes?

So, if there is no point code in the registration and the SG supports
multiple point codes, what is the SG to do?

Does the SG:

a) Reject your registration, knowing that, following your proposal, it
   could receive messages from the ASP with underspecified addresses (in
   SCON or CLDT, CORE, etc.).

b) Accept your registration and send ERROR messages when it receives
   such underspecified addresses?  (Messages which of course the ASP
   is fully justified in ignoring.)  Is there an error for that?  Would
   we now need one?

c) Just pick a point code and send an SS7 network congestion message into
   the PSTN/PLMTN.  (Probably a bad idea.)

The trivial case where the SG has only one point code is not very
interesting, because it is not a provisioning difficulty to provising this
one trivial point code at the ASP.
   
IMO to support interoperability between SG an ASP implementations, it
would be better to make the presence of a point code mandatory in both
registration (enforceable by the SG), and in SNMM, CO and CL messages
containing addresses.

This is what was done for M3UA.  M3UA DATA messages contain (mandatory)
both point codes in both directions, even in the trivial case where the
SG only has one point code, and even in the case where RC can be
construed to imply point code.  For M3UA, the affected point code it is
also present (and mandatory) in the SCON message sent from ASP to SG.

I don't see why SUA should be any different.  I can't speak for the other
authors, but when we wrote the SUA RFC, I never considered that an ASP
or SG would ever not include a point code in an address.

Making the point codes mandatory in address fields for all SUA messages
better promotes interoperability in all configurations, and the miniscule
expense of causing an ASP to provision a single point code for an SG with
only a single point code.

--brian

-- 
Brian F. G. Bidulock
[email protected]
http://www.openss7.org/