Re: [Sigtran] SUA v16: Global Titles

["Brian F. G. Bidulock" <[e-mail]>]

Barry,

Remember that the value "unknown/unspecified" means "unspecified" in the
request/response direction and "unknown" in the indication/confirmation
direction.  When using any GTI, unspecified fields can be coded
"unspecified".  Note that I said that SUA GTI 0100 allows any field to
be specified (and the remainder are "unspecified").  This is true for
SCCP as well.

I hope that clarifies why no additional protocol elements are required
by SUA.

--brian

Barry Nagelberg wrote:                                                               (Mon, 17 May 2004 19:13:00)
> Brian,
> 
> Thanks. As you can see, it's taken me some time to digest this.
> 
> I think I now understand your approach, but I think that you may be
> over-simplifying a bit, and I suspect that we must add something to SUA.
> 
> Let's follow up on your example below. Let's say that an ITU SCCP-user at
> the ASP sends a UNITDATA_REQ primitive to the SUA layer at the ASP with a
> global title address parameter that has only a Nature of Address indicator
> (GTI = 0001). By definition, the other Global title fields - Translation
> type, Numbering plan and Encoding scheme - are absent.
> 
> You propose that the SUA at the ASP send a CLDT msg to the SG, with GTI =
> 0100. But because GTI = 0100 requires that _all_ of the Global title fields
> be _present_, the ASP SUA must choose some arbitrary value to populate the
> fields that were absent in the UNITDATA_REQ.
> 
> Now when the SG SUA layer receives the CLDT msg with GTI = 0100, it thinks
> that it has received a fully-populated address, and has no way to know that
> the values in the Translation type and Numbering plan fields are, in fact,
> arbitrary. As far as it knows, they are real. So it will go ahead and
> include these arbitrary values in the UNITDATA_IND that it sends to the SCCP
> layer at the SG. The SCCP layer will not be very happy after trying to
> decode these arbitrary values.
> 
> I think that we must specify in SUA some value that is defined to mean that
> "this field has been populated with an arbitrary value and should be
> stripped from the address". Zero would be the logical choice, as it is
> already defined as "unknown" for Translation type, Numbering plan and Nature
> of Address.
> 
> Barry Nagelberg
> Adax, Inc.
> 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[e-mail]]
> > Sent: Friday, February 13, 2004 12:56 PM
> > To: Barry Nagelberg
> > Cc: SIGTRAN Mailing List; John Loughney; Michael Perler
> > Subject: Re: [Sigtran] SUA v16: Global Titles
> >
> >
> > 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,
> > >
> > > 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
> > >
> > > > -----Original Message-----
> > > > From: Brian F. G. Bidulock [mailto:[e-mail]]
> > > > 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/sigtran

-- 
Brian F. G. Bidulock
[e-mail]
http://www.openss7.org/

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