Subject: [Enum] RE: ENUM Part of Call Setup (Was: Implementer's dilemma)

From: "Stastny, Richard" <[email-masked]>
Date: Thu, 21 Feb 2002 09:45:39 +0100

Christian wrote:
> My personal conclusion is that ENUM look-up SHOULD NOT be 
> performed "in
> real-time" during call set-up, since there is ambiguity about the
> <snip>

I fully agree, but this is an issue, where a lot of different opinions are
around.

IMHO it should by stated clearly in RFC2916whatever, that (at least
public;-) ENUM is NOT PART of the call setup, that it happens before call
setup.
This is VERY important in legal context and also related to the technical
requirements. Regarding the legal context, if ENUM is NOT PART of the call
setup, it is not part of eventually regulated voice calls, there is no
requiremnt of LI, etc. Technically it is not part of the telephony
infrastructure and therefore ITU-T E.105 is not relevant.

This also makes sense, because AFTER the ENUM lookup the user may still
decide to send an e-mail or do not user the result of the query at all.

Of course I am aware, that some operators (especially mobile operators) are
considering to use ENUM-like services within their networks DURING call
setup, with the end user(s) on both ends not even aware of the fact, that
ENUM-like services are used. But this is not (public) ENUM and up to the
operator.

regards

Richard STASTNY
OeFEG
Arsenal Objekt 24
P.O. Box 147
A-1103 Vienna, Austria

Tel: +43 664 420 4100
Fax: +43 1 79780 13
[email-masked]
[email-masked]

> -----Original Message-----
> From: Christian Huitema [mailto:[email-masked]]
> Sent: Wednesday, February 20, 2002 5:36 PM
> To: Stastny, Richard; Clive D.W. Feather; Lawrence Conroy
> Cc: [email-masked]
> Subject: Implementer's dilemma (was RE: [Enum] DDDS, DNS clarification
> needed?)
> 
> 
> > I don not fully understand this discussion. Considering the Zillions
> of
> > parameters already existing in operation systems and applications, I
> do
> > not
> > see the problem in including the ENUM Root Domain in the 
> Application.
> Or
> > the
> > other way round, if I had to write an ENUM Add-on to Outlook,
> Netmeeting
> > or
> > Messenger, the first thing I would implement is a parameter for the
> ENUM
> > Root Domain (also considering that the discussion is still 
> not settled
> > discussion between IAB and ITU), and second I would implement
> additional
> > optional parameters for other root domains: e.g. if an number is
> entered
> > with +, I would go to ENUM Root, with 000 also, any number without 0
> or +
> > to
> > a private root, etc.
> 
> Alternately, whoever has to write such an interface to ENUM might just
> wait a little for the dust to settle? I believe that there are two
> issues to resolve before implementers feel comfortable with ENUM:
> 
> 1) There is a usability issue to determine when a telephone number has
> to be resolved as an identifier (i.e. through ENUM) versus as 
> a routing
> index (i.e. through the routing protocol proposed by the INTEL group):
> ring that device versus ring the owner of the device.
> 
> 2) There is a cost benefit issue to determine whether paying 
> the cost of
> an ENUM look-up (potentially a second or two) is worth the benefit
> (finding useful information).
> 
> My personal conclusion is that ENUM look-up SHOULD NOT be 
> performed "in
> real-time" during call set-up, since there is ambiguity about the
> meaning of entering a phone number in a call procedure and there is a
> large probability, at least in the initial phase, that the 
> ENUM database
> will not hold any information for a specific number; real-time call
> redirection, if needed, can always be performed by the target of the
> call, or by the last switch. If I was to implement any 
> support for ENUM,
> it would be in an "off-line" procedure e.g. an add-on to the 
> management
> of the local address book. Now, if you think "off-line", it 
> is very easy
> to look in multiple databases and let the user choose.
> 
> -- Christian Huitema
> 

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

---

From: Chip Sharp <[email-masked]>
Date: Thu, 21 Feb 2002 08:54:51 -0500

Stating that the protocols & algorithms defined in RFC2916 should not be part of call setup  could be part of an applicability statement for RFC2916 (or its successor), but there is no reason to put such a restrictive statement in the protocol definition itself. 

RFC 2916 defines protocols & algorithms, not a service (especially in the ITU sense of the word).  RFC2916 does not define (and ENUM isn't) a telecommunications service.
Using RFC2916 procedures during call setup is a decision for a person or organization to make when setting up their network (or service).

Of course, anyone thinking of using RFC2916 during call setup (as understood by traditional telephony) should analyze the implications (some of which were mentioned by Christian) to determine if it will meet requirements. This analysis could be included in an applicability statement. 

Chip

---

From: Michael Mealling <[email-masked]>
Date: Thu, 21 Feb 2002 09:12:17 -0500

On Thu, Feb 21, 2002 at 08:54:51AM -0500, Chip Sharp wrote:
> Stating that the protocols & algorithms defined in RFC2916 should not 
> be part of call setup  could be part of an applicability statement for 
> RFC2916 (or its successor), but there is no reason to put such a 
> restrictive statement in the protocol definition itself. 
> 
> RFC 2916 defines protocols & algorithms, not a service (especially in 
> the ITU sense of the word).  RFC2916 does not define (and ENUM isn't) a 
> telecommunications service.
> Using RFC2916 procedures during call setup is a decision for a person 
> or organization to make when setting up their network (or service).
> 
> Of course, anyone thinking of using RFC2916 during call setup (as 
> understood by traditional telephony) should analyze the implications 
> (some of which were mentioned by Christian) to determine if it will 
> meet requirements. This analysis could be included in an applicability 
> statement. 

I hate to do the 'me too' thing but I was in the process of saying just
about the same thing when this came by, thus saving me the time. But I 
do want to make sure the viewpoint is supported. ENUM (rfc2916bis) is
a very simple definition that you then take and do profiles of within
your application. IMHO, ENUM should never even mention the words 'call
setup', 'telephone call', etc anywhere in the document (except possibly 
in the Examples).

The same goes for SIP....

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | urn:pin:1
[email-masked]      |                              | http://www.neonym.net

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Thu, 21 Feb 2002 09:24:29 -0500

My head hurts.

> infrastructure and therefore ITU-T E.105 is not relevant.

Somewhere there is an instance of bind, responding to queries. The data the
instance of bind uses has a temporal property (TTL value). While valid, two
temporally distinct identical queries yeild identical responses. During the
intervening temporal period the network fabric between the resolver and the
mapped address could have partitioned.

Resolution may be successfully accomplished, even if there is no route to
host.

One of the aspects of one of the "keyword" or "alternate root" offerings
made elsewhere (not on this list) that interested me was the similarity
between interposition (on the dns) and legal intercept.

In the vendor case I became familiar with, a UA formed a string (with infix
dots), heuristics concerning the string (terminating dot-bounded substring
value) caused the UA to (eventually) serially query responders located at
the vendor-partners facilities in three North American sites, not the M root
server, which is more proximal.

The "intercept" occurred at the UA/resolver interface, in the form of query
modification with redirection, rather than query replication with redirection. 
The interested can read rfc2804 for the technical critique of interposition
and related complexity and access model issues. It also occurred at the set
of query responders

I fail to see how resolution (ENUM) is part of transport (call setup).

I fail to see how legal intercept (query replication and/or redirection)
can be implemented outside of the resolver or nameserver, if the lookup
function (dns queries) are within the scope for intercept.

Did someone actually make the case that ENUM is "call setup"? I'd appreciate
a pointer to the item in the archive. Did someone discuss how they plan to
implement LI in ENUM? Ditto.

Eric