Subject: RE: [Sigtran] SUA: GTT function placement

From: "Garnero, Pierre" <[email-masked]>
Date: Thu, 2 May 2002 18:10:59 +0200

Brian,

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Thursday, May 02, 2002 4:04 PM
> To: Garnero, Pierre
> Cc: [email-masked]
> Subject: Re: [Sigtran] SUA: GTT function placement
> 
> 
> Pierre,
> 
> Garnero, Pierre wrote:                     (Thu, 02 May 2002 14:56:39)
> > Brian,
> > 
> > I am not speaking about a SG that cannot service GTT for 
> > a given Routing Context.
> > I talk about a GT translation which refer to a point code 
> > that is no longer accessible on a given SG (and this information
> > has been, of course, transmitted to the AS thru a DUNA).
> > In this case, the GT translation (on the SG) works well but 
> the message
> > cannot be transmitted by the SG, due to the inaccessibility of
> > the remote point code. As others point codes could be seen 
> > accessible on this SG, I don't think that this SG must not 
> > be used (as a whole) by the AS...
> > 
> > Now, as the AS is aware of the pc states, it could be possible 
> > to perform a GT translation (may be without altering the message
> > to be send and keeping the called address as is, just to get the 
> > point code on which the message must be transmitted) and figure out
> > which SG is able to send this message on the ss7 network.
> 
> There is no need.  The ASP can send the message to the SG and it
> will receive CLDR indicating the routing failure if it has return
> on error set.  This will result in a N-NOTICE.  This is no different
> than if the GTT was local.  If local GTT results in an inaccessible
> point code or subsystem, the message will be discarded unless return
> on error is set.  The same end occurs:  the AS gets N-NOTICE.  There
> is no need to do this on the ASP as the SG is in a better position
> to properly return the CLDR.  As this gets translated into the
> appropriate TCAP procedure, the TCAP user does not care that the
> GTT function is at the SG.  The same is true for CO on CORE.  The
> SG would return COREF.
There is no need to do that if:
  . an SUA AS implementation does not expect to provide a synchronous
    return code to the application (and then rely on N-NOTICE indication
    only, if return on error is set). 
  . and also if the application agree to loose messages because one (and
    and only one) SG is not able to transfer message to a remote point code,
    due to a problem in the ss7 network
But, anyway, I think that it is an implementation problem in fact, not an 
SUA one, as far as SUA spec. does not dictate that it is forbidden to perform 
a GTT or a GTT test in the AS...
> 
> If you place GTT at the ASP, you no longer have ASP behavior, but
> IPSP behavior.
> 
> --brian
> 
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> 
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
> 

/Pierre

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 2 May 2002 12:07:28 -0500

Garnero,,

Garnero, Pierre wrote:                                   (Thu, 02 May 2002 18:10:59)
>     only, if return on error is set). 

OSI protocols do no return syncrhonous error code for protocol events:
only for formatting and other interface errors.

>     due to a problem in the ss7 network

If an SG cannot talk to a point code in the SS7 network, it also cannot
be attached to any other SG that can talk to that point code (or it could
tranfer via that other SG).  Therefore, if one is out they all are out, 
or the SG is completely isolated (in which case it should discontinue service
to the ASP using unsolicited ASPIA Ack).

> a GTT or a GTT test in the AS...

Correct.  There is no need to make any changes to messages.  Good luck getting
your ASP half-GTT to work with others' SGs.

--brian

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