Re: Recommendation for SUA modifications

Valerie,

How about this:

The following is necessary for an SG to be able to signal toward
the SS7 network in response to SCON from an ASP (as it MAY, or
in ETSI must) without confusing an overloaded use of the message
for an indication of SCCP congestion:

    The SCON message is used to report SCCP or SCCP subsystem
    congestion when a change in Restricted Importance Level
    occurs for an Affected Point Code in accordance with the
    relevant SCCP standard (e.g. Q.714).  It MUST NOT be used by
    an ASP to indicate other forms of congestion.

The following is now necessary for the SG to determine whether
it can discern a point code for any given message:

    The Routing Context is a mandatory parameter.

The following more clearly identifies that the parameter is
mandatory except in Lincoln's corner case:

    The Affected point code is a mandatory parameter unless the
    SCON is from ASP to SG, the ASP and AS are not provisioned
    with any point code, the ASP is connected to one and only
    one SG, the ASP does not perform GTT, the SG supports one
    and only one point code, and the SG is configured to not
    include an originating point code in the Source Address
    field of messages sent to the ASP.

Let's put that in the IG and then some time 3 or 4 years from
now after it goes to RFC and ETSI endorses it Lincoln can go to
the trouble of removing the point codes from his ASPs when
talking to SGs that don't send OPCs in accordance with SCCP
addressing requirements.

Then again, maybe by then we will have an SUA MIB that will
require it again anyway.

I think it is best to just leave it mandatory.

--brian

Valerie Gastaud wrote:                                                             (Fri, 14 Oct 2005 10:30:15)
> Lincoln, Brian et all,
> 
> Lincoln has explained the problem he tries to solve that requires a modification to the SCON and I think it's a valid case: SG and
> ASPs share the same Point Code and the ASPs are not provisioned with the PC value.
> Let's forget about the usefulness of such architecture. Since I don't think there are any other problem than SCON to solve in this
> case, why not trying to solve it.
> I propose the following text:
> 3.4.4.  Signalling Congestion (SCON)
> .....
> |             When the SCON is from the ASP to the SG, the affected point
> |             code is an optional parameter.  If not included, the SG
> |             must assume the affected PC is its own (primary) Point Code.
> 

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