Subject: Re: Human readable Route descriptors

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

This function is useful, but I'm not sure it needs to be in TRIP. The
mapping from +1 603 to a name for that area code is not dynamic, nor
different from provider to provider. One could actually have a global
database, where you look up a phone prefix, and get out a textual name.
Interestingly, enum was just chartered as a working group to look up a
phone number in DNS, and get something out, where that something is
generally a URL. But, it could be a piece of text.

Also, does enum allow us to lookup just a phone prefix, not a complete
number? I would presume so.

(I'm ccing the enum list on this for comment)

-Jonathan R.

Jon Steer wrote:
> 
> Currently, in the IP world, if I want to understand a route in
> a human readable form, traceroute can use DNS to potentially
> gather the names of the routers/domains along the route.
> 
> For the E.164 address space, this isn't the case, without a
> fixed, hand-generated database.
> 
> I believe that there is an opportunity to provide some extended
> "callerid" and management functionality if the originating LS includes
>   human readable text when advertising a route.
> 
>   For example, if the LS advertises the E.164 1603xxxx route, a textual
> attribute
>   containing NewHampshire would enable the front ends of LS servers to gather
>   and display address spaces.
> 
>   jon
> 
> ---------
> This message came from the IETF IPTEL Working Group Mailing List.

-- 
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

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

---

From: Jon Steer <[email-masked]>
Date: Tue, 09 Nov 1999 23:16:47 -0500

jon

---------

---

From: Jon Steer <[email-masked]>
Date: Wed, 10 Nov 1999 07:10:16 -0500

At 11:55 PM 11/9/99 -0500, Jonathan Rosenberg wrote:
>different from provider to provider.

But what is dynamic is an enterprise phone destination
for example when a company buys a large block of 1603884

>One could actually have a global

Those exist already, however, they cannot be dynamically added to
when new blocks of numbers are allocated (i.e. new area codes or
new large enterprise blocks of numbers).

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 10 Nov 1999 10:16:56 -0500

> for example when a company buys a large block of 1603884

Perhaps dynamic is not the right word. I agree something like that needs
to be covered. The difference is that if company foo buys 1603884, this
number is mapped to foo for everyone that asks. TRIP is great at
distributing information with parameters that are different for
different peers. What you want to do can be done using a global (with
updates) directory service, which is exactly what enum is.

> new large enterprise blocks of numbers).

Whilst the enum group won't address how updates take place, certainly
the database itself won't be useful if it can't be updated. DNS can
certainly be updated; the timescales of the updates we need for this
service are doable using administrative updates, as opposed to real time
protocol based updates.

-Jonathan R.

---------

---

From: Jon Steer <[email-masked]>
Date: Wed, 10 Nov 1999 17:10:48 -0500

At 03:26 PM 11/10/99 -0600, Stephen Sprunk wrote:
>The purchase of a block of phone numbers is generally static in that it 
>doesn't change on a real-time basis; generally blocks of numbers will stay 
>with their owners for months to years.

  Hopefully, one of the things that IP telephony brings is the ability to 
define new services one that might
  require dynamic addresses.

>  The actual line assignments can be delegated to the current owner by the 
> telco.

This presumes that all E.164 addresses that TRIP advertises are RBOC telco 
visible and not
a private numbering system perhaps implemented by an ISP.

>  This is the timeframe and hierarchy that DNS (and therefore enum) is 
> perfect for.  Also, TRIP (and BGP) is based on business relationships, 
> administrative policy, and reachability.  This doesn't apply to a 
> E.164<->entity mapping.

I keep sensing that the implied model here is that only large blocks of 
numbers are represented by routes. BGP scales
down to very small subnets (like 4 address subnets), I'm not sure why Trip 
isn't going to .

For example, I pay my ISP to allow me to setup a dynamic route to handle a 
weekly videoconference. I'm paying
my ISP by bandwidth, not by line.  I want the ISP to route my calls to my 
video unit.

When I call outwards from my dynamic video endpoint, it would be nice to 
deliver the human readable
callerid to the other end.

>>----- Original Message -----
>>From: <mailto:[email-masked]>Jon Steer
>>To: <mailto:[email-masked]>Jonathan Rosenberg
>>Cc: 
>><mailto:[email-masked]>[email-masked]. 
>>com ; <mailto:[email-masked]>[email-masked]
>>Sent: Wednesday, November 10, 1999 6:10
>>Subject: Re: Human readable Route descriptors
>>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 11 Nov 1999 14:29:27 -0500

Jon Steer wrote:
> > The purchase of a block of phone numbers is generally static in that
> > it doesn't change on a real-time basis; generally blocks of numbers
> > will stay with their owners for months to years.
> 
>  Hopefully, one of the things that IP telephony brings is the ability
> to define new services one that might
> >  The actual line assignments can be delegated to the current owner
> > by the telco.
> 
> This presumes that all E.164 addresses that TRIP advertises are RBOC
> telco visible and not

My understanding is that the enum mechanism is not restricted to public
e.164 numbers. By using prefixes other than e164.in, one could look up
private numbers as well.

> For example, I pay my ISP to allow me to setup a dynamic route to
> handle a weekly videoconference. I'm paying
> my ISP by bandwidth, not by line.  I want the ISP to route my calls to
> my video unit.
> 
> When I call outwards from my dynamic video endpoint, it would be nice
> to deliver the human readable

The mechanism, even if in TRIP, wouldn't get you caller ID. SIP itself
as a call establishment protocol provides this.

-Jonathan R.

---------

---

From: Dean Willis <[email-masked]>
Date: Thu, 11 Nov 1999 13:12:02 -0600

Jon Steer wrote
------

   The purchase of a block of phone numbers is generally static
   in that it doesn't change on a real-time basis; generally
   blocks of numbers will stay with their owners for months to years.

Hopefully, one of the things that IP telephony brings is the ability to
define new services one that might require dynamic addresses.
--------

Clearly the relatioship between a phone number and an IP Address can be
dynamic.

Part of my initial adverse reaction to ENUM is my belief that the
association of IP addresses to phone numbers is an exceptionally dynamic
relationship, and that this relationship could not be adequately expressed
in a relatively static and cached DNS.

However, ENUM does appear to have the potential to resolve a phone number
into a dynamic registrar instead of an IP address. This resolution could
also be indirected at one or more levels in order to provide number
portability between carriers, I think. Whether ENUM can address the privacy
requirements of LNP is another issue.

For example -- (all names and numbers fictitious) I as a phone user might
rent a phone number from a carrier, perhaps 13045551212 from BPI (Big Phone
Inc). The NANP NS delegates to the 304 area NS, which delegates exchange 555
to the SBC NS. The SBC NS might contain a record pointing .1212 towards
sip:[email-masked];user=phone. As part of my rental fee for the
phone number, SBC allows me to either use sip.sbc.net as a registrar, or to
provision contacts into it using a web interface. In the simplest mode,
assume I use the registration services. When I turn my phone on, it sends a
SIP REGISTER to sip.bpi.net on behalf of 3045551212 listing the phone's
current IP address as a Contact:.

Calls from the GSTN to my phone resolve in the following way: The call
enters the GSTN as a sequence of dialed digits. The carrier switching system
follows the standard PSTN routing to the nearest BPI switch registered as
handling my exchange (30555). BPI hands the call to an IP gateway.  The
gateway does a DNS lookup on 3045551212, which resolves to
[email-masked]. The GW then sends an INVITE to sip.bpi.net and is
proxied or redirected to my phone. Note that nobody ever looked in the TRIP
routes to resolve the call.

In the event that I place a call to the PSTN, 19153627878, things happen in
a very different fashion.

In this sequence, my phone does a DNS lookup on the dialed number. Perhaps
it does not resolve (It's not an IP or LNP registered phone number). My
phone then sends an INVITE to sip.bpi.net with a request-URI of
tel:9153627878, perhaps with some sort of scope specifier. Next sip.bpi.net
consults its TRIP routing table to find one or more egress gateways and
either proxies or redirects my call.

Alternative:
My phone could be configured to always send my calls to my outgoung proxy
sip.bpi.net. In this case, it sends the INVITE tel:9153627878. The proxy
does a DNS lookup, finds that the name does not resolve, consults TRIP, and
proxies or forwards the call.

These scenarios work pretty well. But, I haven't been able to figure out a
scenario for local number portability from within DNS -- theoretcially, one
of the ENUM possibilities. Anybody want to tackle that? I'm concerned that
LNP is more like NAT than it is a 302: redirect . . .

--
Dean

---------

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 12 Nov 1999 09:12:13 -0500

Dean Willis wrote:
> into a dynamic registrar instead of an IP address.

I agree completely that this is a very reasonable way to do it, and not
inconsistent at all with what Scott is saying. 

> proxies or forwards the call.

The original and alternative appear to be the same, but otherwise I
agree. This example is nice in that it illustrates the different uses of
TRIP and enum.

Thanks,
Jonathan R.

---------

---

From: Dean Willis <[email-masked]>
Date: Fri, 12 Nov 1999 09:52:11 -0600

Jonathan Rosenberg wote:
> Dean Willsi wrote:

The difference is whether my phone begins with an attempt to do DNS
resolution on the called party or goes directly to a SIP proxy. Rather like
the sendmail models of direct SMTP delivery to the destination or reliance
on a smarter host.

The change to call flow occurs when the called number DOES resolve in DNS
and the phone sends the INVITE directly to the resolved destination rather
than to the calling party's proxy. It has implications for proxy-mediated
QoS ala DCS, carrier ability to provide pen-register trace functions, and
probably other stuff I haven't thought of yet. There might be some
interesting interaction in that the choice of egress gateway might resolve
differently, perhaps falling into a different carrier's TRIP path. Of course
these are configuration and operations issues, but it's nice to understand
the impact of protocol on operations, no?

--
Dean

---------