Subject: [Enum] Re: URL Generalization for Portability (was TRIP)

From: "Michael A. Ramalho" <[email-masked]>
Date: Thu, 16 Dec 1999 15:54:32 -0500

All,

Re: Tel URL grammar stuff like ...
>>         INVITE [email-masked]
>>         To: tel:5551212;trans=lnp?gdbs

I've been waiting for some discussion about the accuracy
of the time period in which the translation has been performed
to come up.

Virtually all of these telephony-centric LNP-type issues revolve
about databases which get updated on the order of once a day.

If LNP dips cost the service provider money (and external LNP
queries do) .... the service provider has a strong economic
incentive to cache the resolved numbers for use in subsequent
calls. [There is also a performance benefit for using cached data].

Shouldn't we provide a mechanism to at least give us a hint
that we are using potentially stale information (some mechanism
to deal with the soft-state issues from a variety of governmental
and/or service provider administered portability data bases).

Perhaps a tag that says when the "originally cached dip" was
performed to give a hint to a subsequent proxy how stale the
information may be. Any subsequent proxy could do what it
wished (i.e, do another database dip, if desired).

An evil service provider could forward an Invite with quite old
information instead of doing the remote dip itself .... but in the
case of frequently updated databases .... subsequent proxies
may have more accurate access to the current translation
(perhaps in it's cache, because it is more likely to service
more calls to this particular user).

This will surely kick off a discussion of how DNS solves this
issue vs. the GSTN ... but for the LNP issue ... we should
recognize the economic incentive for cashing information from
LNP databases that are updated relatively infrequently
AND that requirements for these updates are likely to change
in the future AND that it is highly likely that each database
administrator may have different policies regarding the frequency
and timing of database updates.

Does anyone know if such GSTN mobility/portability databases
are mandated (by ITU-T edict or defacto standard) to have a
globally understood update period (e.g., something like +x hours
from midnight GMT for a particular originating country code)?

Darn these legacy issues ... could we get the ITU-T to mandate
LNP/Mobility updates for ALL service providers to be accessed
through a DNS-like mechanism? I would doubt it, as it ruins the
present model of charging other service providers for such information.
The present charging model will die soon anyway ... perhaps we can
help accelerate the change?

Lastly, does anyone know if TIPHON has useful thoughts on
this issue?

I apologize in advance for the subsequent discussion thread,

Michael Ramalho

At 10:34 PM 12/15/99 -0500, Henning Schulzrinne wrote:
>Dean Willis wrote:
>> 
>
>> > Its possible that we might even see things besides phone numbers as user
>> > names that are valid across multiple domains. An example is (heaven
>> > forbid), social security numbers (in the US, at least):
>
>In a few years, Microsoft will assign every human being a GUID :-)
>
>> 
>> The underlying problem here is differentiating between a phone-number and a
>> service-name-which-looks-like-a-number. Yes, the user=phone gives a hint on
>> nature od address, the "+" encodding gives a hint on the scope of address,
>> but it is still muddy.
>
>A phone number in a SIP URL is indeed of local significance, within the
>scope of the proxy or gateway. Thus,
>
>INVITE [email-masked] SIP/2.0
>To: tel:+12015554012
>
>might be used when dialing a number that turns out to be a "tie line" or
>voice VPN.
>
>> 
>> There was some discussion of this problem wrt DCS during the November
>> interim meeting. It was suggested that a cross-domain destination which is a
>> phone number could be better represented by a tel: URL than by confusing the
>> scope of the user part of a sip: URL. This simplilifies life greatly.
>> 
>> Something like
>> 
>>         INVITE [email-masked]
>>         To: tel:5551212;trans=lnp?gdbs
>> 
>> could be used to indicate to gateway.carrier.com that premium gateway
>> service is requested towards the PSTN location identified by telephone
>> number 5551212, that LNP and GDBS translation have been applied, and that
>> the phone number is of local scope for the gateway. Incidentally, I think I
>> just noticed a minor anomaly in the tel-url grammar -- don't see how to
>> encode more than one future-extension field . . .
>
>Is somebody talking to the author of the tel: URL Internet Draft to make
>sure this discussion doesn't get lost?
>
>> 
>> --
>> Dean
>
>-- 
>Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
>
>

Michael A. Ramalho, Ph.D.
Cisco Systems
1802 Rue de la Port
Wall Township, NJ 07719-3784
Office email: [email-masked]
Personal email: [email-masked]
Office: +1.732.449.5762
Cell: +1.732.809.0188
Pager: +1.800.365.4578

_______________________________________________
enum mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/enum

---

From: "Albert Manfredi" <[email-masked]>
Date: Thu, 16 Dec 1999 16:24:21 -0500

On update time periods, my reading is that the DNS and the NPDB
(number portability database) have update periods on the order of
several hours. Maybe 8 hours or more. And that mobility databases
are updated in minute(s). Which is another indication that the DNS
could fill the role of the NPDB, if it comes to that, or certainly
that the DNS could provide that role for IP users wanting to access
portable telephone numbers.

I've seen studies that address the rapid synchronization of huge
database systems (D. Lam, Y. Cui, D. Cox, J. Widom, "A Location
Management Technique to Support Lifelong Numbering in Personal
Communications Services," Proceedings of 1997 IEEE Global
Telecommunications Conference, Volume 3, pp. 704-710, 1997), and I
suppose ultimately the DNS could migrate to that sort of structure.
But for now, the speed required for mobility updates is handled by
keeping those tables in very few servers (distributed according to
service provider).

Bert
[email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 17 Dec 1999 21:08:10 -0500

> wished (i.e, do another database dip, if desired).

This merely seems to be passing the buck. If there are issues with data
staleness,
ought we not solve them at the database (i.e., DNS) level, rather than
within SIP?

-Jonathan R.
-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: "Mark D. Foster" <[email-masked]>
Date: Mon, 20 Dec 1999 01:11:49 -0500

> > about databases which get updated on the order of once a day.

This may be true in some countries today, but not in those with IN-based
LNP.  In the US and Canada, updates to the LNP database are broadcast in
real-time to service provider systems, with contractually mandated broadcast
and transaction response times (e.g. 3 seconds max) for example.  Part of
the reason for this type of quick turnaround is that stale LNP data can
cause looping of SS7 messages, and therefore de-stablize carrier's signaling
backbones, to say nothing of customer's not having any inbound telephony
service until database updates are propagated and calls properly routed.
Neither of these factors will change with iptel.  For example, the LNP
database will be needed to route SS7 TCAP messages using telephone
number-based GTTs, regardless of whether the lower layers are MTP or
M3UA+RTSP+IP.

> > calls. [There is also a performance benefit for using cached data].

Caching is not an effective answer, because unlike domain name lookups, the
lookup frequency of geographic numbers by value is uniformly flat and
uncorrelated, and the TTLs must be set to relatively short intervals to keep
looping probabilities managably low.

Consequently, telcos today either host a copy of the entire database
associated with their service area (by subscribing to the NPAC database
update feeds), or buy query transactions from someone else who does.

> ought we not solve them at the database (i.e., DNS) level, rather than

I agree with Jonathan here.  Fortunately, there is no staleness problem with
the databases today, nor do we have to introduce one where it doesn't exist.
Avoiding stale data is also consistent with the FCC requirement of not
relying on the donor network for call-related (in this case, database query)
processing.  Service providers must be free to choose who will host the
database their resolvers will consult.

R, Mark
-------------------------------------------------------------
Mark D. Foster                  | EMAIL: [email-masked]
CTO                             | NeuStar, Inc.
TEL: +1 202 533 2800/2702       | FAX: +1 202 533 2975
1120 Vermont Ave NW, Suite 550  | Washington, DC 20005

---

From: "Albert Manfredi" <[email-masked]>
Date: Mon, 20 Dec 1999 14:05:40 -0500

> number-based GTTs, regardless of whether the lower layers

Maybe then this LNP database is comparable to IP routing tables
distributed throughout routers. At least, functionally, since it is
required for routing of telephone calls. (By the way, I didn't know
that the LNP database entries are broadcast. Interesting. This
compares with the propagation of info in schemes like OSPF or RIP,
which is asynchronous, and only between neighbors.)

> looping probabilities managably low.

Just as long-term caching of routing tables is not effective in the
Internet. I don't think this is comparable to the DNS, though,
because the DNS does not have information that is used in routing.
The DNS does not need to respond, for example, to any temporary
breaks in the infrastructure. The DNS is more like a telephone
_directory_.

> Fortunately, there is no
> staleness problem with

The staleness issue is not an issue in what I thought we were
discussing, unless I missed something.

The DNS used in the role of number portability database or in the
role of IP-to-E.164 number translation database is not used in a
time-critical role at all, as far as I can see. For real-time
routing roles, such as tracking of _mobile_ stations or the
maintaining of routing tables, I think everyone agrees that the DNS
is not the correct solution.

Bert