Subject: RE: [IPTEL] RFC 2806bis: phone-context, and other issues

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 31 Dec 2001 05:39:09 -0600

A couple of notes on this inline below.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Henning G. Schulzrinne [mailto:[email-masked]]
> Sent: Saturday, December 22, 2001 2:02 PM
> To: [email-masked]
> Subject: [IPTEL] RFC 2806bis: phone-context, and other issues
> 
> 
> (I vaguely recall that we agreed in London that discussion should take
> place on the iptel list. My apologies if my memory is faulty.)
> 
> I'm finally fulfilling my promise to edit RFC 2806bis ('tel' 
> URL). Since
> this presumably is to go eventually to Draft, I'd like to know how
> widely some of the more esoteric features are implemented. Feedback is
> most welcome.
> 
> - RFC 2806 allows several 'area-specifier's, as in
> 
>   tel:7042;phone-context=+1-212-70;phone-context=+1-212-71
> 
>   Is this an "OR" match?
> 
>   Do clients *have* to support this?

I've never really understood phone-context. FWIW, I think it's an OR match,
yes. 6.1.5 says that if multiple phone-contexts are present, the number is
valid in all of the contexts named.

Only when a private dialing plan or special national number (like '911')
outside the scope of E.164 is in use should a tel URL not be in E.164
format. In these cases, unfortunately, the value of an explicit 'context' in
signaling isn't really clear. In an enterprise, for example, where '85062'
is a valid number for a station, a 'context' parameter really isn't needed -
the '8' is already a context. I'm not sure why 'tel:85062' wouldn't be a
better way of representing this number than 'tel:5062;phone-context=8'.
After all, this context will never be meaningful outside the enterprise
anyway.

While some people out there may be implementing phone-context, I wouldn't
have high hopes for interoperable versions of it.

> 
> - RFC 2806 allows several service providers, identified by a domain
> name. Since there is no current data base that maps domain 
> name to, say,
> 1010xxxx prefixes (US example), it is not clear how implementable this
> is. It is also not clear what the client should do if it doesn't
> recognize any of them. Try anyway, using some other carrier? 
> Not try? Is
> a URL the right mechanism for conveying this information?

Even if there were a database that mapped TSP domains onto Carrier
Identification Codes (the XXXX part of 101+XXXX) or vice versa, by itself
that might not be all that useful for routing calls. Routing on both the CIC
and the TSP have their place. Translating between TSPs and CICs would almost
always require some policy decisions; many ITADs with domain names will not
even have any associated CICs.

I think the right way to think about the TSP is as a destination domain. If
the tel URL is used as the userinfo portion of a SIP URI, it should never
have the TSP parameter - that should be the host portion of the SIP URI.
When converting a tel URL into a SIP URI, the 'tsp' parameter should map
directly on to the host portion of the SIP URI. A CIC parameter (and one has
been proposed as an extension to the tel URL) on the other hand is relevant
primarily to SIP-PSTN interworking (find a gateway where you can reach that
CIC). Mapping between these two parameters, or determining which should be
used in a given instance, is probably a policy decision.

> 
> - RFC 2806 allows private dial-plan identifiers (e.g., X-COMPANY-NET),
> with a registration scheme left for future definition. That's 
> a bit too
> vague for my taste. I propose ditching this or, say, making 
> it a domain
> name.

My vote would be to ditch it. Juggling multiple private dial-plans in the
PSTN is a huge, proprietary hassle, and I don't think providing a standard
way to do it would actually grant anyone leverage on any problem I can
imagine. I suspect that the only use of a dial-plan identifier is to provide
further 'context' in which a telephone number can be understood so that some
other entity, elsewhere in the network, can combine the partial number with
the context to get a complete, E.164-ish number. Again, wouldn't be clear to
me why, if the entity creating the tel URL knows its context, it wouldn't
use the context to create a global number to start with - or why any entity
receiving the URL would get any advantage from being able to process the
dialing plan itself.

I'm a little surprised to hear it's being used.

> 
> All of these seem like features that should be added later, as
> extensions, once we understand how they can be useful. Unless we have
> two interoperable implementations, they'll have to be dropped in any
> event. Thus, please let me know if you either have 
> implemented these or
> plan to implement these.
> 
> Also, this would be a good opportunity to remind me of any 
> other issues
> or extensions that should go into the 2806bis draft.
> 
> Thanks.
> 
> Henning
> -- 
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
> _______________________________________________
> IPTEL mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/iptel
> 
_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel