Subject: RE: GLP, number portability and wireless subscribers

From: "Lu, Henry" <[email-masked]>
Date: Tue, 9 Mar 1999 13:10:34 -0600

Hello,

I am in favor of Pat's point but I am still hoping that we can
achieve a sound solution in order for us to handle number portability
environment in the future, including wireless.

The issues I see is how to synchronize two database between GLP and SS7
world. In AIN, 800 number information are kept in not only Signaling 
Control Point(SCP) but also Service Switching Point(SSP), normally in 
local DMS-100 or 5ESS switches. The 800 calling process had to go through 
a conversation session between SSP and SCP to figure out the final
routing to the destination. There are two information databases been
kept on both SCP and local SSP. Do not forget that there are many SSPs
in the network, not like SCP, we have to deal with.
The major problem occur when a new portable number been provisioned,
into both SSP and SCP but there is no information on GLP side.
GLP and SS7 database is out of sync basically.

How to solve this database synchronization problem, I do not have
a solution for you but I hope that we can see the nature of the
problem first. 

Henry W. Lu
925-598-1245
SBC, Technology Resources, Inc.
4698 Willow Road
Pleasanton, CA 94588

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

> 
> >> 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.
> >
> >Translation before the gateway selection is *obviously* the correct
model.
> We >should strive towards this goal.
> >
> >PatC
> >
> >
> 
> The next question is when before gateway selection.  Translation could be
> done as a pre-cursor to call-routing by the ingress, could be done by
> signalling itself via things like SIP redirections/proxies, or could be
> done within the routing infrastructure itself.  
> 
> I'd prefer one of the first two alternatives.  
> 
That seems to be the one that is least disruptive to the Internet (this is
my
perception). We are after all simply creating a new service that runs on top
of the Internet, so it does not seem wise to have to play with the routing
infrastructure.

PatC

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

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

---

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

> GLP and SS7 database is out of sync basically.

As you mention, the somewhat unusual way in which the database is
distributed in the phone network makes this a hard problem. The best way
to keep these databases in sync is to simply not have a separate
database. When a proxy or gatekeeper is going to make a call, it first
queries the phone network (somehow) to translate the number into a
routing number. GLP only advertises routing numbers. As such, the
database of number translations is stored only in the phone network, as
it is today. 

If, however, one chooses to deploy a parallel database in the Internet,
accessible by LDAP or some other means (enum perhaps?), the
synchronization problem exists.

Fortunately, it is outside of our charter to worry about this problem.
We need only decide what numbers may or may not be propagated by GLP,
and how they are represented and aggregated.

-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

---------