Re: Encoding scheme, Number of Digits parameters, GTI in SUA message

Thanks Brian.
It was helpful indeed.
The GTI mapping is not mentioned in the RFC, it was confusing to only reference to ITU spec and wonder what should happen to ANSI.
I now understand that Encoding scheme is now derived from the "Number of digits" parameter , if there are 5 octets and Number of digits is 9, then it is odd, if number of digits is 10, it is even and there cant be values other than 9/10 for a 5 octet digits parameter.

Regards,
Satya



-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email protected]] 
Sent: 15 January 2013 21:42
To: Nemana, Satya
Cc: [email protected]
Subject: Re: [Sigtran] Encoding scheme, Number of Digits parameters, GTI in SUA message

Satya,

Please see comments inline...

Nemana, Satya wrote:                    (Mon, 14 Jan 2013 14:16:06)
> Hello!
> 
> I had two questions trying to understand a problem with GT in SUA.
> 
> 1) Why is the encoding scheme parameter normally present in the SS7 
> messages absent in the SUA message as a parameter. In the absence of 
> the encoding scheme in the SUA Called party GT, how does the SUA NIF 
> analyze the digits.

They are always encoded as digits (i.e. nibble encoded digits) per RFC 3868/3.10.2.3.

> 2) The number of digits in the SUA message (called party) is already 
> known depending on the digits included, i.e if I have a GT of 
> 0123456789, then I have 10 digits. In such a situation where the 
> number of digits present is implicitly known, why do we have an other 
> parameter " Number of Digits" to tell the same? What is the 
> significance of this parameter?

10 digits is not implicitly known unless it can be determined from the translation type.  5 octets of digits can be either 9 or 10 digits.  The odd/even indicator indicates this in SS7.  In SUA we used a full digit count (we had enough bits) instead of an odd/even indicator.  It avoids having to interpret fillers and can be directly calculated off of the odd/even indicator and the length of the digits (in octets).

> In most cases, GT is a phone number, why would we want to use only 
> part of it for processing the message? (there would have been a 
> wildcard GT provisioned for the destination(s) on the SG/STP to handle 
> the case of using a subset of the digits.

The no. digits field does not encode a subset of the GT digits.  For example, 5 octets of digits with a 'no. digits' field of 3 would be an
error: the field would have to be 9 or 10.

> 3) Also, in section 3.10.2.3, the text <snip>
> 0001 Nature of Address is taken over
> <snip>
> What does "taken over" mean? (Sorry, I don't mean the English meaning 
> of it but taken over in this sentence : When there is an explicit 
> Nature of Address parameter in SUA messages , I don't understand what 
> is taken over here?)

It assumes the same value at the corresponding field in the SS7 SCCP
message: that is, it is "taken over" from the SS7 message.

> 4) ANSI specs and ITU specs for message format for different GTI 
> values are different
>
> Example :
> ANSI GTI 1 : Global title includes translation type, numbering plan 
> and encoding scheme ITU GTI 1 : global title includes nature of 
> address indicator only SUA RFC only specifies ITU spec Q.713 
> reference.
> Is it just for an example, and that similar formats should be used 
> from ANSI or other specs wherever possible?
> Or is it to say that the format for the particular GTI is now 
> redefined with the SUA spec and this should be used?

Read the line over the descripton of GTI values:

  "GTI (Global Title Indicator, defined in chapter 3.4.2.3 of Q.713)"

These _are_ the values of the ITU GTI.   ANSI defines fewer and more
restricted GTIs.  SUA uses the ITU GTIs and maps ANSI values into them.
ANSI GTI(1) maps into ITU GTI(3), ANSI GTI(2) maps into ITU GIT(2).

I hope that helps.

--brian

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