Subject: [Enum] "tel:" URIs and phone-context parameter

From: Lawrence Conroy <[email-masked]>
Date: Fri, 1 Mar 2002 15:20:22 +0000

Hi Richard, Folks,

Richard raises some interesting points on tel: URIs.
I get the feeling that we need to add something on how these can be used.

First, a bit of history - some thinking on this was initially done
in PINT (and Annti combined this with the rest of the work he had been
doing on the tel: URI).

The theory is that not all numbers are dialable from everywhere, or
rather you can dial them but you may well not connect to the same end
point. Thus the phone-context parameter was introduced to indicate the
service area in which this telephone number was valid.

With PINT and the tel: work, we were focusing on the dialed number.
(With PINT, both parties are called numbers as it describes a
callback or International Arbitrage service).

We assumed that the caller (or gateway) would know what *their* phone
context was, and could match this against the service area indicated by
the tel: URI they were using as the destination. If they match, then the
number is valid; if they don't, then it isn't dialable from the caller's
or gateway's location.

The problem of originating a call within a particular region is not the
caller's but the gateway service provider's. If the destination is
specified using a tel: URI with a phone-context, then either the
provider can fulfill the request as specified, or it can't. As customers
don't like wrong numbers, I guess that the service provider will have to
be careful about choosing to originate the PSTN segment of the call
outside the requested context.

Thus <tel:1-800-555-1234;phone-context=+1> works if originated within
the NANP region. So does <tel:+1-800-555-1234;phone-context=+1>.

Also, <tel:180-0555-1234;phone-context=+43> works if originated in
Austria, as does <tel:+4318005551234;phone-context=+43>

(Of course, these two probably don't terminate at the same end point :)

One neat use is for network-specific service numbers; thus Scott
Petrack's example from PINT is <tel:123;phone-context=+97252>.
"It so happens that +97252 defines one of the Israeli cell phone
providers, and 123 reaches customer service when dialed within that
network".

Now, to your examples::
I think that you have 3 contexts.

*    The caller's allocated number context

*    The presented number context (e.g. the area code to be added to the
local number in order to construct a full E.164 number, akin to the
implied context with an Q.763 CalledPartyAddress with NAI of 1 or 3)

*    The PSTN call origination point context (i.e. the service area in
which the called number is specified as being valid, and so where the
PSTN  segment of the call should be originated)

As you point out, if the called party is specified using a local number
format, then it *may* be possible to convert this into a full E.164
number. The problem I have with this is that it is not always possible
to tell; for example, +97252123 will almost certainly not work as
expected, but it is possible to convert to <tel:+441794833666> from
<tel:833666;phone-context=+441794>.

BTW, we included the Q763 parameters as described in section 3.4.3.3 of
RFC2848 for this kind of case. I'm still a little uncomfortable with how
these can be used; I suspect that any Operator will simply throw them
away when received from an end user (this goes for the Calling Party
Category as well). Maybe they are still useful, as not everything
is received from the (public) ENUM  - (perhaps from telekom.inside :)?

Perhaps we could add a section to the next version of the 'tel'
specification, on how tel: URIs can be used. This should describe
resolution based not only on the ENUM system, but also on call
origination validity (i.e. whether or not the origination point of the
PSTN segment of a call is within a specified phone-context).

I'm still not completely comfortable about including tel: URIs in the
(public) ENUM that have limited validity (i.e. where a requestor may
have returned a number that is, for them, invalid).

One reason is exactly the one you specify; it can be hard for a caller
to negotiate the PSTN origination point with their Gateway Service
Provider (the counter-argument is, of course, that the service provider
should expect their vendors to read and implement the RFCs :-). As an
alternative, you could always use PINT - see section 3.4.3.1 of RFC2848.

However, given that discomfiture, we can put the text into the next
version (or another document), with the caveat that using this form
needs thought.
For our U.S. readers, that means that you SHOULD put in an entry with
the full E.164 number as well as one with the context-specific version -
NOT just the 1-800 number!

As usual, any comments gratefully received.

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

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

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 1 Mar 2002 15:57:50 +0000

> service area in which this telephone number was valid.

Question: is this a practical problem for E.164 numbers ?

> If the destination is

But +1-800-555-1234 works perfectly well from the +44 region. At least with
some telcos.

> Austria, as does <tel:+4318005551234;phone-context=+43>

Since both of these numbers lie within E.164 space, only the second form
ought to be used.

[Question: does the first form include national numbering plan digits ? In
other words, do I write <tel:020-8371-1138;phone-context=+44> or
<tel:20-8371-1138;phone-context=+44> for +44-20-8371-1138 ?]

I see three separate situations:

[1] An E.164 number can only be reached from certain areas. This might be
because some originating telcos won't route it (+44 8XX was a notorious
example because many telcos tried to route it as +44 18XX) or because the
recipient is rejecting "out-of-area" calls.  I don't see "phone-context"
as being the right way to say this; it's no different from any other
situation where a call might fail, and the person writing the URI might not
understand the rules (see the +1-800 example above).

Also, how do I write "not" in a phone-context ? Consider the Demon "Purple
ROMP", which is:

    <tel:+44-845-212-1666>
    <tel:+44-1883-121666;phone-context=not+44>

[2] An E.164 number reaches different destinations depending on how the call
is routed to the number (this applied to my own home number for most of the
last two months, due to a number porting cock-up). If deliberate (e.g. to
give multiple call centres a common number but have calls routed to the
nearest one), should this fact be published in a tel: URI ?

With this case, how do I write URIs for the call centres ? I want something
like:

    Centre 1 <tel:+44-456-789012;phone-context=+4420or+441923or+441707>
    Centre 2 <tel:+44-456-789012;phone-context=+4424or+44121or+1or+33>
    Centre 3 <tel:+44-456-789012;phone-context=none-of-the-above>

except that I will have perhaps 100 or 200 possible contexts per number.

> providers, and 123 reaches customer service when dialed within that

However, number portability rather breaks this: my mobile is in the
numbering block +447973, allocated to one mobile provider, but it has been
ported to a second one. 123 worked on the first provider but doesn't work
on the second, though 121 now does the same job.

> *    The caller's allocated number context

Not sure what you mean by that one.

> implied context with an Q.763 CalledPartyAddress with NAI of 1 or 3)

If the number is in E.164, then there's little or no point in this. If it

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:  +44 20 8371 1138
Internet Expert     | Home:  <[email-masked]>  | Fax:  +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            | NOTE: fax number change

---

From: Lawrence Conroy <[email-masked]>
Date: Fri, 1 Mar 2002 18:41:47 +0000

Hi Clive, folks,
    I'm still being lazy, so in-line comments I'm afraid::

>Question: is this a practical problem for E.164 numbers ?

Lwc sez:
Depends on quite what you mean ; strictly (for E.164 numbers), no.
In practice, yes (i.e. when using a similar presentation syntax).

>But +1-800-555-1234 works perfectly well from the +44 region. At least with

LwC jests:
No it doesn't - (it has a triple 5 in it :). But seriously, folks, 
here's the rub...
it MAY work from the U.K. - this syntax states that it DOES work from 
within the
NANP region. You SHOULDN'T use this out of area, as it isn't guaranteed to work
as expected. If you go ahead and do it anyway, and it DOES work, great.
But don't blame the tel: URL's author if it doesn't. Hence the MUST 
NOT in 2806.

>Since both of these numbers lie within E.164 space, only the second form

LwC contends:
I beg to differ; I think that the first ("18005551234") is not a fully
qualified E.164 number. The second "+431805551234" is. The plus indicates
a NAI value of 4.

><tel:20-8371-1138;phone-context=+44> for +44-20-8371-1138 ?]

LwC suggests:
Access digits? No, yes, or maybe.
I think that this is a flaw in 2806, as it is silent on this topic. There
are examples that include them (in the section on post dial strings) but
that is probably the exception rather than the norm.
Personally, I'd check in case the author is being dumb, and if so throw
away the extraneous access digits.
(I find a cricket bat around the head teaches them not to do it again :)

>understand the rules (see the +1-800 example above).

LwC puzzles:
Please clarify. The person writing the URI is either the person who is paying
the TSP for the free-phone service (in which case I forgive them being bemused
having looked at the huge contract) or their agent. In either case, they should
know if they're paying for International free-phone service - they will notice!

>     <tel:+44-1883-121666;phone-context=not+44>

LwC ranks:
You don't; nor do you need to do this. You have two NAPTRs in pref. order
and then put the one that constructs the <tel:+448452121666;phone-context=+44>
highest. It will be invalid for people outside Blighty, so they'll pick up the
second one. (Indeed, you could do likewise for people in the Netherlands, ...)

>last two months, due to a number porting cock-up).

LwC sympathises:
My Sympathies (With ENUM, you can perform this particular cock-up yourself,
so saving Operator staff valuable time :)

>If deliberate (e.g. to

LwC admits:
Hmm....The none-of-the-above is (as you guess) a lower priority NAPTR.
The others are (as you also guess) a challenge. The "or" is already in 2806
- just add more parameters, however this can lead to excessive length URIs.

I'm not completely convinced that this is the way to do things, but with
the old (Area Codes -> Modem pool number) list Demon used to have, I can
see that it would be have been very useful.

If you have 100 areas for a single telephone number then this is always
going to be a problem. I wonder if reserving numbers in each of the
calling areas and then CNAMEing them to a common number is the way to go.

Not convinced on that, but if anyone else has any neat ideas, please holler.

>on the second, though 121 now does the same job.

LwC agrees:
Very good point - I suspect that we've have to re-specify using a modified
TSP parameter to get the right effect (e.g. for your example we'd write
something like <tel:123;TSP-context=orange.co.uk>).

>Not sure what you mean by that one.

LwC sez:
If it's a PC and has been allocated a number by Oftel (or BT, or whoever)
then this is the area code - some gateways may let the PC use local numbers
but of course they need to know the area code in which it treats itself as
being located.
>If the number is in E.164, then there's little or no point in this. If it

LwC enquires:
I understand your point - we should all use E.164 when publishing our phone
numbers - however, until they all die out, there is a sizeable chunk of the
population who don't understand this and will feel more comfortable with
local numbers - I haven't checked, but as you're in the smoke I would be
interested in the format of the numbers on cards adorning the phone boxes.

>>  PSTN  segment of the call should be originated)

LwC expands:
This differs from the previous in that the call origination point is at
some gateway, somewhere connected to the PSTN. If the called number can
converted into canonical E.164 format, AND is not restricted in service
area, then this does not matter (unless you pay the bill). If there IS
a restricted service area, then it DOES matter - the gateway provider
may have to select a gateway interconnected in this service area.

Thanks for the interesting comments - I will ponder the ROMP/Call Centre
one further. Another reason, perhaps, to update 2806?

All the best,
    Lawrence