Subject: [Sip] TEL-URL local numbers

From: Christer Holmberg <[email-masked]>
Date: Fri, 17 Jan 2003 13:55:03 +0200

Hi,

When reading the latest (-07) of the 2806bis draft, I see that the "+"
prefix is mandatory for both global- and local numbers.

I assume this means that if a SIP-URI has the user=phone parameter set,
the userpart is not valid unless there is a "+" prefix (since RFC3261
says the userpart shall be parsed as a TEL-URL telephone-uri in this
case)?

The reason I am confused about this because in the examples (chapter 6)
in 2806bis there is no "+" sign in front of the local numbers. Is this a
leftover from previous versions, when there were no "+" in front of
local numbers, or is there a bug in the ABNF?

I also wonder why there has to be a "+" sign in front of a local number
in the first place? When reading chapter 5.1.3 and 5.1.4 I find nowhere
an explanation for this (5.1.3 even says that global numbers are
identified by the "+" prefix).

Regards,

Christer Holmberg
Ericsson Finland

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

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

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.

-- juha

---

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

Hi,

> looks to me that the syntax has a bug, i.e., local numbers don't need

Local numbers MUST NOT start with "+", I'd say.

I also wonder a little about the syntax for local numbers:

local-number          =  local-number-digits *par context *par

I wonder why context is "surrounded" by optional pars. I guess there is
nothing wrong with it from an ABNF point of view, but wouldn't it look
better to have the opional pars either before or after the context? That is
how it used to be, so I wonder what the reason for changing this is?

> be derived from the from uri.

I was going to ask the same, but forgot, so good that you brought it up :)
In previous versions of the draft the context is optional, so I also wonder
what the reason for making it mandatory is?

Regards,

Christer Holmberg
Ericsson Finland

---

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.

> be derived from the from uri.

How would it be uniquely and unambiguously derived?

---

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 11:56:48 +0000

At 1:11 pm +0200 24/1/03, Christer Holmberg wrote:
>Hi,
>
>>  At 3:23 pm +0200 17/1/03, [email-masked] wrote:
>  >[Lawrence said:]
>  > 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.
>
>[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.
>
<snip>
>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.

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
-- 
-----------------------------------------------------------------------
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.
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

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: "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: 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