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

Lincoln,

Oh, also MUST be included in the source and destination addresses of
the Registration Request, because you confused that one too.

I'm sorry but the concept of an SCCP-User that knows the point code of
every node in the SS7 network that it might want to send messages to,
except its own, is not a very useful one.

--brian

Brian F. G. Bidulock wrote:                    (Tue, 11 Oct 2005 10:58:47)
> 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/
> 
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran

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