Subject: [Iptel] Re: [Sip] TEL-URL local numbers

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 17 Jan 2003 08:04:35 -0500

[This discussion should be on iptel, not sip.]

Yes, it's a bug which crept in due to other revisions. It will be fixed 
in 08.

[email-masked] wrote:
> looks to me that the syntax has a bug, i.e., local numbers don't need
> start with +.
> 
> i have another question.  why is context mandatory in local numbers?  i
> would like to make it optional and if it is missing, the context would
> be derived from the from uri.

How would it be uniquely and unambiguously derived?

> -- juha

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

---

From: [email-masked]
Date: Fri, 17 Jan 2003 15:14:24 +0200

> How would it be uniquely and unambiguously derived?

if my from uri is +358-3-1234567 and i make a call to 03-2345678, the
user agent or proxy could figure out that the missing country code is
+358.  this is normal dial plan stuff.

-- juha

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 17 Jan 2003 08:15:58 -0500

> +358.  this is normal dial plan stuff.

tel URIs, as has been discussed a few times, do no incorporate dial 
plans. They are *generated* by dial plans.

---

From: [email-masked]
Date: Fri, 17 Jan 2003 15:23:36 +0200

> plans. They are *generated* by dial plans.

if the tel uri must be always fully qualified then the ua must have a
dial plan and generate the fully qualified tel uri.  in some cases it
would be easier to let the proxy to run the dial plan code on the
message and fully qualify the tel uri.

-- juha

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 17 Jan 2003 15:28:05 +0200

Hi,

> message and fully qualify the tel uri.

I agree with Juha. I don't think we have any requirements on having dial plans
in the SIP phones, do we? I know there is a discussion ongoing about it, but
still...

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Fri, 24 Jan 2003 10:48:23 +0000

>message and fully qualify the tel uri.

Hi Folks,
  ...sigh...

If I receive a tel URL containing a local number, without
and idea of the context *in the place that the URL was constructed*
then I don't know whether or not I'm in that context.

I could dial the local number, but once disambiguated it may well
address a completely different terminal from the one the URL was
intended to address. Yes, the UA will know how to dial out, and will
know it's context, but can't guess the context in which the URL
was written.

The context says - this is the context in which this local number
is valid (e.g. the context of the entity constructing this URL)
- *not* your context.

If the recipient of the URL is NOT in that context then it can't
dial without some serious hacking in the UA, and even then it
might not be possible to dial the number from the recipient's UA.

Hence we NEED a context; this has not changed since Antti's original
document.

all the best,
   Lawrence
-- 
-----------------------------------------------------------------------
Roke Manor Research    : This information is provided "as is" and is not
<mailto:[email-masked]>: intended to create any contractual or legal
<tel:+441794833666>    : relationship.
_______________________________________________
Iptel mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/iptel

---

From: [email-masked]
Date: Fri, 24 Jan 2003 13:09:17 +0200

> then I don't know whether or not I'm in that context.

yes, if YOU receive from me such an url you may not know what its
context is, but the story is quite different if the proxy of my
organization receives such an url from me.  in such a case there is not
need to the ua to add a context to the local number.

-- juha

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 24 Jan 2003 13:11:40 +0200

Hi,

> then I don't know whether or not I'm in that context.

[CHH] In this case you could reject it. If the sender didn't insert it, and
there was no intermediate node inserting it, there is a network architecture
problem.

My point, I guess Juha's too, was not that there should not be a context when
the URL reaches the UAS, but that it MAY be inserted by another node than the
UAC.

> know it's context, but can't guess the context in which the URL

Again, if the UAC doesn't insert the context, another node within the same
context (or, at least a node knowing to which the UAC belongs) SHOULD insert it.

> is valid (e.g. the context of the entity constructing this URL)

I agree on that. However, my SIP phone may not know to which context they
belong, for whatever reason, but the outbound proxy they communicate with DO
know.

> might not be possible to dial the number from the recipient's UA.

Again, in this case the URL will be rejected.

> Hence we NEED a context; this has not changed since Antti's original

Again, I do agree on that. The issue is if it shall be a MUST for the UAC to
insert the context, or if a proxy can do it.

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Fri, 24 Jan 2003 11:44:35 +0000

>need to the ua to add a context to the local number.

Hi again, Juha, folks,
   So, ...
IF you are in the same context as your proxy,
THEN it can use the URL as is,
ELSE IF your proxy knows your context,
THEN the proxy can re-interpret the URL context;
      IF that number if dailable from the Proxy,
      THEN it can use the converted number
      ELSE the URL will be rejected
ELSE the URL will be rejected -- no disambiguation possible.

Now, I'm on the South coast of the UK, whilst my proxy is
in Richardson, TX, USA. I'm aware of another user of this proxy
who is based in Munich, Germany. The proxy may well not find it
easy to guess who's where and to re-construct the intended
disambiguated number. If we pass context along, then it doesn't
have to remember state - it knows by inspection of the URL.

If I *buy* an "off-the-shelf" proxy, I don't expect to hack its
source code just because it happens to be in the same room as me.
The default config will be that the proxy will expect a context
or will bounce the URL.

If you want to hack the proxy and your UA so that they don't exchange
this info, then that's fine. However, don't send this URL to anywhere
else, as the recipient probably can't disambiguate it.

atb,  L

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Fri, 24 Jan 2003 11:56:48 +0000

At 1:11 pm +0200 24/1/03, Christer Holmberg wrote:
>  >[Lawrence said:]
<snip>
>belong, for whatever reason, but the outbound proxy they communicate with DO

To which I reply::

Aha! Thanks for the clarification - I'm being slow today.
   This is a pure SIP issue - usage of tel URLs in SIP, and request
modification by intermediate nodes. Interesting issue.

However, IMHO there are other uses for tel URLs, so I'd suggest that
draft-antti-rfc2916bis is correct in mandating this behaviour.

If there's a separate draft for "SIP usage of tel URLs" that qualifies
the main tel URL RFC, relaxing the requirement, that's fine; I'm not sure
if it's a SIP or SIPPING job, but I think that's where it lives.

I just don't want to nail this down in the general 2916 update.

all the best,
    Lawrence

---

From: [email-masked]
Date: Fri, 24 Jan 2003 13:59:37 +0200

> have to remember state - it knows by inspection of the URL.

you may very well invent scenarios where you have to specify the
context and i have never said that you would not be allowed to do so.
what i have said is that there are lots of scenarios where it is
unnecessary to specify the context, for example, my office sip
hard phone may not have a habit to travel around the world.

i don't quite understand what your motivation is to force me to
configure all my phones with the context info when local calling without
a context info has worked very well for us for two years now.  if you
need to give the context, you are very welcome to do so, but don't try
to force me to do the same.

 > The default config will be that the proxy will expect a context

if that is the case with your proxy, then you simply have to configure
the context in every sip phone that uses local calling.  i'm simply
luckier that you, because i don't need to do it for phones that don't
travel around.

 > else, as the recipient probably can't disambiguate it.

of course not, because my proxy will convert the number to a global one
before it leaves my organization.

-- juha

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 24 Jan 2003 14:01:02 +0200

Hi,

Comment ([CHH]) at the end.

> else, as the recipient probably can't disambiguate it.

[CHH] I don't think anyone has been talking about having to hack source
code... This could be a feature in the proxy, and something called
"configuration" could then be used to make sure it behaves correctly ;)

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 24 Jan 2003 15:37:15 +0200

H,

> I just don't want to nail this down in the general 2916 update.

[CHH] 2916 doesn't have to say anything about SIP. 2916 can make the context
optional, and "users" (eg SIP) and network architectures can then mandate the use of
the context. There may also be other parameters, which are optional in 2916, but
still are mandatory for specific users/architectures/applications.

Another option, which you mentioned, is to write a separate "SIP usage of tel URL"
draft (this is pretty much what has been done for SDP in H.248/Megaco), but I am not
sure that is the best solution for this specific purpose.

Have a nice weekend!

Regards,

Christer Holmberg
Ericsson Finland

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 24 Jan 2003 08:39:59 -0500

> "configuration" could then be used to make sure it behaves correctly ;)

One of the underlying SIP assumptions is that we should treat each 
terminal as mobile, i.e., you should be able to plug it in anywhere in 
the Internet and it should work (modulo NATs and firewalls).

Another fundamental principle of modern Internet protocol design, I 
believe, is that users should not get involved in configuring devices or 
debugging obscure protocol behavior. Things should fail explicitly 
rather than misbehave.

If I take my shiny IP phone home from work, my outbound proxy changes. 
If the phone has no context, I will likely get obscure failures or, in 
the worst case, reach the wrong destination.

Nobody can keep you from omitting phone-context in a phone and 
back-fixing this in a proxy. However, that does not mean that the WG 
should endorse such behavior in documents, particularly given that the 
cost of configuring IP devices with phone context is close to zero.

Henning

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Fri, 24 Jan 2003 13:55:17 +0000

Hi folks,
<snip>
comments below - lwc -
>sure that is the best solution for this specific purpose.

- lwc -
[BTW, folks, apologies for cross-posting - this seems to relevant both to
SIP and IPTEL]

A SIP proxy can have a mechanism to insert a context, so disambiguating the
tel URL. So can other systems, I suspect.
However... if there is no such mechanism, then the DEFAULT behaviour is to
require a context as part of a "local number" tel URL (or bounce the URL).

I think that this "default" should be in RFC2916bis, whilst the relaxation
of the rule should be in the areas where there are mechanisms to avoid the
potential mistakes. Otherwise we can have unsafe but standard-conforming
implementations. My opinion only, but I need to be convinced.

   Nice weekend to one and all.
     Lawrence

---

From: [email-masked]
Date: Fri, 24 Jan 2003 16:16:36 +0200

> the Internet and it should work (modulo NATs and firewalls).

even mobile terminals using local numbers would work ok w/o context
configuration if the terminal is using a local proxy.  only in case
where the terminal uses some non-local proxy and local numbers the
context needs to be configured.  and if it does so, how does the user
know what to put in to the local context?  are you suggesting it learns
it via dhcp or how?  where is the spec for that?

 > the worst case, reach the wrong destination.

we could say that the lack of explicit context means use the context of
the user's home proxy.  that would cause the call via a foreign proxy to
fail w/o context.

 > cost of configuring IP devices with phone context is close to zero.

configuration complexity will certainly increase in many common cases if
the context is made mandatory.  and how about backwards compatibility
with today's sip phones?  i don't know any that supports context
configuration.

-- juha

---

From: Richard Shockey <[email-masked]>
Date: Fri, 24 Jan 2003 10:21:25 -0500

>>sure that is the best solution for this specific purpose.

Well some of this discussion might be relevant for the ENUM WG as well but 
I do not see any need for 2916 to have any information about context at 
all. This thread is somewhat confusing to me.

What 2916 is explicit about is that is dealing with fully qualified e164 
numbers only. You will have noticed that references or examples of partial 
e164 numbers have been removed from 2916bis 03.  Queries to partial e164 
numbers ( local numbers ) or private dialing plans are assumed not to be in 
the context of e164.arpa at all.

UAC ore the relevant proxyshould be able to understand their context and 
reformulate the URL into the e164 number before any other action is taken.

As some one else mentioned this is old stuff to most of us... as a old 
developer of outbound IVR systems we always had to have a local text 
configuration file.

>implementations. My opinion only, but I need to be convinced.

For my information are you suggesting that this behavior be documented in a 
enumservice field registration for the tel URL or as part of the overall 
use of ENUM in SIP.

I dont see how documenting this in 2916bis is relevant..or am I missing 
something here

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: +1 815.333.1237
<mailto:[email-masked]> or <mailto:[email-masked]>
  <http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Fri, 24 Jan 2003 15:55:09 +0000

At 10:21 am -0500 24/1/03, Richard Shockey wrote:
><snip>
>Well some of this discussion might be relevant for the ENUM WG as 
>well but I do not see any need for 2916 to have any information 
>about context at all. This thread is somewhat confusing to me.
<snip>

To which I reply:

Arghh!!!!
     My bad - for 2916bis in the thread, please read 2806bis.
It's time for the weekend. That will teach me to respond to mailing
lists during a teleconference - duh!

Sorry for the confusion - we return you to your normal service.

atb,  Lawrence

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 24 Jan 2003 20:40:33 +0200

Hi,

> >>[CHH] 2916 doesn't have to say anything about SIP. 2916 can make the >>context
> optional, and "users" (eg SIP) and network architectures can then >>mandate the
> use of

[CHH] I was actually thinking about that. If I have a E.164 number, do an ENUM DNS
lookup, and receive a TEL-URL with a local number in the lookup answer, shall that
TEL-URL contain the context, or shall my node add it?

> the context of e164.arpa at all.

[CHH] So, possible TEL-URL(s) received in the ENUM lookup MUST be in international
format?

Regards,

Christer Holmberg
Ericsson Finland

---

From: Richard Shockey <[email-masked]>
Date: Fri, 24 Jan 2003 14:14:36 -0500

>TEL-URL contain the context, or shall my node add it?

why would ENUM return a local number is my question? What is the 
application scenario you have in mind ..

For Instance the presumption is that you would have a return of URL' one 
sip maybe one tel
this is the old call forwarding application ..if you cannot reach sip: then 
try tel: easy to do with the modification of the preference field..then 
certainly the tel should be a FQe164.

>[CHH] So, possible TEL-URL(s) received in the ENUM lookup MUST be in 

Thats certainly what I would recommend and that has always been the 
parameters of 2916 no partial e164 numbers . but you could point to a 
private dialing plan as in a domain other than e164.arpa.

In fact you can create any terminal or non terminal redirection you want if 
you write up a RFC describing it using the procedure in 2916bis