Re: [Iptel] comments on draft-ietf-iptel-tel-enumdi-00.txt

"Stastny Richard" <Richard.Stastny@oefeg.at> Mon, 07 March 2005 02:08 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23700 for <iptel-web-archive@ietf.org>; Sun, 6 Mar 2005 21:08:44 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D87hw-0004V6-5j for iptel-web-archive@ietf.org; Sun, 06 Mar 2005 21:10:56 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D87eu-0001Kz-TB; Sun, 06 Mar 2005 21:07:48 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D87eu-0001Ku-1D for iptel@megatron.ietf.org; Sun, 06 Mar 2005 21:07:48 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23648 for <iptel@ietf.org>; Sun, 6 Mar 2005 21:07:43 -0500 (EST)
Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D87gx-0004U0-1g for iptel@ietf.org; Sun, 06 Mar 2005 21:09:55 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Iptel] comments on draft-ietf-iptel-tel-enumdi-00.txt
Date: Mon, 07 Mar 2005 03:10:03 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D46FBDF@oefeg-s04.oefeg.loc>
Thread-Topic: [Iptel] comments on draft-ietf-iptel-tel-enumdi-00.txt
Thread-Index: AcUisgkcVEipbbjQQRmQOP70POX4TAABGQM3
From: Stastny Richard <Richard.Stastny@oefeg.at>
To: jh@tutpro.com, iptel@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2
Content-Transfer-Encoding: quoted-printable
X-BeenThere: iptel@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Telephony <iptel.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/iptel>, <mailto:iptel-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/iptel>
List-Post: <mailto:iptel@ietf.org>
List-Help: <mailto:iptel-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/iptel>, <mailto:iptel-request@ietf.org?subject=subscribe>
Sender: iptel-bounces@ietf.org
Errors-To: iptel-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1
Content-Transfer-Encoding: quoted-printable

Juha,

>1) is it now a common/allowed practise that an enum query can result a tel
>uri containing another e.164 number so that enum query on that can result
>a third e.164 number, etc? 
 
Who is the authority allowing an end-user what he is entering in his domain?
 
>i thought that at some point it was
>recommended that enum query on an e.164 number should return the final
>result.

If a tel: URI is allowed in in ENUM, it may point to a different number,
since this number may also be in ENUM, an ENUM query makes sense.
I agree with you that this may result in an endless loop. There is
two ways to break this. See below.

>2) if so, how can the draft help in preventing loops a -> b -> a?  i
>didn't see any mentioning about that, because according to the draft,
>enumdi indicator is only added if enum query doesn't produce any result or
>produces the same e.164 as result.

>3) should there also be an indicator telling that an enum query was made
>that resulted in this tel uri, which would allow a proxy, for example, to
>implement a non-looping policy?

This is exactly what enumdi does if provided with a tel URI in ENUM,
see my second answer:

My first answer is of course politically incorrect at this list,
because it is using language considered offensive ;-)
One way to break the loop is not documented in IETF because this
is client behaviour, it is instead documented in ETSI TS 102 172
"Minimum Requirements for Interoperability of ENUM Implementations"
http://enum.nic.at/documents/ETSI/Drafts/05TD142r3%20DTS_102172v020006.pdf

It says basically that a client should do only 5 such quireies, e.g in Section 10.3.1

Full citation:

A gateway from the PSTN to the Internet may be ENUM enabled to route 
calls to destinations potentially "published" in ENUM. This gateway MAY 
support only a limited range of ENUMservices, which can be accessed by the PSTN..  

After processing the information retrieved from ENUM according to 
section 10.1., the ENUM enabled application client looks for the specific 
ENUMservices it supports. This MAY be e.g. "sip", "h323", "voice:sip", 
"voice:h323", "voice:tel", "ifax:mailto", ... 

If a "voice:tel" is chosen, and the E.164 contained in the "tel" URI is 
different from the number originally queried, the ENUM enabled application 
client SHALL launch another ENUM query for the number given (as if it had 
received a NAPTR containing the 'enum' Enumservice, as described in 
section 9.4.1.7). To prevent endless loops, the client SHALL make only a 
maximum of 5 such redirections. In the subsequent queries only "voice", 
"sip" or "h323" ENUMservices SHALL be considered. 

If any of these queries returns any "voice" ENUMservice except "voice:tel", 
this ENUMservice SHALL be used. 

If any of these queries returns a "voice:tel" with the same number as queried 
or an NXDOMAIN, the call SHOULD be processed further by querying infrastructure 
ENUM, another database or by routing the call directly to the PSTN, if the gateway 
is providing this. If the gateway is not providing this functionality, "no such service" 
SHALL be indicated. 

If the call is passed on to another network element, the "enumdi" parameter SHALL be set. 

End of citation.

The second way to prevent an end-less loop is descibed in the draft itself
in Section 4.2 in the second bullet point:

Citation

When a VoIP network element accesses ENUM in e164.arpa for a given
   E.164 number and either:
   o  the result of the query includes a NAPTR RR containing a "tel" URI
      that has the same E.164 number, or
   o  the result of the query includes a NAPTR RR containing a "tel" URI
      with the "enumdi" parameter set,

   then if that retrieved "tel" URI is chosen to be passed to the next
   network element, the sending VoIP network element MUST pass on the
   retrieved URI with the "enumdi" parameter set.

End of citation

I hope this answers your questions

-richard

>-- juha




_______________________________________________
Iptel mailing list
Iptel@ietf.org
https://www1.ietf.org/mailman/listinfo/iptel



_______________________________________________
Iptel mailing list
Iptel@ietf.org
https://www1.ietf.org/mailman/listinfo/iptel