Subject: GLP, number portability and wireless subscribers

From: "Greg Zhang" <[email-masked]>
Date: Mon, 8 Mar 1999 13:26:56 -0800

Hello,

One issue needs to be considered is number portability. Number portability
(NP) is reality for wired POTS lines for some time now. Wireless Number
Portability will be a reality in a few years' time. The portable numbers
cannot
be routed by strictly following the hierarchy derived from the digits of
called
number. When the number of portable numbers is small compared to all
telephone numbers in the network, it can be handled on an exception bases
meaning route the call following the hierarchy then back track when hitting
a dead end. This is approach used in the first generation systems that
supports number portability. However, when the number of portable numbers
gets higher, the inefficiency in the approach becomes more pronounced.
Differentiation of portable numbers or the correct lookup of the
switch/gateway
where the called number resides needs to be done much earlier in the
SETUP forwarding path.

With the competition in local access market heating up and new area code
added using overlay instead of split, aggregation based on the number
hierarchy starts to make less and less sense. On top of this, with cell
phones
becomes cheaper and cheaper to have, and the wireless bandwidth grows
higher, to support roaming/mobility of wireless subscribers both within
wireless networks and across wireless and wireline based networks,
phone numbers will need to be handled more and more on a individual
bases.

To make GLP for IP based telephony networks future proof, the protocol
needs to support unaggregated  location information for telephone numbers.
Of course, this will increase the volume of traffic. But if the information
is
basically unaggregable, it is just the nature of the problem itself. It will
probably requires a different solution than it is currently outlined in the
two proposals that we currently have.

I am in the process of writing up a design that is used for propagating
location information among mobile telephony gateways. Although the
original design target is a IP based carrier class wireless telephone
network. It can be used to solve the generic gateway location problem
in a IP telephony network. If there is enough interest, I can outline the
design or send my document to the group for discussion.

Best regards,

- Greg

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 09 Mar 1999 10:27:31 -0500

Greg Zhang wrote:
> number. 

I agree LNP makes the problem harder. I have two responses here:

1. Simply "not aggregating" is always an option for a protocol which
provides aggregation. I don't want to not support aggregation because of
LNP. If LNP gets in the way, it can just be turned off if needed.

2. I'm not yet convinced LNP actually prevents aggregation. Lets say
gateway X can reach ten numbers, +1 607-1* (using glob matching), +1
607-2*, etc. so these could be aggregated to +1 607*. Lets further
assume all ten numbers are LNP, and actually terminate all over the
country. These numbers can still all be reached through the gateway.
They cannot be aggregated only if the attributes for each are different.
The only attribute likely to differ is cost. So, the question is, does
the cost (to the gateway provider) for terminating calls to each of the
numbers differ? Even if they do, is the cost the gateway provider wants
to charge to its users different for each number? If the answer to
either is no, then they can still be aggregated. With long distance
rates at 10 cents a minute *anywhere* in the U.S., this seems not so
unlikely.

There is a related issue of 800 numbers, and any of the other
non-routing numbers. Should these be advertised by GLP? Or, should they
be translated first, and then the translated numbers advertised? (Please
correct me if I have misunderstood some aspect of how this works in the
PSTN).

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---------

---

From: "David R. Oran" <[email-masked]>
Date: Tue, 9 Mar 1999 11:02:00 -0500

Jonathan R. wrote...
> correct me if I have misunderstood some aspect of how this
We may not be sunk if we try to handle "non-routing numbers" in a
routing protocol, but it sure would be nice to minimize or eliminate the
need to. It would save a lot of bandwidth and memory.

One idea I've kicked around is to have an explicit syntactical marker on
an E.164 number so anybody processing it knows whether that number
represents a destination rather than a "directory number". Then we try
to only feed final destinations into the routing protocol. For the LNP
case, it may mean finding a way to explicitly carry "office codes" in
the protocol. For the 8xx/700 number cases we may wish to simply declare
these to be names and ban them from the routing advertisements.

Dave.

---------

---

From: John Schnizlein <[email-masked]>
Date: Tue, 09 Mar 1999 11:26:10 -0500

At 10:27 AM 3/9/99 -0500, Jonathan Rosenberg wrote:
>
>I don't want to not support aggregation because of

Which "it" do you mean can be turned off? 

>607-2*, etc. so these could be aggregated to +1 607*. 

Aggregation coexists with a moderate amount of "ported numbers" because
most numbers are still covered by the aggregations.
You can keep +1 607-555-1212 in the same database with +1 607-444*
and the ones you listed if you use longest-match lookup.

>correct me if I have misunderstood some aspect of how this works in the

I see 800 number portability as the leading use of LNP, not just related.
The PSTN assumes that ported number will be the exception.
Aggregation by <area><exchage> is used as before LNP unless any number
in an exchange has been ported. If an exchange included a ported number,
the "right" switch looks up the exception in a process called "Global
Title Translation" and forwards the call to a guaranteed-not-ported number
of the switch to which the number was ported.

Longest match enables more flexibility than the fixed fields of area and
exchange as partial addresses, and facilitates keeping the routing for
aggregated destinations in the same database as the (LNP) exceptions.

John

---------

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 09 Mar 1999 11:37:06 -0500

> Which "it" do you mean can be turned off?

Aggregation.

> and the ones you listed if you use longest-match lookup.

Agree.

> of the switch to which the number was ported.

This begs the question, then: does the translation of the 800 number get
done before the gateway selection process, or after? By doing it before,
a gateway can be chosen which is, in fact, close to the real number
being dialed. With 800 numbers, all gateways will be able to reach it.
It seems that this opens the possibility of very non-optimal routing. A
caller in NY that dials an 800 number, goes to a gateway in CA. The
phone network there determines that the 800 number translates to a
number in NY, and routes the call through the PSTN back to NY. However,
if the translation occurs before gateway selection, the caller can
choose a local NY gateway and do much better.

-Jonathan R.

---------

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 9 Mar 1999 08:54:30 -0800 (PST)

> choose a local NY gateway and do much better.

Translation before the gateway selection is *obviously* the correct model. We
should strive towards this goal.

PatC

---------

---

From: Scott Petrack <[email-masked]>
Date: Tue, 9 Mar 1999 12:07:18 -0500 (EST)

The translation of "directory numbers" to "network numbers" can have a lot
of dependencies that are unrelated to GLP -- the calling party id, the
time of day, some ACD info. 

I suppose that GLP advertisements are meant to be valid for some time
which is related to an estimate of how long the particular gateway will be
in service, rather than (say) that it can service a number until close
of business at 5pm EST.

That being said, of course Dave is right that there are a lot of 800
numbers which are perfectly static, and it would be a very useful
optimization to be able to advertise those numbers. 

Bottom line: I don't see why we should forbid a gateway from advertising
an 800 number if it wishes to, but we still need a separate "directory
number to network number" lookup protocol. 

Scott 

---------

---

From: "David R. Oran" <[email-masked]>
Date: Tue, 9 Mar 1999 16:12:08 -0500

I'm reluctant to bring this up, because some would view it as a corner
case or just a "feeeeture" of the PSTN, but when the PSTN does number
translation (or call forwarding in the network as well), the resulting
number is not revealed to the calling party. The pure directory scheme
would reveal the translated number since that's what would be put in the
end-to-end signaling (e.g. SIP, H.323). Do we care about this?

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Tuesday, March 09, 1999 1:43 PM
> To: [email-masked]
> Cc: John Schnizlein; Greg Zhang; David R. Oran; Matt Squire; Scott
> Petrack; Alok Mittal; iptel
> Subject: Re: GLP, number portability and wireless subscribers
>
>
> Hussein F. Salama wrote:
> >
> > Jonathan Rosenberg wrote:
> >
> > >
> > Because of the above example, I think all types of translation (800
> > numbers or LNP) and mapping should occur prior to call
> routing. This is
> > particularly important for 800 numbers, because they have a regional
> > scope in many cases. The same 800 number may owned by
> company X in CA
> > and company Y in NY. In the above example, the call will be
> incorrectly
> > routed to company X instead of going to the originally intended
> > destination, company Y.
>
> This is another good example of why translation before
> gateway selection
> is a good idea. However, I'm not sure there is much we can do from a
> protocol perspective to prevent it. There may be valid reasons why a
> company would like to advertise an 800 number (only they own it, for
> example), and I'd rather not exclude this possibility. It seems like a
> sensible approach is to allow non-routing numbers in GLP, but mention
> that there are issues with them, and translation before routing is a
> good idea. Does this sound sensible?
>
> Scott P., of course, is right, that the translation service itself is
> outside the scope of iptel.
>
> -Jonathan R.
> --

---------

---

From: Scott Petrack <[email-masked]>
Date: Thu, 11 Mar 1999 19:22:17 -0500 (EST)

> end-to-end signaling (e.g. SIP, H.323). Do we care about this?

This question has nothing to do with PSTN gateways or GLP, right? It has
to do with a system based on end-to-end signalling, like SIP and H.323.

If a called party doesn't want to reveal his/her "real" address, then s/he
must set up a SIP proxy server which will get the invitation to the "fake"
address, and the proxy will pass the invitation to the real address. 

In other words, if you need this feeeeeture within a SIP/H.323 system,
then you need to use a SIP proxy server or H.323 GK routed signalling, and
then the "translation" service will return the "fake" routing number.

Scott

---------

---

From: "Louise F. A. Spergel" <[email-masked]>
Date: Wed, 10 Mar 1999 11:18:30 -0500

My comments below are specific to the US. I don't have any knowledge on
other countries.

With 800 numbers, the issue is different due to the current implementation
and regulatory constraints. In 800 service, the called party pays,
therefore the called party picks the carrier, which currently are all
PSTN-type carriers. The carrier for each number is contained in a database
which is accessed by SS7 TCAP. This database is maintained by a neutral
party. In the near-term, you will need to consult this particular database
and to find the right carrier and then hand the call to a gateway to that
carrier. 

At some point I think the SIGTRAN protocols will enable this.

Of course, in the long run, this may change somewhat.

Louise

---------

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 09 Mar 1999 18:00:39 -0500

> end-to-end signaling (e.g. SIP, H.323). Do we care about this?

The pure directory scheme won't necessarily have this characteristic.
For SIP, if a proxy does the lookup, the called number is placed in the
Request-URI. The To and From fields remain unmodified. As such, the
caller will never see the translated number. The called party may see
this number, but if it does, its only because its the next hop. Having
the called party see this number seems a non-problem, since its the
number for that party anyway. The problem you describe only arises if
the caller itself performs the directory lookup. Whether service
providers allow end users to query their 800 number directories directly
is a good question, so this case may never happen. I'm not sure how this
would work in an H.323 context.

In any case, this is outside the scope of iptel. 

-Jonathan R.

---------

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 09 Mar 1999 13:43:03 -0500

Hussein F. Salama wrote:
> numbers or LNP) and mapping should occur prior to call routing. This is
> scope in many cases. The same 800 number may owned by company X in CA
> and company Y in NY. In the above example, the call will be incorrectly

This is another good example of why translation before gateway selection

-Jonathan R.

---------

---

From: "Hussein F. Salama" <[email-masked]>
Date: Tue, 09 Mar 1999 09:33:43 -0800

Hussein

-- 
Hussein F. Salama
Cisco Systems
Mail Stop SJC6/3, 170 W. Tasman Drive, San Jose, CA 95134
Voice: +1 (408) 527-7147, Fax: +1 (408) 527-2499

---------

---

From: Scott Petrack <[email-masked]>
Date: Tue, 9 Mar 1999 12:30:23 -0500 (EST)

On Tue, 9 Mar 1999, [email-masked] wrote:

[Jonathan R:}
> > done before the gateway selection process, or after? By doing it before,
...
> should strive towards this goal.

Well, yes, but there are lots of 800 numbers whose translations change on
time scales MUCH slower than the GLP advertisement changes. In fact, most
800 numbers are this way -- they are used by small-to-medium
businesses, point to the 'real' telephone number, with no
logic at all, and don't change at all.

If a GW wants to advertise that it can service such a number, I don't see
why it should be forbidden from doing so. 

[Of course there is a need for a separate look-up and translation service,
but this is outside the scope of Iptel - right Jonathan? ;-)]

The general problem of for how long the advertisements are valid, and how
quickly change can be propogated, is just that general -- there is nothing
special about 800 numbers or other directory numbers. 

Scott 

---------

---

From: Douglas Clowes <[email-masked]>
Date: Wed, 10 Mar 1999 12:36:47 +1100

Scott,

I agree with you - almost.

>time of day, some ACD info. 

"Directory" numbers, and speed-dial numbers are examples of dialed numbers.
They do need to be translated, in the caller's context. Some of them,
particularly the "directory" ones will translate into obvious network
numbers, but the translation should not be overlooked or ignored. For
example, 555-1212 may translate into +1-415-555-1212 in one location, but
+1-212-555-1212 in a different location. I believe that 1-800 numbers
observe a similar characteristic, they can translate into different network
addresses which are dependent on some characteristic of the caller's
context - their location.

Down under, we have 13 (one-three) numbers. They're like 1-800 numbers,
except the caller pays the cost of a local call while the callee also pays,
based on distance. Take-out pizza chains, banks, insurance companies, and
government departments all love them. You dial the number and get routed to
the local entity - if there is one.

I believe that 1-800 numbers are much the same.

Portable numbers are just another example of a dialed number. They need to
be extended with default local context, before being translated into a
routing number. When I dial 555-1212 in Kalamazoo (MI), I really mean
+1-616-555-1212. In the morning, this translates into routing number
+1-212-555-1212. After noon, the routing number becomes +1-415-555-1212,
and late at night +1-313-555-1212.

>in service, rather than (say) that it can service a number until close

This sort of thing bothers me. Are you talking about the dialed number, or
the network/routing number?

If it's the dialed number, then there may be a different translation,
depending on location, or time of day. At some times, there may be no valid
translation, or a translation to a network number that is busy, or unmanned.

If it's a network number, then it should translate into something routable,
almost physical. It shouldn't suddenly cease to exist (outside the quantum
theory of Internet Telephony, the ID for which I've yet to see), but may be
busy or unanswered.
 
>optimization to be able to advertise those numbers. 

Because the callee pays, probably distance related charges, the callee
would like to control which gateways advertise their numbers. If their only
office is in NYC, they would rather restrict advertising to NYC, than have
some gateway in SFO advertising "their" number.

Every gateway connected to the PSTN has the same "costs" to the caller for
every 800 number. If the callee has their own gateway (no cost to them)
then they should be permitted to ban other gateways from advertising their
number at no cost.

In addition, callees who have devices that can handle calls, should be able
to stake an exclusive claim to their particular network number, as well as
their directory number. In which case, their directory number may translate
into a "network number", which translates into a transport address, but
would probably translate directly into a transport address.

>number to network number" lookup protocol. 

Isn't that "Alias Address to Transport Address" lookup protocol. It may be
the same protocol. It may be used once, or several times. It may be used
differently, or the same.

Aggregation:
============

Portable numbers, and 800 numbers, are issued by somebody - you don't just
invent your own. These numbers are allocated from a range under the control
of somebody. These ranges are aggregated before they are allocated.

Routing numbers are also allocated by somebody. They are also aggregated
before allocation. Same deal. Frequently, or at least historically, the
allocating entities have been the same, and the allocation algorithms have
been linked.

Now we are talking about them being separated. And they are separated in
the mobile telephony world. Now, people with expertise in mobile telephony
will probably tell me this isn't the way it works, but it is a way it could
work.

I buy a mobile telephone, and select a service provider. I get a SIM card
and am told my phone number is X. Transparent to me, my SIM card has its
own number Y. Both X and Y are from a range allocated to my country, and my
service provider, and possibly my locality. My subscriber enters (X, Y)
into their database.

I switch off my mobile phone, and get on a plane (or the other way round).
When I get off, I turn on my phone. My phone tells the local carrier that
my SIM card number is X. The carrier can tell by the aggregation rules of
X, who is the responsible service provider, and establishes that they will
be paid for calls made. They also announce to the service provider how X
can be called.

When someone dials Y, the rules of aggregation, which are different from X,
direct the caller to my service provider. My service provider translates X
into Y, and redirects the call to the mobile carrier described above.

Presumably, as I roam about, the mobile carrier is updating the
relationship. It could either be in my service provider, or in the mobile
carrier, as I roam from tower to tower. It will be in my service provider,
as I roam from carrier to carrier, and country to country.

That is at least two distinct sets of aggregation. Perhaps the mobile
carrier address is also aggregated as well.

My phone number is countryCode.carrierCode.directoryNumber,
 while my SIM number is countryCode.carrierCode.subscriberNumber,
 and my temporary roaming id is countryCode.carrierCode.temporaryNumber!

In DNS, it might be 555-1212.616.1.dialled-number returning
555-1212.415.1.network-number, then translating that returns
[email-masked] etc....

Here the allocating authority for +1-616 is hit for the first translation,
while the gateway provider for +1-415 is hit for the second, and
recursively translated by ns.megatel.com.

>Scott 

Douglas

---------

---

From: "Henry Sinnreich" <[email-masked]>
Date: Sun, 14 Mar 1999 14:06:56 -0600

>logic at all, and don't change at all.

Still there is time of day routing for 800 numbers.

Henry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Scott
Petrack
Sent: Tuesday, March 09, 1999 11:30 AM
To: [email-masked]
Cc: Jonathan Rosenberg; John Schnizlein; Greg Zhang; David R. Oran; Matt
Squire; Alok Mittal; iptel
Subject: Re: GLP, number portability and wireless subscribers

[Jonathan R:}
...

Scott

---------

---------

---

From: Scott Petrack <[email-masked]>
Date: Sun, 14 Mar 1999 16:54:49 -0500 (EST)

yes, of course, Henry, you are right. My point was that there are 800
numbers without time-of-day routing, and such numbers could clearly be
routed via GLP without any problem at all. 

My guess is that 800-numbers-with-time-of-day-routing are ones that we
don't want to advertise via GLP. Of course there is a slippery slope here
-- maybe we could add a time of day "scope" to the numbers -- but I think
that we don't want to go down that path (too much soap). 

Scott

---------