Subject: RE: [Sigtran] SUA v16: Global Titles

From: "Barry Nagelberg" <[email-masked]>
Date: Thu, 12 Feb 2004 16:55:38 -0500

John,

Brian is right. The GTI that is defined in section 3.10.2.3 is closer to
ANSI than to ITU. I suggest that you remove "(defined in chapter 3.4.2.3 of
Q.713)".

Barry Nagelberg

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Wednesday, January 28, 2004 2:24 PM
> To: Barry Nagelberg
> Cc: SIGTRAN Mailing List; Seamus Gilchrist; Michael Perler
> Subject: Re: [Sigtran] SUA v16: Global Titles
>
>
> Barry,
>
> I think you'll find that it more closely resembles ANSI T1.112, which does
> not have a nature of address indicator.  Also, encoding scheme is
> only ever
> BCD (odd or even).  GTI in SUA and (for that matter) GTI in ITU
> and ANSI do
> not match.  The GTI in SUA, like ITU and ANSI indicates the fields present
> in the messsage.  If you need to specify any value, use SUA GTI=0100.  The
> SUA GTI does not dictate what is passed to the SS7 network by a gateway.
> The AMF or GTT result will determine that.
>
> Did you have a specific application that cannot be met with the current
> codings?
>
> --brian
>
> Barry Nagelberg wrote:
>                    (Wed, 28 Jan 2004 13:29:39)
> > We have some questions about global titles in SUA.
> >
> > First, in section 3.10.2.3 of SUA draft 16, the definition for
> GTI=0001 does
> > not appear to match with ITU-T Q.713 (1996) 3.4.2.3.1.
> According to Q.713,
> > GTI=0001 means that the global title information only contains
> a nature of
> > address and the global title address. According to the SUA
> draft, GTI=0001
> > means that the nature of address is ignored, that the
> translation type must
> > be 0 (unknown), and that the numbering plan must be 1 (E.164).
> What is the
> > reason for this difference?
> >
> > Also, section 3.10.2.3 does not include an encoding scheme
> field. The draft
> > says "Address signals to be coded as defined in ITU-T Q.713 Section
> > 3.4.2.3.1." That section of the ITU specification includes an
> example of how
> > the digits would be encoded if BCD encoding was used. Does this
> mean that
> > SUA only supports BCD encoding? If other types of encoding can
> be used, how
> > is the encoding scheme specified in the global title?
> >
> > Barry Nagelberg
> >

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

---

From: "Barry Nagelberg" <[email-masked]>
Date: Fri, 13 Feb 2004 11:58:49 -0500

Brian,

I don't understand what you mean by "If you need to specify any value, ...".
Of course I, and everyone else, must specify a value - GTI is not an
optional field in the Global Title parameter.

I also don't understand how we are supposed to map the GTI values given in
ITU Q.713 3.4.2.3.1 into the values specified in SUA section 3.10.2.3. These
seem to be two disjoint sets.

Barry Nagelberg

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 13 Feb 2004 10:56:28 -0700

Barry,

What I was trying to say was that SUA GTI 0100 global titles can map
nature of address into Q.713 GTI 0001 if you want to specify NAI from
SUA.  Normally, the SCCP GTT function at the SG would decide how to map
SUA GT fields (SCCP-User provided values) into SCCP GT fields.  This
mapping is not specified in SUA, because it is the business of the SS7 node,
however, as SUA GTI 0100 specifies all fields, it is always possible for SUA
to specify any field of a GT.  If you are looking for a 1:1 mapping between
SUA GTI values and SCCP GTI values there is none.  Again, selecting an SCCP
address format is the business of the GTT function at the SG.  This is a
normal function of SCCP.  So, for example:

                        |
                        |  N_UNITDATA_REQ
                        v
                +----------------+
                |                |
                |      SUA       |
                |     (ASP)      |
                |                |
                +----------------+
                        |
                        | SUA CLDT
                        v
                +----------------+
                |                |
                |      SUA       |
                |    (SG-AMF)    |
                |                |
                +----------------+
                        |
                        |  N_UNITDATA_REQ
                        v
                +----------------+
                |                |
                |      SCCP      |
                |                |
                |  Local GTT     |
                |                |
                +----------------+
                        |
                        |  UDT
                        v

All that is necessary is for SUA to provide fields to the N-UNITDATA-Request
(and other SCCP primitives accepting a Called Party Address).

The format of the Called Party Address parameter to N-CONNECT-Request and
N-UNITDATA-Request primitives is not specified (see, for example,
Q.711/6.2.2.2.1) and is implementation specific.  That is, a particular
implementation of SCCP will have made some choices there.  As ITU and ANSI are
rather different, an implementation of the SCCP/SCCP-User interface meant to
be generic across multiple protocol variants would not use GTI.  It might
indicate the presence or absence of each GT element in a GTI indepdendent
fashion.  I don't know what your specific implementation looks like.

So what I was saying is that if your SUA user wants to specify NAI, it should
formulate an N-UNITDATA-Request containing NAI.  SUA at the ASP can place this
value in the SUA Called Party Address with GTI 0100.  SUA at the SG can then
regenerate an N-UNITDATA-Request an issue that primitive to SCCP at the SG.
The local GTT function at the SG is responsible for deciding GTI and Called
Party Address format based on the N-UNITDATA request according to network
routing policy (local GTT datafill).  It is that function that will utlimately
determine the Called Party Address in any resulting UDT message.

For complete IP domain operation (IPSP) the fields populated in the
N-UNITDATA-Request primitive as placed in the CLDT can be indicated in the
N-UNITDATA-Indication primitive.

--brian

Barry Nagelberg wrote:                                                               (Fri, 13 Feb 2004 11:58:49)

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