Subject: [Iptel] tel URI and ENUM

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 19 Mar 2003 14:06:54 -0500

To pick up the discussion that was started in the iptel meeting:

One model of the tel URI is that it is a name identifying an (abstract) 
resource via a telephone number. Other entities are needed to direct a 
request containing the URI (in the SIP case) or to generate an action 
(in the HTML case) causing a connection. This is no different from, say, 
an ISBN URN that invokes a translation service. The subtle difference is 
that a tel URI can both directly reach a specific resource as well as do 
this via translation and that multiple translation steps can be 
involved, but that property is inherent in the phone number (via things 
like 800# translation, number portability and ENUM) and not specific to 
a tel URI.

Like all telephone numbers in protocols, I believe that tel URI numbers 
can be subject to ENUM translation. It shouldn't matter if a tel URI was 
itself the result of an ENUM lookup. Thus, you could have

[SIP UA] tel URI
[outbound proxy]  ENUM: tel1 -> tel2 (number portability)
[some other proxy] ENUM: tel2 -> sip URI

I don't see the need for parameters in this case. (In other words, 
parameters might be *useful*, but they shouldn't be *necessary*.)

Thus, 'translation hints' in the tel URI comply with the model. It might 
be interesting to divide the tel URI extensions into categories. There 
seem to be at least four:

(TH) translation history hints ("translation X has been performed");

(TD) translation directive ("translation X should/should not be performed");

(NP) number property: "the number in the tel URI is a 'foo'" (and it 
will be a 'foo' for a long time).

(CP) call property: the call with this tel URI has the following properties

I have to admit that I find (CP) least convincing as a tel URI 
extension. Names and URN-like things like tel URIs should be long-term 
stable.

(NP) is really a URC-like thing, although that concept seems to have 
seen no instantiation in actual usage. The Contact parameters in 
caller-preferences are an example of binding NP-like properties to a SIP 
URI. One could argue that (NP) should be retrieved by reference, to 
avoid sprinkling it all over the place (like web pages and address 
books) where the parameters are hard to change when they do change. 
Thus, including things like carrier codes seems potentially dangerous. 
What happens if the tel URI with a carrier code in a web page gets a 
different carrier?

Henning

_______________________________________________
Iptel mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/iptel

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 20 Mar 2003 23:26:53 -0500

> like 800# translation, number portability and ENUM) and not specific to

Another thing to consider is, that tel-URIs may be present in other places that
just the Request-URI, for example "To", "From", "P-Asserted-Identity". I believe
these considerations is what motivated some of the calling party category
suggestions and one could see other tel-URI parameters showing up in some of
these header fields.

> parameters might be *useful*, but they shouldn't be *necessary*.)

I think the issues here are the same as for number portability; if you already
know that a tel-URI is in its canonical form and hence attempts at resolving it
further will be futile, it would be a good idea to indicate this (i.e. we would
need a new indicator). In many ways, the "npdi" indicator is really just a
special case of this, however it is probably still reasonable to have a separate
indicator for number portability and "fully resolved". Also note, that if the
URI can change after an npdi dip has been performed (say because we use enum to
translate it into yet another number), the "npdi" indicator may no longer be
correct.

> (TH) translation history hints ("translation X has been performed");

Agree (note that when a translation of type X has been performed, hints for
translations of all other types may have to be cleared).

> (TD) translation directive ("translation X should/should not be performed");

I'm not sure I see where we would need TD; doesn't each hop simply perform
whatever translations it deems necessary, and as long as we have TH, we can
avoid performing unnecessary translation attempts ?

> extension.

Agreed - it seems reasonable that things that are related to the call in general
as opposed to the tel-URI specifically, should rather be present in headers (or
media descriptions, depending on what type of properties we are looking at). I'm
not sure we have everything covered though:

1. Which category does the "cic" parameter in yu-tel-url belong to ?

2. What if I wanted to add the equivalent of carrier selection, i.e. an
indicator to show whether a "cic" parameter was provided because the user
actively requested it or because it was simply the pre-subscribed carrier for
this call ?

> Names and URN-like things like tel URIs should be long-term
> stable.

I think that depends on where they are used. In the context of say a reference
on a web-page I agree, but it's less clear once we start putting them in various
fields in call signaling.

-- Flemming