Subject: Re: data issue 1: phone numbers

From: Greg Zhang <[email-masked]>
Date: Thu, 11 Mar 1999 22:19:20 -0800

Matt Squire wrote:

> a) Expressing a set of phone destinations as a prefix, range, regular
> expression, or other? The above methods have all been mentioned as
> possible methods of describing a colletion of phone numbers. I
> believe we've reached consensus on the use of prefixes as the best
> method, based on the use of heirarchical phone numbers and on the
> potential for aggregation.

How about allowing all three options including individual phone numbers
as a special case for regular expression? This will make the aggregation,
lookup and matching code somewhat complex. But it does provide
the maximum flexibility for real world use. With number portability, an
aggregrated entry will likely to have holes in it. If holes are to be avoided,
the entries in the database get very fragmented. They may end up to be
either ranges or descret numbers.

Of course, one can choose to make the holes hidden when propagating
the entries. Routing requests that reaches the wrong gateway will get
redirected. I am not sure if this approach can work. The wrong gateway
needs to know where to redirect the request to. In a case of multiple providers advertising the services for numbers in the same range, the holes will get aggregated/hidden. Gateways of some provider may not know which
gateway serves the numbers in the holes.

> c) What numbers are allowed in the database?

From a simplistic point of view, as long as the signalling server associated
with a LS is capable of handle signalling for calls to to a number, the LS
should be able to advertisement the number. I agree that local routable
numbers and 800 numbers should get fully qualified to E.164 numbers
before advertising. With corporate/private numbers, I would think with
proper scoping, they should be allowed to be advertised and stored in
the database. I am not sure whether you can or should convert corporate
private numbers to E.164 numbers. If not, we would need a type field
making the solution less elegant.

> For (b), I propose that we just go with a string of octet digits (ie
> 0x02 == '2'). If people feel the need to save space, we could encode
> two digits into a single octet, but in the interest of stating an
> opinion, I'll go with the 1 octet == 1 digit approach.

I vote for putting two digits in one octet. The code for encoding/
decoding this, and matching etc. is not complex or costly. Print it in hex,
it is perfectly readable to human too :)

> Scoping and portability will be discussed as separate issues.

Since number presentation and handling of corporate/private numbers
seems to be related to scoping and portability, we may not be able to
view them as separate issues. Having to handle them may make the
solution not as elegant as one would otherwise desire. But we may not
have a choice.

- Greg

---------
This message came from the IETF IPTEL Working Group Mailing List.

---

From: Matt Squire <[email-masked]>
Date: Thu, 11 Mar 1999 14:08:14 -0500

<bigger>Phone numbers.  

Most of these issues have been discussed on the list.

   a) Expressing a set of phone destinations as a prefix, range, 
regular

   b) Encoding number as string, binary string, hex string, or other?

   We've discussed multiple methods for encoding the phone numbers into

   the protocol.  I believe we've agreed on the use of some kind of

   string representation.  I don't know if we've reached agreement on

   the exact kind of string representation.  

   c) What numbers are allowed in the database?  There are (at least)

   the following categories of phone numbers which have been mentioned

   as in need of representation.

      * Global routable e164.  Standard international numbers like

        +19199929048.

      * Local routable (ie no country/area code).  An example would be

        9929048.  The number has local but not global significance,

        although it can be automatically mapped to a number with global

        significance.  

      * Private/corporate.  These are numbers which are routable within

        a particular area, but without global significance and without
an

        existing method for mapping the number to one with global

        significance.

      * "800" numbers.  These are numbers that are not routable in the

        PSTN.  In the PSTN, the "800" number is translated into a
routable

        number.  Such numbers have multiple purposes:

        - portability - the mapping to a routable number can be changed

        over time

        - scoping - the mapping can be different depending upon the

        source of the call, or the mapping is only visible to a

        limited set of servers

        - charging - since the caller is not exposed to the final

        destination, the callee is responsible for usage

        - a bunch of other reasons as well...

On the kinds of phone numbers supported, I assume we have consensus on

the necessity of routable e164 numbers and on the fact that local

numbers should not be permitted (ie they should be mapped into routable

e164s before going into the call routing infrastructure).  I believe

that we also have consensus that we can route to an "800" number, but

that THIS IS NOT THE SAME AS PROVIDING "800" SERVICES (ie we can treat

"800" numbers as a routable e164, but if this does not meet the needs 
of

the deployment, then such number should not be permitted into the

database - the protocol can route on any number that's in the database).  

The protocol does not place any restrictions on billing/charging.  If

the stated use of "800" numbers in the call routing infrastructure does

not satisfy the the billing constraints of the deployment, then "800"

numbers should not be permitted in the database.  The protocol also 
does

not require or prohibit a directory service that translates "800"

numbers to routable e164s.  

Scoping and portability will be discussed as separate issues.  Any other
'services' provided by "800" numbers should be dealt with as independent
issues and should be handled by attributes and not by handling a number
as 'special' because it has a certain form.

</bigger>

---------