Re: Comment on SIP

Henning Schulzrinne <schulzrinne@cs.columbia.edu> Mon, 16 February 1998 14:49 UTC

Return-Path: <owner-confctrl>
Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id GAA25364 for confctrl-outgoing; Mon, 16 Feb 1998 06:49:22 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA25359 for <confctrl@zephyr.isi.edu>; Mon, 16 Feb 1998 06:49:21 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA26807 for <confctrl@ISI.EDU>; Mon, 16 Feb 1998 06:49:20 -0800 (PST)
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id JAA11990; Mon, 16 Feb 1998 09:49:18 -0500 (EST)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id JAA26643; Mon, 16 Feb 1998 09:49:12 -0500 (EST)
Message-ID: <34E851E7.8C8DEF94@cs.columbia.edu>
Date: Mon, 16 Feb 1998 09:49:11 -0500
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: takagih@iwatsu.co.jp
CC: confctrl@ISI.EDU
Subject: Re: Comment on SIP
References: <0002008162000321006600000855@algw.iwatsu.co.jp>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

takagih@iwatsu.co.jp wrote:
> 
> Dear Authors of SIP,
> 

> Q 1.
> On page 49 and 50 there are some PSTN phone addresses that
> I think they use a notation defined in a working phase draft
> called "URLs for telephony".
> But the directive, "phone" is different from the draft and
> they have additional descriptions such like "service=",
> "mobility="...

I looked at
ftp://ds.internic.net/internet-drafts/draft-antti-telephony-url-03.txt
and did not find any reference to "service" or "mobility". I assume you
are thus referring to the SIP draft. These modifiers are (now more
clearly...) *not* part of the URL, but part of the Location header and
described in the "Call Control" SIP extensions draft.

> Do they use a different notation from the draft. If so, could
> you name the specification(s).

The intent is to align phone number notation as much as possible with
other ongoing IETF work; thanks for pointing out the discrepancy. 

Some of the things contained in the URL are part of the Location header
in the "Call Control" draft. Our intent was to keep the phone URL to
what's necessary to make a phone call, rather than describe the service
completely, that being the job of other protocols. (One reason not to
include this in the URL is that classifications such as business and
home are of interest for all kinds of URLs, including H.323, SIP,
possibly even email and web pages. This blurs the distinction between a
"locator" and descriptor (URC). Another reason is that it makes URLs too
long and it becomes unclear as to whether one has to specify all of it
to actually make the phone call.)

> 
> Q 2.
> If the answer of Q 1 is using a different or modified specification,
> is it possible for you to add a new parameter to the specification ?
> 
> The parameter is "scope=" that specifies the valid scope of
> the phone number.
> 
> The following is the usage of this parameter.
> If the scope is extension, the number can be reached from
> a local PBX, i.e. the number is a PBX extension number.
> If the scope is global or the parameter is omitted, the number can be
> reached from any PSTN network, i.e. the number is an international number
> in ITU Recommendation E.123.
> 
> If the destination cannot be reached via computer network, dialing the
> extension number is a good alternative method, if it can be used.

One of the greatest weaknesses of the phone numbering system is that
phone numbers are not source-independent, i.e., depending on where I am,
I need to dial different numbers to reach a location or, conversely,
that a number which is valid from location X is not valid from location
Y. (Example: In Atlanta, you have to dial the area code for local
numbers, but you are not allowed to dial the 1. Try convincing the
Windows'95 dialer of that...)

I thus agree with Antti Vaha-Sipila's reasoning that including scoped
numbers is (a) a bad ideas, (b) if it has to be done, cannot be
automated in any meaningful way. "Local" has very little meaning on the
Internet, as it is quite likely that web pages, for example, don't have
the same locality as phone numbers.

Unless there is a strong reason not to do this, I would much rather
force all phone numbers in SIP to be global (that is, full E.164) and
let the PBX figure out that this is a local number (trivial, by
comparing the prefix) and strip any numbers not needed for dialing.

Henning