Subject: RE: [Enum] draft-lind-enum-callflows-03.txt, RFC2916bis default a ction

From: "Stastny, Richard" <[email-masked]>
Date: Thu, 7 Mar 2002 12:15:55 +0100

Dear Colleagues,

In section 5.3 Call from a Terminal on an IP-based Network to a phone on the
PSTN 
of draft-lind-enum-callflows-03.txt, Steve explains:
   <snip>
   In the example, the SIP Client transforms the dialed number into a 
   FQDN of 4.3.2.1.5.5.5.1.0.3.1.e164.arpa. During the 
   transformation, the country and area codes for the destination are 
   added to the number by the client. 
    
   Step 3 - The DNS returns any NAPTR service records associated with 
   the FQDN.  
    
   In the example, the DNS returns at least one record containing the 
   URI tel:+13015551234. 
    
   If no ENUM record exists for the URL, the call should be attempted 
   for termination on the PSTN using the dialed digits as the target 
   for further steps in the call flow.
   <snip>

Considering the discussion with Patrik on the examples in RFC2916bis, that a
NAPTR with the same number in the tel: URI does not make much sense, and
also, that in Steve example exactly the same action takes place, if DNS
returns the URI tel:+13015551234 or if no records exist. I suggest to
include something like following statement somewhere in RFC2916:

Default Action of the client:

If the ENUM query for a given AUS does not return a result (404), the action
taken by the client SHALL be the same as if the result would have been:
     IN NAPTR 10 10 "u" "E2U+tel"     "!^(.*$)$!tel:\1!"     .

This would solve the opt-in problem of the calling user as mentioned in the
previous discussions, and also the problem of Patrik to find a place where
to use the \1 replacement example ;-)

For Steves example, I would suggest to use either another example, or to use
e.g. the following wording:

   Step 3 - The DNS returns either any NAPTR service records associated with

   the FQDN, which are evaluted according to RFC2915 and RCF2916.  E.g a
sip, 
   h323 or tel URI.
    
   If no ENUM record exists for the URI, as in this example,
   the call should be attempted 
   for termination on the PSTN using the dialed digits as the target 
   for further steps in the call flow, as if the URI tel:+13015551234 
   has been returned.

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

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

---

From: Lawrence Conroy <[email-masked]>
Date: Thu, 7 Mar 2002 12:57:24 +0000

<snip>

<snip>

To which I reply:
   Hi Richard, folks,

I'm still not completely sure about whether one SHOULD NOT have a tel: URI
that evaluates to the same E.164 number as the domain, or one SHOULD (so
that this "tight loop" can indicate that this is the end of a tel: redirect
process).
It's certainly one of the open issues with the 'tel' ENUMservice that we
intended to raise at MSP.
It also ties in with Richard's earlier comment on the use of tel: URI
parameters, and the possible evaluation of the contents from a local number,
qualified with a phone-context, through to a "full" E.164 number
(Which is another open issue with use of tel: URIs, also to be raised in MSP).

Speaking of tel: URI parameters, is the intention to cover the CPC draft in
ENUM or in SIP//SIPPING or both or...?

Best Regards,
    Lawrence
-- 
[email-masked]: +44 1794 833666::<my opinions>:

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 07 Mar 2002 21:06:44 +0100

--On 2002-03-07 12.15 +0100 "Stastny, Richard" <[email-masked]>
wrote:

> I suggest to
> If the ENUM query for a given AUS does not return a result (404), the
> action taken by the client SHALL be the same as if the result would have
> been:      IN NAPTR 10 10 "u" "E2U+tel"     "!^(.*$)$!tel:\1!"     .

The problem with this is that 2916bis then guess what the definition is of
the enumservice indicator "tel", which it doesn't.

I.e. I think it is the "tel" specification which should specify what it
means to get the same number in a tel URI as the input to the NAPTR
algorithm.

Now, the $10.000 question is of course what a client which queries the DNS
should do if it gets back a NXDOMAIN. Maybe that is _also_ something which
should be specified per enumservice specification?

  paf