Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM

From: James Yu <[email-masked]>
Date: Fri, 18 Feb 2000 17:11:24 -0600

I agree with Greg that 411, 911, 611 or *XX, #XX like numbers are non-E.164
numbers.  Those numbers currently are handled by the GSTN switches (local
matters if we exclude the mobile roaming scenario).  If IP based networks
are to support those service codes or abbreviated dialing codes, the network
entity that receives the requests (e.g., the SIP server or GK) must know how
to handle those codes if they are "local matters."  In Internet, it may be a
problem if there are no standardized procedures in handling those codes.  If
the end users can switch the service providers or servers freely and each
SP/server may handle the codes differently, there will be end user
confusion.  The end users may perceive different treatment/handling or are
required to dial different codes when accessing different SPs/servers.  But
those are not enum issues.  The enum issue may be whether DNS is needed to
resolve those codes.

If handling of those codes are "local matters," the client that is to
resolve the code may need to append a domain name belonging to the service
provider.  If it is a service provider's network entity that is to resolve
the code, it probably can resolve it without using the DNS or it can append
its domain name if DNS is used.  In this case, no suffix is required.

Unless those codes are standardized and "shared" NSs are used to resolve
them, then a suffix different from e164.foo and those for private numbering
plans as suggested by Johnathan can be used if DNS is used.  DNS can be used
to point to the "shared" NSs that has the information about the codes.  The
problem is what if the information is location dependent (e.g., 911 call is
to be handled by a PSAP that has the jurisdiction for the caller's/client's
geo. location)?   The network (e.g., the SIP server) or client may have
pre-provisioned client location/address.  The issue is that the
caller/client may call from anywhere other than the default
location/address.  In that case, neither the network entity nor the client
itself has any clue about the client's current location/address.  Again,
this is not an enum issue but an issue for the IP telephony.

James
> -----Original Message-----
> From: Vaudreuil, Greg M (Greg) [mailto:[email-masked]]
> Sent: Friday, February 18, 2000 4:23 PM
> To: Manfredi, Albert E; 'Jonathan Rosenberg'
> Cc: IETF Enum
> Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM
> 
> 
> 
> As other emails discussed, the 411, 911, 611, *9, and other 
> north-american
> short-code information services provided by local telco's are 
> not part of
> the E.164 or local _numbering plan_.  They are part of the 
> local _dialing_
> plan.  One important characteristic of each of these services 
> is that the
> end-point varies by the "location" of the dialer.  It is the 
> client (or
> client's agent in the case of a POTS phone connected to a 
> telco switch) that
> maps from a dialing plan to a numbering plan.  If you dial 911, you
> certianly want a geographically local emergency response department! 
> 
> These dialing plans have a use in Internet space, but they need to be
> provided by a service better equipped than ENUM to do 
> geographical location.
> This can be performed by the client (enter an e164 alias for 
> 911), or a
> query to the geographically (emergency response) / politically (city
> services) / contractually (phone repair) "local" remapping 
> service for the
> current clients definition of "local".
> 
> Greg V.
> 
> -----Original Message-----
> From: Manfredi, Albert E [mailto:[email-masked]]
> Sent: Friday, February 18, 2000 2:35 PM
> To: 'Jonathan Rosenberg'
> Cc: IETF Enum
> Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM
> 
> 
> Jonathan Rosenberg wrote:
> 
> > My point was that our system works for both the global and private
> > space. For the global case, the application will know to 
> > append e164.int
> > or whatever, and for applications that are using private plans, some
> > other suffix is supplied by the application. As far as the enum
> > component goes, it gets a domain suffix and a phone number. How the
> > application decides what that suffix is, whether its e164.int 
> > or not, is
> > irrelevant for the enum component. It takes that suffix and 
> > the number,
> > constructs a domain name as per the document, and then goes 
> to DNS and
> > gets back URIs for the services available.
> 
> But what's more, it is possible that some of these local 
> numbering plan
> queries will never be translated over to a query for the 
> e164.int domain at
> all. For example, why not permit 911 calls from an Internet 
> applicance, as
> long as you're in the US?
> 
> I guess that if this scheme works for more than just e.164, 
> more power to
> enum.
> 
> Bert
> [email-masked]
> 
> _______________________________________________
> enum mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/enum
> 
> _______________________________________________
> enum mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/enum
> 

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

---

From: Dean Willis <[email-masked]>
Date: Fri, 18 Feb 2000 17:35:35 -0600

For E.164 numbers, I see ENUM as providing a means to find a SIP server or
gatekeeper that knows how to resolve the given e.164 number. We know pretty
much how this works.

DNS solves local problems as awell as global ones. We do this with a
split-DNS model, or with shadow servers, or local subdomains, or other
techniques.

The question is, how does ENUM help you find a SIP server or gatekeeper that
knows how to resolve the funky local numbers? I suspect that we know how
this works, too -- one simply makes an ENUM query in an appropriate local
domain. How? By using the same techniques that apply for local DNS. And
that's not an ENUM problem, as long as ENUM provides a way for the
number-to-server-within-a-domain-context problem to be resolved. The current
proposal seems to handle this nicely.

I suggest we cease trying to make the problem harder than it is, and simply
accept the obvious conclusion that the ENUM representation can be used in
ANY name context with some utility.

--
Dean

> From: [email-masked] [mailto:[email-masked]]On Behalf Of James
> Yu
> Sent: Friday, February 18, 2000 5:11 PM
> To: 'Vaudreuil, Greg M (Greg)'
> Cc: IETF Enum; Manfredi, Albert E; 'Jonathan Rosenberg'

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 21 Feb 2000 09:49:03 -0500

> this is not an enum issue but an issue for the IP telephony.

911 in a pure IP context is a mega-hard problem (I believe its probably
material for at least two solid PhD dissertations). It encapsulates QoS
issues, naming and resolution issues, anycast issues, caller
identification issues, etc. We are not going to solve them here.
However, when we do figure the whole thing out, the way enum fits is
easy - you resolve 911 in DNS with enum, and it gives you back some
server that you contact that will actually perform the hard
geographical-locale based location. For example, this may be a sip
server. When it receives an INVITE, it takes the source IP address,
looks for an LOC (aka ICBM) RR (see rfc1876) in DNS, and get get the
geographic locale of the caller (assuming we have figured out how to
update the DNS with this information). 

I do not want to try and add location dependent resolution or anything
like that into enum.

-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