Re: Congestion in M3UA/SUA and the use of the SCON

Lincoln,

Read down just a couple paragraphs: (the section you quote is applicable
to SCCP routing, not information delivered to the SCCP-User).

3.10.2.2.  Address Indicator

   This parameter is needed for interworking with SS7 networks.  The
   address indicator specifies what address parameters are actually
   received in the SCCP address from the SS7 network, or are to be
   populated in the SCCP address when the message is sent into the SS7
   network.  The value of the routing indicator needs to be taken into
   account.  It is used in the ASP to SG direction.  For example, the PC
   parameter is present in the destination address of the CLDT sent from
   ASP->SG, but bit 2 is set to "0" meaning "do not populate this in the
   SCCP called party address".  The effect is that the SG only uses the
   PC to populate the MTP routing label DPC field, but does not include
   it in the SCCP called party address.

   In the SG->ASP direction, the source address PC parameter is present
   (PC of SS7 SEP).  However, this may have been populated from the OPC
   in the received MTP routing label, not from the PC field in the SCCP
   calling party address.  In this case, bit 2 = "0" denotes that.  The
   AI gives further instructions to the SG how and when to populate the
   SCCP addresses; in the SG->ASP direction, the AI gives information to
   the ASP as to what was actually present in the received SCCP
   addresses.

If this is so unclear that you do not understand that both the source
and destination addresses always have PC populated when interworking
with SS7 (just bit 2 of the address indicator set to indicate whether
it came from the MTP routing label or the calling or called part
addresses), we need to add to the SCCP I-G that when the CLDT, CLDR,
CORE, COAK, COREF is sent from an SG to an ASP that one of a PC,
Hostname, or IP address MUST be included in both the destination and
source addresses.

--brian

Haresign Lincoln wrote:                      (Tue, 11 Oct 2005 08:51:51)
> Brian,
> 
> The result of the GTT is a point code/SSN.  However this information
> does not need to be forwarded to the ASP in the address field.  A CLDT
> message can arrive at the ASP with _NO_ DPC in the message anywhere.   
> 
> Please refer to the defintion for source address in section 3.10.2:
> 
>    -  Global Title (e.g., E.164 number) + optional PC and/or SSN, SSN
>       may be zero, when routing is done on Global Title
> 
>    -  SSN (non-zero) + optional PC and/or Global Title, when routing is
>       done on PC + SSN.  The PC is mandatory in the source address when
>       sending from SGP to ASP, and in the destination address when
>       sending from ASP to SGP to reach the SS7 SEP.
> 
>    -  Hostname + optional SSN, when routing is done by Hostname
> 
>    -  SSN (non-zero) and optional IP address (IPv4 or IPv6) when routing
>       is done on IP address + SSN
> 
> It is _NOT_ required that the SG provide the PC/SSN in a CLDT message.
> Therefore, if the ASP wants to implement the OPTIONAL SCON procedure,
> and it is working with global titles, we need to modify the SCON message
> requirements.
> 
> Regards,
> Lincoln
> 

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