From mailnull@www1.ietf.org  Thu Jan  2 14:17:27 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11786
	for <sipping-archive@odin.ietf.org>; Thu, 2 Jan 2003 14:17:27 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h02JPq914605
	for sipping-archive@odin.ietf.org; Thu, 2 Jan 2003 14:25:52 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02JPqJ14602
	for <sipping-web-archive@optimus.ietf.org>; Thu, 2 Jan 2003 14:25:52 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11777
	for <sipping-web-archive@ietf.org>; Thu, 2 Jan 2003 14:16:56 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02JOUJ14563;
	Thu, 2 Jan 2003 14:24:30 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02JNDJ14527
	for <sipping@optimus.ietf.org>; Thu, 2 Jan 2003 14:23:13 -0500
Received: from md2.ksolutions.it (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11742
	for <sipping@ietf.org>; Thu, 2 Jan 2003 14:14:17 -0500 (EST)
Received: from computer ([62.98.178.35])
	by md2.ksolutions.it (Mirapoint)
	with ESMTP id BGF28666 (AUTH enzo.abate@katamail.com);
	Thu, 2 Jan 2003 20:17:22 +0100 (CET)
From: "Enzo" <enzo.abate@katamail.com>
To: <sipping@ietf.org>
Date: Thu, 2 Jan 2003 20:16:19 +0100
Message-ID: <000a01c2b293$6fde2000$23b2623e@computer>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000B_01C2B29B.D1A28800"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Subject: [Sipping] conference and participant's list
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_000B_01C2B29B.D1A28800
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

In a centralized conference model, I have the problem of discovering
participant's identities. I have found 2 solutions:

	
1.	I can use the SIP extension (CONF method) described in
"draft-miladinovic-sip-multiparty-ext-01";
2.	The conference server can use a 200 OK in response to a REGISTER
request, to carry the participant's list, and then the client can
subscribe a "conference" event as described in
"draft-ietf-sipping-conference-package-00", to obtain notifications of
list changes.

They seem equivalent methods; what of these ways "SHOULD" I go?

 

Thanks in advance.

Enzo.


------=_NextPart_000_000B_01C2B29B.D1A28800
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Messaggio</TITLE>

<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR></HEAD>
<BODY><FONT face=3DArial size=3D2><SPAN class=3D296243917-02012003>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; TEXT-INDENT: 0cm; LINE-HEIGHT: normal; =
TEXT-ALIGN: left"=20
align=3Dleft><SPAN lang=3DEN-GB=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-ansi-language: =
EN-GB">In a=20
centralized conference model,&nbsp;I have the problem of discovering=20
participant<SPAN class=3D296243917-02012003>'s</SPAN> identities. I have =
found 2=20
solutions:</SPAN></P>
<OL><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-ansi-language: =
EN-GB"></SPAN><SPAN=20
  lang=3DEN-GB style=3D"mso-ansi-language: EN-GB"><?xml:namespace prefix =
=3D o ns =3D=20
  "urn:schemas-microsoft-com:office:office" /><o:p>
  <LI><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-ansi-language: =
EN-GB">I can=20
  use the SIP extension (CONF method) described in=20
  "draft-miladinovic-sip-multiparty-ext-01";</SPAN></LI>
  <LI><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-ansi-language: =
EN-GB"></SPAN></o:p></SPAN><SPAN=20
  lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-ansi-language: =
EN-GB">The=20
  conference server can use a 200 OK in response to a REGISTER request, =
to carry=20
  the participant<SPAN class=3D296243917-02012003>'s</SPAN> =
list,&nbsp;and then=20
  the client can subscribe a "conference" event as described in=20
  "draft-ietf-sipping-conference-package-00", to =
obtain&nbsp;notifications=20
  of&nbsp;list changes.</SPAN><SPAN lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p></o:p></SPAN></LI></OL>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; TEXT-INDENT: 0cm; LINE-HEIGHT: normal; =
TEXT-ALIGN: left"=20
align=3Dleft><SPAN lang=3DEN-GB=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-ansi-language: =
EN-GB">They seem=20
equivalent methods; what of these ways "SHOULD" I go?</SPAN><SPAN =
lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p></o:p></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; TEXT-INDENT: 0cm; LINE-HEIGHT: normal; =
TEXT-ALIGN: left"=20
align=3Dleft><SPAN lang=3DEN-GB style=3D"mso-ansi-language: EN-GB"><FONT =
size=3D3><FONT=20
face=3D"Times New Roman">&nbsp;<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; TEXT-INDENT: 0cm; LINE-HEIGHT: normal; =
TEXT-ALIGN: left"=20
align=3Dleft><SPAN lang=3DEN-GB=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-ansi-language: =
EN-GB">Thanks in=20
advance.</SPAN><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p></o:p></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; TEXT-INDENT: 0cm; LINE-HEIGHT: normal; =
TEXT-ALIGN: left"=20
align=3Dleft><SPAN lang=3DEN-GB=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-ansi-language: =
EN-GB">Enzo.</SPAN><SPAN=20
lang=3DEN-GB=20
style=3D"mso-ansi-language: =
EN-GB"><o:p></o:p></SPAN></P></SPAN></FONT></BODY></HTML>

------=_NextPart_000_000B_01C2B29B.D1A28800--

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  2 14:37:32 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12418
	for <sipping-archive@odin.ietf.org>; Thu, 2 Jan 2003 14:37:32 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h02Jjvo16259
	for sipping-archive@odin.ietf.org; Thu, 2 Jan 2003 14:45:57 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02JjvJ16256
	for <sipping-web-archive@optimus.ietf.org>; Thu, 2 Jan 2003 14:45:57 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12411
	for <sipping-web-archive@ietf.org>; Thu, 2 Jan 2003 14:37:00 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02JjAJ16221;
	Thu, 2 Jan 2003 14:45:10 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02JiYJ16170
	for <sipping@optimus.ietf.org>; Thu, 2 Jan 2003 14:44:34 -0500
Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12369
	for <sipping@ietf.org>; Thu, 2 Jan 2003 14:35:38 -0500 (EST)
Received: from diamond.cs.columbia.edu (diamond.cs.columbia.edu [128.59.16.9])
	by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id h02Jcn9N027667
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT);
	Thu, 2 Jan 2003 14:38:50 -0500 (EST)
Received: from diamond.cs.columbia.edu (localhost [127.0.0.1])
	by diamond.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id h02JcmcR004961;
	Thu, 2 Jan 2003 14:38:48 -0500 (EST)
Received: (from petkos@localhost)
	by diamond.cs.columbia.edu (8.12.6/8.12.6/Submit) id h02Jcmlf004958;
	Thu, 2 Jan 2003 14:38:48 -0500 (EST)
From: "Petri K. Koskelainen" <petkos@cs.columbia.edu>
Message-Id: <200301021938.h02Jcmlf004958@diamond.cs.columbia.edu>
Subject: Re: [Sipping] conference and participant's list
To: enzo.abate@katamail.com (Enzo)
Date: Thu, 2 Jan 2003 14:38:48 -0500 (EST)
Cc: sipping@ietf.org
In-Reply-To: <000a01c2b293$6fde2000$23b2623e@computer> from "Enzo" at Jan 02, 2003 08:16:19 PM
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hi Enzo,

> In a centralized conference model, I have the problem of discovering
> participant's identities. I have found 2 solutions:
> 

You can subscribe to conference state and get notifications
about the participants. See 
http://www.ietf.org/internet-drafts/draft-ietf-sipping-conference-package-00.txt


> 1.	I can use the SIP extension (CONF method) described in
> "draft-miladinovic-sip-multiparty-ext-01";

This idea will not be used.


> 2.	The conference server can use a 200 OK in response to a REGISTER
> request, to carry the participant's list,

You don't need this (makes no sense anyway).

> and then the client can
> subscribe a "conference" event as described in
> "draft-ietf-sipping-conference-package-00", to obtain notifications of
> list changes.

You can do this without using REGISTER.
First notify includes the current participant list. Why this is not enough
for your purposes ?

> They seem equivalent methods; what of these ways "SHOULD" I go?

Forget option 1. Using Subscribe/Notify for this is a SHOULD.
Conferencing Framework document should also clarify
these issues.

Br,
Petri
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  2 14:50:41 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12625
	for <sipping-archive@odin.ietf.org>; Thu, 2 Jan 2003 14:50:41 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h02Jx6s16899
	for sipping-archive@odin.ietf.org; Thu, 2 Jan 2003 14:59:06 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02Jx6J16892
	for <sipping-web-archive@optimus.ietf.org>; Thu, 2 Jan 2003 14:59:06 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12611
	for <sipping-web-archive@ietf.org>; Thu, 2 Jan 2003 14:50:09 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02Jw1J16811;
	Thu, 2 Jan 2003 14:58:01 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02JtWJ16696
	for <sipping@optimus.ietf.org>; Thu, 2 Jan 2003 14:55:32 -0500
Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12545
	for <sipping@ietf.org>; Thu, 2 Jan 2003 14:46:35 -0500 (EST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA22578
	for <sipping@ietf.org>; Thu, 2 Jan 2003 14:49:44 -0500 (EST)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA14349
	for <sipping@ietf.org>; Thu, 2 Jan 2003 14:49:45 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <ZVACH2GW>; Thu, 2 Jan 2003 14:49:45 -0500
Message-ID: <313680C9A886D511A06000204840E1CF030B5C96@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'sipping@ietf.org'" <sipping@ietf.org>
Date: Thu, 2 Jan 2003 14:49:41 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sipping] Gateway BCP
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

I'm planning on writing a BCP on gateways.  I'm going to start with
enterprise/home style gateways rather than "tandem" PSTN gateways.
If you have experience, as we do, where every gateway does things
different enough that your sipphone/proxy has all kinds of special
purpose code in it to cope, please let me know where the differences
arise, and I'll try to get something in there to make it one way.  

I'll stick to sip stuff, leaving configuration/provisioning out of it
to start, although I'm tempted to put stuff like DHCP support in there.

One of the big areas we have problems with is getting URIs correct
so that CallerId works both ways.  I'd like to start a thread on that,
which I will do in the next email.

Brian
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  2 14:51:50 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12670
	for <sipping-archive@odin.ietf.org>; Thu, 2 Jan 2003 14:51:50 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h02K0Fw16983
	for sipping-archive@odin.ietf.org; Thu, 2 Jan 2003 15:00:15 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02K0FJ16980
	for <sipping-web-archive@optimus.ietf.org>; Thu, 2 Jan 2003 15:00:15 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12663
	for <sipping-web-archive@ietf.org>; Thu, 2 Jan 2003 14:51:18 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02Jx4J16853;
	Thu, 2 Jan 2003 14:59:04 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02JuCJ16713
	for <sipping@optimus.ietf.org>; Thu, 2 Jan 2003 14:56:12 -0500
Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12548
	for <sipping@ietf.org>; Thu, 2 Jan 2003 14:47:15 -0500 (EST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA22592
	for <sipping@ietf.org>; Thu, 2 Jan 2003 14:50:24 -0500 (EST)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA14380
	for <sipping@ietf.org>; Thu, 2 Jan 2003 14:50:25 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <ZVACH2G6>; Thu, 2 Jan 2003 14:50:25 -0500
Message-ID: <313680C9A886D511A06000204840E1CF030B5C97@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'sipping@ietf.org'" <sipping@ietf.org>
Date: Thu, 2 Jan 2003 14:50:15 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sipping] URIs for Gateways
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

On an enterprise type gateway, it's a problem to construct headers to
get the correct thing to happen, especially with CallerId and multiple
"lines".

Enterprise gateways almost always have multiple ports/lines connected to
them.  These lines may be connected to the PSTN or they may be connected
to a PBX.  Some gateways are simple analog loops, others are digital
telephone loops, ISDN BRI, CAS or ISDN PRI trunks.  There are two ways
these gateways are deployed:
    Pool - where all the lines are in a big pool, and calls come in to
		the first available line in the pool, and go out on the
           next available line in the pool.  It's pretty close to
		impossible to have correct CallerId with pooled lines
    Mapped - a user is mapped to a particular line/port.
		All calls to that line/port go to that user, all calls from
		that user go to that line/port
When you have a shared trunk like a CAS or PRI, effectively you have
a hybrid.  Each of the "DS0s" are pooled, but the gateway can obtain/insert
phone number information to determine/assert the called/calling party.

Many, but not all, gateways implement mapped; you can provision a URI with
a line/port.  When a call arrives at the line, a SIP call is made to the
specified URI.  When a sip call comes to the gateway, the FROM line
is matched with the provisioned URIs to pick the line/port to place the
call.  For example, I might have a mapping of "brian.rosen@sip.marconi.com"
to port3 on gateway2.marconi.com.  A call from 4125551212 to my phone
number,
7247426826 might result in an INVITE from the gateway like:
INVITE brian.rosen@sip.marconi.com
From: port3@gateway2.marconi.com
To: brian.rosen@sip.marconi.com

To place a call on the gateway, some gateways use the user part of a URI
as a phone number.  So:
INVITE 4125551212@gateway2.marconi.com
From: brian.rosen@sip.marconi.com
To: 4125551212@gateway2.marconi.com

Not all gateways work like this.  Some use the display name for the number,
and the username as the port:
INVITE port3@gateway2.marconi.com
From: brian.rosen@sip.marconi.com
To: "4125551212" <port3@gateway2.marconi.com>

Now, we add the complication of CallerId. 
For gateways that maintain mappings, some gateways send called party number
for terminating calls in the display name of the From:
INVITE brian.rosen@sip.marconi.com
From "4125551212" <port3@gateway2.marconi.com
To: "7247426826" <brian.rosen@sip.marconi.com>

I have not seen a gateway that actually accepts a calling party
number in the display name of a From on an originating call, but
it might be useful if more than one number mapped to the same
user. 

Many of the PRI/CAS gateways don't have full tables for the hundreds of
numbers per trunk that they can handle.  For these gateways, you tell
them what number to use for the outgoing CallerId, and they report
what called number they got on an incoming call.
If there is no mapping table, then you need some intermediary
to translate the called party to a sip URI.  So, the gateway might send
INVITE 7247426826@translate.marconi.com
From: "4125551212" <port3@gateway2.marconi.com>
To: "7247426826" <7247526826@translate.marconi.com> 

The translator would have to redirect the call to the correct party
INVITE brian.rosen@sip.marconi.com
From: "4125551212" <port3@gateway2.marconi.com>
To: "7247426826" <7247526826@translate.marconi.com> 

Similarly, the outgoing call would start as:
INVITE 4125551212@translate.marconi.com
From: brian.rosen@sip.marconi.com
To: "4125551212@translate.marconi.com"

and the translator would send
INVITE port3@gateway2.marconi.com
From: "7247426826" <brian.rosen@sip.marconi.com>
To: "4125551212@translate.marconi.com"

This is a no-no if the translator is a proxy.  It would have to be
a B2BUA.  So, one question is whether we should indeed force the
UAS to know its phone number, so it can construct the From:
correctly.  If a UA has multiple "lines", then it actually needs
a way to tell the gateway which "line" it wants to use for an
outgoing call.  Most systems don't do this, so it's a big deal
to make this assumption.

Translators are pretty useful.  Many systems have them, because you
don't want UAs to know which gateway they should use.

I would prefer to make the rules such that the username was
the port name.  That allows the port name to be registered, and checked.  
That implies the numbers go in the display name.  We might actually
want to specify how tel URIs are used instead of sip URIs.
I'm not sure I know what the right thing to do is, because some
gateways need that port number.

I'd like to get a new header for the calling party number on
an outbound call.  That way, the translator can be a proxy and
add the header.  I'd recommend that gateways allow the number
to be in the From.   

Comments?

Brian

 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  2 15:11:23 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13122
	for <sipping-archive@odin.ietf.org>; Thu, 2 Jan 2003 15:11:23 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h02KJnw18435
	for sipping-archive@odin.ietf.org; Thu, 2 Jan 2003 15:19:49 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02KJnJ18432
	for <sipping-web-archive@optimus.ietf.org>; Thu, 2 Jan 2003 15:19:49 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13113
	for <sipping-web-archive@ietf.org>; Thu, 2 Jan 2003 15:10:52 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02KIZJ18357;
	Thu, 2 Jan 2003 15:18:35 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02KE3J18174
	for <sipping@optimus.ietf.org>; Thu, 2 Jan 2003 15:14:03 -0500
Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12982
	for <sipping@ietf.org>; Thu, 2 Jan 2003 15:05:07 -0500 (EST)
Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66])
	(user=hgs10 mech=PLAIN bits=0)
	by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h02K8IFk013111
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Thu, 2 Jan 2003 15:08:18 -0500 (EST)
Message-ID: <3E149C8F.8020000@cs.columbia.edu>
Date: Thu, 02 Jan 2003 15:09:51 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
CC: "'sipping@ietf.org'" <sipping@ietf.org>
Subject: Re: [Sipping] URIs for Gateways
References: <313680C9A886D511A06000204840E1CF030B5C97@whq-msgusr-02.pit.comms.marconi.com>
In-Reply-To: <313680C9A886D511A06000204840E1CF030B5C97@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

> I'd like to get a new header for the calling party number on
> an outbound call.  That way, the translator can be a proxy and
> add the header.  I'd recommend that gateways allow the number
> to be in the From.   

Generalized, you want something like the Request-URI that can be 
modified or inserted. How about the NAI stuff?

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  2 15:38:45 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13595
	for <sipping-archive@odin.ietf.org>; Thu, 2 Jan 2003 15:38:45 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h02KlCJ20183
	for sipping-archive@odin.ietf.org; Thu, 2 Jan 2003 15:47:12 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02KlCJ20180
	for <sipping-web-archive@optimus.ietf.org>; Thu, 2 Jan 2003 15:47:12 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13588
	for <sipping-web-archive@ietf.org>; Thu, 2 Jan 2003 15:38:14 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02KkFJ20111;
	Thu, 2 Jan 2003 15:46:15 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02Kk1J20088
	for <sipping@optimus.ietf.org>; Thu, 2 Jan 2003 15:46:01 -0500
Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13570
	for <sipping@ietf.org>; Thu, 2 Jan 2003 15:37:02 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.143])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h02KeHYH024631;
	Thu, 2 Jan 2003 15:40:17 -0500 (EST)
Message-ID: <3E14A3AD.2070005@dynamicsoft.com>
Date: Thu, 02 Jan 2003 15:40:13 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
CC: "'sipping@ietf.org'" <sipping@ietf.org>
Subject: Re: [Sipping] URIs for Gateways
References: <313680C9A886D511A06000204840E1CF030B5C97@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit



Rosen, Brian wrote:
> On an enterprise type gateway, it's a problem to construct headers to
> get the correct thing to happen, especially with CallerId and multiple
> "lines".

Let me just make sure I have your network diagram right. You are worried 
about a SIP-based enterprise that has a gateway for communicating to 
outside PSTN users, right?

> To place a call on the gateway, some gateways use the user part of a URI
> as a phone number.  So:
> INVITE 4125551212@gateway2.marconi.com
> From: brian.rosen@sip.marconi.com
> To: 4125551212@gateway2.marconi.com
> 
> Not all gateways work like this.  Some use the display name for the number,
> and the username as the port:
> INVITE port3@gateway2.marconi.com
> From: brian.rosen@sip.marconi.com
> To: "4125551212" <port3@gateway2.marconi.com>

This is a big no-no, since the To field cannot be used as an identifier 
for the desired target. It only specifies the original intended target. 
Had their been proxying inbetween, the wrong number would be dialed.

> 
> Now, we add the complication of CallerId. 
> For gateways that maintain mappings, some gateways send called party number
> for terminating calls in the display name of the From:
> INVITE brian.rosen@sip.marconi.com
>>From "4125551212" <port3@gateway2.marconi.com
> To: "7247426826" <brian.rosen@sip.marconi.com>
> 
> I have not seen a gateway that actually accepts a calling party
> number in the display name of a From on an originating call, but
> it might be useful if more than one number mapped to the same
> user. 
> 
> Many of the PRI/CAS gateways don't have full tables for the hundreds of
> numbers per trunk that they can handle.  For these gateways, you tell
> them what number to use for the outgoing CallerId, and they report
> what called number they got on an incoming call.
> If there is no mapping table, then you need some intermediary
> to translate the called party to a sip URI.  So, the gateway might send
> INVITE 7247426826@translate.marconi.com
> From: "4125551212" <port3@gateway2.marconi.com>
> To: "7247426826" <7247526826@translate.marconi.com> 
> 
> The translator would have to redirect the call to the correct party
> INVITE brian.rosen@sip.marconi.com
> From: "4125551212" <port3@gateway2.marconi.com>
> To: "7247426826" <7247526826@translate.marconi.com> 
> 
> Similarly, the outgoing call would start as:
> INVITE 4125551212@translate.marconi.com
> From: brian.rosen@sip.marconi.com
> To: "4125551212@translate.marconi.com"
> 
> and the translator would send
> INVITE port3@gateway2.marconi.com
> From: "7247426826" <brian.rosen@sip.marconi.com>
> To: "4125551212@translate.marconi.com"
> 
> This is a no-no if the translator is a proxy.  It would have to be
> a B2BUA. 

I don't understand why this is not just network asserted ID.

> So, one question is whether we should indeed force the
> UAS to know its phone number, so it can construct the From:
> correctly.  If a UA has multiple "lines", then it actually needs
> a way to tell the gateway which "line" it wants to use for an
> outgoing call.  Most systems don't do this, so it's a big deal
> to make this assumption.

There is another issue you have been touching on. It relates back to the 
app components ID that I wrote some time ago 
(http://www.jdrosen.net/papers/draft-rosenberg-sip-app-components-01.txt). 
Really, a gateway is an application-independent component, just like a 
conference server or a voicexml server. All of them have the same 
general problem of how you invoke services on them. For a vxml server, 
its how to pass the vxml script. For a conference serevr, its how to 
identify the conference to join. For a gateway, its how to identify the 
user to call, along with other invocation parameters, such as what port 
to join.

What I think you are talking about is that a gateway has several 
parameters needed for "service invocation" on it, and these need to 
somehow been standardized. I still believe we are in need of a framework 
for service invocation in sip, presenting a generic way to name 
services, discover capabilities, pass parameters, register new services, 
and so on. That work was discussed in sipping but never took off....

> I would prefer to make the rules such that the username was
> the port name.  That allows the port name to be registered, and checked.  
> That implies the numbers go in the display name.  

As I point out above, you cannot use the To field display name.

> We might actually
> want to specify how tel URIs are used instead of sip URIs.
> I'm not sure I know what the right thing to do is, because some
> gateways need that port number.
> 
> I'd like to get a new header for the calling party number on
> an outbound call.  That way, the translator can be a proxy and
> add the header.  I'd recommend that gateways allow the number
> to be in the From.   

As I asked above, why is this bit not the network asserted ID?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  2 15:47:29 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13743
	for <sipping-archive@odin.ietf.org>; Thu, 2 Jan 2003 15:47:29 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h02Ktut20669
	for sipping-archive@odin.ietf.org; Thu, 2 Jan 2003 15:55:56 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02KttJ20666
	for <sipping-web-archive@optimus.ietf.org>; Thu, 2 Jan 2003 15:55:55 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13735
	for <sipping-web-archive@ietf.org>; Thu, 2 Jan 2003 15:46:57 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02Kt6J20633;
	Thu, 2 Jan 2003 15:55:06 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02KsXJ20562
	for <sipping@optimus.ietf.org>; Thu, 2 Jan 2003 15:54:33 -0500
Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13723
	for <sipping@ietf.org>; Thu, 2 Jan 2003 15:45:35 -0500 (EST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA24687;
	Thu, 2 Jan 2003 15:48:45 -0500 (EST)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA21240;
	Thu, 2 Jan 2003 15:48:46 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <ZVACHJ9C>; Thu, 2 Jan 2003 15:48:45 -0500
Message-ID: <313680C9A886D511A06000204840E1CF030B5C9D@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Henning Schulzrinne'" <hgs@cs.columbia.edu>
Cc: "'sipping@ietf.org'" <sipping@ietf.org>
Subject: RE: [Sipping] URIs for Gateways
Date: Thu, 2 Jan 2003 15:48:41 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

Yeah, I actually thought of just allowing a display name in the
Request URI and using that, but it seems so foolish to make a change,
and have that change not be exactly what we needed.

We could use NAI.  I suppose we could use a P-Asserted-Identity
with a tel URI:  
P-Asserted-Identity tel:+17247426826

What do we do when the "real" NAI happens?

Brian

> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Thursday, January 02, 2003 3:10 PM
> To: Rosen, Brian
> Cc: 'sipping@ietf.org'
> Subject: Re: [Sipping] URIs for Gateways
> 
> 
> > I'd like to get a new header for the calling party number on
> > an outbound call.  That way, the translator can be a proxy and
> > add the header.  I'd recommend that gateways allow the number
> > to be in the From.   
> 
> Generalized, you want something like the Request-URI that can be 
> modified or inserted. How about the NAI stuff?
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  2 16:00:41 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14177
	for <sipping-archive@odin.ietf.org>; Thu, 2 Jan 2003 16:00:41 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h02L98H22266
	for sipping-archive@odin.ietf.org; Thu, 2 Jan 2003 16:09:08 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02L98J22263
	for <sipping-web-archive@optimus.ietf.org>; Thu, 2 Jan 2003 16:09:08 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14148
	for <sipping-web-archive@ietf.org>; Thu, 2 Jan 2003 16:00:08 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02L8AJ22168;
	Thu, 2 Jan 2003 16:08:10 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02L7vJ22085
	for <sipping@optimus.ietf.org>; Thu, 2 Jan 2003 16:07:57 -0500
Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14091
	for <sipping@ietf.org>; Thu, 2 Jan 2003 15:58:58 -0500 (EST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA25094;
	Thu, 2 Jan 2003 16:02:08 -0500 (EST)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA22544;
	Thu, 2 Jan 2003 16:02:09 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <ZVACHK2A>; Thu, 2 Jan 2003 16:02:09 -0500
Message-ID: <313680C9A886D511A06000204840E1CF030B5C9E@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>
Cc: "'sipping@ietf.org'" <sipping@ietf.org>
Subject: RE: [Sipping] URIs for Gateways
Date: Thu, 2 Jan 2003 16:02:01 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

Yes, it's a SIP based enterprise communication system with
a gateway to a PSTN or PBX.

I'm not really happy with the display name trick, but there are
lots and lots of gateways that do this.  It works because, as we
know, To: and From: are never modified.  It's up to normal
SIP routing to get the INVITE to the right gateway.  When it gets there,
the display name on the To: should be intact.  

However, overloading the display name with the number to dial is
not a great idea, even if a lot of stuff in the field does it.

In a prior message, I did agree that P-Asserted-Identity with
a tel URI could be used for a proxy asserting the translation, 
but not the "real" NAI stuff (Jon's signed headers).  Do you
want a BCP to say that P-Asserted-Identity is what translators
use to get the phone number in the message?  The "P-" is a
problem.  P-Asserted-Identity should go away once the
signed header idea is fully baked, but this problem stays for
a very long time.

I guess I think putting a gateway in the category of a service
component and designing a new framework for service invocation
on it is a bit heavy handed given the problem, but I agree that a
brand new thing can be made to solve any problem.

Brian

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Thursday, January 02, 2003 3:40 PM
> To: Rosen, Brian
> Cc: 'sipping@ietf.org'
> Subject: Re: [Sipping] URIs for Gateways
> 
> 
> 
> 
> Rosen, Brian wrote:
> > On an enterprise type gateway, it's a problem to construct 
> headers to
> > get the correct thing to happen, especially with CallerId 
> and multiple
> > "lines".
> 
> Let me just make sure I have your network diagram right. You 
> are worried 
> about a SIP-based enterprise that has a gateway for communicating to 
> outside PSTN users, right?
> 
> > To place a call on the gateway, some gateways use the user 
> part of a URI
> > as a phone number.  So:
> > INVITE 4125551212@gateway2.marconi.com
> > From: brian.rosen@sip.marconi.com
> > To: 4125551212@gateway2.marconi.com
> > 
> > Not all gateways work like this.  Some use the display name 
> for the number,
> > and the username as the port:
> > INVITE port3@gateway2.marconi.com
> > From: brian.rosen@sip.marconi.com
> > To: "4125551212" <port3@gateway2.marconi.com>
> 
> This is a big no-no, since the To field cannot be used as an 
> identifier 
> for the desired target. It only specifies the original 
> intended target. 
> Had their been proxying inbetween, the wrong number would be dialed.
> 
> > 
> > Now, we add the complication of CallerId. 
> > For gateways that maintain mappings, some gateways send 
> called party number
> > for terminating calls in the display name of the From:
> > INVITE brian.rosen@sip.marconi.com
> >>From "4125551212" <port3@gateway2.marconi.com
> > To: "7247426826" <brian.rosen@sip.marconi.com>
> > 
> > I have not seen a gateway that actually accepts a calling party
> > number in the display name of a From on an originating call, but
> > it might be useful if more than one number mapped to the same
> > user. 
> > 
> > Many of the PRI/CAS gateways don't have full tables for the 
> hundreds of
> > numbers per trunk that they can handle.  For these 
> gateways, you tell
> > them what number to use for the outgoing CallerId, and they report
> > what called number they got on an incoming call.
> > If there is no mapping table, then you need some intermediary
> > to translate the called party to a sip URI.  So, the 
> gateway might send
> > INVITE 7247426826@translate.marconi.com
> > From: "4125551212" <port3@gateway2.marconi.com>
> > To: "7247426826" <7247526826@translate.marconi.com> 
> > 
> > The translator would have to redirect the call to the correct party
> > INVITE brian.rosen@sip.marconi.com
> > From: "4125551212" <port3@gateway2.marconi.com>
> > To: "7247426826" <7247526826@translate.marconi.com> 
> > 
> > Similarly, the outgoing call would start as:
> > INVITE 4125551212@translate.marconi.com
> > From: brian.rosen@sip.marconi.com
> > To: "4125551212@translate.marconi.com"
> > 
> > and the translator would send
> > INVITE port3@gateway2.marconi.com
> > From: "7247426826" <brian.rosen@sip.marconi.com>
> > To: "4125551212@translate.marconi.com"
> > 
> > This is a no-no if the translator is a proxy.  It would have to be
> > a B2BUA. 
> 
> I don't understand why this is not just network asserted ID.
> 
> > So, one question is whether we should indeed force the
> > UAS to know its phone number, so it can construct the From:
> > correctly.  If a UA has multiple "lines", then it actually needs
> > a way to tell the gateway which "line" it wants to use for an
> > outgoing call.  Most systems don't do this, so it's a big deal
> > to make this assumption.
> 
> There is another issue you have been touching on. It relates 
> back to the 
> app components ID that I wrote some time ago 
> (http://www.jdrosen.net/papers/draft-rosenberg-sip-app-compone
> nts-01.txt). 
> Really, a gateway is an application-independent component, 
> just like a 
> conference server or a voicexml server. All of them have the same 
> general problem of how you invoke services on them. For a 
> vxml server, 
> its how to pass the vxml script. For a conference serevr, its how to 
> identify the conference to join. For a gateway, its how to 
> identify the 
> user to call, along with other invocation parameters, such as 
> what port 
> to join.
> 
> What I think you are talking about is that a gateway has several 
> parameters needed for "service invocation" on it, and these need to 
> somehow been standardized. I still believe we are in need of 
> a framework 
> for service invocation in sip, presenting a generic way to name 
> services, discover capabilities, pass parameters, register 
> new services, 
> and so on. That work was discussed in sipping but never took off....
> 
> > I would prefer to make the rules such that the username was
> > the port name.  That allows the port name to be registered, 
> and checked.  
> > That implies the numbers go in the display name.  
> 
> As I point out above, you cannot use the To field display name.
> 
> > We might actually
> > want to specify how tel URIs are used instead of sip URIs.
> > I'm not sure I know what the right thing to do is, because some
> > gateways need that port number.
> > 
> > I'd like to get a new header for the calling party number on
> > an outbound call.  That way, the translator can be a proxy and
> > add the header.  I'd recommend that gateways allow the number
> > to be in the From.   
> 
> As I asked above, why is this bit not the network asserted ID?
> 
> -Jonathan R.
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  2 16:32:57 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14811
	for <sipping-archive@odin.ietf.org>; Thu, 2 Jan 2003 16:32:57 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h02LfNh24320
	for sipping-archive@odin.ietf.org; Thu, 2 Jan 2003 16:41:23 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02LfNJ24317
	for <sipping-web-archive@optimus.ietf.org>; Thu, 2 Jan 2003 16:41:23 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14787
	for <sipping-web-archive@ietf.org>; Thu, 2 Jan 2003 16:32:26 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02LebJ24247;
	Thu, 2 Jan 2003 16:40:37 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02LdTJ24166
	for <sipping@optimus.ietf.org>; Thu, 2 Jan 2003 16:39:29 -0500
Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14731
	for <sipping@ietf.org>; Thu, 2 Jan 2003 16:30:31 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h02LYFRY011217;
	Thu, 2 Jan 2003 16:34:15 -0500 (EST)
Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAX27516;
	Thu, 2 Jan 2003 16:38:37 -0500 (EST)
Message-ID: <3E14B02F.9010307@cisco.com>
Date: Thu, 02 Jan 2003 16:33:35 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
CC: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>,
        "'sipping@ietf.org'" <sipping@ietf.org>
Subject: Re: [Sipping] URIs for Gateways
References: <313680C9A886D511A06000204840E1CF030B5C9E@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Rosen, Brian wrote:
> 
> I'm not really happy with the display name trick, but there are
> lots and lots of gateways that do this.  It works because, as we
> know, To: and From: are never modified.  It's up to normal
> SIP routing to get the INVITE to the right gateway.  When it gets there,
> the display name on the To: should be intact.  

You miss the point. You may have called sip:alice. That call is then 
proxied to a pstn number "1234567890" sip:port@gateway. The proxy can't 
change the To address to put the phone number in. It can't even solve 
the problem with a redirect, because your UAC will probably just change 
the request id and reissue the invite with the old To value.

> 
> However, overloading the display name with the number to dial is
> not a great idea, even if a lot of stuff in the field does it.
> 
> In a prior message, I did agree that P-Asserted-Identity with
> a tel URI could be used for a proxy asserting the translation, 
> but not the "real" NAI stuff (Jon's signed headers).  Do you
> want a BCP to say that P-Asserted-Identity is what translators
> use to get the phone number in the message? 

What you are suggesting seems backward. The P-Asserted-Identity is only 
useful for the calling number, not the called number. Assuming the 
gateway can trust the callerid info it gets from the PSTN, it should be 
inserting a P-Asserted-Identity header with that value for inbound 
calls. And it ought to be using it to generate callerid on outbound 
calls. The kind of translator you describe seems useless for this.

I think the best choice right now for outbound calls is a tel: uri. You 
can pack all sorts of info into it. This can also be represented as a 
sip uri with user=phone. If you want to use a translator, start by 
generating a tel: uri, then route it to the translator, which can turn 
it into a sip uri with user=phone, using the domain name to select the 
actual gateway. It can also fill in extra parameters (defined in the 
tel: uri) in the user part of the sip uri to help the gateway do the 
right thing.

 > The "P-" is a
> problem.  P-Asserted-Identity should go away once the
> signed header idea is fully baked, but this problem stays for
> a very long time.

I don't think the signed header is a replacement for the 
P-Asserted-Identity. Which to use depends on whether you have trusted 
servers in the network that are responsible for some aspects of 
identity. As long as you are interoperating with the PSTN this will 
probably remain as a requirement.

	Paul

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  2 18:33:35 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16957
	for <sipping-archive@odin.ietf.org>; Thu, 2 Jan 2003 18:33:35 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h02Ng4E32451
	for sipping-archive@odin.ietf.org; Thu, 2 Jan 2003 18:42:04 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02Ng4J32448
	for <sipping-web-archive@optimus.ietf.org>; Thu, 2 Jan 2003 18:42:04 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16932
	for <sipping-web-archive@ietf.org>; Thu, 2 Jan 2003 18:33:03 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02NfQJ32401;
	Thu, 2 Jan 2003 18:41:26 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02NeWJ32337
	for <sipping@optimus.ietf.org>; Thu, 2 Jan 2003 18:40:32 -0500
Received: from pmesmtp02.wcom.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16899;
	Thu, 2 Jan 2003 18:31:32 -0500 (EST)
Received: from pmismtp02.wcomnet.com ([166.38.62.37])
 by firewall.wcom.com (Iplanet MTA )
 with ESMTP id <0H84008JI1HU5L@firewall.wcom.com>; Thu,
 02 Jan 2003 23:34:43 +0000 (GMT)
Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com
 (iPlanet Messaging Server 5.1 HotFix 0.7 (built May  7 2002))
 with SMTP id <0H8400F011HURV@pmismtp02.wcomnet.com>; Thu,
 02 Jan 2003 23:34:42 +0000 (GMT)
Received: from hsinnreich2 ([166.42.41.19])
 by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7
 2002)) with ESMTP id <0H8400DCP1HSJ2@pmismtp02.wcomnet.com>; Thu,
 02 Jan 2003 23:34:42 +0000 (GMT)
Date: Thu, 02 Jan 2003 17:34:40 -0600
From: Henry Sinnreich <Henry.Sinnreich@wcom.com>
To: sipping@ietf.org, midcom@ietf.org
Message-id: <000601c2b2b7$864567d0$13292aa6@hsinnreich2>
Organization: WorldCom, Inc.
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1097
X-Mailer: Microsoft Outlook, Build 10.0.3416
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Content-Transfer-Encoding: 7bit
Subject: [Sipping] UPnP and routing updates for SIPPING and MIDCOM I-Ds
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

There is quite a bit of excellent work reflected in all the SIPPING and
MIDCOM I-Ds on NAT and Firewall traversal and some solutions, such as
STUN and TURN.

I believe we need however also updated versions of this work by
enlarging the focus with some other aspects. Here are two examples that
come to my mind, there may be other:

UPnP

Commercial UPnP residential gateways allow UPnP enabled SIP UA to
function well, examples are commercial  wired NAT/FWs and wireless
access points working with some well known softphone clients and SIP
phones. Please see for reference:

http://upnp.org/resources/whitepapers.asp 

After experiencing the true "plug-and-play" nature of the UPnP solution,
I happen to believe it is also a valid enterprise approach as well and
the I-Ds should consider such an enterprise scenario for outsourced and
enterprise services. UPnP gateways have a wider application area since
they will also support collaboration applications that may not be SIP
based, appliances, etc. Along this rationale SIP phones MUST support
UPnP, I believe, see
http://www.ietf.org/internet-drafts/draft-sinnreich-sipdev-req-00.txt .
Some SIP phones already support UPnP.

Both the MIDCOM and Sipping WGs need to come to grips with the reality
of the excellent work done by the UPnP people and document it in an
informational RFC IMHO. Is the architecture as IP-centric and good as it
seems? Are there any issues, such as scalability or security? It appears
UPnP has solved much of the MIDCOM problem space.

Ignoring UPnP by the IETF is not a good option.

Routing 

Solutions in most recent I-D have a single NAT/FW - this often an
unacceptable single point of failure. The drafts need to show solutions
with multiple NAT/FW locations and the routing implications, since all
internal routers need to be aware of the NAT/FWs at the edge of the
enterprise network.

Should this be reflected in updates to the charter of the SIPPING and
MIDCOM WGs as well?

What do you think?

Thanks, Henry

Henry Sinnreich
WorldCom
400 International Parkway
Richardson, Texas 75081
USA



_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  2 18:41:41 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17047
	for <sipping-archive@odin.ietf.org>; Thu, 2 Jan 2003 18:41:41 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h02NoA732751
	for sipping-archive@odin.ietf.org; Thu, 2 Jan 2003 18:50:10 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02NoAJ32748
	for <sipping-web-archive@optimus.ietf.org>; Thu, 2 Jan 2003 18:50:10 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17041
	for <sipping-web-archive@ietf.org>; Thu, 2 Jan 2003 18:41:10 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02Nn6J32713;
	Thu, 2 Jan 2003 18:49:06 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02Nm7J32660
	for <sipping@optimus.ietf.org>; Thu, 2 Jan 2003 18:48:07 -0500
Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17018
	for <sipping@ietf.org>; Thu, 2 Jan 2003 18:39:07 -0500 (EST)
Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h02NepSK010075;
	Thu, 2 Jan 2003 18:40:52 -0500 (EST)
Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <W6F4F09Y>; Thu, 2 Jan 2003 17:42:14 -0600
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A643BE@DYN-TX-EXCH-001.dynamicsoft.com>
From: Adam Roach <adam@dynamicsoft.com>
To: "'Peterson, Jon'" <jon.peterson@neustar.biz>,
        "'Francois Audet'"
	 <audet@nortelnetworks.com>
Cc: "'sipping@ietf.org'" <sipping@ietf.org>
Subject: RE: [Sipping] Re: Meaning of status codes
Date: Thu, 2 Jan 2003 17:42:05 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

<JFP>I also remain a little unsure what the SDP in 180 is meant to
accomplish.</JFP>

I'll provide a strawman.

E.180 defines a "Ringing Tone" to be played to a caller for ringback.

E.180 also defines a "Caller Waiting Tone", which is typically a
concatenation of a ringback tone and a call-waiting tone (for most
locales). It lets the caller know that the called party is on another
call, but is being alerted nonetheless.

(Although not in widespread use for US landline exchanges, I have heard
such a tone when calling certain PBXes and mobile phones).

Arguably, a "180 Ringing" with media, then, has the ability to provide
this additional bit of information to the caller -- so it's not completely
valueless.

/a

(I'm not going to even mention how grateful I am that I've had considerate 
co-workers who, upon calling my GSM phone and hearing, say, a Spanish
ringback tone have thought better of disturbing me at 3 in the morning and
promptly hung up).
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  2 18:46:38 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17121
	for <sipping-archive@odin.ietf.org>; Thu, 2 Jan 2003 18:46:37 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h02Nt7w00487
	for sipping-archive@odin.ietf.org; Thu, 2 Jan 2003 18:55:07 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02Nt7J00484
	for <sipping-web-archive@optimus.ietf.org>; Thu, 2 Jan 2003 18:55:07 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17115
	for <sipping-web-archive@ietf.org>; Thu, 2 Jan 2003 18:46:06 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02NsIJ00460;
	Thu, 2 Jan 2003 18:54:18 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02NriJ00407
	for <sipping@optimus.ietf.org>; Thu, 2 Jan 2003 18:53:44 -0500
Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17105
	for <sipping@ietf.org>; Thu, 2 Jan 2003 18:44:43 -0500 (EST)
Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h02NkVSK010093;
	Thu, 2 Jan 2003 18:46:31 -0500 (EST)
Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <W6F4F096>; Thu, 2 Jan 2003 17:47:54 -0600
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A643BF@DYN-TX-EXCH-001.dynamicsoft.com>
From: Adam Roach <adam@dynamicsoft.com>
To: "'Rohan Mahy'" <rohan@cisco.com>, Paul Kyzivat <pkyzivat@cisco.com>
Cc: "Peterson, Jon" <jon.peterson@neustar.biz>, sipping@ietf.org
Subject: RE: [Sipping] Re: Meaning of status codes
Date: Thu, 2 Jan 2003 17:47:51 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

> From: Rohan Mahy [mailto:rohan@cisco.com]
> >
> > I *think* Rohan is proposing to use UPDATE to move the media stream 
> > for each dialog to a unique port. 
> 
> yes

Why? Differentiation? You can get that from the SSRC.

/a
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  2 21:28:54 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20209
	for <sipping-archive@odin.ietf.org>; Thu, 2 Jan 2003 21:28:53 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h032bRg10871
	for sipping-archive@odin.ietf.org; Thu, 2 Jan 2003 21:37:27 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h032bQJ10852
	for <sipping-web-archive@optimus.ietf.org>; Thu, 2 Jan 2003 21:37:26 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20205
	for <sipping-web-archive@ietf.org>; Thu, 2 Jan 2003 21:28:21 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h032abJ10306;
	Thu, 2 Jan 2003 21:36:37 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h032ZrJ10274
	for <sipping@optimus.ietf.org>; Thu, 2 Jan 2003 21:35:53 -0500
Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20196
	for <sipping@ietf.org>; Thu, 2 Jan 2003 21:26:48 -0500 (EST)
Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44])
	by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id h032TrKv011505;
	Thu, 2 Jan 2003 18:29:53 -0800 (PST)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134])
	by imop.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA)
	with ESMTP id ABM74723;
	Thu, 2 Jan 2003 18:26:47 -0800 (PST)
Date: Thu, 2 Jan 2003 18:29:49 -0800
Subject: Re: [Sipping] Re: Meaning of status codes
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
Cc: Paul Kyzivat <pkyzivat@cisco.com>,
        "Peterson, Jon" <jon.peterson@neustar.biz>, sipping@ietf.org
To: Adam Roach <adam@dynamicsoft.com>
From: Rohan Mahy <rohan@cisco.com>
In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A643BF@DYN-TX-EXCH-001.dynamicsoft.com>
Message-Id: <3B64B710-1EC3-11D7-891B-0003938AF740@cisco.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.551)
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


On Thursday, January 2, 2003, at 03:47 PM, Adam Roach wrote:

>> From: Rohan Mahy [mailto:rohan@cisco.com]
>>>
>>> I *think* Rohan is proposing to use UPDATE to move the media stream
>>> for each dialog to a unique port.
>>
>> yes
>
> Why? Differentiation? You can get that from the SSRC.

As an aside, technically you shouldn't use SSRC to differentiate, 
because the SSRCs could collide.  However this is a one in a million 
style corner case, which I am willing to ignore at the moment.  I am 
much more concerned with correlation than with differentitation.  If 
you get 3 SSRCs, you can't correlate this to a SIP (early) dialog or a 
Contact.  Note that if RTP were symmetric, or if you knew your peers' 
SSRCs through their answer this would not be a problem.

thanks,
-rohan

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Fri Jan  3 01:29:51 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23799
	for <sipping-archive@odin.ietf.org>; Fri, 3 Jan 2003 01:29:50 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h036cSQ23407
	for sipping-archive@odin.ietf.org; Fri, 3 Jan 2003 01:38:28 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h036cSJ23404
	for <sipping-web-archive@optimus.ietf.org>; Fri, 3 Jan 2003 01:38:28 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23789
	for <sipping-web-archive@ietf.org>; Fri, 3 Jan 2003 01:29:19 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h036aEJ22666;
	Fri, 3 Jan 2003 01:36:14 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h036ZLJ22634
	for <sipping@optimus.ietf.org>; Fri, 3 Jan 2003 01:35:21 -0500
Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23767
	for <sipping@ietf.org>; Fri, 3 Jan 2003 01:26:13 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.143])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h036TQYH024729;
	Fri, 3 Jan 2003 01:29:27 -0500 (EST)
Message-ID: <3E152DC4.6020703@dynamicsoft.com>
Date: Fri, 03 Jan 2003 01:29:24 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
CC: "'sipping@ietf.org'" <sipping@ietf.org>
Subject: Re: [Sipping] URIs for Gateways
References: <313680C9A886D511A06000204840E1CF030B5C9E@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

inline.

Rosen, Brian wrote:

> I'm not really happy with the display name trick, but there are
> lots and lots of gateways that do this.  It works because, as we
> know, To: and From: are never modified.  It's up to normal
> SIP routing to get the INVITE to the right gateway.  When it gets there,
> the display name on the To: should be intact.  

Right, but it will be WRONG if the call has been forwarded before 
reaching the gateway. That is, I call you, Brian, and you forward the 
call to a PSTN number. The To display name is YOUR number, when the 
number that the gateway needs to use is the forwarded number.

> In a prior message, I did agree that P-Asserted-Identity with
> a tel URI could be used for a proxy asserting the translation, 
> but not the "real" NAI stuff (Jon's signed headers). 

Why not? They both support assertion of identity; the difference is in 
whether its done through transitive trust or digital signatures.

> I guess I think putting a gateway in the category of a service
> component and designing a new framework for service invocation
> on it is a bit heavy handed given the problem, but I agree that a
> brand new thing can be made to solve any problem.

I think that, as a framework, this particular one can be looked at as 
amazingly complicated or quite simple, depending on how you scope it. 
THe main thing it needs to tackle is to simply declare that these are 
really all the same problem, and to give some general guidelines, 
whether its to use the r-uri for passing parameters (as in rfc3087) or 
whether its in a soap body in the INVITE request.

Anyway, it is our job here in sipping to look at the broader issues with 
any problem, is it not? I think that viewing these as the same is at 
least worthy of discussion.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Fri Jan  3 03:54:27 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05367
	for <sipping-archive@odin.ietf.org>; Fri, 3 Jan 2003 03:54:27 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h03939Z09547
	for sipping-archive@odin.ietf.org; Fri, 3 Jan 2003 04:03:09 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03939J09544
	for <sipping-web-archive@optimus.ietf.org>; Fri, 3 Jan 2003 04:03:09 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05364
	for <sipping-web-archive@ietf.org>; Fri, 3 Jan 2003 03:53:56 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0391wJ09229;
	Fri, 3 Jan 2003 04:01:58 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0390RJ09140
	for <sipping@optimus.ietf.org>; Fri, 3 Jan 2003 04:00:27 -0500
Received: from gbnewp0915s1.eu.ubiquity.net (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA05320
	for <sipping@ietf.org>; Fri, 3 Jan 2003 03:51:14 -0500 (EST)
Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net
          via smtpd (for [132.151.6.1]) with SMTP; 3 Jan 2003 08:53:34 UT
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Sipping] Re: Meaning of status codes
Date: Fri, 3 Jan 2003 08:54:27 -0000
Message-ID: <45730E094814E44488F789C1CDED27AE018C2584@GBNEWP0758M.eu.ubiquity.net>
Thread-Topic: [Sipping] Re: Meaning of status codes
Thread-Index: AcKyuL4bcctkPu8MR7qoJdTX0LTcgwATKS8w
From: "James Undery" <jundery@ubiquity.net>
To: "Adam Roach" <adam@dynamicsoft.com>,
        "Peterson, Jon" <jon.peterson@neustar.biz>,
        "Francois Audet" <audet@nortelnetworks.com>
Cc: <sipping@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0390RJ09141
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

Hmm "Caller Waiting Tone" shouldn't this be 182 Queued, but then again I've no idea about E.180

James

> -----Original Message-----
> From: Adam Roach [mailto:adam@dynamicsoft.com]
> Sent: 02 January 2003 23:42
> To: 'Peterson, Jon'; 'Francois Audet'
> Cc: 'sipping@ietf.org'
> Subject: RE: [Sipping] Re: Meaning of status codes
> 
> 
> <JFP>I also remain a little unsure what the SDP in 180 is meant to
> accomplish.</JFP>
> 
> I'll provide a strawman.
> 
> E.180 defines a "Ringing Tone" to be played to a caller for ringback.
> 
> E.180 also defines a "Caller Waiting Tone", which is typically a
> concatenation of a ringback tone and a call-waiting tone (for most
> locales). It lets the caller know that the called party is on another
> call, but is being alerted nonetheless.
> 
> (Although not in widespread use for US landline exchanges, I 
> have heard
> such a tone when calling certain PBXes and mobile phones).
> 
> Arguably, a "180 Ringing" with media, then, has the ability to provide
> this additional bit of information to the caller -- so it's 
> not completely
> valueless.
> 
> /a
> 
> (I'm not going to even mention how grateful I am that I've 
> had considerate 
> co-workers who, upon calling my GSM phone and hearing, say, a Spanish
> ringback tone have thought better of disturbing me at 3 in 
> the morning and
> promptly hung up).
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Fri Jan  3 10:52:22 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11697
	for <sipping-archive@odin.ietf.org>; Fri, 3 Jan 2003 10:52:22 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h03G1CA01790
	for sipping-archive@odin.ietf.org; Fri, 3 Jan 2003 11:01:12 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03G1CJ01787
	for <sipping-web-archive@optimus.ietf.org>; Fri, 3 Jan 2003 11:01:12 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11680
	for <sipping-web-archive@ietf.org>; Fri, 3 Jan 2003 10:51:50 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03G0BJ01664;
	Fri, 3 Jan 2003 11:00:11 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03FvLJ01469
	for <sipping@optimus.ietf.org>; Fri, 3 Jan 2003 10:57:21 -0500
Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11417
	for <sipping@ietf.org>; Fri, 3 Jan 2003 10:47:59 -0500 (EST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA18210;
	Fri, 3 Jan 2003 10:51:10 -0500 (EST)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA11278;
	Fri, 3 Jan 2003 10:51:12 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <ZVACH58F>; Fri, 3 Jan 2003 10:51:11 -0500
Message-ID: <313680C9A886D511A06000204840E1CF030B5CA5@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Paul Kyzivat'" <pkyzivat@cisco.com>
Cc: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>,
        "'sipping@ietf.org'"
	 <sipping@ietf.org>
Subject: RE: [Sipping] URIs for Gateways
Date: Fri, 3 Jan 2003 10:51:07 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

Hmm, well, another case of explain the problem and you often solve
it yourself.
> You miss the point. You may have called sip:alice. That call is then 
> proxied to a pstn number "1234567890" sip:port@gateway. The 
> proxy can't 
> change the To address to put the phone number in. It can't even solve 
> the problem with a redirect, because your UAC will probably 
> just change 
> the request id and reissue the invite with the old To value.
I'll agree that if you called alice, and it got proxied to 1234567890
then the proxy can't change the To:.  On the other hand, all the proxy
can do is to change the Request URI, and that doesn't have a display
name, so you can't actually proxy to "1234567890" sip:port@gateway
You can proxy to a Tel URI, which has a phone number, but does
not have the port and gateway.  However, point taken.

> > In a prior message, I did agree that P-Asserted-Identity with
> > a tel URI could be used for a proxy asserting the translation, 
> > but not the "real" NAI stuff (Jon's signed headers).  Do you
> > want a BCP to say that P-Asserted-Identity is what translators
> > use to get the phone number in the message? 
> 
> What you are suggesting seems backward. The 
> P-Asserted-Identity is only 
> useful for the calling number, not the called number. Assuming the 
> gateway can trust the callerid info it gets from the PSTN, it 
> should be 
> inserting a P-Asserted-Identity header with that value for inbound 
> calls. And it ought to be using it to generate callerid on outbound 
> calls. The kind of translator you describe seems useless for this.
Let's start with inbound calls.  The gateway has calling and called
numbers, it may have a calledId name.  If it has mapping, it has the
sip URI of the intended recipient.  I now see that this works:

The text of 3325 talks about asserting the identity of the entity
the message is from.  For an inbound call, this is really the gateway,
but in this case, I think we would assume that we would use it for
the calling party identity as you say.  Two of them can be used to get
both the number and the name.  The Request URI, if the gateway
has mapping, could be the end UAS, but if it doesn't, either it has to be
a translator URI, or it just sends it with a tel URI, and the proxies
handle it.  The gateway could use a tel URI as the From field which
would be the called party number, but it would have to get the port
number in as a parameter to the tel URI because if translation is
needed, that information is essential to the translation.
If the gateway doesn't have translation, the translator takes the
called party from the Request URI, or if necessary, the From:
and changes the Request URI to the sip URI of the UAS.  Okay,
that works.  Never saw a gateway that came even close to it (okay,
well I've seen some gateways take a tel uri in the Request URI 
for the calling number), but it seems to work.

On outgoing calls, the originating UAC could construct a tel URI, 
or a phone number@gateway sip uri for the Request URI and To: and 
it would clearly put it's sip URI, not it's phone number in the From. 
If there was a translator, it would put a P-Asserted-Identity of the
From (the sip UAC) as a phone number (and name if it wanted).  
It would have to add the port number to the Request URI as a parameter
to the tel URI and forward it to the gateway.  I guess the UAC could 
put the P-Asserted-Identity in the original INVITE just like the gateway
does if there is no translator.  I'm not sure I understand how
routing is done if the proxy that knows which gateway is associated
with the user's line (or destination phone number if that's the routing
decision) would construct a Request URI with the port@gateway 
addressing and still keep the number to dial.  That means the
routing gateway has to be next-to-last proxy in the path, which is
clearly not always true. 


> 
> I think the best choice right now for outbound calls is a 
> tel: uri. You 
> can pack all sorts of info into it. This can also be represented as a 
> sip uri with user=phone. If you want to use a translator, start by 
> generating a tel: uri, then route it to the translator, which 
> can turn 
> it into a sip uri with user=phone, using the domain name to 
> select the 
> actual gateway. It can also fill in extra parameters (defined in the 
> tel: uri) in the user part of the sip uri to help the gateway do the 
> right thing.
> 
>  > The "P-" is a
> > problem.  P-Asserted-Identity should go away once the
> > signed header idea is fully baked, but this problem stays for
> > a very long time.
> 
> I don't think the signed header is a replacement for the 
> P-Asserted-Identity. Which to use depends on whether you have trusted 
> servers in the network that are responsible for some aspects of 
> identity. As long as you are interoperating with the PSTN this will 
> probably remain as a requirement.
Probably not the thread for a discussion like this, but it does seem
to me that the "right" way we want to move to is to have the UAC set
identity correctly, and have the trusted proxy sign it to authenticate
it.  I think there is then no reason to keep P-Asserted-Identity for
any NAI application, including 3G and PSTN interwork.  The only
thing that won't do is allow the "trusted" network to have some
identity that the UAC is unaware of.  I don't think that is a good
plan although you still need the phone number AND the UAC sip uri,
which is what we are really talking about, so the P-A-I morphs
into a UAC (or local, untrusted, proxy) thing, and not a trusted
proxy thing, and the trusted proxy signs it, authenticating it.

Brian
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Fri Jan  3 11:21:08 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12202
	for <sipping-archive@odin.ietf.org>; Fri, 3 Jan 2003 11:21:07 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h03GTvi03742
	for sipping-archive@odin.ietf.org; Fri, 3 Jan 2003 11:29:57 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03GTuJ03737
	for <sipping-web-archive@optimus.ietf.org>; Fri, 3 Jan 2003 11:29:56 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12199
	for <sipping-web-archive@ietf.org>; Fri, 3 Jan 2003 11:20:36 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03GSYJ03676;
	Fri, 3 Jan 2003 11:28:34 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03GQjJ03583
	for <sipping@optimus.ietf.org>; Fri, 3 Jan 2003 11:26:45 -0500
Received: from auemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12114
	for <sipping@ietf.org>; Fri, 3 Jan 2003 11:17:25 -0500 (EST)
Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57])
	by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h03GKYJ19346
	for <sipping@ietf.org>; Fri, 3 Jan 2003 11:20:34 -0500 (EST)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19)
	id <XNTA53N4>; Fri, 3 Jan 2003 16:20:33 -0000
Message-ID: <475FF955A05DD411980D00508B6D5FB006FFB401@en0033exch001u.uk.lucent.com>
From: "Drage, Keith (Keith)" <drage@lucent.com>
To: Paul Kyzivat <pkyzivat@cisco.com>,
        "Rosen, Brian"
	 <Brian.Rosen@marconi.com>
Cc: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>,
        "'sipping@ietf.org'"
	 <sipping@ietf.org>
Subject: RE: [Sipping] URIs for Gateways
Date: Fri, 3 Jan 2003 16:20:28 -0000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

See inline

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: drage@lucent.com 

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: 02 January 2003 21:34
> To: Rosen, Brian
> Cc: 'Jonathan Rosenberg'; 'sipping@ietf.org'
> Subject: Re: [Sipping] URIs for Gateways
> 
> 
> Rosen, Brian wrote:
> > 
> > I'm not really happy with the display name trick, but there are
> > lots and lots of gateways that do this.  It works because, as we
> > know, To: and From: are never modified.  It's up to normal
> > SIP routing to get the INVITE to the right gateway.  When 
> it gets there,
> > the display name on the To: should be intact.  
> 
> You miss the point. You may have called sip:alice. That call is then 
> proxied to a pstn number "1234567890" sip:port@gateway. The 
> proxy can't 
> change the To address to put the phone number in. It can't even solve 
> the problem with a redirect, because your UAC will probably 
> just change 
> the request id and reissue the invite with the old To value.
> 
> > 
> > However, overloading the display name with the number to dial is
> > not a great idea, even if a lot of stuff in the field does it.
> > 
> > In a prior message, I did agree that P-Asserted-Identity with
> > a tel URI could be used for a proxy asserting the translation, 
> > but not the "real" NAI stuff (Jon's signed headers).  Do you
> > want a BCP to say that P-Asserted-Identity is what translators
> > use to get the phone number in the message? 
> 
> What you are suggesting seems backward. The 
> P-Asserted-Identity is only 
> useful for the calling number, not the called number. Assuming the 
> gateway can trust the callerid info it gets from the PSTN, it 
> should be 
> inserting a P-Asserted-Identity header with that value for inbound 
> calls. And it ought to be using it to generate callerid on outbound 
> calls. The kind of translator you describe seems useless for this.

Why is the P-Asserted-Identity only useful for calling number. It is perfectly valid in responses to INVITE. Obviously you still need to meet the requirements of having a first proxy to assert the identity, but that does exist in certain architectures, e.g. 3GPP, and the mechanisms to identify and include such a proxy are standards track items.

> 
> I think the best choice right now for outbound calls is a 
> tel: uri. You 
> can pack all sorts of info into it. This can also be represented as a 
> sip uri with user=phone. If you want to use a translator, start by 
> generating a tel: uri, then route it to the translator, which 
> can turn 
> it into a sip uri with user=phone, using the domain name to 
> select the 
> actual gateway. It can also fill in extra parameters (defined in the 
> tel: uri) in the user part of the sip uri to help the gateway do the 
> right thing.
> 
>  > The "P-" is a
> > problem.  P-Asserted-Identity should go away once the
> > signed header idea is fully baked, but this problem stays for
> > a very long time.
> 
> I don't think the signed header is a replacement for the 
> P-Asserted-Identity. Which to use depends on whether you have trusted 
> servers in the network that are responsible for some aspects of 
> identity. As long as you are interoperating with the PSTN this will 
> probably remain as a requirement.

I have commented on this in another mail. I support Paul on this. They are two different solutions and their usage depends on the network architecture that you are working with.

> 
> 	Paul
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Fri Jan  3 11:22:19 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12240
	for <sipping-archive@odin.ietf.org>; Fri, 3 Jan 2003 11:22:19 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h03GV8D03891
	for sipping-archive@odin.ietf.org; Fri, 3 Jan 2003 11:31:08 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03GV8J03888
	for <sipping-web-archive@optimus.ietf.org>; Fri, 3 Jan 2003 11:31:08 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12236
	for <sipping-web-archive@ietf.org>; Fri, 3 Jan 2003 11:21:48 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03GU3J03779;
	Fri, 3 Jan 2003 11:30:03 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03GQkJ03587
	for <sipping@optimus.ietf.org>; Fri, 3 Jan 2003 11:26:46 -0500
Received: from auemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12116
	for <sipping@ietf.org>; Fri, 3 Jan 2003 11:17:26 -0500 (EST)
Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57])
	by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h03GKaJ19362
	for <sipping@ietf.org>; Fri, 3 Jan 2003 11:20:36 -0500 (EST)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19)
	id <XNTA53NV>; Fri, 3 Jan 2003 16:20:33 -0000
Message-ID: <475FF955A05DD411980D00508B6D5FB006FFB400@en0033exch001u.uk.lucent.com>
From: "Drage, Keith (Keith)" <drage@lucent.com>
To: "Rosen, Brian" <Brian.Rosen@marconi.com>,
        "'Henning Schulzrinne'"
	 <hgs@cs.columbia.edu>
Cc: "'sipping@ietf.org'" <sipping@ietf.org>
Subject: RE: [Sipping] URIs for Gateways
Date: Fri, 3 Jan 2003 16:20:26 -0000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

Network asserted identity (RFC 3325) is the real network asserted identity. It is a P header not because it is preliminary, but because the whole idea of network assertion is not generally applicable to all SIP architectures. For RFC 3325 a trust domain needs to exist between proxies that use the P-Asserted-Identity in order to guarantee the privacy, this does not exist in all SIP networks. In does in 3GPP and therefore 3GPP are using RFC 3325.

If you want to let the 1et outbound proxy assert identity on your behalf then use RFC 3325. If you want to let application servers with whom you have a secure relationship assert your identity, then use Jon Petersons drafts, when they eventually become RFCs. 

One is not a short term solution for the other.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: drage@lucent.com 

> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: 02 January 2003 20:49
> To: 'Henning Schulzrinne'
> Cc: 'sipping@ietf.org'
> Subject: RE: [Sipping] URIs for Gateways
> 
> 
> Yeah, I actually thought of just allowing a display name in the
> Request URI and using that, but it seems so foolish to make a change,
> and have that change not be exactly what we needed.
> 
> We could use NAI.  I suppose we could use a P-Asserted-Identity
> with a tel URI:  
> P-Asserted-Identity tel:+17247426826
> 
> What do we do when the "real" NAI happens?
> 
> Brian
> 
> > -----Original Message-----
> > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> > Sent: Thursday, January 02, 2003 3:10 PM
> > To: Rosen, Brian
> > Cc: 'sipping@ietf.org'
> > Subject: Re: [Sipping] URIs for Gateways
> > 
> > 
> > > I'd like to get a new header for the calling party number on
> > > an outbound call.  That way, the translator can be a proxy and
> > > add the header.  I'd recommend that gateways allow the number
> > > to be in the From.   
> > 
> > Generalized, you want something like the Request-URI that can be 
> > modified or inserted. How about the NAI stuff?
> > 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Fri Jan  3 13:50:29 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16058
	for <sipping-archive@odin.ietf.org>; Fri, 3 Jan 2003 13:50:29 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h03IxMs15736
	for sipping-archive@odin.ietf.org; Fri, 3 Jan 2003 13:59:22 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03IxMJ15730
	for <sipping-web-archive@optimus.ietf.org>; Fri, 3 Jan 2003 13:59:22 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16033
	for <sipping-web-archive@ietf.org>; Fri, 3 Jan 2003 13:49:58 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03IwKJ15653;
	Fri, 3 Jan 2003 13:58:20 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03IvwJ15624
	for <sipping@optimus.ietf.org>; Fri, 3 Jan 2003 13:57:58 -0500
Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15962
	for <sipping@ietf.org>; Fri, 3 Jan 2003 13:48:34 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h03IqI6H011817;
	Fri, 3 Jan 2003 13:52:18 -0500 (EST)
Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAX31871;
	Fri, 3 Jan 2003 13:56:39 -0500 (EST)
Message-ID: <3E15DBB9.8030208@cisco.com>
Date: Fri, 03 Jan 2003 13:51:37 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Drage, Keith (Keith)" <drage@lucent.com>
CC: "Rosen, Brian" <Brian.Rosen@marconi.com>,
        "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>,
        "'sipping@ietf.org'" <sipping@ietf.org>
Subject: Re: [Sipping] URIs for Gateways
References: <475FF955A05DD411980D00508B6D5FB006FFB401@en0033exch001u.uk.lucent.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Drage, Keith (Keith) wrote:
> 
>>What you are suggesting seems backward. The 
>>P-Asserted-Identity is only 
>>useful for the calling number, not the called number. Assuming the 
>>gateway can trust the callerid info it gets from the PSTN, it 
>>should be 
>>inserting a P-Asserted-Identity header with that value for inbound 
>>calls. And it ought to be using it to generate callerid on outbound 
>>calls. The kind of translator you describe seems useless for this.
> 
> 
> Why is the P-Asserted-Identity only useful for calling number.
> It is perfectly valid in responses to INVITE.
> Obviously you still need to meet the requirements of having a
> first proxy to assert the identity, but that does exist in certain
> architectures, e.g. 3GPP, and the mechanisms to identify and
> include such a proxy are standards track items.

Sorry - I wasn't specific enough. It seemed that Brian was trying to use 
P-Asserted-Identity in a *request* to identify the *called* number. But 
NAI in the request can only identify who is calling. This is what seemed 
backward to me.

	Paul

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Fri Jan  3 14:29:50 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17237
	for <sipping-archive@odin.ietf.org>; Fri, 3 Jan 2003 14:29:50 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h03Jci319565
	for sipping-archive@odin.ietf.org; Fri, 3 Jan 2003 14:38:44 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03JciJ19562
	for <sipping-web-archive@optimus.ietf.org>; Fri, 3 Jan 2003 14:38:44 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17222
	for <sipping-web-archive@ietf.org>; Fri, 3 Jan 2003 14:29:18 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03JbNJ19292;
	Fri, 3 Jan 2003 14:37:23 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03JaLJ18860
	for <sipping@optimus.ietf.org>; Fri, 3 Jan 2003 14:36:21 -0500
Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17178
	for <sipping@ietf.org>; Fri, 3 Jan 2003 14:26:56 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h03JUeCD017379;
	Fri, 3 Jan 2003 14:30:41 -0500 (EST)
Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAX32223;
	Fri, 3 Jan 2003 14:35:02 -0500 (EST)
Message-ID: <3E15E4B8.1080905@cisco.com>
Date: Fri, 03 Jan 2003 14:30:00 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
CC: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>,
        "'sipping@ietf.org'" <sipping@ietf.org>
Subject: Re: [Sipping] URIs for Gateways
References: <313680C9A886D511A06000204840E1CF030B5CA5@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Brian,

Some of your comments seem so confusing to me that I think I must be 
misunderstanding them in some fundamental way.

Are you talking about a situation where a particular port on a gateway 
is intended to map 1:1 to a particular phone number in the PSTN and to a 
particular sip uri in the sip network? (To be specific, lets call these 
+1-987-654-3210, sip:foo@bar.com, sip:port3@gw.bar.com.)

Do you then want take all outbound calls to the pstn from sip:foo@bar to 
be routed thru sip:port3@gw.bar.com, and all inbound calls from the pstn 
to arrive at port3 on the gateway and then be sent to sip:foo@bar.com?

If the above are true, do you then want to put knowledge of these 
mappings in your translator proxy rather than in the gateway?

Under those assumptions, I can start to make some sense of your 
comments. If the gw always sends inbound calls from the pstn to the 
translator, putting the port address (sip:port2@gw.bar.com) in the From 
header, then I suppose the translator could use the from address to map 
sip:port3@gw.bar.com to sip:foo@bar.com.

But it seems like an odd thing to do. It would make way more sense to me 
in this case for the gw to put tel:+1-987-654-3210 in the To and request 
addresses, and then send the request to the translator. The translator 
could then look that up and forward the request to sip:foo@bar.com.

Going the other way - a call from sip:foo@bar.com to some phone number 
in the pstn (e.g. +1-789-456-0123), I would expect the UAC to put its 
own address in the From, and a tel: uri in the To and request uris. Then 
it would probably deliver this to the translator. The translator would 
look up +1-789-456-0123,  and discover it isn't in the sip network and 
so must be in the pstn. Given the assumptions I think you are making, it 
would then decide it must route this call to the gateway port associated 
with the caller. So it would look up the From address (sip:foo@bar.com) 
and translate it to a gateway address (sip:port3@gw.bar.com) and forward 
the request there. But that breaks down, because the gw has no good way 
to learn called number.

This simplest answer I can see to this is for the translator to simply 
translate the From address to the FQDN of the gateway, and then to use 
that to convert the request address from tel: format to sip format: 
<sip:+1-789-456-0123@gw.bar.com;user=phone> and also insert an NAI of 
the caller as tel:+1-987-654-3210. This gets the call to the right 
gateway with the necessary information. It would be up to the gateway to 
figure out that calls from NAI tel:+1-987-654-3210 should use port3.

Further comments inline below.

	Paul

Rosen, Brian wrote:
> 
> Let's start with inbound calls.  The gateway has calling and called
> numbers, it may have a calledId name.  If it has mapping, it has the
> sip URI of the intended recipient.  I now see that this works:
> 
> The text of 3325 talks about asserting the identity of the entity
> the message is from.  For an inbound call, this is really the gateway,
> but in this case, I think we would assume that we would use it for
> the calling party identity as you say.  Two of them can be used to get
> both the number and the name.  The Request URI, if the gateway
> has mapping, could be the end UAS, but if it doesn't, either it has to be
> a translator URI, or it just sends it with a tel URI, and the proxies
> handle it. 

The last makes the most sense to me.

> The gateway could use a tel URI as the From field which
> would be the called party number,
                ^^^^^^
                calling???

I hope this was a typo. Why would you put the *called* number in the 
 From field?

> but it would have to get the port
> number in as a parameter to the tel URI because if translation is
> needed, that information is essential to the translation.

Why? It would be a lot simpler if the gw at least knew, or could get, 
the phone number corresponding to each port, so it can form a tel: uri 
to use as the To address. Then the translator will have something useful 
to work from.

> If the gateway doesn't have translation, the translator takes the
> called party from the Request URI, or if necessary, the From:
                                                           ^^^^^
                                                           ?????
The above is still worrying me.

> and changes the Request URI to the sip URI of the UAS.  Okay,
> that works.  Never saw a gateway that came even close to it (okay,
> well I've seen some gateways take a tel uri in the Request URI 
> for the calling number), but it seems to work.
> 
> On outgoing calls, the originating UAC could construct a tel URI, 
> or a phone number@gateway sip uri for the Request URI and To: and 
> it would clearly put it's sip URI, not it's phone number in the From. 
> If there was a translator, it would put a P-Asserted-Identity of the
>>From (the sip UAC) as a phone number (and name if it wanted).  

Tat seems ok.

> It would have to add the port number to the Request URI as a parameter
> to the tel URI and forward it to the gateway. 

See above for a way to finesse this.

 > I guess the UAC could
> put the P-Asserted-Identity in the original INVITE just like the gateway
> does if there is no translator.  I'm not sure I understand how
> routing is done if the proxy that knows which gateway is associated
> with the user's line (or destination phone number if that's the routing
> decision) would construct a Request URI with the port@gateway 
> addressing and still keep the number to dial.  That means the
> routing gateway has to be next-to-last proxy in the path, which is
> clearly not always true. 

Possible answer above.

> Probably not the thread for a discussion like this, but it does seem
> to me that the "right" way we want to move to is to have the UAC set
> identity correctly, and have the trusted proxy sign it to authenticate
> it.  I think there is then no reason to keep P-Asserted-Identity for
> any NAI application, including 3G and PSTN interwork.  The only
> thing that won't do is allow the "trusted" network to have some
> identity that the UAC is unaware of.  I don't think that is a good
> plan although you still need the phone number AND the UAC sip uri,
> which is what we are really talking about, so the P-A-I morphs
> into a UAC (or local, untrusted, proxy) thing, and not a trusted
> proxy thing, and the trusted proxy signs it, authenticating it.

I'm not confident that I understand all the issues yet. Jon's proposal 
seems pretty heavyweight - so I am not yet confident that it can be a 
total solution on its own. Also, I think as long as we have to deal with 
the PSTN, which assumes trusted network components, we may continue to 
need the NAI approach. But maybe not.

	Paul

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Fri Jan  3 22:16:17 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24444
	for <sipping-archive@odin.ietf.org>; Fri, 3 Jan 2003 22:16:17 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h043PLM11904
	for sipping-archive@odin.ietf.org; Fri, 3 Jan 2003 22:25:21 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h043PLJ11901
	for <sipping-web-archive@optimus.ietf.org>; Fri, 3 Jan 2003 22:25:21 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24440
	for <sipping-web-archive@ietf.org>; Fri, 3 Jan 2003 22:15:36 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h043OSJ11849;
	Fri, 3 Jan 2003 22:24:28 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h043NSJ11815
	for <sipping@optimus.ietf.org>; Fri, 3 Jan 2003 22:23:28 -0500
Received: from mtiwmhc12.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24410
	for <sipping@ietf.org>; Fri, 3 Jan 2003 22:13:53 -0500 (EST)
Received: from cs.columbia.edu ([12.85.3.253])
          by mtiwmhc12.worldnet.att.net
          (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP
          id <20030104031706.UKVL12483.mtiwmhc12.worldnet.att.net@cs.columbia.edu>;
          Sat, 4 Jan 2003 03:17:06 +0000
Message-ID: <3E1651A1.2030207@cs.columbia.edu>
Date: Fri, 03 Jan 2003 22:14:41 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Hammer <mhammer@cisco.com>
CC: sipping@ietf.org
Subject: Re: [Sipping] Re: Comments on revised 'sos' draft
References: <4.3.2.7.2.20021223165256.00b2de58@cia.cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

I agree with Mike. I don't want to require that a SIP UA has to use a 
specific "local" outbound proxy, for example, but it may do so as a 
performance optimization. The local outbound proxy can and should 
recognize the local emergency number (in addition to 'sos') - that's 
fairly trivial. There isn't really anything much the terminal (UA) needs 
to do special in that case. (Possible exception: if the terminal 
normally ignores the outbound proxy, it might decide not to in an 
emergency. That seems a stretch since ignoring the outbound proxy is 
likely to have you run smack into the firewall.)

The draft already says

Outbound proxy servers {\MUST} be
configurable to recognize additional local emergency numbers.

What other special actions does the *terminal* need to perform in case 
of emergency?

Michael Hammer wrote:
> Mike,
> 
> Before a "terminal" can handle the local dial plan, it must first 
> determine what "local" is.  It is still not clear to me how that is 
> going to occur.
> 
> The terminal may be able to handle a number input by the end-user and 
> formulate a request, but then it may need to rely on a nearby proxy 
> which is more fixed and knowledgeable of what local is and route 
> accordingly.  But, this may depend on the topology of the network and 
> its relationship to geography and jurisdictional boundaries.
> 
> Mike
> 
> 
> At 03:11 PM 12/23/2002 -0500, Mpierce1@aol.com wrote:
> 
>> In a message dated 12/21/2002 12:06:10 AM Eastern Standard Time, 
>> hgs@cs.columbia.edu writes:
>>
>>
>>> That's why I argued that incorporating all local numbers is not feasible
>>> nor desirable. I'm still undecided whether favoring 112 or 911 is a good
>>> idea (I suspect it may not be since it's hard to draw the line).
>>
>>
>>
>>
>> [MAP] I think there is still confusion here. Of course, a device can 
>> not "incorporate" all local numbers. My comment was that it must 
>> "handle" all local numbers (where the primary discussion at the moment 
>> is regarding emergency numbers). If this is claiming to lead to an 
>> "international standard", then it can not "favor" 112 or 911. While 
>> "SOS" itself could be a good idea, perhaps the discussion and draft 
>> should be separated from the more general, complex issue of 
>> recognition by a terminal of the local dial plan. Maybe just a 
>> statement to the effect that "besides handling the "SOS" as defined in 
>> this note, a terminal must correctly handle the local dial plan, 
>> including the appropriate emergency number(s), which is not described 
>> here".
>>
>> Mike Pierce
>> Artel
> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Fri Jan  3 22:33:49 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24630
	for <sipping-archive@odin.ietf.org>; Fri, 3 Jan 2003 22:33:49 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h043grj13016
	for sipping-archive@odin.ietf.org; Fri, 3 Jan 2003 22:42:53 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h043grJ13013
	for <sipping-web-archive@optimus.ietf.org>; Fri, 3 Jan 2003 22:42:53 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24627
	for <sipping-web-archive@ietf.org>; Fri, 3 Jan 2003 22:33:18 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h043gCJ12994;
	Fri, 3 Jan 2003 22:42:12 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h043fhJ12962
	for <sipping@optimus.ietf.org>; Fri, 3 Jan 2003 22:41:43 -0500
Received: from mtiwmhc11.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24612
	for <sipping@ietf.org>; Fri, 3 Jan 2003 22:32:08 -0500 (EST)
Received: from cs.columbia.edu ([12.85.3.253])
          by mtiwmhc11.worldnet.att.net
          (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP
          id <20030104033520.YWYP9286.mtiwmhc11.worldnet.att.net@cs.columbia.edu>;
          Sat, 4 Jan 2003 03:35:20 +0000
Message-ID: <3E1655E8.4060308@cs.columbia.edu>
Date: Fri, 03 Jan 2003 22:32:56 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
CC: "'James.Hamlin@RNID.org.uk'" <James.Hamlin@RNID.org.uk>, sipping@ietf.org
Subject: Re: [Sipping] Authentication issues with emergency and other serv
 ices
References: <313680C9A886D511A06000204840E1CF030B5C65@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit



Rosen, Brian wrote:
> Well, the basic problem is that you need a global PKI to
> have the signature of the signer verified.  That is
> a hard problem no one has solved.  You might be able to
> provide some traceability using the P-asserted-identity
> header, or the subsequent work Jon Peterson has proposed.
> That would imply that there is a trusted service provider,
> and it wouldn't give you any information about the network
> beyond the "demarc".

Also, as long as identities are cheap, even a client-level PKI doesn't 
really help all that much. We already have SIP services where you can 
get a SIP identity without identifying yourself beyond possibly a 
throw-away email address. You would effectively need a 'bonded' SIP 
address. This might be useful for spam prevention, too, but it's even 
harder here since while one can easily refuse to receive 
un-authenticated email, it's not generally legally possible or desirable 
to refuse unauthenticated emergency calls.

> 
> We have talked about the other side of that problem = 
> authenticating that the caller is talking to a bona fide
> PSAP.  Even that is seen as an impossibly hard problem =
> getting all PSAPs to get a cert signed by a global PSAP
> CA.

To amplify: the typical SSL cert from Thawte or Verisign wouldn't do 
much good here. You need somebody to provide a certificate that 
psap.sometown.ny.us is indeed a PSAP and not the Pseudo-Service Agency 
imPersonator. Things would be somewhat easier if ICANN created another 
restricted top-level domain similar to .museum, but I know of no such plans.

> 
> Brian
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Fri Jan  3 22:49:48 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24881
	for <sipping-archive@odin.ietf.org>; Fri, 3 Jan 2003 22:49:48 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h043wqR13558
	for sipping-archive@odin.ietf.org; Fri, 3 Jan 2003 22:58:52 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h043wqJ13555
	for <sipping-web-archive@optimus.ietf.org>; Fri, 3 Jan 2003 22:58:52 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24871
	for <sipping-web-archive@ietf.org>; Fri, 3 Jan 2003 22:49:16 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h043wAJ13532;
	Fri, 3 Jan 2003 22:58:10 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h043v2J13473
	for <sipping@optimus.ietf.org>; Fri, 3 Jan 2003 22:57:02 -0500
Received: from mtiwmhc12.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24811
	for <sipping@ietf.org>; Fri, 3 Jan 2003 22:47:26 -0500 (EST)
Received: from cs.columbia.edu ([12.85.3.253])
          by mtiwmhc12.worldnet.att.net
          (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP
          id <20030104035039.VBNC12483.mtiwmhc12.worldnet.att.net@cs.columbia.edu>;
          Sat, 4 Jan 2003 03:50:39 +0000
Message-ID: <3E16597E.3070203@cs.columbia.edu>
Date: Fri, 03 Jan 2003 22:48:14 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
CC: "'James.Hamlin@RNID.org.uk'" <James.Hamlin@RNID.org.uk>, sipping@ietf.org
Subject: Re: [Sipping] Authentication issues with emergency and other serv
 ices
References: <313680C9A886D511A06000204840E1CF030B5C65@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

One additional comment: even with a global PKI, the caller would need to 
be able to reliably determine the public key of the specific PSAP. There 
doesn't seem to be a way to do this at this point, without adding a lot 
of non-standard signaling exchanges. (The caller would have to place an 
unencrypted call to get back a signed response or use OPTIONS, as 
proposed by Cullen, presumably without any location or other 
privacy-relevant content, and then re-issue the request. This seems 
likely to add multiple seconds to the call setup time. Unless there is a 
recognizable name or some other certificate extension, this doesn't 
really help much.)


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Fri Jan  3 23:12:00 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25135
	for <sipping-archive@odin.ietf.org>; Fri, 3 Jan 2003 23:12:00 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h044L5r15002
	for sipping-archive@odin.ietf.org; Fri, 3 Jan 2003 23:21:05 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h044L5J14996
	for <sipping-web-archive@optimus.ietf.org>; Fri, 3 Jan 2003 23:21:05 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25122
	for <sipping-web-archive@ietf.org>; Fri, 3 Jan 2003 23:11:27 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h044KLJ14946;
	Fri, 3 Jan 2003 23:20:21 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h044JaJ14890
	for <sipping@optimus.ietf.org>; Fri, 3 Jan 2003 23:19:36 -0500
Received: from mtiwmhc12.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25089
	for <sipping@ietf.org>; Fri, 3 Jan 2003 23:10:00 -0500 (EST)
Received: from cs.columbia.edu ([12.85.3.253])
          by mtiwmhc12.worldnet.att.net
          (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP
          id <20030104041312.VLJK12483.mtiwmhc12.worldnet.att.net@cs.columbia.edu>;
          Sat, 4 Jan 2003 04:13:12 +0000
Message-ID: <3E165EC7.6090107@cs.columbia.edu>
Date: Fri, 03 Jan 2003 23:10:47 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: William Marshall <wtm@research.att.com>
CC: Brian.Rosen@marconi.com, sipping@ietf.org
Subject: Re: [Sipping] Re: Comments on revised 'sos' draft
References: <200212191500.KAA51775@fish.research.att.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

William Marshall wrote:
> One aspect of 'sos' calls that is rather annoying is that there
> is no agreed standard for some details of the service.  While
> organizations such as NENA and ANSI write various documents, local
> justidictions actually set the requirements as part of CLEC-
> certification (important if you want to get blocks of phone numbers
> from the NANP so PSTN subscribers can call your subscribers).
> 
> Some jurisdictions require "called-party control" on 9-1-1 calls.  Some 
> jurisdictions require PSAP-initiated constant-ring on an attempted hangup.
> (I realize that SIP phones, like cell phones, are under the user's
> control and can be disconnected or powered off and the real usefulness
> of these requirements is dubious; but CLEC-certification is still useful).

Since this comes up again and again, I've asked this question (a while 
ago) on the NENA mailing and nobody (that answered) was able to provide 
any indication that this is still true for E911 today. (It was true for 
the early 911 service where the PSAP was connected directly to the local 
switch.) It was claimed that modern ISDN switches don't provide this 
functionality, either. Maybe you're talking about non-North American 
jurisdictions? Do you have citable evidence on this requirement? Since 
the PSAP tandem and the caller switch may be several 'hops' apart, this 
capability would have to be part of ISUP.

I looked at one of the Telcordia/Bellcore specs for 911 service and it 
doesn't mandate it, either. Since CLECs generally don't (like to) write 
their own switch software, I'd imagine that this would at least be a 
Bellcore requirement.

I got the following two contradictory quotes, among others:

"I can't speak for Call Transfer however Call Waiting and Three Way
Calling are still available to the 9-1-1 caller.  At least it is here
in a DMS environment."

"From my experience, most switches (5ESS, DMX-100, and GTD5EAX) disable
custom calling features for the entire call when calling to N11 services
in a manner similar to when they are establishing a call to another
number.  In other words, the switch deals with the 911 call like when
you are listening to a ringing signal (i.e.  no call waiting, no call
transfer, no 3-way calling, etc.)."

This only requires the originating switch to recognize N11, so that 
seems fairly easy in PSTN land. I suppose one could say that UAs should 
not use REFER.

> 
> There is a basic design decision of whether it is all in the UA, and if 
> not, potentially a standardization issue.
> 
> If the decision is that the UA doesn't really know when it calls an
> emergence service (possibly due to the numerous ways to dial such a 
> service), then there are several areas that would need some agreement.

This probably argues again for a global identifier. Some behavior, like 
call waiting, doesn't really apply in UAs. REFER issued by the UA to the 
PSAP is harmless.

> 
> 1) what is the effect of a BYE request generated by a UAC that is
> rejected by the UAS with a 4xx (e.g. 403-Forbidden)?  Does the UA
> need to wait for the response to the BYE before tossing call state?
> Likewise, call-stateful proxies on the path?  There is, of course,
> a denial-of-service threat here when a non-PSAP rejects a BYE.

Given the many ways that the caller can terminate a call, this seems 
like a second-order problem. Can ISUP refuse a teardown request? What 
happens in that case?

This may be a simple UI issue. Since this is primarily a prevention of 
accidental disconnects, a UA might want to treat the 403 as a "Callee 
doesn't want to hang up. Do you really want to terminate the call?" (The 
rough equivalent of the corresponding Windows Ctrl-Alt-Del behavior...)

> 
> 2) what is the effect of a mid-call INVITE when the instrument is
> in an on-hook state?  Is 180-Ringing an allowable response?

You mean for PSAP initiated call-back? This would be the same situation 
as if I had sent a BYE and an INVITE crossed on the wire. It would 
probably yield an invalid call-ID error.

> 
> I believe both case are "under-specified" in rfc3261, so the needed
> behavior is allowed but not mandated.  I think this is more than a BCP.

Since these are corner-cases, it seems a bad idea to rely on specific UA 
behavior. Do cell phones support any of the features you describe?

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Sat Jan  4 11:06:26 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12766
	for <sipping-archive@odin.ietf.org>; Sat, 4 Jan 2003 11:06:26 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h04GFjw26943
	for sipping-archive@odin.ietf.org; Sat, 4 Jan 2003 11:15:45 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04GFjJ26940
	for <sipping-web-archive@optimus.ietf.org>; Sat, 4 Jan 2003 11:15:45 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12759
	for <sipping-web-archive@ietf.org>; Sat, 4 Jan 2003 11:05:52 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04GEnJ26908;
	Sat, 4 Jan 2003 11:14:50 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04GCrJ26839
	for <sipping@optimus.ietf.org>; Sat, 4 Jan 2003 11:12:53 -0500
Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12735
	for <sipping@ietf.org>; Sat, 4 Jan 2003 11:03:02 -0500 (EST)
Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66])
	(user=hgs10 mech=PLAIN bits=0)
	by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h04G64Te007391
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Sat, 4 Jan 2003 11:06:05 -0500 (EST)
Message-ID: <3E170671.4020904@cs.columbia.edu>
Date: Sat, 04 Jan 2003 11:06:09 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Hammer <mhammer@cisco.com>
CC: "Rosen, Brian" <Brian.Rosen@marconi.com>,
        "'Mpierce1@aol.com'" <Mpierce1@aol.com>, sipping@ietf.org
Subject: Re: [Sipping] Re: Comments on revised 'sos' draft
References: <4.3.2.7.2.20021218151742.05261d00@cia.cisco.com>
In-Reply-To: <4.3.2.7.2.20021218151742.05261d00@cia.cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

> This is the same issue that TIA TR45.2 had to address when dealing with 
> cell phones and determining how to route to the correct PSAP.  An 
> example given was that a caller in Georgia will be directed to a 911 
> center in Atlanta, but the connection to the police/fire/medical 
> personnel had to be local to the caller.  And often the caller did not 
> know where he was.  A number of solutions were proposed, which included 
> various angle of arrival (AOA), time of arrival (TOA), and GPS-assisted 
> triangulation methods where either the phone or the radio station 
> determined and reported this type of information.
> 
> I don't know if we want to repeat that whole history here.  But, it 
> might be useful to provide the ability to add that information to the 
> INVITE.  Is there any current technique for doing that?

We've been playing around with a simple mechanism that includes the 
location information, both civil and geographic, in a SIP header only 
for 'sos' calls. This is simple to implement and avoids having to set up 
a large infrastructure. It also greatly simplifies the trust 
relationships. If you deliver this information out-of-band *e.g., as 
part of a presence mechanism via UPDATE), the PSAP has to convince the 
entity holding the location information that it is indeed a PSAP and, 
more over, preferably the one the user just called. (See the related 
discussion on the difficulties of authenticating users.)

The location information can be added by the UA or the proxy; it is 
somewhat similar in spirit to the NAI problem.

The reason for suggesting a SIP header field instead of a body is that 
proxies aren't supposed to be adding body parts to requests.

However, a header like this should be standardized outside the emergency 
call context since it is more generic.

>> 2. If it requires that a proxy actively know that an emergency
>> number is dialed, and take some distinguished action based on that
>> knowledge, then we don't need any standards.  We could write
>> a BCP or Informational.

My take is that we should not *require* that a proxy between the caller 
and the home domain know that the call is special, but allow this. The 
Draft describes two such actions:
- the obp may recognize a local emergency number and route it to a local 
gateway or PSAP
- the obp may recognize 'sos' and do the same.


>> In simple systems, none of the above is necessary.  The scenario
>> where it might be necessary to do some work is a situation in
>> which you have:
>>         A number of UAs in different geographic locations
>>         A set of proxy servers where the UAs served by one
>>                 proxy server do not respect geographic locations
>>         A set of gateways in different geographic locations
>>         A set of users who can roam from UA to UA
>>
>> In this case, if the user dialed the "local" emergency number,
>> the some entity must know which gateway to route the call to.
>> It isn't dependent on the user, it's dependent on the UA, or more
>> precisely, the geographic location of the UA when the call is made.
>> The distinction is what happens if the UA is moved.
>> If a user whose home registrar is in New York visits a site in
>> Chicago and calls 911, you need the call to route to a gateway
>> in Chicago. The proxy server for Chicago might be in St. Louis.
>> Somehow, the proxy server needs to know that a call from the UA
>> in Chicago, regardless of who is registered, needs to be routed
>> to the gateway in Chicago.

We have implemented a system that does exactly that, based on the 
location information I mentioned above, using a commercially-available 
database. Unfortunately, the protocol that maps location information to 
jurisdiction is proprietary and it is very difficult to gain access to 
the database. (You need to set a strange VPN, establish contracts and 
the like. This makes this arrangement suitable for large telecom 
carriers, but not for a small or mid-sized business with its own proxy 
servers.)


>>
>> Generally, most real systems have dialing plans, where dialing
>> strings are interpreted by some element to determine how to
>> route a call.  Most systems I know of use a proxy server to
>> implement the dialing plan.  It's a local matter for the proxy
>> server to determine how to route a call to the emergency number
>> BUT, it has to know the geographic location of the UA.
>> So, we might have some work to do in order to pass that
>> kind of information from UA to proxy server.  There is some work
>> on this underway (thanks again Henning).  I'm not sure there is
>> anything else we need do.
>>

I agree. My current hunch is that my draft or something improved is 
probably heading for BCP or Informational. It really doesn't describe 
any new SIP protocol elements.

At this point, there is an opportunity to ensure somewhat SIP-friendly 
non-jurisdiction-specific solutions in this space, rather than mandating 
replicating the existing system with all its warts.

Henning

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Sat Jan  4 11:47:39 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13305
	for <sipping-archive@odin.ietf.org>; Sat, 4 Jan 2003 11:47:39 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h04GuxD28716
	for sipping-archive@odin.ietf.org; Sat, 4 Jan 2003 11:56:59 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04GuxJ28713
	for <sipping-web-archive@optimus.ietf.org>; Sat, 4 Jan 2003 11:56:59 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13297
	for <sipping-web-archive@ietf.org>; Sat, 4 Jan 2003 11:47:05 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04GuFJ28697;
	Sat, 4 Jan 2003 11:56:15 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04GtBJ28674
	for <sipping@optimus.ietf.org>; Sat, 4 Jan 2003 11:55:11 -0500
Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13294
	for <sipping@ietf.org>; Sat, 4 Jan 2003 11:45:19 -0500 (EST)
Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66])
	(user=hgs10 mech=PLAIN bits=0)
	by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h04GmTmd000455
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Sat, 4 Jan 2003 11:48:29 -0500 (EST)
Message-ID: <3E171064.8070303@cs.columbia.edu>
Date: Sat, 04 Jan 2003 11:48:36 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mpierce1@aol.com
CC: mhammer@cisco.com, sipping@ietf.org
Subject: Re: [Sipping] Re: Comments on revised 'sos' draft
References: <f2.268c339d.2b321127@aol.com>
In-Reply-To: <f2.268c339d.2b321127@aol.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

> [MAP] There is nothing wrong with building a phone with a special button 
> that translates into a dialed number, e.g., 911, but my point is that 
> the user must still be able to dial 911 and have the exact same thing 
> happen. Which means if the phone does something special when you push 
> that button, then it must do the same special thing when you dial 911.

As suggested for 3G, it would be helpful, but not necessary, to have 
some geographically local entity provide this information to the UA. 
(After all, a telephone doesn't need to know that the digits 911 are 
special in some way.)

There are, I believe, only two plausible solutions:

(1) DHCP or possibly SLP. Given that it's in the same broadcast domain 
as the caller, most likely to be local, at least at the country level. 
(Even traveling dial-in users will rarely dial an out-of-country number.)

SLP would seem most appropriate, but it is yet another specialized 
service that would be used only for a very narrow purpose. (Unless, of 
course, our suggestion of using SLP [draft-zhao-iptel-gwloc-slp] for 
local gateway location catches on...) The only extension needed would be 
  the list of locally valid emergency numbers.

(2) Outbound proxy. Given the separation of data carriage and SIP 
services, may be at corporate headquarters or at some centralized SIP 
service provider POP.

Thus, (1) seems better. However, for DHCP, since it's the outbound proxy 
server that needs to route the calls, it may be better to have it 
indicate what the numbers it can handle.

A slightly different approach would be to have DHCP identify a local 
gateway that can handle local emergency calls, rather than just the 
numbers.


> [MAP] But I think the question is, what is the "locality" that does the 
> translating? And how? If it is the user agent (phone), it needs to know 
> the local dialing plan. If it is some "network" element, it needs to 
> know the location of the originating user. I don't see an easy solution 
> to either.

Fortunately, for this problem, either entity only needs to know the 
country (or, in Western Europe and North America, a good chunk of a 
continent) rather than more precise location. This may make it more 
manageable. In general, since there are likely going to be far fewer 
outbound proxies than UAs, I tend to prefer a 'UA does a best guess at 
location, outbound proxy knows local dialing plans'. For devices that 
are unlikely to move beyond national borders, such as the SIP phone on 
your desk, a local dialing plan will work pretty well.

> 
>> In arguing against this, you have not reduced the infrastructure workload
>> one bit, but you have pushed the problem to the end-user to configure, 
>> with
>> attendant Murphy's Law consequences.
> 
> 
> [MAP] Yes, I understand the end-user configuration problem. And I think 
> the rules would say that calls to 911 must work without any end-user 
> configuration.

That's the intent of the draft.

> 
> Mike Pierce
> Artel
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Sat Jan  4 12:49:23 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14020
	for <sipping-archive@odin.ietf.org>; Sat, 4 Jan 2003 12:49:23 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h04HwiH31729
	for sipping-archive@odin.ietf.org; Sat, 4 Jan 2003 12:58:44 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04HwiJ31726
	for <sipping-web-archive@optimus.ietf.org>; Sat, 4 Jan 2003 12:58:44 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13989
	for <sipping-web-archive@ietf.org>; Sat, 4 Jan 2003 12:47:21 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04HuWJ31667;
	Sat, 4 Jan 2003 12:56:32 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04HtNJ31593
	for <sipping@optimus.ietf.org>; Sat, 4 Jan 2003 12:55:23 -0500
Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13927
	for <sipping@ietf.org>; Sat, 4 Jan 2003 12:45:32 -0500 (EST)
Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66])
	(user=hgs10 mech=PLAIN bits=0)
	by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h04Hmdmd022234
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Sat, 4 Jan 2003 12:48:39 -0500 (EST)
Message-ID: <3E171E82.2000808@cs.columbia.edu>
Date: Sat, 04 Jan 2003 12:48:50 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Drage, Keith (Keith)" <drage@lucent.com>
CC: "'Michael Hammer'" <mhammer@cisco.com>, Mpierce1@aol.com, sipping@ietf.org
Subject: Re: [Sipping] Re: Comments on revised 'sos' draft
References: <475FF955A05DD411980D00508B6D5FB00439EB5A@en0033exch001u.uk.lucent.com>
In-Reply-To: <475FF955A05DD411980D00508B6D5FB00439EB5A@en0033exch001u.uk.lucent.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


> While you may converge on a small set of consistent SIP URLs, you
> will still need to cater for people who go to an unfamiliar device
> that happens to look like a phone, and enter the PSTN local service
> number they associate with emergency dialling. I believe supporting
> such emergency calls is a requirement, and the regulators will insist
> that it is so. Thus we continue to have the same problem in SIP
> space.

Hopefully, the devices can then have a red button marked 'SOS' which 
should deal with some of the user interface issues. See the other 
discussion on means to find the local emergency number. In practice, 
this may not be a big issue. After all, in the worst case that the call 
goes back 'home' across several timezones, the list of such numbers is 
no larger than the list of 200+ countries, so a simple SOAP service that 
retrieves the current list is pretty straightforward. (I'm restricting 
myself to countries with national emergency numbers.) The harder part is 
then routing the call to a place that can dial the number and reach 
somebody useful. In practice, I don't see anything except an obp local 
to the caller (at least within the same country) that can do this.

Henning

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Sat Jan  4 13:10:33 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14152
	for <sipping-archive@odin.ietf.org>; Sat, 4 Jan 2003 13:10:33 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h04IJsL00357
	for sipping-archive@odin.ietf.org; Sat, 4 Jan 2003 13:19:54 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04IJrJ00354
	for <sipping-web-archive@optimus.ietf.org>; Sat, 4 Jan 2003 13:19:53 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14136
	for <sipping-web-archive@ietf.org>; Sat, 4 Jan 2003 13:10:01 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04IJIJ00338;
	Sat, 4 Jan 2003 13:19:18 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04IIcJ00309
	for <sipping@optimus.ietf.org>; Sat, 4 Jan 2003 13:18:38 -0500
Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14128
	for <sipping@ietf.org>; Sat, 4 Jan 2003 13:08:46 -0500 (EST)
Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66])
	(user=hgs10 mech=PLAIN bits=0)
	by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h04IBuTe021893
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Sat, 4 Jan 2003 13:11:57 -0500 (EST)
Message-ID: <3E1723F8.7080508@cs.columbia.edu>
Date: Sat, 04 Jan 2003 13:12:08 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Mills, Duncan, D, CND Tech Dev, VF UK" <Duncan.Mills@gb.vodafone.co.uk>
CC: "Drage, Keith (Keith)" <drage@lucent.com>, sipping@ietf.org
Subject: Re: [Sipping] Re: Comments on revised 'sos' draft
References: <B77796343B16E047B045999EC4460F0D236C34@UKWMXM02>
In-Reply-To: <B77796343B16E047B045999EC4460F0D236C34@UKWMXM02>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Mills, Duncan, D, CND Tech Dev, VF UK wrote:
> In section 5 of the draft - 'Request Routing':
> 
> You talk about the need for a UA to be able to provide information
> about its location.  You mention providing exact information such as
> longitude, latitude and altitude.  You also mention possibilities of
> providing 'Agent-Circuit-ID' and 'Remote-ID', as per RFC 3046.
> 
> Have you considered also mentioning the use of the
> p-access-network-info header for this purpose?  (see
> draft-garcia-sipping-3gpp-p-headers-02 which is in the RFC editors
> queue).
> 
> The p-access-network-info header enables you to specify an
> access-type and an access-info field in cases where the UA is aware
> of the access network.

This seems potentially useful, but somewhat in the wrong direction and 
at the wrong layer. At least currently, the information appears to be a 
list of physical layers, as in

"IEEE-802.11a" / "IEEE-802.11b" /
"3GPP-GERAN" / "3GPP-UTRAN-FDD" /
"3GPP-UTRAN-TDD" /
"3GPP-CDMA2000"

and is provided by the UA. This type of information doesn't seem to help 
much in determining the local emergency number, a local suitable gateway 
or other emergency information. How would you envision extending this 
information and how would the UA find out this information?

> 
> In 3GPP circles this helps (as Keith said) the outbound proxy to try
> and figure out if the 'dialled digits' are that of a local emergency
> centre or not...
> 
> Best Regards,
> 
> Duncan

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Sat Jan  4 13:31:50 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14286
	for <sipping-archive@odin.ietf.org>; Sat, 4 Jan 2003 13:31:49 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h04IfBg01506
	for sipping-archive@odin.ietf.org; Sat, 4 Jan 2003 13:41:11 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04IfBJ01503
	for <sipping-web-archive@optimus.ietf.org>; Sat, 4 Jan 2003 13:41:11 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14275
	for <sipping-web-archive@ietf.org>; Sat, 4 Jan 2003 13:31:16 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04IeKJ01477;
	Sat, 4 Jan 2003 13:40:20 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04IdZJ01414
	for <sipping@optimus.ietf.org>; Sat, 4 Jan 2003 13:39:35 -0500
Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14261
	for <sipping@ietf.org>; Sat, 4 Jan 2003 13:29:43 -0500 (EST)
Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66])
	(user=hgs10 mech=PLAIN bits=0)
	by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h04IWtmd007482
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Sat, 4 Jan 2003 13:32:55 -0500 (EST)
Message-ID: <3E1728E4.9090704@cs.columbia.edu>
Date: Sat, 04 Jan 2003 13:33:08 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mpierce1@aol.com
CC: sipping@ietf.org
References: <1c5.30e3c4a.2b2b7db9@aol.com>
In-Reply-To: <1c5.30e3c4a.2b2b7db9@aol.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sipping] Re: Comments on revised 'sos' draft
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Thanks for your comments. Skipping things discussed already, some 
remarks inline.

Mpierce1@aol.com wrote:


> This capability to support a special universal identifier does not 
> replace any requirements that a user must be able to dial local 
> emergency numbers and have the UA correctly handle the call, including 
> any appropriate processing..

I noted that this is an additional capability.

> If the approach in the 6h paragraph of defining subaddresses is used 
> (e.g., fire, rescue, police), it would be necessary to be able to define 
> many other types, as well as to deal with language differences. Note 
> that "SOS" itself was chosen due it its international recognition and 
> not being dependent on a particular language. There would need to be, at 
> a minimum, an IANA Considerations for assignment of other subaddresses.

Has been added.

> 
> The seventh paragraph states that the "sos" user name and user names 
> starting with "sos." MUST NOT be assigned to any user. Such a 
> restriction can not possibly be enforced due to possible existing 
> conflicts (as noted in Section 6). While this restriction may be 
> "recommended", just as it might be recommended that a PBX not use an 
> extension number of 911, this can not be the basis for any processing on 
> the URL in a proxy. Depending on a URL of the form "sos@any_domain" to 
> call the emergency center is not sufficient. This could result in many 
> unwanted calls to emergency centers.

Do you have any suggestions that work better? The section 'Alternative 
Identifiers Considered' describes why I believe that none of the obvious 
alternatives is workable if you want

- gradual deployability (this rules out special tel: URIs)

- ability for non-modified UAs to dial this number (this rules out a new 
header field or URI parameter)

We have a long-standing precedent for this, namely the 'postmaster' 
convention in RFC 2821, Section 4.5.1:

  Any system that includes an SMTP server supporting mail relaying or
    delivery MUST support the reserved mailbox "postmaster" as a case-
    insensitive local name.

> 
> 4. Request handling
> 
> The 4th paragraph talks about "testing" by use of OPTIONS. Since the 
> testing is only "recommended", there should be no reason that the random 
> intervals be a "MUST".

This does not follow logically. It simply states that "if you do X, you 
MUST do it in a certain way." I don't want to say that "if you do X, you 
SHOULD do it that way, but may do it differently if you need to".


> 
> The next paragraph states that "any proxy ... that receives such a 
> request MUST forward the request to the appropriate local emergency 
> number". Since this certainly does not refer to the test call in the 
> preceding paragraph, this paragraph should be moved.

Moved.

> 
> Mike Pierce
> Artel
> 
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Sat Jan  4 13:34:18 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14340
	for <sipping-archive@odin.ietf.org>; Sat, 4 Jan 2003 13:34:17 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h04Ihd201625
	for sipping-archive@odin.ietf.org; Sat, 4 Jan 2003 13:43:39 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04IhdJ01622
	for <sipping-web-archive@optimus.ietf.org>; Sat, 4 Jan 2003 13:43:39 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14330
	for <sipping-web-archive@ietf.org>; Sat, 4 Jan 2003 13:33:46 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04Ih4J01603;
	Sat, 4 Jan 2003 13:43:04 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04IgYJ01552
	for <sipping@optimus.ietf.org>; Sat, 4 Jan 2003 13:42:34 -0500
Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14306
	for <sipping@ietf.org>; Sat, 4 Jan 2003 13:32:41 -0500 (EST)
Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id h04IZk8W008346;
	Sat, 4 Jan 2003 12:35:46 -0600
From: "Dean Willis" <dean.willis@softarmor.com>
To: "'Henning Schulzrinne'" <hgs@cs.columbia.edu>,
        "'Rosen, Brian'" <Brian.Rosen@marconi.com>
Cc: <James.Hamlin@RNID.org.uk>, <sipping@ietf.org>
Subject: RE: [Sipping] Authentication issues with emergency and other serv ices
Date: Sat, 4 Jan 2003 12:35:24 -0600
Message-ID: <003601c2b420$0bbcc930$0c02a8c0@txdwillis>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <3E1655E8.4060308@cs.columbia.edu>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h04IgYJ01553
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

> > We have talked about the other side of that problem =
> > authenticating that the caller is talking to a bona fide
> > PSAP.  Even that is seen as an impossibly hard problem =
> > getting all PSAPs to get a cert signed by a global PSAP
> > CA.
> 
> To amplify: the typical SSL cert from Thawte or Verisign wouldn't do 
> much good here. You need somebody to provide a certificate that 
> psap.sometown.ny.us is indeed a PSAP and not the 
> Pseudo-Service Agency 
> imPersonator. Things would be somewhat easier if ICANN 
> created another 
> restricted top-level domain similar to .museum, but I know of 
> no such plans.

Well, the problem is that you need to be able to trust that the PSAP URL
you've been given is a valid PSAP. That boils down to "so, where did you get
this PSAP URL from?" Once you HAVE a URL, pki can validate that the party
you end up talking to is the rightful holder of that URL.

So let's separate the problem out.

Where does the PSAP URL come from?

Possibilities:

1) Something like DHCP. Well, this pushes the whole trust problem onto DHCP,
doesn't it? Although we SEEM ready to trust DHCP for everything else,
including assignment of DNS servers. This same model generalizes to the
"trusted introducer/configuratio nserver" problem.

2) Something statically configured, perhaps "operator provisioned". This
would mean that the routing infrastructure would have to find you the
"right" PSAP among the many. Potentially, an interesting application of
nearest-anycast, or simply a design problem for an operator network. Might
work in a 3GPP-ish environment (where th P-CSCF can make local diversion
decisions), but how does it help the SIP-phone at my desk?

--
Dean

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Sat Jan  4 20:06:37 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18036
	for <sipping-archive@odin.ietf.org>; Sat, 4 Jan 2003 20:06:36 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h051G6f18743
	for sipping-archive@odin.ietf.org; Sat, 4 Jan 2003 20:16:06 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h051G6J18740
	for <sipping-web-archive@optimus.ietf.org>; Sat, 4 Jan 2003 20:16:06 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18031
	for <sipping-web-archive@ietf.org>; Sat, 4 Jan 2003 20:06:02 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h051FDJ18714;
	Sat, 4 Jan 2003 20:15:13 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0519kJ18621
	for <sipping@optimus.ietf.org>; Sat, 4 Jan 2003 20:09:46 -0500
Received: from mtiwmhc13.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17975
	for <sipping@ietf.org>; Sat, 4 Jan 2003 19:59:45 -0500 (EST)
Received: from cs.columbia.edu ([12.85.1.245])
          by mtiwmhc13.worldnet.att.net
          (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP
          id <20030105010257.FUSS20003.mtiwmhc13.worldnet.att.net@cs.columbia.edu>;
          Sun, 5 Jan 2003 01:02:57 +0000
Message-ID: <3E1783B0.7050209@cs.columbia.edu>
Date: Sat, 04 Jan 2003 20:00:32 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dean Willis <dean.willis@softarmor.com>
CC: "'Rosen, Brian'" <Brian.Rosen@marconi.com>, James.Hamlin@RNID.org.uk,
        sipping@ietf.org
Subject: Re: [Sipping] Authentication issues with emergency and other serv
 ices
References: <003601c2b420$0bbcc930$0c02a8c0@txdwillis>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

> Well, the problem is that you need to be able to trust that the PSAP URL
> you've been given is a valid PSAP. That boils down to "so, where did you get
> this PSAP URL from?" Once you HAVE a URL, pki can validate that the party
> you end up talking to is the rightful holder of that URL.

The problem is even worse in that I have no realistic way to determine 
whether I reached the right PSAP, leaving the PKI issues aside. The PSAP 
is determined (in the US) by the MSAG, the Master Street-Address Guide, 
which maps street locations to PSAPs (roughly speaking). Another 
database maps longitude/latitude to jurisdictions. As far as I know, 
this information is not public. (You have to pay a certain database 
company serious money to get it and be authorized.) In addition, PSAPs 
back up each other, so that you may end up at a different PSAP than last 
time you called for quite legitimate reasons.

Thus, under the best of circumstances (with a special credential or a 
restricted domain), you might be able to tell that you have reached *a* 
PSAP among the 5,000 or so in the United States. Whether this is the 
correct PSAP can, at best, be guessed at.

Plus, unlike in the typical case, where you send an INVITE to 
dean.will@softarmor.com and can expect to get a cert with the principal 
being that address, you'd dial 'sos@somewhere' or 'tel:911' and might 
get back something signed by 'agent17@admin.co.fayette.ga.us' (to pick a 
real-life example from 
http://www.admin.co.fayette.ga.us/communications/fayetteco911/).

The SSL-style cert would be useful for the ERC (to use my draft 
terminology). Once it determines the correct PSAP SIP address, it can 
indeed verify that it got connected to it. In practice, this may be 
sufficient as long as you can trust the database.


> 
> So let's separate the problem out.
> 
> Where does the PSAP URL come from?
> 
> Possibilities:
> 
> 1) Something like DHCP. Well, this pushes the whole trust problem onto DHCP,
> doesn't it? Although we SEEM ready to trust DHCP for everything else,
> including assignment of DNS servers. This same model generalizes to the
> "trusted introducer/configuratio nserver" problem.

DHCP is unlikely. My understanding is that jurisdictional boundaries 
change, albeit infrequently, and PSAPs get split and reorganized. Thus, 
you probably don't want to update the DHCP server in each dentist's 
office and law practice when that happens. (It's not even clear how 
you'd notify them all.). Thus, you typically have companies like Intrado 
that provide these databases. (Intrado calls this the CRDB database, see 
http://www.intrado.com/main/offerings/intellivector/wireless/nineoneone/)

> 
> 2) Something statically configured, perhaps "operator provisioned". This
> would mean that the routing infrastructure would have to find you the
> "right" PSAP among the many. Potentially, an interesting application of
> nearest-anycast, or simply a design problem for an operator network. Might
> work in a 3GPP-ish environment (where th P-CSCF can make local diversion
> decisions), but how does it help the SIP-phone at my desk?

As above. We have implemented a system that takes a street address, 
converts it to long/lat, feeds it to the database mentioned earlier and 
gets the PSAP. (Clearly, you'd cache the data for your desk SIP phone 
since there's little point in asking the same question again and again.)

> 
> --
> Dean

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Sun Jan  5 22:44:09 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14961
	for <sipping-archive@odin.ietf.org>; Sun, 5 Jan 2003 22:44:09 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h063sCw06974
	for sipping-archive@odin.ietf.org; Sun, 5 Jan 2003 22:54:12 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h063sCJ06971
	for <sipping-web-archive@optimus.ietf.org>; Sun, 5 Jan 2003 22:54:12 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14940
	for <sipping-web-archive@ietf.org>; Sun, 5 Jan 2003 22:43:37 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h063nYJ06856;
	Sun, 5 Jan 2003 22:49:34 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h063mpJ06820
	for <sipping@optimus.ietf.org>; Sun, 5 Jan 2003 22:48:51 -0500
Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14881
	for <sipping@ietf.org>; Sun, 5 Jan 2003 22:38:18 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.11])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h063fSYH025550;
	Sun, 5 Jan 2003 22:41:28 -0500 (EST)
Message-ID: <3E18FAE9.8040609@dynamicsoft.com>
Date: Sun, 05 Jan 2003 22:41:29 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Henning Schulzrinne <hgs@cs.columbia.edu>
CC: William Marshall <wtm@research.att.com>, Brian.Rosen@marconi.com,
        sipping@ietf.org
Subject: Re: [Sipping] Re: Comments on revised 'sos' draft
References: <200212191500.KAA51775@fish.research.att.com> <3E165EC7.6090107@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

inline.

Henning Schulzrinne wrote:
> William Marshall wrote:
> 
>
>> 1) what is the effect of a BYE request generated by a UAC that is
>> rejected by the UAS with a 4xx (e.g. 403-Forbidden)?  Does the UA
>> need to wait for the response to the BYE before tossing call state?
>> Likewise, call-stateful proxies on the path?  There is, of course,
>> a denial-of-service threat here when a non-PSAP rejects a BYE.
> 
> 
> Given the many ways that the caller can terminate a call, this seems 
> like a second-order problem. Can ISUP refuse a teardown request? What 
> happens in that case?

SIP does in fact describe behavior here. According to Section 15.1.1:

The UAC MUST
    consider the session terminated (and therefore stop sending or
    listening for media) as soon as the BYE request is passed to the
    client transaction.

Thus, rejecting the call will not achieve the "desired" effect.


>>
>> 2) what is the effect of a mid-call INVITE when the instrument is
>> in an on-hook state?  Is 180-Ringing an allowable response?
> 
> 
> You mean for PSAP initiated call-back? This would be the same situation 
> as if I had sent a BYE and an INVITE crossed on the wire. It would 
> probably yield an invalid call-ID error.

THis re-INVITE would appear to the UA as a new INVITE (not corresponding 
to an existing dialog) but with tags. Behavior in this case is also well 
specified in 3261. Section 13.3.1 bullet 3 covers this case, and it 
refers the reader to Section 12.2.2. That section says that, unless you 
are specifically re-creating old dialogs beacuse you are a conferencing 
server or something, then you should send a 481.



> 
>>
>> I believe both case are "under-specified" in rfc3261, so the needed
>> behavior is allowed but not mandated.  I think this is more than a BCP.

It is most certainly not "under-specified".

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan  6 00:23:17 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16563
	for <sipping-archive@odin.ietf.org>; Mon, 6 Jan 2003 00:23:16 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h065XMi12017
	for sipping-archive@odin.ietf.org; Mon, 6 Jan 2003 00:33:22 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h065XLJ12014
	for <sipping-web-archive@optimus.ietf.org>; Mon, 6 Jan 2003 00:33:21 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16543
	for <sipping-web-archive@ietf.org>; Mon, 6 Jan 2003 00:22:44 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h065T4J11873;
	Mon, 6 Jan 2003 00:29:04 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h065RuJ11788
	for <sipping@optimus.ietf.org>; Mon, 6 Jan 2003 00:27:56 -0500
Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16472
	for <sipping@ietf.org>; Mon, 6 Jan 2003 00:17:19 -0500 (EST)
Received: from cisco.com (desh.cisco.com [192.122.173.43])
	by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h065K0jS004004
	for <sipping@ietf.org>; Sun, 5 Jan 2003 21:20:00 -0800 (PST)
Received: from cisco.com ([10.77.138.78])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA18976
	for <sipping@ietf.org>; Mon, 6 Jan 2003 10:50:11 +0530 (IST)
Message-ID: <3E19121E.ACF487EA@cisco.com>
Date: Mon, 06 Jan 2003 10:50:31 +0530
From: Sunderajan Selvaraj <suselvar@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
CC: "'sipping@ietf.org'" <sipping@ietf.org>
References: <475FF955A05DD411980D00508B6D5FB006FFB400@en0033exch001u.uk.lucent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sipping] UNSUBSCRIBE
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit



"Drage, Keith (Keith)" wrote:

> Network asserted identity (RFC 3325) is the real network asserted identity. It is a P header not because it is preliminary, but because the whole idea of network assertion is not generally applicable to all SIP architectures. For RFC 3325 a trust domain needs to exist between proxies that use the P-Asserted-Identity in order to guarantee the privacy, this does not exist in all SIP networks. In does in 3GPP and therefore 3GPP are using RFC 3325.
>
> If you want to let the 1et outbound proxy assert identity on your behalf then use RFC 3325. If you want to let application servers with whom you have a secure relationship assert your identity, then use Jon Petersons drafts, when they eventually become RFCs.
>
> One is not a short term solution for the other.
>
> Keith
>
> Keith Drage
> Lucent Technologies
> Tel: +44 1793 776249
> Email: drage@lucent.com
>
> > -----Original Message-----
> > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > Sent: 02 January 2003 20:49
> > To: 'Henning Schulzrinne'
> > Cc: 'sipping@ietf.org'
> > Subject: RE: [Sipping] URIs for Gateways
> >
> >
> > Yeah, I actually thought of just allowing a display name in the
> > Request URI and using that, but it seems so foolish to make a change,
> > and have that change not be exactly what we needed.
> >
> > We could use NAI.  I suppose we could use a P-Asserted-Identity
> > with a tel URI:
> > P-Asserted-Identity tel:+17247426826
> >
> > What do we do when the "real" NAI happens?
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> > > Sent: Thursday, January 02, 2003 3:10 PM
> > > To: Rosen, Brian
> > > Cc: 'sipping@ietf.org'
> > > Subject: Re: [Sipping] URIs for Gateways
> > >
> > >
> > > > I'd like to get a new header for the calling party number on
> > > > an outbound call.  That way, the translator can be a proxy and
> > > > add the header.  I'd recommend that gateways allow the number
> > > > to be in the From.
> > >
> > > Generalized, you want something like the Request-URI that can be
> > > modified or inserted. How about the NAI stuff?
> > >
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sip@ietf.org for new developments of core SIP
> >
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan  6 07:27:57 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02059
	for <sipping-archive@odin.ietf.org>; Mon, 6 Jan 2003 07:27:56 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h06CcAg13881
	for sipping-archive@odin.ietf.org; Mon, 6 Jan 2003 07:38:10 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06CcAJ13878
	for <sipping-web-archive@optimus.ietf.org>; Mon, 6 Jan 2003 07:38:10 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02052
	for <sipping-web-archive@ietf.org>; Mon, 6 Jan 2003 07:27:24 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06CYkJ13139;
	Mon, 6 Jan 2003 07:34:46 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06CX6J13068
	for <sipping@optimus.ietf.org>; Mon, 6 Jan 2003 07:33:06 -0500
Received: from mail-blue.research.att.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01942
	for <sipping@ietf.org>; Mon, 6 Jan 2003 07:22:21 -0500 (EST)
Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26])
	by mail-blue.research.att.com (Postfix) with ESMTP
	id ED3FE4CF9F; Mon,  6 Jan 2003 07:25:35 -0500 (EST)
Received: from fish.research.att.com (fish.research.att.com [135.207.27.137])
	by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id HAA04045;
	Mon, 6 Jan 2003 07:25:34 -0500 (EST)
From: William Marshall <wtm@research.att.com>
Received: (from wtm@localhost)
	by fish.research.att.com (SGI-8.9.3/8.8.5) id HAA06165;
	Mon, 6 Jan 2003 07:24:51 -0500 (EST)
Date: Mon, 6 Jan 2003 07:24:51 -0500 (EST)
Message-Id: <200301061224.HAA06165@fish.research.att.com>
To: jdrosen@dynamicsoft.com
Cc: sipping@ietf.org
Subject: Re: [Sipping] Re: Comments on revised 'sos' draft
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

Jonathan wrote:
> It is most certainly not "under-specified".

I'll conceed on the first point (a rejected BYE), but not yet on the second.

Nowhere in RFC3261 does it state that if SIP is being used to control
a 2500-style telehpone handset, and that handset goes to an "onhook" 
state with a session active, that the UA MUST send a BYE.

If the UA does not, due e.g. to knowing that it just called a number
such as 9-1-1, and the PSAP sends a mid-call INVITE with all the
proper Route headers and Contact values and tags, it will certainly
match the existing dialog at the UA, so will not be a new INVITE.
So a 481 is not the proper response.  Is 180-Ringing allowable?

Bill Marshall
wtm@research.att.com

-----original message-----
Date: Sun, 05 Jan 2003 22:41:29 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: Henning Schulzrinne <hgs@cs.columbia.edu>
Cc: William Marshall <wtm@research.att.com>, Brian.Rosen@marconi.com,
        sipping@ietf.org
Subject: Re: [Sipping] Re: Comments on revised 'sos' draft

inline.

Henning Schulzrinne wrote:
> William Marshall wrote:
> 
>
>> 1) what is the effect of a BYE request generated by a UAC that is
>> rejected by the UAS with a 4xx (e.g. 403-Forbidden)?  Does the UA
>> need to wait for the response to the BYE before tossing call state?
>> Likewise, call-stateful proxies on the path?  There is, of course,
>> a denial-of-service threat here when a non-PSAP rejects a BYE.
> 
> 
> Given the many ways that the caller can terminate a call, this seems 
> like a second-order problem. Can ISUP refuse a teardown request? What 
> happens in that case?

SIP does in fact describe behavior here. According to Section 15.1.1:

The UAC MUST
    consider the session terminated (and therefore stop sending or
    listening for media) as soon as the BYE request is passed to the
    client transaction.

Thus, rejecting the call will not achieve the "desired" effect.


>>
>> 2) what is the effect of a mid-call INVITE when the instrument is
>> in an on-hook state?  Is 180-Ringing an allowable response?
> 
> 
> You mean for PSAP initiated call-back? This would be the same situation 
> as if I had sent a BYE and an INVITE crossed on the wire. It would 
> probably yield an invalid call-ID error.

THis re-INVITE would appear to the UA as a new INVITE (not corresponding 
to an existing dialog) but with tags. Behavior in this case is also well 
specified in 3261. Section 13.3.1 bullet 3 covers this case, and it 
refers the reader to Section 12.2.2. That section says that, unless you 
are specifically re-creating old dialogs beacuse you are a conferencing 
server or something, then you should send a 481.



> 
>>
>> I believe both case are "under-specified" in rfc3261, so the needed
>> behavior is allowed but not mandated.  I think this is more than a BCP.

It is most certainly not "under-specified".

-Jonathan R.
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan  6 08:13:37 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02792
	for <sipping-archive@odin.ietf.org>; Mon, 6 Jan 2003 08:13:37 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h06DNo216121
	for sipping-archive@odin.ietf.org; Mon, 6 Jan 2003 08:23:50 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06DNoJ16118
	for <sipping-web-archive@optimus.ietf.org>; Mon, 6 Jan 2003 08:23:50 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02773
	for <sipping-web-archive@ietf.org>; Mon, 6 Jan 2003 08:13:03 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06DITJ15895;
	Mon, 6 Jan 2003 08:18:29 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06DHFJ15848
	for <sipping@optimus.ietf.org>; Mon, 6 Jan 2003 08:17:15 -0500
Received: from mail-green.research.att.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02667
	for <sipping@ietf.org>; Mon, 6 Jan 2003 08:06:30 -0500 (EST)
Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26])
	by mail-green.research.att.com (Postfix) with ESMTP
	id CCCE01E0AF; Mon,  6 Jan 2003 08:09:43 -0500 (EST)
Received: from fish.research.att.com (fish.research.att.com [135.207.27.137])
	by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id IAA04411;
	Mon, 6 Jan 2003 08:09:40 -0500 (EST)
From: William Marshall <wtm@research.att.com>
Received: (from wtm@localhost)
	by fish.research.att.com (SGI-8.9.3/8.8.5) id IAA62581;
	Mon, 6 Jan 2003 08:08:42 -0500 (EST)
Date: Mon, 6 Jan 2003 08:08:42 -0500 (EST)
Message-Id: <200301061308.IAA62581@fish.research.att.com>
To: hgs@cs.columbia.edu
Cc: Brian.Rosen@marconi.com, sipping@ietf.org
Subject: Re: [Sipping] Re: Comments on revised 'sos' draft
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

Henning,

Very good questions, and I really wish I had something citable as
evidence of the current situation.

I've been told that Bell South has written their own specifications
for 9-1-1 service, and don't use the Bellcore ones. (but no citation).

And I certainly agree that these "basic-9-1-1 features" won't work in
an E911 system when the caller is not connected to the same class 5
switch as the PSAP.  I believe all the NENA and Bellcore documents on
E911 are consistent on this.

The most solid piece of evidence that I have is that the packetcable
signaling draft specification was rejected by the cable operators because
it did not support PSAP-initiated constant-ring on an attempted hangup.
At least one cable operator (unknown which one) insisted this was an
absolute requirement in their service area.  But since it was an
anonymous veto, there is again no citation available.  So we just deal
with it (and a few lines of text added to the next rev of the proxy-
proxy I-D defining an additional token to the P-DCS-OSPS header).

I really do wish that I had a better answer for this one.

> Given the many ways that the caller can terminate a call, this seems 
> like a second-order problem. Can ISUP refuse a teardown request? What 
> happens in that case?

I agree that the technical situation borders on ludicrous, but the fact
remains that CLEC-certification is essential and is not a technical issue.

> Do cell phones support any of the features you describe?

Keith can answer this one more completely, but I believe emergency calls
on cell phones are not supported yet in IMS - that the cell phones are
required to use the circuit-switch modes for 9-1-1 calls.  As for non-3G
phones, nothing prevents them being turned off, and (fortunately) nobody 
considers that a problem.

Bill Marshall
wtm@research.att.com

-----original message-----
Date: Fri, 03 Jan 2003 23:10:47 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
To: William Marshall <wtm@research.att.com>
Cc: Brian.Rosen@marconi.com, sipping@ietf.org
Subject: Re: [Sipping] Re: Comments on revised 'sos' draft

William Marshall wrote:
> One aspect of 'sos' calls that is rather annoying is that there
> is no agreed standard for some details of the service.  While
> organizations such as NENA and ANSI write various documents, local
> justidictions actually set the requirements as part of CLEC-
> certification (important if you want to get blocks of phone numbers
> from the NANP so PSTN subscribers can call your subscribers).
> 
> Some jurisdictions require "called-party control" on 9-1-1 calls.  Some 
> jurisdictions require PSAP-initiated constant-ring on an attempted hangup.
> (I realize that SIP phones, like cell phones, are under the user's
> control and can be disconnected or powered off and the real usefulness
> of these requirements is dubious; but CLEC-certification is still useful).

Since this comes up again and again, I've asked this question (a while 
ago) on the NENA mailing and nobody (that answered) was able to provide 
any indication that this is still true for E911 today. (It was true for 
the early 911 service where the PSAP was connected directly to the local 
switch.) It was claimed that modern ISDN switches don't provide this 
functionality, either. Maybe you're talking about non-North American 
jurisdictions? Do you have citable evidence on this requirement? Since 
the PSAP tandem and the caller switch may be several 'hops' apart, this 
capability would have to be part of ISUP.

I looked at one of the Telcordia/Bellcore specs for 911 service and it 
doesn't mandate it, either. Since CLECs generally don't (like to) write 
their own switch software, I'd imagine that this would at least be a 
Bellcore requirement.

I got the following two contradictory quotes, among others:

"I can't speak for Call Transfer however Call Waiting and Three Way
Calling are still available to the 9-1-1 caller.  At least it is here
in a DMS environment."

"From my experience, most switches (5ESS, DMX-100, and GTD5EAX) disable
custom calling features for the entire call when calling to N11 services
in a manner similar to when they are establishing a call to another
number.  In other words, the switch deals with the 911 call like when
you are listening to a ringing signal (i.e.  no call waiting, no call
transfer, no 3-way calling, etc.)."

This only requires the originating switch to recognize N11, so that 
seems fairly easy in PSTN land. I suppose one could say that UAs should 
not use REFER.

> 
> There is a basic design decision of whether it is all in the UA, and if 
> not, potentially a standardization issue.
> 
> If the decision is that the UA doesn't really know when it calls an
> emergence service (possibly due to the numerous ways to dial such a 
> service), then there are several areas that would need some agreement.

This probably argues again for a global identifier. Some behavior, like 
call waiting, doesn't really apply in UAs. REFER issued by the UA to the 
PSAP is harmless.

> 
> 1) what is the effect of a BYE request generated by a UAC that is
> rejected by the UAS with a 4xx (e.g. 403-Forbidden)?  Does the UA
> need to wait for the response to the BYE before tossing call state?
> Likewise, call-stateful proxies on the path?  There is, of course,
> a denial-of-service threat here when a non-PSAP rejects a BYE.

Given the many ways that the caller can terminate a call, this seems 
like a second-order problem. Can ISUP refuse a teardown request? What 
happens in that case?

This may be a simple UI issue. Since this is primarily a prevention of 
accidental disconnects, a UA might want to treat the 403 as a "Callee 
doesn't want to hang up. Do you really want to terminate the call?" (The 
rough equivalent of the corresponding Windows Ctrl-Alt-Del behavior...)

> 
> 2) what is the effect of a mid-call INVITE when the instrument is
> in an on-hook state?  Is 180-Ringing an allowable response?

You mean for PSAP initiated call-back? This would be the same situation 
as if I had sent a BYE and an INVITE crossed on the wire. It would 
probably yield an invalid call-ID error.

> 
> I believe both case are "under-specified" in rfc3261, so the needed
> behavior is allowed but not mandated.  I think this is more than a BCP.

Since these are corner-cases, it seems a bad idea to rely on specific UA 
behavior. Do cell phones support any of the features you describe?
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan  6 10:48:00 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05852
	for <sipping-archive@odin.ietf.org>; Mon, 6 Jan 2003 10:47:59 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h06FwHj25721
	for sipping-archive@odin.ietf.org; Mon, 6 Jan 2003 10:58:17 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06FwGJ25718
	for <sipping-web-archive@optimus.ietf.org>; Mon, 6 Jan 2003 10:58:16 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05839
	for <sipping-web-archive@ietf.org>; Mon, 6 Jan 2003 10:47:27 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06FsLJ25525;
	Mon, 6 Jan 2003 10:54:21 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06FrhJ25446
	for <sipping@optimus.ietf.org>; Mon, 6 Jan 2003 10:53:43 -0500
Received: from hoemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05767
	for <sipping@ietf.org>; Mon, 6 Jan 2003 10:42:55 -0500 (EST)
Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57])
	by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h06Fk7c07661
	for <sipping@ietf.org>; Mon, 6 Jan 2003 10:46:08 -0500 (EST)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19)
	id <XNTA6R0J>; Mon, 6 Jan 2003 15:46:06 -0000
Message-ID: <475FF955A05DD411980D00508B6D5FB00439EB7B@en0033exch001u.uk.lucent.com>
From: "Drage, Keith (Keith)" <drage@lucent.com>
To: "'Henning Schulzrinne'" <hgs@cs.columbia.edu>,
        "Mills, Duncan, D, CND Tech Dev, VF UK" <Duncan.Mills@gb.vodafone.co.uk>
Cc: "Drage, Keith (Keith)" <drage@lucent.com>, sipping@ietf.org
Subject: RE: [Sipping] Re: Comments on revised 'sos' draft
Date: Mon, 6 Jan 2003 15:46:03 -0000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

See below

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: drage@lucent.com 

> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: 04 January 2003 18:12
> To: Mills, Duncan, D, CND Tech Dev, VF UK
> Cc: Drage, Keith (Keith); sipping@ietf.org
> Subject: Re: [Sipping] Re: Comments on revised 'sos' draft
> 
> 
> Mills, Duncan, D, CND Tech Dev, VF UK wrote:
> > In section 5 of the draft - 'Request Routing':
> > 
> > You talk about the need for a UA to be able to provide information
> > about its location.  You mention providing exact information such as
> > longitude, latitude and altitude.  You also mention possibilities of
> > providing 'Agent-Circuit-ID' and 'Remote-ID', as per RFC 3046.
> > 
> > Have you considered also mentioning the use of the
> > p-access-network-info header for this purpose?  (see
> > draft-garcia-sipping-3gpp-p-headers-02 which is in the RFC editors
> > queue).
> > 
> > The p-access-network-info header enables you to specify an
> > access-type and an access-info field in cases where the UA is aware
> > of the access network.
> 
> This seems potentially useful, but somewhat in the wrong 
> direction and 
> at the wrong layer. At least currently, the information 
> appears to be a 
> list of physical layers, as in
> 
> "IEEE-802.11a" / "IEEE-802.11b" /
> "3GPP-GERAN" / "3GPP-UTRAN-FDD" /
> "3GPP-UTRAN-TDD" /
> "3GPP-CDMA2000"
> 
> and is provided by the UA. This type of information doesn't 
> seem to help 
> much in determining the local emergency number, a local 
> suitable gateway 
> or other emergency information. How would you envision extending this 
> information and how would the UA find out this information?

The relevant parts of the information is (from the 3GPP P-headers i-d):

cgi-3gpp               = "cgi-3gpp" EQUAL
                               (token / quoted-string)
utran-cell-id-3gpp     = "utran-cell-id-3gpp" EQUAL
                               (token / quoted-string)

The values for "cgi-3gpp" and "utran-cell-id-3gpp"
   are defined in 3GPP TS 24.229 [15].

3GPP TS 24.229 then defines:

If the access type field is equal to "3GPP-UTRAN-FDD", "3GPP-UTRAN-TDD" or "3GPP-CDMA2000" the access info field shall contain a value for "utran-cell-id-3gpp" parameter. This value shall be made up of a concatenation of the MCC, MNC, LAC (as described in 3GPP TS 23.003) and the UMTS Cell Identity (as described in 3GPP TS 25.331), obtained from lower layers of the UE, and is coded as a text string as follows:
Starting with the most significant bit, MCC (3 digits), MNC (2 or 3 digits depending on MCC value), LAC (fixed length code of 16 bits using full hexadecimal representation) and UMTS Cell Identity (fixed length code of 28 bits).

A similar definition exists for the GERAN type of access.

Other access mechanisms would be expected to make their own definitions of location information, as the structure of the data in this header is specific to the access mechanism, i.e. it has not been converted into a standard geodetic specification.

> 
> > 
> > In 3GPP circles this helps (as Keith said) the outbound proxy to try
> > and figure out if the 'dialled digits' are that of a local emergency
> > centre or not...
> > 
> > Best Regards,
> > 
> > Duncan
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan  6 10:59:17 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06025
	for <sipping-archive@odin.ietf.org>; Mon, 6 Jan 2003 10:59:17 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h06G9YD26863
	for sipping-archive@odin.ietf.org; Mon, 6 Jan 2003 11:09:34 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06G9YJ26860
	for <sipping-web-archive@optimus.ietf.org>; Mon, 6 Jan 2003 11:09:34 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06017
	for <sipping-web-archive@ietf.org>; Mon, 6 Jan 2003 10:58:45 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06G5OJ26054;
	Mon, 6 Jan 2003 11:05:24 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06G41J26000
	for <sipping@optimus.ietf.org>; Mon, 6 Jan 2003 11:04:01 -0500
Received: from hoemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05920
	for <sipping@ietf.org>; Mon, 6 Jan 2003 10:53:13 -0500 (EST)
Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57])
	by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h06FuPc12289
	for <sipping@ietf.org>; Mon, 6 Jan 2003 10:56:25 -0500 (EST)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19)
	id <XNTA6S3H>; Mon, 6 Jan 2003 15:56:24 -0000
Message-ID: <475FF955A05DD411980D00508B6D5FB00439EB7C@en0033exch001u.uk.lucent.com>
From: "Drage, Keith (Keith)" <drage@lucent.com>
To: "'Henning Schulzrinne'" <hgs@cs.columbia.edu>,
        "'sipping@ietf.org'"
	 <sipping@ietf.org>
Date: Mon, 6 Jan 2003 15:56:22 -0000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sipping] Comments on sos draft -0
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

Rather than reply to the other mails on this draft, I thought I should start from scratch on generating comments, although some of the comments below have some bearing on the discussions that are already taking place.

Comments on draft-schulzrinne-sipping-sos-03

1)	The document is missing an abstract which defines the scope. I am therefore unsure whether it is just a requirements document, or whether it is intended to be provide the total solution for emergency calls. My assumption is the latter, and therefore this ultimately will be the RFC that will register the sos and sos. urls, and will also define the actions of UAs and proxies in regard to emergency calls. However the latter presumably should be SIP actions, and should be in the SIP group. The following should therefore be done:

-	add an abstract detailing the scope of this specification
-	if the document is to define requirements for SIP UAs and proxies, then decide whether it should be a SIP group draft.

2)	section 3 (Emergency URI). I think we should break down this section into 2. The first should detail requirements for SIP URLs and the second should deal with tel URLs. It seems to me that the requirements for these are somewhat different. For sip URLs we assume that designated URLs are always emergency calls, and send them to the local emergency centre. For tel URLs, we have the additional problem of determining whether the related telephony number is an emergency local service number, and this issue requires considerable discussion in its own right, see later comments.

Perhaps we also need to take a step further back, and start with the user input itself. Perhaps we need a requirement that "UAs that determine that a dialog or transaction relates to an emergency MUST use an emergency call identifier in the Request-URI". Such a requirement would relate to where the user pushes the big red emergency button, and also to where input key sequences are analysed against a list of emergency related key sequences.

3)	section 3 (Emergency URI), last paragraph, text: 'The "sos" user name and user names starting with "sos." MUST NOT be assigned to any regular user.' I assume this a requirement relating specificly to SIP URLs, and is not a general URL requirement. It would be desirable to state this explicitly.

4)	section 3 (Emergency URI), last paragraph, text: 'It is RECOMMENDED that SIP MESSAGE requests are directed....' is presumably a requirement that must be taken in the context of section 4, i.e. it applies to all UAs and all proxies. It would be better specified in clause 4, and its applicability should be made clear. Further "SIP messaging" should presumably be "instant messaging" which is I believe the terminology used in the SIP MESSAGE RFC.

5)	section 3 (Emergency URI), 3rd paragraph: "In addition, user agents and proxies SHOULD also recognise the telephone numbers 911 and 112 ...". The 3GPP specification (3GPP TS 22.101) makes a somewhat longer list of numbers that should be applied. The following two sentences apply: 
-	"The following emergency numbers shall be stored in the ME for use when no emergency numbers are stored in the SIM/USIM: 000, 08, 112, 110,  911 and 999. "
-	"The following emergency numbers shall be stored in the ME for use without SIM/USIM: 000, 08, 112, 110, 118, 119, 911 and 999."
Given that the above lists work for all existing GSM phones in the countries of the world where GSM is used, which is most, it would seem sensible to use those lists rather than come up with a new IETF specific list. 
As to which list should be used, perhaps in fact the answer is both. The first list should apply where there is an additional number list in the SIP phone that is dynamically configurable by some external entity, and the second when there is not. More on these requirements in other comments.

6)	section 3 (Emergency URI), 3rd paragraph: use of "phone-context". Is it appropriate to use phone context in any emergency call. In 3GPP, any use of one of the numbers from the list stored in the phone is an emergency call, no matter where it originates from. If my understanding of phone-context is correct, it SHOULD NOT be used, as it could result in failure to deliver an emergency call.

7)	Section 4 (Request handling). There are mentions of "sos.*" in this text. Is the intent that "sos.*" should be a valid SIP URL with appropriate emergency call handling, or is it being used as a shorthand in this document to refer to those defined in section 3, and as such would not appear in a Request-URI? 

8)	Section 4 (Request handling), text: "It is RECOMMENDED that user agents periodically automatically check for the availability....". I consider that the use of this may be unnecessary in all cases. If the phone can be loaded with emergency numbers dynamically, and the update of those numbers is of reasonable frequency, then there is no need to regularly perform the OPTIONS request. For this reason, it would appear to be unnecessary for 3GPP phones. 

9)	Section 4 (Request handling): There seems to be an assumption that a local emergency number, e.g. 911 is more routeable in a network of SIP proxies than a sos URL. Surely this is a matter of local policy. Surely it is possible that the emergency call is entirely routed as a sos URL. Surely the main requirement is that the owner of the first proxy reached is responsible for routing it to an emergency call centre, and it is a matter of local policy how that is done.

10)	Section 4 (Request handling): Further the text should acknowledge that where a SIP outbound proxy exists then that can also perform such analysis of keyed numbers. Mechanisms for establishing an outbound proxy at registration time are standards track items. 3GPP accompanies all requests with the Mobile Country Code and the Mobile Network Code to assist in this analysis (where the analysis has failed at the phone). Some text for this is currently stated in section 3, but section 3 is the wrong place for this information.

11)	Section 5 (Request routing): I believe the text should acknowledge that at least some phones will have the capability of storing dynamically emergency numbers for use in analysing calls made with telephony type user input. 3GPP SIP phones will carry this requirement, and any SIP phone that uses some SIM like technology to carry subscription information is capable of being programmed at subscription time (i.e. delivery of the SIM to the subscriber) to carry the appropriate emergency numbers. It is becoming clear from the discussion that no one method is appropriate for doing this, but I believe there should be a discussion of the mechanisms that do exist, and any future SIP extensions should take account of that. Clause 5 should not be specific to the one mechanism that is specified here; for example 3GPP will use another mechanism and not one based on DHCP.

12)	If this draft is creating the sos URLs, should it not have an IANA considerations section telling IANA to register these URLs.


Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: drage@lucent.com 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan  6 14:08:26 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10778
	for <sipping-archive@odin.ietf.org>; Mon, 6 Jan 2003 14:08:26 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h06JImL06669
	for sipping-archive@odin.ietf.org; Mon, 6 Jan 2003 14:18:48 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06JImJ06663
	for <sipping-web-archive@optimus.ietf.org>; Mon, 6 Jan 2003 14:18:48 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10752
	for <sipping-web-archive@ietf.org>; Mon, 6 Jan 2003 14:07:49 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06JCQJ06494;
	Mon, 6 Jan 2003 14:12:26 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06JBmJ06457
	for <sipping@optimus.ietf.org>; Mon, 6 Jan 2003 14:11:48 -0500
Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10518
	for <sipping@ietf.org>; Mon, 6 Jan 2003 14:00:55 -0500 (EST)
Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11])
	by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h06J3g813457;
	Mon, 6 Jan 2003 19:03:42 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19)
	id <ZH2JFC5Q>; Mon, 6 Jan 2003 14:06:01 -0500
Message-ID: <15A2739B7DAA624D8091C65981D7DA815EB4DB@stntexch2.va.neustar.com>
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: "'Drage, Keith (Keith)'" <drage@lucent.com>,
        "Rosen, Brian"
	 <Brian.Rosen@marconi.com>,
        "'Henning Schulzrinne'" <hgs@cs.columbia.edu>
Cc: "'sipping@ietf.org'" <sipping@ietf.org>
Subject: RE: [Sipping] URIs for Gateways
Date: Mon, 6 Jan 2003 14:05:53 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>


RFC3325 was 'short-term' because it was achievable in the short-term and has
a more limited (but still useful) applicability. The long-term identity
solution must be a superset of the functionality of short-term - it must
address the short-term scope of applicability, but also encompass general
needs for network assertion (which SIP does have). Accordingly, it takes
longer to develop. At such a time as there is a workable long-term solution,
it would be pointless to allow both to be SIP standards except as part of a
transition plan. So in that sense, I disagree - one is a short-term solution
of the other.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Drage, Keith (Keith) [mailto:drage@lucent.com]
> Sent: Friday, January 03, 2003 8:20 AM
> To: Rosen, Brian; 'Henning Schulzrinne'
> Cc: 'sipping@ietf.org'
> Subject: RE: [Sipping] URIs for Gateways
> 
> 
> Network asserted identity (RFC 3325) is the real network 
> asserted identity. It is a P header not because it is 
> preliminary, but because the whole idea of network assertion 
> is not generally applicable to all SIP architectures. For RFC 
> 3325 a trust domain needs to exist between proxies that use 
> the P-Asserted-Identity in order to guarantee the privacy, 
> this does not exist in all SIP networks. In does in 3GPP and 
> therefore 3GPP are using RFC 3325.
> 
> If you want to let the 1et outbound proxy assert identity on 
> your behalf then use RFC 3325. If you want to let application 
> servers with whom you have a secure relationship assert your 
> identity, then use Jon Petersons drafts, when they eventually 
> become RFCs. 
> 
> One is not a short term solution for the other.
> 
> Keith
> 
> Keith Drage
> Lucent Technologies
> Tel: +44 1793 776249
> Email: drage@lucent.com 
> 
> > -----Original Message-----
> > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > Sent: 02 January 2003 20:49
> > To: 'Henning Schulzrinne'
> > Cc: 'sipping@ietf.org'
> > Subject: RE: [Sipping] URIs for Gateways
> > 
> > 
> > Yeah, I actually thought of just allowing a display name in the
> > Request URI and using that, but it seems so foolish to make 
> a change,
> > and have that change not be exactly what we needed.
> > 
> > We could use NAI.  I suppose we could use a P-Asserted-Identity
> > with a tel URI:  
> > P-Asserted-Identity tel:+17247426826
> > 
> > What do we do when the "real" NAI happens?
> > 
> > Brian
> > 
> > > -----Original Message-----
> > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> > > Sent: Thursday, January 02, 2003 3:10 PM
> > > To: Rosen, Brian
> > > Cc: 'sipping@ietf.org'
> > > Subject: Re: [Sipping] URIs for Gateways
> > > 
> > > 
> > > > I'd like to get a new header for the calling party number on
> > > > an outbound call.  That way, the translator can be a proxy and
> > > > add the header.  I'd recommend that gateways allow the number
> > > > to be in the From.   
> > > 
> > > Generalized, you want something like the Request-URI that can be 
> > > modified or inserted. How about the NAI stuff?
> > > 
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sip@ietf.org for new developments of core SIP
> > 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan  6 14:35:24 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11882
	for <sipping-archive@odin.ietf.org>; Mon, 6 Jan 2003 14:35:24 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h06JjjA08754
	for sipping-archive@odin.ietf.org; Mon, 6 Jan 2003 14:45:45 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06JjiJ08751
	for <sipping-web-archive@optimus.ietf.org>; Mon, 6 Jan 2003 14:45:44 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11847
	for <sipping-web-archive@ietf.org>; Mon, 6 Jan 2003 14:34:52 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06JVQJ07398;
	Mon, 6 Jan 2003 14:31:26 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06JUKJ07323
	for <sipping@optimus.ietf.org>; Mon, 6 Jan 2003 14:30:20 -0500
Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11238
	for <sipping@ietf.org>; Mon, 6 Jan 2003 14:19:28 -0500 (EST)
Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66])
	(user=hgs10 mech=PLAIN bits=0)
	by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h06JMdJE017331
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Mon, 6 Jan 2003 14:22:40 -0500 (EST)
Message-ID: <3E19D7A1.3060901@cs.columbia.edu>
Date: Mon, 06 Jan 2003 14:23:13 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Drage, Keith (Keith)" <drage@lucent.com>
CC: "Mills, Duncan, D, CND Tech Dev, VF UK" <Duncan.Mills@gb.vodafone.co.uk>,
        sipping@ietf.org
Subject: Re: [Sipping] Re: Comments on revised 'sos' draft
References: <475FF955A05DD411980D00508B6D5FB00439EB7B@en0033exch001u.uk.lucent.com>
In-Reply-To: <475FF955A05DD411980D00508B6D5FB00439EB7B@en0033exch001u.uk.lucent.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

> The relevant parts of the information is (from the 3GPP P-headers i-d):
> 
> cgi-3gpp               = "cgi-3gpp" EQUAL
>                                (token / quoted-string)
> utran-cell-id-3gpp     = "utran-cell-id-3gpp" EQUAL
>                                (token / quoted-string)
> 
> The values for "cgi-3gpp" and "utran-cell-id-3gpp"
>    are defined in 3GPP TS 24.229 [15].
> 
> 3GPP TS 24.229 then defines:
> 
> If the access type field is equal to "3GPP-UTRAN-FDD", "3GPP-UTRAN-TDD" or "3GPP-CDMA2000" the access info field shall contain a value for "utran-cell-id-3gpp" parameter. This value shall be made up of a concatenation of the MCC, MNC, LAC (as described in 3GPP TS 23.003) and the UMTS Cell Identity (as described in 3GPP TS 25.331), obtained from lower layers of the UE, and is coded as a text string as follows:
> Starting with the most significant bit, MCC (3 digits), MNC (2 or 3 digits depending on MCC value), LAC (fixed length code of 16 bits using full hexadecimal representation) and UMTS Cell Identity (fixed length code of 28 bits).
> 
> A similar definition exists for the GERAN type of access.
> 
> Other access mechanisms would be expected to make their own definitions of location information, as the structure of the data in this header is specific to the access mechanism, i.e. it has not been converted into a standard geodetic specification.
> 

I've added a reference to this. I suppose for an 802.11 wireless base 
station, the basestation MAC address would be the equivalent. Any 
interest in defining this, given that the draft already lists 
IEEE-802.11a and IEEE-802.11b as access-types?


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan  6 15:10:05 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13489
	for <sipping-archive@odin.ietf.org>; Mon, 6 Jan 2003 15:10:05 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h06KKRp11241
	for sipping-archive@odin.ietf.org; Mon, 6 Jan 2003 15:20:27 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06KKQJ11237
	for <sipping-web-archive@optimus.ietf.org>; Mon, 6 Jan 2003 15:20:26 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13475
	for <sipping-web-archive@ietf.org>; Mon, 6 Jan 2003 15:09:33 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06KHNJ11049;
	Mon, 6 Jan 2003 15:17:23 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06KDGJ10883
	for <sipping@optimus.ietf.org>; Mon, 6 Jan 2003 15:13:16 -0500
Received: from brazilnut.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13260
	for <sipping@ietf.org>; Mon, 6 Jan 2003 15:02:24 -0500 (EST)
Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66])
	(user=hgs10 mech=PLAIN bits=0)
	by brazilnut.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h06K5bK5018011
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Mon, 6 Jan 2003 15:05:37 -0500 (EST)
Message-ID: <3E19E1B3.5010205@cs.columbia.edu>
Date: Mon, 06 Jan 2003 15:06:11 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Drage, Keith (Keith)" <drage@lucent.com>
CC: "'sipping@ietf.org'" <sipping@ietf.org>
Subject: Re: [Sipping] Comments on sos draft -0 (scope)
References: <475FF955A05DD411980D00508B6D5FB00439EB7C@en0033exch001u.uk.lucent.com>
In-Reply-To: <475FF955A05DD411980D00508B6D5FB00439EB7C@en0033exch001u.uk.lucent.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Drage, Keith (Keith) wrote:
> Rather than reply to the other mails on this draft, I thought I
> should start from scratch on generating comments, although some of
> the comments below have some bearing on the discussions that are
> already taking place.
> 
> Comments on draft-schulzrinne-sipping-sos-03

Thanks for your extensive comments. Responses inline, where needed. I've 
split my response to keep it to a length that others may still read...

> 
> 1)	The document is missing an abstract which defines the scope. I am
> therefore unsure whether it is just a requirements document, or
> whether it is intended to be provide the total solution for emergency
> calls. My assumption is the latter, and therefore this ultimately
> will be the RFC that will register the sos and sos. urls, and will
> also define the actions of UAs and proxies in regard to emergency
> calls. However the latter presumably should be SIP actions, and
> should be in the SIP group. The following should therefore be done:
> 
> -	add an abstract detailing the scope of this specification -	if the
> document is to define requirements for SIP UAs and proxies, then
> decide whether it should be a SIP group draft.

Abstract updated as:

This document describes how SIP user agents and proxies can set up
emergency calls and, more generally, reach emergency assistance via SIP
requests.  For that purpose, it defines a universal emergency SIP URI,
sip:sos@domain and sips:sos@domain, that allows SIP user agents to
contact the local emergency number.  It also defines conventions that
increase the high probability of reaching the appropriate emergency call
center.  The document does not define any SIP protocol extensions.


Except for a reserved-name, the spec does not modify or extend SIP 
protocol behavior (that's the point). Thus, I don't think this requires 
SIP WG action. I believe this activity falls under WG charter item 2:

"2. Documenting the usage of SIP to solve real problems that need to be 
solved in a standardized way."



_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan  6 16:00:42 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14659
	for <sipping-archive@odin.ietf.org>; Mon, 6 Jan 2003 16:00:42 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h06LB5A14596
	for sipping-archive@odin.ietf.org; Mon, 6 Jan 2003 16:11:05 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06LB5J14593
	for <sipping-web-archive@optimus.ietf.org>; Mon, 6 Jan 2003 16:11:05 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14655
	for <sipping-web-archive@ietf.org>; Mon, 6 Jan 2003 16:00:10 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06KpAJ13255;
	Mon, 6 Jan 2003 15:51:10 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06KmnJ13148
	for <sipping@optimus.ietf.org>; Mon, 6 Jan 2003 15:48:49 -0500
Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14199
	for <sipping@ietf.org>; Mon, 6 Jan 2003 15:37:56 -0500 (EST)
Received: from dynamicsoft.com ([63.113.47.242])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h06KfCYH026152;
	Mon, 6 Jan 2003 15:41:12 -0500 (EST)
Message-ID: <3E19E9E5.3060002@dynamicsoft.com>
Date: Mon, 06 Jan 2003 15:41:09 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: William Marshall <wtm@research.att.com>
CC: sipping@ietf.org
Subject: Re: [Sipping] Re: Comments on revised 'sos' draft
References: <200301061224.HAA06165@fish.research.att.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit



William Marshall wrote:
> Jonathan wrote:
> 
>>It is most certainly not "under-specified".
> 
> 
> I'll conceed on the first point (a rejected BYE), but not yet on the second.
> 
> Nowhere in RFC3261 does it state that if SIP is being used to control
> a 2500-style telehpone handset, and that handset goes to an "onhook" 
> state with a session active, that the UA MUST send a BYE.

Of course.

My point was that if it DID send a BYE, the behavior would be to send a 481.

> 
> If the UA does not, due e.g. to knowing that it just called a number
> such as 9-1-1, and the PSAP sends a mid-call INVITE with all the
> proper Route headers and Contact values and tags, it will certainly
> match the existing dialog at the UA, so will not be a new INVITE.
> So a 481 is not the proper response.  Is 180-Ringing allowable?

Sure, the UAS can send a 180. Whether the UA would "alert" the user when 
receiving a re-INVITE is a matter of UI, and not subject to 
specification. The intent of the re-INVITE is standardized, though - to 
modify session characteristics. Thus a UA would decide whether to alert 
the user based on this definition. It would not be correct to interpret 
the re-INVITE as specifically for the purposes of PSAP initiated ring, 
however.

-JOnathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan  6 16:25:49 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15263
	for <sipping-archive@odin.ietf.org>; Mon, 6 Jan 2003 16:25:49 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h06LaDK15603
	for sipping-archive@odin.ietf.org; Mon, 6 Jan 2003 16:36:13 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06LaDJ15600
	for <sipping-web-archive@optimus.ietf.org>; Mon, 6 Jan 2003 16:36:13 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15237
	for <sipping-web-archive@ietf.org>; Mon, 6 Jan 2003 16:25:17 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06LXKJ15466;
	Mon, 6 Jan 2003 16:33:20 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06LTUJ15310
	for <sipping@optimus.ietf.org>; Mon, 6 Jan 2003 16:29:30 -0500
Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15080
	for <sipping@ietf.org>; Mon, 6 Jan 2003 16:18:35 -0500 (EST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA27682;
	Mon, 6 Jan 2003 16:21:48 -0500 (EST)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA25227;
	Mon, 6 Jan 2003 16:21:49 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <ZVACJ45F>; Mon, 6 Jan 2003 16:21:48 -0500
Message-ID: <313680C9A886D511A06000204840E1CF030B5CC4@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Peterson, Jon'" <jon.peterson@neustar.biz>,
        "'Drage, Keith (Keith)'"
	 <drage@lucent.com>,
        "Rosen, Brian" <Brian.Rosen@marconi.com>,
        "'Henning Schulzrinne'" <hgs@cs.columbia.edu>
Cc: "'sipping@ietf.org'" <sipping@ietf.org>
Subject: RE: [Sipping] URIs for Gateways
Date: Mon, 6 Jan 2003 16:21:42 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

I agree with this.  I'm confused by those who seem to think that
P-Asserted-Identity is needed when the long term solution is
fully baked.  If the UA knows its identity, which seems
reasonable, then it can "assert" it, and have that assertion
validated by a trusted entity using cryptographic means.
That is the fundamental idea I get out of Jon's proposal.
The only circumstance where that won't work is where the
UA doesn't know its identity.  I don't see that as a problem
on any network I'm aware of, but ...... keep reading.

I do think there is a problem which this whole thread talks about.
The basic reality is that many users of SIP UAs will have two
identities - a SIP URI and a telephone number.  It may be
necessary to assert both identities in one call, because the
originator of the call does not know which identity may be
needed.  There is no current header to do this.  I think that 
it is advantageous to have a proxy be able to assert the phone 
number.  Otherwise EVERY UA will have to be able to understand 
that two identities are possible, know them both by some 
unspecified means, and assert them in every call on every UA.  
This seems unreasonable.  I'm not sure that there is a reason
to have both identities validated, but there could be.

Brian
> -----Original Message-----
> From: Peterson, Jon [mailto:jon.peterson@neustar.biz]
> Sent: Monday, January 06, 2003 2:06 PM
> To: 'Drage, Keith (Keith)'; Rosen, Brian; 'Henning Schulzrinne'
> Cc: 'sipping@ietf.org'
> Subject: RE: [Sipping] URIs for Gateways
> 
> 
> 
> RFC3325 was 'short-term' because it was achievable in the 
> short-term and has
> a more limited (but still useful) applicability. The 
> long-term identity
> solution must be a superset of the functionality of 
> short-term - it must
> address the short-term scope of applicability, but also 
> encompass general
> needs for network assertion (which SIP does have). 
> Accordingly, it takes
> longer to develop. At such a time as there is a workable 
> long-term solution,
> it would be pointless to allow both to be SIP standards 
> except as part of a
> transition plan. So in that sense, I disagree - one is a 
> short-term solution
> of the other.
> 
> Jon Peterson
> NeuStar, Inc.
> 
> > -----Original Message-----
> > From: Drage, Keith (Keith) [mailto:drage@lucent.com]
> > Sent: Friday, January 03, 2003 8:20 AM
> > To: Rosen, Brian; 'Henning Schulzrinne'
> > Cc: 'sipping@ietf.org'
> > Subject: RE: [Sipping] URIs for Gateways
> > 
> > 
> > Network asserted identity (RFC 3325) is the real network 
> > asserted identity. It is a P header not because it is 
> > preliminary, but because the whole idea of network assertion 
> > is not generally applicable to all SIP architectures. For RFC 
> > 3325 a trust domain needs to exist between proxies that use 
> > the P-Asserted-Identity in order to guarantee the privacy, 
> > this does not exist in all SIP networks. In does in 3GPP and 
> > therefore 3GPP are using RFC 3325.
> > 
> > If you want to let the 1et outbound proxy assert identity on 
> > your behalf then use RFC 3325. If you want to let application 
> > servers with whom you have a secure relationship assert your 
> > identity, then use Jon Petersons drafts, when they eventually 
> > become RFCs. 
> > 
> > One is not a short term solution for the other.
> > 
> > Keith
> > 
> > Keith Drage
> > Lucent Technologies
> > Tel: +44 1793 776249
> > Email: drage@lucent.com 
> > 
> > > -----Original Message-----
> > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > > Sent: 02 January 2003 20:49
> > > To: 'Henning Schulzrinne'
> > > Cc: 'sipping@ietf.org'
> > > Subject: RE: [Sipping] URIs for Gateways
> > > 
> > > 
> > > Yeah, I actually thought of just allowing a display name in the
> > > Request URI and using that, but it seems so foolish to make 
> > a change,
> > > and have that change not be exactly what we needed.
> > > 
> > > We could use NAI.  I suppose we could use a P-Asserted-Identity
> > > with a tel URI:  
> > > P-Asserted-Identity tel:+17247426826
> > > 
> > > What do we do when the "real" NAI happens?
> > > 
> > > Brian
> > > 
> > > > -----Original Message-----
> > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> > > > Sent: Thursday, January 02, 2003 3:10 PM
> > > > To: Rosen, Brian
> > > > Cc: 'sipping@ietf.org'
> > > > Subject: Re: [Sipping] URIs for Gateways
> > > > 
> > > > 
> > > > > I'd like to get a new header for the calling party number on
> > > > > an outbound call.  That way, the translator can be a proxy and
> > > > > add the header.  I'd recommend that gateways allow the number
> > > > > to be in the From.   
> > > > 
> > > > Generalized, you want something like the Request-URI 
> that can be 
> > > > modified or inserted. How about the NAI stuff?
> > > > 
> > > _______________________________________________
> > > Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> > > This list is for NEW development of the application of SIP
> > > Use sip-implementors@cs.columbia.edu for questions on current sip
> > > Use sip@ietf.org for new developments of core SIP
> > > 
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sip@ietf.org for new developments of core SIP
> > 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan  6 17:15:10 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17143
	for <sipping-archive@odin.ietf.org>; Mon, 6 Jan 2003 17:15:10 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h06MPZc20456
	for sipping-archive@odin.ietf.org; Mon, 6 Jan 2003 17:25:35 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06MPZJ20453
	for <sipping-web-archive@optimus.ietf.org>; Mon, 6 Jan 2003 17:25:35 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17139
	for <sipping-web-archive@ietf.org>; Mon, 6 Jan 2003 17:14:39 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06MMSJ20242;
	Mon, 6 Jan 2003 17:22:28 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06MJHJ19882
	for <sipping@optimus.ietf.org>; Mon, 6 Jan 2003 17:19:17 -0500
Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16844
	for <sipping@ietf.org>; Mon, 6 Jan 2003 17:08:21 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h06MCAos001291;
	Mon, 6 Jan 2003 17:12:10 -0500 (EST)
Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAX42166;
	Mon, 6 Jan 2003 17:16:31 -0500 (EST)
Message-ID: <3E19FF11.5000806@cisco.com>
Date: Mon, 06 Jan 2003 17:11:29 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: William Marshall <wtm@research.att.com>, sipping@ietf.org
Subject: Re: [Sipping] Re: Comments on revised 'sos' draft
References: <200301061224.HAA06165@fish.research.att.com> <3E19E9E5.3060002@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:
> 
>> If the UA does not, due e.g. to knowing that it just called a number
>> such as 9-1-1, and the PSAP sends a mid-call INVITE with all the
>> proper Route headers and Contact values and tags, it will certainly
>> match the existing dialog at the UA, so will not be a new INVITE.
>> So a 481 is not the proper response.  Is 180-Ringing allowable?
> 
> 
> Sure, the UAS can send a 180. Whether the UA would "alert" the user when 
> receiving a re-INVITE is a matter of UI, and not subject to 
> specification. The intent of the re-INVITE is standardized, though - to 
> modify session characteristics. Thus a UA would decide whether to alert 
> the user based on this definition. It would not be correct to interpret 
> the re-INVITE as specifically for the purposes of PSAP initiated ring, 
> however.

While there is probably nothing wrong with returning a 180 in this case, 
I believe there is something wrong with then actually ringing the phone 
and waiting for it to to go off hook before sending a final response.

The reason is that this is a reINVITE. There has been a bunch of 
discussion of call flows involving reinvite, and the need for it to 
complete without an extended delay.

Perhaps that decision could be reopened now. I have some other cases 
where it is desirable to permit alerting, with the associated delay, on 
a reinvite. But it will be messy to reopen that can of worms.

	Paul

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan  6 18:14:00 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18354
	for <sipping-archive@odin.ietf.org>; Mon, 6 Jan 2003 18:14:00 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h06NOQH23786
	for sipping-archive@odin.ietf.org; Mon, 6 Jan 2003 18:24:26 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06NOQJ23783
	for <sipping-web-archive@optimus.ietf.org>; Mon, 6 Jan 2003 18:24:26 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18335
	for <sipping-web-archive@ietf.org>; Mon, 6 Jan 2003 18:13:14 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06NLTJ23670;
	Mon, 6 Jan 2003 18:21:29 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06NILJ23559
	for <sipping@optimus.ietf.org>; Mon, 6 Jan 2003 18:18:21 -0500
Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18260
	for <sipping@ietf.org>; Mon, 6 Jan 2003 18:07:23 -0500 (EST)
Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66])
	(user=hgs10 mech=PLAIN bits=0)
	by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h06NAbJE013511
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Mon, 6 Jan 2003 18:10:38 -0500 (EST)
Message-ID: <3E1A0D0F.3090505@cs.columbia.edu>
Date: Mon, 06 Jan 2003 18:11:11 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Drage, Keith (Keith)" <drage@lucent.com>
CC: "'sipping@ietf.org'" <sipping@ietf.org>
Subject: Re: [Sipping] Comments on sos draft -03 (URI)
References: <475FF955A05DD411980D00508B6D5FB00439EB7C@en0033exch001u.uk.lucent.com>
In-Reply-To: <475FF955A05DD411980D00508B6D5FB00439EB7C@en0033exch001u.uk.lucent.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

> 5)	section 3 (Emergency URI), 3rd paragraph: "In addition, user
> two sentences apply: -	"The following emergency numbers shall be
> stored in the ME for use when no emergency numbers are stored in the
> SIM/USIM: 000, 08, 112, 110,  911 and 999. " -	"The following

Good idea. The only difference seems to be 118 and 119.

> 6)	section 3 (Emergency URI), 3rd paragraph: use of "phone-context".
> Is it appropriate to use phone context in any emergency call. In
> 3GPP, any use of one of the numbers from the list stored in the phone
> is an emergency call, no matter where it originates from. If my
> understanding of phone-context is correct, it SHOULD NOT be used, as
> it could result in failure to deliver an emergency call.
> 

I wrote this before the most recent phone-context discussion and I tend 
to agree. If there's to be a phone context at all, it would need to be 
something like 'sos' or some other recognized identifier. The problem 
occurs with 118 and 119, which presumably are omitted from the shorter 
list since they mean something other than emergency somewhere. 
(Apparently, 118 is directory assistance in the UK; 119 is fire in 
Japan.) The outbound proxy doesn't know whether the phone was configured 
with a local list or not, so it needs to be able to tell whether tel:118 
is emergency or something else.

One simple, pragmatic rule would be that numbers from the longer list 
without context always mean emergency.


> 8)	Section 4 (Request handling), text: "It is RECOMMENDED that user
> agents periodically automatically check for the availability....". I
> consider that the use of this may be unnecessary in all cases. If the
> phone can be loaded with emergency numbers dynamically, and the
> update of those numbers is of reasonable frequency, then there is no
> need to regularly perform the OPTIONS request. For this reason, it
> would appear to be unnecessary for 3GPP phones.

The problem is that I can't rely on a local friendly outbound proxy that 
knows how to handle either sip:sos or tel:XXX. You can mandate this for 
3GPP providers, but not all VoIP systems will be run by common carriers.

I'm reluctant to encode 'I'm a 3GPP phone, so I don't need to do this' 
into the protocol. After all, this 3GPP phone may also use your friendly 
neighborhood 802.11 hotspot.


> 
> 9)	Section 4 (Request handling): There seems to be an assumption that
> a local emergency number, e.g. 911 is more routeable in a network of
> SIP proxies than a sos URL. Surely this is a matter of local policy.
> Surely it is possible that the emergency call is entirely routed as a
> sos URL. Surely the main requirement is that the owner of the first
> proxy reached is responsible for routing it to an emergency call
> centre, and it is a matter of local policy how that is done.

This wasn't the intent. I'll reword.

> 
> 10)	Section 4 (Request handling): Further the text should acknowledge
> that where a SIP outbound proxy exists then that can also perform
> such analysis of keyed numbers. Mechanisms for establishing an
> outbound proxy at registration time are standards track items. 3GPP
> accompanies all requests with the Mobile Country Code and the Mobile
> Network Code to assist in this analysis (where the analysis has
> failed at the phone). Some text for this is currently stated in
> section 3, but section 3 is the wrong place for this information.

Moved and reworded.


> 12)	If this draft is creating the sos URLs, should it not have an
> IANA considerations section telling IANA to register these URLs.

There will be a section on registering additional sos.* services. There 
currently is no registry for reserved SIP user identities and tel URIs. 
Should there be?

Henning

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan  6 21:17:07 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21623
	for <sipping-archive@odin.ietf.org>; Mon, 6 Jan 2003 21:17:07 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h072Ra202374
	for sipping-archive@odin.ietf.org; Mon, 6 Jan 2003 21:27:36 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h072RaJ02371
	for <sipping-web-archive@optimus.ietf.org>; Mon, 6 Jan 2003 21:27:36 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21575
	for <sipping-web-archive@ietf.org>; Mon, 6 Jan 2003 21:13:43 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h072M1J02251;
	Mon, 6 Jan 2003 21:22:01 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h072KYJ02202
	for <sipping@optimus.ietf.org>; Mon, 6 Jan 2003 21:20:34 -0500
Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21542
	for <sipping@ietf.org>; Mon, 6 Jan 2003 21:09:34 -0500 (EST)
Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66])
	(user=hgs10 mech=PLAIN bits=0)
	by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h072Cmkw019502
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT)
	for <sipping@ietf.org>; Mon, 6 Jan 2003 21:12:48 -0500 (EST)
Message-ID: <3E1A37C0.5050104@cs.columbia.edu>
Date: Mon, 06 Jan 2003 21:13:20 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "'sipping@ietf.org'" <sipping@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sipping] New -sos- draft (04)
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

http://www.cs.columbia.edu/sip/drafts/draft-schulzrinne-sipping-sos-04.txt

will be submitted shortly, hopefully reflecting the comments received. 
Additional comments are most welcome.

Henning

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Tue Jan  7 02:51:32 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06358
	for <sipping-archive@odin.ietf.org>; Tue, 7 Jan 2003 02:51:32 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h07828131741
	for sipping-archive@odin.ietf.org; Tue, 7 Jan 2003 03:02:08 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07827J31738
	for <sipping-web-archive@optimus.ietf.org>; Tue, 7 Jan 2003 03:02:07 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06352
	for <sipping-web-archive@ietf.org>; Tue, 7 Jan 2003 02:51:01 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h077ujJ31430;
	Tue, 7 Jan 2003 02:56:45 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h077tHJ31373
	for <sipping@optimus.ietf.org>; Tue, 7 Jan 2003 02:55:17 -0500
Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06265
	for <sipping@ietf.org>; Tue, 7 Jan 2003 02:44:10 -0500 (EST)
From: jh@lohi.eng.song.fi
Received: from harjus.eng.song.fi ([195.10.149.20])
	by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian))
	id 18VoSB-0000Bv-00; Tue, 07 Jan 2003 09:47:15 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15898.34306.984596.183022@harjus.eng.song.fi>
Date: Tue, 7 Jan 2003 09:47:14 +0200
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
Cc: "'Peterson, Jon'" <jon.peterson@neustar.biz>,
        "'Drage, Keith (Keith)'"
	 <drage@lucent.com>,
        "'Henning Schulzrinne'" <hgs@cs.columbia.edu>,
        "'sipping@ietf.org'" <sipping@ietf.org>
Subject: RE: [Sipping] URIs for Gateways
In-Reply-To: <313680C9A886D511A06000204840E1CF030B5CC4@whq-msgusr-02.pit.comms.marconi.com>
References: <313680C9A886D511A06000204840E1CF030B5CC4@whq-msgusr-02.pit.comms.marconi.com>
X-Mailer: VM 7.03 under Emacs 21.2.1
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Rosen, Brian writes:

 > I do think there is a problem which this whole thread talks about.
 > The basic reality is that many users of SIP UAs will have two
 > identities - a SIP URI and a telephone number.  It may be
 > necessary to assert both identities in one call, because the
 > originator of the call does not know which identity may be
 > needed.  There is no current header to do this.  I think that 
 > it is advantageous to have a proxy be able to assert the phone 
 > number.  Otherwise EVERY UA will have to be able to understand 
 > that two identities are possible, know them both by some 
 > unspecified means, and assert them in every call on every UA.  
 > This seems unreasonable.  I'm not sure that there is a reason
 > to have both identities validated, but there could be.

if your proxy receives a call from sip:foo@bar.com who has also been
allocated a phone number +1234567890, why can't is add an asserted
identity header containing sip:+1234567890@bar.com to the call in case
the call is bound to pstn?  why would you need yet another header for
that purpose?

-- juha

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Tue Jan  7 06:40:14 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10097
	for <sipping-archive@odin.ietf.org>; Tue, 7 Jan 2003 06:40:14 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h07Botn13513
	for sipping-archive@odin.ietf.org; Tue, 7 Jan 2003 06:50:55 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07BotJ13510
	for <sipping-web-archive@optimus.ietf.org>; Tue, 7 Jan 2003 06:50:55 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10083
	for <sipping-web-archive@ietf.org>; Tue, 7 Jan 2003 06:39:42 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07BgZJ13102;
	Tue, 7 Jan 2003 06:42:35 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07Bf6J12949
	for <sipping@optimus.ietf.org>; Tue, 7 Jan 2003 06:41:06 -0500
Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09875
	for <sipping@ietf.org>; Tue, 7 Jan 2003 06:29:53 -0500 (EST)
Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11])
	by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h07BWw825862;
	Tue, 7 Jan 2003 11:32:58 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19)
	id <ZH2JFHM5>; Tue, 7 Jan 2003 06:35:18 -0500
Message-ID: <15A2739B7DAA624D8091C65981D7DA815EB4E6@stntexch2.va.neustar.com>
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: "'Rosen, Brian'" <Brian.Rosen@marconi.com>,
        "'Drage, Keith (Keith)'"
	 <drage@lucent.com>,
        "'Henning Schulzrinne'" <hgs@cs.columbia.edu>
Cc: "'sipping@ietf.org'" <sipping@ietf.org>
Subject: RE: [Sipping] URIs for Gateways
Date: Tue, 7 Jan 2003 06:35:17 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>


First, it is possible, with the long-term identity mechanism, to assert two
identities in an authenticated identity body. So, you could have headers
corresponding to a telephone number and a SIP URI of a gateway or a user -
it strikes me that a telephone number is a good Reply-To, actually, when a
call comes from a gateway (originating in the PSTN, say) and the From header
field contains a SIP URI for the gateway, perhaps including some port
information. The identity that the gateway which handles a PSTN-SIP call
would assert needs to be its own, and recipients of calls from gateways need
to trust the telephone number provided by the gateway or not accordingly
(i.e. a signature from att.com vouching for such a request should be
acceptable).

Technologies like ENUM (when/where available) could enable gateways to
convert originating telephone numbers into URIs. Of course, a gateway
wouldn't be able to assert that identity to an intermediary unless it
possessed credentials appropriate to that URI, which is unlikely.

For outbound calls (SIP-PSTN), the gateway may or may not be able to map
(authenticated) SIP URIs representing originators to appropriate telephone
numbers via some sort of local tables as you suggested. If not, might also
pick a number from a pool, sure. The question of whether some authentication
service should be able to assert an originating telephone number (in an
authenticated identity body, say) that a gateway will use is also a trust
question - it is possible to put the tel URL in the AIB. If the gateway has
a reason to trust the authentication service, then certainly it should send
that number to the PSTN (when the protocol allows gateways to supply a
number, like with ISUP or Q.931). The gateway would be very ill advised to
take just any authentication service's word on this matter, though. 

The target of the calls for the PSTN should be identified with a telephone
number - at least, by the time the call arrives a gateway, it's Request-URI
should contain a tel URL or a SIP URI with a tel URL component. Whether the
originating UAC sets the To header field to a tel URL or a subsequent proxy
retargets the request doesn't seem to make much difference. ENUM can also
play a pretty obvious role here.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: Monday, January 06, 2003 1:22 PM
> To: 'Peterson, Jon'; 'Drage, Keith (Keith)'; Rosen, Brian; 'Henning
> Schulzrinne'
> Cc: 'sipping@ietf.org'
> Subject: RE: [Sipping] URIs for Gateways
> 
> 
> I agree with this.  I'm confused by those who seem to think that
> P-Asserted-Identity is needed when the long term solution is
> fully baked.  If the UA knows its identity, which seems
> reasonable, then it can "assert" it, and have that assertion
> validated by a trusted entity using cryptographic means.
> That is the fundamental idea I get out of Jon's proposal.
> The only circumstance where that won't work is where the
> UA doesn't know its identity.  I don't see that as a problem
> on any network I'm aware of, but ...... keep reading.
> 
> I do think there is a problem which this whole thread talks about.
> The basic reality is that many users of SIP UAs will have two
> identities - a SIP URI and a telephone number.  It may be
> necessary to assert both identities in one call, because the
> originator of the call does not know which identity may be
> needed.  There is no current header to do this.  I think that 
> it is advantageous to have a proxy be able to assert the phone 
> number.  Otherwise EVERY UA will have to be able to understand 
> that two identities are possible, know them both by some 
> unspecified means, and assert them in every call on every UA.  
> This seems unreasonable.  I'm not sure that there is a reason
> to have both identities validated, but there could be.
> 
> Brian
> > -----Original Message-----
> > From: Peterson, Jon [mailto:jon.peterson@neustar.biz]
> > Sent: Monday, January 06, 2003 2:06 PM
> > To: 'Drage, Keith (Keith)'; Rosen, Brian; 'Henning Schulzrinne'
> > Cc: 'sipping@ietf.org'
> > Subject: RE: [Sipping] URIs for Gateways
> > 
> > 
> > 
> > RFC3325 was 'short-term' because it was achievable in the 
> > short-term and has
> > a more limited (but still useful) applicability. The 
> > long-term identity
> > solution must be a superset of the functionality of 
> > short-term - it must
> > address the short-term scope of applicability, but also 
> > encompass general
> > needs for network assertion (which SIP does have). 
> > Accordingly, it takes
> > longer to develop. At such a time as there is a workable 
> > long-term solution,
> > it would be pointless to allow both to be SIP standards 
> > except as part of a
> > transition plan. So in that sense, I disagree - one is a 
> > short-term solution
> > of the other.
> > 
> > Jon Peterson
> > NeuStar, Inc.
> > 
> > > -----Original Message-----
> > > From: Drage, Keith (Keith) [mailto:drage@lucent.com]
> > > Sent: Friday, January 03, 2003 8:20 AM
> > > To: Rosen, Brian; 'Henning Schulzrinne'
> > > Cc: 'sipping@ietf.org'
> > > Subject: RE: [Sipping] URIs for Gateways
> > > 
> > > 
> > > Network asserted identity (RFC 3325) is the real network 
> > > asserted identity. It is a P header not because it is 
> > > preliminary, but because the whole idea of network assertion 
> > > is not generally applicable to all SIP architectures. For RFC 
> > > 3325 a trust domain needs to exist between proxies that use 
> > > the P-Asserted-Identity in order to guarantee the privacy, 
> > > this does not exist in all SIP networks. In does in 3GPP and 
> > > therefore 3GPP are using RFC 3325.
> > > 
> > > If you want to let the 1et outbound proxy assert identity on 
> > > your behalf then use RFC 3325. If you want to let application 
> > > servers with whom you have a secure relationship assert your 
> > > identity, then use Jon Petersons drafts, when they eventually 
> > > become RFCs. 
> > > 
> > > One is not a short term solution for the other.
> > > 
> > > Keith
> > > 
> > > Keith Drage
> > > Lucent Technologies
> > > Tel: +44 1793 776249
> > > Email: drage@lucent.com 
> > > 
> > > > -----Original Message-----
> > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > > > Sent: 02 January 2003 20:49
> > > > To: 'Henning Schulzrinne'
> > > > Cc: 'sipping@ietf.org'
> > > > Subject: RE: [Sipping] URIs for Gateways
> > > > 
> > > > 
> > > > Yeah, I actually thought of just allowing a display name in the
> > > > Request URI and using that, but it seems so foolish to make 
> > > a change,
> > > > and have that change not be exactly what we needed.
> > > > 
> > > > We could use NAI.  I suppose we could use a P-Asserted-Identity
> > > > with a tel URI:  
> > > > P-Asserted-Identity tel:+17247426826
> > > > 
> > > > What do we do when the "real" NAI happens?
> > > > 
> > > > Brian
> > > > 
> > > > > -----Original Message-----
> > > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> > > > > Sent: Thursday, January 02, 2003 3:10 PM
> > > > > To: Rosen, Brian
> > > > > Cc: 'sipping@ietf.org'
> > > > > Subject: Re: [Sipping] URIs for Gateways
> > > > > 
> > > > > 
> > > > > > I'd like to get a new header for the calling party number on
> > > > > > an outbound call.  That way, the translator can be 
> a proxy and
> > > > > > add the header.  I'd recommend that gateways allow 
> the number
> > > > > > to be in the From.   
> > > > > 
> > > > > Generalized, you want something like the Request-URI 
> > that can be 
> > > > > modified or inserted. How about the NAI stuff?
> > > > > 
> > > > _______________________________________________
> > > > Sipping mailing list  
> > https://www1.ietf.org/mailman/listinfo/sipping
> > > > This list is for NEW development of the application of SIP
> > > > Use sip-implementors@cs.columbia.edu for questions on 
> current sip
> > > > Use sip@ietf.org for new developments of core SIP
> > > > 
> > > _______________________________________________
> > > Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> > > This list is for NEW development of the application of SIP
> > > Use sip-implementors@cs.columbia.edu for questions on current sip
> > > Use sip@ietf.org for new developments of core SIP
> > > 
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sip@ietf.org for new developments of core SIP
> > 
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Tue Jan  7 06:49:23 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10286
	for <sipping-archive@odin.ietf.org>; Tue, 7 Jan 2003 06:49:23 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h07C05h13861
	for sipping-archive@odin.ietf.org; Tue, 7 Jan 2003 07:00:05 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07C04J13858
	for <sipping-web-archive@optimus.ietf.org>; Tue, 7 Jan 2003 07:00:04 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10259
	for <sipping-web-archive@ietf.org>; Tue, 7 Jan 2003 06:48:51 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07Bq7J13613;
	Tue, 7 Jan 2003 06:52:07 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07BpBJ13541
	for <sipping@optimus.ietf.org>; Tue, 7 Jan 2003 06:51:11 -0500
Received: from relay4.clb.oleane.net (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10091
	for <sipping@ietf.org>; Tue, 7 Jan 2003 06:39:58 -0500 (EST)
Received: from oleane (upper-side.rain.fr [194.250.212.114]) 
	by relay4.clb.oleane.net with SMTP id h07BhCDh031150
	for <sipping@ietf.org>; Tue, 7 Jan 2003 12:43:13 +0100
Message-ID: <01f301c2b643$343137a0$0601a8c0@oleane.com>
From: "Peter Lewis" <peter.lewis@upperside.fr>
To: <sipping@ietf.org>
Date: Tue, 7 Jan 2003 12:52:06 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_01F0_01C2B64B.95AADB00"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Subject: [Sipping] The International SIP 2003 Conference
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_01F0_01C2B64B.95AADB00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Happy New Year and all the best for you and your family!=20

The International SIP 2003 Conference is going to take place in Paris in =
one week, from the=20
14th to the 17th of January 03.=20

You can still register for the conference at: =
http://www.upperside.fr/intersip03/sip03earlyreg.htm=20


------=_NextPart_000_01F0_01C2B64B.95AADB00
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>
<DIV><FONT face=3DArial size=3D2>Happy New Year and all the best for you =
and your=20
family! <BR><BR><B><FONT color=3D#996699>The International SIP 2003=20
Conference</FONT></B> is going to take place in Paris in one week, from =
the=20
<U><BR>14th to the 17th of January 03</U>. <BR><BR>You can still =
register for=20
the conference at: <A=20
href=3D"http://www.upperside.fr/intersip03/sip03earlyreg.htm">http://www.=
upperside.fr/intersip03/sip03earlyreg.htm</A>=20
</FONT></DIV>
<DIV>&nbsp;</DIV></DIV></BODY></HTML>

------=_NextPart_000_01F0_01C2B64B.95AADB00--

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Tue Jan  7 08:37:56 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12679
	for <sipping-archive@odin.ietf.org>; Tue, 7 Jan 2003 08:37:56 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h07Dme720514
	for sipping-archive@odin.ietf.org; Tue, 7 Jan 2003 08:48:40 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07DmeJ20511
	for <sipping-web-archive@optimus.ietf.org>; Tue, 7 Jan 2003 08:48:40 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12671
	for <sipping-web-archive@ietf.org>; Tue, 7 Jan 2003 08:37:24 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07DfjJ20208;
	Tue, 7 Jan 2003 08:41:46 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07De5J20093
	for <sipping@optimus.ietf.org>; Tue, 7 Jan 2003 08:40:05 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12023;
	Tue, 7 Jan 2003 08:28:50 -0500 (EST)
Message-Id: <200301071328.IAA12023@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: sipping@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Tue, 07 Jan 2003 08:28:49 -0500
Subject: [Sipping] I-D ACTION:draft-rosenberg-sipping-session-policy-req-00.txt
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Requirements for Session Policy for the Session 
                          Initiation Protocol (SIP)
	Author(s)	: J. Rosenberg
	Filename	: draft-rosenberg-sipping-session-policy-req-00.txt
	Pages		: 15
	Date		: 2003-1-6
	
The proxy server plays a central role as an intermediary in the
establishment of sessions in the Session Initiation Protocol (SIP).
In that role, they can define and impact policies on call routing,
rendezvous, and other call features.  However, there is no standard
means by which proxies can have any influence on session policies,
such as the codecs that are to be used.  As such, ad-hoc and
non-conformant techniques have been deployed to allow for such policy
mechanisms.  There is a need for a standards-based and complete
mechanism for session policies.  This document defines a set of
requirements for such a mechanism.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-session-policy-req-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-rosenberg-sipping-session-policy-req-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-rosenberg-sipping-session-policy-req-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-1-6145302.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-rosenberg-sipping-session-policy-req-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-rosenberg-sipping-session-policy-req-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-1-6145302.I-D@ietf.org>

--OtherAccess--

--NextPart--


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Tue Jan  7 08:50:26 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13670
	for <sipping-archive@odin.ietf.org>; Tue, 7 Jan 2003 08:50:26 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h07E1Bv21347
	for sipping-archive@odin.ietf.org; Tue, 7 Jan 2003 09:01:11 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07E1BJ21344
	for <sipping-web-archive@optimus.ietf.org>; Tue, 7 Jan 2003 09:01:11 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13626
	for <sipping-web-archive@ietf.org>; Tue, 7 Jan 2003 08:49:55 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07Do5J20627;
	Tue, 7 Jan 2003 08:50:05 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07DnTJ20588
	for <sipping@optimus.ietf.org>; Tue, 7 Jan 2003 08:49:29 -0500
Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12694
	for <sipping@ietf.org>; Tue, 7 Jan 2003 08:38:13 -0500 (EST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA17718;
	Tue, 7 Jan 2003 08:41:28 -0500 (EST)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA13770;
	Tue, 7 Jan 2003 08:41:28 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <ZVACKC44>; Tue, 7 Jan 2003 08:41:27 -0500
Message-ID: <313680C9A886D511A06000204840E1CF030B5CCB@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'jh@lohi.eng.song.fi'" <jh@lohi.eng.song.fi>
Cc: "'Peterson, Jon'" <jon.peterson@neustar.biz>,
        "'Drage, Keith (Keith)'"
	 <drage@lucent.com>,
        "'Henning Schulzrinne'" <hgs@cs.columbia.edu>,
        "'sipping@ietf.org'" <sipping@ietf.org>
Subject: RE: [Sipping] URIs for Gateways
Date: Tue, 7 Jan 2003 08:41:22 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

It may be that we want to use P-Asserted-Identity for this
purpose.  I currently think it's a pretty good idea, but:
	* It doesn't really meet the definition in RFC3325
	* The "P" bothers me if this is a permanent solution
Brian

> -----Original Message-----
> From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi]
> Sent: Tuesday, January 07, 2003 2:47 AM
> To: Rosen, Brian
> Cc: 'Peterson, Jon'; 'Drage, Keith (Keith)'; 'Henning Schulzrinne';
> 'sipping@ietf.org'
> Subject: RE: [Sipping] URIs for Gateways
> 
> 
> Rosen, Brian writes:
> 
>  > I do think there is a problem which this whole thread talks about.
>  > The basic reality is that many users of SIP UAs will have two
>  > identities - a SIP URI and a telephone number.  It may be
>  > necessary to assert both identities in one call, because the
>  > originator of the call does not know which identity may be
>  > needed.  There is no current header to do this.  I think that 
>  > it is advantageous to have a proxy be able to assert the phone 
>  > number.  Otherwise EVERY UA will have to be able to understand 
>  > that two identities are possible, know them both by some 
>  > unspecified means, and assert them in every call on every UA.  
>  > This seems unreasonable.  I'm not sure that there is a reason
>  > to have both identities validated, but there could be.
> 
> if your proxy receives a call from sip:foo@bar.com who has also been
> allocated a phone number +1234567890, why can't is add an asserted
> identity header containing sip:+1234567890@bar.com to the call in case
> the call is bound to pstn?  why would you need yet another header for
> that purpose?
> 
> -- juha
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Tue Jan  7 08:57:58 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14119
	for <sipping-archive@odin.ietf.org>; Tue, 7 Jan 2003 08:57:58 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h07E8fU22368
	for sipping-archive@odin.ietf.org; Tue, 7 Jan 2003 09:08:41 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07E8fJ22365
	for <sipping-web-archive@optimus.ietf.org>; Tue, 7 Jan 2003 09:08:41 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14057
	for <sipping-web-archive@ietf.org>; Tue, 7 Jan 2003 08:54:07 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07DwFJ21139;
	Tue, 7 Jan 2003 08:58:15 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07DvRJ21018
	for <sipping@optimus.ietf.org>; Tue, 7 Jan 2003 08:57:27 -0500
Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13267
	for <sipping@ietf.org>; Tue, 7 Jan 2003 08:46:10 -0500 (EST)
From: jh@lohi.eng.song.fi
Received: from harjus.eng.song.fi ([195.10.149.20])
	by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian))
	id 18Vu6c-0000c1-00; Tue, 07 Jan 2003 15:49:22 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15898.56033.854083.599679@harjus.eng.song.fi>
Date: Tue, 7 Jan 2003 15:49:21 +0200
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
Cc: "'Peterson, Jon'" <jon.peterson@neustar.biz>,
        "'Drage, Keith (Keith)'"
	 <drage@lucent.com>,
        "'Henning Schulzrinne'" <hgs@cs.columbia.edu>,
        "'sipping@ietf.org'" <sipping@ietf.org>
Subject: RE: [Sipping] URIs for Gateways
In-Reply-To: <313680C9A886D511A06000204840E1CF030B5CCB@whq-msgusr-02.pit.comms.marconi.com>
References: <313680C9A886D511A06000204840E1CF030B5CCB@whq-msgusr-02.pit.comms.marconi.com>
X-Mailer: VM 7.03 under Emacs 21.2.1
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Rosen, Brian writes:

 > It may be that we want to use P-Asserted-Identity for this
 > purpose.  I currently think it's a pretty good idea, but:
 > 	* It doesn't really meet the definition in RFC3325
 > 	* The "P" bothers me if this is a permanent solution

brian,

you can take a look at the archives and see that i was strongly against
in making asserted-identity a p header for the reason that as long as it
is a p header, sip/ss7 gw vendors are not likely to support in their
gateways as a means to obtain the asserted pstn number of the calling
party.  so in practice the header became a 3gpp only thing.

-- juha


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Tue Jan  7 10:20:41 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17653
	for <sipping-archive@odin.ietf.org>; Tue, 7 Jan 2003 10:20:41 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h07FVQY27959
	for sipping-archive@odin.ietf.org; Tue, 7 Jan 2003 10:31:26 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07FVQJ27956
	for <sipping-web-archive@optimus.ietf.org>; Tue, 7 Jan 2003 10:31:26 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17625
	for <sipping-web-archive@ietf.org>; Tue, 7 Jan 2003 10:20:09 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07FKAJ27360;
	Tue, 7 Jan 2003 10:20:10 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07FJjJ27307
	for <sipping@optimus.ietf.org>; Tue, 7 Jan 2003 10:19:45 -0500
Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16486
	for <sipping@ietf.org>; Tue, 7 Jan 2003 10:08:28 -0500 (EST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA23073;
	Tue, 7 Jan 2003 10:11:41 -0500 (EST)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA29593;
	Tue, 7 Jan 2003 10:11:41 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <ZVACKGMX>; Tue, 7 Jan 2003 10:11:40 -0500
Message-ID: <313680C9A886D511A06000204840E1CF030B5CCD@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Peterson, Jon'" <jon.peterson@neustar.biz>,
        "'Drage, Keith (Keith)'"
	 <drage@lucent.com>,
        "'Henning Schulzrinne'" <hgs@cs.columbia.edu>
Cc: "'sipping@ietf.org'" <sipping@ietf.org>
Subject: RE: [Sipping] URIs for Gateways
Date: Tue, 7 Jan 2003 10:11:37 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

I think Reply-To is a so-so place to put a second identity.
I think it's problematic to have a From have the "real"
SIP URI and the Reply-To have the "real" tel URI.  It
warps the definition of Reply-To.

It also has a serious problem that a proxy can't add it.
One of the requirements I have is that a proxy be able to
do the translation.  Not every gateway can hold all the tables
required for this kind of translation, and I don't think
we want to force every gateway to have the tables.

I think your proposals on identity will not work unless
the signer can be a proxy which later in the routing
than my proxy that does the translation.  If the gateway
does the translation, then in theory there would have to be
a trust relationship between the PSTN and the gateway.  
That won't work for an enterprise gateway, although I'm not
sure that's a practical problem, because if the gateway
translated, the PSTN is going to check that the number
the gateway asserted is one of the identities that loop
is allocated (PRIs have ranges).

I don't see how ENUM is useful with identity assertion,
although it's clearly applicable to the proxy that
translates a SIP URI into a phone number or vice versa in
the Request URI.  

Brian

> -----Original Message-----
> From: Peterson, Jon [mailto:jon.peterson@neustar.biz]
> Sent: Tuesday, January 07, 2003 6:35 AM
> To: 'Rosen, Brian'; 'Drage, Keith (Keith)'; 'Henning Schulzrinne'
> Cc: 'sipping@ietf.org'
> Subject: RE: [Sipping] URIs for Gateways
> 
> 
> 
> First, it is possible, with the long-term identity mechanism, 
> to assert two
> identities in an authenticated identity body. So, you could 
> have headers
> corresponding to a telephone number and a SIP URI of a 
> gateway or a user -
> it strikes me that a telephone number is a good Reply-To, 
> actually, when a
> call comes from a gateway (originating in the PSTN, say) and 
> the From header
> field contains a SIP URI for the gateway, perhaps including some port
> information. The identity that the gateway which handles a 
> PSTN-SIP call
> would assert needs to be its own, and recipients of calls 
> from gateways need
> to trust the telephone number provided by the gateway or not 
> accordingly
> (i.e. a signature from att.com vouching for such a request should be
> acceptable).
> 
> Technologies like ENUM (when/where available) could enable gateways to
> convert originating telephone numbers into URIs. Of course, a gateway
> wouldn't be able to assert that identity to an intermediary unless it
> possessed credentials appropriate to that URI, which is unlikely.
> 
> For outbound calls (SIP-PSTN), the gateway may or may not be 
> able to map
> (authenticated) SIP URIs representing originators to 
> appropriate telephone
> numbers via some sort of local tables as you suggested. If 
> not, might also
> pick a number from a pool, sure. The question of whether some 
> authentication
> service should be able to assert an originating telephone 
> number (in an
> authenticated identity body, say) that a gateway will use is 
> also a trust
> question - it is possible to put the tel URL in the AIB. If 
> the gateway has
> a reason to trust the authentication service, then certainly 
> it should send
> that number to the PSTN (when the protocol allows gateways to supply a
> number, like with ISUP or Q.931). The gateway would be very 
> ill advised to
> take just any authentication service's word on this matter, though. 
> 
> The target of the calls for the PSTN should be identified 
> with a telephone
> number - at least, by the time the call arrives a gateway, 
> it's Request-URI
> should contain a tel URL or a SIP URI with a tel URL 
> component. Whether the
> originating UAC sets the To header field to a tel URL or a 
> subsequent proxy
> retargets the request doesn't seem to make much difference. 
> ENUM can also
> play a pretty obvious role here.
> 
> Jon Peterson
> NeuStar, Inc.
> 
> > -----Original Message-----
> > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > Sent: Monday, January 06, 2003 1:22 PM
> > To: 'Peterson, Jon'; 'Drage, Keith (Keith)'; Rosen, Brian; 'Henning
> > Schulzrinne'
> > Cc: 'sipping@ietf.org'
> > Subject: RE: [Sipping] URIs for Gateways
> > 
> > 
> > I agree with this.  I'm confused by those who seem to think that
> > P-Asserted-Identity is needed when the long term solution is
> > fully baked.  If the UA knows its identity, which seems
> > reasonable, then it can "assert" it, and have that assertion
> > validated by a trusted entity using cryptographic means.
> > That is the fundamental idea I get out of Jon's proposal.
> > The only circumstance where that won't work is where the
> > UA doesn't know its identity.  I don't see that as a problem
> > on any network I'm aware of, but ...... keep reading.
> > 
> > I do think there is a problem which this whole thread talks about.
> > The basic reality is that many users of SIP UAs will have two
> > identities - a SIP URI and a telephone number.  It may be
> > necessary to assert both identities in one call, because the
> > originator of the call does not know which identity may be
> > needed.  There is no current header to do this.  I think that 
> > it is advantageous to have a proxy be able to assert the phone 
> > number.  Otherwise EVERY UA will have to be able to understand 
> > that two identities are possible, know them both by some 
> > unspecified means, and assert them in every call on every UA.  
> > This seems unreasonable.  I'm not sure that there is a reason
> > to have both identities validated, but there could be.
> > 
> > Brian
> > > -----Original Message-----
> > > From: Peterson, Jon [mailto:jon.peterson@neustar.biz]
> > > Sent: Monday, January 06, 2003 2:06 PM
> > > To: 'Drage, Keith (Keith)'; Rosen, Brian; 'Henning Schulzrinne'
> > > Cc: 'sipping@ietf.org'
> > > Subject: RE: [Sipping] URIs for Gateways
> > > 
> > > 
> > > 
> > > RFC3325 was 'short-term' because it was achievable in the 
> > > short-term and has
> > > a more limited (but still useful) applicability. The 
> > > long-term identity
> > > solution must be a superset of the functionality of 
> > > short-term - it must
> > > address the short-term scope of applicability, but also 
> > > encompass general
> > > needs for network assertion (which SIP does have). 
> > > Accordingly, it takes
> > > longer to develop. At such a time as there is a workable 
> > > long-term solution,
> > > it would be pointless to allow both to be SIP standards 
> > > except as part of a
> > > transition plan. So in that sense, I disagree - one is a 
> > > short-term solution
> > > of the other.
> > > 
> > > Jon Peterson
> > > NeuStar, Inc.
> > > 
> > > > -----Original Message-----
> > > > From: Drage, Keith (Keith) [mailto:drage@lucent.com]
> > > > Sent: Friday, January 03, 2003 8:20 AM
> > > > To: Rosen, Brian; 'Henning Schulzrinne'
> > > > Cc: 'sipping@ietf.org'
> > > > Subject: RE: [Sipping] URIs for Gateways
> > > > 
> > > > 
> > > > Network asserted identity (RFC 3325) is the real network 
> > > > asserted identity. It is a P header not because it is 
> > > > preliminary, but because the whole idea of network assertion 
> > > > is not generally applicable to all SIP architectures. For RFC 
> > > > 3325 a trust domain needs to exist between proxies that use 
> > > > the P-Asserted-Identity in order to guarantee the privacy, 
> > > > this does not exist in all SIP networks. In does in 3GPP and 
> > > > therefore 3GPP are using RFC 3325.
> > > > 
> > > > If you want to let the 1et outbound proxy assert identity on 
> > > > your behalf then use RFC 3325. If you want to let application 
> > > > servers with whom you have a secure relationship assert your 
> > > > identity, then use Jon Petersons drafts, when they eventually 
> > > > become RFCs. 
> > > > 
> > > > One is not a short term solution for the other.
> > > > 
> > > > Keith
> > > > 
> > > > Keith Drage
> > > > Lucent Technologies
> > > > Tel: +44 1793 776249
> > > > Email: drage@lucent.com 
> > > > 
> > > > > -----Original Message-----
> > > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > > > > Sent: 02 January 2003 20:49
> > > > > To: 'Henning Schulzrinne'
> > > > > Cc: 'sipping@ietf.org'
> > > > > Subject: RE: [Sipping] URIs for Gateways
> > > > > 
> > > > > 
> > > > > Yeah, I actually thought of just allowing a display 
> name in the
> > > > > Request URI and using that, but it seems so foolish to make 
> > > > a change,
> > > > > and have that change not be exactly what we needed.
> > > > > 
> > > > > We could use NAI.  I suppose we could use a 
> P-Asserted-Identity
> > > > > with a tel URI:  
> > > > > P-Asserted-Identity tel:+17247426826
> > > > > 
> > > > > What do we do when the "real" NAI happens?
> > > > > 
> > > > > Brian
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> > > > > > Sent: Thursday, January 02, 2003 3:10 PM
> > > > > > To: Rosen, Brian
> > > > > > Cc: 'sipping@ietf.org'
> > > > > > Subject: Re: [Sipping] URIs for Gateways
> > > > > > 
> > > > > > 
> > > > > > > I'd like to get a new header for the calling 
> party number on
> > > > > > > an outbound call.  That way, the translator can be 
> > a proxy and
> > > > > > > add the header.  I'd recommend that gateways allow 
> > the number
> > > > > > > to be in the From.   
> > > > > > 
> > > > > > Generalized, you want something like the Request-URI 
> > > that can be 
> > > > > > modified or inserted. How about the NAI stuff?
> > > > > > 
> > > > > _______________________________________________
> > > > > Sipping mailing list  
> > > https://www1.ietf.org/mailman/listinfo/sipping
> > > > > This list is for NEW development of the application of SIP
> > > > > Use sip-implementors@cs.columbia.edu for questions on 
> > current sip
> > > > > Use sip@ietf.org for new developments of core SIP
> > > > > 
> > > > _______________________________________________
> > > > Sipping mailing list  
> > https://www1.ietf.org/mailman/listinfo/sipping
> > > > This list is for NEW development of the application of SIP
> > > > Use sip-implementors@cs.columbia.edu for questions on 
> current sip
> > > > Use sip@ietf.org for new developments of core SIP
> > > > 
> > > _______________________________________________
> > > Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> > > This list is for NEW development of the application of SIP
> > > Use sip-implementors@cs.columbia.edu for questions on current sip
> > > Use sip@ietf.org for new developments of core SIP
> > > 
> > 
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Tue Jan  7 11:40:16 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20270
	for <sipping-archive@odin.ietf.org>; Tue, 7 Jan 2003 11:40:16 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h07Gp3r01748
	for sipping-archive@odin.ietf.org; Tue, 7 Jan 2003 11:51:03 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07Gp3J01745
	for <sipping-web-archive@optimus.ietf.org>; Tue, 7 Jan 2003 11:51:03 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20252
	for <sipping-web-archive@ietf.org>; Tue, 7 Jan 2003 11:39:43 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07GkoJ01601;
	Tue, 7 Jan 2003 11:46:50 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07GjeJ01561
	for <sipping@optimus.ietf.org>; Tue, 7 Jan 2003 11:45:40 -0500
Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20110
	for <sipping@ietf.org>; Tue, 7 Jan 2003 11:34:22 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h07GcCCe000875;
	Tue, 7 Jan 2003 11:38:12 -0500 (EST)
Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAX45995;
	Tue, 7 Jan 2003 11:42:32 -0500 (EST)
Message-ID: <3E1B024A.1020309@cisco.com>
Date: Tue, 07 Jan 2003 11:37:30 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: sipping@ietf.org
Subject: Re: [Sipping] I-D ACTION:draft-rosenberg-sipping-session-policy-req-00.txt
References: <200301071328.IAA12023@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

This document provides many detailed requirements. But I am still left 
with a feeling of uncertainty about the overall scope. For instance:

- I'm not sure what is in scope and out of scope for a media policy. Is 
there anything that can be negotiated via an offer/answer exchange that 
is out of scope? Certain specific features that are encoded in SDP are 
called out specifically. This might imply that it is intended that 
features not mentioned are out of scope.

An example of a specific feature not mentioned, is the a=direction 
attribute used by comedia. It is possible to imagine an intermediate 
node might want to alter an a=direction:both to be only 
a=direction:active. Does this need to be listed as a requirement before 
it can be addressed by policy?

I am somewhat concerned that this is a slippery slope. Unless we can 
clearly define what is in scope and what is out, I think we will find 
that we are simply defining a new representation of SDP, one syntactic 
element at a time. At the least, this seems to require a sort of 
meta-model for offers and answers that transcends SDP and SDPng.

- Continuing the scope question a bit, is there any intent to support 
policies that can't already be expressed via an offer/answer exchange? 
(I don't think so, but just checking.)

- There is much mention of proxies as the nodes that want to specify 
policy. But I think there are other kinds of servers that may also take 
on this role. Specifically, a B2BUA may also want to work cooperatively 
with the endpoints in same way. Of course a B2BUA already has more 
capabilities to modify the SDP directly, but it may want to be more 
subtle and friendly in its manipulations. For instance, this mechanism 
may permit a more extended pre-alert negotiation than is currently 
possible. So I would like to see these requirements phrased to permit a 
B2BUA as a policy setter if that makes sense.

	Paul

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Tue Jan  7 11:50:56 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20704
	for <sipping-archive@odin.ietf.org>; Tue, 7 Jan 2003 11:50:56 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h07H1ii02309
	for sipping-archive@odin.ietf.org; Tue, 7 Jan 2003 12:01:44 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07H1iJ02306
	for <sipping-web-archive@optimus.ietf.org>; Tue, 7 Jan 2003 12:01:44 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20684
	for <sipping-web-archive@ietf.org>; Tue, 7 Jan 2003 11:50:16 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07GvCJ02130;
	Tue, 7 Jan 2003 11:57:12 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07GulJ02099
	for <sipping@optimus.ietf.org>; Tue, 7 Jan 2003 11:56:47 -0500
Received: from imo-m04.mx.aol.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20544
	for <sipping@ietf.org>; Tue, 7 Jan 2003 11:45:29 -0500 (EST)
From: Mpierce1@aol.com
Received: from Mpierce1@aol.com
	by imo-m04.mx.aol.com (mail_out_v34.13.) id 7.128.1f9ae0e1 (4552);
	Tue, 7 Jan 2003 11:48:12 -0500 (EST)
Message-ID: <128.1f9ae0e1.2b4c5ecc@aol.com>
Date: Tue, 7 Jan 2003 11:48:12 EST
Subject: Re: [Sipping] Comments on sos draft -03 (URI)
To: hgs@cs.columbia.edu
CC: sipping@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: AOL 6.0 for Windows XP US sub 51
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

In a message dated 1/6/2003 6:51:38 PM Eastern Standard Time, 
hgs@cs.columbia.edu writes:


The problem 
occurs with 118 and 119, which presumably are omitted from the shorter 
list since they mean something other than emergency somewhere. 

[MAP] This is the fundamental problem. If a number means something else 
someplace else, then it can't be coded into the phone and setup to 
automatically initiate a call to emergency if dialed. This also applies if 
the number means nothing somewhere else. For example, if 118 means emergency 
somewhere, but is unused in the US, then if I dial 118 on my SIP phone when 
I'm in the US, it can't be allowed to initiate a call to emergency. People 
can get fined for false calls to emergency, but you can't very easily fault 
someone if it was the design of their phone that did it when they dialed a 
non-existant digit string.

As Henning wrote on 12/21: "Are you arguing that 112 does *not* work on GSM 
phones in 
the US? (I don't know; I don't want to try on mine...)"

I believe that this rules out any numbers being automatically recognized by a 
phone device, unless that device has specific knowledge about the local 
dialing plan. So, until the issue of how a phone knows the local dial plan is 
solved/answered, I suggest that all discussion of storing emergency (or 
other) numbers in the phone be dropped.


In a message dated 1/4/2003 1:33:09 PM Eastern Standard Time, 
hgs@cs.columbia.edu writes:

[MAP] > The seventh paragraph states that the "sos" user name and user names 
> starting with "sos." MUST NOT be assigned to any user. Such a 
> restriction can not possibly be enforced due to possible existing 
> conflicts (as noted in Section 6). 

[HS] 
Do you have any suggestions that work better? The section 'Alternative 
Identifiers Considered' describes why I believe that none of the obvious 
alternatives is workable if you want

Yes, I have a suggestion, but I know it is highly controversial and is not 
liked, since it goes against the vision of how the Internet MUST work. I 
don't think that the draft (Section 10 in -04) makes the case that the 
alternatives listed are not workable.

The first "tel:sos" says it is not a valid tel URI and it only works if every 
outbound proxy knows what to do with it. Can't this form be included in the 
definition of tel:url?

The draft says that a URI parameter won't work since it "requires 
mechanism-aware user agents", but everything we've been discussing seems to 
be based on a premise that the user agent is "mechanism-aware" (has a special 
button or recognizes "emergency" numbers).

Special domain: Same as tel:uri.

Further, the statement in support of not using the tel:sos scheme also says 
that the "SIP URI proposed here only requires a user's home domain to be 
appropriately configured". This is a major disadvantage with this scheme, 
which I suppose has been the subject of some past discussions. There is a 
fundamental problem with this approach. The user's home domain is not subject 
to any of the regulations that apply to the local area regarding the support 
of emergency telephone service. It couldn't even be required to support it. 
Depending on the user's home domain to know how to handle emergency calls for 
the area that the user is in (if the home domain even knows where they are) 
is very problematic. It presumes that the home domain not only understands 
the "sos.", but knows how to call the emergency service local to the user. I 
can't imagine for a monent that any local regulatory body (which, in the end, 
controls how emergency services are reached) would accept a scheme that 
depends on some distant equipment, which it does not control through 
regulations, to be the critical point in providing emergency service.

The solution to the above is to state that the outbound proxy must recognize 
and take action on all emergency calls, whether dialed with 911, 118, etc. or 
by the use of a special button on the phone which sends a special URI. The 
URI can be some new form defined within the context of the tel:url, since it 
is intended as a direct replacement for a telephone number, or some other 
form. The user's home domain is never responsible to handling emergency 
calls. Further, all calls require the use of an outbound proxy. (The 
alternative is for the phone itself to be able to perform the functions of 
the outbound proxy, which requires, among other things, that it know the 
entire local dialing plan. It could know this through configuration or 
download of parameters when it is turned on.)

(See, I said it was controversial!)

Mike Pierce
Artel
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Tue Jan  7 12:04:18 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21096
	for <sipping-archive@odin.ietf.org>; Tue, 7 Jan 2003 12:04:18 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h07HF6r03663
	for sipping-archive@odin.ietf.org; Tue, 7 Jan 2003 12:15:06 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07HF5J03660
	for <sipping-web-archive@optimus.ietf.org>; Tue, 7 Jan 2003 12:15:05 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21070
	for <sipping-web-archive@ietf.org>; Tue, 7 Jan 2003 12:03:40 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07H8DJ03397;
	Tue, 7 Jan 2003 12:08:13 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07H6UJ02617
	for <sipping@optimus.ietf.org>; Tue, 7 Jan 2003 12:06:30 -0500
Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20899
	for <sipping@ietf.org>; Tue, 7 Jan 2003 11:55:12 -0500 (EST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA29419;
	Tue, 7 Jan 2003 11:58:25 -0500 (EST)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA18308;
	Tue, 7 Jan 2003 11:58:26 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <ZVACKKQ1>; Tue, 7 Jan 2003 11:58:26 -0500
Message-ID: <313680C9A886D511A06000204840E1CF030B5CCF@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Paul Kyzivat'" <pkyzivat@cisco.com>,
        Jonathan Rosenberg
	 <jdrosen@dynamicsoft.com>
Cc: sipping@ietf.org
Subject: RE: [Sipping] I-D ACTION:draft-rosenberg-sipping-session-policy-r
	eq-00.txt
Date: Tue, 7 Jan 2003 11:58:23 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

Agree.  I specifically want to have the mechanism allowed to
specify the bandwidth parameters (I ask for a 6MB video stream,
the proxy tells me I can only send 4, everything else is the same).
So, is this in scope or out?

I'll point out that this is an interesting one because there is no
middle box; there is simply a bandwidth manager that is doing
something much better than simplistic call admission control. However,
I don't see any reason to judge why one SDP parameter is subject
to policy, and another one is not.  

Brian

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Tuesday, January 07, 2003 11:38 AM
> To: Jonathan Rosenberg
> Cc: sipping@ietf.org
> Subject: Re: [Sipping] I-D
> ACTION:draft-rosenberg-sipping-session-policy-req-00.txt
> 
> 
> This document provides many detailed requirements. But I am 
> still left 
> with a feeling of uncertainty about the overall scope. For instance:
> 
> - I'm not sure what is in scope and out of scope for a media 
> policy. Is 
> there anything that can be negotiated via an offer/answer 
> exchange that 
> is out of scope? Certain specific features that are encoded 
> in SDP are 
> called out specifically. This might imply that it is intended that 
> features not mentioned are out of scope.
> 
> An example of a specific feature not mentioned, is the a=direction 
> attribute used by comedia. It is possible to imagine an intermediate 
> node might want to alter an a=direction:both to be only 
> a=direction:active. Does this need to be listed as a 
> requirement before 
> it can be addressed by policy?
> 
> I am somewhat concerned that this is a slippery slope. Unless we can 
> clearly define what is in scope and what is out, I think we will find 
> that we are simply defining a new representation of SDP, one 
> syntactic 
> element at a time. At the least, this seems to require a sort of 
> meta-model for offers and answers that transcends SDP and SDPng.
> 
> - Continuing the scope question a bit, is there any intent to support 
> policies that can't already be expressed via an offer/answer 
> exchange? 
> (I don't think so, but just checking.)
> 
> - There is much mention of proxies as the nodes that want to specify 
> policy. But I think there are other kinds of servers that may 
> also take 
> on this role. Specifically, a B2BUA may also want to work 
> cooperatively 
> with the endpoints in same way. Of course a B2BUA already has more 
> capabilities to modify the SDP directly, but it may want to be more 
> subtle and friendly in its manipulations. For instance, this 
> mechanism 
> may permit a more extended pre-alert negotiation than is currently 
> possible. So I would like to see these requirements phrased 
> to permit a 
> B2BUA as a policy setter if that makes sense.
> 
> 	Paul
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Tue Jan  7 12:28:02 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21620
	for <sipping-archive@odin.ietf.org>; Tue, 7 Jan 2003 12:28:02 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h07HcoH05300
	for sipping-archive@odin.ietf.org; Tue, 7 Jan 2003 12:38:50 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07HcoJ05297
	for <sipping-web-archive@optimus.ietf.org>; Tue, 7 Jan 2003 12:38:50 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21598
	for <sipping-web-archive@ietf.org>; Tue, 7 Jan 2003 12:27:26 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07HYAJ04545;
	Tue, 7 Jan 2003 12:34:10 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07HX2J04494
	for <sipping@optimus.ietf.org>; Tue, 7 Jan 2003 12:33:02 -0500
Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21530
	for <sipping@ietf.org>; Tue, 7 Jan 2003 12:21:42 -0500 (EST)
Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66])
	(user=hgs10 mech=PLAIN bits=0)
	by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h07HOuEE028883
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Tue, 7 Jan 2003 12:24:57 -0500 (EST)
Message-ID: <3E1B0D86.8070407@cs.columbia.edu>
Date: Tue, 07 Jan 2003 12:25:26 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mpierce1@aol.com
CC: sipping@ietf.org
Subject: Re: [Sipping] Comments on sos draft -03 (URI)
References: <128.1f9ae0e1.2b4c5ecc@aol.com>
In-Reply-To: <128.1f9ae0e1.2b4c5ecc@aol.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

> [MAP] This is the fundamental problem. If a number means something else 
> someplace else, then it can't be coded into the phone and setup to 
> automatically initiate a call to emergency if dialed. This also applies if 
> the number means nothing somewhere else. For example, if 118 means emergency 
> somewhere, but is unused in the US, then if I dial 118 on my SIP phone when 
> I'm in the US, it can't be allowed to initiate a call to emergency. People 
> can get fined for false calls to emergency, but you can't very easily fault 
> someone if it was the design of their phone that did it when they dialed a 
> non-existant digit string.

I guess you'll have to argue this with 3GPP, since they preload a set of 
numbers into the phone.

There are basically two kinds of errors:

(1) The user dials a three-digit number reasonably expecting it to reach 
emergency and it reaches, say, repair service or nobody. Bad, with 
potentially life-threatening consequences.

(2) The user dials a three-digit number, believing it reaches some 
service like repair or directory assistance, and gets connected to the 
police department. Unless the caller insists on getting grandma's phone 
number, this is mostly a nuisance. (I don't think accidentally dialing 
911 is a crime, since this occurs quite commonly with cell phones that 
have one-button emergency calls. Reporting a non-existing emergency is, 
obviously, punishable.) This becomes a problem if this number is widely 
advertised. If the device recognizes the three-digit number combination, 
it can easily pop up a dialog that says "you're dialing an emergency 
number, please confirm". (This, btw, argues for translating all of these 
into sos URIs, since there's otherwise no way for the user to dial 
tel:118 for directory assistance since the proxy will *always* assume 
its an emergency number.)

My interpretation of the 3GPP list is that none of the numbers, with the 
exception of 118 and 119, are used for anything else of importance, so 
that (2) is not likely to be common. This is not terribly satisfying, 
but pragmatic, given case (1).


> 
> As Henning wrote on 12/21: "Are you arguing that 112 does *not* work on GSM 
> phones in 
> the US? (I don't know; I don't want to try on mine...)"
> 
> I believe that this rules out any numbers being automatically recognized by a 
> phone device, unless that device has specific knowledge about the local 
> dialing plan. So, until the issue of how a phone knows the local dial plan is 
> solved/answered, I suggest that all discussion of storing emergency (or 
> other) numbers in the phone be dropped.

Again, something you should take up with 3GPP first.

> The first "tel:sos" says it is not a valid tel URI and it only works if every 
> outbound proxy knows what to do with it. Can't this form be included in the 
> definition of tel:url?

It could, but the other problem remains. Plus, conceptually, I'm 
reluctant to classify emergency calls as a tel(ephone) service. If we go 
down this route of what is essentially a URN, I think it's cleaner to 
define a new URN scheme that identifies generic communication services, 
similar to the ISBN schemes and organizations, as in

URN:service:sos

We had a related discussion in the IPTEL working group, since this is 
one of the major open issues remaining for the tel URI. Defining the URN 
is easy, defining the resolution is hard, particulary if you want to 
allow things like

URN:service:pizza

or even

URN:service:phone-directory

where multiple providers want to be reached via that URN. I don't think 
NAPTR works for this, for example. You effectively recreate the 
'mnemonic name' problem, see RFC 2972, 3367 and 3368 for one such 
service. Indeed, you could use

go:sos

today, except that CNRP seems to have been one of those 2000-era ideas 
that floundered. (http://www.realnames.com is no more...)

> 
> The draft says that a URI parameter won't work since it "requires 
> mechanism-aware user agents", but everything we've been discussing seems to 
> be based on a premise that the user agent is "mechanism-aware" (has a special 
> button or recognizes "emergency" numbers).

Not really. I can take a SIP phone and dial 911 or any of the other 
numbers and that would work (assuming it gets translated to a tel URI) 
or dial sos@mydomain and this will work, without any UA modification. 
Clearly, some proxy has to recognize these identifiers, but UAs do not. 
(Actually, even that's not true for the common case where the gateway is 
in the same country. Dialing tel:911 today may work, even though you may 
be talking to a police department that's in a different part of the 
country.)

> 
> Special domain: Same as tel:uri.
> 
> Further, the statement in support of not using the tel:sos scheme also says 
> that the "SIP URI proposed here only requires a user's home domain to be 
> appropriately configured". This is a major disadvantage with this scheme, 
> which I suppose has been the subject of some past discussions. There is a 
> fundamental problem with this approach. The user's home domain is not subject 
> to any of the regulations that apply to the local area regarding the support 
> of emergency telephone service. It couldn't even be required to support it. 

I don't know what you mean by 'local area'. I don't see how I can 
require Starbucks to support a PSTN gateway in each of its 802.11 hot spots.

> Depending on the user's home domain to know how to handle emergency calls for 
> the area that the user is in (if the home domain even knows where they are) 
> is very problematic. It presumes that the home domain not only understands 
> the "sos.", but knows how to call the emergency service local to the user. I 
> can't imagine for a monent that any local regulatory body (which, in the end, 
> controls how emergency services are reached) would accept a scheme that 
> depends on some distant equipment, which it does not control through 
> regulations, to be the critical point in providing emergency service.

Are you mandating that every LAN, every 802.11 hotspot, every IETF 
wireless LAN has to have:
- an outbound SIP proxy server, and
- a PSTN gateway that can dial 911
?

Good luck. I'm trying to build a system that will work well once this is 
true and will work ok (and be testable) until this is true.


> 
> The solution to the above is to state that the outbound proxy must recognize 
> and take action on all emergency calls, whether dialed with 911, 118, etc. or 

The draft already says that. The problem is that there may be no 
outbound proxy in every LAN or local geographic area. After all, this is 
not a mandatory piece of equipment and not every network will be 
SIP-aware. I want to be able to use SIP phones without local support. 
Once we have outbound proxies everywhere, things will work better (and 
exactly as well as your proposal).

> by the use of a special button on the phone which sends a special URI. The 
> URI can be some new form defined within the context of the tel:url, since it 
> is intended as a direct replacement for a telephone number, or some other 
> form. The user's home domain is never responsible to handling emergency 
> calls. Further, all calls require the use of an outbound proxy. (The 
> alternative is for the phone itself to be able to perform the functions of 
> the outbound proxy, which requires, among other things, that it know the 
> entire local dialing plan. It could know this through configuration or 
> download of parameters when it is turned on.)
> 
> (See, I said it was controversial!)


> 
> Mike Pierce
> Artel

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Tue Jan  7 13:18:13 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23199
	for <sipping-archive@odin.ietf.org>; Tue, 7 Jan 2003 13:18:13 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h07IT3x08192
	for sipping-archive@odin.ietf.org; Tue, 7 Jan 2003 13:29:03 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07IT3J08189
	for <sipping-web-archive@optimus.ietf.org>; Tue, 7 Jan 2003 13:29:03 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23156
	for <sipping-web-archive@ietf.org>; Tue, 7 Jan 2003 13:17:21 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07IP5J08004;
	Tue, 7 Jan 2003 13:25:05 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07IOEJ07936
	for <sipping@optimus.ietf.org>; Tue, 7 Jan 2003 13:24:14 -0500
Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22925
	for <sipping@ietf.org>; Tue, 7 Jan 2003 13:12:53 -0500 (EST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA02567;
	Tue, 7 Jan 2003 13:16:06 -0500 (EST)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA29329;
	Tue, 7 Jan 2003 13:16:07 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <ZVACKNFV>; Tue, 7 Jan 2003 13:16:07 -0500
Message-ID: <313680C9A886D511A06000204840E1CF030B5CD0@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Henning Schulzrinne'" <hgs@cs.columbia.edu>, Mpierce1@aol.com
Cc: sipping@ietf.org
Subject: RE: [Sipping] Comments on sos draft -03 (URI)
Date: Tue, 7 Jan 2003 13:15:57 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

I don't think this works.  Not all dialing plans are the same,
and even if all 3G phones have the same dialing plans, that
won't be the same as, say, an enterprise telephony system.

In most US enterprises, and for that matter, in most US college
campuses, the emergency number is 9-911.  911 would not connect
(the 9 would be interpreted as "outside line", and the 11 would
probably be interpreted as an illegal number).  In a "greenfield"
all-VoIP system, this could be changed, but in general, it can't.
A great many enterprise systems have 3 digit extensions where 1
is a legal first digit. 

Brian

> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Tuesday, January 07, 2003 12:25 PM
> To: Mpierce1@aol.com
> Cc: sipping@ietf.org
> Subject: Re: [Sipping] Comments on sos draft -03 (URI)
> 
> 
> > [MAP] This is the fundamental problem. If a number means 
> something else 
> > someplace else, then it can't be coded into the phone and setup to 
> > automatically initiate a call to emergency if dialed. This 
> also applies if 
> > the number means nothing somewhere else. For example, if 
> 118 means emergency 
> > somewhere, but is unused in the US, then if I dial 118 on 
> my SIP phone when 
> > I'm in the US, it can't be allowed to initiate a call to 
> emergency. People 
> > can get fined for false calls to emergency, but you can't 
> very easily fault 
> > someone if it was the design of their phone that did it 
> when they dialed a 
> > non-existant digit string.
> 
> I guess you'll have to argue this with 3GPP, since they 
> preload a set of 
> numbers into the phone.
> 
> There are basically two kinds of errors:
> 
> (1) The user dials a three-digit number reasonably expecting 
> it to reach 
> emergency and it reaches, say, repair service or nobody. Bad, with 
> potentially life-threatening consequences.
> 
> (2) The user dials a three-digit number, believing it reaches some 
> service like repair or directory assistance, and gets 
> connected to the 
> police department. Unless the caller insists on getting 
> grandma's phone 
> number, this is mostly a nuisance. (I don't think 
> accidentally dialing 
> 911 is a crime, since this occurs quite commonly with cell 
> phones that 
> have one-button emergency calls. Reporting a non-existing 
> emergency is, 
> obviously, punishable.) This becomes a problem if this number 
> is widely 
> advertised. If the device recognizes the three-digit number 
> combination, 
> it can easily pop up a dialog that says "you're dialing an emergency 
> number, please confirm". (This, btw, argues for translating 
> all of these 
> into sos URIs, since there's otherwise no way for the user to dial 
> tel:118 for directory assistance since the proxy will *always* assume 
> its an emergency number.)
> 
> My interpretation of the 3GPP list is that none of the 
> numbers, with the 
> exception of 118 and 119, are used for anything else of 
> importance, so 
> that (2) is not likely to be common. This is not terribly satisfying, 
> but pragmatic, given case (1).
> 
> 
> > 
> > As Henning wrote on 12/21: "Are you arguing that 112 does 
> *not* work on GSM 
> > phones in 
> > the US? (I don't know; I don't want to try on mine...)"
> > 
> > I believe that this rules out any numbers being 
> automatically recognized by a 
> > phone device, unless that device has specific knowledge 
> about the local 
> > dialing plan. So, until the issue of how a phone knows the 
> local dial plan is 
> > solved/answered, I suggest that all discussion of storing 
> emergency (or 
> > other) numbers in the phone be dropped.
> 
> Again, something you should take up with 3GPP first.
> 
> > The first "tel:sos" says it is not a valid tel URI and it 
> only works if every 
> > outbound proxy knows what to do with it. Can't this form be 
> included in the 
> > definition of tel:url?
> 
> It could, but the other problem remains. Plus, conceptually, I'm 
> reluctant to classify emergency calls as a tel(ephone) 
> service. If we go 
> down this route of what is essentially a URN, I think it's cleaner to 
> define a new URN scheme that identifies generic communication 
> services, 
> similar to the ISBN schemes and organizations, as in
> 
> URN:service:sos
> 
> We had a related discussion in the IPTEL working group, since this is 
> one of the major open issues remaining for the tel URI. 
> Defining the URN 
> is easy, defining the resolution is hard, particulary if you want to 
> allow things like
> 
> URN:service:pizza
> 
> or even
> 
> URN:service:phone-directory
> 
> where multiple providers want to be reached via that URN. I 
> don't think 
> NAPTR works for this, for example. You effectively recreate the 
> 'mnemonic name' problem, see RFC 2972, 3367 and 3368 for one such 
> service. Indeed, you could use
> 
> go:sos
> 
> today, except that CNRP seems to have been one of those 
> 2000-era ideas 
> that floundered. (http://www.realnames.com is no more...)
> 
> > 
> > The draft says that a URI parameter won't work since it "requires 
> > mechanism-aware user agents", but everything we've been 
> discussing seems to 
> > be based on a premise that the user agent is 
> "mechanism-aware" (has a special 
> > button or recognizes "emergency" numbers).
> 
> Not really. I can take a SIP phone and dial 911 or any of the other 
> numbers and that would work (assuming it gets translated to a 
> tel URI) 
> or dial sos@mydomain and this will work, without any UA modification. 
> Clearly, some proxy has to recognize these identifiers, but 
> UAs do not. 
> (Actually, even that's not true for the common case where the 
> gateway is 
> in the same country. Dialing tel:911 today may work, even 
> though you may 
> be talking to a police department that's in a different part of the 
> country.)
> 
> > 
> > Special domain: Same as tel:uri.
> > 
> > Further, the statement in support of not using the tel:sos 
> scheme also says 
> > that the "SIP URI proposed here only requires a user's home 
> domain to be 
> > appropriately configured". This is a major disadvantage 
> with this scheme, 
> > which I suppose has been the subject of some past 
> discussions. There is a 
> > fundamental problem with this approach. The user's home 
> domain is not subject 
> > to any of the regulations that apply to the local area 
> regarding the support 
> > of emergency telephone service. It couldn't even be 
> required to support it. 
> 
> I don't know what you mean by 'local area'. I don't see how I can 
> require Starbucks to support a PSTN gateway in each of its 
> 802.11 hot spots.
> 
> > Depending on the user's home domain to know how to handle 
> emergency calls for 
> > the area that the user is in (if the home domain even knows 
> where they are) 
> > is very problematic. It presumes that the home domain not 
> only understands 
> > the "sos.", but knows how to call the emergency service 
> local to the user. I 
> > can't imagine for a monent that any local regulatory body 
> (which, in the end, 
> > controls how emergency services are reached) would accept a 
> scheme that 
> > depends on some distant equipment, which it does not 
> control through 
> > regulations, to be the critical point in providing 
> emergency service.
> 
> Are you mandating that every LAN, every 802.11 hotspot, every IETF 
> wireless LAN has to have:
> - an outbound SIP proxy server, and
> - a PSTN gateway that can dial 911
> ?
> 
> Good luck. I'm trying to build a system that will work well 
> once this is 
> true and will work ok (and be testable) until this is true.
> 
> 
> > 
> > The solution to the above is to state that the outbound 
> proxy must recognize 
> > and take action on all emergency calls, whether dialed with 
> 911, 118, etc. or 
> 
> The draft already says that. The problem is that there may be no 
> outbound proxy in every LAN or local geographic area. After 
> all, this is 
> not a mandatory piece of equipment and not every network will be 
> SIP-aware. I want to be able to use SIP phones without local support. 
> Once we have outbound proxies everywhere, things will work 
> better (and 
> exactly as well as your proposal).
> 
> > by the use of a special button on the phone which sends a 
> special URI. The 
> > URI can be some new form defined within the context of the 
> tel:url, since it 
> > is intended as a direct replacement for a telephone number, 
> or some other 
> > form. The user's home domain is never responsible to 
> handling emergency 
> > calls. Further, all calls require the use of an outbound 
> proxy. (The 
> > alternative is for the phone itself to be able to perform 
> the functions of 
> > the outbound proxy, which requires, among other things, 
> that it know the 
> > entire local dialing plan. It could know this through 
> configuration or 
> > download of parameters when it is turned on.)
> > 
> > (See, I said it was controversial!)
> 
> 
> > 
> > Mike Pierce
> > Artel
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Tue Jan  7 13:18:37 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23219
	for <sipping-archive@odin.ietf.org>; Tue, 7 Jan 2003 13:18:37 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h07ITR908216
	for sipping-archive@odin.ietf.org; Tue, 7 Jan 2003 13:29:27 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07ITQJ08213
	for <sipping-web-archive@optimus.ietf.org>; Tue, 7 Jan 2003 13:29:26 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23187
	for <sipping-web-archive@ietf.org>; Tue, 7 Jan 2003 13:17:52 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07IOkJ07955;
	Tue, 7 Jan 2003 13:24:46 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07INOJ07914
	for <sipping@optimus.ietf.org>; Tue, 7 Jan 2003 13:23:24 -0500
Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22909
	for <sipping@ietf.org>; Tue, 7 Jan 2003 13:11:58 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h07IFlmh016150;
	Tue, 7 Jan 2003 13:15:48 -0500 (EST)
Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAX46860;
	Tue, 7 Jan 2003 13:20:07 -0500 (EST)
Message-ID: <3E1B1929.8040507@cisco.com>
Date: Tue, 07 Jan 2003 13:15:05 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mpierce1@aol.com
CC: hgs@cs.columbia.edu, sipping@ietf.org
Subject: Re: [Sipping] Comments on sos draft -03 (URI)
References: <128.1f9ae0e1.2b4c5ecc@aol.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Mpierce1@aol.com wrote:
> 
> The solution to the above is to state that the outbound proxy must recognize 
> and take action on all emergency calls, whether dialed with 911, 118, etc. or 
> by the use of a special button on the phone which sends a special URI. The 
> URI can be some new form defined within the context of the tel:url, since it 
> is intended as a direct replacement for a telephone number, or some other 
> form. The user's home domain is never responsible to handling emergency 
> calls. Further, all calls require the use of an outbound proxy. (The 
> alternative is for the phone itself to be able to perform the functions of 
> the outbound proxy, which requires, among other things, that it know the 
> entire local dialing plan. It could know this through configuration or 
> download of parameters when it is turned on.)

Are you suggesting that it be illegal to have a portable device that 
doesn't use a local proxy? (E.g. a satelite phone, or an 802.11b based 
phone.)

These are very meaningful devices to consider. And its not clear (to me) 
if they are even subject to any regulatory requirements about local 
emergency service. If I'm wandering around Iraq with my satelite phone 
and dial the local emergency number, is my call supposed to be routed 
from the satelite to some local Iraq proxy to check for local emergency 
numbers?

Also, there are some problems with using a local proxy to provide dial 
plan and so resolve emergency services. tel:911 is not a valid tel uri - 
it must have a context, such as tel:911;phone-context=+1. However, for a 
mobile phone it is difficult to know what context to use. It might need 
to be discovered at the same time as the local proxy is selected. This 
is equivalent to requiring the phone to obtain a local dial plan.

	Paul

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Tue Jan  7 13:49:58 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23978
	for <sipping-archive@odin.ietf.org>; Tue, 7 Jan 2003 13:49:58 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h07J0mG09922
	for sipping-archive@odin.ietf.org; Tue, 7 Jan 2003 14:00:48 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07J0mJ09919
	for <sipping-web-archive@optimus.ietf.org>; Tue, 7 Jan 2003 14:00:48 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23940
	for <sipping-web-archive@ietf.org>; Tue, 7 Jan 2003 13:49:22 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07IuLJ09770;
	Tue, 7 Jan 2003 13:56:21 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07ItWJ09734
	for <sipping@optimus.ietf.org>; Tue, 7 Jan 2003 13:55:32 -0500
Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23857
	for <sipping@ietf.org>; Tue, 7 Jan 2003 13:44:10 -0500 (EST)
Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66])
	(user=hgs10 mech=PLAIN bits=0)
	by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h07IlOhg023842
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Tue, 7 Jan 2003 13:47:24 -0500 (EST)
Message-ID: <3E1B20D8.1000602@cs.columbia.edu>
Date: Tue, 07 Jan 2003 13:47:52 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
CC: Mpierce1@aol.com, sipping@ietf.org
Subject: Re: [Sipping] Comments on sos draft -03 (URI)
References: <313680C9A886D511A06000204840E1CF030B5CD0@whq-msgusr-02.pit.comms.marconi.com>
In-Reply-To: <313680C9A886D511A06000204840E1CF030B5CD0@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

This is another argument for having the end system convert locally 
recognized digit strings into 'sos'.

My

Rosen, Brian wrote:
> I don't think this works.  Not all dialing plans are the same,
> and even if all 3G phones have the same dialing plans, that
> won't be the same as, say, an enterprise telephony system.
> 
> In most US enterprises, and for that matter, in most US college
> campuses, the emergency number is 9-911.  911 would not connect

I think there are attempts to change this; see 
http://emergency.lib.uci.edu/ or 
http://www.news.cornell.edu/Chronicle/97/7.24.97/911.html or 
http://www.med.umich.edu/medschool/faculty/handbook/phones.html
for some quick Google research.

I doubt that anybody sane will assign somebody extension 911.

> (the 9 would be interpreted as "outside line", and the 11 would
> probably be interpreted as an illegal number).  In a "greenfield"
> all-VoIP system, this could be changed, but in general, it can't.
> A great many enterprise systems have 3 digit extensions where 1
> is a legal first digit. 

There are probably two pragmatic approaches:

- Network-based: Don't assign 000, 08, 112, 110, 118, 119, 911 and 999 
as regular numbers. 0-00 would seem to be difficult since that's the 
common way that you'd dial an international number from a European PBX 
phone. However, it should never appear as anything but the initial part 
of an overlap dialing string, which wouldn't be in a tel: URI to begin with.

One can argue how difficult it would be to vacate the other half dozen 
numbers.

- UA-based: The UA recognizes these numbers and then asks whether you 
want extension 112 or emergency. 
(http://www.citrus.usda.gov/Staff2001.htm has them all :-)) If it's the 
extension, the normal tel:112;phone-context mechanism tells the proxy 
that it shouldn't call the fire department.

Needless to say, neither approach is particularly satisfactory. Since 
the outbound proxy is the one mangling extension 112 into an emergency 
call, it might be nice to able to ask it. Generalized, having a 
mechanism where you can ask a proxy what it would do with a tel URI 
would be nice. OPTIONS with Max-Forward plus one of the tracing 
mechanism discussed (Jiri's draft, say) here may come close, but seems 
rather complicated.

Clearly, this could be part of the SIP device configuration, but that 
wouldn't help for a visiting device that gets its configuration from home.

Henning

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Tue Jan  7 14:04:28 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24550
	for <sipping-archive@odin.ietf.org>; Tue, 7 Jan 2003 14:04:28 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h07JFJS11114
	for sipping-archive@odin.ietf.org; Tue, 7 Jan 2003 14:15:19 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07JFGJ11109
	for <sipping-web-archive@optimus.ietf.org>; Tue, 7 Jan 2003 14:15:16 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24468
	for <sipping-web-archive@ietf.org>; Tue, 7 Jan 2003 14:02:52 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07JA9J10886;
	Tue, 7 Jan 2003 14:10:09 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07J98J10835
	for <sipping@optimus.ietf.org>; Tue, 7 Jan 2003 14:09:08 -0500
Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24235
	for <sipping@ietf.org>; Tue, 7 Jan 2003 13:57:46 -0500 (EST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA04691;
	Tue, 7 Jan 2003 14:01:00 -0500 (EST)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA06806;
	Tue, 7 Jan 2003 14:01:00 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <ZVACKPAL>; Tue, 7 Jan 2003 14:01:00 -0500
Message-ID: <313680C9A886D511A06000204840E1CF030B5CD1@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Henning Schulzrinne'" <hgs@cs.columbia.edu>
Cc: Mpierce1@aol.com, sipping@ietf.org
Subject: RE: [Sipping] Comments on sos draft -03 (URI)
Date: Tue, 7 Jan 2003 14:00:52 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

I agree as long as "locally recognized" is learned from some site-dependent
entity (e.g. DHCP); it can't be built in.

> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Tuesday, January 07, 2003 1:48 PM
> To: Rosen, Brian
> Cc: Mpierce1@aol.com; sipping@ietf.org
> Subject: Re: [Sipping] Comments on sos draft -03 (URI)
> 
> 
> This is another argument for having the end system convert locally 
> recognized digit strings into 'sos'.
> 
> My
> 
> Rosen, Brian wrote:
> > I don't think this works.  Not all dialing plans are the same,
> > and even if all 3G phones have the same dialing plans, that
> > won't be the same as, say, an enterprise telephony system.
> > 
> > In most US enterprises, and for that matter, in most US college
> > campuses, the emergency number is 9-911.  911 would not connect
> 
> I think there are attempts to change this; see 
> http://emergency.lib.uci.edu/ or 
> http://www.news.cornell.edu/Chronicle/97/7.24.97/911.html or 
> http://www.med.umich.edu/medschool/faculty/handbook/phones.html
> for some quick Google research.
> 
> I doubt that anybody sane will assign somebody extension 911.
> 
> > (the 9 would be interpreted as "outside line", and the 11 would
> > probably be interpreted as an illegal number).  In a "greenfield"
> > all-VoIP system, this could be changed, but in general, it can't.
> > A great many enterprise systems have 3 digit extensions where 1
> > is a legal first digit. 
> 
> There are probably two pragmatic approaches:
> 
> - Network-based: Don't assign 000, 08, 112, 110, 118, 119, 
> 911 and 999 
> as regular numbers. 0-00 would seem to be difficult since that's the 
> common way that you'd dial an international number from a 
> European PBX 
> phone. However, it should never appear as anything but the 
> initial part 
> of an overlap dialing string, which wouldn't be in a tel: URI 
> to begin with.
> 
> One can argue how difficult it would be to vacate the other 
> half dozen 
> numbers.
> 
> - UA-based: The UA recognizes these numbers and then asks whether you 
> want extension 112 or emergency. 
> (http://www.citrus.usda.gov/Staff2001.htm has them all :-)) 
> If it's the 
> extension, the normal tel:112;phone-context mechanism tells the proxy 
> that it shouldn't call the fire department.
> 
> Needless to say, neither approach is particularly satisfactory. Since 
> the outbound proxy is the one mangling extension 112 into an 
> emergency 
> call, it might be nice to able to ask it. Generalized, having a 
> mechanism where you can ask a proxy what it would do with a tel URI 
> would be nice. OPTIONS with Max-Forward plus one of the tracing 
> mechanism discussed (Jiri's draft, say) here may come close, 
> but seems 
> rather complicated.
> 
> Clearly, this could be part of the SIP device configuration, but that 
> wouldn't help for a visiting device that gets its 
> configuration from home.
> 
> Henning
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Tue Jan  7 14:15:06 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25120
	for <sipping-archive@odin.ietf.org>; Tue, 7 Jan 2003 14:15:06 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h07JPv611565
	for sipping-archive@odin.ietf.org; Tue, 7 Jan 2003 14:25:57 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07JPvJ11562
	for <sipping-web-archive@optimus.ietf.org>; Tue, 7 Jan 2003 14:25:57 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25025
	for <sipping-web-archive@ietf.org>; Tue, 7 Jan 2003 14:13:23 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07JNIJ11460;
	Tue, 7 Jan 2003 14:23:18 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07JM4J11408
	for <sipping@optimus.ietf.org>; Tue, 7 Jan 2003 14:22:04 -0500
Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24942
	for <sipping@ietf.org>; Tue, 7 Jan 2003 14:10:42 -0500 (EST)
Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66])
	(user=hgs10 mech=PLAIN bits=0)
	by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h07JDvhg012428
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Tue, 7 Jan 2003 14:13:58 -0500 (EST)
Message-ID: <3E1B2712.4060501@cs.columbia.edu>
Date: Tue, 07 Jan 2003 14:14:26 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
CC: sipping@ietf.org
Subject: Re: [Sipping] Comments on sos draft -03 (URI)
References: <313680C9A886D511A06000204840E1CF030B5CD1@whq-msgusr-02.pit.comms.marconi.com>
In-Reply-To: <313680C9A886D511A06000204840E1CF030B5CD1@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Rosen, Brian wrote:
> I agree as long as "locally recognized" is learned from some site-dependent
> entity (e.g. DHCP); it can't be built in.

While I proposed DHCP in -04, I am concerned that the strings announced 
by DHCP are not guaranteed to be the strings recognized by the outbound 
proxy. This is not a problem if DHCP also announces the outbound proxy 
server. Thus, this mechanism should be used only in conjunction with RFC 
3361.

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Tue Jan  7 14:58:54 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26583
	for <sipping-archive@odin.ietf.org>; Tue, 7 Jan 2003 14:58:53 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h07K9kc14785
	for sipping-archive@odin.ietf.org; Tue, 7 Jan 2003 15:09:46 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07K9kJ14782
	for <sipping-web-archive@optimus.ietf.org>; Tue, 7 Jan 2003 15:09:46 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26563
	for <sipping-web-archive@ietf.org>; Tue, 7 Jan 2003 14:58:15 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07K8SJ14705;
	Tue, 7 Jan 2003 15:08:28 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07K7fJ14581
	for <sipping@optimus.ietf.org>; Tue, 7 Jan 2003 15:07:41 -0500
Received: from zoe.office.snowshore.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26518
	for <sipping@ietf.org>; Tue, 7 Jan 2003 14:56:16 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps?
Date: Tue, 7 Jan 2003 14:59:32 -0500
Message-ID: <4A3384433CE2AB46A63468CB207E209D24864B@zoe.office.snowshore.com>
Thread-Topic: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps?
Thread-Index: AcK2Tx7fsfsYx14yRXSUmMADoydQZQAND8IA
From: "Eric Burger" <eburger@snowshore.com>
To: "Steve Fisher" <sfisher1@att.com>
Cc: <sipping@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h07K7fJ14582
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

To answer the question directly: 

KPML only works with HTTP reporting.  It would be a different language for SIP reporting.  MSCML is an example of a language that uses SIP for reporting.



To answer the SIP stimulus reporting question:

Done INFO in the past, not planning on it again :-)

NOTIFY is my leading contender, but a new method may be needed because if you do a strict reading of NOTIFY, you might not want a NOTIFY without a SUBSCRIBE.

Using SUBSCRIBE as a method of pushing KPML is out and out evil (I mean wrong).  KPML changes the state of the UAS.  SUBSCRIBE is not supposed to have any side-effects.



> -----Original Message-----
> From: Steve Fisher [mailto:sfisher1@att.com]
> Sent: Tuesday, January 07, 2003 8:15 AM
> To: Eric Burger
> Cc: sipping@ietf.org
> Subject: RE: [Sipping] Stimulus Signaling/Markup between 
> complex SIP UAs
> and apps?
> 
> 
> Eric,
> 
> I've been thinking about your statement below...
> 
> > > If we say SIP for stimulus reporting, then the diagram you drew, 
> > > with the implication that the signaling follows the 
> signaling path, 
> > > is what will occur.
> > > 
> > > Is this distinction important for you?  The design team 
> did not come
> 
> > > to full agreement on which way to go.  Compelling 
> arguments either 
> > > way welcomed.
> 
> Could you possibly elaborate on how "SIP for stimulus reporting" would
> work? Are you thinking of SUBSCRIBE/NOTIFY? Are you thinking of using
> INFO? It's fairly clear from the KPML draft how HTTP would 
> work, but SIP
> was less clear to me...
> 
> Thanks!
> Steve
> 
> -----Original Message-----
> From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf
> Of Eric Burger
> Sent: Tuesday, December 17, 2002 5:18 PM
> To: Don Stanwyck
> Cc: sipping@ietf.org; Jain, Rajnish (Rajnish)
> Subject: RE: [Sipping] Stimulus Signaling/Markup between 
> complex SIP UAs
> and apps?
> 
> 
> Rajnish is 1000% correct in his interpretation.  Looking at 
> the message
> I can see how my statement isn't entirely clear.
> 
> I am on record in this and other fora that H.248 and J.162 are the
> appropriate protocols for device control.  See my posts to 
> the speechsc
> list.  I should have a paste buffer with my "Don't use SIP 
> for low-level
> peripheral device control" rant.
> 
> When I said "It [the thing referenced as "softswitch" in Rajnish's
> e-mail -- ewb] is not a media gateway controller" I meant it was not a
> media gateway controller, e.g., a device control thing, which uses
> device control protocols like H.248 and J.162.
> 
> Now it's my turn for interpreting Rajnish, instead of him interpreting
> me :-)  I assumed that the "PSTN X" thing was a MG-MGC combination,
> speaking SIP on the packet network side.  E.g., the MG-MGC 
> interface was
> a private matter, not of interest to the discussion.
> 
> Sorry for the confusion.
> 
> > -----Original Message-----
> > From: Jain, Rajnish (Rajnish) [mailto:rajnishjain@lucent.com]
> > Sent: Tuesday, December 17, 2002 4:02 PM
> > To: 'Don Stanwyck'; Eric Burger; Jain, Rajnish (Rajnish)
> > Cc: sipping@ietf.org; Twomey, Michael S (Michael)
> > Subject: RE: [Sipping] Stimulus Signaling/Markup between
> > complex SIP UAs
> > and apps?
> > 
> > 
> > Don,
> > I don't think Eric implied controlling a MG from a Softswitch
> > via SIP in his
> > comment. That particular topic has come up in this forum many 
> > times and as I 
> > recall the conclusion has always been that SIP is not meant 
> > for that. SIP is 
> > a peer-to-peer to protocol not a master-slave protcol - 
> > agreed. However this
> > is completely orthogonal to using stimulus/markup signaling 
> > in SIP.  I don't
> > see how in-lining a KPML doc (e.g.) in a SIP message breaks 
> > SIP paradigm. 
> > 
> > Eric,
> > In general, I would like to propose an HTTP-free alternative
> > for delivery of 
> > stimulus signals, such as through in-lining of KPML. The 
> > benefits of such an
> > alternative in my mind are following:
> > 
> > - it would make it easier for SIP developers on embedded
> > platforms to embrace 
> >   markup/stimulus signaling that don't support HTTP currently
> > 
> > - it would facilitate close coordination between announcement
> > play and DTMF
> >   collection. Barge-in is a good example for that. The app 
> > can delegate the  
> >   job to stop announcement play at barge-in to the 
> > Softswitch. As an aside,
> >   the Softswitch in my previous figure is one w/ bizarre API 
> > as you say :-)
> > 
> > Rajnish
> > 
> > -----Original Message-----
> > From: Don Stanwyck [mailto:don@stanwyck.com]
> > Sent: Tuesday, December 17, 2002 3:10 PM
> > To: 'Eric Burger'; 'Jain, Rajnish (Rajnish)'
> > Cc: sipping@ietf.org; 'Twomey, Michael S (Michael)'
> > Subject: RE: [Sipping] Stimulus Signaling/Markup between
> > complex SIP UAs
> > and apps?
> > 
> > 
> > RFC 3261, Section 2 reads:
> > 
> > //START QUOTE
> > 
> > SIP supports five facets of establishing and terminating
> > multimedia communications:
> >   - User location: determination of the end system to be
> >     used for communication;
> >   - User availability: determination of the willingness
> >     of the called party to engage in communications;
> >   - User capabilities: determination of the media and media
> >     parameters to be used;
> >   - Session setup: "ringing", establishment of session
> >     parameters at both called and calling party;
> >   - Session management: including transfer and termination
> >     of sessions, modifying session parameters, and invoking
> >     services.
> > 
> > SIP is not a vertically integrated communications system.
> > SIP is rather
> > a component that can be used with other IETF protocols to build a
> > complete multimedia architecture.  Typically, these 
> architectures will
> > include protocols such as the Real-time Transport Protocol 
> (RTP) (RFC
> > 1889 [28]) for transporting real-time data and providing 
> QoS feedback,
> > the Real-Time streaming protocol (RTSP) (RFC 2326 [29]) for 
> > controlling
> > delivery of streaming media, the Media Gateway Control 
> > Protocol (MEGACO)
> > (RFC 3015 [30]) for controlling gateways to the Public Switched
> > Telephone Network (PSTN), and the Session Description Protocol (SDP)
> > (RFC 2327 [1]) for describing multimedia sessions.  Therefore, SIP
> > should be used in conjunction with other protocols in order 
> to provide
> > complete services to the users.  However, the basic 
> functionality and
> > operation of SIP does not depend on any of these protocols.
> > 
> > //END QUOTE
> > 
> > I can't find any support in this definition of SIP for
> > carrying stimulus
> > signaling or for controling media gateways (comment 1 in Eric's
> > comments).  SIP, as defined and approved by the IETF, is not 
> > expected to
> > do these kinds of things that other IETF protocols are designed to
> > handle.
> > 
> > Let's try to keep SIP doing the things it is designed to do 
> and does 
> > well, and not try to make it into a protocol for doing everything 
> > imaginable.  It is already in danger of becoming too difficult to 
> > implement as the number of options and new headers grows.
> > 
> > Don Stanwyck
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]
> > > On Behalf Of Eric Burger
> > > Sent: Tuesday, December 17, 2002 12:12 PM
> > > To: Jain, Rajnish (Rajnish)
> > > Cc: sipping@ietf.org; Twomey, Michael S (Michael)
> > > Subject: RE: [Sipping] Stimulus Signaling/Markup between 
> > > complex SIP UAs and apps?
> > > 
> > > 
> > > For timelines, I would suggest asking the work group chairs.
> > > We're at their mercy :-)
> > > 
> > > Putting my ISC hat on, what is the Softswitch in your diagram?
> > >   1. It is not a media gateway controller, as it talks to
> > >      the gateway with SIP (right answer, by the way).
> > >   2. Is it a Stateless Proxy, a'la the Routing Function
> > >      in the ISC reference diagram?  If so, that works
> > >      exactly as you want it to.  See below for more.
> > >   3. Is it an application server, a'la dynamicsoft,
> > >      Ubiquity, LongBoard, etc.?  If so, that also works
> > >      exactly as you want it to.  See below for more.
> > >   4. Is it some kind of statefull proxy, with a bizarre,
> > >      proprietary API to the pre-paid application (e.g., 
> > >      Parlay, JAIN, EXS, ...)?  If so, you are on your
> > >      own.
> > > 
> > > If we say "HTTP only" for stimulus reporting, the PSTN
> > > gateway must be a HTTP client.  The good news is the gateway 
> > > can communicate directly with the pre-paid application.  That 
> > > also means the pre-paid application needs to have a HTTP 
> > > server.  Alternatively, if the "Softswitch" is really a 
> > > telephony application server (case #3 above), then it 
> > > probably already has HTTP server capability built-in.
> > > 
> > > If we say SIP for stimulus reporting, then the diagram you
> > > drew, with the implication that the signaling follows the 
> > > signaling path, is what will occur.
> > > 
> > > Is this distinction important for you?  The design team did
> > > not come to full agreement on which way to go.  Compelling 
> > > arguments either way welcomed.
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Jain, Rajnish (Rajnish) [mailto:rajnishjain@lucent.com]
> > > > Sent: Friday, December 06, 2002 4:20 PM
> > > > To: Eric Burger; Jain, Rajnish (Rajnish)
> > > > Cc: sipping@ietf.org; Twomey, Michael S (Michael)
> > > > Subject: RE: [Sipping] Stimulus Signaling/Markup 
> between complex 
> > > > SIP UAs and apps?
> > > > 
> > > > 
> > > > Eric,
> > > > 
> > > > Thanks for your response. Would you be able to comment on the 
> > > > timeline of when does the design team hope to accomplish the
> > > > following:
> > > > 
> > > > - general acceptance of the stimulus signaling, KPML etc.
> > > > - standardization of app interaction fwk, KPML into an RFC
> > > > 
> > > > Regarding an example of a PSTN switch that can be 
> connected to a 
> > > > pre-paid app over SIP-T, I don't know how much I can 
> disclose in 
> > > > front of this forum, but that is something being looked at by a 
> > > > few telecom gear vendors in my understanding.
> > > > 
> > > > I wanted to bring your attention to SIP-T wrt to my
> > > previous question.
> > > > I believe your answer will remain the same but I just to
> > wanted to
> > > > re-iterate the question in different words this time,
> > just to make
> > > > sure we're communicating:
> > > > 
> > > > In the setup below:
> > > >                                Pre-paid app
> > > >                                    |
> > > > POTS ---- PSTN X <---SIP-T---> Softswitch ----
> > > >                                
> > > >     
> > > > .. you would think, application interaction framework concepts 
> > > > such as stimulus signaling, user-inetrfaces and KPML etc. are 
> > > > designed to work over the SIP-T i/f between packet-enabled PSTN 
> > > > switch and a Softswitch. Wouldn't you?
> > > > 
> > > > Thanks,
> > > > Rajnish
> > > > 
> > > > > -----Original Message----- From: Jain, Rajnish (Rajnish)
> > > [mailto:rajnishjain@lucent.com]
> > > > 
> > > > The Application Interaction Framework draft talks about stimulus
> > > > signaling as a way for SIP UAs to interact w/ SIP 
> > applications. The
> > > > draft suggests use of markup languages to allow
> > > applications to manage
> > > > local/remote user interfaces on SIP UAs.
> > > > 
> > > > While the draft exemplifies a UA's stimulus/markup 
> interaction w/ 
> > > > a pre-paid application server, it is not very clear to 
> us if the 
> > > > caller UA (instead of a subscriber end-point) can be a 
> complex UA 
> > > > such as the following:
> > > > 
> > > > - SIP (enabled) Gateway
> > > 
> > > Why not?  It does SIP.  It may do tone detection.
> > > 
> > > > - PSTN Switch w/ SIP-T interface
> > > 
> > > Why not?  It does SIP.  It may do tone detection.
> > > 
> > > > and does the draft recommend stimulus/markup signaling between 
> > > > such complex/concentrated UAs (or apps) and SIP applications ?
> > > 
> > > The draft is silent on it.  If you manufacture media rich
> > > gateways, you might say "of course".  If you manufacture 
> > > media servers, you might say "you could if you wanted, but 
> > > you would be better served if you didn't."  :-)
> > > 
> > > > In other words, does the stimulus signaling apply to following
> > > > scenarios ?:
> > > > 
> > > > 1. The pre-paid caller is connected to a PSTN switch that has a 
> > > > SIP-T interface to the pre-paid application.
> > > 
> > > Yes, so long as the PSTN switch is SIP-aware, able to parse
> > > and execute KPML, and report using SIP (or, yuck, http).
> > > 
> > > Do you know of such a switch?
> > >  
> > > > 2. The pre-paid caller is connected to a PBX (SIP 
> Gateway) over an
> 
> > > > ISDN i/f, which in turn is connected to the pre-paid app. over 
> > > > normal SIP.
> > > 
> > > Same issues as for the PSTN switch.
> > > 
> > > > If yes, would the terms client-local and client-remote still be
> > > > accurate, as the user here is a POTS/ISDN user? From the user's 
> > > > perspective, the UI would be client-remote. But from 
> > application's
> > > > perspective the UI would be client-local (as the UI will be
> > > on the PBX
> > > > or PSTN switch both of which look like a UA to app server).
> > > 
> > > It is still client-local, as the gateway/switch/PBX is a
> > > local proxy for the user.  If you used a media server in the 
> > > IP network behind the gateway/switch/PBX to execute the KPML, 
> > > then you would be cline-remote. 
> > > _______________________________________________
> > > Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> > > This list is for NEW development of the application of SIP
> > > Use sip-implementors@cs.columbia.edu for questions on current 
> > > sip Use sip@ietf.org for new developments of core SIP
> > > 
> > 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip Use
> sip@ietf.org for new developments of core SIP
> 
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Tue Jan  7 18:11:01 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02501
	for <sipping-archive@odin.ietf.org>; Tue, 7 Jan 2003 18:11:01 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h07NLuS26599
	for sipping-archive@odin.ietf.org; Tue, 7 Jan 2003 18:21:56 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07NLuJ26596
	for <sipping-web-archive@optimus.ietf.org>; Tue, 7 Jan 2003 18:21:56 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02399
	for <sipping-web-archive@ietf.org>; Tue, 7 Jan 2003 18:09:04 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07NEHJ26152;
	Tue, 7 Jan 2003 18:14:17 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07N98J25951
	for <sipping@optimus.ietf.org>; Tue, 7 Jan 2003 18:09:08 -0500
Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02069
	for <sipping@ietf.org>; Tue, 7 Jan 2003 17:57:37 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h07N1SpV028656
	for <sipping@ietf.org>; Tue, 7 Jan 2003 18:01:32 -0500 (EST)
Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAX49678;
	Tue, 7 Jan 2003 18:05:48 -0500 (EST)
Message-ID: <3E1B5C1E.3090801@cisco.com>
Date: Tue, 07 Jan 2003 18:00:46 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: sipping@ietf.org
Subject: Re: [Sipping] I-D ACTION:draft-barnes-sipping-history-info-01.txt
References: <200212231254.HAA27412@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

A comment about the recording of indices...

The syntax
              hi-index = "index" EQUAL 1*(DIGIT DOT )

permits indices of "...", "1..3", ".2" etc. These seem to be incorrect. 
A better syntax would be

              hi-index = "index" EQUAL 1*DIGIT *(DOT 1*DIGIT)

The only specification I could find for how this is maintained is in 
Section 2.2.3, which says:

     In order to maintain ordering and accurately reflect forking and
     nesting, the index should also be included, with the last digit
     being incremented as the request is retargeted.
     ...
     If the index is captured at
     each occurrence of retargeting, a proxy can more accurately capture
     the logical order and nesting involved.

This doesn't seem like enough to specify the maintenance of the index. 
Although doing this is straightforward, there ought to be some normative 
language about it. For instance the following are some issues about 
responsibility:

- if a proxy receives a request with a History-Info that has an index 
paramter, and adds another entry as it forwards the request on, MUST it 
place an index param on the new entry? If so, MUST it follow the 
intuitive rule for deriving the new index? (I think the answer should be 
YES to both of these.)

- if a proxy receives a request with a History-Info that has no index 
parameter, and it adds another entry as it forwards the request on, MAY 
it place an index param on the new entry? (I think it MUST NOT, because 
it has no way to determine a correct value.)

- if a proxy receives a request with no History-Info, and creates one 
with an initial entry, MAY it place an index param on the new entry? (I 
think it MUST NOT, because again it has no way to determine a correct 
value.)

If you buy my answers to the above, then it is the UAC that determines 
whether indices are used.

In any case, for the indices to be useful for anything there ought to be 
more normative text that specifies how they are managed.

	Paul

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Tue Jan  7 22:16:58 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09932
	for <sipping-archive@odin.ietf.org>; Tue, 7 Jan 2003 22:16:58 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h083RwT08678
	for sipping-archive@odin.ietf.org; Tue, 7 Jan 2003 22:27:58 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h083RvJ08675
	for <sipping-web-archive@optimus.ietf.org>; Tue, 7 Jan 2003 22:27:57 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09926
	for <sipping-web-archive@ietf.org>; Tue, 7 Jan 2003 22:16:19 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h083P0J08605;
	Tue, 7 Jan 2003 22:25:00 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h083NoJ08552
	for <sipping@optimus.ietf.org>; Tue, 7 Jan 2003 22:23:50 -0500
Received: from imo-r04.mx.aol.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09885
	for <sipping@ietf.org>; Tue, 7 Jan 2003 22:12:20 -0500 (EST)
From: Mpierce1@aol.com
Received: from Mpierce1@aol.com
	by imo-r04.mx.aol.com (mail_out_v34.13.) id 7.55.3592b34d (3657);
	Tue, 7 Jan 2003 22:15:15 -0500 (EST)
Message-ID: <55.3592b34d.2b4cf1c3@aol.com>
Date: Tue, 7 Jan 2003 22:15:15 EST
Subject: Re: [Sipping] Comments on sos draft -03 (URI)
To: hgs@cs.columbia.edu, Brian.Rosen@marconi.com
CC: sipping@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: AOL 6.0 for Windows XP US sub 51
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

In a message dated 1/7/2003 1:48:08 PM Eastern Standard Time, 
hgs@cs.columbia.edu writes:


I don't know what you mean by 'local area'. I don't see how I can 
require Starbucks to support a PSTN gateway in each of its 802.11 hot spots.

Are you mandating that every LAN, every 802.11 hotspot, every IETF 
wireless LAN has to have:
- an outbound SIP proxy server, and
- a PSTN gateway that can dial 911
?

[MAP] No, but if a LAN, 802.11 hotspot, etc claims to be providing "telephone 
service" then it should come under the regulatory requirements and provide 
proper service, which I believe requires what I was describing. Of course, if 
someone is not claiming to provide "telephone service", then it doesn't 
matter what happens or if their "home domain" fails to properly handle an 
emergency call.


Rosen, Brian wrote:
> 
> In most US enterprises, and for that matter, in most US college
> campuses, the emergency number is 9-911.  911 would not connect

[HS] I think there are attempts to change this; see 
http://emergency.lib.uci.edu/ or 
http://www.news.cornell.edu/Chronicle/97/7.24.97/911.html or 
http://www.med.umich.edu/medschool/faculty/handbook/phones.html
for some quick Google research.

I doubt that anybody sane will assign somebody extension 911.

[MAP] I agree fully that no one should assign an extension of 911 if they can 
avoid it and private systems should allow 911 to be interpreted as a call to 
emergency, even without prefixing it with a "9", but the point is that we 
can't design SIP phones, or protocols, or proxy functioning based on an 
assumption that no one is doing this. (Incidentally, this mean that some 
hotels would have to get rid of room number 911, just as some airplanes don't 
have a row 13.)


[HS] There are probably two pragmatic approaches:

- Network-based: Don't assign 000, 08, 112, 110, 118, 119, 911 and 999 
as regular numbers. 0-00 would seem to be difficult since that's the 
common way that you'd dial an international number from a European PBX 
phone. However, it should never appear as anything but the initial part 
of an overlap dialing string, which wouldn't be in a tel: URI to begin with.
[MAP] So does this mean that none of these numbers could be used as extension 
numbers? Or hotel room numbers?

[HS] One can argue how difficult it would be to vacate the other half dozen 
numbers.

[MAP] And one must also presume that it will never happen, and accept that 
these dialing strings (or numbers starting with them) will forever exist 
somewhere in the telephony world.

Mike Pierce
Artel
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Wed Jan  8 04:05:05 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14425
	for <sipping-archive@odin.ietf.org>; Wed, 8 Jan 2003 04:05:05 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h089GC506705
	for sipping-archive@odin.ietf.org; Wed, 8 Jan 2003 04:16:12 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h089GBJ06702
	for <sipping-web-archive@optimus.ietf.org>; Wed, 8 Jan 2003 04:16:11 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14413
	for <sipping-web-archive@ietf.org>; Wed, 8 Jan 2003 04:04:24 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h089E3J06429;
	Wed, 8 Jan 2003 04:14:04 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h089CuJ06342
	for <sipping@optimus.ietf.org>; Wed, 8 Jan 2003 04:12:56 -0500
Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14265
	for <sipping@ietf.org>; Wed, 8 Jan 2003 04:01:16 -0500 (EST)
From: hisham.khartabil@nokia.com
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0896Tt21523
	for <sipping@ietf.org>; Wed, 8 Jan 2003 11:06:29 +0200 (EET)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5fa9df34ceac158f230f3@esvir03nok.nokia.com>;
 Wed, 8 Jan 2003 11:04:30 +0200
Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 8 Jan 2003 11:04:29 +0200
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 8 Jan 2003 11:04:28 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps?
Date: Wed, 8 Jan 2003 11:04:28 +0200
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE70C7@esebe019.ntc.nokia.com>
Thread-Topic: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps?
Thread-Index: AcK2Tx7fsfsYx14yRXSUmMADoydQZQAND8IAABxHdzA=
To: <eburger@snowshore.com>, <sfisher1@att.com>
Cc: <sipping@ietf.org>
X-OriginalArrivalTime: 08 Jan 2003 09:04:28.0879 (UTC) FILETIME=[F33AD5F0:01C2B6F4]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h089CuJ06343
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

You can report KPML using HTTP, then use SUBSCRIBE/NOTIFY for stimulus reporting. But you might need to map one to the other using an id of some sort.

Presence package coupled with some publishing mechanism is a similar example. (early presence publishing was done using HTTP).

Regards,
Hisham

> -----Original Message-----
> From: ext Eric Burger [mailto:eburger@snowshore.com]
> Sent: Tuesday, January 07, 2003 10:00 PM
> To: Steve Fisher
> Cc: sipping@ietf.org
> Subject: RE: [Sipping] Stimulus Signaling/Markup between 
> complex SIP UAs
> and apps?
> 
> 
> To answer the question directly: 
> 
> KPML only works with HTTP reporting.  It would be a different 
> language for SIP reporting.  MSCML is an example of a 
> language that uses SIP for reporting.
> 
> 
> 
> To answer the SIP stimulus reporting question:
> 
> Done INFO in the past, not planning on it again :-)
> 
> NOTIFY is my leading contender, but a new method may be 
> needed because if you do a strict reading of NOTIFY, you 
> might not want a NOTIFY without a SUBSCRIBE.
> 
> Using SUBSCRIBE as a method of pushing KPML is out and out 
> evil (I mean wrong).  KPML changes the state of the UAS.  
> SUBSCRIBE is not supposed to have any side-effects.
> 
> 
> 
> > -----Original Message-----
> > From: Steve Fisher [mailto:sfisher1@att.com]
> > Sent: Tuesday, January 07, 2003 8:15 AM
> > To: Eric Burger
> > Cc: sipping@ietf.org
> > Subject: RE: [Sipping] Stimulus Signaling/Markup between 
> > complex SIP UAs
> > and apps?
> > 
> > 
> > Eric,
> > 
> > I've been thinking about your statement below...
> > 
> > > > If we say SIP for stimulus reporting, then the diagram 
> you drew, 
> > > > with the implication that the signaling follows the 
> > signaling path, 
> > > > is what will occur.
> > > > 
> > > > Is this distinction important for you?  The design team 
> > did not come
> > 
> > > > to full agreement on which way to go.  Compelling 
> > arguments either 
> > > > way welcomed.
> > 
> > Could you possibly elaborate on how "SIP for stimulus 
> reporting" would
> > work? Are you thinking of SUBSCRIBE/NOTIFY? Are you 
> thinking of using
> > INFO? It's fairly clear from the KPML draft how HTTP would 
> > work, but SIP
> > was less clear to me...
> > 
> > Thanks!
> > Steve
> > 
> > -----Original Message-----
> > From: sipping-admin@ietf.org 
> [mailto:sipping-admin@ietf.org] On Behalf
> > Of Eric Burger
> > Sent: Tuesday, December 17, 2002 5:18 PM
> > To: Don Stanwyck
> > Cc: sipping@ietf.org; Jain, Rajnish (Rajnish)
> > Subject: RE: [Sipping] Stimulus Signaling/Markup between 
> > complex SIP UAs
> > and apps?
> > 
> > 
> > Rajnish is 1000% correct in his interpretation.  Looking at 
> > the message
> > I can see how my statement isn't entirely clear.
> > 
> > I am on record in this and other fora that H.248 and J.162 are the
> > appropriate protocols for device control.  See my posts to 
> > the speechsc
> > list.  I should have a paste buffer with my "Don't use SIP 
> > for low-level
> > peripheral device control" rant.
> > 
> > When I said "It [the thing referenced as "softswitch" in Rajnish's
> > e-mail -- ewb] is not a media gateway controller" I meant 
> it was not a
> > media gateway controller, e.g., a device control thing, which uses
> > device control protocols like H.248 and J.162.
> > 
> > Now it's my turn for interpreting Rajnish, instead of him 
> interpreting
> > me :-)  I assumed that the "PSTN X" thing was a MG-MGC combination,
> > speaking SIP on the packet network side.  E.g., the MG-MGC 
> > interface was
> > a private matter, not of interest to the discussion.
> > 
> > Sorry for the confusion.
> > 
> > > -----Original Message-----
> > > From: Jain, Rajnish (Rajnish) [mailto:rajnishjain@lucent.com]
> > > Sent: Tuesday, December 17, 2002 4:02 PM
> > > To: 'Don Stanwyck'; Eric Burger; Jain, Rajnish (Rajnish)
> > > Cc: sipping@ietf.org; Twomey, Michael S (Michael)
> > > Subject: RE: [Sipping] Stimulus Signaling/Markup between
> > > complex SIP UAs
> > > and apps?
> > > 
> > > 
> > > Don,
> > > I don't think Eric implied controlling a MG from a Softswitch
> > > via SIP in his
> > > comment. That particular topic has come up in this forum many 
> > > times and as I 
> > > recall the conclusion has always been that SIP is not meant 
> > > for that. SIP is 
> > > a peer-to-peer to protocol not a master-slave protcol - 
> > > agreed. However this
> > > is completely orthogonal to using stimulus/markup signaling 
> > > in SIP.  I don't
> > > see how in-lining a KPML doc (e.g.) in a SIP message breaks 
> > > SIP paradigm. 
> > > 
> > > Eric,
> > > In general, I would like to propose an HTTP-free alternative
> > > for delivery of 
> > > stimulus signals, such as through in-lining of KPML. The 
> > > benefits of such an
> > > alternative in my mind are following:
> > > 
> > > - it would make it easier for SIP developers on embedded
> > > platforms to embrace 
> > >   markup/stimulus signaling that don't support HTTP currently
> > > 
> > > - it would facilitate close coordination between announcement
> > > play and DTMF
> > >   collection. Barge-in is a good example for that. The app 
> > > can delegate the  
> > >   job to stop announcement play at barge-in to the 
> > > Softswitch. As an aside,
> > >   the Softswitch in my previous figure is one w/ bizarre API 
> > > as you say :-)
> > > 
> > > Rajnish
> > > 
> > > -----Original Message-----
> > > From: Don Stanwyck [mailto:don@stanwyck.com]
> > > Sent: Tuesday, December 17, 2002 3:10 PM
> > > To: 'Eric Burger'; 'Jain, Rajnish (Rajnish)'
> > > Cc: sipping@ietf.org; 'Twomey, Michael S (Michael)'
> > > Subject: RE: [Sipping] Stimulus Signaling/Markup between
> > > complex SIP UAs
> > > and apps?
> > > 
> > > 
> > > RFC 3261, Section 2 reads:
> > > 
> > > //START QUOTE
> > > 
> > > SIP supports five facets of establishing and terminating
> > > multimedia communications:
> > >   - User location: determination of the end system to be
> > >     used for communication;
> > >   - User availability: determination of the willingness
> > >     of the called party to engage in communications;
> > >   - User capabilities: determination of the media and media
> > >     parameters to be used;
> > >   - Session setup: "ringing", establishment of session
> > >     parameters at both called and calling party;
> > >   - Session management: including transfer and termination
> > >     of sessions, modifying session parameters, and invoking
> > >     services.
> > > 
> > > SIP is not a vertically integrated communications system.
> > > SIP is rather
> > > a component that can be used with other IETF protocols to build a
> > > complete multimedia architecture.  Typically, these 
> > architectures will
> > > include protocols such as the Real-time Transport Protocol 
> > (RTP) (RFC
> > > 1889 [28]) for transporting real-time data and providing 
> > QoS feedback,
> > > the Real-Time streaming protocol (RTSP) (RFC 2326 [29]) for 
> > > controlling
> > > delivery of streaming media, the Media Gateway Control 
> > > Protocol (MEGACO)
> > > (RFC 3015 [30]) for controlling gateways to the Public Switched
> > > Telephone Network (PSTN), and the Session Description 
> Protocol (SDP)
> > > (RFC 2327 [1]) for describing multimedia sessions.  Therefore, SIP
> > > should be used in conjunction with other protocols in order 
> > to provide
> > > complete services to the users.  However, the basic 
> > functionality and
> > > operation of SIP does not depend on any of these protocols.
> > > 
> > > //END QUOTE
> > > 
> > > I can't find any support in this definition of SIP for
> > > carrying stimulus
> > > signaling or for controling media gateways (comment 1 in Eric's
> > > comments).  SIP, as defined and approved by the IETF, is not 
> > > expected to
> > > do these kinds of things that other IETF protocols are designed to
> > > handle.
> > > 
> > > Let's try to keep SIP doing the things it is designed to do 
> > and does 
> > > well, and not try to make it into a protocol for doing everything 
> > > imaginable.  It is already in danger of becoming too difficult to 
> > > implement as the number of options and new headers grows.
> > > 
> > > Don Stanwyck
> > > 
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]
> > > > On Behalf Of Eric Burger
> > > > Sent: Tuesday, December 17, 2002 12:12 PM
> > > > To: Jain, Rajnish (Rajnish)
> > > > Cc: sipping@ietf.org; Twomey, Michael S (Michael)
> > > > Subject: RE: [Sipping] Stimulus Signaling/Markup between 
> > > > complex SIP UAs and apps?
> > > > 
> > > > 
> > > > For timelines, I would suggest asking the work group chairs.
> > > > We're at their mercy :-)
> > > > 
> > > > Putting my ISC hat on, what is the Softswitch in your diagram?
> > > >   1. It is not a media gateway controller, as it talks to
> > > >      the gateway with SIP (right answer, by the way).
> > > >   2. Is it a Stateless Proxy, a'la the Routing Function
> > > >      in the ISC reference diagram?  If so, that works
> > > >      exactly as you want it to.  See below for more.
> > > >   3. Is it an application server, a'la dynamicsoft,
> > > >      Ubiquity, LongBoard, etc.?  If so, that also works
> > > >      exactly as you want it to.  See below for more.
> > > >   4. Is it some kind of statefull proxy, with a bizarre,
> > > >      proprietary API to the pre-paid application (e.g., 
> > > >      Parlay, JAIN, EXS, ...)?  If so, you are on your
> > > >      own.
> > > > 
> > > > If we say "HTTP only" for stimulus reporting, the PSTN
> > > > gateway must be a HTTP client.  The good news is the gateway 
> > > > can communicate directly with the pre-paid application.  That 
> > > > also means the pre-paid application needs to have a HTTP 
> > > > server.  Alternatively, if the "Softswitch" is really a 
> > > > telephony application server (case #3 above), then it 
> > > > probably already has HTTP server capability built-in.
> > > > 
> > > > If we say SIP for stimulus reporting, then the diagram you
> > > > drew, with the implication that the signaling follows the 
> > > > signaling path, is what will occur.
> > > > 
> > > > Is this distinction important for you?  The design team did
> > > > not come to full agreement on which way to go.  Compelling 
> > > > arguments either way welcomed.
> > > > 
> > > > 
> > > > > -----Original Message-----
> > > > > From: Jain, Rajnish (Rajnish) [mailto:rajnishjain@lucent.com]
> > > > > Sent: Friday, December 06, 2002 4:20 PM
> > > > > To: Eric Burger; Jain, Rajnish (Rajnish)
> > > > > Cc: sipping@ietf.org; Twomey, Michael S (Michael)
> > > > > Subject: RE: [Sipping] Stimulus Signaling/Markup 
> > between complex 
> > > > > SIP UAs and apps?
> > > > > 
> > > > > 
> > > > > Eric,
> > > > > 
> > > > > Thanks for your response. Would you be able to comment on the 
> > > > > timeline of when does the design team hope to accomplish the
> > > > > following:
> > > > > 
> > > > > - general acceptance of the stimulus signaling, KPML etc.
> > > > > - standardization of app interaction fwk, KPML into an RFC
> > > > > 
> > > > > Regarding an example of a PSTN switch that can be 
> > connected to a 
> > > > > pre-paid app over SIP-T, I don't know how much I can 
> > disclose in 
> > > > > front of this forum, but that is something being 
> looked at by a 
> > > > > few telecom gear vendors in my understanding.
> > > > > 
> > > > > I wanted to bring your attention to SIP-T wrt to my
> > > > previous question.
> > > > > I believe your answer will remain the same but I just to
> > > wanted to
> > > > > re-iterate the question in different words this time,
> > > just to make
> > > > > sure we're communicating:
> > > > > 
> > > > > In the setup below:
> > > > >                                Pre-paid app
> > > > >                                    |
> > > > > POTS ---- PSTN X <---SIP-T---> Softswitch ----
> > > > >                                
> > > > >     
> > > > > .. you would think, application interaction framework 
> concepts 
> > > > > such as stimulus signaling, user-inetrfaces and KPML etc. are 
> > > > > designed to work over the SIP-T i/f between 
> packet-enabled PSTN 
> > > > > switch and a Softswitch. Wouldn't you?
> > > > > 
> > > > > Thanks,
> > > > > Rajnish
> > > > > 
> > > > > > -----Original Message----- From: Jain, Rajnish (Rajnish)
> > > > [mailto:rajnishjain@lucent.com]
> > > > > 
> > > > > The Application Interaction Framework draft talks 
> about stimulus
> > > > > signaling as a way for SIP UAs to interact w/ SIP 
> > > applications. The
> > > > > draft suggests use of markup languages to allow
> > > > applications to manage
> > > > > local/remote user interfaces on SIP UAs.
> > > > > 
> > > > > While the draft exemplifies a UA's stimulus/markup 
> > interaction w/ 
> > > > > a pre-paid application server, it is not very clear to 
> > us if the 
> > > > > caller UA (instead of a subscriber end-point) can be a 
> > complex UA 
> > > > > such as the following:
> > > > > 
> > > > > - SIP (enabled) Gateway
> > > > 
> > > > Why not?  It does SIP.  It may do tone detection.
> > > > 
> > > > > - PSTN Switch w/ SIP-T interface
> > > > 
> > > > Why not?  It does SIP.  It may do tone detection.
> > > > 
> > > > > and does the draft recommend stimulus/markup 
> signaling between 
> > > > > such complex/concentrated UAs (or apps) and SIP applications ?
> > > > 
> > > > The draft is silent on it.  If you manufacture media rich
> > > > gateways, you might say "of course".  If you manufacture 
> > > > media servers, you might say "you could if you wanted, but 
> > > > you would be better served if you didn't."  :-)
> > > > 
> > > > > In other words, does the stimulus signaling apply to following
> > > > > scenarios ?:
> > > > > 
> > > > > 1. The pre-paid caller is connected to a PSTN switch 
> that has a 
> > > > > SIP-T interface to the pre-paid application.
> > > > 
> > > > Yes, so long as the PSTN switch is SIP-aware, able to parse
> > > > and execute KPML, and report using SIP (or, yuck, http).
> > > > 
> > > > Do you know of such a switch?
> > > >  
> > > > > 2. The pre-paid caller is connected to a PBX (SIP 
> > Gateway) over an
> > 
> > > > > ISDN i/f, which in turn is connected to the pre-paid 
> app. over 
> > > > > normal SIP.
> > > > 
> > > > Same issues as for the PSTN switch.
> > > > 
> > > > > If yes, would the terms client-local and 
> client-remote still be
> > > > > accurate, as the user here is a POTS/ISDN user? From 
> the user's 
> > > > > perspective, the UI would be client-remote. But from 
> > > application's
> > > > > perspective the UI would be client-local (as the UI will be
> > > > on the PBX
> > > > > or PSTN switch both of which look like a UA to app server).
> > > > 
> > > > It is still client-local, as the gateway/switch/PBX is a
> > > > local proxy for the user.  If you used a media server in the 
> > > > IP network behind the gateway/switch/PBX to execute the KPML, 
> > > > then you would be cline-remote. 
> > > > _______________________________________________
> > > > Sipping mailing list  
> > https://www1.ietf.org/mailman/listinfo/sipping
> > > > This list is for NEW development of the application of SIP
> > > > Use sip-implementors@cs.columbia.edu for questions on current 
> > > > sip Use sip@ietf.org for new developments of core SIP
> > > > 
> > > 
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use sip-implementors@cs.columbia.edu for questions on 
> current sip Use
> > sip@ietf.org for new developments of core SIP
> > 
> > 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Wed Jan  8 05:32:48 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15979
	for <sipping-archive@odin.ietf.org>; Wed, 8 Jan 2003 05:32:48 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h08AhvS12017
	for sipping-archive@odin.ietf.org; Wed, 8 Jan 2003 05:43:57 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08AhuJ12013
	for <sipping-web-archive@optimus.ietf.org>; Wed, 8 Jan 2003 05:43:56 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15960
	for <sipping-web-archive@ietf.org>; Wed, 8 Jan 2003 05:32:13 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08AfMJ11922;
	Wed, 8 Jan 2003 05:41:22 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08Ae9J11878
	for <sipping@optimus.ietf.org>; Wed, 8 Jan 2003 05:40:09 -0500
Received: from hoemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15905
	for <sipping@ietf.org>; Wed, 8 Jan 2003 05:28:30 -0500 (EST)
Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57])
	by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h08AVhB13469
	for <sipping@ietf.org>; Wed, 8 Jan 2003 05:31:43 -0500 (EST)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19)
	id <XNTA8BTD>; Wed, 8 Jan 2003 10:31:42 -0000
Message-ID: <475FF955A05DD411980D00508B6D5FB00439EB84@en0033exch001u.uk.lucent.com>
From: "Drage, Keith (Keith)" <drage@lucent.com>
To: "'Henning Schulzrinne'" <hgs@cs.columbia.edu>,
        "Drage, Keith (Keith)"
	 <drage@lucent.com>
Cc: "Mills, Duncan, D, CND Tech Dev, VF UK"
	 <Duncan.Mills@gb.vodafone.co.uk>,
        sipping@ietf.org
Subject: RE: [Sipping] Re: Comments on revised 'sos' draft
Date: Wed, 8 Jan 2003 10:31:38 -0000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

see below (original snipped)

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: drage@lucent.com 
> 
> 
> I've added a reference to this. I suppose for an 802.11 wireless base 
> station, the basestation MAC address would be the equivalent. Any 
> interest in defining this, given that the draft already lists 
> IEEE-802.11a and IEEE-802.11b as access-types?
> 
There is work going on in 3GPP release 6 on using wireless LAN as an access mechanism to 3GPP. This has not yet addressed the issue of SIP users on the wireless LAN accssing the IM CN subsystem within 3GPP. There are still more fundamental architectural issues being addressed. I would expect some specification of the requirement here to eventually fall out of this, but it is too early to say yet which specification it will end up in (whether it be 3GPP or IEEE). 
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Wed Jan  8 06:33:35 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17011
	for <sipping-archive@odin.ietf.org>; Wed, 8 Jan 2003 06:33:34 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h08BijD15543
	for sipping-archive@odin.ietf.org; Wed, 8 Jan 2003 06:44:45 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08BijJ15540
	for <sipping-web-archive@optimus.ietf.org>; Wed, 8 Jan 2003 06:44:45 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16984
	for <sipping-web-archive@ietf.org>; Wed, 8 Jan 2003 06:32:47 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08BhWJ15505;
	Wed, 8 Jan 2003 06:43:32 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08BgYJ15464
	for <sipping@optimus.ietf.org>; Wed, 8 Jan 2003 06:42:34 -0500
Received: from auemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16943
	for <sipping@ietf.org>; Wed, 8 Jan 2003 06:30:51 -0500 (EST)
Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36])
	by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h08BY6205350
	for <sipping@ietf.org>; Wed, 8 Jan 2003 06:34:06 -0500 (EST)
Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2653.19)
	id <ZFG44MK2>; Wed, 8 Jan 2003 06:34:06 -0500
Message-ID: <E4BB443436F22D4AB9E84B06AB7C4CE0022221C3@nj7460exch004u.ho.lucent.com>
From: "Jain, Rajnish (Rajnish)" <rajnishjain@lucent.com>
To: "'Eric Burger'" <eburger@snowshore.com>, Steve Fisher <sfisher1@att.com>
Cc: sipping@ietf.org
Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs a
	nd apps?
Date: Wed, 8 Jan 2003 06:34:03 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

Eric,
Can you expand on why sending KPML w/in SUBSCRIBE is a bad idea? In other
words, why inling KPML w/in INVITE is fine but not w/in SUBSCRIBE. 

A SUBSCRIBE message w/ inline KPML should be oblivious to UA session FSM.
It's an orthogonal activity from UA's perspective. Upon receipt of a KPML
request (w/in SUBSCRIBE) the UA will attach a DSP for DTMF collecion and
report digits to app (via NOTIFY). This shouldn't change the state of SIP
session w/in UA.  

Rajnish


-----Original Message-----
From: Eric Burger [mailto:eburger@snowshore.com]
Sent: Tuesday, January 07, 2003 3:00 PM
To: Steve Fisher
Cc: sipping@ietf.org
Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs
and apps?


To answer the question directly: 

KPML only works with HTTP reporting.  It would be a different language for SIP reporting.  MSCML is an example of a language that uses SIP for reporting.



To answer the SIP stimulus reporting question:

Done INFO in the past, not planning on it again :-)

NOTIFY is my leading contender, but a new method may be needed because if you do a strict reading of NOTIFY, you might not want a NOTIFY without a SUBSCRIBE.

Using SUBSCRIBE as a method of pushing KPML is out and out evil (I mean wrong).  KPML changes the state of the UAS.  SUBSCRIBE is not supposed to have any side-effects.



> -----Original Message-----
> From: Steve Fisher [mailto:sfisher1@att.com]
> Sent: Tuesday, January 07, 2003 8:15 AM
> To: Eric Burger
> Cc: sipping@ietf.org
> Subject: RE: [Sipping] Stimulus Signaling/Markup between 
> complex SIP UAs
> and apps?
> 
> 
> Eric,
> 
> I've been thinking about your statement below...
> 
> > > If we say SIP for stimulus reporting, then the diagram you drew, 
> > > with the implication that the signaling follows the 
> signaling path, 
> > > is what will occur.
> > > 
> > > Is this distinction important for you?  The design team 
> did not come
> 
> > > to full agreement on which way to go.  Compelling 
> arguments either 
> > > way welcomed.
> 
> Could you possibly elaborate on how "SIP for stimulus reporting" would
> work? Are you thinking of SUBSCRIBE/NOTIFY? Are you thinking of using
> INFO? It's fairly clear from the KPML draft how HTTP would 
> work, but SIP
> was less clear to me...
> 
> Thanks!
> Steve
> 
> -----Original Message-----
> From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf
> Of Eric Burger
> Sent: Tuesday, December 17, 2002 5:18 PM
> To: Don Stanwyck
> Cc: sipping@ietf.org; Jain, Rajnish (Rajnish)
> Subject: RE: [Sipping] Stimulus Signaling/Markup between 
> complex SIP UAs
> and apps?
> 
> 
> Rajnish is 1000% correct in his interpretation.  Looking at 
> the message
> I can see how my statement isn't entirely clear.
> 
> I am on record in this and other fora that H.248 and J.162 are the
> appropriate protocols for device control.  See my posts to 
> the speechsc
> list.  I should have a paste buffer with my "Don't use SIP 
> for low-level
> peripheral device control" rant.
> 
> When I said "It [the thing referenced as "softswitch" in Rajnish's
> e-mail -- ewb] is not a media gateway controller" I meant it was not a
> media gateway controller, e.g., a device control thing, which uses
> device control protocols like H.248 and J.162.
> 
> Now it's my turn for interpreting Rajnish, instead of him interpreting
> me :-)  I assumed that the "PSTN X" thing was a MG-MGC combination,
> speaking SIP on the packet network side.  E.g., the MG-MGC 
> interface was
> a private matter, not of interest to the discussion.
> 
> Sorry for the confusion.
> 
> > -----Original Message-----
> > From: Jain, Rajnish (Rajnish) [mailto:rajnishjain@lucent.com]
> > Sent: Tuesday, December 17, 2002 4:02 PM
> > To: 'Don Stanwyck'; Eric Burger; Jain, Rajnish (Rajnish)
> > Cc: sipping@ietf.org; Twomey, Michael S (Michael)
> > Subject: RE: [Sipping] Stimulus Signaling/Markup between
> > complex SIP UAs
> > and apps?
> > 
> > 
> > Don,
> > I don't think Eric implied controlling a MG from a Softswitch
> > via SIP in his
> > comment. That particular topic has come up in this forum many 
> > times and as I 
> > recall the conclusion has always been that SIP is not meant 
> > for that. SIP is 
> > a peer-to-peer to protocol not a master-slave protcol - 
> > agreed. However this
> > is completely orthogonal to using stimulus/markup signaling 
> > in SIP.  I don't
> > see how in-lining a KPML doc (e.g.) in a SIP message breaks 
> > SIP paradigm. 
> > 
> > Eric,
> > In general, I would like to propose an HTTP-free alternative
> > for delivery of 
> > stimulus signals, such as through in-lining of KPML. The 
> > benefits of such an
> > alternative in my mind are following:
> > 
> > - it would make it easier for SIP developers on embedded
> > platforms to embrace 
> >   markup/stimulus signaling that don't support HTTP currently
> > 
> > - it would facilitate close coordination between announcement
> > play and DTMF
> >   collection. Barge-in is a good example for that. The app 
> > can delegate the  
> >   job to stop announcement play at barge-in to the 
> > Softswitch. As an aside,
> >   the Softswitch in my previous figure is one w/ bizarre API 
> > as you say :-)
> > 
> > Rajnish
> > 
> > -----Original Message-----
> > From: Don Stanwyck [mailto:don@stanwyck.com]
> > Sent: Tuesday, December 17, 2002 3:10 PM
> > To: 'Eric Burger'; 'Jain, Rajnish (Rajnish)'
> > Cc: sipping@ietf.org; 'Twomey, Michael S (Michael)'
> > Subject: RE: [Sipping] Stimulus Signaling/Markup between
> > complex SIP UAs
> > and apps?
> > 
> > 
> > RFC 3261, Section 2 reads:
> > 
> > //START QUOTE
> > 
> > SIP supports five facets of establishing and terminating
> > multimedia communications:
> >   - User location: determination of the end system to be
> >     used for communication;
> >   - User availability: determination of the willingness
> >     of the called party to engage in communications;
> >   - User capabilities: determination of the media and media
> >     parameters to be used;
> >   - Session setup: "ringing", establishment of session
> >     parameters at both called and calling party;
> >   - Session management: including transfer and termination
> >     of sessions, modifying session parameters, and invoking
> >     services.
> > 
> > SIP is not a vertically integrated communications system.
> > SIP is rather
> > a component that can be used with other IETF protocols to build a
> > complete multimedia architecture.  Typically, these 
> architectures will
> > include protocols such as the Real-time Transport Protocol 
> (RTP) (RFC
> > 1889 [28]) for transporting real-time data and providing 
> QoS feedback,
> > the Real-Time streaming protocol (RTSP) (RFC 2326 [29]) for 
> > controlling
> > delivery of streaming media, the Media Gateway Control 
> > Protocol (MEGACO)
> > (RFC 3015 [30]) for controlling gateways to the Public Switched
> > Telephone Network (PSTN), and the Session Description Protocol (SDP)
> > (RFC 2327 [1]) for describing multimedia sessions.  Therefore, SIP
> > should be used in conjunction with other protocols in order 
> to provide
> > complete services to the users.  However, the basic 
> functionality and
> > operation of SIP does not depend on any of these protocols.
> > 
> > //END QUOTE
> > 
> > I can't find any support in this definition of SIP for
> > carrying stimulus
> > signaling or for controling media gateways (comment 1 in Eric's
> > comments).  SIP, as defined and approved by the IETF, is not 
> > expected to
> > do these kinds of things that other IETF protocols are designed to
> > handle.
> > 
> > Let's try to keep SIP doing the things it is designed to do 
> and does 
> > well, and not try to make it into a protocol for doing everything 
> > imaginable.  It is already in danger of becoming too difficult to 
> > implement as the number of options and new headers grows.
> > 
> > Don Stanwyck
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]
> > > On Behalf Of Eric Burger
> > > Sent: Tuesday, December 17, 2002 12:12 PM
> > > To: Jain, Rajnish (Rajnish)
> > > Cc: sipping@ietf.org; Twomey, Michael S (Michael)
> > > Subject: RE: [Sipping] Stimulus Signaling/Markup between 
> > > complex SIP UAs and apps?
> > > 
> > > 
> > > For timelines, I would suggest asking the work group chairs.
> > > We're at their mercy :-)
> > > 
> > > Putting my ISC hat on, what is the Softswitch in your diagram?
> > >   1. It is not a media gateway controller, as it talks to
> > >      the gateway with SIP (right answer, by the way).
> > >   2. Is it a Stateless Proxy, a'la the Routing Function
> > >      in the ISC reference diagram?  If so, that works
> > >      exactly as you want it to.  See below for more.
> > >   3. Is it an application server, a'la dynamicsoft,
> > >      Ubiquity, LongBoard, etc.?  If so, that also works
> > >      exactly as you want it to.  See below for more.
> > >   4. Is it some kind of statefull proxy, with a bizarre,
> > >      proprietary API to the pre-paid application (e.g., 
> > >      Parlay, JAIN, EXS, ...)?  If so, you are on your
> > >      own.
> > > 
> > > If we say "HTTP only" for stimulus reporting, the PSTN
> > > gateway must be a HTTP client.  The good news is the gateway 
> > > can communicate directly with the pre-paid application.  That 
> > > also means the pre-paid application needs to have a HTTP 
> > > server.  Alternatively, if the "Softswitch" is really a 
> > > telephony application server (case #3 above), then it 
> > > probably already has HTTP server capability built-in.
> > > 
> > > If we say SIP for stimulus reporting, then the diagram you
> > > drew, with the implication that the signaling follows the 
> > > signaling path, is what will occur.
> > > 
> > > Is this distinction important for you?  The design team did
> > > not come to full agreement on which way to go.  Compelling 
> > > arguments either way welcomed.
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Jain, Rajnish (Rajnish) [mailto:rajnishjain@lucent.com]
> > > > Sent: Friday, December 06, 2002 4:20 PM
> > > > To: Eric Burger; Jain, Rajnish (Rajnish)
> > > > Cc: sipping@ietf.org; Twomey, Michael S (Michael)
> > > > Subject: RE: [Sipping] Stimulus Signaling/Markup 
> between complex 
> > > > SIP UAs and apps?
> > > > 
> > > > 
> > > > Eric,
> > > > 
> > > > Thanks for your response. Would you be able to comment on the 
> > > > timeline of when does the design team hope to accomplish the
> > > > following:
> > > > 
> > > > - general acceptance of the stimulus signaling, KPML etc.
> > > > - standardization of app interaction fwk, KPML into an RFC
> > > > 
> > > > Regarding an example of a PSTN switch that can be 
> connected to a 
> > > > pre-paid app over SIP-T, I don't know how much I can 
> disclose in 
> > > > front of this forum, but that is something being looked at by a 
> > > > few telecom gear vendors in my understanding.
> > > > 
> > > > I wanted to bring your attention to SIP-T wrt to my
> > > previous question.
> > > > I believe your answer will remain the same but I just to
> > wanted to
> > > > re-iterate the question in different words this time,
> > just to make
> > > > sure we're communicating:
> > > > 
> > > > In the setup below:
> > > >                                Pre-paid app
> > > >                                    |
> > > > POTS ---- PSTN X <---SIP-T---> Softswitch ----
> > > >                                
> > > >     
> > > > .. you would think, application interaction framework concepts 
> > > > such as stimulus signaling, user-inetrfaces and KPML etc. are 
> > > > designed to work over the SIP-T i/f between packet-enabled PSTN 
> > > > switch and a Softswitch. Wouldn't you?
> > > > 
> > > > Thanks,
> > > > Rajnish
> > > > 
> > > > > -----Original Message----- From: Jain, Rajnish (Rajnish)
> > > [mailto:rajnishjain@lucent.com]
> > > > 
> > > > The Application Interaction Framework draft talks about stimulus
> > > > signaling as a way for SIP UAs to interact w/ SIP 
> > applications. The
> > > > draft suggests use of markup languages to allow
> > > applications to manage
> > > > local/remote user interfaces on SIP UAs.
> > > > 
> > > > While the draft exemplifies a UA's stimulus/markup 
> interaction w/ 
> > > > a pre-paid application server, it is not very clear to 
> us if the 
> > > > caller UA (instead of a subscriber end-point) can be a 
> complex UA 
> > > > such as the following:
> > > > 
> > > > - SIP (enabled) Gateway
> > > 
> > > Why not?  It does SIP.  It may do tone detection.
> > > 
> > > > - PSTN Switch w/ SIP-T interface
> > > 
> > > Why not?  It does SIP.  It may do tone detection.
> > > 
> > > > and does the draft recommend stimulus/markup signaling between 
> > > > such complex/concentrated UAs (or apps) and SIP applications ?
> > > 
> > > The draft is silent on it.  If you manufacture media rich
> > > gateways, you might say "of course".  If you manufacture 
> > > media servers, you might say "you could if you wanted, but 
> > > you would be better served if you didn't."  :-)
> > > 
> > > > In other words, does the stimulus signaling apply to following
> > > > scenarios ?:
> > > > 
> > > > 1. The pre-paid caller is connected to a PSTN switch that has a 
> > > > SIP-T interface to the pre-paid application.
> > > 
> > > Yes, so long as the PSTN switch is SIP-aware, able to parse
> > > and execute KPML, and report using SIP (or, yuck, http).
> > > 
> > > Do you know of such a switch?
> > >  
> > > > 2. The pre-paid caller is connected to a PBX (SIP 
> Gateway) over an
> 
> > > > ISDN i/f, which in turn is connected to the pre-paid app. over 
> > > > normal SIP.
> > > 
> > > Same issues as for the PSTN switch.
> > > 
> > > > If yes, would the terms client-local and client-remote still be
> > > > accurate, as the user here is a POTS/ISDN user? From the user's 
> > > > perspective, the UI would be client-remote. But from 
> > application's
> > > > perspective the UI would be client-local (as the UI will be
> > > on the PBX
> > > > or PSTN switch both of which look like a UA to app server).
> > > 
> > > It is still client-local, as the gateway/switch/PBX is a
> > > local proxy for the user.  If you used a media server in the 
> > > IP network behind the gateway/switch/PBX to execute the KPML, 
> > > then you would be cline-remote. 
> > > _______________________________________________
> > > Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> > > This list is for NEW development of the application of SIP
> > > Use sip-implementors@cs.columbia.edu for questions on current 
> > > sip Use sip@ietf.org for new developments of core SIP
> > > 
> > 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip Use
> sip@ietf.org for new developments of core SIP
> 
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Wed Jan  8 08:53:00 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19797
	for <sipping-archive@odin.ietf.org>; Wed, 8 Jan 2003 08:53:00 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h08E4Ee22881
	for sipping-archive@odin.ietf.org; Wed, 8 Jan 2003 09:04:14 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08E4DJ22878
	for <sipping-web-archive@optimus.ietf.org>; Wed, 8 Jan 2003 09:04:13 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19789
	for <sipping-web-archive@ietf.org>; Wed, 8 Jan 2003 08:52:09 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08E2pJ22832;
	Wed, 8 Jan 2003 09:02:51 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08E1OJ22732
	for <sipping@optimus.ietf.org>; Wed, 8 Jan 2003 09:01:24 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19584;
	Wed, 8 Jan 2003 08:49:38 -0500 (EST)
Message-Id: <200301081349.IAA19584@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: sipping@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 08 Jan 2003 08:49:38 -0500
Subject: [Sipping] I-D ACTION:draft-mukundan-sipping-dpnss-00.txt
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: MIME media types for DPNSS Objects
	Author(s)	: R. Mukundan et al.
	Filename	: draft-mukundan-sipping-dpnss-00.txt
	Pages		: 9
	Date		: 2003-1-7
	
This document describes MIME type for application/DPNSS objects for
use in SIP [3] applications, according to the rules defined in
RFC 2048 [4]. These types can be used to identify Digital Private
Network Signaling System 1 (DPNSS 1) [2] objects within a SIP message
such as INVITE or INFO, as might be implemented when using SIP in an
environment where part of the call involves interworking to
DPNSS based Private Networks. RFC 3204 [9] addresses a similar need
for ISUP and QSIG.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-mukundan-sipping-dpnss-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-mukundan-sipping-dpnss-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-1-7160918.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-mukundan-sipping-dpnss-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-mukundan-sipping-dpnss-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-1-7160918.I-D@ietf.org>

--OtherAccess--

--NextPart--


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Wed Jan  8 09:06:27 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20157
	for <sipping-archive@odin.ietf.org>; Wed, 8 Jan 2003 09:06:27 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h08EHfu24140
	for sipping-archive@odin.ietf.org; Wed, 8 Jan 2003 09:17:41 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08EHfJ24137
	for <sipping-web-archive@optimus.ietf.org>; Wed, 8 Jan 2003 09:17:41 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20046
	for <sipping-web-archive@ietf.org>; Wed, 8 Jan 2003 09:01:23 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08EC7J23903;
	Wed, 8 Jan 2003 09:12:07 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08EBuJ23876
	for <sipping@optimus.ietf.org>; Wed, 8 Jan 2003 09:11:56 -0500
Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19979
	for <sipping@ietf.org>; Wed, 8 Jan 2003 09:00:09 -0500 (EST)
From: hisham.khartabil@nokia.com
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h08E5Ot00852
	for <sipping@ietf.org>; Wed, 8 Jan 2003 16:05:24 +0200 (EET)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5faaf0dd3aac158f230f3@esvir03nok.nokia.com>;
 Wed, 8 Jan 2003 16:03:25 +0200
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 8 Jan 2003 16:03:25 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps?
Date: Wed, 8 Jan 2003 16:03:23 +0200
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE70D2@esebe019.ntc.nokia.com>
Thread-Topic: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps?
Thread-Index: AcK3Cv1oSugmyIh5SG2i6x1kj1m4SgAEvC1g
To: <rajnishjain@lucent.com>, <eburger@snowshore.com>, <sfisher1@att.com>
Cc: <sipping@ietf.org>
X-OriginalArrivalTime: 08 Jan 2003 14:03:25.0037 (UTC) FILETIME=[B60359D0:01C2B71E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h08EBuJ23877
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

The body of a SUBSCRIBE should be used for things like filtering. Something related to the subscription itself. Putting KMPL in the body of SUBSCRIBE is considered as a form of tunnelling, IMO. We try to keep a use of a certain SIP method, header, or whatever to a minimum, preferably one.

Bodies of INVITEs typically carry information about the session. KPML, I would consider, a type of session description.

Regards,
Hisham

> -----Original Message-----
> From: ext Jain, Rajnish (Rajnish) [mailto:rajnishjain@lucent.com]
> Sent: Wednesday, January 08, 2003 1:34 PM
> To: 'Eric Burger'; Steve Fisher
> Cc: sipping@ietf.org
> Subject: RE: [Sipping] Stimulus Signaling/Markup between 
> complex SIP UAs
> and apps?
> 
> 
> Eric,
> Can you expand on why sending KPML w/in SUBSCRIBE is a bad 
> idea? In other
> words, why inling KPML w/in INVITE is fine but not w/in SUBSCRIBE. 
> 
> A SUBSCRIBE message w/ inline KPML should be oblivious to UA 
> session FSM.
> It's an orthogonal activity from UA's perspective. Upon 
> receipt of a KPML
> request (w/in SUBSCRIBE) the UA will attach a DSP for DTMF 
> collecion and
> report digits to app (via NOTIFY). This shouldn't change the 
> state of SIP
> session w/in UA.  
> 
> Rajnish
> 
> 
> -----Original Message-----
> From: Eric Burger [mailto:eburger@snowshore.com]
> Sent: Tuesday, January 07, 2003 3:00 PM
> To: Steve Fisher
> Cc: sipping@ietf.org
> Subject: RE: [Sipping] Stimulus Signaling/Markup between 
> complex SIP UAs
> and apps?
> 
> 
> To answer the question directly: 
> 
> KPML only works with HTTP reporting.  It would be a different 
> language for SIP reporting.  MSCML is an example of a 
> language that uses SIP for reporting.
> 
> 
> 
> To answer the SIP stimulus reporting question:
> 
> Done INFO in the past, not planning on it again :-)
> 
> NOTIFY is my leading contender, but a new method may be 
> needed because if you do a strict reading of NOTIFY, you 
> might not want a NOTIFY without a SUBSCRIBE.
> 
> Using SUBSCRIBE as a method of pushing KPML is out and out 
> evil (I mean wrong).  KPML changes the state of the UAS.  
> SUBSCRIBE is not supposed to have any side-effects.
> 
> 
> 
> > -----Original Message-----
> > From: Steve Fisher [mailto:sfisher1@att.com]
> > Sent: Tuesday, January 07, 2003 8:15 AM
> > To: Eric Burger
> > Cc: sipping@ietf.org
> > Subject: RE: [Sipping] Stimulus Signaling/Markup between 
> > complex SIP UAs
> > and apps?
> > 
> > 
> > Eric,
> > 
> > I've been thinking about your statement below...
> > 
> > > > If we say SIP for stimulus reporting, then the diagram 
> you drew, 
> > > > with the implication that the signaling follows the 
> > signaling path, 
> > > > is what will occur.
> > > > 
> > > > Is this distinction important for you?  The design team 
> > did not come
> > 
> > > > to full agreement on which way to go.  Compelling 
> > arguments either 
> > > > way welcomed.
> > 
> > Could you possibly elaborate on how "SIP for stimulus 
> reporting" would
> > work? Are you thinking of SUBSCRIBE/NOTIFY? Are you 
> thinking of using
> > INFO? It's fairly clear from the KPML draft how HTTP would 
> > work, but SIP
> > was less clear to me...
> > 
> > Thanks!
> > Steve
> > 
> > -----Original Message-----
> > From: sipping-admin@ietf.org 
> [mailto:sipping-admin@ietf.org] On Behalf
> > Of Eric Burger
> > Sent: Tuesday, December 17, 2002 5:18 PM
> > To: Don Stanwyck
> > Cc: sipping@ietf.org; Jain, Rajnish (Rajnish)
> > Subject: RE: [Sipping] Stimulus Signaling/Markup between 
> > complex SIP UAs
> > and apps?
> > 
> > 
> > Rajnish is 1000% correct in his interpretation.  Looking at 
> > the message
> > I can see how my statement isn't entirely clear.
> > 
> > I am on record in this and other fora that H.248 and J.162 are the
> > appropriate protocols for device control.  See my posts to 
> > the speechsc
> > list.  I should have a paste buffer with my "Don't use SIP 
> > for low-level
> > peripheral device control" rant.
> > 
> > When I said "It [the thing referenced as "softswitch" in Rajnish's
> > e-mail -- ewb] is not a media gateway controller" I meant 
> it was not a
> > media gateway controller, e.g., a device control thing, which uses
> > device control protocols like H.248 and J.162.
> > 
> > Now it's my turn for interpreting Rajnish, instead of him 
> interpreting
> > me :-)  I assumed that the "PSTN X" thing was a MG-MGC combination,
> > speaking SIP on the packet network side.  E.g., the MG-MGC 
> > interface was
> > a private matter, not of interest to the discussion.
> > 
> > Sorry for the confusion.
> > 
> > > -----Original Message-----
> > > From: Jain, Rajnish (Rajnish) [mailto:rajnishjain@lucent.com]
> > > Sent: Tuesday, December 17, 2002 4:02 PM
> > > To: 'Don Stanwyck'; Eric Burger; Jain, Rajnish (Rajnish)
> > > Cc: sipping@ietf.org; Twomey, Michael S (Michael)
> > > Subject: RE: [Sipping] Stimulus Signaling/Markup between
> > > complex SIP UAs
> > > and apps?
> > > 
> > > 
> > > Don,
> > > I don't think Eric implied controlling a MG from a Softswitch
> > > via SIP in his
> > > comment. That particular topic has come up in this forum many 
> > > times and as I 
> > > recall the conclusion has always been that SIP is not meant 
> > > for that. SIP is 
> > > a peer-to-peer to protocol not a master-slave protcol - 
> > > agreed. However this
> > > is completely orthogonal to using stimulus/markup signaling 
> > > in SIP.  I don't
> > > see how in-lining a KPML doc (e.g.) in a SIP message breaks 
> > > SIP paradigm. 
> > > 
> > > Eric,
> > > In general, I would like to propose an HTTP-free alternative
> > > for delivery of 
> > > stimulus signals, such as through in-lining of KPML. The 
> > > benefits of such an
> > > alternative in my mind are following:
> > > 
> > > - it would make it easier for SIP developers on embedded
> > > platforms to embrace 
> > >   markup/stimulus signaling that don't support HTTP currently
> > > 
> > > - it would facilitate close coordination between announcement
> > > play and DTMF
> > >   collection. Barge-in is a good example for that. The app 
> > > can delegate the  
> > >   job to stop announcement play at barge-in to the 
> > > Softswitch. As an aside,
> > >   the Softswitch in my previous figure is one w/ bizarre API 
> > > as you say :-)
> > > 
> > > Rajnish
> > > 
> > > -----Original Message-----
> > > From: Don Stanwyck [mailto:don@stanwyck.com]
> > > Sent: Tuesday, December 17, 2002 3:10 PM
> > > To: 'Eric Burger'; 'Jain, Rajnish (Rajnish)'
> > > Cc: sipping@ietf.org; 'Twomey, Michael S (Michael)'
> > > Subject: RE: [Sipping] Stimulus Signaling/Markup between
> > > complex SIP UAs
> > > and apps?
> > > 
> > > 
> > > RFC 3261, Section 2 reads:
> > > 
> > > //START QUOTE
> > > 
> > > SIP supports five facets of establishing and terminating
> > > multimedia communications:
> > >   - User location: determination of the end system to be
> > >     used for communication;
> > >   - User availability: determination of the willingness
> > >     of the called party to engage in communications;
> > >   - User capabilities: determination of the media and media
> > >     parameters to be used;
> > >   - Session setup: "ringing", establishment of session
> > >     parameters at both called and calling party;
> > >   - Session management: including transfer and termination
> > >     of sessions, modifying session parameters, and invoking
> > >     services.
> > > 
> > > SIP is not a vertically integrated communications system.
> > > SIP is rather
> > > a component that can be used with other IETF protocols to build a
> > > complete multimedia architecture.  Typically, these 
> > architectures will
> > > include protocols such as the Real-time Transport Protocol 
> > (RTP) (RFC
> > > 1889 [28]) for transporting real-time data and providing 
> > QoS feedback,
> > > the Real-Time streaming protocol (RTSP) (RFC 2326 [29]) for 
> > > controlling
> > > delivery of streaming media, the Media Gateway Control 
> > > Protocol (MEGACO)
> > > (RFC 3015 [30]) for controlling gateways to the Public Switched
> > > Telephone Network (PSTN), and the Session Description 
> Protocol (SDP)
> > > (RFC 2327 [1]) for describing multimedia sessions.  Therefore, SIP
> > > should be used in conjunction with other protocols in order 
> > to provide
> > > complete services to the users.  However, the basic 
> > functionality and
> > > operation of SIP does not depend on any of these protocols.
> > > 
> > > //END QUOTE
> > > 
> > > I can't find any support in this definition of SIP for
> > > carrying stimulus
> > > signaling or for controling media gateways (comment 1 in Eric's
> > > comments).  SIP, as defined and approved by the IETF, is not 
> > > expected to
> > > do these kinds of things that other IETF protocols are designed to
> > > handle.
> > > 
> > > Let's try to keep SIP doing the things it is designed to do 
> > and does 
> > > well, and not try to make it into a protocol for doing everything 
> > > imaginable.  It is already in danger of becoming too difficult to 
> > > implement as the number of options and new headers grows.
> > > 
> > > Don Stanwyck
> > > 
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]
> > > > On Behalf Of Eric Burger
> > > > Sent: Tuesday, December 17, 2002 12:12 PM
> > > > To: Jain, Rajnish (Rajnish)
> > > > Cc: sipping@ietf.org; Twomey, Michael S (Michael)
> > > > Subject: RE: [Sipping] Stimulus Signaling/Markup between 
> > > > complex SIP UAs and apps?
> > > > 
> > > > 
> > > > For timelines, I would suggest asking the work group chairs.
> > > > We're at their mercy :-)
> > > > 
> > > > Putting my ISC hat on, what is the Softswitch in your diagram?
> > > >   1. It is not a media gateway controller, as it talks to
> > > >      the gateway with SIP (right answer, by the way).
> > > >   2. Is it a Stateless Proxy, a'la the Routing Function
> > > >      in the ISC reference diagram?  If so, that works
> > > >      exactly as you want it to.  See below for more.
> > > >   3. Is it an application server, a'la dynamicsoft,
> > > >      Ubiquity, LongBoard, etc.?  If so, that also works
> > > >      exactly as you want it to.  See below for more.
> > > >   4. Is it some kind of statefull proxy, with a bizarre,
> > > >      proprietary API to the pre-paid application (e.g., 
> > > >      Parlay, JAIN, EXS, ...)?  If so, you are on your
> > > >      own.
> > > > 
> > > > If we say "HTTP only" for stimulus reporting, the PSTN
> > > > gateway must be a HTTP client.  The good news is the gateway 
> > > > can communicate directly with the pre-paid application.  That 
> > > > also means the pre-paid application needs to have a HTTP 
> > > > server.  Alternatively, if the "Softswitch" is really a 
> > > > telephony application server (case #3 above), then it 
> > > > probably already has HTTP server capability built-in.
> > > > 
> > > > If we say SIP for stimulus reporting, then the diagram you
> > > > drew, with the implication that the signaling follows the 
> > > > signaling path, is what will occur.
> > > > 
> > > > Is this distinction important for you?  The design team did
> > > > not come to full agreement on which way to go.  Compelling 
> > > > arguments either way welcomed.
> > > > 
> > > > 
> > > > > -----Original Message-----
> > > > > From: Jain, Rajnish (Rajnish) [mailto:rajnishjain@lucent.com]
> > > > > Sent: Friday, December 06, 2002 4:20 PM
> > > > > To: Eric Burger; Jain, Rajnish (Rajnish)
> > > > > Cc: sipping@ietf.org; Twomey, Michael S (Michael)
> > > > > Subject: RE: [Sipping] Stimulus Signaling/Markup 
> > between complex 
> > > > > SIP UAs and apps?
> > > > > 
> > > > > 
> > > > > Eric,
> > > > > 
> > > > > Thanks for your response. Would you be able to comment on the 
> > > > > timeline of when does the design team hope to accomplish the
> > > > > following:
> > > > > 
> > > > > - general acceptance of the stimulus signaling, KPML etc.
> > > > > - standardization of app interaction fwk, KPML into an RFC
> > > > > 
> > > > > Regarding an example of a PSTN switch that can be 
> > connected to a 
> > > > > pre-paid app over SIP-T, I don't know how much I can 
> > disclose in 
> > > > > front of this forum, but that is something being 
> looked at by a 
> > > > > few telecom gear vendors in my understanding.
> > > > > 
> > > > > I wanted to bring your attention to SIP-T wrt to my
> > > > previous question.
> > > > > I believe your answer will remain the same but I just to
> > > wanted to
> > > > > re-iterate the question in different words this time,
> > > just to make
> > > > > sure we're communicating:
> > > > > 
> > > > > In the setup below:
> > > > >                                Pre-paid app
> > > > >                                    |
> > > > > POTS ---- PSTN X <---SIP-T---> Softswitch ----
> > > > >                                
> > > > >     
> > > > > .. you would think, application interaction framework 
> concepts 
> > > > > such as stimulus signaling, user-inetrfaces and KPML etc. are 
> > > > > designed to work over the SIP-T i/f between 
> packet-enabled PSTN 
> > > > > switch and a Softswitch. Wouldn't you?
> > > > > 
> > > > > Thanks,
> > > > > Rajnish
> > > > > 
> > > > > > -----Original Message----- From: Jain, Rajnish (Rajnish)
> > > > [mailto:rajnishjain@lucent.com]
> > > > > 
> > > > > The Application Interaction Framework draft talks 
> about stimulus
> > > > > signaling as a way for SIP UAs to interact w/ SIP 
> > > applications. The
> > > > > draft suggests use of markup languages to allow
> > > > applications to manage
> > > > > local/remote user interfaces on SIP UAs.
> > > > > 
> > > > > While the draft exemplifies a UA's stimulus/markup 
> > interaction w/ 
> > > > > a pre-paid application server, it is not very clear to 
> > us if the 
> > > > > caller UA (instead of a subscriber end-point) can be a 
> > complex UA 
> > > > > such as the following:
> > > > > 
> > > > > - SIP (enabled) Gateway
> > > > 
> > > > Why not?  It does SIP.  It may do tone detection.
> > > > 
> > > > > - PSTN Switch w/ SIP-T interface
> > > > 
> > > > Why not?  It does SIP.  It may do tone detection.
> > > > 
> > > > > and does the draft recommend stimulus/markup 
> signaling between 
> > > > > such complex/concentrated UAs (or apps) and SIP applications ?
> > > > 
> > > > The draft is silent on it.  If you manufacture media rich
> > > > gateways, you might say "of course".  If you manufacture 
> > > > media servers, you might say "you could if you wanted, but 
> > > > you would be better served if you didn't."  :-)
> > > > 
> > > > > In other words, does the stimulus signaling apply to following
> > > > > scenarios ?:
> > > > > 
> > > > > 1. The pre-paid caller is connected to a PSTN switch 
> that has a 
> > > > > SIP-T interface to the pre-paid application.
> > > > 
> > > > Yes, so long as the PSTN switch is SIP-aware, able to parse
> > > > and execute KPML, and report using SIP (or, yuck, http).
> > > > 
> > > > Do you know of such a switch?
> > > >  
> > > > > 2. The pre-paid caller is connected to a PBX (SIP 
> > Gateway) over an
> > 
> > > > > ISDN i/f, which in turn is connected to the pre-paid 
> app. over 
> > > > > normal SIP.
> > > > 
> > > > Same issues as for the PSTN switch.
> > > > 
> > > > > If yes, would the terms client-local and 
> client-remote still be
> > > > > accurate, as the user here is a POTS/ISDN user? From 
> the user's 
> > > > > perspective, the UI would be client-remote. But from 
> > > application's
> > > > > perspective the UI would be client-local (as the UI will be
> > > > on the PBX
> > > > > or PSTN switch both of which look like a UA to app server).
> > > > 
> > > > It is still client-local, as the gateway/switch/PBX is a
> > > > local proxy for the user.  If you used a media server in the 
> > > > IP network behind the gateway/switch/PBX to execute the KPML, 
> > > > then you would be cline-remote. 
> > > > _______________________________________________
> > > > Sipping mailing list  
> > https://www1.ietf.org/mailman/listinfo/sipping
> > > > This list is for NEW development of the application of SIP
> > > > Use sip-implementors@cs.columbia.edu for questions on current 
> > > > sip Use sip@ietf.org for new developments of core SIP
> > > > 
> > > 
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use sip-implementors@cs.columbia.edu for questions on 
> current sip Use
> > sip@ietf.org for new developments of core SIP
> > 
> > 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Wed Jan  8 09:39:34 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21179
	for <sipping-archive@odin.ietf.org>; Wed, 8 Jan 2003 09:39:34 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h08Eonx26510
	for sipping-archive@odin.ietf.org; Wed, 8 Jan 2003 09:50:49 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08EonJ26507
	for <sipping-web-archive@optimus.ietf.org>; Wed, 8 Jan 2003 09:50:49 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21165
	for <sipping-web-archive@ietf.org>; Wed, 8 Jan 2003 09:38:29 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08EnWJ26429;
	Wed, 8 Jan 2003 09:49:32 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08EmxJ26383
	for <sipping@optimus.ietf.org>; Wed, 8 Jan 2003 09:48:59 -0500
Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21154
	for <sipping@ietf.org>; Wed, 8 Jan 2003 09:37:13 -0500 (EST)
Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66])
	(user=hgs10 mech=PLAIN bits=0)
	by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h08EeR91005302
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Wed, 8 Jan 2003 09:40:27 -0500 (EST)
Message-ID: <3E1C3873.8000503@cs.columbia.edu>
Date: Wed, 08 Jan 2003 09:40:51 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mpierce1@aol.com
CC: Brian.Rosen@marconi.com, sipping@ietf.org
Subject: Re: [Sipping] Comments on sos draft -03 (URI)
References: <55.3592b34d.2b4cf1c3@aol.com>
In-Reply-To: <55.3592b34d.2b4cf1c3@aol.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

> [MAP] No, but if a LAN, 802.11 hotspot, etc claims to be providing "telephone 
> service" then it should come under the regulatory requirements and provide 
> proper service, which I believe requires what I was describing. Of course, if 
> someone is not claiming to provide "telephone service", then it doesn't 
> matter what happens or if their "home domain" fails to properly handle an 
> emergency call.

I have control over my home domain, so it makes sense to put more 
responsibility on it. LANs shouldn't have to provide 'telephone 
service'; things should work if they provide IP transport. That's the 
Internet approach.

> [MAP] I agree fully that no one should assign an extension of 911 if they can 
> avoid it and private systems should allow 911 to be interpreted as a call to 
> emergency, even without prefixing it with a "9", but the point is that we 
> can't design SIP phones, or protocols, or proxy functioning based on an 
> assumption that no one is doing this. (Incidentally, this mean that some 
> hotels would have to get rid of room number 911, just as some airplanes don't 
> have a row 13.)

I agree that this isn't ideal. However, in practice, we probably will 
have two cases that may make this point moot:

- The hotel or business has its own VoIP phone system. In that case, 
with the DHCP option outlined in the 04 draft, the device can discover 
both the outbound proxy and the local emergency numbers.

- If a business has extensions, but no local SIP service (say, just a 
local wireless LAN), the issue doesn't arise, since you'd have to dial 
the E.164 number anyway. In that case, the default lists of numbers 
kicks in.

I think this covers the practically useful cases; I will change the 04 
draft to only suggest using the default list if there's no local 
knowledge. (Since, in that case, the extension problem won't appear to 
begin with.) The DHCP advertisement should advertise the local emergency 
number, but also all of the 'customary' emergency numbers that are not 
used for non-emergency uses. In other words, if a hotel in Europe 
doesn't have room 911, it should allow this as an emergency number, to 
accomodate the US or Canadian traveler.

This is not perfect for the traveler (since some of his familiar numbers 
may no longer work), but my hope is that most SIP devices will come 
equipped with an 'SOS' button which avoids the whole mess.

Henning

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Wed Jan  8 09:58:53 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21639
	for <sipping-archive@odin.ietf.org>; Wed, 8 Jan 2003 09:58:53 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h08FA8O27994
	for sipping-archive@odin.ietf.org; Wed, 8 Jan 2003 10:10:08 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08FA8J27991
	for <sipping-web-archive@optimus.ietf.org>; Wed, 8 Jan 2003 10:10:08 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21618
	for <sipping-web-archive@ietf.org>; Wed, 8 Jan 2003 09:57:46 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08F3KJ27106;
	Wed, 8 Jan 2003 10:03:20 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08F2VJ27063
	for <sipping@optimus.ietf.org>; Wed, 8 Jan 2003 10:02:32 -0500
Received: from zcars04e.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21447
	for <sipping@ietf.org>; Wed, 8 Jan 2003 09:50:45 -0500 (EST)
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h08ErVu13367;
	Wed, 8 Jan 2003 09:53:31 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <ZC6RWBD0>; Wed, 8 Jan 2003 09:53:32 -0500
Message-ID: <4D79C746863DD51197690002A52CDA000400E10B@zcard0kc.ca.nortel.com>
From: "Tom-PT Taylor" <taylor@nortelnetworks.com>
To: "'Drage, Keith (Keith)'" <drage@lucent.com>,
        "'Henning Schulzrinne'"
	 <hgs@cs.columbia.edu>,
        "'sipping@ietf.org'" <sipping@ietf.org>
Subject: RE: [Sipping] Comments on sos draft -0
Date: Wed, 8 Jan 2003 09:53:32 -0500 
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

A comment on one point only.

> -----Original Message-----
> From: Drage, Keith (Keith) [mailto:drage@lucent.com] 
> Sent: Monday, January 06, 2003 10:56 AM
> To: 'Henning Schulzrinne'; 'sipping@ietf.org'
> Subject: [Sipping] Comments on sos draft -0
> 
[snip]
> 
> 6)	section 3 (Emergency URI), 3rd paragraph: use of 
> "phone-context". Is it appropriate to use phone context in 
> any emergency call. In 3GPP, any use of one of the numbers 
> from the list stored in the phone is an emergency call, no 
> matter where it originates from. If my understanding of 
> phone-context is correct, it SHOULD NOT be used, as it could 
> result in failure to deliver an emergency call.
> 
[PTT] My company has a scheme where "3333" on the internal network reaches
an internal emergency response centre who then direct the call externally if
required.  This was introduced to ensure that emergency vehicles are
directed to the right building and building entrance.  It might be
conceivable under such an arrangement to have a phone-context in the
original Request-URI.

[snip]
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Wed Jan  8 10:00:39 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21677
	for <sipping-archive@odin.ietf.org>; Wed, 8 Jan 2003 10:00:39 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h08FBrx28066
	for sipping-archive@odin.ietf.org; Wed, 8 Jan 2003 10:11:53 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08FBqJ28063
	for <sipping-web-archive@optimus.ietf.org>; Wed, 8 Jan 2003 10:11:52 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21644
	for <sipping-web-archive@ietf.org>; Wed, 8 Jan 2003 09:59:10 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08FAFJ28014;
	Wed, 8 Jan 2003 10:10:15 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08F9sJ27962
	for <sipping@optimus.ietf.org>; Wed, 8 Jan 2003 10:09:54 -0500
Received: from zsc3s004.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21632
	for <sipping@ietf.org>; Wed, 8 Jan 2003 09:58:06 -0500 (EST)
Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h08F1L606467;
	Wed, 8 Jan 2003 07:01:21 -0800 (PST)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h08F1Xd18062;
	Wed, 8 Jan 2003 09:01:33 -0600 (CST)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <C2QDXAZX>; Wed, 8 Jan 2003 09:01:20 -0600
Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7CBC9@zrc2c000.us.nortel.com>
From: "Mary Barnes" <mbarnes@nortelnetworks.com>
To: "'Paul Kyzivat'" <pkyzivat@cisco.com>, sipping@ietf.org
Subject: RE: [Sipping] I-D ACTION:draft-barnes-sipping-history-info-01.txt
Date: Wed, 8 Jan 2003 09:01:18 -0600 
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

Paul,

Thanks so much for your constructive comments.  My specific responses are
embedded below [MB] and I welcome further discussion on these points. 

In general, as you mention, the normative text around the index is quite
lacking and I will definitely work to improve that including your concerns
in the next version. 

Regards,
Mary. 

-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
Sent: Tuesday, January 07, 2003 5:01 PM
To: sipping@ietf.org
Subject: Re: [Sipping] I-D
ACTION:draft-barnes-sipping-history-info-01.txt


A comment about the recording of indices...

The syntax
              hi-index = "index" EQUAL 1*(DIGIT DOT )

permits indices of "...", "1..3", ".2" etc. These seem to be incorrect. 
[MB] Yes, you are correct.  This is wrong and your proposed syntax is what
was intended.

A better syntax would be

              hi-index = "index" EQUAL 1*DIGIT *(DOT 1*DIGIT)

The only specification I could find for how this is maintained is in 
Section 2.2.3, which says:

     In order to maintain ordering and accurately reflect forking and
     nesting, the index should also be included, with the last digit
     being incremented as the request is retargeted.
     ...
     If the index is captured at
     each occurrence of retargeting, a proxy can more accurately capture
     the logical order and nesting involved.

This doesn't seem like enough to specify the maintenance of the index. 
Although doing this is straightforward, there ought to be some normative 
language about it. For instance the following are some issues about 
responsibility:

- if a proxy receives a request with a History-Info that has an index 
paramter, and adds another entry as it forwards the request on, MUST it 
place an index param on the new entry? If so, MUST it follow the 
intuitive rule for deriving the new index? (I think the answer should be 
YES to both of these.)

[MB] I think I also agree that these both should be yes.  Although, I think
that we may have to specify it as SHOULD (or RECOMMENDED) due to the
optionality aspects of HI (subject to local policy, etc.)  

- if a proxy receives a request with a History-Info that has no index 
parameter, and it adds another entry as it forwards the request on, MAY 
it place an index param on the new entry? (I think it MUST NOT, because 
it has no way to determine a correct value.)

[MB] Another good question.  I agree it would be much simpler to suggest
that the proxy SHOULD NOT add an index if there was HI entries without an
index.  The MUST NOT I think definitely needs to be documented is that the
proxy MUST NOT add an index to a previous index (i.e. MUST NOT attempt to
correct the previous lack of an index). It should be up to an end
application that receives HI entries that might require an index to use
whatever algorithm might be appropriate to add the indices.  


- if a proxy receives a request with no History-Info, and creates one 
with an initial entry, MAY it place an index param on the new entry? (I 
think it MUST NOT, because again it has no way to determine a correct 
value.)

If you buy my answers to the above, then it is the UAC that determines 
whether indices are used.
[MB] I agree, this is the way that it SHOULD work and with the approach that
the UAC does add the initial entry prior to sending the request, this would
work quite well.  The only problem arises in the case of a proxy that
perhaps only needs the information within its domain, but local policy
requires the indices, then it's perhaps not unreasonable to just start with
the entries that it adds itself. So, my answer to this 3rd point is that it
would be a MAY, but I'm open to further discussion on this. 

In any case, for the indices to be useful for anything there ought to be 
more normative text that specifies how they are managed.

	Paul

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Wed Jan  8 11:32:43 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24069
	for <sipping-archive@odin.ietf.org>; Wed, 8 Jan 2003 11:32:43 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h08Ghxv02110
	for sipping-archive@odin.ietf.org; Wed, 8 Jan 2003 11:43:59 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08GhxJ02107
	for <sipping-web-archive@optimus.ietf.org>; Wed, 8 Jan 2003 11:43:59 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23972
	for <sipping-web-archive@ietf.org>; Wed, 8 Jan 2003 11:31:44 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08GgFJ01953;
	Wed, 8 Jan 2003 11:42:15 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08GeSJ01762
	for <sipping@optimus.ietf.org>; Wed, 8 Jan 2003 11:40:28 -0500
Received: from zoe.office.snowshore.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23841
	for <sipping@ietf.org>; Wed, 8 Jan 2003 11:28:39 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps?
Date: Wed, 8 Jan 2003 11:31:55 -0500
Message-ID: <4A3384433CE2AB46A63468CB207E209D2DF65E@zoe.office.snowshore.com>
Thread-Topic: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps?
Thread-Index: AcK3Cv1oSugmyIh5SG2i6x1kj1m4SgAEvC1gAAVd8UA=
From: "Eric Burger" <eburger@snowshore.com>
To: <hisham.khartabil@nokia.com>, <rajnishjain@lucent.com>, <sfisher1@att.com>
Cc: <sipping@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h08GeSJ01763
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

Precisely.  The "state" I was referring to is not the state of the SIP session, but the state of the UAS.

> -----Original Message-----
> From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]
> Sent: Wednesday, January 08, 2003 9:03 AM
> To: rajnishjain@lucent.com; Eric Burger; sfisher1@att.com
> Cc: sipping@ietf.org
> Subject: RE: [Sipping] Stimulus Signaling/Markup between 
> complex SIP UAs
> and apps?
> 
> 
> The body of a SUBSCRIBE should be used for things like 
> filtering. Something related to the subscription itself. 
> Putting KMPL in the body of SUBSCRIBE is considered as a form 
> of tunnelling, IMO. We try to keep a use of a certain SIP 
> method, header, or whatever to a minimum, preferably one.
> 
> Bodies of INVITEs typically carry information about the 
> session. KPML, I would consider, a type of session description.
> 
> Regards,
> Hisham
> 
> > -----Original Message-----
> > From: ext Jain, Rajnish (Rajnish) [mailto:rajnishjain@lucent.com]
> > Sent: Wednesday, January 08, 2003 1:34 PM
> > To: 'Eric Burger'; Steve Fisher
> > Cc: sipping@ietf.org
> > Subject: RE: [Sipping] Stimulus Signaling/Markup between 
> > complex SIP UAs
> > and apps?
> > 
> > 
> > Eric,
> > Can you expand on why sending KPML w/in SUBSCRIBE is a bad 
> > idea? In other
> > words, why inling KPML w/in INVITE is fine but not w/in SUBSCRIBE. 
> > 
> > A SUBSCRIBE message w/ inline KPML should be oblivious to UA 
> > session FSM.
> > It's an orthogonal activity from UA's perspective. Upon 
> > receipt of a KPML
> > request (w/in SUBSCRIBE) the UA will attach a DSP for DTMF 
> > collecion and
> > report digits to app (via NOTIFY). This shouldn't change the 
> > state of SIP
> > session w/in UA.  
> > 
> > Rajnish
> > 
> > 
> > -----Original Message-----
> > From: Eric Burger [mailto:eburger@snowshore.com]
> > Sent: Tuesday, January 07, 2003 3:00 PM
> > To: Steve Fisher
> > Cc: sipping@ietf.org
> > Subject: RE: [Sipping] Stimulus Signaling/Markup between 
> > complex SIP UAs
> > and apps?
> > 
> > 
> > To answer the question directly: 
> > 
> > KPML only works with HTTP reporting.  It would be a different 
> > language for SIP reporting.  MSCML is an example of a 
> > language that uses SIP for reporting.
> > 
> > 
> > 
> > To answer the SIP stimulus reporting question:
> > 
> > Done INFO in the past, not planning on it again :-)
> > 
> > NOTIFY is my leading contender, but a new method may be 
> > needed because if you do a strict reading of NOTIFY, you 
> > might not want a NOTIFY without a SUBSCRIBE.
> > 
> > Using SUBSCRIBE as a method of pushing KPML is out and out 
> > evil (I mean wrong).  KPML changes the state of the UAS.  
> > SUBSCRIBE is not supposed to have any side-effects.
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Steve Fisher [mailto:sfisher1@att.com]
> > > Sent: Tuesday, January 07, 2003 8:15 AM
> > > To: Eric Burger
> > > Cc: sipping@ietf.org
> > > Subject: RE: [Sipping] Stimulus Signaling/Markup between 
> > > complex SIP UAs
> > > and apps?
> > > 
> > > 
> > > Eric,
> > > 
> > > I've been thinking about your statement below...
> > > 
> > > > > If we say SIP for stimulus reporting, then the diagram 
> > you drew, 
> > > > > with the implication that the signaling follows the 
> > > signaling path, 
> > > > > is what will occur.
> > > > > 
> > > > > Is this distinction important for you?  The design team 
> > > did not come
> > > 
> > > > > to full agreement on which way to go.  Compelling 
> > > arguments either 
> > > > > way welcomed.
> > > 
> > > Could you possibly elaborate on how "SIP for stimulus 
> > reporting" would
> > > work? Are you thinking of SUBSCRIBE/NOTIFY? Are you 
> > thinking of using
> > > INFO? It's fairly clear from the KPML draft how HTTP would 
> > > work, but SIP
> > > was less clear to me...
> > > 
> > > Thanks!
> > > Steve
> > > 
> > > -----Original Message-----
> > > From: sipping-admin@ietf.org 
> > [mailto:sipping-admin@ietf.org] On Behalf
> > > Of Eric Burger
> > > Sent: Tuesday, December 17, 2002 5:18 PM
> > > To: Don Stanwyck
> > > Cc: sipping@ietf.org; Jain, Rajnish (Rajnish)
> > > Subject: RE: [Sipping] Stimulus Signaling/Markup between 
> > > complex SIP UAs
> > > and apps?
> > > 
> > > 
> > > Rajnish is 1000% correct in his interpretation.  Looking at 
> > > the message
> > > I can see how my statement isn't entirely clear.
> > > 
> > > I am on record in this and other fora that H.248 and J.162 are the
> > > appropriate protocols for device control.  See my posts to 
> > > the speechsc
> > > list.  I should have a paste buffer with my "Don't use SIP 
> > > for low-level
> > > peripheral device control" rant.
> > > 
> > > When I said "It [the thing referenced as "softswitch" in Rajnish's
> > > e-mail -- ewb] is not a media gateway controller" I meant 
> > it was not a
> > > media gateway controller, e.g., a device control thing, which uses
> > > device control protocols like H.248 and J.162.
> > > 
> > > Now it's my turn for interpreting Rajnish, instead of him 
> > interpreting
> > > me :-)  I assumed that the "PSTN X" thing was a MG-MGC 
> combination,
> > > speaking SIP on the packet network side.  E.g., the MG-MGC 
> > > interface was
> > > a private matter, not of interest to the discussion.
> > > 
> > > Sorry for the confusion.
> > > 
> > > > -----Original Message-----
> > > > From: Jain, Rajnish (Rajnish) [mailto:rajnishjain@lucent.com]
> > > > Sent: Tuesday, December 17, 2002 4:02 PM
> > > > To: 'Don Stanwyck'; Eric Burger; Jain, Rajnish (Rajnish)
> > > > Cc: sipping@ietf.org; Twomey, Michael S (Michael)
> > > > Subject: RE: [Sipping] Stimulus Signaling/Markup between
> > > > complex SIP UAs
> > > > and apps?
> > > > 
> > > > 
> > > > Don,
> > > > I don't think Eric implied controlling a MG from a Softswitch
> > > > via SIP in his
> > > > comment. That particular topic has come up in this forum many 
> > > > times and as I 
> > > > recall the conclusion has always been that SIP is not meant 
> > > > for that. SIP is 
> > > > a peer-to-peer to protocol not a master-slave protcol - 
> > > > agreed. However this
> > > > is completely orthogonal to using stimulus/markup signaling 
> > > > in SIP.  I don't
> > > > see how in-lining a KPML doc (e.g.) in a SIP message breaks 
> > > > SIP paradigm. 
> > > > 
> > > > Eric,
> > > > In general, I would like to propose an HTTP-free alternative
> > > > for delivery of 
> > > > stimulus signals, such as through in-lining of KPML. The 
> > > > benefits of such an
> > > > alternative in my mind are following:
> > > > 
> > > > - it would make it easier for SIP developers on embedded
> > > > platforms to embrace 
> > > >   markup/stimulus signaling that don't support HTTP currently
> > > > 
> > > > - it would facilitate close coordination between announcement
> > > > play and DTMF
> > > >   collection. Barge-in is a good example for that. The app 
> > > > can delegate the  
> > > >   job to stop announcement play at barge-in to the 
> > > > Softswitch. As an aside,
> > > >   the Softswitch in my previous figure is one w/ bizarre API 
> > > > as you say :-)
> > > > 
> > > > Rajnish
> > > > 
> > > > -----Original Message-----
> > > > From: Don Stanwyck [mailto:don@stanwyck.com]
> > > > Sent: Tuesday, December 17, 2002 3:10 PM
> > > > To: 'Eric Burger'; 'Jain, Rajnish (Rajnish)'
> > > > Cc: sipping@ietf.org; 'Twomey, Michael S (Michael)'
> > > > Subject: RE: [Sipping] Stimulus Signaling/Markup between
> > > > complex SIP UAs
> > > > and apps?
> > > > 
> > > > 
> > > > RFC 3261, Section 2 reads:
> > > > 
> > > > //START QUOTE
> > > > 
> > > > SIP supports five facets of establishing and terminating
> > > > multimedia communications:
> > > >   - User location: determination of the end system to be
> > > >     used for communication;
> > > >   - User availability: determination of the willingness
> > > >     of the called party to engage in communications;
> > > >   - User capabilities: determination of the media and media
> > > >     parameters to be used;
> > > >   - Session setup: "ringing", establishment of session
> > > >     parameters at both called and calling party;
> > > >   - Session management: including transfer and termination
> > > >     of sessions, modifying session parameters, and invoking
> > > >     services.
> > > > 
> > > > SIP is not a vertically integrated communications system.
> > > > SIP is rather
> > > > a component that can be used with other IETF protocols 
> to build a
> > > > complete multimedia architecture.  Typically, these 
> > > architectures will
> > > > include protocols such as the Real-time Transport Protocol 
> > > (RTP) (RFC
> > > > 1889 [28]) for transporting real-time data and providing 
> > > QoS feedback,
> > > > the Real-Time streaming protocol (RTSP) (RFC 2326 [29]) for 
> > > > controlling
> > > > delivery of streaming media, the Media Gateway Control 
> > > > Protocol (MEGACO)
> > > > (RFC 3015 [30]) for controlling gateways to the Public Switched
> > > > Telephone Network (PSTN), and the Session Description 
> > Protocol (SDP)
> > > > (RFC 2327 [1]) for describing multimedia sessions.  
> Therefore, SIP
> > > > should be used in conjunction with other protocols in order 
> > > to provide
> > > > complete services to the users.  However, the basic 
> > > functionality and
> > > > operation of SIP does not depend on any of these protocols.
> > > > 
> > > > //END QUOTE
> > > > 
> > > > I can't find any support in this definition of SIP for
> > > > carrying stimulus
> > > > signaling or for controling media gateways (comment 1 in Eric's
> > > > comments).  SIP, as defined and approved by the IETF, is not 
> > > > expected to
> > > > do these kinds of things that other IETF protocols are 
> designed to
> > > > handle.
> > > > 
> > > > Let's try to keep SIP doing the things it is designed to do 
> > > and does 
> > > > well, and not try to make it into a protocol for doing 
> everything 
> > > > imaginable.  It is already in danger of becoming too 
> difficult to 
> > > > implement as the number of options and new headers grows.
> > > > 
> > > > Don Stanwyck
> > > > 
> > > > 
> > > > 
> > > > > -----Original Message-----
> > > > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]
> > > > > On Behalf Of Eric Burger
> > > > > Sent: Tuesday, December 17, 2002 12:12 PM
> > > > > To: Jain, Rajnish (Rajnish)
> > > > > Cc: sipping@ietf.org; Twomey, Michael S (Michael)
> > > > > Subject: RE: [Sipping] Stimulus Signaling/Markup between 
> > > > > complex SIP UAs and apps?
> > > > > 
> > > > > 
> > > > > For timelines, I would suggest asking the work group chairs.
> > > > > We're at their mercy :-)
> > > > > 
> > > > > Putting my ISC hat on, what is the Softswitch in your diagram?
> > > > >   1. It is not a media gateway controller, as it talks to
> > > > >      the gateway with SIP (right answer, by the way).
> > > > >   2. Is it a Stateless Proxy, a'la the Routing Function
> > > > >      in the ISC reference diagram?  If so, that works
> > > > >      exactly as you want it to.  See below for more.
> > > > >   3. Is it an application server, a'la dynamicsoft,
> > > > >      Ubiquity, LongBoard, etc.?  If so, that also works
> > > > >      exactly as you want it to.  See below for more.
> > > > >   4. Is it some kind of statefull proxy, with a bizarre,
> > > > >      proprietary API to the pre-paid application (e.g., 
> > > > >      Parlay, JAIN, EXS, ...)?  If so, you are on your
> > > > >      own.
> > > > > 
> > > > > If we say "HTTP only" for stimulus reporting, the PSTN
> > > > > gateway must be a HTTP client.  The good news is the gateway 
> > > > > can communicate directly with the pre-paid application.  That 
> > > > > also means the pre-paid application needs to have a HTTP 
> > > > > server.  Alternatively, if the "Softswitch" is really a 
> > > > > telephony application server (case #3 above), then it 
> > > > > probably already has HTTP server capability built-in.
> > > > > 
> > > > > If we say SIP for stimulus reporting, then the diagram you
> > > > > drew, with the implication that the signaling follows the 
> > > > > signaling path, is what will occur.
> > > > > 
> > > > > Is this distinction important for you?  The design team did
> > > > > not come to full agreement on which way to go.  Compelling 
> > > > > arguments either way welcomed.
> > > > > 
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Jain, Rajnish (Rajnish) 
> [mailto:rajnishjain@lucent.com]
> > > > > > Sent: Friday, December 06, 2002 4:20 PM
> > > > > > To: Eric Burger; Jain, Rajnish (Rajnish)
> > > > > > Cc: sipping@ietf.org; Twomey, Michael S (Michael)
> > > > > > Subject: RE: [Sipping] Stimulus Signaling/Markup 
> > > between complex 
> > > > > > SIP UAs and apps?
> > > > > > 
> > > > > > 
> > > > > > Eric,
> > > > > > 
> > > > > > Thanks for your response. Would you be able to 
> comment on the 
> > > > > > timeline of when does the design team hope to accomplish the
> > > > > > following:
> > > > > > 
> > > > > > - general acceptance of the stimulus signaling, KPML etc.
> > > > > > - standardization of app interaction fwk, KPML into an RFC
> > > > > > 
> > > > > > Regarding an example of a PSTN switch that can be 
> > > connected to a 
> > > > > > pre-paid app over SIP-T, I don't know how much I can 
> > > disclose in 
> > > > > > front of this forum, but that is something being 
> > looked at by a 
> > > > > > few telecom gear vendors in my understanding.
> > > > > > 
> > > > > > I wanted to bring your attention to SIP-T wrt to my
> > > > > previous question.
> > > > > > I believe your answer will remain the same but I just to
> > > > wanted to
> > > > > > re-iterate the question in different words this time,
> > > > just to make
> > > > > > sure we're communicating:
> > > > > > 
> > > > > > In the setup below:
> > > > > >                                Pre-paid app
> > > > > >                                    |
> > > > > > POTS ---- PSTN X <---SIP-T---> Softswitch ----
> > > > > >                                
> > > > > >     
> > > > > > .. you would think, application interaction framework 
> > concepts 
> > > > > > such as stimulus signaling, user-inetrfaces and 
> KPML etc. are 
> > > > > > designed to work over the SIP-T i/f between 
> > packet-enabled PSTN 
> > > > > > switch and a Softswitch. Wouldn't you?
> > > > > > 
> > > > > > Thanks,
> > > > > > Rajnish
> > > > > > 
> > > > > > > -----Original Message----- From: Jain, Rajnish (Rajnish)
> > > > > [mailto:rajnishjain@lucent.com]
> > > > > > 
> > > > > > The Application Interaction Framework draft talks 
> > about stimulus
> > > > > > signaling as a way for SIP UAs to interact w/ SIP 
> > > > applications. The
> > > > > > draft suggests use of markup languages to allow
> > > > > applications to manage
> > > > > > local/remote user interfaces on SIP UAs.
> > > > > > 
> > > > > > While the draft exemplifies a UA's stimulus/markup 
> > > interaction w/ 
> > > > > > a pre-paid application server, it is not very clear to 
> > > us if the 
> > > > > > caller UA (instead of a subscriber end-point) can be a 
> > > complex UA 
> > > > > > such as the following:
> > > > > > 
> > > > > > - SIP (enabled) Gateway
> > > > > 
> > > > > Why not?  It does SIP.  It may do tone detection.
> > > > > 
> > > > > > - PSTN Switch w/ SIP-T interface
> > > > > 
> > > > > Why not?  It does SIP.  It may do tone detection.
> > > > > 
> > > > > > and does the draft recommend stimulus/markup 
> > signaling between 
> > > > > > such complex/concentrated UAs (or apps) and SIP 
> applications ?
> > > > > 
> > > > > The draft is silent on it.  If you manufacture media rich
> > > > > gateways, you might say "of course".  If you manufacture 
> > > > > media servers, you might say "you could if you wanted, but 
> > > > > you would be better served if you didn't."  :-)
> > > > > 
> > > > > > In other words, does the stimulus signaling apply 
> to following
> > > > > > scenarios ?:
> > > > > > 
> > > > > > 1. The pre-paid caller is connected to a PSTN switch 
> > that has a 
> > > > > > SIP-T interface to the pre-paid application.
> > > > > 
> > > > > Yes, so long as the PSTN switch is SIP-aware, able to parse
> > > > > and execute KPML, and report using SIP (or, yuck, http).
> > > > > 
> > > > > Do you know of such a switch?
> > > > >  
> > > > > > 2. The pre-paid caller is connected to a PBX (SIP 
> > > Gateway) over an
> > > 
> > > > > > ISDN i/f, which in turn is connected to the pre-paid 
> > app. over 
> > > > > > normal SIP.
> > > > > 
> > > > > Same issues as for the PSTN switch.
> > > > > 
> > > > > > If yes, would the terms client-local and 
> > client-remote still be
> > > > > > accurate, as the user here is a POTS/ISDN user? From 
> > the user's 
> > > > > > perspective, the UI would be client-remote. But from 
> > > > application's
> > > > > > perspective the UI would be client-local (as the UI will be
> > > > > on the PBX
> > > > > > or PSTN switch both of which look like a UA to app server).
> > > > > 
> > > > > It is still client-local, as the gateway/switch/PBX is a
> > > > > local proxy for the user.  If you used a media server in the 
> > > > > IP network behind the gateway/switch/PBX to execute the KPML, 
> > > > > then you would be cline-remote. 
> > > > > _______________________________________________
> > > > > Sipping mailing list  
> > > https://www1.ietf.org/mailman/listinfo/sipping
> > > > > This list is for NEW development of the application of SIP
> > > > > Use sip-implementors@cs.columbia.edu for questions on current 
> > > > > sip Use sip@ietf.org for new developments of core SIP
> > > > > 
> > > > 
> > > _______________________________________________
> > > Sipping mailing list  
https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use sip-implementors@cs.columbia.edu for questions on 
> current sip Use
> > sip@ietf.org for new developments of core SIP
> > 
> > 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Wed Jan  8 15:08:15 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05166
	for <sipping-archive@odin.ietf.org>; Wed, 8 Jan 2003 15:08:15 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h08KJaO18677
	for sipping-archive@odin.ietf.org; Wed, 8 Jan 2003 15:19:36 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08KJaJ18674
	for <sipping-web-archive@optimus.ietf.org>; Wed, 8 Jan 2003 15:19:36 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05019
	for <sipping-web-archive@ietf.org>; Wed, 8 Jan 2003 15:05:12 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08KEGJ18466;
	Wed, 8 Jan 2003 15:14:16 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08KBIJ18360
	for <sipping@optimus.ietf.org>; Wed, 8 Jan 2003 15:11:18 -0500
Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04723
	for <sipping@ietf.org>; Wed, 8 Jan 2003 14:59:25 -0500 (EST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA21138
	for <sipping@ietf.org>; Wed, 8 Jan 2003 15:02:40 -0500 (EST)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA26615
	for <sipping@ietf.org>; Wed, 8 Jan 2003 15:02:41 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <ZVACLS45>; Wed, 8 Jan 2003 15:02:40 -0500
Message-ID: <313680C9A886D511A06000204840E1CF030B5CE2@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'sipping@ietf.org'" <sipping@ietf.org>
Subject: RE: [Sipping] URIs for Gateways
Date: Wed, 8 Jan 2003 15:02:40 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

After all of this, I propose the following:

1. We add the possibility of a callerId string to a tel uri:
   telephone-uri = "tel:" [callerIdName LWS] subscriber
   callerIdName = quoted-string

2. Gateways accept or send sip uris of the form:
   sip:"Alice Toklas" 4125551212@gateway.atlanta.com; user=phone; port=3
or tel uris of the form:
   tel:"Alice Toklas" +14125551212; port=3
or "ordinary" sip uri's with extra information in a separate header 
of the form:
   <header> +14125551212; port=3

where <header> could be "P-Asserted-Identity", or it could be a new
header we define for the purpose.

Then, we have the following possibilities:

SIP device to gateway (outgoing) call
   To a phone number
        use the phone number in the Request-URI & To:, probably
        in a tel URI, or maybe phonenumber@localdomain; user=phone

        use normal sip URI in From:
     
        If a translator is available, it may assert the phone number
        for the identity in the From: using <header>

        proxy may rewrite the Request-URI in the form of
        sip: phone@gateway;user=phone;port=portnum
   
   To a sip URI
        use the sip uri in the Request-URI and To:
        use normal sip URI in From:

        proxy rewrites Request-URI, due to forwarding behavior,
        ENUM lookup, etc, resulting in a tel URI or a user=phone sip
        uri.  If necessary, a local incoming proxy can rewrite it to
        add the port parameter to the Request-URI based on the From:
    
        If a translator is available, it may assert the phone number
        for the identity in the From: using the <header>

Gateway to SIP device (incoming call)
   With mapping
        use the mapped uri in the Request-URI & To:
          
        (optionally) supply called number using <header>
        This might be needed when multiple called numbers
        map to the same uri.
        
        use sip:"callerId" phone@gateway; port=portnum or
        a tel: uri in From:

   Without mapping
        use a provisioned (per port) URI, a tel uri with the called 
        number, or a sip uri with calledNumber@localdomain; user=phone
        in the Request-URI & To:.  Gateways should support all 3,
        choice should be made by provisioning.

        use sip:"callerId" phone@gateway; port=portnum or tel
        uri in From: 

        proxy will rewrite the Request-URI with the correct sip URI
        associated with the called number  
  
Brian
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Wed Jan  8 15:39:03 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06482
	for <sipping-archive@odin.ietf.org>; Wed, 8 Jan 2003 15:39:03 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h08KoQi20409
	for sipping-archive@odin.ietf.org; Wed, 8 Jan 2003 15:50:26 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08KoPJ20406
	for <sipping-web-archive@optimus.ietf.org>; Wed, 8 Jan 2003 15:50:26 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06420
	for <sipping-web-archive@ietf.org>; Wed, 8 Jan 2003 15:38:05 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08KlSJ20308;
	Wed, 8 Jan 2003 15:47:28 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08KkcJ20281
	for <sipping@optimus.ietf.org>; Wed, 8 Jan 2003 15:46:38 -0500
Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06367
	for <sipping@ietf.org>; Wed, 8 Jan 2003 15:34:45 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h08Kcg0q024274;
	Wed, 8 Jan 2003 15:38:43 -0500 (EST)
Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAX55812;
	Wed, 8 Jan 2003 15:43:02 -0500 (EST)
Message-ID: <3E1C8C28.4030802@cisco.com>
Date: Wed, 08 Jan 2003 15:38:00 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
CC: "'sipping@ietf.org'" <sipping@ietf.org>
Subject: Re: [Sipping] URIs for Gateways
References: <313680C9A886D511A06000204840E1CF030B5CE2@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Brian,

A few initial comments. More later when I get time to think about it.

- I'm not sure of the advisability of adding caller name to the tel uri. 
If  you do it, I don't like that way. Would prefer a tel: parameter, as in
      tel:+14125551212;caller-name="Alice Toklas"

- I don't think the port should be a sip uri parameter. It is very 
telephony oriented, so I think it is better as a tel: uri parameter.

	Paul

Rosen, Brian wrote:
> After all of this, I propose the following:
> 
> 1. We add the possibility of a callerId string to a tel uri:
>    telephone-uri = "tel:" [callerIdName LWS] subscriber
>    callerIdName = quoted-string
> 
> 2. Gateways accept or send sip uris of the form:
>    sip:"Alice Toklas" 4125551212@gateway.atlanta.com; user=phone; port=3
> or tel uris of the form:
>    tel:"Alice Toklas" +14125551212; port=3
> or "ordinary" sip uri's with extra information in a separate header 
> of the form:
>    <header> +14125551212; port=3
> 
> where <header> could be "P-Asserted-Identity", or it could be a new
> header we define for the purpose.
> 
> Then, we have the following possibilities:
> 
> SIP device to gateway (outgoing) call
>    To a phone number
>         use the phone number in the Request-URI & To:, probably
>         in a tel URI, or maybe phonenumber@localdomain; user=phone
> 
>         use normal sip URI in From:
>      
>         If a translator is available, it may assert the phone number
>         for the identity in the From: using <header>
> 
>         proxy may rewrite the Request-URI in the form of
>         sip: phone@gateway;user=phone;port=portnum
>    
>    To a sip URI
>         use the sip uri in the Request-URI and To:
>         use normal sip URI in From:
> 
>         proxy rewrites Request-URI, due to forwarding behavior,
>         ENUM lookup, etc, resulting in a tel URI or a user=phone sip
>         uri.  If necessary, a local incoming proxy can rewrite it to
>         add the port parameter to the Request-URI based on the From:
>     
>         If a translator is available, it may assert the phone number
>         for the identity in the From: using the <header>
> 
> Gateway to SIP device (incoming call)
>    With mapping
>         use the mapped uri in the Request-URI & To:
>           
>         (optionally) supply called number using <header>
>         This might be needed when multiple called numbers
>         map to the same uri.
>         
>         use sip:"callerId" phone@gateway; port=portnum or
>         a tel: uri in From:
> 
>    Without mapping
>         use a provisioned (per port) URI, a tel uri with the called 
>         number, or a sip uri with calledNumber@localdomain; user=phone
>         in the Request-URI & To:.  Gateways should support all 3,
>         choice should be made by provisioning.
> 
>         use sip:"callerId" phone@gateway; port=portnum or tel
>         uri in From: 
> 
>         proxy will rewrite the Request-URI with the correct sip URI
>         associated with the called number  
>   
> Brian
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Wed Jan  8 17:29:25 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10090
	for <sipping-archive@odin.ietf.org>; Wed, 8 Jan 2003 17:29:25 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h08MemI28492
	for sipping-archive@odin.ietf.org; Wed, 8 Jan 2003 17:40:48 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08MemJ28489
	for <sipping-web-archive@optimus.ietf.org>; Wed, 8 Jan 2003 17:40:48 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10030
	for <sipping-web-archive@ietf.org>; Wed, 8 Jan 2003 17:28:41 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08MbiJ28368;
	Wed, 8 Jan 2003 17:37:44 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08MaNJ27715
	for <sipping@optimus.ietf.org>; Wed, 8 Jan 2003 17:36:23 -0500
Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09914
	for <sipping@ietf.org>; Wed, 8 Jan 2003 17:24:28 -0500 (EST)
Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11])
	by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h08MRI807288;
	Wed, 8 Jan 2003 22:27:18 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19)
	id <ZH2JFXGF>; Wed, 8 Jan 2003 17:29:39 -0500
Message-ID: <15A2739B7DAA624D8091C65981D7DA815EB4FF@stntexch2.va.neustar.com>
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: "'Rosen, Brian'" <Brian.Rosen@marconi.com>,
        "'Drage, Keith (Keith)'"
	 <drage@lucent.com>,
        "'Henning Schulzrinne'" <hgs@cs.columbia.edu>
Cc: "'sipping@ietf.org'" <sipping@ietf.org>
Subject: RE: [Sipping] URIs for Gateways
Date: Wed, 8 Jan 2003 17:29:38 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>


Some notes below.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: Tuesday, January 07, 2003 7:12 AM
> To: 'Peterson, Jon'; 'Drage, Keith (Keith)'; 'Henning Schulzrinne'
> Cc: 'sipping@ietf.org'
> Subject: RE: [Sipping] URIs for Gateways
> 
> 
> I think Reply-To is a so-so place to put a second identity.
> I think it's problematic to have a From have the "real"
> SIP URI and the Reply-To have the "real" tel URI.  It
> warps the definition of Reply-To.
> 

What I suggested was that the From header hold the URI of the gateway - not
the 'real' SIP URI of the user - for PSTN-to-SIP calls. The From address in
this instance is not the address to which you should reply if you want to
reach the initiator of the session later. The tel URL of that user is in
fact the URI to which you should reply. I think this is a good place to put
it for this case, and it doesn't warp the Reply-To header in any way that I
can see. This is completely unrelated to where one would put the 'real' SIP
URI of the user.

> It also has a serious problem that a proxy can't add it.

I think you mean that you want the proxy to be able to add a telephone
number to a request for a SIP-to-PSTN call, or maybe to add a SIP URI
representing the originating user to a request for a PSTN-to-SIP call
(though this latter one is difficult - how would a user authenticate
themselves to an auth service through a PSTN gateway?). I agree that
Reply-To is not a good candidate for this usage - this is where it has been
argued that P-Asserted-Identity is a good candidate.

There are some minor issues with this (such as how a proxy knows when and
why to add identities, and how authentication for particular identifies is
managed), but I think that if a proxy asserts an identity, it can and should
use the identity mechanisms we've already defined, which were designed
specifically with proxies in mind. However, there are some reasons to ask
whether or not proxies are always the best entities to decide when synonym
identities should be added to a request.

> One of the requirements I have is that a proxy be able to
> do the translation.  Not every gateway can hold all the tables
> required for this kind of translation, and I don't think
> we want to force every gateway to have the tables.
> 

The whole issue of who should do 'translation' by various entities is a
little problematic, and ultimately this problem should be separable from the
selection of the headers we might use to express the results of translation.
Personally, I think ENUM is the right way to do telephone number to URI
translations - however, it is not servicable for the reverse, for URI to
telephone number translations. Having some kind of 'reverse ENUM' for this
purpose has been the subject of much speculation in ENUM circles, but it
currently is not well understood how it would work.

ENUM is best performed by the initiator of the session, rather than an
intermediary, for various reasons that are enumerated in sipping-e164-02.
Therefore, for PSTN-to-SIP calls, I think the PSTN gateway is the right
place to do an ENUM query. This does not require the gateway to have any
tables, or what have you. Intermediaries can also query ENUM and apply the
results to a message, even if it is sub-optimal for them to do so.

> I think your proposals on identity will not work unless
> the signer can be a proxy which later in the routing
> than my proxy that does the translation.  

Well, an authentication service, as I describe it, does the signing after a
request has been generated, yes. If a later proxy wants to shove some
(authenticated) information into the request afterwards, that isn't possible
unless is supplies a separate signed body.

> If the gateway
> does the translation, then in theory there would have to be
> a trust relationship between the PSTN and the gateway. 

There is always, in effect, a trust relationship between the PSTN and a
gateway. The gateway is a node on the PSTN (whether it is a privileged node,
like an SS7 gateway, or a user node, like a CAS gateway), and nodes have a
certain defined trust relationship with the PSTN. I think the gateway is one
of the better candidates to do ENUM, and possibly to perform the reverse
operation (however that would work).
 
> That won't work for an enterprise gateway, although I'm not
> sure that's a practical problem, because if the gateway
> translated, the PSTN is going to check that the number
> the gateway asserted is one of the identities that loop
> is allocated (PRIs have ranges).
> 

Presumably, gateways shouldn't trust authentication services that might give
them improper information. In fact, there are numerous restrictions
surrounding what sorts of phone numbers should be sent over many sorts of
ISUP trunks as well (as well as rules about when a CgPN must be present, as
opposed to may be present). An proxy or user agent that supplies originating
telephone numbers for SIP-to-PSTN calls should expect gateways to validate
them, and there should be some way to accomodate cases in which the gateway
cannot transmit these numbers to the PSTN, since it may be difficult for a
proxy to determine what sort of gateway a request will ultimately land on
(which is one of the reasons why proxies might not be the best place for
synonym identities to be managed).

> I don't see how ENUM is useful with identity assertion,
> although it's clearly applicable to the proxy that
> translates a SIP URI into a phone number or vice versa in
> the Request URI.  

It doesn't assert identity itself, certainly. The one place in which it is
conceivably useful for identity assertion is that ENUM could be queried for
a URI associated with the calling party's number in a PSTN-to-SIP call. This
could be useful for a number of reasons - that URI could be stuck in a
header to indicate a SIP URI for the end user that is more explicit or
recognizable than their telephone number.

> 
> Brian
> 
> > -----Original Message-----
> > From: Peterson, Jon [mailto:jon.peterson@neustar.biz]
> > Sent: Tuesday, January 07, 2003 6:35 AM
> > To: 'Rosen, Brian'; 'Drage, Keith (Keith)'; 'Henning Schulzrinne'
> > Cc: 'sipping@ietf.org'
> > Subject: RE: [Sipping] URIs for Gateways
> > 
> > 
> > 
> > First, it is possible, with the long-term identity mechanism, 
> > to assert two
> > identities in an authenticated identity body. So, you could 
> > have headers
> > corresponding to a telephone number and a SIP URI of a 
> > gateway or a user -
> > it strikes me that a telephone number is a good Reply-To, 
> > actually, when a
> > call comes from a gateway (originating in the PSTN, say) and 
> > the From header
> > field contains a SIP URI for the gateway, perhaps including 
> some port
> > information. The identity that the gateway which handles a 
> > PSTN-SIP call
> > would assert needs to be its own, and recipients of calls 
> > from gateways need
> > to trust the telephone number provided by the gateway or not 
> > accordingly
> > (i.e. a signature from att.com vouching for such a request should be
> > acceptable).
> > 
> > Technologies like ENUM (when/where available) could enable 
> gateways to
> > convert originating telephone numbers into URIs. Of course, 
> a gateway
> > wouldn't be able to assert that identity to an intermediary 
> unless it
> > possessed credentials appropriate to that URI, which is unlikely.
> > 
> > For outbound calls (SIP-PSTN), the gateway may or may not be 
> > able to map
> > (authenticated) SIP URIs representing originators to 
> > appropriate telephone
> > numbers via some sort of local tables as you suggested. If 
> > not, might also
> > pick a number from a pool, sure. The question of whether some 
> > authentication
> > service should be able to assert an originating telephone 
> > number (in an
> > authenticated identity body, say) that a gateway will use is 
> > also a trust
> > question - it is possible to put the tel URL in the AIB. If 
> > the gateway has
> > a reason to trust the authentication service, then certainly 
> > it should send
> > that number to the PSTN (when the protocol allows gateways 
> to supply a
> > number, like with ISUP or Q.931). The gateway would be very 
> > ill advised to
> > take just any authentication service's word on this matter, though. 
> > 
> > The target of the calls for the PSTN should be identified 
> > with a telephone
> > number - at least, by the time the call arrives a gateway, 
> > it's Request-URI
> > should contain a tel URL or a SIP URI with a tel URL 
> > component. Whether the
> > originating UAC sets the To header field to a tel URL or a 
> > subsequent proxy
> > retargets the request doesn't seem to make much difference. 
> > ENUM can also
> > play a pretty obvious role here.
> > 
> > Jon Peterson
> > NeuStar, Inc.
> > 
> > > -----Original Message-----
> > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > > Sent: Monday, January 06, 2003 1:22 PM
> > > To: 'Peterson, Jon'; 'Drage, Keith (Keith)'; Rosen, 
> Brian; 'Henning
> > > Schulzrinne'
> > > Cc: 'sipping@ietf.org'
> > > Subject: RE: [Sipping] URIs for Gateways
> > > 
> > > 
> > > I agree with this.  I'm confused by those who seem to think that
> > > P-Asserted-Identity is needed when the long term solution is
> > > fully baked.  If the UA knows its identity, which seems
> > > reasonable, then it can "assert" it, and have that assertion
> > > validated by a trusted entity using cryptographic means.
> > > That is the fundamental idea I get out of Jon's proposal.
> > > The only circumstance where that won't work is where the
> > > UA doesn't know its identity.  I don't see that as a problem
> > > on any network I'm aware of, but ...... keep reading.
> > > 
> > > I do think there is a problem which this whole thread talks about.
> > > The basic reality is that many users of SIP UAs will have two
> > > identities - a SIP URI and a telephone number.  It may be
> > > necessary to assert both identities in one call, because the
> > > originator of the call does not know which identity may be
> > > needed.  There is no current header to do this.  I think that 
> > > it is advantageous to have a proxy be able to assert the phone 
> > > number.  Otherwise EVERY UA will have to be able to understand 
> > > that two identities are possible, know them both by some 
> > > unspecified means, and assert them in every call on every UA.  
> > > This seems unreasonable.  I'm not sure that there is a reason
> > > to have both identities validated, but there could be.
> > > 
> > > Brian
> > > > -----Original Message-----
> > > > From: Peterson, Jon [mailto:jon.peterson@neustar.biz]
> > > > Sent: Monday, January 06, 2003 2:06 PM
> > > > To: 'Drage, Keith (Keith)'; Rosen, Brian; 'Henning Schulzrinne'
> > > > Cc: 'sipping@ietf.org'
> > > > Subject: RE: [Sipping] URIs for Gateways
> > > > 
> > > > 
> > > > 
> > > > RFC3325 was 'short-term' because it was achievable in the 
> > > > short-term and has
> > > > a more limited (but still useful) applicability. The 
> > > > long-term identity
> > > > solution must be a superset of the functionality of 
> > > > short-term - it must
> > > > address the short-term scope of applicability, but also 
> > > > encompass general
> > > > needs for network assertion (which SIP does have). 
> > > > Accordingly, it takes
> > > > longer to develop. At such a time as there is a workable 
> > > > long-term solution,
> > > > it would be pointless to allow both to be SIP standards 
> > > > except as part of a
> > > > transition plan. So in that sense, I disagree - one is a 
> > > > short-term solution
> > > > of the other.
> > > > 
> > > > Jon Peterson
> > > > NeuStar, Inc.
> > > > 
> > > > > -----Original Message-----
> > > > > From: Drage, Keith (Keith) [mailto:drage@lucent.com]
> > > > > Sent: Friday, January 03, 2003 8:20 AM
> > > > > To: Rosen, Brian; 'Henning Schulzrinne'
> > > > > Cc: 'sipping@ietf.org'
> > > > > Subject: RE: [Sipping] URIs for Gateways
> > > > > 
> > > > > 
> > > > > Network asserted identity (RFC 3325) is the real network 
> > > > > asserted identity. It is a P header not because it is 
> > > > > preliminary, but because the whole idea of network assertion 
> > > > > is not generally applicable to all SIP architectures. For RFC 
> > > > > 3325 a trust domain needs to exist between proxies that use 
> > > > > the P-Asserted-Identity in order to guarantee the privacy, 
> > > > > this does not exist in all SIP networks. In does in 3GPP and 
> > > > > therefore 3GPP are using RFC 3325.
> > > > > 
> > > > > If you want to let the 1et outbound proxy assert identity on 
> > > > > your behalf then use RFC 3325. If you want to let application 
> > > > > servers with whom you have a secure relationship assert your 
> > > > > identity, then use Jon Petersons drafts, when they eventually 
> > > > > become RFCs. 
> > > > > 
> > > > > One is not a short term solution for the other.
> > > > > 
> > > > > Keith
> > > > > 
> > > > > Keith Drage
> > > > > Lucent Technologies
> > > > > Tel: +44 1793 776249
> > > > > Email: drage@lucent.com 
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > > > > > Sent: 02 January 2003 20:49
> > > > > > To: 'Henning Schulzrinne'
> > > > > > Cc: 'sipping@ietf.org'
> > > > > > Subject: RE: [Sipping] URIs for Gateways
> > > > > > 
> > > > > > 
> > > > > > Yeah, I actually thought of just allowing a display 
> > name in the
> > > > > > Request URI and using that, but it seems so foolish to make 
> > > > > a change,
> > > > > > and have that change not be exactly what we needed.
> > > > > > 
> > > > > > We could use NAI.  I suppose we could use a 
> > P-Asserted-Identity
> > > > > > with a tel URI:  
> > > > > > P-Asserted-Identity tel:+17247426826
> > > > > > 
> > > > > > What do we do when the "real" NAI happens?
> > > > > > 
> > > > > > Brian
> > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> > > > > > > Sent: Thursday, January 02, 2003 3:10 PM
> > > > > > > To: Rosen, Brian
> > > > > > > Cc: 'sipping@ietf.org'
> > > > > > > Subject: Re: [Sipping] URIs for Gateways
> > > > > > > 
> > > > > > > 
> > > > > > > > I'd like to get a new header for the calling 
> > party number on
> > > > > > > > an outbound call.  That way, the translator can be 
> > > a proxy and
> > > > > > > > add the header.  I'd recommend that gateways allow 
> > > the number
> > > > > > > > to be in the From.   
> > > > > > > 
> > > > > > > Generalized, you want something like the Request-URI 
> > > > that can be 
> > > > > > > modified or inserted. How about the NAI stuff?
> > > > > > > 
> > > > > > _______________________________________________
> > > > > > Sipping mailing list  
> > > > https://www1.ietf.org/mailman/listinfo/sipping
> > > > > > This list is for NEW development of the application of SIP
> > > > > > Use sip-implementors@cs.columbia.edu for questions on 
> > > current sip
> > > > > > Use sip@ietf.org for new developments of core SIP
> > > > > > 
> > > > > _______________________________________________
> > > > > Sipping mailing list  
> > > https://www1.ietf.org/mailman/listinfo/sipping
> > > > > This list is for NEW development of the application of SIP
> > > > > Use sip-implementors@cs.columbia.edu for questions on 
> > current sip
> > > > > Use sip@ietf.org for new developments of core SIP
> > > > > 
> > > > _______________________________________________
> > > > Sipping mailing list  
> > https://www1.ietf.org/mailman/listinfo/sipping
> > > > This list is for NEW development of the application of SIP
> > > > Use sip-implementors@cs.columbia.edu for questions on 
> current sip
> > > > Use sip@ietf.org for new developments of core SIP
> > > > 
> > > 
> > 
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Wed Jan  8 17:31:21 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10246
	for <sipping-archive@odin.ietf.org>; Wed, 8 Jan 2003 17:31:21 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h08MgiB28663
	for sipping-archive@odin.ietf.org; Wed, 8 Jan 2003 17:42:44 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08MgiJ28660
	for <sipping-web-archive@optimus.ietf.org>; Wed, 8 Jan 2003 17:42:44 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10172
	for <sipping-web-archive@ietf.org>; Wed, 8 Jan 2003 17:30:25 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08Me7J28481;
	Wed, 8 Jan 2003 17:40:07 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08McjJ28380
	for <sipping@optimus.ietf.org>; Wed, 8 Jan 2003 17:38:45 -0500
Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09951
	for <sipping@ietf.org>; Wed, 8 Jan 2003 17:26:51 -0500 (EST)
Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11])
	by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h08MTw807347;
	Wed, 8 Jan 2003 22:29:58 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19)
	id <ZH2JFXGV>; Wed, 8 Jan 2003 17:32:19 -0500
Message-ID: <15A2739B7DAA624D8091C65981D7DA815EB501@stntexch2.va.neustar.com>
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: "'Paul Kyzivat'" <pkyzivat@cisco.com>,
        "Rosen, Brian"
	 <Brian.Rosen@marconi.com>
Cc: "'sipping@ietf.org'" <sipping@ietf.org>
Subject: RE: [Sipping] URIs for Gateways
Date: Wed, 8 Jan 2003 17:32:18 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>


On the subject of a 'port' parameter, I agree this is best as a tel URL
parameter. In fact, I suggest that the trunk group tel URL parameter
currently under development in IPTEL might be sufficient for expressing port
information.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Wednesday, January 08, 2003 12:38 PM
> To: Rosen, Brian
> Cc: 'sipping@ietf.org'
> Subject: Re: [Sipping] URIs for Gateways
> 
> 
> Brian,
> 
> A few initial comments. More later when I get time to think about it.
> 
> - I'm not sure of the advisability of adding caller name to 
> the tel uri. 
> If  you do it, I don't like that way. Would prefer a tel: 
> parameter, as in
>       tel:+14125551212;caller-name="Alice Toklas"
> 
> - I don't think the port should be a sip uri parameter. It is very 
> telephony oriented, so I think it is better as a tel: uri parameter.
> 
> 	Paul
> 
> Rosen, Brian wrote:
> > After all of this, I propose the following:
> > 
> > 1. We add the possibility of a callerId string to a tel uri:
> >    telephone-uri = "tel:" [callerIdName LWS] subscriber
> >    callerIdName = quoted-string
> > 
> > 2. Gateways accept or send sip uris of the form:
> >    sip:"Alice Toklas" 4125551212@gateway.atlanta.com; 
> user=phone; port=3
> > or tel uris of the form:
> >    tel:"Alice Toklas" +14125551212; port=3
> > or "ordinary" sip uri's with extra information in a separate header 
> > of the form:
> >    <header> +14125551212; port=3
> > 
> > where <header> could be "P-Asserted-Identity", or it could be a new
> > header we define for the purpose.
> > 
> > Then, we have the following possibilities:
> > 
> > SIP device to gateway (outgoing) call
> >    To a phone number
> >         use the phone number in the Request-URI & To:, probably
> >         in a tel URI, or maybe phonenumber@localdomain; user=phone
> > 
> >         use normal sip URI in From:
> >      
> >         If a translator is available, it may assert the phone number
> >         for the identity in the From: using <header>
> > 
> >         proxy may rewrite the Request-URI in the form of
> >         sip: phone@gateway;user=phone;port=portnum
> >    
> >    To a sip URI
> >         use the sip uri in the Request-URI and To:
> >         use normal sip URI in From:
> > 
> >         proxy rewrites Request-URI, due to forwarding behavior,
> >         ENUM lookup, etc, resulting in a tel URI or a user=phone sip
> >         uri.  If necessary, a local incoming proxy can rewrite it to
> >         add the port parameter to the Request-URI based on the From:
> >     
> >         If a translator is available, it may assert the phone number
> >         for the identity in the From: using the <header>
> > 
> > Gateway to SIP device (incoming call)
> >    With mapping
> >         use the mapped uri in the Request-URI & To:
> >           
> >         (optionally) supply called number using <header>
> >         This might be needed when multiple called numbers
> >         map to the same uri.
> >         
> >         use sip:"callerId" phone@gateway; port=portnum or
> >         a tel: uri in From:
> > 
> >    Without mapping
> >         use a provisioned (per port) URI, a tel uri with the called 
> >         number, or a sip uri with calledNumber@localdomain; 
> user=phone
> >         in the Request-URI & To:.  Gateways should support all 3,
> >         choice should be made by provisioning.
> > 
> >         use sip:"callerId" phone@gateway; port=portnum or tel
> >         uri in From: 
> > 
> >         proxy will rewrite the Request-URI with the correct sip URI
> >         associated with the called number  
> >   
> > Brian
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sip@ietf.org for new developments of core SIP
> > 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Wed Jan  8 18:13:28 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12715
	for <sipping-archive@odin.ietf.org>; Wed, 8 Jan 2003 18:13:28 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h08NOqV30989
	for sipping-archive@odin.ietf.org; Wed, 8 Jan 2003 18:24:52 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08NOqJ30986
	for <sipping-web-archive@optimus.ietf.org>; Wed, 8 Jan 2003 18:24:52 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12692
	for <sipping-web-archive@ietf.org>; Wed, 8 Jan 2003 18:12:43 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08NMGJ30902;
	Wed, 8 Jan 2003 18:22:16 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08NLQJ30869
	for <sipping@optimus.ietf.org>; Wed, 8 Jan 2003 18:21:26 -0500
Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12611
	for <sipping@ietf.org>; Wed, 8 Jan 2003 18:09:29 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h08NDCEt017091;
	Wed, 8 Jan 2003 18:13:12 -0500 (EST)
Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAX57214;
	Wed, 8 Jan 2003 18:17:32 -0500 (EST)
Message-ID: <3E1CB05E.2080004@cisco.com>
Date: Wed, 08 Jan 2003 18:12:30 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Peterson, Jon" <jon.peterson@neustar.biz>
CC: "'Rosen, Brian'" <Brian.Rosen@marconi.com>,
        "'Drage, Keith (Keith)'" <drage@lucent.com>,
        "'Henning Schulzrinne'" <hgs@cs.columbia.edu>,
        "'sipping@ietf.org'" <sipping@ietf.org>
Subject: Re: [Sipping] URIs for Gateways
References: <15A2739B7DAA624D8091C65981D7DA815EB4FF@stntexch2.va.neustar.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

This is interesting. I wonder how many SIP UAs do anything with the 
Reply-To header?

At a minimum, I think there is a *lot* of best-practice to work out so 
that phone displays of who is calling, and automatic callback functions 
on phones "do the right thing" with all the various combinations of 
From, Reply-To, NAI, etc. Perhaps Brian is doing the right thing by 
starting down this path.

In your example, if I am the recipient of the call, I will want my phone 
to display the Reply-To address, and use that for any kind of automated 
callback it might do. I probably have no interest in seeing the From 
address at all.

But I have the feeling there are other (non-gateway) use cases where 
this may not be the case. For instance, I may be able to provide 
credentials that authenticate my From address, but want callbacks to go 
someplace else that I can't authenticate. The recipient may be unwilling 
to display an unauthenticated caller identity.

	Paul

Peterson, Jon wrote:
> Some notes below.
> 
> Jon Peterson
> NeuStar, Inc.
> 
> 
>>-----Original Message-----
>>From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
>>Sent: Tuesday, January 07, 2003 7:12 AM
>>To: 'Peterson, Jon'; 'Drage, Keith (Keith)'; 'Henning Schulzrinne'
>>Cc: 'sipping@ietf.org'
>>Subject: RE: [Sipping] URIs for Gateways
>>
>>
>>I think Reply-To is a so-so place to put a second identity.
>>I think it's problematic to have a From have the "real"
>>SIP URI and the Reply-To have the "real" tel URI.  It
>>warps the definition of Reply-To.
>>
> 
> 
> What I suggested was that the From header hold the URI of the gateway - not
> the 'real' SIP URI of the user - for PSTN-to-SIP calls. The From address in
> this instance is not the address to which you should reply if you want to
> reach the initiator of the session later. The tel URL of that user is in
> fact the URI to which you should reply. I think this is a good place to put
> it for this case, and it doesn't warp the Reply-To header in any way that I
> can see. This is completely unrelated to where one would put the 'real' SIP
> URI of the user.
> 
> 
>>It also has a serious problem that a proxy can't add it.
> 
> 
> I think you mean that you want the proxy to be able to add a telephone
> number to a request for a SIP-to-PSTN call, or maybe to add a SIP URI
> representing the originating user to a request for a PSTN-to-SIP call
> (though this latter one is difficult - how would a user authenticate
> themselves to an auth service through a PSTN gateway?). I agree that
> Reply-To is not a good candidate for this usage - this is where it has been
> argued that P-Asserted-Identity is a good candidate.
> 
> There are some minor issues with this (such as how a proxy knows when and
> why to add identities, and how authentication for particular identifies is
> managed), but I think that if a proxy asserts an identity, it can and should
> use the identity mechanisms we've already defined, which were designed
> specifically with proxies in mind. However, there are some reasons to ask
> whether or not proxies are always the best entities to decide when synonym
> identities should be added to a request.
> 
> 
>>One of the requirements I have is that a proxy be able to
>>do the translation.  Not every gateway can hold all the tables
>>required for this kind of translation, and I don't think
>>we want to force every gateway to have the tables.
>>
> 
> 
> The whole issue of who should do 'translation' by various entities is a
> little problematic, and ultimately this problem should be separable from the
> selection of the headers we might use to express the results of translation.
> Personally, I think ENUM is the right way to do telephone number to URI
> translations - however, it is not servicable for the reverse, for URI to
> telephone number translations. Having some kind of 'reverse ENUM' for this
> purpose has been the subject of much speculation in ENUM circles, but it
> currently is not well understood how it would work.
> 
> ENUM is best performed by the initiator of the session, rather than an
> intermediary, for various reasons that are enumerated in sipping-e164-02.
> Therefore, for PSTN-to-SIP calls, I think the PSTN gateway is the right
> place to do an ENUM query. This does not require the gateway to have any
> tables, or what have you. Intermediaries can also query ENUM and apply the
> results to a message, even if it is sub-optimal for them to do so.
> 
> 
>>I think your proposals on identity will not work unless
>>the signer can be a proxy which later in the routing
>>than my proxy that does the translation.  
> 
> 
> Well, an authentication service, as I describe it, does the signing after a
> request has been generated, yes. If a later proxy wants to shove some
> (authenticated) information into the request afterwards, that isn't possible
> unless is supplies a separate signed body.
> 
> 
>>If the gateway
>>does the translation, then in theory there would have to be
>>a trust relationship between the PSTN and the gateway. 
> 
> 
> There is always, in effect, a trust relationship between the PSTN and a
> gateway. The gateway is a node on the PSTN (whether it is a privileged node,
> like an SS7 gateway, or a user node, like a CAS gateway), and nodes have a
> certain defined trust relationship with the PSTN. I think the gateway is one
> of the better candidates to do ENUM, and possibly to perform the reverse
> operation (however that would work).
>  
> 
>>That won't work for an enterprise gateway, although I'm not
>>sure that's a practical problem, because if the gateway
>>translated, the PSTN is going to check that the number
>>the gateway asserted is one of the identities that loop
>>is allocated (PRIs have ranges).
>>
> 
> 
> Presumably, gateways shouldn't trust authentication services that might give
> them improper information. In fact, there are numerous restrictions
> surrounding what sorts of phone numbers should be sent over many sorts of
> ISUP trunks as well (as well as rules about when a CgPN must be present, as
> opposed to may be present). An proxy or user agent that supplies originating
> telephone numbers for SIP-to-PSTN calls should expect gateways to validate
> them, and there should be some way to accomodate cases in which the gateway
> cannot transmit these numbers to the PSTN, since it may be difficult for a
> proxy to determine what sort of gateway a request will ultimately land on
> (which is one of the reasons why proxies might not be the best place for
> synonym identities to be managed).
> 
> 
>>I don't see how ENUM is useful with identity assertion,
>>although it's clearly applicable to the proxy that
>>translates a SIP URI into a phone number or vice versa in
>>the Request URI.  
> 
> 
> It doesn't assert identity itself, certainly. The one place in which it is
> conceivably useful for identity assertion is that ENUM could be queried for
> a URI associated with the calling party's number in a PSTN-to-SIP call. This
> could be useful for a number of reasons - that URI could be stuck in a
> header to indicate a SIP URI for the end user that is more explicit or
> recognizable than their telephone number.
> 
> 
>>Brian
>>
>>
>>>-----Original Message-----
>>>From: Peterson, Jon [mailto:jon.peterson@neustar.biz]
>>>Sent: Tuesday, January 07, 2003 6:35 AM
>>>To: 'Rosen, Brian'; 'Drage, Keith (Keith)'; 'Henning Schulzrinne'
>>>Cc: 'sipping@ietf.org'
>>>Subject: RE: [Sipping] URIs for Gateways
>>>
>>>
>>>
>>>First, it is possible, with the long-term identity mechanism, 
>>>to assert two
>>>identities in an authenticated identity body. So, you could 
>>>have headers
>>>corresponding to a telephone number and a SIP URI of a 
>>>gateway or a user -
>>>it strikes me that a telephone number is a good Reply-To, 
>>>actually, when a
>>>call comes from a gateway (originating in the PSTN, say) and 
>>>the From header
>>>field contains a SIP URI for the gateway, perhaps including 
>>
>>some port
>>
>>>information. The identity that the gateway which handles a 
>>>PSTN-SIP call
>>>would assert needs to be its own, and recipients of calls 
>>>from gateways need
>>>to trust the telephone number provided by the gateway or not 
>>>accordingly
>>>(i.e. a signature from att.com vouching for such a request should be
>>>acceptable).
>>>
>>>Technologies like ENUM (when/where available) could enable 
>>
>>gateways to
>>
>>>convert originating telephone numbers into URIs. Of course, 
>>
>>a gateway
>>
>>>wouldn't be able to assert that identity to an intermediary 
>>
>>unless it
>>
>>>possessed credentials appropriate to that URI, which is unlikely.
>>>
>>>For outbound calls (SIP-PSTN), the gateway may or may not be 
>>>able to map
>>>(authenticated) SIP URIs representing originators to 
>>>appropriate telephone
>>>numbers via some sort of local tables as you suggested. If 
>>>not, might also
>>>pick a number from a pool, sure. The question of whether some 
>>>authentication
>>>service should be able to assert an originating telephone 
>>>number (in an
>>>authenticated identity body, say) that a gateway will use is 
>>>also a trust
>>>question - it is possible to put the tel URL in the AIB. If 
>>>the gateway has
>>>a reason to trust the authentication service, then certainly 
>>>it should send
>>>that number to the PSTN (when the protocol allows gateways 
>>
>>to supply a
>>
>>>number, like with ISUP or Q.931). The gateway would be very 
>>>ill advised to
>>>take just any authentication service's word on this matter, though. 
>>>
>>>The target of the calls for the PSTN should be identified 
>>>with a telephone
>>>number - at least, by the time the call arrives a gateway, 
>>>it's Request-URI
>>>should contain a tel URL or a SIP URI with a tel URL 
>>>component. Whether the
>>>originating UAC sets the To header field to a tel URL or a 
>>>subsequent proxy
>>>retargets the request doesn't seem to make much difference. 
>>>ENUM can also
>>>play a pretty obvious role here.
>>>
>>>Jon Peterson
>>>NeuStar, Inc.
>>>
>>>
>>>>-----Original Message-----
>>>>From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
>>>>Sent: Monday, January 06, 2003 1:22 PM
>>>>To: 'Peterson, Jon'; 'Drage, Keith (Keith)'; Rosen, 
>>>
>>Brian; 'Henning
>>
>>>>Schulzrinne'
>>>>Cc: 'sipping@ietf.org'
>>>>Subject: RE: [Sipping] URIs for Gateways
>>>>
>>>>
>>>>I agree with this.  I'm confused by those who seem to think that
>>>>P-Asserted-Identity is needed when the long term solution is
>>>>fully baked.  If the UA knows its identity, which seems
>>>>reasonable, then it can "assert" it, and have that assertion
>>>>validated by a trusted entity using cryptographic means.
>>>>That is the fundamental idea I get out of Jon's proposal.
>>>>The only circumstance where that won't work is where the
>>>>UA doesn't know its identity.  I don't see that as a problem
>>>>on any network I'm aware of, but ...... keep reading.
>>>>
>>>>I do think there is a problem which this whole thread talks about.
>>>>The basic reality is that many users of SIP UAs will have two
>>>>identities - a SIP URI and a telephone number.  It may be
>>>>necessary to assert both identities in one call, because the
>>>>originator of the call does not know which identity may be
>>>>needed.  There is no current header to do this.  I think that 
>>>>it is advantageous to have a proxy be able to assert the phone 
>>>>number.  Otherwise EVERY UA will have to be able to understand 
>>>>that two identities are possible, know them both by some 
>>>>unspecified means, and assert them in every call on every UA.  
>>>>This seems unreasonable.  I'm not sure that there is a reason
>>>>to have both identities validated, but there could be.
>>>>
>>>>Brian
>>>>
>>>>>-----Original Message-----
>>>>>From: Peterson, Jon [mailto:jon.peterson@neustar.biz]
>>>>>Sent: Monday, January 06, 2003 2:06 PM
>>>>>To: 'Drage, Keith (Keith)'; Rosen, Brian; 'Henning Schulzrinne'
>>>>>Cc: 'sipping@ietf.org'
>>>>>Subject: RE: [Sipping] URIs for Gateways
>>>>>
>>>>>
>>>>>
>>>>>RFC3325 was 'short-term' because it was achievable in the 
>>>>>short-term and has
>>>>>a more limited (but still useful) applicability. The 
>>>>>long-term identity
>>>>>solution must be a superset of the functionality of 
>>>>>short-term - it must
>>>>>address the short-term scope of applicability, but also 
>>>>>encompass general
>>>>>needs for network assertion (which SIP does have). 
>>>>>Accordingly, it takes
>>>>>longer to develop. At such a time as there is a workable 
>>>>>long-term solution,
>>>>>it would be pointless to allow both to be SIP standards 
>>>>>except as part of a
>>>>>transition plan. So in that sense, I disagree - one is a 
>>>>>short-term solution
>>>>>of the other.
>>>>>
>>>>>Jon Peterson
>>>>>NeuStar, Inc.
>>>>>
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Drage, Keith (Keith) [mailto:drage@lucent.com]
>>>>>>Sent: Friday, January 03, 2003 8:20 AM
>>>>>>To: Rosen, Brian; 'Henning Schulzrinne'
>>>>>>Cc: 'sipping@ietf.org'
>>>>>>Subject: RE: [Sipping] URIs for Gateways
>>>>>>
>>>>>>
>>>>>>Network asserted identity (RFC 3325) is the real network 
>>>>>>asserted identity. It is a P header not because it is 
>>>>>>preliminary, but because the whole idea of network assertion 
>>>>>>is not generally applicable to all SIP architectures. For RFC 
>>>>>>3325 a trust domain needs to exist between proxies that use 
>>>>>>the P-Asserted-Identity in order to guarantee the privacy, 
>>>>>>this does not exist in all SIP networks. In does in 3GPP and 
>>>>>>therefore 3GPP are using RFC 3325.
>>>>>>
>>>>>>If you want to let the 1et outbound proxy assert identity on 
>>>>>>your behalf then use RFC 3325. If you want to let application 
>>>>>>servers with whom you have a secure relationship assert your 
>>>>>>identity, then use Jon Petersons drafts, when they eventually 
>>>>>>become RFCs. 
>>>>>>
>>>>>>One is not a short term solution for the other.
>>>>>>
>>>>>>Keith
>>>>>>
>>>>>>Keith Drage
>>>>>>Lucent Technologies
>>>>>>Tel: +44 1793 776249
>>>>>>Email: drage@lucent.com 
>>>>>>
>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
>>>>>>>Sent: 02 January 2003 20:49
>>>>>>>To: 'Henning Schulzrinne'
>>>>>>>Cc: 'sipping@ietf.org'
>>>>>>>Subject: RE: [Sipping] URIs for Gateways
>>>>>>>
>>>>>>>
>>>>>>>Yeah, I actually thought of just allowing a display 
>>>>>>
>>>name in the
>>>
>>>>>>>Request URI and using that, but it seems so foolish to make 
>>>>>>
>>>>>>a change,
>>>>>>
>>>>>>>and have that change not be exactly what we needed.
>>>>>>>
>>>>>>>We could use NAI.  I suppose we could use a 
>>>>>>
>>>P-Asserted-Identity
>>>
>>>>>>>with a tel URI:  
>>>>>>>P-Asserted-Identity tel:+17247426826
>>>>>>>
>>>>>>>What do we do when the "real" NAI happens?
>>>>>>>
>>>>>>>Brian
>>>>>>>
>>>>>>>
>>>>>>>>-----Original Message-----
>>>>>>>>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
>>>>>>>>Sent: Thursday, January 02, 2003 3:10 PM
>>>>>>>>To: Rosen, Brian
>>>>>>>>Cc: 'sipping@ietf.org'
>>>>>>>>Subject: Re: [Sipping] URIs for Gateways
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>I'd like to get a new header for the calling 
>>>>>>>>
>>>party number on
>>>
>>>>>>>>>an outbound call.  That way, the translator can be 
>>>>>>>>
>>>>a proxy and
>>>>
>>>>>>>>>add the header.  I'd recommend that gateways allow 
>>>>>>>>
>>>>the number
>>>>
>>>>>>>>>to be in the From.   
>>>>>>>>
>>>>>>>>Generalized, you want something like the Request-URI 
>>>>>>>
>>>>>that can be 
>>>>>
>>>>>>>>modified or inserted. How about the NAI stuff?
>>>>>>>>
>>>>>>>
>>>>>>>_______________________________________________
>>>>>>>Sipping mailing list  
>>>>>>
>>>>>https://www1.ietf.org/mailman/listinfo/sipping
>>>>>
>>>>>>>This list is for NEW development of the application of SIP
>>>>>>>Use sip-implementors@cs.columbia.edu for questions on 
>>>>>>
>>>>current sip
>>>>
>>>>>>>Use sip@ietf.org for new developments of core SIP
>>>>>>>
>>>>>>
>>>>>>_______________________________________________
>>>>>>Sipping mailing list  
>>>>>
>>>>https://www1.ietf.org/mailman/listinfo/sipping
>>>>
>>>>>>This list is for NEW development of the application of SIP
>>>>>>Use sip-implementors@cs.columbia.edu for questions on 
>>>>>
>>>current sip
>>>
>>>>>>Use sip@ietf.org for new developments of core SIP
>>>>>>
>>>>>
>>>>>_______________________________________________
>>>>>Sipping mailing list  
>>>>
>>>https://www1.ietf.org/mailman/listinfo/sipping
>>>
>>>>>This list is for NEW development of the application of SIP
>>>>>Use sip-implementors@cs.columbia.edu for questions on 
>>>>
>>current sip
>>
>>>>>Use sip@ietf.org for new developments of core SIP
>>>>>
>>>>
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  9 00:26:33 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20454
	for <sipping-archive@odin.ietf.org>; Thu, 9 Jan 2003 00:26:33 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h095c5918604
	for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 00:38:05 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h095c5J18601
	for <sipping-web-archive@optimus.ietf.org>; Thu, 9 Jan 2003 00:38:05 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20446
	for <sipping-web-archive@ietf.org>; Thu, 9 Jan 2003 00:25:50 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h095ZbJ17906;
	Thu, 9 Jan 2003 00:35:37 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h095YLJ17854
	for <sipping@optimus.ietf.org>; Thu, 9 Jan 2003 00:34:21 -0500
Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20323
	for <sipping@ietf.org>; Thu, 9 Jan 2003 00:22:17 -0500 (EST)
Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32])
	by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h095PXFp021861
	for <sipping@ietf.org>; Wed, 8 Jan 2003 21:25:33 -0800 (PST)
Received: from fluffyw2k (dhcp-128-107-141-97.cisco.com [128.107.141.97])
	by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA)
	with ESMTP id HTL00004;
	Wed, 8 Jan 2003 21:26:06 -0800 (PST)
From: "Cullen Jennings" <fluffy@cisco.com>
To: <sipping@ietf.org>
Subject: RE: [Sipping] URIs for Gateways
Date: Wed, 8 Jan 2003 21:25:33 -0800
Message-ID: <002301c2b79f$882feb00$618d6b80@amer.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
In-Reply-To: <15A2739B7DAA624D8091C65981D7DA815EB501@stntexch2.va.neustar.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


We should roll it into the same work either way. 

> -----Original Message-----
> From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] 
> On Behalf Of Peterson, Jon
> Sent: Wednesday, January 08, 2003 2:32 PM
> To: 'Paul Kyzivat'; Rosen, Brian
> Cc: 'sipping@ietf.org'
> Subject: RE: [Sipping] URIs for Gateways
> 
> 
> 
> On the subject of a 'port' parameter, I agree this is best as 
> a tel URL parameter. In fact, I suggest that the trunk group 
> tel URL parameter currently under development in IPTEL might 
> be sufficient for expressing port information.
> 
> Jon Peterson
> NeuStar, Inc.
> 
> > -----Original Message-----
> > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> > Sent: Wednesday, January 08, 2003 12:38 PM
> > To: Rosen, Brian
> > Cc: 'sipping@ietf.org'
> > Subject: Re: [Sipping] URIs for Gateways
> > 
> > 
> > Brian,
> > 
> > A few initial comments. More later when I get time to think 
> about it.
> > 
> > - I'm not sure of the advisability of adding caller name to
> > the tel uri. 
> > If  you do it, I don't like that way. Would prefer a tel: 
> > parameter, as in
> >       tel:+14125551212;caller-name="Alice Toklas"
> > 
> > - I don't think the port should be a sip uri parameter. It is very
> > telephony oriented, so I think it is better as a tel: uri parameter.
> > 
> > 	Paul
> > 
> > Rosen, Brian wrote:
> > > After all of this, I propose the following:
> > > 
> > > 1. We add the possibility of a callerId string to a tel uri:
> > >    telephone-uri = "tel:" [callerIdName LWS] subscriber
> > >    callerIdName = quoted-string
> > > 
> > > 2. Gateways accept or send sip uris of the form:
> > >    sip:"Alice Toklas" 4125551212@gateway.atlanta.com;
> > user=phone; port=3
> > > or tel uris of the form:
> > >    tel:"Alice Toklas" +14125551212; port=3
> > > or "ordinary" sip uri's with extra information in a 
> separate header
> > > of the form:
> > >    <header> +14125551212; port=3
> > > 
> > > where <header> could be "P-Asserted-Identity", or it 
> could be a new 
> > > header we define for the purpose.
> > > 
> > > Then, we have the following possibilities:
> > > 
> > > SIP device to gateway (outgoing) call
> > >    To a phone number
> > >         use the phone number in the Request-URI & To:, probably
> > >         in a tel URI, or maybe phonenumber@localdomain; user=phone
> > > 
> > >         use normal sip URI in From:
> > >      
> > >         If a translator is available, it may assert the 
> phone number
> > >         for the identity in the From: using <header>
> > > 
> > >         proxy may rewrite the Request-URI in the form of
> > >         sip: phone@gateway;user=phone;port=portnum
> > >    
> > >    To a sip URI
> > >         use the sip uri in the Request-URI and To:
> > >         use normal sip URI in From:
> > > 
> > >         proxy rewrites Request-URI, due to forwarding behavior,
> > >         ENUM lookup, etc, resulting in a tel URI or a 
> user=phone sip
> > >         uri.  If necessary, a local incoming proxy can 
> rewrite it to
> > >         add the port parameter to the Request-URI based 
> on the From:
> > >     
> > >         If a translator is available, it may assert the 
> phone number
> > >         for the identity in the From: using the <header>
> > > 
> > > Gateway to SIP device (incoming call)
> > >    With mapping
> > >         use the mapped uri in the Request-URI & To:
> > >           
> > >         (optionally) supply called number using <header>
> > >         This might be needed when multiple called numbers
> > >         map to the same uri.
> > >         
> > >         use sip:"callerId" phone@gateway; port=portnum or
> > >         a tel: uri in From:
> > > 
> > >    Without mapping
> > >         use a provisioned (per port) URI, a tel uri with 
> the called 
> > >         number, or a sip uri with calledNumber@localdomain;
> > user=phone
> > >         in the Request-URI & To:.  Gateways should support all 3,
> > >         choice should be made by provisioning.
> > > 
> > >         use sip:"callerId" phone@gateway; port=portnum or tel
> > >         uri in From:
> > > 
> > >         proxy will rewrite the Request-URI with the 
> correct sip URI
> > >         associated with the called number
> > >   
> > > Brian
> > > _______________________________________________
> > > Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> > > This list 
> is for NEW development of the application of SIP Use 
> > > sip-implementors@cs.columbia.edu for questions on current sip Use 
> > > sip@ietf.org for new developments of core SIP
> > > 
> > 
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP Use 
> > sip-implementors@cs.columbia.edu for questions on current sip Use 
> > sip@ietf.org for new developments of core SIP
> > 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current 
> sip Use sip@ietf.org for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  9 00:30:53 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20514
	for <sipping-archive@odin.ietf.org>; Thu, 9 Jan 2003 00:30:53 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h095gPR18768
	for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 00:42:25 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h095gPJ18765
	for <sipping-web-archive@optimus.ietf.org>; Thu, 9 Jan 2003 00:42:25 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20500
	for <sipping-web-archive@ietf.org>; Thu, 9 Jan 2003 00:30:16 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h095e7J18694;
	Thu, 9 Jan 2003 00:40:07 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h095d2J18632
	for <sipping@optimus.ietf.org>; Thu, 9 Jan 2003 00:39:02 -0500
Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20470
	for <sipping@ietf.org>; Thu, 9 Jan 2003 00:26:59 -0500 (EST)
Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32])
	by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h095U9Fp023429;
	Wed, 8 Jan 2003 21:30:09 -0800 (PST)
Received: from fluffyw2k (dhcp-128-107-141-97.cisco.com [128.107.141.97])
	by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA)
	with ESMTP id HTL00072;
	Wed, 8 Jan 2003 21:30:42 -0800 (PST)
From: "Cullen Jennings" <fluffy@cisco.com>
To: "'Paul Kyzivat'" <pkyzivat@cisco.com>,
        "'Rosen, Brian'" <Brian.Rosen@marconi.com>
Cc: <sipping@ietf.org>
Subject: RE: [Sipping] URIs for Gateways
Date: Wed, 8 Jan 2003 21:30:09 -0800
Message-ID: <002401c2b7a0$2cc05dd0$618d6b80@amer.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
In-Reply-To: <3E1C8C28.4030802@cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


The port names a specific resource on the GW (similar to a trunk group)
so if it is in a SIP URL, I think it should be in the user portion. This
matches up perfectly with just defining it in the tel URL then let the
normal tel to sip translation rules apply to how looks in a SIP URL.


> -----Original Message-----
> From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] 
> On Behalf Of Paul Kyzivat
> Sent: Wednesday, January 08, 2003 12:38 PM
> To: Rosen, Brian
> Cc: 'sipping@ietf.org'
> Subject: Re: [Sipping] URIs for Gateways
> 
> 
> Brian,
> 
> A few initial comments. More later when I get time to think about it.
> 
> - I'm not sure of the advisability of adding caller name to 
> the tel uri. 
> If  you do it, I don't like that way. Would prefer a tel: 
> parameter, as in
>       tel:+14125551212;caller-name="Alice Toklas"
> 
> - I don't think the port should be a sip uri parameter. It is very 
> telephony oriented, so I think it is better as a tel: uri parameter.
> 
> 	Paul
> 
> Rosen, Brian wrote:
> > After all of this, I propose the following:
> > 
> > 1. We add the possibility of a callerId string to a tel uri:
> >    telephone-uri = "tel:" [callerIdName LWS] subscriber
> >    callerIdName = quoted-string
> > 
> > 2. Gateways accept or send sip uris of the form:
> >    sip:"Alice Toklas" 4125551212@gateway.atlanta.com; user=phone; 
> > port=3 or tel uris of the form:
> >    tel:"Alice Toklas" +14125551212; port=3
> > or "ordinary" sip uri's with extra information in a separate header
> > of the form:
> >    <header> +14125551212; port=3
> > 
> > where <header> could be "P-Asserted-Identity", or it could be a new 
> > header we define for the purpose.
> > 
> > Then, we have the following possibilities:
> > 
> > SIP device to gateway (outgoing) call
> >    To a phone number
> >         use the phone number in the Request-URI & To:, probably
> >         in a tel URI, or maybe phonenumber@localdomain; user=phone
> > 
> >         use normal sip URI in From:
> >      
> >         If a translator is available, it may assert the phone number
> >         for the identity in the From: using <header>
> > 
> >         proxy may rewrite the Request-URI in the form of
> >         sip: phone@gateway;user=phone;port=portnum
> >    
> >    To a sip URI
> >         use the sip uri in the Request-URI and To:
> >         use normal sip URI in From:
> > 
> >         proxy rewrites Request-URI, due to forwarding behavior,
> >         ENUM lookup, etc, resulting in a tel URI or a user=phone sip
> >         uri.  If necessary, a local incoming proxy can rewrite it to
> >         add the port parameter to the Request-URI based on the From:
> >     
> >         If a translator is available, it may assert the phone number
> >         for the identity in the From: using the <header>
> > 
> > Gateway to SIP device (incoming call)
> >    With mapping
> >         use the mapped uri in the Request-URI & To:
> >           
> >         (optionally) supply called number using <header>
> >         This might be needed when multiple called numbers
> >         map to the same uri.
> >         
> >         use sip:"callerId" phone@gateway; port=portnum or
> >         a tel: uri in From:
> > 
> >    Without mapping
> >         use a provisioned (per port) URI, a tel uri with the called 
> >         number, or a sip uri with calledNumber@localdomain; 
> user=phone
> >         in the Request-URI & To:.  Gateways should support all 3,
> >         choice should be made by provisioning.
> > 
> >         use sip:"callerId" phone@gateway; port=portnum or tel
> >         uri in From:
> > 
> >         proxy will rewrite the Request-URI with the correct sip URI
> >         associated with the called number
> >   
> > Brian
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP Use 
> > sip-implementors@cs.columbia.edu for questions on current sip Use 
> > sip@ietf.org for new developments of core SIP
> > 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current 
> sip Use sip@ietf.org for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  9 02:11:55 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02227
	for <sipping-archive@odin.ietf.org>; Thu, 9 Jan 2003 02:11:55 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h097NTo31768
	for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 02:23:29 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h097NTJ31765
	for <sipping-web-archive@optimus.ietf.org>; Thu, 9 Jan 2003 02:23:29 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02220
	for <sipping-web-archive@ietf.org>; Thu, 9 Jan 2003 02:11:11 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h097KvJ31676;
	Thu, 9 Jan 2003 02:20:57 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07DPJJ18931
	for <sipping@optimus.ietf.org>; Tue, 7 Jan 2003 08:25:19 -0500
Received: from kcmso2.proxy.att.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11672
	for <sipping@ietf.org>; Tue, 7 Jan 2003 08:14:03 -0500 (EST)
Received: from maillennium.att.com ([135.25.114.99])
	by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h07DHJYt007365
	for <sipping@ietf.org>; Tue, 7 Jan 2003 07:17:20 -0600 (CST)
Received: from fisherlatitude (<unknown.domain>[135.210.110.158])
          by maillennium.att.com (mailgw1) with SMTP
          id <20030107131651gw100ksckpe>; Tue, 7 Jan 2003 13:16:51 +0000
From: "Steve Fisher" <sfisher1@att.com>
To: "'Eric Burger'" <eburger@snowshore.com>
Cc: <sipping@ietf.org>
Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps?
Date: Tue, 7 Jan 2003 08:15:25 -0500
Message-ID: <000001c2b64e$d778fcd0$9e6ed287@fisherlatitude>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
In-Reply-To: <4A3384433CE2AB46A63468CB207E209D097BAF@zoe.office.snowshore.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Eric,

I've been thinking about your statement below...

> > If we say SIP for stimulus reporting, then the diagram you drew, 
> > with the implication that the signaling follows the signaling path, 
> > is what will occur.
> > 
> > Is this distinction important for you?  The design team did not come

> > to full agreement on which way to go.  Compelling arguments either 
> > way welcomed.

Could you possibly elaborate on how "SIP for stimulus reporting" would
work? Are you thinking of SUBSCRIBE/NOTIFY? Are you thinking of using
INFO? It's fairly clear from the KPML draft how HTTP would work, but SIP
was less clear to me...

Thanks!
Steve

-----Original Message-----
From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf
Of Eric Burger
Sent: Tuesday, December 17, 2002 5:18 PM
To: Don Stanwyck
Cc: sipping@ietf.org; Jain, Rajnish (Rajnish)
Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs
and apps?


Rajnish is 1000% correct in his interpretation.  Looking at the message
I can see how my statement isn't entirely clear.

I am on record in this and other fora that H.248 and J.162 are the
appropriate protocols for device control.  See my posts to the speechsc
list.  I should have a paste buffer with my "Don't use SIP for low-level
peripheral device control" rant.

When I said "It [the thing referenced as "softswitch" in Rajnish's
e-mail -- ewb] is not a media gateway controller" I meant it was not a
media gateway controller, e.g., a device control thing, which uses
device control protocols like H.248 and J.162.

Now it's my turn for interpreting Rajnish, instead of him interpreting
me :-)  I assumed that the "PSTN X" thing was a MG-MGC combination,
speaking SIP on the packet network side.  E.g., the MG-MGC interface was
a private matter, not of interest to the discussion.

Sorry for the confusion.

> -----Original Message-----
> From: Jain, Rajnish (Rajnish) [mailto:rajnishjain@lucent.com]
> Sent: Tuesday, December 17, 2002 4:02 PM
> To: 'Don Stanwyck'; Eric Burger; Jain, Rajnish (Rajnish)
> Cc: sipping@ietf.org; Twomey, Michael S (Michael)
> Subject: RE: [Sipping] Stimulus Signaling/Markup between
> complex SIP UAs
> and apps?
> 
> 
> Don,
> I don't think Eric implied controlling a MG from a Softswitch
> via SIP in his
> comment. That particular topic has come up in this forum many 
> times and as I 
> recall the conclusion has always been that SIP is not meant 
> for that. SIP is 
> a peer-to-peer to protocol not a master-slave protcol - 
> agreed. However this
> is completely orthogonal to using stimulus/markup signaling 
> in SIP.  I don't
> see how in-lining a KPML doc (e.g.) in a SIP message breaks 
> SIP paradigm. 
> 
> Eric,
> In general, I would like to propose an HTTP-free alternative
> for delivery of 
> stimulus signals, such as through in-lining of KPML. The 
> benefits of such an
> alternative in my mind are following:
> 
> - it would make it easier for SIP developers on embedded
> platforms to embrace 
>   markup/stimulus signaling that don't support HTTP currently
> 
> - it would facilitate close coordination between announcement
> play and DTMF
>   collection. Barge-in is a good example for that. The app 
> can delegate the  
>   job to stop announcement play at barge-in to the 
> Softswitch. As an aside,
>   the Softswitch in my previous figure is one w/ bizarre API 
> as you say :-)
> 
> Rajnish
> 
> -----Original Message-----
> From: Don Stanwyck [mailto:don@stanwyck.com]
> Sent: Tuesday, December 17, 2002 3:10 PM
> To: 'Eric Burger'; 'Jain, Rajnish (Rajnish)'
> Cc: sipping@ietf.org; 'Twomey, Michael S (Michael)'
> Subject: RE: [Sipping] Stimulus Signaling/Markup between
> complex SIP UAs
> and apps?
> 
> 
> RFC 3261, Section 2 reads:
> 
> //START QUOTE
> 
> SIP supports five facets of establishing and terminating
> multimedia communications:
>   - User location: determination of the end system to be
>     used for communication;
>   - User availability: determination of the willingness
>     of the called party to engage in communications;
>   - User capabilities: determination of the media and media
>     parameters to be used;
>   - Session setup: "ringing", establishment of session
>     parameters at both called and calling party;
>   - Session management: including transfer and termination
>     of sessions, modifying session parameters, and invoking
>     services.
> 
> SIP is not a vertically integrated communications system.
> SIP is rather
> a component that can be used with other IETF protocols to build a
> complete multimedia architecture.  Typically, these architectures will
> include protocols such as the Real-time Transport Protocol (RTP) (RFC
> 1889 [28]) for transporting real-time data and providing QoS feedback,
> the Real-Time streaming protocol (RTSP) (RFC 2326 [29]) for 
> controlling
> delivery of streaming media, the Media Gateway Control 
> Protocol (MEGACO)
> (RFC 3015 [30]) for controlling gateways to the Public Switched
> Telephone Network (PSTN), and the Session Description Protocol (SDP)
> (RFC 2327 [1]) for describing multimedia sessions.  Therefore, SIP
> should be used in conjunction with other protocols in order to provide
> complete services to the users.  However, the basic functionality and
> operation of SIP does not depend on any of these protocols.
> 
> //END QUOTE
> 
> I can't find any support in this definition of SIP for
> carrying stimulus
> signaling or for controling media gateways (comment 1 in Eric's
> comments).  SIP, as defined and approved by the IETF, is not 
> expected to
> do these kinds of things that other IETF protocols are designed to
> handle.
> 
> Let's try to keep SIP doing the things it is designed to do and does 
> well, and not try to make it into a protocol for doing everything 
> imaginable.  It is already in danger of becoming too difficult to 
> implement as the number of options and new headers grows.
> 
> Don Stanwyck
> 
> 
> 
> > -----Original Message-----
> > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]
> > On Behalf Of Eric Burger
> > Sent: Tuesday, December 17, 2002 12:12 PM
> > To: Jain, Rajnish (Rajnish)
> > Cc: sipping@ietf.org; Twomey, Michael S (Michael)
> > Subject: RE: [Sipping] Stimulus Signaling/Markup between 
> > complex SIP UAs and apps?
> > 
> > 
> > For timelines, I would suggest asking the work group chairs.
> > We're at their mercy :-)
> > 
> > Putting my ISC hat on, what is the Softswitch in your diagram?
> >   1. It is not a media gateway controller, as it talks to
> >      the gateway with SIP (right answer, by the way).
> >   2. Is it a Stateless Proxy, a'la the Routing Function
> >      in the ISC reference diagram?  If so, that works
> >      exactly as you want it to.  See below for more.
> >   3. Is it an application server, a'la dynamicsoft,
> >      Ubiquity, LongBoard, etc.?  If so, that also works
> >      exactly as you want it to.  See below for more.
> >   4. Is it some kind of statefull proxy, with a bizarre,
> >      proprietary API to the pre-paid application (e.g., 
> >      Parlay, JAIN, EXS, ...)?  If so, you are on your
> >      own.
> > 
> > If we say "HTTP only" for stimulus reporting, the PSTN
> > gateway must be a HTTP client.  The good news is the gateway 
> > can communicate directly with the pre-paid application.  That 
> > also means the pre-paid application needs to have a HTTP 
> > server.  Alternatively, if the "Softswitch" is really a 
> > telephony application server (case #3 above), then it 
> > probably already has HTTP server capability built-in.
> > 
> > If we say SIP for stimulus reporting, then the diagram you
> > drew, with the implication that the signaling follows the 
> > signaling path, is what will occur.
> > 
> > Is this distinction important for you?  The design team did
> > not come to full agreement on which way to go.  Compelling 
> > arguments either way welcomed.
> > 
> > 
> > > -----Original Message-----
> > > From: Jain, Rajnish (Rajnish) [mailto:rajnishjain@lucent.com]
> > > Sent: Friday, December 06, 2002 4:20 PM
> > > To: Eric Burger; Jain, Rajnish (Rajnish)
> > > Cc: sipping@ietf.org; Twomey, Michael S (Michael)
> > > Subject: RE: [Sipping] Stimulus Signaling/Markup between complex 
> > > SIP UAs and apps?
> > > 
> > > 
> > > Eric,
> > > 
> > > Thanks for your response. Would you be able to comment on the 
> > > timeline of when does the design team hope to accomplish the
> > > following:
> > > 
> > > - general acceptance of the stimulus signaling, KPML etc.
> > > - standardization of app interaction fwk, KPML into an RFC
> > > 
> > > Regarding an example of a PSTN switch that can be connected to a 
> > > pre-paid app over SIP-T, I don't know how much I can disclose in 
> > > front of this forum, but that is something being looked at by a 
> > > few telecom gear vendors in my understanding.
> > > 
> > > I wanted to bring your attention to SIP-T wrt to my
> > previous question.
> > > I believe your answer will remain the same but I just to
> wanted to
> > > re-iterate the question in different words this time,
> just to make
> > > sure we're communicating:
> > > 
> > > In the setup below:
> > >                                Pre-paid app
> > >                                    |
> > > POTS ---- PSTN X <---SIP-T---> Softswitch ----
> > >                                
> > >     
> > > .. you would think, application interaction framework concepts 
> > > such as stimulus signaling, user-inetrfaces and KPML etc. are 
> > > designed to work over the SIP-T i/f between packet-enabled PSTN 
> > > switch and a Softswitch. Wouldn't you?
> > > 
> > > Thanks,
> > > Rajnish
> > > 
> > > > -----Original Message----- From: Jain, Rajnish (Rajnish)
> > [mailto:rajnishjain@lucent.com]
> > > 
> > > The Application Interaction Framework draft talks about stimulus
> > > signaling as a way for SIP UAs to interact w/ SIP 
> applications. The
> > > draft suggests use of markup languages to allow
> > applications to manage
> > > local/remote user interfaces on SIP UAs.
> > > 
> > > While the draft exemplifies a UA's stimulus/markup interaction w/ 
> > > a pre-paid application server, it is not very clear to us if the 
> > > caller UA (instead of a subscriber end-point) can be a complex UA 
> > > such as the following:
> > > 
> > > - SIP (enabled) Gateway
> > 
> > Why not?  It does SIP.  It may do tone detection.
> > 
> > > - PSTN Switch w/ SIP-T interface
> > 
> > Why not?  It does SIP.  It may do tone detection.
> > 
> > > and does the draft recommend stimulus/markup signaling between 
> > > such complex/concentrated UAs (or apps) and SIP applications ?
> > 
> > The draft is silent on it.  If you manufacture media rich
> > gateways, you might say "of course".  If you manufacture 
> > media servers, you might say "you could if you wanted, but 
> > you would be better served if you didn't."  :-)
> > 
> > > In other words, does the stimulus signaling apply to following
> > > scenarios ?:
> > > 
> > > 1. The pre-paid caller is connected to a PSTN switch that has a 
> > > SIP-T interface to the pre-paid application.
> > 
> > Yes, so long as the PSTN switch is SIP-aware, able to parse
> > and execute KPML, and report using SIP (or, yuck, http).
> > 
> > Do you know of such a switch?
> >  
> > > 2. The pre-paid caller is connected to a PBX (SIP Gateway) over an

> > > ISDN i/f, which in turn is connected to the pre-paid app. over 
> > > normal SIP.
> > 
> > Same issues as for the PSTN switch.
> > 
> > > If yes, would the terms client-local and client-remote still be
> > > accurate, as the user here is a POTS/ISDN user? From the user's 
> > > perspective, the UI would be client-remote. But from 
> application's
> > > perspective the UI would be client-local (as the UI will be
> > on the PBX
> > > or PSTN switch both of which look like a UA to app server).
> > 
> > It is still client-local, as the gateway/switch/PBX is a
> > local proxy for the user.  If you used a media server in the 
> > IP network behind the gateway/switch/PBX to execute the KPML, 
> > then you would be cline-remote. 
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use sip-implementors@cs.columbia.edu for questions on current 
> > sip Use sip@ietf.org for new developments of core SIP
> > 
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip Use
sip@ietf.org for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  9 02:13:50 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02290
	for <sipping-archive@odin.ietf.org>; Thu, 9 Jan 2003 02:13:50 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h097POi31868
	for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 02:25:24 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h097POJ31865
	for <sipping-web-archive@optimus.ietf.org>; Thu, 9 Jan 2003 02:25:24 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02279
	for <sipping-web-archive@ietf.org>; Thu, 9 Jan 2003 02:13:01 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h097MnJ31753;
	Thu, 9 Jan 2003 02:22:49 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h080caJ31939
	for <sipping@optimus.ietf.org>; Tue, 7 Jan 2003 19:38:36 -0500
Received: from kcmso2.proxy.att.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05147
	for <sipping@ietf.org>; Tue, 7 Jan 2003 19:27:06 -0500 (EST)
Received: from maillennium.att.com ([135.25.114.99])
	by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h080UNYt013379
	for <sipping@ietf.org>; Tue, 7 Jan 2003 18:30:23 -0600 (CST)
Received: from fisherlatitude (<unknown.domain>[135.210.40.96])
          by maillennium.att.com (mailgw1) with SMTP
          id <20030108002954gw100ksh3ue>; Wed, 8 Jan 2003 00:29:54 +0000
From: "Steve Fisher" <sfisher1@att.com>
To: "'Eric Burger'" <eburger@snowshore.com>
Cc: <sipping@ietf.org>
Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps?
Date: Tue, 7 Jan 2003 19:28:28 -0500
Message-ID: <000801c2b6ac$dd919150$6028d287@fisherlatitude>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <4A3384433CE2AB46A63468CB207E209D24864B@zoe.office.snowshore.com>
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Eric, thanks for the quick response! Do you have a sense when the design
team will decide about SIP or HTTP reporting? Also, do you have any more
thoughts as to how the SIP version would work? 

Steve Fisher
Division Manager
AT&T Labs 

-----Original Message-----
From: Eric Burger [mailto:eburger@snowshore.com] 
Sent: Tuesday, January 07, 2003 3:00 PM
To: Steve Fisher
Cc: sipping@ietf.org
Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs
and apps?


To answer the question directly: 

KPML only works with HTTP reporting.  It would be a different language
for SIP reporting.  MSCML is an example of a language that uses SIP for
reporting.



To answer the SIP stimulus reporting question:

Done INFO in the past, not planning on it again :-)

NOTIFY is my leading contender, but a new method may be needed because
if you do a strict reading of NOTIFY, you might not want a NOTIFY
without a SUBSCRIBE.

Using SUBSCRIBE as a method of pushing KPML is out and out evil (I mean
wrong).  KPML changes the state of the UAS.  SUBSCRIBE is not supposed
to have any side-effects.



> -----Original Message-----
> From: Steve Fisher [mailto:sfisher1@att.com]
> Sent: Tuesday, January 07, 2003 8:15 AM
> To: Eric Burger
> Cc: sipping@ietf.org
> Subject: RE: [Sipping] Stimulus Signaling/Markup between
> complex SIP UAs
> and apps?
> 
> 
> Eric,
> 
> I've been thinking about your statement below...
> 
> > > If we say SIP for stimulus reporting, then the diagram you drew,
> > > with the implication that the signaling follows the 
> signaling path,
> > > is what will occur.
> > > 
> > > Is this distinction important for you?  The design team
> did not come
> 
> > > to full agreement on which way to go.  Compelling
> arguments either
> > > way welcomed.
> 
> Could you possibly elaborate on how "SIP for stimulus reporting" would

> work? Are you thinking of SUBSCRIBE/NOTIFY? Are you thinking of using 
> INFO? It's fairly clear from the KPML draft how HTTP would work, but 
> SIP was less clear to me...
> 
> Thanks!
> Steve
> 
> -----Original Message-----
> From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf

> Of Eric Burger
> Sent: Tuesday, December 17, 2002 5:18 PM
> To: Don Stanwyck
> Cc: sipping@ietf.org; Jain, Rajnish (Rajnish)
> Subject: RE: [Sipping] Stimulus Signaling/Markup between
> complex SIP UAs
> and apps?
> 
> 
> Rajnish is 1000% correct in his interpretation.  Looking at
> the message
> I can see how my statement isn't entirely clear.
> 
> I am on record in this and other fora that H.248 and J.162 are the 
> appropriate protocols for device control.  See my posts to the 
> speechsc list.  I should have a paste buffer with my "Don't use SIP
> for low-level
> peripheral device control" rant.
> 
> When I said "It [the thing referenced as "softswitch" in Rajnish's 
> e-mail -- ewb] is not a media gateway controller" I meant it was not a

> media gateway controller, e.g., a device control thing, which uses 
> device control protocols like H.248 and J.162.
> 
> Now it's my turn for interpreting Rajnish, instead of him interpreting

> me :-)  I assumed that the "PSTN X" thing was a MG-MGC combination, 
> speaking SIP on the packet network side.  E.g., the MG-MGC interface 
> was a private matter, not of interest to the discussion.
> 
> Sorry for the confusion.
> 
> > -----Original Message-----
> > From: Jain, Rajnish (Rajnish) [mailto:rajnishjain@lucent.com]
> > Sent: Tuesday, December 17, 2002 4:02 PM
> > To: 'Don Stanwyck'; Eric Burger; Jain, Rajnish (Rajnish)
> > Cc: sipping@ietf.org; Twomey, Michael S (Michael)
> > Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP

> > UAs and apps?
> > 
> > 
> > Don,
> > I don't think Eric implied controlling a MG from a Softswitch via 
> > SIP in his comment. That particular topic has come up in this forum 
> > many times and as I
> > recall the conclusion has always been that SIP is not meant 
> > for that. SIP is 
> > a peer-to-peer to protocol not a master-slave protcol - 
> > agreed. However this
> > is completely orthogonal to using stimulus/markup signaling 
> > in SIP.  I don't
> > see how in-lining a KPML doc (e.g.) in a SIP message breaks 
> > SIP paradigm. 
> > 
> > Eric,
> > In general, I would like to propose an HTTP-free alternative for 
> > delivery of stimulus signals, such as through in-lining of KPML. The
> > benefits of such an
> > alternative in my mind are following:
> > 
> > - it would make it easier for SIP developers on embedded platforms 
> > to embrace
> >   markup/stimulus signaling that don't support HTTP currently
> > 
> > - it would facilitate close coordination between announcement play 
> > and DTMF
> >   collection. Barge-in is a good example for that. The app
> > can delegate the  
> >   job to stop announcement play at barge-in to the 
> > Softswitch. As an aside,
> >   the Softswitch in my previous figure is one w/ bizarre API 
> > as you say :-)
> > 
> > Rajnish
> > 
> > -----Original Message-----
> > From: Don Stanwyck [mailto:don@stanwyck.com]
> > Sent: Tuesday, December 17, 2002 3:10 PM
> > To: 'Eric Burger'; 'Jain, Rajnish (Rajnish)'
> > Cc: sipping@ietf.org; 'Twomey, Michael S (Michael)'
> > Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP

> > UAs and apps?
> > 
> > 
> > RFC 3261, Section 2 reads:
> > 
> > //START QUOTE
> > 
> > SIP supports five facets of establishing and terminating multimedia 
> > communications:
> >   - User location: determination of the end system to be
> >     used for communication;
> >   - User availability: determination of the willingness
> >     of the called party to engage in communications;
> >   - User capabilities: determination of the media and media
> >     parameters to be used;
> >   - Session setup: "ringing", establishment of session
> >     parameters at both called and calling party;
> >   - Session management: including transfer and termination
> >     of sessions, modifying session parameters, and invoking
> >     services.
> > 
> > SIP is not a vertically integrated communications system. SIP is 
> > rather a component that can be used with other IETF protocols to 
> > build a complete multimedia architecture.  Typically, these
> architectures will
> > include protocols such as the Real-time Transport Protocol
> (RTP) (RFC
> > 1889 [28]) for transporting real-time data and providing
> QoS feedback,
> > the Real-Time streaming protocol (RTSP) (RFC 2326 [29]) for
> > controlling
> > delivery of streaming media, the Media Gateway Control 
> > Protocol (MEGACO)
> > (RFC 3015 [30]) for controlling gateways to the Public Switched
> > Telephone Network (PSTN), and the Session Description Protocol (SDP)
> > (RFC 2327 [1]) for describing multimedia sessions.  Therefore, SIP
> > should be used in conjunction with other protocols in order 
> to provide
> > complete services to the users.  However, the basic
> functionality and
> > operation of SIP does not depend on any of these protocols.
> > 
> > //END QUOTE
> > 
> > I can't find any support in this definition of SIP for carrying 
> > stimulus signaling or for controling media gateways (comment 1 in 
> > Eric's comments).  SIP, as defined and approved by the IETF, is not
> > expected to
> > do these kinds of things that other IETF protocols are designed to
> > handle.
> > 
> > Let's try to keep SIP doing the things it is designed to do
> and does
> > well, and not try to make it into a protocol for doing everything
> > imaginable.  It is already in danger of becoming too difficult to 
> > implement as the number of options and new headers grows.
> > 
> > Don Stanwyck
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On 
> > > Behalf Of Eric Burger
> > > Sent: Tuesday, December 17, 2002 12:12 PM
> > > To: Jain, Rajnish (Rajnish)
> > > Cc: sipping@ietf.org; Twomey, Michael S (Michael)
> > > Subject: RE: [Sipping] Stimulus Signaling/Markup between
> > > complex SIP UAs and apps?
> > > 
> > > 
> > > For timelines, I would suggest asking the work group chairs. We're

> > > at their mercy :-)
> > > 
> > > Putting my ISC hat on, what is the Softswitch in your diagram?
> > >   1. It is not a media gateway controller, as it talks to
> > >      the gateway with SIP (right answer, by the way).
> > >   2. Is it a Stateless Proxy, a'la the Routing Function
> > >      in the ISC reference diagram?  If so, that works
> > >      exactly as you want it to.  See below for more.
> > >   3. Is it an application server, a'la dynamicsoft,
> > >      Ubiquity, LongBoard, etc.?  If so, that also works
> > >      exactly as you want it to.  See below for more.
> > >   4. Is it some kind of statefull proxy, with a bizarre,
> > >      proprietary API to the pre-paid application (e.g., 
> > >      Parlay, JAIN, EXS, ...)?  If so, you are on your
> > >      own.
> > > 
> > > If we say "HTTP only" for stimulus reporting, the PSTN gateway 
> > > must be a HTTP client.  The good news is the gateway can 
> > > communicate directly with the pre-paid application.  That also 
> > > means the pre-paid application needs to have a HTTP server.  
> > > Alternatively, if the "Softswitch" is really a telephony 
> > > application server (case #3 above), then it probably already has 
> > > HTTP server capability built-in.
> > > 
> > > If we say SIP for stimulus reporting, then the diagram you drew, 
> > > with the implication that the signaling follows the signaling 
> > > path, is what will occur.
> > > 
> > > Is this distinction important for you?  The design team did not 
> > > come to full agreement on which way to go.  Compelling arguments 
> > > either way welcomed.
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Jain, Rajnish (Rajnish) [mailto:rajnishjain@lucent.com]
> > > > Sent: Friday, December 06, 2002 4:20 PM
> > > > To: Eric Burger; Jain, Rajnish (Rajnish)
> > > > Cc: sipping@ietf.org; Twomey, Michael S (Michael)
> > > > Subject: RE: [Sipping] Stimulus Signaling/Markup
> between complex
> > > > SIP UAs and apps?
> > > > 
> > > > 
> > > > Eric,
> > > > 
> > > > Thanks for your response. Would you be able to comment on the
> > > > timeline of when does the design team hope to accomplish the
> > > > following:
> > > > 
> > > > - general acceptance of the stimulus signaling, KPML etc.
> > > > - standardization of app interaction fwk, KPML into an RFC
> > > > 
> > > > Regarding an example of a PSTN switch that can be
> connected to a
> > > > pre-paid app over SIP-T, I don't know how much I can
> disclose in
> > > > front of this forum, but that is something being looked at by a
> > > > few telecom gear vendors in my understanding.
> > > > 
> > > > I wanted to bring your attention to SIP-T wrt to my
> > > previous question.
> > > > I believe your answer will remain the same but I just to
> > wanted to
> > > > re-iterate the question in different words this time,
> > just to make
> > > > sure we're communicating:
> > > > 
> > > > In the setup below:
> > > >                                Pre-paid app
> > > >                                    |
> > > > POTS ---- PSTN X <---SIP-T---> Softswitch ----
> > > >                                
> > > >     
> > > > .. you would think, application interaction framework concepts
> > > > such as stimulus signaling, user-inetrfaces and KPML etc. are 
> > > > designed to work over the SIP-T i/f between packet-enabled PSTN 
> > > > switch and a Softswitch. Wouldn't you?
> > > > 
> > > > Thanks,
> > > > Rajnish
> > > > 
> > > > > -----Original Message----- From: Jain, Rajnish (Rajnish)
> > > [mailto:rajnishjain@lucent.com]
> > > > 
> > > > The Application Interaction Framework draft talks about stimulus

> > > > signaling as a way for SIP UAs to interact w/ SIP
> > applications. The
> > > > draft suggests use of markup languages to allow
> > > applications to manage
> > > > local/remote user interfaces on SIP UAs.
> > > > 
> > > > While the draft exemplifies a UA's stimulus/markup
> interaction w/
> > > > a pre-paid application server, it is not very clear to
> us if the
> > > > caller UA (instead of a subscriber end-point) can be a
> complex UA
> > > > such as the following:
> > > > 
> > > > - SIP (enabled) Gateway
> > > 
> > > Why not?  It does SIP.  It may do tone detection.
> > > 
> > > > - PSTN Switch w/ SIP-T interface
> > > 
> > > Why not?  It does SIP.  It may do tone detection.
> > > 
> > > > and does the draft recommend stimulus/markup signaling between
> > > > such complex/concentrated UAs (or apps) and SIP applications ?
> > > 
> > > The draft is silent on it.  If you manufacture media rich 
> > > gateways, you might say "of course".  If you manufacture media 
> > > servers, you might say "you could if you wanted, but you would be 
> > > better served if you didn't."  :-)
> > > 
> > > > In other words, does the stimulus signaling apply to following 
> > > > scenarios ?:
> > > > 
> > > > 1. The pre-paid caller is connected to a PSTN switch that has a
> > > > SIP-T interface to the pre-paid application.
> > > 
> > > Yes, so long as the PSTN switch is SIP-aware, able to parse and 
> > > execute KPML, and report using SIP (or, yuck, http).
> > > 
> > > Do you know of such a switch?
> > >  
> > > > 2. The pre-paid caller is connected to a PBX (SIP
> Gateway) over an
> 
> > > > ISDN i/f, which in turn is connected to the pre-paid app. over
> > > > normal SIP.
> > > 
> > > Same issues as for the PSTN switch.
> > > 
> > > > If yes, would the terms client-local and client-remote still be 
> > > > accurate, as the user here is a POTS/ISDN user? From the user's 
> > > > perspective, the UI would be client-remote. But from
> > application's
> > > > perspective the UI would be client-local (as the UI will be
> > > on the PBX
> > > > or PSTN switch both of which look like a UA to app server).
> > > 
> > > It is still client-local, as the gateway/switch/PBX is a local 
> > > proxy for the user.  If you used a media server in the IP network 
> > > behind the gateway/switch/PBX to execute the KPML, then you would 
> > > be cline-remote. _______________________________________________
> > > Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> > > This list is for NEW development of the application of SIP Use 
> > > sip-implementors@cs.columbia.edu for questions on current sip Use 
> > > sip@ietf.org for new developments of core SIP
> > > 
> > 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP Use 
> sip-implementors@cs.columbia.edu for questions on current sip Use 
> sip@ietf.org for new developments of core SIP
> 
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  9 02:16:26 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02345
	for <sipping-archive@odin.ietf.org>; Thu, 9 Jan 2003 02:16:26 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h097S1R32427
	for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 02:28:01 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h097S0J32424
	for <sipping-web-archive@optimus.ietf.org>; Thu, 9 Jan 2003 02:28:00 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02334
	for <sipping-web-archive@ietf.org>; Thu, 9 Jan 2003 02:15:45 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h097OdJ31834;
	Thu, 9 Jan 2003 02:24:39 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08FhDJ30112
	for <sipping@optimus.ietf.org>; Wed, 8 Jan 2003 10:43:13 -0500
Received: from almso2.proxy.att.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22415
	for <sipping@ietf.org>; Wed, 8 Jan 2003 10:31:25 -0500 (EST)
Received: from maillennium.att.com ([135.25.114.99])
	by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h08FYXDG008924
	for <sipping@ietf.org>; Wed, 8 Jan 2003 10:34:33 -0500 (EST)
Received: from fisherlatitude (fisher-latitude.mt.att.com[135.91.66.75])
          by maillennium.att.com (mailgw1) with SMTP
          id <20030108153405gw100ksd7re>; Wed, 8 Jan 2003 15:34:05 +0000
From: "Steve Fisher" <sfisher1@att.com>
To: <hisham.khartabil@nokia.com>
Cc: <sipping@ietf.org>
Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps?
Date: Wed, 8 Jan 2003 10:32:34 -0500
Message-ID: <000201c2b72b$2aa88880$96f1fea9@fisherlatitude>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7FE70D2@esebe019.ntc.nokia.com>
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

I agree that KPML is a type of session description, and, in addition, is
something an application will likely want established at the beginning
of the dialog. Setting up the KPML in a SUBSCRIBE seems like it might
result in a race condition, where there would be some period of time in
which the "triggers" were not set.

Is it true that the current thinking for SIP Reporting is that the KPML
(or something like it) would be "inlined" in the SIP INVITE/OK/ACK
exchange, using a mechanism similar to that described in
draft-jennings-sip-app-info-00? Would this then establish a
subscription?

Steve

-----Original Message-----
From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] 
Sent: Wednesday, January 08, 2003 9:03 AM
To: rajnishjain@lucent.com; eburger@snowshore.com; sfisher1@att.com
Cc: sipping@ietf.org
Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs
and apps?


The body of a SUBSCRIBE should be used for things like filtering.
Something related to the subscription itself. Putting KMPL in the body
of SUBSCRIBE is considered as a form of tunnelling, IMO. We try to keep
a use of a certain SIP method, header, or whatever to a minimum,
preferably one.

Bodies of INVITEs typically carry information about the session. KPML, I
would consider, a type of session description.

Regards,
Hisham

> -----Original Message-----
> From: ext Jain, Rajnish (Rajnish) [mailto:rajnishjain@lucent.com]
> Sent: Wednesday, January 08, 2003 1:34 PM
> To: 'Eric Burger'; Steve Fisher
> Cc: sipping@ietf.org
> Subject: RE: [Sipping] Stimulus Signaling/Markup between
> complex SIP UAs
> and apps?
> 
> 
> Eric,
> Can you expand on why sending KPML w/in SUBSCRIBE is a bad
> idea? In other
> words, why inling KPML w/in INVITE is fine but not w/in SUBSCRIBE. 
> 
> A SUBSCRIBE message w/ inline KPML should be oblivious to UA
> session FSM.
> It's an orthogonal activity from UA's perspective. Upon 
> receipt of a KPML
> request (w/in SUBSCRIBE) the UA will attach a DSP for DTMF 
> collecion and
> report digits to app (via NOTIFY). This shouldn't change the 
> state of SIP
> session w/in UA.  
> 
> Rajnish
> 
> 
> -----Original Message-----
> From: Eric Burger [mailto:eburger@snowshore.com]
> Sent: Tuesday, January 07, 2003 3:00 PM
> To: Steve Fisher
> Cc: sipping@ietf.org
> Subject: RE: [Sipping] Stimulus Signaling/Markup between
> complex SIP UAs
> and apps?
> 
> 
> To answer the question directly:
> 
> KPML only works with HTTP reporting.  It would be a different
> language for SIP reporting.  MSCML is an example of a 
> language that uses SIP for reporting.
> 
> 
> 
> To answer the SIP stimulus reporting question:
> 
> Done INFO in the past, not planning on it again :-)
> 
> NOTIFY is my leading contender, but a new method may be
> needed because if you do a strict reading of NOTIFY, you 
> might not want a NOTIFY without a SUBSCRIBE.
> 
> Using SUBSCRIBE as a method of pushing KPML is out and out
> evil (I mean wrong).  KPML changes the state of the UAS.  
> SUBSCRIBE is not supposed to have any side-effects.
> 
> 
> 
> > -----Original Message-----
> > From: Steve Fisher [mailto:sfisher1@att.com]
> > Sent: Tuesday, January 07, 2003 8:15 AM
> > To: Eric Burger
> > Cc: sipping@ietf.org
> > Subject: RE: [Sipping] Stimulus Signaling/Markup between
> > complex SIP UAs
> > and apps?
> > 
> > 
> > Eric,
> > 
> > I've been thinking about your statement below...
> > 
> > > > If we say SIP for stimulus reporting, then the diagram
> you drew,
> > > > with the implication that the signaling follows the
> > signaling path,
> > > > is what will occur.
> > > > 
> > > > Is this distinction important for you?  The design team
> > did not come
> > 
> > > > to full agreement on which way to go.  Compelling
> > arguments either
> > > > way welcomed.
> > 
> > Could you possibly elaborate on how "SIP for stimulus
> reporting" would
> > work? Are you thinking of SUBSCRIBE/NOTIFY? Are you
> thinking of using
> > INFO? It's fairly clear from the KPML draft how HTTP would
> > work, but SIP
> > was less clear to me...
> > 
> > Thanks!
> > Steve
> > 
> > -----Original Message-----
> > From: sipping-admin@ietf.org
> [mailto:sipping-admin@ietf.org] On Behalf
> > Of Eric Burger
> > Sent: Tuesday, December 17, 2002 5:18 PM
> > To: Don Stanwyck
> > Cc: sipping@ietf.org; Jain, Rajnish (Rajnish)
> > Subject: RE: [Sipping] Stimulus Signaling/Markup between
> > complex SIP UAs
> > and apps?
> > 
> > 
> > Rajnish is 1000% correct in his interpretation.  Looking at
> > the message
> > I can see how my statement isn't entirely clear.
> > 
> > I am on record in this and other fora that H.248 and J.162 are the 
> > appropriate protocols for device control.  See my posts to the 
> > speechsc list.  I should have a paste buffer with my "Don't use SIP
> > for low-level
> > peripheral device control" rant.
> > 
> > When I said "It [the thing referenced as "softswitch" in Rajnish's 
> > e-mail -- ewb] is not a media gateway controller" I meant
> it was not a
> > media gateway controller, e.g., a device control thing, which uses 
> > device control protocols like H.248 and J.162.
> > 
> > Now it's my turn for interpreting Rajnish, instead of him
> interpreting
> > me :-)  I assumed that the "PSTN X" thing was a MG-MGC combination, 
> > speaking SIP on the packet network side.  E.g., the MG-MGC interface

> > was a private matter, not of interest to the discussion.
> > 
> > Sorry for the confusion.
> > 
> > > -----Original Message-----
> > > From: Jain, Rajnish (Rajnish) [mailto:rajnishjain@lucent.com]
> > > Sent: Tuesday, December 17, 2002 4:02 PM
> > > To: 'Don Stanwyck'; Eric Burger; Jain, Rajnish (Rajnish)
> > > Cc: sipping@ietf.org; Twomey, Michael S (Michael)
> > > Subject: RE: [Sipping] Stimulus Signaling/Markup between complex 
> > > SIP UAs and apps?
> > > 
> > > 
> > > Don,
> > > I don't think Eric implied controlling a MG from a Softswitch via 
> > > SIP in his comment. That particular topic has come up in this 
> > > forum many times and as I
> > > recall the conclusion has always been that SIP is not meant 
> > > for that. SIP is 
> > > a peer-to-peer to protocol not a master-slave protcol - 
> > > agreed. However this
> > > is completely orthogonal to using stimulus/markup signaling 
> > > in SIP.  I don't
> > > see how in-lining a KPML doc (e.g.) in a SIP message breaks 
> > > SIP paradigm. 
> > > 
> > > Eric,
> > > In general, I would like to propose an HTTP-free alternative for 
> > > delivery of stimulus signals, such as through in-lining of KPML. 
> > > The benefits of such an
> > > alternative in my mind are following:
> > > 
> > > - it would make it easier for SIP developers on embedded platforms

> > > to embrace
> > >   markup/stimulus signaling that don't support HTTP currently
> > > 
> > > - it would facilitate close coordination between announcement play

> > > and DTMF
> > >   collection. Barge-in is a good example for that. The app
> > > can delegate the  
> > >   job to stop announcement play at barge-in to the 
> > > Softswitch. As an aside,
> > >   the Softswitch in my previous figure is one w/ bizarre API 
> > > as you say :-)
> > > 
> > > Rajnish
> > > 
> > > -----Original Message-----
> > > From: Don Stanwyck [mailto:don@stanwyck.com]
> > > Sent: Tuesday, December 17, 2002 3:10 PM
> > > To: 'Eric Burger'; 'Jain, Rajnish (Rajnish)'
> > > Cc: sipping@ietf.org; 'Twomey, Michael S (Michael)'
> > > Subject: RE: [Sipping] Stimulus Signaling/Markup between complex 
> > > SIP UAs and apps?
> > > 
> > > 
> > > RFC 3261, Section 2 reads:
> > > 
> > > //START QUOTE
> > > 
> > > SIP supports five facets of establishing and terminating 
> > > multimedia communications:
> > >   - User location: determination of the end system to be
> > >     used for communication;
> > >   - User availability: determination of the willingness
> > >     of the called party to engage in communications;
> > >   - User capabilities: determination of the media and media
> > >     parameters to be used;
> > >   - Session setup: "ringing", establishment of session
> > >     parameters at both called and calling party;
> > >   - Session management: including transfer and termination
> > >     of sessions, modifying session parameters, and invoking
> > >     services.
> > > 
> > > SIP is not a vertically integrated communications system. SIP is 
> > > rather a component that can be used with other IETF protocols to 
> > > build a complete multimedia architecture.  Typically, these
> > architectures will
> > > include protocols such as the Real-time Transport Protocol
> > (RTP) (RFC
> > > 1889 [28]) for transporting real-time data and providing
> > QoS feedback,
> > > the Real-Time streaming protocol (RTSP) (RFC 2326 [29]) for
> > > controlling
> > > delivery of streaming media, the Media Gateway Control 
> > > Protocol (MEGACO)
> > > (RFC 3015 [30]) for controlling gateways to the Public Switched
> > > Telephone Network (PSTN), and the Session Description 
> Protocol (SDP)
> > > (RFC 2327 [1]) for describing multimedia sessions.  Therefore, SIP

> > > should be used in conjunction with other protocols in order
> > to provide
> > > complete services to the users.  However, the basic
> > functionality and
> > > operation of SIP does not depend on any of these protocols.
> > > 
> > > //END QUOTE
> > > 
> > > I can't find any support in this definition of SIP for carrying 
> > > stimulus signaling or for controling media gateways (comment 1 in 
> > > Eric's comments).  SIP, as defined and approved by the IETF, is 
> > > not expected to
> > > do these kinds of things that other IETF protocols are designed to
> > > handle.
> > > 
> > > Let's try to keep SIP doing the things it is designed to do
> > and does
> > > well, and not try to make it into a protocol for doing everything
> > > imaginable.  It is already in danger of becoming too difficult to 
> > > implement as the number of options and new headers grows.
> > > 
> > > Don Stanwyck
> > > 
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On 
> > > > Behalf Of Eric Burger
> > > > Sent: Tuesday, December 17, 2002 12:12 PM
> > > > To: Jain, Rajnish (Rajnish)
> > > > Cc: sipping@ietf.org; Twomey, Michael S (Michael)
> > > > Subject: RE: [Sipping] Stimulus Signaling/Markup between
> > > > complex SIP UAs and apps?
> > > > 
> > > > 
> > > > For timelines, I would suggest asking the work group chairs. 
> > > > We're at their mercy :-)
> > > > 
> > > > Putting my ISC hat on, what is the Softswitch in your diagram?
> > > >   1. It is not a media gateway controller, as it talks to
> > > >      the gateway with SIP (right answer, by the way).
> > > >   2. Is it a Stateless Proxy, a'la the Routing Function
> > > >      in the ISC reference diagram?  If so, that works
> > > >      exactly as you want it to.  See below for more.
> > > >   3. Is it an application server, a'la dynamicsoft,
> > > >      Ubiquity, LongBoard, etc.?  If so, that also works
> > > >      exactly as you want it to.  See below for more.
> > > >   4. Is it some kind of statefull proxy, with a bizarre,
> > > >      proprietary API to the pre-paid application (e.g., 
> > > >      Parlay, JAIN, EXS, ...)?  If so, you are on your
> > > >      own.
> > > > 
> > > > If we say "HTTP only" for stimulus reporting, the PSTN gateway 
> > > > must be a HTTP client.  The good news is the gateway can 
> > > > communicate directly with the pre-paid application.  That also 
> > > > means the pre-paid application needs to have a HTTP server.  
> > > > Alternatively, if the "Softswitch" is really a telephony 
> > > > application server (case #3 above), then it probably already has

> > > > HTTP server capability built-in.
> > > > 
> > > > If we say SIP for stimulus reporting, then the diagram you drew,

> > > > with the implication that the signaling follows the signaling 
> > > > path, is what will occur.
> > > > 
> > > > Is this distinction important for you?  The design team did not 
> > > > come to full agreement on which way to go.  Compelling arguments

> > > > either way welcomed.
> > > > 
> > > > 
> > > > > -----Original Message-----
> > > > > From: Jain, Rajnish (Rajnish) [mailto:rajnishjain@lucent.com]
> > > > > Sent: Friday, December 06, 2002 4:20 PM
> > > > > To: Eric Burger; Jain, Rajnish (Rajnish)
> > > > > Cc: sipping@ietf.org; Twomey, Michael S (Michael)
> > > > > Subject: RE: [Sipping] Stimulus Signaling/Markup
> > between complex
> > > > > SIP UAs and apps?
> > > > > 
> > > > > 
> > > > > Eric,
> > > > > 
> > > > > Thanks for your response. Would you be able to comment on the
> > > > > timeline of when does the design team hope to accomplish the
> > > > > following:
> > > > > 
> > > > > - general acceptance of the stimulus signaling, KPML etc.
> > > > > - standardization of app interaction fwk, KPML into an RFC
> > > > > 
> > > > > Regarding an example of a PSTN switch that can be
> > connected to a
> > > > > pre-paid app over SIP-T, I don't know how much I can
> > disclose in
> > > > > front of this forum, but that is something being
> looked at by a
> > > > > few telecom gear vendors in my understanding.
> > > > > 
> > > > > I wanted to bring your attention to SIP-T wrt to my
> > > > previous question.
> > > > > I believe your answer will remain the same but I just to
> > > wanted to
> > > > > re-iterate the question in different words this time,
> > > just to make
> > > > > sure we're communicating:
> > > > > 
> > > > > In the setup below:
> > > > >                                Pre-paid app
> > > > >                                    |
> > > > > POTS ---- PSTN X <---SIP-T---> Softswitch ----
> > > > >                                
> > > > >     
> > > > > .. you would think, application interaction framework
> concepts
> > > > > such as stimulus signaling, user-inetrfaces and KPML etc. are
> > > > > designed to work over the SIP-T i/f between 
> packet-enabled PSTN
> > > > > switch and a Softswitch. Wouldn't you?
> > > > > 
> > > > > Thanks,
> > > > > Rajnish
> > > > > 
> > > > > > -----Original Message----- From: Jain, Rajnish (Rajnish)
> > > > [mailto:rajnishjain@lucent.com]
> > > > > 
> > > > > The Application Interaction Framework draft talks
> about stimulus
> > > > > signaling as a way for SIP UAs to interact w/ SIP
> > > applications. The
> > > > > draft suggests use of markup languages to allow
> > > > applications to manage
> > > > > local/remote user interfaces on SIP UAs.
> > > > > 
> > > > > While the draft exemplifies a UA's stimulus/markup
> > interaction w/
> > > > > a pre-paid application server, it is not very clear to
> > us if the
> > > > > caller UA (instead of a subscriber end-point) can be a
> > complex UA
> > > > > such as the following:
> > > > > 
> > > > > - SIP (enabled) Gateway
> > > > 
> > > > Why not?  It does SIP.  It may do tone detection.
> > > > 
> > > > > - PSTN Switch w/ SIP-T interface
> > > > 
> > > > Why not?  It does SIP.  It may do tone detection.
> > > > 
> > > > > and does the draft recommend stimulus/markup
> signaling between
> > > > > such complex/concentrated UAs (or apps) and SIP applications ?
> > > > 
> > > > The draft is silent on it.  If you manufacture media rich 
> > > > gateways, you might say "of course".  If you manufacture media 
> > > > servers, you might say "you could if you wanted, but you would 
> > > > be better served if you didn't."  :-)
> > > > 
> > > > > In other words, does the stimulus signaling apply to following

> > > > > scenarios ?:
> > > > > 
> > > > > 1. The pre-paid caller is connected to a PSTN switch
> that has a
> > > > > SIP-T interface to the pre-paid application.
> > > > 
> > > > Yes, so long as the PSTN switch is SIP-aware, able to parse and 
> > > > execute KPML, and report using SIP (or, yuck, http).
> > > > 
> > > > Do you know of such a switch?
> > > >  
> > > > > 2. The pre-paid caller is connected to a PBX (SIP
> > Gateway) over an
> > 
> > > > > ISDN i/f, which in turn is connected to the pre-paid
> app. over
> > > > > normal SIP.
> > > > 
> > > > Same issues as for the PSTN switch.
> > > > 
> > > > > If yes, would the terms client-local and
> client-remote still be
> > > > > accurate, as the user here is a POTS/ISDN user? From
> the user's
> > > > > perspective, the UI would be client-remote. But from
> > > application's
> > > > > perspective the UI would be client-local (as the UI will be
> > > > on the PBX
> > > > > or PSTN switch both of which look like a UA to app server).
> > > > 
> > > > It is still client-local, as the gateway/switch/PBX is a local 
> > > > proxy for the user.  If you used a media server in the IP 
> > > > network behind the gateway/switch/PBX to execute the KPML, then 
> > > > you would be cline-remote. 
> > > > _______________________________________________
> > > > Sipping mailing list
> > https://www1.ietf.org/mailman/listinfo/sipping
> > > > This list is for NEW development of the application of SIP Use 
> > > > sip-implementors@cs.columbia.edu for questions on current sip 
> > > > Use sip@ietf.org for new developments of core SIP
> > > > 
> > > 
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP Use 
> > sip-implementors@cs.columbia.edu for questions on
> current sip Use
> > sip@ietf.org for new developments of core SIP
> > 
> > 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP Use 
> sip-implementors@cs.columbia.edu for questions on current sip Use 
> sip@ietf.org for new developments of core SIP 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP Use 
> sip-implementors@cs.columbia.edu for questions on current sip Use 
> sip@ietf.org for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  9 02:49:07 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02973
	for <sipping-archive@odin.ietf.org>; Thu, 9 Jan 2003 02:49:07 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0980g002316
	for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 03:00:42 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0980gJ02313
	for <sipping-web-archive@optimus.ietf.org>; Thu, 9 Jan 2003 03:00:42 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02968
	for <sipping-web-archive@ietf.org>; Thu, 9 Jan 2003 02:48:30 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h097wLJ02215;
	Thu, 9 Jan 2003 02:58:21 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h097vlJ02160
	for <sipping@optimus.ietf.org>; Thu, 9 Jan 2003 02:57:47 -0500
Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02953
	for <sipping@ietf.org>; Thu, 9 Jan 2003 02:45:40 -0500 (EST)
From: jh@lohi.eng.song.fi
Received: from harjus.eng.song.fi ([195.10.149.20])
	by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian))
	id 18WXQu-0003Vh-00; Thu, 09 Jan 2003 09:48:56 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15901.10600.528257.26668@harjus.eng.song.fi>
Date: Thu, 9 Jan 2003 09:48:56 +0200
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
Cc: "'sipping@ietf.org'" <sipping@ietf.org>
Subject: RE: [Sipping] URIs for Gateways
In-Reply-To: <313680C9A886D511A06000204840E1CF030B5CE2@whq-msgusr-02.pit.comms.marconi.com>
References: <313680C9A886D511A06000204840E1CF030B5CE2@whq-msgusr-02.pit.comms.marconi.com>
X-Mailer: VM 7.03 under Emacs 21.2.1
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

brian,

you can program your sip/ss7 gw whatever way you like to map phone
numbers and sip uris.  there is no need to standardize anything new now
that we already have asserted identity to place the phone number in case
the user is using a from uri which is either anonymous or does not
contain callers phone number.  the mappings themselves are a local
matter of your domain.

-- juha

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  9 07:13:59 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07637
	for <sipping-archive@odin.ietf.org>; Thu, 9 Jan 2003 07:13:59 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h09CPdl18796
	for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 07:25:39 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09CPcJ18793
	for <sipping-web-archive@optimus.ietf.org>; Thu, 9 Jan 2003 07:25:38 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07613
	for <sipping-web-archive@ietf.org>; Thu, 9 Jan 2003 07:12:55 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09CMfJ18689;
	Thu, 9 Jan 2003 07:22:41 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09CLcJ18612
	for <sipping@optimus.ietf.org>; Thu, 9 Jan 2003 07:21:39 -0500
Received: from igate2.vodafone.co.uk (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07569
	for <sipping@ietf.org>; Thu, 9 Jan 2003 07:09:24 -0500 (EST)
Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id MAA26538; Thu, 9 Jan 2003 12:12:38 GMT
Received: from putney.vfl.vodafone (putney [10.33.112.118])
	by mailguard3 (4.6.1.123) with ESMTP id ;
	Thu, 09 Jan 2003 12:16:42 GMT
Received: from ukwmxc01.vf-uk.internal.vodafone.com (UKWMXC01.vfl.vodafone [10.33.126.160]) by putney.vfl.vodafone with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id YL9AGRDS; Thu, 9 Jan 2003 12:11:10 -0000
Received: from ukwmxc04.vf-uk.internal.vodafone.com ([10.33.126.173]) by ukwmxc01.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.4453);
	 Thu, 9 Jan 2003 12:11:02 +0000
Received: from ukwmxm02.vf-uk.internal.vodafone.com ([10.33.126.242]) by ukwmxc04.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.4453);
	 Thu, 9 Jan 2003 12:11:02 +0000
content-class: urn:content-classes:message
Subject: RE: [Sipping] New -sos- draft (04)
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Thu, 9 Jan 2003 12:11:02 -0000
Message-ID: <B77796343B16E047B045999EC4460F0D236C51@UKWMXM02>
Thread-Topic: [Sipping] New -sos- draft (04)
Thread-Index: AcK18/qMaXCEjsrIQSiXUcpCd4sMFwB1mO5A
From: "Mills, Duncan, D, CND Tech Dev, VF UK" <Duncan.Mills@gb.vodafone.co.uk>
To: "Henning Schulzrinne" <hgs@cs.columbia.edu>, <sipping@ietf.org>
X-OriginalArrivalTime: 09 Jan 2003 12:11:02.0582 (UTC) FILETIME=[2D9C1D60:01C2B7D8]
MIME-Version: 1.0 (Generated by Clearswift ES version 4.6.1.122)
Content-Type: text/plain;	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h09CLeJ18614
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

Henning,

A very very minor comment in case you revise the draft again:

In section 3.2 you talk about 118 being an ambiguous number, i.e. a collision exists between a Japanese emergency number and a UK directory services number.  I think it is actually Finland that uses 118 as a directory services number, not the UK.

Another well known collision exists for 192 which is currently one of the UK's directory services number and is also an emergency number in Brazil.

Regards,

Duncan





-----Original Message-----
From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
Sent: 07 January 2003 02:13
To: 'sipping@ietf.org'
Subject: [Sipping] New -sos- draft (04)


http://www.cs.columbia.edu/sip/drafts/draft-schulzrinne-sipping-sos-04.txt

will be submitted shortly, hopefully reflecting the comments received. 
Additional comments are most welcome.

Henning

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  9 07:50:50 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08258
	for <sipping-archive@odin.ietf.org>; Thu, 9 Jan 2003 07:50:50 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h09D2V020782
	for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 08:02:31 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09D2VJ20779
	for <sipping-web-archive@optimus.ietf.org>; Thu, 9 Jan 2003 08:02:31 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08193
	for <sipping-web-archive@ietf.org>; Thu, 9 Jan 2003 07:49:41 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09CxGJ20600;
	Thu, 9 Jan 2003 07:59:16 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09CvdJ20491
	for <sipping@optimus.ietf.org>; Thu, 9 Jan 2003 07:57:39 -0500
Received: from mtiwmhc11.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08092
	for <sipping@ietf.org>; Thu, 9 Jan 2003 07:45:27 -0500 (EST)
Received: from cs.columbia.edu ([12.92.125.222])
          by mtiwmhc11.worldnet.att.net
          (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP
          id <20030109124842.FRKY9286.mtiwmhc11.worldnet.att.net@cs.columbia.edu>;
          Thu, 9 Jan 2003 12:48:42 +0000
Message-ID: <3E1D6F18.1000506@cs.columbia.edu>
Date: Thu, 09 Jan 2003 07:46:16 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Mills, Duncan, D, CND Tech Dev, VF UK" <Duncan.Mills@gb.vodafone.co.uk>
CC: sipping@ietf.org
Subject: Re: [Sipping] New -sos- draft (04)
References: <B77796343B16E047B045999EC4460F0D236C51@UKWMXM02>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

Mills, Duncan, D, CND Tech Dev, VF UK wrote:
 > Henning,
 >
 > A very very minor comment in case you revise the draft again:
 >
 > In section 3.2 you talk about 118 being an ambiguous number, i.e. a
 > collision exists between a Japanese emergency number and a UK
 > directory services number.  I think it is actually Finland that uses
 > 118 as a directory services number, not the UK.

Thanks for catching this. I had been confused by the new 118XXX numbers 
in the UK; see 
http://www.oftel.gov.uk/publications/consumer/2002/dq1202.htm. These 
118XXX numbers would obviously not collide.

 >
 > Another well known collision exists for 192 which is currently one of
 > the UK's directory services number and is also an emergency number in
 > Brazil.

Apparently, according to the Oftel page above, this number is to be 
withdrawn. ("After the last weekend in August 2003 the existing DQ 
numbers such as 192 will no longer work – only the 118 numbers will be 
available.") Fortunately, 192 isn't on the list of 'default' emergency 
numbers.


 >
 > Regards,
 >
 > Duncan
 >
 >
 >
 >
 >
 > -----Original Message----- From: Henning Schulzrinne
 > [mailto:hgs@cs.columbia.edu] Sent: 07 January 2003 02:13 To:
 > 'sipping@ietf.org' Subject: [Sipping] New -sos- draft (04)
 >
 >
 > 
http://www.cs.columbia.edu/sip/drafts/draft-schulzrinne-sipping-sos-04.txt
 >
 >
 > will be submitted shortly, hopefully reflecting the comments
 > received. Additional comments are most welcome.
 >
 > Henning
 >
 > _______________________________________________ Sipping mailing list
 > https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW
 > development of the application of SIP Use
 > sip-implementors@cs.columbia.edu for questions on current sip Use
 > sip@ietf.org for new developments of core SIP
 > _______________________________________________ Sipping mailing list
 > https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW
 > development of the application of SIP Use
 > sip-implementors@cs.columbia.edu for questions on current sip Use
 > sip@ietf.org for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  9 09:18:01 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10562
	for <sipping-archive@odin.ietf.org>; Thu, 9 Jan 2003 09:18:00 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h09ETiM25820
	for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 09:29:44 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09ETiJ25817
	for <sipping-web-archive@optimus.ietf.org>; Thu, 9 Jan 2003 09:29:44 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10543
	for <sipping-web-archive@ietf.org>; Thu, 9 Jan 2003 09:17:29 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09ESSJ25759;
	Thu, 9 Jan 2003 09:28:28 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09EQpJ25669
	for <sipping@optimus.ietf.org>; Thu, 9 Jan 2003 09:26:51 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10318;
	Thu, 9 Jan 2003 09:14:37 -0500 (EST)
Message-Id: <200301091414.JAA10318@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: sip@ietf.org, sipping@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Thu, 09 Jan 2003 09:14:37 -0500
Subject: [Sipping] I-D ACTION:draft-miller-sip-tcap-00.txt
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Carrying TCAP in SIP Messages (SIP-TCAP)
	Author(s)	: F. Miller et al.
	Filename	: draft-miller-sip-tcap-00.txt
	Pages		: 0
	Date		: 2003-1-8
	
SIP-TCAP is a mechanism by which an XML representation of TCAP
messages can be transported in the body of SIP INFO messages.  This
mechanism can be used to allow SIP elements to access features
implemented by PSTN equipment without having to implement the binary
TCAP protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-miller-sip-tcap-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-miller-sip-tcap-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-miller-sip-tcap-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-1-9092045.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-miller-sip-tcap-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-miller-sip-tcap-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-1-9092045.I-D@ietf.org>

--OtherAccess--

--NextPart--


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  9 09:24:34 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11033
	for <sipping-archive@odin.ietf.org>; Thu, 9 Jan 2003 09:24:34 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h09EaIw26112
	for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 09:36:18 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09EaHJ26109
	for <sipping-web-archive@optimus.ietf.org>; Thu, 9 Jan 2003 09:36:17 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10918
	for <sipping-web-archive@ietf.org>; Thu, 9 Jan 2003 09:24:03 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09EZ4J26019;
	Thu, 9 Jan 2003 09:35:04 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09EYHJ25972
	for <sipping@optimus.ietf.org>; Thu, 9 Jan 2003 09:34:17 -0500
Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10613
	for <sipping@ietf.org>; Thu, 9 Jan 2003 09:22:03 -0500 (EST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA21058;
	Thu, 9 Jan 2003 09:25:19 -0500 (EST)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA06508;
	Thu, 9 Jan 2003 09:25:19 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <ZVACMHSW>; Thu, 9 Jan 2003 09:25:18 -0500
Message-ID: <313680C9A886D511A06000204840E1CF030B5CEC@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Paul Kyzivat'" <pkyzivat@cisco.com>
Cc: "'sipping@ietf.org'" <sipping@ietf.org>
Subject: RE: [Sipping] URIs for Gateways
Date: Thu, 9 Jan 2003 09:25:18 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

> - I'm not sure of the advisability of adding caller name to 
> the tel uri. 
> If  you do it, I don't like that way. Would prefer a tel: 
> parameter, as in
>       tel:+14125551212;caller-name="Alice Toklas"
I don't see that it matters much at all.  I can deal with either

> 
> - I don't think the port should be a sip uri parameter. It is very 
> telephony oriented, so I think it is better as a tel: uri parameter.
It's often the case that routing decisions on which gateway gets a
call is made prior to the next-to-last proxy.  To make that work, you
have to rewrite the Request-URI to a form of phonenumber@gateway
so that subsequent proxies route correctly.  Therefore, I think you
need the parameter in both

Brian 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  9 09:52:52 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13187
	for <sipping-archive@odin.ietf.org>; Thu, 9 Jan 2003 09:52:51 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h09F4aA28578
	for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 10:04:36 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09F4aJ28575
	for <sipping-web-archive@optimus.ietf.org>; Thu, 9 Jan 2003 10:04:36 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13150
	for <sipping-web-archive@ietf.org>; Thu, 9 Jan 2003 09:52:20 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09F3AJ28510;
	Thu, 9 Jan 2003 10:03:10 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09F2TJ28425
	for <sipping@optimus.ietf.org>; Thu, 9 Jan 2003 10:02:29 -0500
Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13078
	for <sipping@ietf.org>; Thu, 9 Jan 2003 09:50:13 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h09Es7YK019363
	for <sipping@ietf.org>; Thu, 9 Jan 2003 09:54:08 -0500 (EST)
Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAX59874;
	Thu, 9 Jan 2003 09:58:27 -0500 (EST)
Message-ID: <3E1D8CE5.6050308@cisco.com>
Date: Thu, 09 Jan 2003 09:53:25 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "'sipping@ietf.org'" <sipping@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

I have a few comments about draft-schulzrinne-sipping-sos-04.txt.
(I haven't been following this work very closely, so perhaps some of 
these pertain to things that were in earlier drafts.)

I must say, these are really messy problems, so I am glad you are 
working on them.

Section 3.2 says:

    ... a UAC MAY use a "tel" URI [3,4] without phone-context, such as

    tel:911
    tel:112

The latest and greatest definition of the tel: uri that I can find is 
draft-antti-rfc2806bis-07.txt. According to that, the above tel: uris 
are syntactically incorrect. Either the number must be global or else it 
must contain a phone-context parameter.

Are there plans to change the definition of the tel uri, or is this 
language going to change?

In the case of a UAC that is using a local outbound proxy, is it 
required that the UAC specifically recognize these strings and deliver 
them to the proxy, or is it sufficient for it to deliver any and all 
dialed digit strings to the proxy as tel uris without attempting to 
recognize them itself? Is it sufficient to determine that the dialed 
number is complete by timeout on the input rather than by recognition?

Section 5 specifies that the UAC should insert location information into 
emergency calls. However, presumably location information should in 
general not be placed in non-emergency calls, so it is important that 
the UAC realize it is making an emergency call. In the case of dialed 
digit strings, it may only be the outbound proxy that can determine if 
the call is an emergency call. One way to handle this would be for the 
local outbound proxy to redirect requests to tel: emergency numbers to 
the corresponding sip:sos number. Then the UAC would be able to 
positively determine this is an emergency call and include the location 
information.

Section 9 says:

    We propose a new DHCP option that enumerates the valid local
    emergency identifiers, as a list of "tel", "sip" or "sips" URIs.

This doesn't seem sufficient. Most phone-like devices have provision for 
entering primarily sequences of digits, not tel: uris. It is up to the 
phone to translate a digit sequence into a valid uri. In general this 
requires some sort of dial plan. Without the dial plan, the phone may 
well not be able to generate anything that matches one of the specified 
tel uris.

	Paul

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  9 10:03:02 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13618
	for <sipping-archive@odin.ietf.org>; Thu, 9 Jan 2003 10:03:02 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h09FElM29668
	for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 10:14:47 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FElJ29665
	for <sipping-web-archive@optimus.ietf.org>; Thu, 9 Jan 2003 10:14:47 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13597
	for <sipping-web-archive@ietf.org>; Thu, 9 Jan 2003 10:02:30 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FDXJ29617;
	Thu, 9 Jan 2003 10:13:33 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FBgJ29537
	for <sipping@optimus.ietf.org>; Thu, 9 Jan 2003 10:11:42 -0500
Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13395
	for <sipping@ietf.org>; Thu, 9 Jan 2003 09:59:26 -0500 (EST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA23798;
	Thu, 9 Jan 2003 10:02:42 -0500 (EST)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA13128;
	Thu, 9 Jan 2003 10:02:39 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <ZVACMJ1Q>; Thu, 9 Jan 2003 10:02:39 -0500
Message-ID: <313680C9A886D511A06000204840E1CF030B5CED@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Peterson, Jon'" <jon.peterson@neustar.biz>,
        "'Drage, Keith (Keith)'"
	 <drage@lucent.com>,
        "'Henning Schulzrinne'" <hgs@cs.columbia.edu>
Cc: "'sipping@ietf.org'" <sipping@ietf.org>
Subject: RE: [Sipping] URIs for Gateways
Date: Thu, 9 Jan 2003 10:02:38 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

Note below

> What I suggested was that the From header hold the URI of the 
> gateway - not
> the 'real' SIP URI of the user - for PSTN-to-SIP calls. The 
> From address in
> this instance is not the address to which you should reply if 
> you want to
> reach the initiator of the session later. The tel URL of that 
> user is in
> fact the URI to which you should reply. I think this is a 
> good place to put
> it for this case, and it doesn't warp the Reply-To header in 
> any way that I
> can see. This is completely unrelated to where one would put 
> the 'real' SIP
> URI of the user.
I see how it works in this case, but only if the UA knows both identities.
In some cases it doesn't now, but I think we might reasonably ask
whether it should (ie the BCP I propose could state that gateways
should know the telephone number it is connected to, and fill in
From and Reply To as you suggest).  We want to build systems where
a proxy knows this, and doesn't rely on the gateway.  Basically, we
have ONE place that maintains the phone-number-to-user and phone-number-
to-port-on-gateway information, and all tel URIs are routed through
that proxy.  It adds mappings and decides on which gateway will get
the call.  UAs don't know the mapping, gateways don't know the mapping,
only the one proxy knows.  We now have mechanisms that attempt to
keep gateway mapping systems accurate from the one database.  It takes 
vendor specific code in the proxy that knows how to manipulate the 
management port of each gateway in order to maintain the mappings.
That's not a good system design, even if it does work.

> 
> > It also has a serious problem that a proxy can't add it.
> 
> I think you mean that you want the proxy to be able to add a telephone
> number to a request for a SIP-to-PSTN call, or maybe to add a SIP URI
> representing the originating user to a request for a PSTN-to-SIP call
> (though this latter one is difficult - how would a user authenticate
> themselves to an auth service through a PSTN gateway?). I agree that
> Reply-To is not a good candidate for this usage - this is 
> where it has been
> argued that P-Asserted-Identity is a good candidate.
Yes, you see what I mean.  Yes P-A-I would work, although this use
does not meet the definition of P-A-I.  I'm also bothered that we use
two different headers for what I think is the same thing (holding both
a sip URI and a tel URI in the sip message for the "From" identity).

> 
> There are some minor issues with this (such as how a proxy 
> knows when and
> why to add identities, and how authentication for particular 
> identifies is
> managed), but I think that if a proxy asserts an identity, it 
> can and should
> use the identity mechanisms we've already defined, which were designed
> specifically with proxies in mind. However, there are some 
> reasons to ask
> whether or not proxies are always the best entities to decide 
> when synonym
> identities should be added to a request.
I agree that authentication in this case is a little tricky, but
I don't think it's very hard.  

> 
> > One of the requirements I have is that a proxy be able to
> > do the translation.  Not every gateway can hold all the tables
> > required for this kind of translation, and I don't think
> > we want to force every gateway to have the tables.
> > 
> 
> The whole issue of who should do 'translation' by various 
> entities is a
> little problematic, and ultimately this problem should be 
> separable from the
> selection of the headers we might use to express the results 
> of translation.
> Personally, I think ENUM is the right way to do telephone 
> number to URI
> translations - however, it is not servicable for the reverse, 
> for URI to
> telephone number translations. Having some kind of 'reverse 
> ENUM' for this
> purpose has been the subject of much speculation in ENUM 
> circles, but it
> currently is not well understood how it would work.
This is only true for Service Provider gateways.  It is not true
for enterprise gateways.  You would not want to use the currently
defined ENUM, because it would require that every enterprise
publish their internal mappings in the global ENUM DNS.  That
is not acceptable, and there are no mechanisms to do that (it
implies that, for example, an enterprise tells it's SP what the
SIP URI associated with each extension is).

> 
> ENUM is best performed by the initiator of the session, rather than an
> intermediary, for various reasons that are enumerated in 
> sipping-e164-02.
> Therefore, for PSTN-to-SIP calls, I think the PSTN gateway is 
> the right
> place to do an ENUM query. This does not require the gateway 
> to have any
> tables, or what have you. Intermediaries can also query ENUM 
> and apply the
> results to a message, even if it is sub-optimal for them to do so.
When ENUM is used, I agree, best at the gateway, less optimal in
an intermediary (proxy).  

> 
> > I think your proposals on identity will not work unless
> > the signer can be a proxy which later in the routing
> > than my proxy that does the translation.  
> 
> Well, an authentication service, as I describe it, does the 
> signing after a
> request has been generated, yes. If a later proxy wants to shove some
> (authenticated) information into the request afterwards, that 
> isn't possible
> unless is supplies a separate signed body.
It would be ugly, but possible, for an authentication to be performed
first on From/To/Reply-To and then subsequently on P-A-I. 
The idea of authenticating cryptographically the P-A-I header 
amuses me.

> 
> > If the gateway
> > does the translation, then in theory there would have to be
> > a trust relationship between the PSTN and the gateway. 
> 
> There is always, in effect, a trust relationship between the 
> PSTN and a
> gateway. The gateway is a node on the PSTN (whether it is a 
> privileged node,
> like an SS7 gateway, or a user node, like a CAS gateway), and 
> nodes have a
> certain defined trust relationship with the PSTN. I think the 
> gateway is one
> of the better candidates to do ENUM, and possibly to perform 
> the reverse
> operation (however that would work).
Do SPs really trust CAS gateways?  I didn't think it's true, 
although I don't know what actually happens if the gateway
supplies a calling number that is not one of it's assigned DNs.
I'm pretty sure it's NOT true of PRI gateways, but don't really
know.  I don't think that it matters for this discussion.

See above for routing issues that argue against the gateway doing
the mapping, at least for an enterprise system.

>  
> > That won't work for an enterprise gateway, although I'm not
> > sure that's a practical problem, because if the gateway
> > translated, the PSTN is going to check that the number
> > the gateway asserted is one of the identities that loop
> > is allocated (PRIs have ranges).
> > 
> 
> Presumably, gateways shouldn't trust authentication services 
> that might give
> them improper information. In fact, there are numerous restrictions
> surrounding what sorts of phone numbers should be sent over 
> many sorts of
> ISUP trunks as well (as well as rules about when a CgPN must 
> be present, as
> opposed to may be present). An proxy or user agent that 
> supplies originating
> telephone numbers for SIP-to-PSTN calls should expect 
> gateways to validate
> them, and there should be some way to accomodate cases in 
> which the gateway
> cannot transmit these numbers to the PSTN, since it may be 
> difficult for a
> proxy to determine what sort of gateway a request will 
> ultimately land on
> (which is one of the reasons why proxies might not be the 
> best place for
> synonym identities to be managed).
> 
> > I don't see how ENUM is useful with identity assertion,
> > although it's clearly applicable to the proxy that
> > translates a SIP URI into a phone number or vice versa in
> > the Request URI.  
> 
> It doesn't assert identity itself, certainly. The one place 
> in which it is
> conceivably useful for identity assertion is that ENUM could 
> be queried for
> a URI associated with the calling party's number in a 
> PSTN-to-SIP call. This
> could be useful for a number of reasons - that URI could be stuck in a
> header to indicate a SIP URI for the end user that is more explicit or
> recognizable than their telephone number.
Agree.  This could be useful.  What header?

> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  9 10:04:39 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13657
	for <sipping-archive@odin.ietf.org>; Thu, 9 Jan 2003 10:04:39 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h09FGOq29752
	for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 10:16:24 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FGOJ29749
	for <sipping-web-archive@optimus.ietf.org>; Thu, 9 Jan 2003 10:16:24 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13646
	for <sipping-web-archive@ietf.org>; Thu, 9 Jan 2003 10:03:54 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FF4J29711;
	Thu, 9 Jan 2003 10:15:04 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FEhJ29661
	for <sipping@optimus.ietf.org>; Thu, 9 Jan 2003 10:14:43 -0500
Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13592
	for <sipping@ietf.org>; Thu, 9 Jan 2003 10:02:27 -0500 (EST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA23977;
	Thu, 9 Jan 2003 10:05:43 -0500 (EST)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA14170;
	Thu, 9 Jan 2003 10:05:43 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <ZVACMJ3Y>; Thu, 9 Jan 2003 10:05:43 -0500
Message-ID: <313680C9A886D511A06000204840E1CF030B5CEE@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Cullen Jennings'" <fluffy@cisco.com>,
        "'Paul Kyzivat'"
	 <pkyzivat@cisco.com>
Cc: sipping@ietf.org
Subject: RE: [Sipping] URIs for Gateways
Date: Thu, 9 Jan 2003 10:05:42 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

I don't think this works if I'm understanding you

I have a tel uri like tel:+14125551212.  I translate that
to sip:14125551212@gateway.atlanta.com; user=phone
Where does the port number go?

Brian

> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy@cisco.com]
> Sent: Thursday, January 09, 2003 12:30 AM
> To: 'Paul Kyzivat'; 'Rosen, Brian'
> Cc: sipping@ietf.org
> Subject: RE: [Sipping] URIs for Gateways
> 
> 
> 
> The port names a specific resource on the GW (similar to a 
> trunk group)
> so if it is in a SIP URL, I think it should be in the user 
> portion. This
> matches up perfectly with just defining it in the tel URL then let the
> normal tel to sip translation rules apply to how looks in a SIP URL.
> 
> 
> > -----Original Message-----
> > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] 
> > On Behalf Of Paul Kyzivat
> > Sent: Wednesday, January 08, 2003 12:38 PM
> > To: Rosen, Brian
> > Cc: 'sipping@ietf.org'
> > Subject: Re: [Sipping] URIs for Gateways
> > 
> > 
> > Brian,
> > 
> > A few initial comments. More later when I get time to think 
> about it.
> > 
> > - I'm not sure of the advisability of adding caller name to 
> > the tel uri. 
> > If  you do it, I don't like that way. Would prefer a tel: 
> > parameter, as in
> >       tel:+14125551212;caller-name="Alice Toklas"
> > 
> > - I don't think the port should be a sip uri parameter. It is very 
> > telephony oriented, so I think it is better as a tel: uri parameter.
> > 
> > 	Paul
> > 
> > Rosen, Brian wrote:
> > > After all of this, I propose the following:
> > > 
> > > 1. We add the possibility of a callerId string to a tel uri:
> > >    telephone-uri = "tel:" [callerIdName LWS] subscriber
> > >    callerIdName = quoted-string
> > > 
> > > 2. Gateways accept or send sip uris of the form:
> > >    sip:"Alice Toklas" 4125551212@gateway.atlanta.com; user=phone; 
> > > port=3 or tel uris of the form:
> > >    tel:"Alice Toklas" +14125551212; port=3
> > > or "ordinary" sip uri's with extra information in a 
> separate header
> > > of the form:
> > >    <header> +14125551212; port=3
> > > 
> > > where <header> could be "P-Asserted-Identity", or it 
> could be a new 
> > > header we define for the purpose.
> > > 
> > > Then, we have the following possibilities:
> > > 
> > > SIP device to gateway (outgoing) call
> > >    To a phone number
> > >         use the phone number in the Request-URI & To:, probably
> > >         in a tel URI, or maybe phonenumber@localdomain; user=phone
> > > 
> > >         use normal sip URI in From:
> > >      
> > >         If a translator is available, it may assert the 
> phone number
> > >         for the identity in the From: using <header>
> > > 
> > >         proxy may rewrite the Request-URI in the form of
> > >         sip: phone@gateway;user=phone;port=portnum
> > >    
> > >    To a sip URI
> > >         use the sip uri in the Request-URI and To:
> > >         use normal sip URI in From:
> > > 
> > >         proxy rewrites Request-URI, due to forwarding behavior,
> > >         ENUM lookup, etc, resulting in a tel URI or a 
> user=phone sip
> > >         uri.  If necessary, a local incoming proxy can 
> rewrite it to
> > >         add the port parameter to the Request-URI based 
> on the From:
> > >     
> > >         If a translator is available, it may assert the 
> phone number
> > >         for the identity in the From: using the <header>
> > > 
> > > Gateway to SIP device (incoming call)
> > >    With mapping
> > >         use the mapped uri in the Request-URI & To:
> > >           
> > >         (optionally) supply called number using <header>
> > >         This might be needed when multiple called numbers
> > >         map to the same uri.
> > >         
> > >         use sip:"callerId" phone@gateway; port=portnum or
> > >         a tel: uri in From:
> > > 
> > >    Without mapping
> > >         use a provisioned (per port) URI, a tel uri with 
> the called 
> > >         number, or a sip uri with calledNumber@localdomain; 
> > user=phone
> > >         in the Request-URI & To:.  Gateways should support all 3,
> > >         choice should be made by provisioning.
> > > 
> > >         use sip:"callerId" phone@gateway; port=portnum or tel
> > >         uri in From:
> > > 
> > >         proxy will rewrite the Request-URI with the 
> correct sip URI
> > >         associated with the called number
> > >   
> > > Brian
> > > _______________________________________________
> > > Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> > > This list is for NEW development of the application of SIP Use 
> > > sip-implementors@cs.columbia.edu for questions on current sip Use 
> > > sip@ietf.org for new developments of core SIP
> > > 
> > 
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use sip-implementors@cs.columbia.edu for questions on current 
> > sip Use sip@ietf.org for new developments of core SIP
> > 
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  9 10:09:56 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13835
	for <sipping-archive@odin.ietf.org>; Thu, 9 Jan 2003 10:09:56 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h09FLfk30122
	for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 10:21:41 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FLfJ30117
	for <sipping-web-archive@optimus.ietf.org>; Thu, 9 Jan 2003 10:21:41 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13809
	for <sipping-web-archive@ietf.org>; Thu, 9 Jan 2003 10:09:18 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FK8J29999;
	Thu, 9 Jan 2003 10:20:08 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FJUJ29926
	for <sipping@optimus.ietf.org>; Thu, 9 Jan 2003 10:19:30 -0500
Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13766
	for <sipping@ietf.org>; Thu, 9 Jan 2003 10:07:14 -0500 (EST)
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h09FAVAv006913;
	Thu, 9 Jan 2003 16:10:31 +0100 (MET)
Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55)
	id ZGM07TNN; Thu, 9 Jan 2003 16:10:30 +0100
Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.19])
	by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h09FAVu4009243;
	Thu, 9 Jan 2003 17:10:31 +0200 (EET)
Message-ID: <3E1D90ED.A8157681@lmf.ericsson.se>
Date: Thu, 09 Jan 2003 17:10:37 +0200
X-Sybari-Trust: 9fbbc6c2 1864f774 d5511081 00000138
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
CC: "'Cullen Jennings'" <fluffy@cisco.com>,
        "'Paul Kyzivat'" <pkyzivat@cisco.com>, sipping@ietf.org
Subject: Re: [Sipping] URIs for Gateways
References: <313680C9A886D511A06000204840E1CF030B5CEE@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


Hi,

> I don't think this works if I'm understanding you
>
> I have a tel uri like tel:+14125551212.  I translate that
> to sip:14125551212@gateway.atlanta.com; user=phone
> Where does the port number go?

Into the user part. The URI would look like:

sip:14125551212;port=3@gateway.atlanta.com;user=phone

Regards,

Christer Holmberg
Ericsson Finland





>
>
> Brian
>
> > -----Original Message-----
> > From: Cullen Jennings [mailto:fluffy@cisco.com]
> > Sent: Thursday, January 09, 2003 12:30 AM
> > To: 'Paul Kyzivat'; 'Rosen, Brian'
> > Cc: sipping@ietf.org
> > Subject: RE: [Sipping] URIs for Gateways
> >
> >
> >
> > The port names a specific resource on the GW (similar to a
> > trunk group)
> > so if it is in a SIP URL, I think it should be in the user
> > portion. This
> > matches up perfectly with just defining it in the tel URL then let the
> > normal tel to sip translation rules apply to how looks in a SIP URL.
> >
> >
> > > -----Original Message-----
> > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]
> > > On Behalf Of Paul Kyzivat
> > > Sent: Wednesday, January 08, 2003 12:38 PM
> > > To: Rosen, Brian
> > > Cc: 'sipping@ietf.org'
> > > Subject: Re: [Sipping] URIs for Gateways
> > >
> > >
> > > Brian,
> > >
> > > A few initial comments. More later when I get time to think
> > about it.
> > >
> > > - I'm not sure of the advisability of adding caller name to
> > > the tel uri.
> > > If  you do it, I don't like that way. Would prefer a tel:
> > > parameter, as in
> > >       tel:+14125551212;caller-name="Alice Toklas"
> > >
> > > - I don't think the port should be a sip uri parameter. It is very
> > > telephony oriented, so I think it is better as a tel: uri parameter.
> > >
> > >     Paul
> > >
> > > Rosen, Brian wrote:
> > > > After all of this, I propose the following:
> > > >
> > > > 1. We add the possibility of a callerId string to a tel uri:
> > > >    telephone-uri = "tel:" [callerIdName LWS] subscriber
> > > >    callerIdName = quoted-string
> > > >
> > > > 2. Gateways accept or send sip uris of the form:
> > > >    sip:"Alice Toklas" 4125551212@gateway.atlanta.com; user=phone;
> > > > port=3 or tel uris of the form:
> > > >    tel:"Alice Toklas" +14125551212; port=3
> > > > or "ordinary" sip uri's with extra information in a
> > separate header
> > > > of the form:
> > > >    <header> +14125551212; port=3
> > > >
> > > > where <header> could be "P-Asserted-Identity", or it
> > could be a new
> > > > header we define for the purpose.
> > > >
> > > > Then, we have the following possibilities:
> > > >
> > > > SIP device to gateway (outgoing) call
> > > >    To a phone number
> > > >         use the phone number in the Request-URI & To:, probably
> > > >         in a tel URI, or maybe phonenumber@localdomain; user=phone
> > > >
> > > >         use normal sip URI in From:
> > > >
> > > >         If a translator is available, it may assert the
> > phone number
> > > >         for the identity in the From: using <header>
> > > >
> > > >         proxy may rewrite the Request-URI in the form of
> > > >         sip: phone@gateway;user=phone;port=portnum
> > > >
> > > >    To a sip URI
> > > >         use the sip uri in the Request-URI and To:
> > > >         use normal sip URI in From:
> > > >
> > > >         proxy rewrites Request-URI, due to forwarding behavior,
> > > >         ENUM lookup, etc, resulting in a tel URI or a
> > user=phone sip
> > > >         uri.  If necessary, a local incoming proxy can
> > rewrite it to
> > > >         add the port parameter to the Request-URI based
> > on the From:
> > > >
> > > >         If a translator is available, it may assert the
> > phone number
> > > >         for the identity in the From: using the <header>
> > > >
> > > > Gateway to SIP device (incoming call)
> > > >    With mapping
> > > >         use the mapped uri in the Request-URI & To:
> > > >
> > > >         (optionally) supply called number using <header>
> > > >         This might be needed when multiple called numbers
> > > >         map to the same uri.
> > > >
> > > >         use sip:"callerId" phone@gateway; port=portnum or
> > > >         a tel: uri in From:
> > > >
> > > >    Without mapping
> > > >         use a provisioned (per port) URI, a tel uri with
> > the called
> > > >         number, or a sip uri with calledNumber@localdomain;
> > > user=phone
> > > >         in the Request-URI & To:.  Gateways should support all 3,
> > > >         choice should be made by provisioning.
> > > >
> > > >         use sip:"callerId" phone@gateway; port=portnum or tel
> > > >         uri in From:
> > > >
> > > >         proxy will rewrite the Request-URI with the
> > correct sip URI
> > > >         associated with the called number
> > > >
> > > > Brian
> > > > _______________________________________________
> > > > Sipping mailing list
> > https://www1.ietf.org/mailman/listinfo/sipping
> > > > This list is for NEW development of the application of SIP Use
> > > > sip-implementors@cs.columbia.edu for questions on current sip Use
> > > > sip@ietf.org for new developments of core SIP
> > > >
> > >
> > > _______________________________________________
> > > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > > This list is for NEW development of the application of SIP
> > > Use sip-implementors@cs.columbia.edu for questions on current
> > > sip Use sip@ietf.org for new developments of core SIP
> > >
> >
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  9 10:12:07 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13949
	for <sipping-archive@odin.ietf.org>; Thu, 9 Jan 2003 10:12:07 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h09FNqM30336
	for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 10:23:52 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FNqJ30333
	for <sipping-web-archive@optimus.ietf.org>; Thu, 9 Jan 2003 10:23:52 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13896
	for <sipping-web-archive@ietf.org>; Thu, 9 Jan 2003 10:11:22 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FMVJ30203;
	Thu, 9 Jan 2003 10:22:31 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FLfJ30120
	for <sipping@optimus.ietf.org>; Thu, 9 Jan 2003 10:21:41 -0500
Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13812
	for <sipping@ietf.org>; Thu, 9 Jan 2003 10:09:25 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h09FDNKa023463;
	Thu, 9 Jan 2003 10:13:23 -0500 (EST)
Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAX60053;
	Thu, 9 Jan 2003 10:17:42 -0500 (EST)
Message-ID: <3E1D9168.1020606@cisco.com>
Date: Thu, 09 Jan 2003 10:12:40 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
CC: "'sipping@ietf.org'" <sipping@ietf.org>
Subject: Re: [Sipping] URIs for Gateways
References: <313680C9A886D511A06000204840E1CF030B5CEC@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit



Rosen, Brian wrote:
>>- I don't think the port should be a sip uri parameter. It is very 
>>telephony oriented, so I think it is better as a tel: uri parameter.
> 
> It's often the case that routing decisions on which gateway gets a
> call is made prior to the next-to-last proxy.  To make that work, you
> have to rewrite the Request-URI to a form of phonenumber@gateway
> so that subsequent proxies route correctly.  Therefore, I think you
> need the parameter in both

Why does that change anything? All the parameters of a tel uri are 
mapped to parameters in the user part of a sip uri with user=phone. So 
the following sequence of addresses should be fine while transiting a 
series of proxies:

	tel:+16025551212
	sip:+16025551212@gw1.acme.com;user=phone
	sip:+16025551212;port=37@gw3.provider.com;user=phone

Paul

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  9 10:12:09 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13951
	for <sipping-archive@odin.ietf.org>; Thu, 9 Jan 2003 10:12:09 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h09FNsh30352
	for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 10:23:54 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FNsJ30349
	for <sipping-web-archive@optimus.ietf.org>; Thu, 9 Jan 2003 10:23:54 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13851
	for <sipping-web-archive@ietf.org>; Thu, 9 Jan 2003 10:10:01 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FL4J30075;
	Thu, 9 Jan 2003 10:21:04 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FKkJ30055
	for <sipping@optimus.ietf.org>; Thu, 9 Jan 2003 10:20:46 -0500
Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13798
	for <sipping@ietf.org>; Thu, 9 Jan 2003 10:08:30 -0500 (EST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA24358;
	Thu, 9 Jan 2003 10:11:46 -0500 (EST)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA14956;
	Thu, 9 Jan 2003 10:11:47 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <ZVACMJWA>; Thu, 9 Jan 2003 10:11:46 -0500
Message-ID: <313680C9A886D511A06000204840E1CF030B5CEF@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Paul Kyzivat'" <pkyzivat@cisco.com>,
        "'sipping@ietf.org'"
	 <sipping@ietf.org>
Date: Thu, 9 Jan 2003 10:11:44 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sipping] Do Phones Have Dial Plans, or do Proxies map?  was RE: [Sipping]
 Re: draft-schulzrinne-sipping-sos-04.txt
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

This comes up a lot.  I think we should decide.

Who translates a dial string into a tel uri?

tel uris, as of now, explicitly don't handle dialing strings,
only dialed numbers.  In essentially all existing systems,
phones don't have dialing plans in them; central elements
map dialing strings to dialed numbers.  What's our story?
Does every UA that has a dial pad have to have a dialing plan 
loaded in it that maps dialing strings to dialed numbers, 
or does a proxy server do it?

If it's the former, then how do we standardize the mapping?
If it's the latter, then how does a UA send a dialing string?

Brian

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Thursday, January 09, 2003 9:53 AM
> To: 'sipping@ietf.org'
> Subject: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
> 
> 
> I have a few comments about draft-schulzrinne-sipping-sos-04.txt.
> (I haven't been following this work very closely, so perhaps some of 
> these pertain to things that were in earlier drafts.)
> 
> I must say, these are really messy problems, so I am glad you are 
> working on them.
> 
> Section 3.2 says:
> 
>     ... a UAC MAY use a "tel" URI [3,4] without phone-context, such as
> 
>     tel:911
>     tel:112
> 
> The latest and greatest definition of the tel: uri that I can find is 
> draft-antti-rfc2806bis-07.txt. According to that, the above tel: uris 
> are syntactically incorrect. Either the number must be global 
> or else it 
> must contain a phone-context parameter.
> 
> Are there plans to change the definition of the tel uri, or is this 
> language going to change?
> 
> In the case of a UAC that is using a local outbound proxy, is it 
> required that the UAC specifically recognize these strings 
> and deliver 
> them to the proxy, or is it sufficient for it to deliver any and all 
> dialed digit strings to the proxy as tel uris without attempting to 
> recognize them itself? Is it sufficient to determine that the dialed 
> number is complete by timeout on the input rather than by recognition?
> 
> Section 5 specifies that the UAC should insert location 
> information into 
> emergency calls. However, presumably location information should in 
> general not be placed in non-emergency calls, so it is important that 
> the UAC realize it is making an emergency call. In the case of dialed 
> digit strings, it may only be the outbound proxy that can 
> determine if 
> the call is an emergency call. One way to handle this would 
> be for the 
> local outbound proxy to redirect requests to tel: emergency 
> numbers to 
> the corresponding sip:sos number. Then the UAC would be able to 
> positively determine this is an emergency call and include 
> the location 
> information.
> 
> Section 9 says:
> 
>     We propose a new DHCP option that enumerates the valid local
>     emergency identifiers, as a list of "tel", "sip" or "sips" URIs.
> 
> This doesn't seem sufficient. Most phone-like devices have 
> provision for 
> entering primarily sequences of digits, not tel: uris. It is 
> up to the 
> phone to translate a digit sequence into a valid uri. In general this 
> requires some sort of dial plan. Without the dial plan, the phone may 
> well not be able to generate anything that matches one of the 
> specified 
> tel uris.
> 
> 	Paul
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  9 10:12:48 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13973
	for <sipping-archive@odin.ietf.org>; Thu, 9 Jan 2003 10:12:48 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h09FOXm30393
	for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 10:24:33 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FOXJ30390
	for <sipping-web-archive@optimus.ietf.org>; Thu, 9 Jan 2003 10:24:33 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13929
	for <sipping-web-archive@ietf.org>; Thu, 9 Jan 2003 10:11:59 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FN5J30270;
	Thu, 9 Jan 2003 10:23:05 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FM9J30166
	for <sipping@optimus.ietf.org>; Thu, 9 Jan 2003 10:22:09 -0500
Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13826
	for <sipping@ietf.org>; Thu, 9 Jan 2003 10:09:53 -0500 (EST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA24478;
	Thu, 9 Jan 2003 10:13:09 -0500 (EST)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA15419;
	Thu, 9 Jan 2003 10:13:09 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <ZVACMJ5W>; Thu, 9 Jan 2003 10:13:08 -0500
Message-ID: <313680C9A886D511A06000204840E1CF030B5CF0@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'jh@lohi.eng.song.fi'" <jh@lohi.eng.song.fi>
Cc: "'sipping@ietf.org'" <sipping@ietf.org>
Subject: RE: [Sipping] URIs for Gateways
Date: Thu, 9 Jan 2003 10:13:05 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

Juha

Not all gateways are equipped to do the mapping.
In many cases, there is some element (a proxy server) that
does the mapping.  I am loath to make it a requirement
that the mapping is done at the gateway. 

Also, tel URIs in Request-URIs are often rewritten by
proxy servers to a form of sip:phonenumber@gateway;user=phone
when the routing mechanisms that decide which gateway
gets the call is not the next-to-last proxy.  For example, one
might have gateways at two sites in an enterprise.  A local
decision may be made on one site to forward a call to the
gateway at the other site.  To do this, it must rewrite the
Request-URI so that subsequent proxy servers will correctly
route the call.  We have seen 3 or 4 different ways that
gateways interpret fields to handle this case.

P-A-I is interesting when asserting a phone number for a "normal"
sip URI.  This usage does not precisely follow the text of the
RFC, but it's pretty close.

Brian 

> -----Original Message-----
> From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi]
> Sent: Thursday, January 09, 2003 2:49 AM
> To: Rosen, Brian
> Cc: 'sipping@ietf.org'
> Subject: RE: [Sipping] URIs for Gateways
> 
> 
> brian,
> 
> you can program your sip/ss7 gw whatever way you like to map phone
> numbers and sip uris.  there is no need to standardize 
> anything new now
> that we already have asserted identity to place the phone 
> number in case
> the user is using a from uri which is either anonymous or does not
> contain callers phone number.  the mappings themselves are a local
> matter of your domain.
> 
> -- juha
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  9 10:15:20 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14071
	for <sipping-archive@odin.ietf.org>; Thu, 9 Jan 2003 10:15:20 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h09FR5630580
	for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 10:27:05 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FR5J30577
	for <sipping-web-archive@optimus.ietf.org>; Thu, 9 Jan 2003 10:27:05 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14033
	for <sipping-web-archive@ietf.org>; Thu, 9 Jan 2003 10:14:14 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FP4J30501;
	Thu, 9 Jan 2003 10:25:04 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FOYJ30405
	for <sipping@optimus.ietf.org>; Thu, 9 Jan 2003 10:24:34 -0500
Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13954
	for <sipping@ietf.org>; Thu, 9 Jan 2003 10:12:17 -0500 (EST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA24707;
	Thu, 9 Jan 2003 10:15:34 -0500 (EST)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA16150;
	Thu, 9 Jan 2003 10:15:34 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <ZVACMKBZ>; Thu, 9 Jan 2003 10:15:34 -0500
Message-ID: <313680C9A886D511A06000204840E1CF030B5CF1@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Christer Holmberg'" <christer.holmberg@lmf.ericsson.se>
Cc: "'Cullen Jennings'" <fluffy@cisco.com>,
        "'Paul Kyzivat'"
	 <pkyzivat@cisco.com>, sipping@ietf.org
Subject: RE: [Sipping] URIs for Gateways
Date: Thu, 9 Jan 2003 10:15:33 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

Ugh.

Legal though:
   SIP-URI          =  "sip:" [ userinfo "@" ] hostport
                       uri-parameters [ headers ]
   userinfo         =  [ user / telephone-subscriber [ ":" password ]]
   user             =  *( unreserved / escaped / user-unreserved )
   user-unreserved  =  "&" / "=" / "+" / "$" / "," / ";" / "?" / "/"

I can deal with it, but it seems much more appropriate to have it
be a uri-parameter

Brian

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se]
> Sent: Thursday, January 09, 2003 10:11 AM
> To: Rosen, Brian
> Cc: 'Cullen Jennings'; 'Paul Kyzivat'; sipping@ietf.org
> Subject: Re: [Sipping] URIs for Gateways
> 
> 
> 
> Hi,
> 
> > I don't think this works if I'm understanding you
> >
> > I have a tel uri like tel:+14125551212.  I translate that
> > to sip:14125551212@gateway.atlanta.com; user=phone
> > Where does the port number go?
> 
> Into the user part. The URI would look like:
> 
> sip:14125551212;port=3@gateway.atlanta.com;user=phone
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> 
> 
> 
> 
> >
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Cullen Jennings [mailto:fluffy@cisco.com]
> > > Sent: Thursday, January 09, 2003 12:30 AM
> > > To: 'Paul Kyzivat'; 'Rosen, Brian'
> > > Cc: sipping@ietf.org
> > > Subject: RE: [Sipping] URIs for Gateways
> > >
> > >
> > >
> > > The port names a specific resource on the GW (similar to a
> > > trunk group)
> > > so if it is in a SIP URL, I think it should be in the user
> > > portion. This
> > > matches up perfectly with just defining it in the tel URL 
> then let the
> > > normal tel to sip translation rules apply to how looks in 
> a SIP URL.
> > >
> > >
> > > > -----Original Message-----
> > > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]
> > > > On Behalf Of Paul Kyzivat
> > > > Sent: Wednesday, January 08, 2003 12:38 PM
> > > > To: Rosen, Brian
> > > > Cc: 'sipping@ietf.org'
> > > > Subject: Re: [Sipping] URIs for Gateways
> > > >
> > > >
> > > > Brian,
> > > >
> > > > A few initial comments. More later when I get time to think
> > > about it.
> > > >
> > > > - I'm not sure of the advisability of adding caller name to
> > > > the tel uri.
> > > > If  you do it, I don't like that way. Would prefer a tel:
> > > > parameter, as in
> > > >       tel:+14125551212;caller-name="Alice Toklas"
> > > >
> > > > - I don't think the port should be a sip uri parameter. 
> It is very
> > > > telephony oriented, so I think it is better as a tel: 
> uri parameter.
> > > >
> > > >     Paul
> > > >
> > > > Rosen, Brian wrote:
> > > > > After all of this, I propose the following:
> > > > >
> > > > > 1. We add the possibility of a callerId string to a tel uri:
> > > > >    telephone-uri = "tel:" [callerIdName LWS] subscriber
> > > > >    callerIdName = quoted-string
> > > > >
> > > > > 2. Gateways accept or send sip uris of the form:
> > > > >    sip:"Alice Toklas" 4125551212@gateway.atlanta.com; 
> user=phone;
> > > > > port=3 or tel uris of the form:
> > > > >    tel:"Alice Toklas" +14125551212; port=3
> > > > > or "ordinary" sip uri's with extra information in a
> > > separate header
> > > > > of the form:
> > > > >    <header> +14125551212; port=3
> > > > >
> > > > > where <header> could be "P-Asserted-Identity", or it
> > > could be a new
> > > > > header we define for the purpose.
> > > > >
> > > > > Then, we have the following possibilities:
> > > > >
> > > > > SIP device to gateway (outgoing) call
> > > > >    To a phone number
> > > > >         use the phone number in the Request-URI & 
> To:, probably
> > > > >         in a tel URI, or maybe 
> phonenumber@localdomain; user=phone
> > > > >
> > > > >         use normal sip URI in From:
> > > > >
> > > > >         If a translator is available, it may assert the
> > > phone number
> > > > >         for the identity in the From: using <header>
> > > > >
> > > > >         proxy may rewrite the Request-URI in the form of
> > > > >         sip: phone@gateway;user=phone;port=portnum
> > > > >
> > > > >    To a sip URI
> > > > >         use the sip uri in the Request-URI and To:
> > > > >         use normal sip URI in From:
> > > > >
> > > > >         proxy rewrites Request-URI, due to forwarding 
> behavior,
> > > > >         ENUM lookup, etc, resulting in a tel URI or a
> > > user=phone sip
> > > > >         uri.  If necessary, a local incoming proxy can
> > > rewrite it to
> > > > >         add the port parameter to the Request-URI based
> > > on the From:
> > > > >
> > > > >         If a translator is available, it may assert the
> > > phone number
> > > > >         for the identity in the From: using the <header>
> > > > >
> > > > > Gateway to SIP device (incoming call)
> > > > >    With mapping
> > > > >         use the mapped uri in the Request-URI & To:
> > > > >
> > > > >         (optionally) supply called number using <header>
> > > > >         This might be needed when multiple called numbers
> > > > >         map to the same uri.
> > > > >
> > > > >         use sip:"callerId" phone@gateway; port=portnum or
> > > > >         a tel: uri in From:
> > > > >
> > > > >    Without mapping
> > > > >         use a provisioned (per port) URI, a tel uri with
> > > the called
> > > > >         number, or a sip uri with calledNumber@localdomain;
> > > > user=phone
> > > > >         in the Request-URI & To:.  Gateways should 
> support all 3,
> > > > >         choice should be made by provisioning.
> > > > >
> > > > >         use sip:"callerId" phone@gateway; port=portnum or tel
> > > > >         uri in From:
> > > > >
> > > > >         proxy will rewrite the Request-URI with the
> > > correct sip URI
> > > > >         associated with the called number
> > > > >
> > > > > Brian
> > > > > _______________________________________________
> > > > > Sipping mailing list
> > > https://www1.ietf.org/mailman/listinfo/sipping
> > > > > This list is for NEW development of the application of SIP Use
> > > > > sip-implementors@cs.columbia.edu for questions on 
> current sip Use
> > > > > sip@ietf.org for new developments of core SIP
> > > > >
> > > >
> > > > _______________________________________________
> > > > Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> > > > This list is for NEW development of the application of SIP
> > > > Use sip-implementors@cs.columbia.edu for questions on current
> > > > sip Use sip@ietf.org for new developments of core SIP
> > > >
> > >
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sip@ietf.org for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  9 10:30:13 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14625
	for <sipping-archive@odin.ietf.org>; Thu, 9 Jan 2003 10:30:13 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h09Ffxo32228
	for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 10:41:59 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FfxJ32225
	for <sipping-web-archive@optimus.ietf.org>; Thu, 9 Jan 2003 10:41:59 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14555
	for <sipping-web-archive@ietf.org>; Thu, 9 Jan 2003 10:29:13 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09Fe6J31897;
	Thu, 9 Jan 2003 10:40:07 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FWiJ30849
	for <sipping@optimus.ietf.org>; Thu, 9 Jan 2003 10:32:44 -0500
Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14229
	for <sipping@ietf.org>; Thu, 9 Jan 2003 10:20:27 -0500 (EST)
Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h09FNiAv010220;
	Thu, 9 Jan 2003 16:23:44 +0100 (MET)
Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55)
	id ZGNLT9NT; Thu, 9 Jan 2003 16:23:44 +0100
Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.19])
	by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h09FNiu4009823;
	Thu, 9 Jan 2003 17:23:44 +0200 (EET)
Message-ID: <3E1D9406.92A57154@lmf.ericsson.se>
Date: Thu, 09 Jan 2003 17:23:50 +0200
X-Sybari-Trust: 98ca81bf 1864f774 d5511081 00000138
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
CC: "'Cullen Jennings'" <fluffy@cisco.com>,
        "'Paul Kyzivat'" <pkyzivat@cisco.com>, sipping@ietf.org
Subject: Re: [Sipping] URIs for Gateways
References: <313680C9A886D511A06000204840E1CF030B5CF1@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


Hi,

> Ugh.
>
> Legal though:
>    SIP-URI          =  "sip:" [ userinfo "@" ] hostport
>                        uri-parameters [ headers ]
>    userinfo         =  [ user / telephone-subscriber [ ":" password ]]
>    user             =  *( unreserved / escaped / user-unreserved )
>    user-unreserved  =  "&" / "=" / "+" / "$" / "," / ";" / "?" / "/"
>
> I can deal with it, but it seems much more appropriate to have it
> be a uri-parameter

I had issues with this too, a long time ago. You should have backed me up at
that time ;) No idea to bring that up again, though...

Also, chapter 19.1.6 describes how the tel-url, including the parameters,
are mapped into sip-uri.

Regards,

Christer Holmberg
Ericsson Finland






>
>
> Brian
>
> > -----Original Message-----
> > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se]
> > Sent: Thursday, January 09, 2003 10:11 AM
> > To: Rosen, Brian
> > Cc: 'Cullen Jennings'; 'Paul Kyzivat'; sipping@ietf.org
> > Subject: Re: [Sipping] URIs for Gateways
> >
> >
> >
> > Hi,
> >
> > > I don't think this works if I'm understanding you
> > >
> > > I have a tel uri like tel:+14125551212.  I translate that
> > > to sip:14125551212@gateway.atlanta.com; user=phone
> > > Where does the port number go?
> >
> > Into the user part. The URI would look like:
> >
> > sip:14125551212;port=3@gateway.atlanta.com;user=phone
> >
> > Regards,
> >
> > Christer Holmberg
> > Ericsson Finland
> >
> >
> >
> >
> >
> > >
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Cullen Jennings [mailto:fluffy@cisco.com]
> > > > Sent: Thursday, January 09, 2003 12:30 AM
> > > > To: 'Paul Kyzivat'; 'Rosen, Brian'
> > > > Cc: sipping@ietf.org
> > > > Subject: RE: [Sipping] URIs for Gateways
> > > >
> > > >
> > > >
> > > > The port names a specific resource on the GW (similar to a
> > > > trunk group)
> > > > so if it is in a SIP URL, I think it should be in the user
> > > > portion. This
> > > > matches up perfectly with just defining it in the tel URL
> > then let the
> > > > normal tel to sip translation rules apply to how looks in
> > a SIP URL.
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]
> > > > > On Behalf Of Paul Kyzivat
> > > > > Sent: Wednesday, January 08, 2003 12:38 PM
> > > > > To: Rosen, Brian
> > > > > Cc: 'sipping@ietf.org'
> > > > > Subject: Re: [Sipping] URIs for Gateways
> > > > >
> > > > >
> > > > > Brian,
> > > > >
> > > > > A few initial comments. More later when I get time to think
> > > > about it.
> > > > >
> > > > > - I'm not sure of the advisability of adding caller name to
> > > > > the tel uri.
> > > > > If  you do it, I don't like that way. Would prefer a tel:
> > > > > parameter, as in
> > > > >       tel:+14125551212;caller-name="Alice Toklas"
> > > > >
> > > > > - I don't think the port should be a sip uri parameter.
> > It is very
> > > > > telephony oriented, so I think it is better as a tel:
> > uri parameter.
> > > > >
> > > > >     Paul
> > > > >
> > > > > Rosen, Brian wrote:
> > > > > > After all of this, I propose the following:
> > > > > >
> > > > > > 1. We add the possibility of a callerId string to a tel uri:
> > > > > >    telephone-uri = "tel:" [callerIdName LWS] subscriber
> > > > > >    callerIdName = quoted-string
> > > > > >
> > > > > > 2. Gateways accept or send sip uris of the form:
> > > > > >    sip:"Alice Toklas" 4125551212@gateway.atlanta.com;
> > user=phone;
> > > > > > port=3 or tel uris of the form:
> > > > > >    tel:"Alice Toklas" +14125551212; port=3
> > > > > > or "ordinary" sip uri's with extra information in a
> > > > separate header
> > > > > > of the form:
> > > > > >    <header> +14125551212; port=3
> > > > > >
> > > > > > where <header> could be "P-Asserted-Identity", or it
> > > > could be a new
> > > > > > header we define for the purpose.
> > > > > >
> > > > > > Then, we have the following possibilities:
> > > > > >
> > > > > > SIP device to gateway (outgoing) call
> > > > > >    To a phone number
> > > > > >         use the phone number in the Request-URI &
> > To:, probably
> > > > > >         in a tel URI, or maybe
> > phonenumber@localdomain; user=phone
> > > > > >
> > > > > >         use normal sip URI in From:
> > > > > >
> > > > > >         If a translator is available, it may assert the
> > > > phone number
> > > > > >         for the identity in the From: using <header>
> > > > > >
> > > > > >         proxy may rewrite the Request-URI in the form of
> > > > > >         sip: phone@gateway;user=phone;port=portnum
> > > > > >
> > > > > >    To a sip URI
> > > > > >         use the sip uri in the Request-URI and To:
> > > > > >         use normal sip URI in From:
> > > > > >
> > > > > >         proxy rewrites Request-URI, due to forwarding
> > behavior,
> > > > > >         ENUM lookup, etc, resulting in a tel URI or a
> > > > user=phone sip
> > > > > >         uri.  If necessary, a local incoming proxy can
> > > > rewrite it to
> > > > > >         add the port parameter to the Request-URI based
> > > > on the From:
> > > > > >
> > > > > >         If a translator is available, it may assert the
> > > > phone number
> > > > > >         for the identity in the From: using the <header>
> > > > > >
> > > > > > Gateway to SIP device (incoming call)
> > > > > >    With mapping
> > > > > >         use the mapped uri in the Request-URI & To:
> > > > > >
> > > > > >         (optionally) supply called number using <header>
> > > > > >         This might be needed when multiple called numbers
> > > > > >         map to the same uri.
> > > > > >
> > > > > >         use sip:"callerId" phone@gateway; port=portnum or
> > > > > >         a tel: uri in From:
> > > > > >
> > > > > >    Without mapping
> > > > > >         use a provisioned (per port) URI, a tel uri with
> > > > the called
> > > > > >         number, or a sip uri with calledNumber@localdomain;
> > > > > user=phone
> > > > > >         in the Request-URI & To:.  Gateways should
> > support all 3,
> > > > > >         choice should be made by provisioning.
> > > > > >
> > > > > >         use sip:"callerId" phone@gateway; port=portnum or tel
> > > > > >         uri in From:
> > > > > >
> > > > > >         proxy will rewrite the Request-URI with the
> > > > correct sip URI
> > > > > >         associated with the called number
> > > > > >
> > > > > > Brian
> > > > > > _______________________________________________
> > > > > > Sipping mailing list
> > > > https://www1.ietf.org/mailman/listinfo/sipping
> > > > > > This list is for NEW development of the application of SIP Use
> > > > > > sip-implementors@cs.columbia.edu for questions on
> > current sip Use
> > > > > > sip@ietf.org for new developments of core SIP
> > > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Sipping mailing list
> > https://www1.ietf.org/mailman/listinfo/sipping
> > > > > This list is for NEW development of the application of SIP
> > > > > Use sip-implementors@cs.columbia.edu for questions on current
> > > > > sip Use sip@ietf.org for new developments of core SIP
> > > > >
> > > >
> > > _______________________________________________
> > > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > > This list is for NEW development of the application of SIP
> > > Use sip-implementors@cs.columbia.edu for questions on current sip
> > > Use sip@ietf.org for new developments of core SIP
> >

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  9 10:34:10 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14855
	for <sipping-archive@odin.ietf.org>; Thu, 9 Jan 2003 10:34:10 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h09Fjt732558
	for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 10:45:55 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FjtJ32555
	for <sipping-web-archive@optimus.ietf.org>; Thu, 9 Jan 2003 10:45:55 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14781
	for <sipping-web-archive@ietf.org>; Thu, 9 Jan 2003 10:33:01 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09Fi4J32447;
	Thu, 9 Jan 2003 10:44:04 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FhqJ32423
	for <sipping@optimus.ietf.org>; Thu, 9 Jan 2003 10:43:52 -0500
Received: from mtiwmhc12.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14723
	for <sipping@ietf.org>; Thu, 9 Jan 2003 10:31:35 -0500 (EST)
Received: from cs.columbia.edu ([12.92.123.81])
          by mtiwmhc12.worldnet.att.net
          (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP
          id <20030109153451.GNSH12483.mtiwmhc12.worldnet.att.net@cs.columbia.edu>;
          Thu, 9 Jan 2003 15:34:51 +0000
Message-ID: <3E1D9608.4080400@cs.columbia.edu>
Date: Thu, 09 Jan 2003 10:32:24 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
CC: "'Paul Kyzivat'" <pkyzivat@cisco.com>,
        "'sipping@ietf.org'" <sipping@ietf.org>
Subject: Re: [Sipping] Do Phones Have Dial Plans, or do Proxies map?  was
 RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
References: <313680C9A886D511A06000204840E1CF030B5CEF@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

I would find it instructive how non-SIP systems have solved similar 
problems. In web browsers and email, we have auto-completion functions 
and nick names, for examples.

There's also the analogy with 'real names' (not the defunct company, the 
concept) which translates strings-nice-for-humans into URLs. See the CRN 
work, including the go: URL. (I'm not aware of implemenentations, but 
the concept may be relevant, in particular keeping the identifier and 
various 'nicknames' clearly distinct.)

There are probably two sub-problems here:

- Recognizing patterns so that one can keep the old 
"no-need-to-hit-dial" user interface.

- Translating abbreviations such as extensions and local-area numbers to 
fully-expanded, globally unique identifiers.

The former will always require downloading a pattern to an end system, 
the latter is a (local) translation service. The only question then 
becomes if the translation is done in one or two steps, i.e., before 
issuing a SIP request or as part of a SIP request.

Aside: There are clearly examles of widely-deployed systems where the 
phone has a dial-plan, downloaded via tftp.

Rosen, Brian wrote:
> This comes up a lot.  I think we should decide.
> 
> Who translates a dial string into a tel uri?
> 
> tel uris, as of now, explicitly don't handle dialing strings,
> only dialed numbers.  In essentially all existing systems,
> phones don't have dialing plans in them; central elements
> map dialing strings to dialed numbers.  What's our story?
> Does every UA that has a dial pad have to have a dialing plan 
> loaded in it that maps dialing strings to dialed numbers, 
> or does a proxy server do it?
> 
> If it's the former, then how do we standardize the mapping?
> If it's the latter, then how does a UA send a dialing string?
> 
> Brian
> 
> 
>>-----Original Message-----
>>From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
>>Sent: Thursday, January 09, 2003 9:53 AM
>>To: 'sipping@ietf.org'
>>Subject: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
>>
>>
>>I have a few comments about draft-schulzrinne-sipping-sos-04.txt.
>>(I haven't been following this work very closely, so perhaps some of 
>>these pertain to things that were in earlier drafts.)
>>
>>I must say, these are really messy problems, so I am glad you are 
>>working on them.
>>
>>Section 3.2 says:
>>
>>    ... a UAC MAY use a "tel" URI [3,4] without phone-context, such as
>>
>>    tel:911
>>    tel:112
>>
>>The latest and greatest definition of the tel: uri that I can find is 
>>draft-antti-rfc2806bis-07.txt. According to that, the above tel: uris 
>>are syntactically incorrect. Either the number must be global 
>>or else it 
>>must contain a phone-context parameter.
>>
>>Are there plans to change the definition of the tel uri, or is this 
>>language going to change?
>>
>>In the case of a UAC that is using a local outbound proxy, is it 
>>required that the UAC specifically recognize these strings 
>>and deliver 
>>them to the proxy, or is it sufficient for it to deliver any and all 
>>dialed digit strings to the proxy as tel uris without attempting to 
>>recognize them itself? Is it sufficient to determine that the dialed 
>>number is complete by timeout on the input rather than by recognition?
>>
>>Section 5 specifies that the UAC should insert location 
>>information into 
>>emergency calls. However, presumably location information should in 
>>general not be placed in non-emergency calls, so it is important that 
>>the UAC realize it is making an emergency call. In the case of dialed 
>>digit strings, it may only be the outbound proxy that can 
>>determine if 
>>the call is an emergency call. One way to handle this would 
>>be for the 
>>local outbound proxy to redirect requests to tel: emergency 
>>numbers to 
>>the corresponding sip:sos number. Then the UAC would be able to 
>>positively determine this is an emergency call and include 
>>the location 
>>information.
>>
>>Section 9 says:
>>
>>    We propose a new DHCP option that enumerates the valid local
>>    emergency identifiers, as a list of "tel", "sip" or "sips" URIs.
>>
>>This doesn't seem sufficient. Most phone-like devices have 
>>provision for 
>>entering primarily sequences of digits, not tel: uris. It is 
>>up to the 
>>phone to translate a digit sequence into a valid uri. In general this 
>>requires some sort of dial plan. Without the dial plan, the phone may 
>>well not be able to generate anything that matches one of the 
>>specified 
>>tel uris.
>>
>>	Paul
>>
>>_______________________________________________
>>Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>>This list is for NEW development of the application of SIP
>>Use sip-implementors@cs.columbia.edu for questions on current sip
>>Use sip@ietf.org for new developments of core SIP
>>
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  9 10:45:17 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15101
	for <sipping-archive@odin.ietf.org>; Thu, 9 Jan 2003 10:45:17 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h09Fv3a00628
	for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 10:57:03 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09Fv3J00625
	for <sipping-web-archive@optimus.ietf.org>; Thu, 9 Jan 2003 10:57:03 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15079
	for <sipping-web-archive@ietf.org>; Thu, 9 Jan 2003 10:43:58 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09Fq4J00386;
	Thu, 9 Jan 2003 10:52:04 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09Fp6J00347
	for <sipping@optimus.ietf.org>; Thu, 9 Jan 2003 10:51:06 -0500
Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14976
	for <sipping@ietf.org>; Thu, 9 Jan 2003 10:38:49 -0500 (EST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA26573;
	Thu, 9 Jan 2003 10:42:05 -0500 (EST)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA21052;
	Thu, 9 Jan 2003 10:42:06 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <ZVACMLKH>; Thu, 9 Jan 2003 10:42:06 -0500
Message-ID: <313680C9A886D511A06000204840E1CF030B5CF4@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Henning Schulzrinne'" <hgs@cs.columbia.edu>
Cc: "'Paul Kyzivat'" <pkyzivat@cisco.com>,
        "'sipping@ietf.org'"
	 <sipping@ietf.org>
Subject: RE: [Sipping] Do Phones Have Dial Plans, or do Proxies map?  was 
	RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
Date: Thu, 9 Jan 2003 10:42:03 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

The systems I'm aware of use regexps in one form or another
to mangle a string into a dialed number.  I don't have
a problem making this a UA function, but if we do, I want
to standardize the regexp and "Publish" it to the UA.

A lot of enterprise gateways have dial string to dialed number mapping.
Some sipphones do.

Brian



> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Thursday, January 09, 2003 10:32 AM
> To: Rosen, Brian
> Cc: 'Paul Kyzivat'; 'sipping@ietf.org'
> Subject: Re: [Sipping] Do Phones Have Dial Plans, or do 
> Proxies map? was
> RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
> 
> 
> I would find it instructive how non-SIP systems have solved similar 
> problems. In web browsers and email, we have auto-completion 
> functions 
> and nick names, for examples.
> 
> There's also the analogy with 'real names' (not the defunct 
> company, the 
> concept) which translates strings-nice-for-humans into URLs. 
> See the CRN 
> work, including the go: URL. (I'm not aware of implemenentations, but 
> the concept may be relevant, in particular keeping the identifier and 
> various 'nicknames' clearly distinct.)
> 
> There are probably two sub-problems here:
> 
> - Recognizing patterns so that one can keep the old 
> "no-need-to-hit-dial" user interface.
> 
> - Translating abbreviations such as extensions and local-area 
> numbers to 
> fully-expanded, globally unique identifiers.
> 
> The former will always require downloading a pattern to an 
> end system, 
> the latter is a (local) translation service. The only question then 
> becomes if the translation is done in one or two steps, i.e., before 
> issuing a SIP request or as part of a SIP request.
> 
> Aside: There are clearly examles of widely-deployed systems where the 
> phone has a dial-plan, downloaded via tftp.
> 
> Rosen, Brian wrote:
> > This comes up a lot.  I think we should decide.
> > 
> > Who translates a dial string into a tel uri?
> > 
> > tel uris, as of now, explicitly don't handle dialing strings,
> > only dialed numbers.  In essentially all existing systems,
> > phones don't have dialing plans in them; central elements
> > map dialing strings to dialed numbers.  What's our story?
> > Does every UA that has a dial pad have to have a dialing plan 
> > loaded in it that maps dialing strings to dialed numbers, 
> > or does a proxy server do it?
> > 
> > If it's the former, then how do we standardize the mapping?
> > If it's the latter, then how does a UA send a dialing string?
> > 
> > Brian
> > 
> > 
> >>-----Original Message-----
> >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> >>Sent: Thursday, January 09, 2003 9:53 AM
> >>To: 'sipping@ietf.org'
> >>Subject: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
> >>
> >>
> >>I have a few comments about draft-schulzrinne-sipping-sos-04.txt.
> >>(I haven't been following this work very closely, so 
> perhaps some of 
> >>these pertain to things that were in earlier drafts.)
> >>
> >>I must say, these are really messy problems, so I am glad you are 
> >>working on them.
> >>
> >>Section 3.2 says:
> >>
> >>    ... a UAC MAY use a "tel" URI [3,4] without 
> phone-context, such as
> >>
> >>    tel:911
> >>    tel:112
> >>
> >>The latest and greatest definition of the tel: uri that I 
> can find is 
> >>draft-antti-rfc2806bis-07.txt. According to that, the above 
> tel: uris 
> >>are syntactically incorrect. Either the number must be global 
> >>or else it 
> >>must contain a phone-context parameter.
> >>
> >>Are there plans to change the definition of the tel uri, or is this 
> >>language going to change?
> >>
> >>In the case of a UAC that is using a local outbound proxy, is it 
> >>required that the UAC specifically recognize these strings 
> >>and deliver 
> >>them to the proxy, or is it sufficient for it to deliver 
> any and all 
> >>dialed digit strings to the proxy as tel uris without attempting to 
> >>recognize them itself? Is it sufficient to determine that 
> the dialed 
> >>number is complete by timeout on the input rather than by 
> recognition?
> >>
> >>Section 5 specifies that the UAC should insert location 
> >>information into 
> >>emergency calls. However, presumably location information should in 
> >>general not be placed in non-emergency calls, so it is 
> important that 
> >>the UAC realize it is making an emergency call. In the case 
> of dialed 
> >>digit strings, it may only be the outbound proxy that can 
> >>determine if 
> >>the call is an emergency call. One way to handle this would 
> >>be for the 
> >>local outbound proxy to redirect requests to tel: emergency 
> >>numbers to 
> >>the corresponding sip:sos number. Then the UAC would be able to 
> >>positively determine this is an emergency call and include 
> >>the location 
> >>information.
> >>
> >>Section 9 says:
> >>
> >>    We propose a new DHCP option that enumerates the valid local
> >>    emergency identifiers, as a list of "tel", "sip" or "sips" URIs.
> >>
> >>This doesn't seem sufficient. Most phone-like devices have 
> >>provision for 
> >>entering primarily sequences of digits, not tel: uris. It is 
> >>up to the 
> >>phone to translate a digit sequence into a valid uri. In 
> general this 
> >>requires some sort of dial plan. Without the dial plan, the 
> phone may 
> >>well not be able to generate anything that matches one of the 
> >>specified 
> >>tel uris.
> >>
> >>	Paul
> >>
> >>_______________________________________________
> >>Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> >>This list is for NEW development of the application of SIP
> >>Use sip-implementors@cs.columbia.edu for questions on current sip
> >>Use sip@ietf.org for new developments of core SIP
> >>
> > 
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sip@ietf.org for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  9 11:25:29 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16716
	for <sipping-archive@odin.ietf.org>; Thu, 9 Jan 2003 11:25:28 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h09GbD104045
	for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 11:37:13 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09GbDJ04037
	for <sipping-web-archive@optimus.ietf.org>; Thu, 9 Jan 2003 11:37:13 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16655
	for <sipping-web-archive@ietf.org>; Thu, 9 Jan 2003 11:24:07 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09GZ7J03679;
	Thu, 9 Jan 2003 11:35:07 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09GYpJ03653
	for <sipping@optimus.ietf.org>; Thu, 9 Jan 2003 11:34:51 -0500
Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16617
	for <sipping@ietf.org>; Thu, 9 Jan 2003 11:22:34 -0500 (EST)
Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h09GOH53017880;
	Thu, 9 Jan 2003 11:24:17 -0500 (EST)
Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <W6F4GBXW>; Thu, 9 Jan 2003 10:25:42 -0600
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A643F9@DYN-TX-EXCH-001.dynamicsoft.com>
From: Adam Roach <adam@dynamicsoft.com>
To: "'Henning Schulzrinne'" <hgs@cs.columbia.edu>,
        "Rosen, Brian"
	 <Brian.Rosen@marconi.com>
Cc: "'Paul Kyzivat'" <pkyzivat@cisco.com>,
        "'sipping@ietf.org'"
	 <sipping@ietf.org>
Subject: RE: [Sipping] Do Phones Have Dial Plans, or do Proxies map?  was 
	RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
Date: Thu, 9 Jan 2003 10:25:40 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

> - Recognizing patterns so that one can keep the old 
> "no-need-to-hit-dial" user interface.

AAAAAUUUUGGGHHHHH!!! AAAAAUUUUGGGHHHHH!!! AAAAAUUUUGGGHHHHH!!!

No!

Cell phones have sufficiently trained the public that it's
okay to hit something like "OK" or "YES" or "DIAL" or "ENTER"
after a phone number. It makes life so much easier for user
interface designers and users alike. For the love of all that
is good, let's not encourage backsliding.

/a
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  9 11:43:40 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17214
	for <sipping-archive@odin.ietf.org>; Thu, 9 Jan 2003 11:43:40 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h09GtP605422
	for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 11:55:25 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09GtPJ05419
	for <sipping-web-archive@optimus.ietf.org>; Thu, 9 Jan 2003 11:55:25 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17177
	for <sipping-web-archive@ietf.org>; Thu, 9 Jan 2003 11:42:33 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09GrZJ05354;
	Thu, 9 Jan 2003 11:53:35 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09GqAJ05274
	for <sipping@optimus.ietf.org>; Thu, 9 Jan 2003 11:52:10 -0500
Received: from hoemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17133
	for <sipping@ietf.org>; Thu, 9 Jan 2003 11:39:53 -0500 (EST)
Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57])
	by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h09Gh7s02439
	for <sipping@ietf.org>; Thu, 9 Jan 2003 11:43:07 -0500 (EST)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19)
	id <XNTA9T11>; Thu, 9 Jan 2003 16:43:06 -0000
Message-ID: <475FF955A05DD411980D00508B6D5FB00439EB8F@en0033exch001u.uk.lucent.com>
From: "Drage, Keith (Keith)" <drage@lucent.com>
To: "'Tom-PT Taylor'" <taylor@nortelnetworks.com>,
        "'Henning Schulzrinne'"
	 <hgs@cs.columbia.edu>,
        "'sipping@ietf.org'" <sipping@ietf.org>
Subject: RE: [Sipping] Comments on sos draft -0
Date: Thu, 9 Jan 2003 16:43:04 -0000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

Is the number 3333 on an internal network an emergency number in the terms of the sos draft?

The way I read the defined sos url is that it only reachs public emergency service centres. therefore the scope of the document with regard to tel urls is to define the format of tel urls to reach those same centres. Have I misunderstood the scope? We possible need to extend Hennings proposed scope to make this clear.

I do think we need to delve further into the subject of context, possible in association with additional clarifications in the rfc2806bis draft. I note that the text there has a special case dealing with 800 numbers, viz:
   "National freephone numbers do not need a context, even though they     |
   are not necessarily reachable from outside a particular country code   |
   or numbering plan. Recall that "tel" URIs are identifiers; it is       |
   sufficient that a global number is unique, but it is not required      |
   that it be reachable from everywhere." 

It therefore seems to me that we could say the same about emergency numbers that are globally unique. 

For those emergency numbers that are not globally unique (and we probably need to include 118 and 119 in this list), then looking at the existing RFC 2806 or at the bis, they probably do need a context. What worries me is that the user sticks in an inappropriate context, i.e. the one he uses for all his local calls, rather than one used for national calls. Such inappropriate usage would cause calls to fail. Would a special context used only for local service numbers be appropriate here? My thinking here is that if we give the user something real to code, then he will not be tempted to code something inappropriate.                                  

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: drage@lucent.com 

> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> Sent: 08 January 2003 14:54
> To: 'Drage, Keith (Keith)'; 'Henning Schulzrinne'; 'sipping@ietf.org'
> Subject: RE: [Sipping] Comments on sos draft -0
> 
> 
> A comment on one point only.
> 
> > -----Original Message-----
> > From: Drage, Keith (Keith) [mailto:drage@lucent.com] 
> > Sent: Monday, January 06, 2003 10:56 AM
> > To: 'Henning Schulzrinne'; 'sipping@ietf.org'
> > Subject: [Sipping] Comments on sos draft -0
> > 
> [snip]
> > 
> > 6)	section 3 (Emergency URI), 3rd paragraph: use of 
> > "phone-context". Is it appropriate to use phone context in 
> > any emergency call. In 3GPP, any use of one of the numbers 
> > from the list stored in the phone is an emergency call, no 
> > matter where it originates from. If my understanding of 
> > phone-context is correct, it SHOULD NOT be used, as it could 
> > result in failure to deliver an emergency call.
> > 
> [PTT] My company has a scheme where "3333" on the internal 
> network reaches
> an internal emergency response centre who then direct the 
> call externally if
> required.  This was introduced to ensure that emergency vehicles are
> directed to the right building and building entrance.  It might be
> conceivable under such an arrangement to have a phone-context in the
> original Request-URI.
> 
> [snip]
> > 
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  9 12:54:54 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19008
	for <sipping-archive@odin.ietf.org>; Thu, 9 Jan 2003 12:54:54 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h09I6fj10102
	for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 13:06:41 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09I6fJ10099
	for <sipping-web-archive@optimus.ietf.org>; Thu, 9 Jan 2003 13:06:41 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18893
	for <sipping-web-archive@ietf.org>; Thu, 9 Jan 2003 12:51:05 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09I2HJ09937;
	Thu, 9 Jan 2003 13:02:17 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09I1AJ09884
	for <sipping@optimus.ietf.org>; Thu, 9 Jan 2003 13:01:10 -0500
Received: from auemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18840
	for <sipping@ietf.org>; Thu, 9 Jan 2003 12:48:52 -0500 (EST)
Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57])
	by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h09Hq7Y05188
	for <sipping@ietf.org>; Thu, 9 Jan 2003 12:52:07 -0500 (EST)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19)
	id <XNTA9V8M>; Thu, 9 Jan 2003 17:52:06 -0000
Message-ID: <475FF955A05DD411980D00508B6D5FB00439EB90@en0033exch001u.uk.lucent.com>
From: "Drage, Keith (Keith)" <drage@lucent.com>
To: "'Henning Schulzrinne'" <hgs@cs.columbia.edu>,
        "Drage, Keith (Keith)"
	 <drage@lucent.com>
Cc: "'sipping@ietf.org'" <sipping@ietf.org>
Subject: RE: [Sipping] Comments on sos draft -03 (URI)
Date: Thu, 9 Jan 2003 17:52:03 -0000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

See below - I have snipped out the areas where I am happy with the response, or have replied elsewhere.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: drage@lucent.com 

> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: 06 January 2003 23:11
> To: Drage, Keith (Keith)
> Cc: 'sipping@ietf.org'
> Subject: Re: [Sipping] Comments on sos draft -03 (URI)
> 
> 
> > 8)	Section 4 (Request handling), text: "It is RECOMMENDED that user
> > agents periodically automatically check for the availability....". I
> > consider that the use of this may be unnecessary in all 
> cases. If the
> > phone can be loaded with emergency numbers dynamically, and the
> > update of those numbers is of reasonable frequency, then there is no
> > need to regularly perform the OPTIONS request. For this reason, it
> > would appear to be unnecessary for 3GPP phones.
> 
> The problem is that I can't rely on a local friendly outbound 
> proxy that 
> knows how to handle either sip:sos or tel:XXX. You can 
> mandate this for 
> 3GPP providers, but not all VoIP systems will be run by 
> common carriers.
> 
> I'm reluctant to encode 'I'm a 3GPP phone, so I don't need to 
> do this' 
> into the protocol. After all, this 3GPP phone may also use 
> your friendly 
> neighborhood 802.11 hotspot.
> 
> 
> > 
Firstly I note that the requirement already was only a SHOULD rather than a MUST. In the case where SHOULD is used I usually prefer to specify some examples of where the SHOULD does not apply as guidance, and this appeared to be the appropriate one.

From what you are saying, the flaw in the argument is that 3GPP controls the routeing to the emergency call centre as well as the downloading of numbers to the UA, and therefore can say that if a number is downloaded it will work, and therefore the the testing of the numbers is not needed. In a more general case the DHCP server or whatever may be providing information in the emergency numbers to the UE may not be provided by the same provider who does the routeing to the emergency call centre and therefore such numbers may fail, and as a result, should be tested.

I am not convinced by the argument; that may be answered by what do we expect the UA to do if the OPTIONS request it sends to the tel url it has been given fails? If the user dials that tel url, does the UA continue to treat such a call as an emergency call, or does it flash a message on the users display saying "I don't know what to do with this"?
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  9 13:20:21 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19806
	for <sipping-archive@odin.ietf.org>; Thu, 9 Jan 2003 13:20:21 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h09IW8612257
	for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 13:32:08 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09IW8J12254
	for <sipping-web-archive@optimus.ietf.org>; Thu, 9 Jan 2003 13:32:08 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19736
	for <sipping-web-archive@ietf.org>; Thu, 9 Jan 2003 13:18:52 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09ITlJ11912;
	Thu, 9 Jan 2003 13:29:47 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09IMXJ11513
	for <sipping@optimus.ietf.org>; Thu, 9 Jan 2003 13:22:33 -0500
Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19503
	for <sipping@ietf.org>; Thu, 9 Jan 2003 13:10:13 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h09IE5qW026530;
	Thu, 9 Jan 2003 13:14:05 -0500 (EST)
Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAX61833;
	Thu, 9 Jan 2003 13:18:22 -0500 (EST)
Message-ID: <3E1DBBC0.6020704@cisco.com>
Date: Thu, 09 Jan 2003 13:13:20 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
CC: "'Henning Schulzrinne'" <hgs@cs.columbia.edu>,
        "'sipping@ietf.org'" <sipping@ietf.org>
Subject: Re: [Sipping] Do Phones Have Dial Plans, or do Proxies map?  was
 	RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
References: <313680C9A886D511A06000204840E1CF030B5CF4@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Unless we are going to require users to enter full URIs into the phone 
(including "tel:"), the phone MUST have some sort of dial plan. We only 
need to discuss how complex it is.

At one extreme it could simply be to prefix the entered digits with 
"tel:" and let a proxy do the rest.

At the other extreme it could do all sorts of complex transformations to 
turn short sequences into global tel: uris, or even sip uris, possibly 
even chosing different gateways based on dialed number.

As I mentioned in an earlier reply, simply slapping "tel:" on the 
entered digits doesn't create syntactically correct tel: uris according 
to the latest definition. To go that way, the tel: syntax needs to be 
altered. Also, the tel: definition currently says that a tel: address 
SHOULD always use global syntax unless there is no valid global address. 
Encoding dialed digits as a local tel: uri and defering conversion to a 
global address to a proxy would violate that rule.

One possibility is to define the minimal dial plan for a phone as: 
prefix the dialed digits with "tel:" and suffix the dialed digits with 
";phone-context=XXX", where XXX needs to be learned or provisioned 
somewhere. The XXX is then effectively a name for the dial plan to be 
used to expand the number. This gets around the syntax problem with 
using the tel: uri, though it still violates the semantic rule.

	Paul

Rosen, Brian wrote:
> The systems I'm aware of use regexps in one form or another
> to mangle a string into a dialed number.  I don't have
> a problem making this a UA function, but if we do, I want
> to standardize the regexp and "Publish" it to the UA.
> 
> A lot of enterprise gateways have dial string to dialed number mapping.
> Some sipphones do.
> 
> Brian
> 
> 
> 
> 
>>-----Original Message-----
>>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
>>Sent: Thursday, January 09, 2003 10:32 AM
>>To: Rosen, Brian
>>Cc: 'Paul Kyzivat'; 'sipping@ietf.org'
>>Subject: Re: [Sipping] Do Phones Have Dial Plans, or do 
>>Proxies map? was
>>RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
>>
>>
>>I would find it instructive how non-SIP systems have solved similar 
>>problems. In web browsers and email, we have auto-completion 
>>functions 
>>and nick names, for examples.
>>
>>There's also the analogy with 'real names' (not the defunct 
>>company, the 
>>concept) which translates strings-nice-for-humans into URLs. 
>>See the CRN 
>>work, including the go: URL. (I'm not aware of implemenentations, but 
>>the concept may be relevant, in particular keeping the identifier and 
>>various 'nicknames' clearly distinct.)
>>
>>There are probably two sub-problems here:
>>
>>- Recognizing patterns so that one can keep the old 
>>"no-need-to-hit-dial" user interface.
>>
>>- Translating abbreviations such as extensions and local-area 
>>numbers to 
>>fully-expanded, globally unique identifiers.
>>
>>The former will always require downloading a pattern to an 
>>end system, 
>>the latter is a (local) translation service. The only question then 
>>becomes if the translation is done in one or two steps, i.e., before 
>>issuing a SIP request or as part of a SIP request.
>>
>>Aside: There are clearly examles of widely-deployed systems where the 
>>phone has a dial-plan, downloaded via tftp.
>>
>>Rosen, Brian wrote:
>>
>>>This comes up a lot.  I think we should decide.
>>>
>>>Who translates a dial string into a tel uri?
>>>
>>>tel uris, as of now, explicitly don't handle dialing strings,
>>>only dialed numbers.  In essentially all existing systems,
>>>phones don't have dialing plans in them; central elements
>>>map dialing strings to dialed numbers.  What's our story?
>>>Does every UA that has a dial pad have to have a dialing plan 
>>>loaded in it that maps dialing strings to dialed numbers, 
>>>or does a proxy server do it?
>>>
>>>If it's the former, then how do we standardize the mapping?
>>>If it's the latter, then how does a UA send a dialing string?
>>>
>>>Brian
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
>>>>Sent: Thursday, January 09, 2003 9:53 AM
>>>>To: 'sipping@ietf.org'
>>>>Subject: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
>>>>
>>>>
>>>>I have a few comments about draft-schulzrinne-sipping-sos-04.txt.
>>>>(I haven't been following this work very closely, so 
>>>
>>perhaps some of 
>>
>>>>these pertain to things that were in earlier drafts.)
>>>>
>>>>I must say, these are really messy problems, so I am glad you are 
>>>>working on them.
>>>>
>>>>Section 3.2 says:
>>>>
>>>>   ... a UAC MAY use a "tel" URI [3,4] without 
>>>
>>phone-context, such as
>>
>>>>   tel:911
>>>>   tel:112
>>>>
>>>>The latest and greatest definition of the tel: uri that I 
>>>
>>can find is 
>>
>>>>draft-antti-rfc2806bis-07.txt. According to that, the above 
>>>
>>tel: uris 
>>
>>>>are syntactically incorrect. Either the number must be global 
>>>>or else it 
>>>>must contain a phone-context parameter.
>>>>
>>>>Are there plans to change the definition of the tel uri, or is this 
>>>>language going to change?
>>>>
>>>>In the case of a UAC that is using a local outbound proxy, is it 
>>>>required that the UAC specifically recognize these strings 
>>>>and deliver 
>>>>them to the proxy, or is it sufficient for it to deliver 
>>>
>>any and all 
>>
>>>>dialed digit strings to the proxy as tel uris without attempting to 
>>>>recognize them itself? Is it sufficient to determine that 
>>>
>>the dialed 
>>
>>>>number is complete by timeout on the input rather than by 
>>>
>>recognition?
>>
>>>>Section 5 specifies that the UAC should insert location 
>>>>information into 
>>>>emergency calls. However, presumably location information should in 
>>>>general not be placed in non-emergency calls, so it is 
>>>
>>important that 
>>
>>>>the UAC realize it is making an emergency call. In the case 
>>>
>>of dialed 
>>
>>>>digit strings, it may only be the outbound proxy that can 
>>>>determine if 
>>>>the call is an emergency call. One way to handle this would 
>>>>be for the 
>>>>local outbound proxy to redirect requests to tel: emergency 
>>>>numbers to 
>>>>the corresponding sip:sos number. Then the UAC would be able to 
>>>>positively determine this is an emergency call and include 
>>>>the location 
>>>>information.
>>>>
>>>>Section 9 says:
>>>>
>>>>   We propose a new DHCP option that enumerates the valid local
>>>>   emergency identifiers, as a list of "tel", "sip" or "sips" URIs.
>>>>
>>>>This doesn't seem sufficient. Most phone-like devices have 
>>>>provision for 
>>>>entering primarily sequences of digits, not tel: uris. It is 
>>>>up to the 
>>>>phone to translate a digit sequence into a valid uri. In 
>>>
>>general this 
>>
>>>>requires some sort of dial plan. Without the dial plan, the 
>>>
>>phone may 
>>
>>>>well not be able to generate anything that matches one of the 
>>>>specified 
>>>>tel uris.
>>>>
>>>>	Paul
>>>>
>>>>_______________________________________________
>>>>Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>>>>This list is for NEW development of the application of SIP
>>>>Use sip-implementors@cs.columbia.edu for questions on current sip
>>>>Use sip@ietf.org for new developments of core SIP
>>>>
>>>
>>>_______________________________________________
>>>Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>>>This list is for NEW development of the application of SIP
>>>Use sip-implementors@cs.columbia.edu for questions on current sip
>>>Use sip@ietf.org for new developments of core SIP
>>
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  9 13:20:22 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19817
	for <sipping-archive@odin.ietf.org>; Thu, 9 Jan 2003 13:20:22 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h09IWAP12273
	for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 13:32:10 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09IWAJ12270
	for <sipping-web-archive@optimus.ietf.org>; Thu, 9 Jan 2003 13:32:10 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19745
	for <sipping-web-archive@ietf.org>; Thu, 9 Jan 2003 13:19:19 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09IU5J11980;
	Thu, 9 Jan 2003 13:30:05 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09ITvJ11924
	for <sipping@optimus.ietf.org>; Thu, 9 Jan 2003 13:29:57 -0500
Received: from znsgs01r.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19667
	for <sipping@ietf.org>; Thu, 9 Jan 2003 13:17:38 -0500 (EST)
Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124])
	by znsgs01r.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h09I8nw03867;
	Thu, 9 Jan 2003 18:08:49 GMT
Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19)
	id <ZFFSSCKN>; Thu, 9 Jan 2003 18:08:49 -0000
Message-ID: <A3C2399B2FACD411A54200508BE39C74054F7A81@zwcwd00r.europe.nortel.com>
From: "Mark Watson" <mwatson@nortelnetworks.com>
To: "'Adam Roach'" <adam@dynamicsoft.com>,
        "'Henning Schulzrinne'"
	 <hgs@cs.columbia.edu>,
        "Rosen, Brian" <Brian.Rosen@marconi.com>
Cc: "'Paul Kyzivat'" <pkyzivat@cisco.com>,
        "'sipping@ietf.org'"
	 <sipping@ietf.org>
Subject: RE: [Sipping] Do Phones Have Dial Plans, or do Proxies map?  was 
	 RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
Date: Thu, 9 Jan 2003 18:08:46 -0000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2B80A.272462F8"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2B80A.272462F8
Content-Type: text/plain;
	charset="iso-8859-1"

Adam wrote:

> AAAAAUUUUGGGHHHHH!!! AAAAAUUUUGGGHHHHH!!! AAAAAUUUUGGGHHHHH!!!
> 
> No!

Is overlap dialling **really** that bad :-) (ok, ok, I know, it is)

I'd agree you should really try and avoid UIs without an 'end of dialing'
key whenever you can. You can't rely on any regexp to tell you when the end
of dialling is - at least obtaining and maintaining such a regexp for the
global E.164 dial-plan would be infeasible. Even for some national dialling
plans it is infeasible.

No 'end of dialling' key = overlap or inter-digit timers, end of story.

...Mark

 

------_=_NextPart_001_01C2B80A.272462F8
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>RE: [Sipping] Do Phones Have Dial Plans, or do Proxies map?  was =
 RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Adam wrote:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; AAAAAUUUUGGGHHHHH!!! AAAAAUUUUGGGHHHHH!!! =
AAAAAUUUUGGGHHHHH!!!</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; No!</FONT>
</P>

<P><FONT SIZE=3D2>Is overlap dialling **really** that bad :-) (ok, ok, =
I know, it is)</FONT>
</P>

<P><FONT SIZE=3D2>I'd agree you should really try and avoid UIs without =
an 'end of dialing' key whenever you can. You can't rely on any regexp =
to tell you when the end of dialling is - at least obtaining and =
maintaining such a regexp for the global E.164 dial-plan would be =
infeasible. Even for some national dialling plans it is =
infeasible.</FONT></P>

<P><FONT SIZE=3D2>No 'end of dialling' key =3D overlap or inter-digit =
timers, end of story.</FONT>
</P>

<P><FONT SIZE=3D2>...Mark</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2B80A.272462F8--
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  9 13:38:14 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20383
	for <sipping-archive@odin.ietf.org>; Thu, 9 Jan 2003 13:38:14 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h09Io2l13829
	for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 13:50:02 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09Io2J13826
	for <sipping-web-archive@optimus.ietf.org>; Thu, 9 Jan 2003 13:50:02 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20340
	for <sipping-web-archive@ietf.org>; Thu, 9 Jan 2003 13:37:23 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09ImHJ13743;
	Thu, 9 Jan 2003 13:48:17 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09IlpJ13700
	for <sipping@optimus.ietf.org>; Thu, 9 Jan 2003 13:47:51 -0500
Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20310
	for <sipping@ietf.org>; Thu, 9 Jan 2003 13:35:31 -0500 (EST)
Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h09Iav53018766;
	Thu, 9 Jan 2003 13:37:00 -0500 (EST)
Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <W6F4GBZ5>; Thu, 9 Jan 2003 12:38:22 -0600
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A643FB@DYN-TX-EXCH-001.dynamicsoft.com>
From: Adam Roach <adam@dynamicsoft.com>
To: "'Henning Schulzrinne'" <hgs@cs.columbia.edu>,
        "Rosen, Brian"
	 <Brian.Rosen@marconi.com>
Cc: "'Paul Kyzivat'" <pkyzivat@cisco.com>,
        "'sipping@ietf.org'"
	 <sipping@ietf.org>
Subject: RE: [Sipping] Do Phones Have Dial Plans, or do Proxies map?  was 
	RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
Date: Thu, 9 Jan 2003 12:38:21 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

> - Translating abbreviations such as extensions and local-area 
> numbers to 
> fully-expanded, globally unique identifiers.

It's also interesting to note that many systems (e.g. PBXes)
include extensions that don't have an external representation.

For example, let's imaine a company that has a PBX with an
assigned range of +1-713-555-8xxx. They use 4-digit internal
dialling. Some extensions (e.g. 8123) can have an external
mapping (+1 713 555 8123). Others, like 3123, can't be reached
externally. They *can't* exist as fully-expanded, globally unique
identifiers.

So, how exactly do we address this? I see several options:

1) Allow "tel:" to include dialled digit strings, possibly
   with some parameter to indicate as much.

2) Create a new URI that is defined to carry dialled digits.

Both of these have their own rather obvious problems.
Can someone think of an alternate solution?

/a
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  9 13:45:00 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20508
	for <sipping-archive@odin.ietf.org>; Thu, 9 Jan 2003 13:45:00 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h09Iuma14046
	for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 13:56:48 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09IumJ14043
	for <sipping-web-archive@optimus.ietf.org>; Thu, 9 Jan 2003 13:56:48 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20496
	for <sipping-web-archive@ietf.org>; Thu, 9 Jan 2003 13:44:28 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09ItBJ13995;
	Thu, 9 Jan 2003 13:55:11 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09IsRJ13951
	for <sipping@optimus.ietf.org>; Thu, 9 Jan 2003 13:54:27 -0500
Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20429
	for <sipping@ietf.org>; Thu, 9 Jan 2003 13:42:07 -0500 (EST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA05945;
	Thu, 9 Jan 2003 13:45:22 -0500 (EST)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA18461;
	Thu, 9 Jan 2003 13:45:23 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <ZVACMSFP>; Thu, 9 Jan 2003 13:45:23 -0500
Message-ID: <313680C9A886D511A06000204840E1CF030B5CF9@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Paul Kyzivat'" <pkyzivat@cisco.com>
Cc: "'Henning Schulzrinne'" <hgs@cs.columbia.edu>,
        "'sipping@ietf.org'"
	 <sipping@ietf.org>
Subject: RE: [Sipping] Do Phones Have Dial Plans, or do Proxies map?  was 
	RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
Date: Thu, 9 Jan 2003 13:45:22 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

I think this response just restates the question.  
I think we either say that phones essentially always put out 
global numbers, or they put out dialing strings and a proxy 
expands it.  We can probably agree on the tel uri prefix for
either.  If a proxy expands dialing strings to phone numbers,
then we probably do need some kind of context, as you point out.

First we should decide if we put the dialing plan in the phone.

BTW, I currently favor NOT putting the dialing plan in the UA,
but I don't feel strongly about it.  I do feel strongly about
standardizing this bit, because I surely want all sipphones to
"play" in my system, and I don't want a boat-load of vendor specific
code to make that work.

Our sip based enterprise system has a classical enterprise dialing 
plan, although we interpret 7 or more digits as national or 
international numbers, rather than requiring the "9" prefix.  
That works because all internal numbers are less than 7 digits.  
Proxies do the expansion.  There is vendor specific code in this 
proxy because no two gateways we support work the same.  
Hence this entire effort :)

Brian

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Thursday, January 09, 2003 1:13 PM
> To: Rosen, Brian
> Cc: 'Henning Schulzrinne'; 'sipping@ietf.org'
> Subject: Re: [Sipping] Do Phones Have Dial Plans, or do 
> Proxies map? was
> RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
> 
> 
> Unless we are going to require users to enter full URIs into 
> the phone 
> (including "tel:"), the phone MUST have some sort of dial 
> plan. We only 
> need to discuss how complex it is.
> 
> At one extreme it could simply be to prefix the entered digits with 
> "tel:" and let a proxy do the rest.
> 
> At the other extreme it could do all sorts of complex 
> transformations to 
> turn short sequences into global tel: uris, or even sip uris, 
> possibly 
> even chosing different gateways based on dialed number.
> 
> As I mentioned in an earlier reply, simply slapping "tel:" on the 
> entered digits doesn't create syntactically correct tel: uris 
> according 
> to the latest definition. To go that way, the tel: syntax needs to be 
> altered. Also, the tel: definition currently says that a tel: address 
> SHOULD always use global syntax unless there is no valid 
> global address. 
> Encoding dialed digits as a local tel: uri and defering 
> conversion to a 
> global address to a proxy would violate that rule.
> 
> One possibility is to define the minimal dial plan for a phone as: 
> prefix the dialed digits with "tel:" and suffix the dialed 
> digits with 
> ";phone-context=XXX", where XXX needs to be learned or provisioned 
> somewhere. The XXX is then effectively a name for the dial plan to be 
> used to expand the number. This gets around the syntax problem with 
> using the tel: uri, though it still violates the semantic rule.
> 
> 	Paul
> 
> Rosen, Brian wrote:
> > The systems I'm aware of use regexps in one form or another
> > to mangle a string into a dialed number.  I don't have
> > a problem making this a UA function, but if we do, I want
> > to standardize the regexp and "Publish" it to the UA.
> > 
> > A lot of enterprise gateways have dial string to dialed 
> number mapping.
> > Some sipphones do.
> > 
> > Brian
> > 
> > 
> > 
> > 
> >>-----Original Message-----
> >>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> >>Sent: Thursday, January 09, 2003 10:32 AM
> >>To: Rosen, Brian
> >>Cc: 'Paul Kyzivat'; 'sipping@ietf.org'
> >>Subject: Re: [Sipping] Do Phones Have Dial Plans, or do 
> >>Proxies map? was
> >>RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
> >>
> >>
> >>I would find it instructive how non-SIP systems have solved similar 
> >>problems. In web browsers and email, we have auto-completion 
> >>functions 
> >>and nick names, for examples.
> >>
> >>There's also the analogy with 'real names' (not the defunct 
> >>company, the 
> >>concept) which translates strings-nice-for-humans into URLs. 
> >>See the CRN 
> >>work, including the go: URL. (I'm not aware of 
> implemenentations, but 
> >>the concept may be relevant, in particular keeping the 
> identifier and 
> >>various 'nicknames' clearly distinct.)
> >>
> >>There are probably two sub-problems here:
> >>
> >>- Recognizing patterns so that one can keep the old 
> >>"no-need-to-hit-dial" user interface.
> >>
> >>- Translating abbreviations such as extensions and local-area 
> >>numbers to 
> >>fully-expanded, globally unique identifiers.
> >>
> >>The former will always require downloading a pattern to an 
> >>end system, 
> >>the latter is a (local) translation service. The only question then 
> >>becomes if the translation is done in one or two steps, 
> i.e., before 
> >>issuing a SIP request or as part of a SIP request.
> >>
> >>Aside: There are clearly examles of widely-deployed systems 
> where the 
> >>phone has a dial-plan, downloaded via tftp.
> >>
> >>Rosen, Brian wrote:
> >>
> >>>This comes up a lot.  I think we should decide.
> >>>
> >>>Who translates a dial string into a tel uri?
> >>>
> >>>tel uris, as of now, explicitly don't handle dialing strings,
> >>>only dialed numbers.  In essentially all existing systems,
> >>>phones don't have dialing plans in them; central elements
> >>>map dialing strings to dialed numbers.  What's our story?
> >>>Does every UA that has a dial pad have to have a dialing plan 
> >>>loaded in it that maps dialing strings to dialed numbers, 
> >>>or does a proxy server do it?
> >>>
> >>>If it's the former, then how do we standardize the mapping?
> >>>If it's the latter, then how does a UA send a dialing string?
> >>>
> >>>Brian
> >>>
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> >>>>Sent: Thursday, January 09, 2003 9:53 AM
> >>>>To: 'sipping@ietf.org'
> >>>>Subject: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
> >>>>
> >>>>
> >>>>I have a few comments about draft-schulzrinne-sipping-sos-04.txt.
> >>>>(I haven't been following this work very closely, so 
> >>>
> >>perhaps some of 
> >>
> >>>>these pertain to things that were in earlier drafts.)
> >>>>
> >>>>I must say, these are really messy problems, so I am glad you are 
> >>>>working on them.
> >>>>
> >>>>Section 3.2 says:
> >>>>
> >>>>   ... a UAC MAY use a "tel" URI [3,4] without 
> >>>
> >>phone-context, such as
> >>
> >>>>   tel:911
> >>>>   tel:112
> >>>>
> >>>>The latest and greatest definition of the tel: uri that I 
> >>>
> >>can find is 
> >>
> >>>>draft-antti-rfc2806bis-07.txt. According to that, the above 
> >>>
> >>tel: uris 
> >>
> >>>>are syntactically incorrect. Either the number must be global 
> >>>>or else it 
> >>>>must contain a phone-context parameter.
> >>>>
> >>>>Are there plans to change the definition of the tel uri, 
> or is this 
> >>>>language going to change?
> >>>>
> >>>>In the case of a UAC that is using a local outbound proxy, is it 
> >>>>required that the UAC specifically recognize these strings 
> >>>>and deliver 
> >>>>them to the proxy, or is it sufficient for it to deliver 
> >>>
> >>any and all 
> >>
> >>>>dialed digit strings to the proxy as tel uris without 
> attempting to 
> >>>>recognize them itself? Is it sufficient to determine that 
> >>>
> >>the dialed 
> >>
> >>>>number is complete by timeout on the input rather than by 
> >>>
> >>recognition?
> >>
> >>>>Section 5 specifies that the UAC should insert location 
> >>>>information into 
> >>>>emergency calls. However, presumably location information 
> should in 
> >>>>general not be placed in non-emergency calls, so it is 
> >>>
> >>important that 
> >>
> >>>>the UAC realize it is making an emergency call. In the case 
> >>>
> >>of dialed 
> >>
> >>>>digit strings, it may only be the outbound proxy that can 
> >>>>determine if 
> >>>>the call is an emergency call. One way to handle this would 
> >>>>be for the 
> >>>>local outbound proxy to redirect requests to tel: emergency 
> >>>>numbers to 
> >>>>the corresponding sip:sos number. Then the UAC would be able to 
> >>>>positively determine this is an emergency call and include 
> >>>>the location 
> >>>>information.
> >>>>
> >>>>Section 9 says:
> >>>>
> >>>>   We propose a new DHCP option that enumerates the valid local
> >>>>   emergency identifiers, as a list of "tel", "sip" or 
> "sips" URIs.
> >>>>
> >>>>This doesn't seem sufficient. Most phone-like devices have 
> >>>>provision for 
> >>>>entering primarily sequences of digits, not tel: uris. It is 
> >>>>up to the 
> >>>>phone to translate a digit sequence into a valid uri. In 
> >>>
> >>general this 
> >>
> >>>>requires some sort of dial plan. Without the dial plan, the 
> >>>
> >>phone may 
> >>
> >>>>well not be able to generate anything that matches one of the 
> >>>>specified 
> >>>>tel uris.
> >>>>
> >>>>	Paul
> >>>>
> >>>>_______________________________________________
> >>>>Sipping mailing list  
https://www1.ietf.org/mailman/listinfo/sipping
>>>>This list is for NEW development of the application of SIP
>>>>Use sip-implementors@cs.columbia.edu for questions on current sip
>>>>Use sip@ietf.org for new developments of core SIP
>>>>
>>>
>>>_______________________________________________
>>>Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>>>This list is for NEW development of the application of SIP
>>>Use sip-implementors@cs.columbia.edu for questions on current sip
>>>Use sip@ietf.org for new developments of core SIP
>>
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  9 14:02:16 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21986
	for <sipping-archive@odin.ietf.org>; Thu, 9 Jan 2003 14:02:16 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h09JE5D16199
	for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 14:14:05 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09JE5J16196
	for <sipping-web-archive@optimus.ietf.org>; Thu, 9 Jan 2003 14:14:05 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21928
	for <sipping-web-archive@ietf.org>; Thu, 9 Jan 2003 14:01:44 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09JAOJ15962;
	Thu, 9 Jan 2003 14:10:24 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09J9hJ15920
	for <sipping@optimus.ietf.org>; Thu, 9 Jan 2003 14:09:43 -0500
Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21436
	for <sipping@ietf.org>; Thu, 9 Jan 2003 13:57:22 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h09J14Yc005237;
	Thu, 9 Jan 2003 14:01:04 -0500 (EST)
Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAX62371;
	Thu, 9 Jan 2003 14:05:22 -0500 (EST)
Message-ID: <3E1DC6C5.1060606@cisco.com>
Date: Thu, 09 Jan 2003 14:00:21 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Adam Roach <adam@dynamicsoft.com>
CC: "'Henning Schulzrinne'" <hgs@cs.columbia.edu>,
        "Rosen, Brian" <Brian.Rosen@marconi.com>,
        "'sipping@ietf.org'" <sipping@ietf.org>
Subject: Re: [Sipping] Do Phones Have Dial Plans, or do Proxies map?  was
 	RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
References: <9BF66EBF6BEFD942915B4D4D45C051F3A643FB@DYN-TX-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

I believe the current definition of tel: would want you to translate 
these numbers as follows:

   8123 => tel:+17135558123
   3123 => tel:3123;phone-context=+17135558

(Or use some other context, but this one should be legal for your case.)

This is no problem as long as the phone is presumed to have a full and 
complete dial plan that can turn ever dialed number into the proper 
valid tel: uri.

The problem comes if you want this task to be performed someplace else, 
like in a local outbound proxy. In that case, you need some way to 
convey the dialed digits to the proxy, where it can do its magic. See my 
earlier message for more on that.

	Paul

Adam Roach wrote:
>>- Translating abbreviations such as extensions and local-area 
>>numbers to 
>>fully-expanded, globally unique identifiers.
> 
> 
> It's also interesting to note that many systems (e.g. PBXes)
> include extensions that don't have an external representation.
> 
> For example, let's imaine a company that has a PBX with an
> assigned range of +1-713-555-8xxx. They use 4-digit internal
> dialling. Some extensions (e.g. 8123) can have an external
> mapping (+1 713 555 8123). Others, like 3123, can't be reached
> externally. They *can't* exist as fully-expanded, globally unique
> identifiers.
> 
> So, how exactly do we address this? I see several options:
> 
> 1) Allow "tel:" to include dialled digit strings, possibly
>    with some parameter to indicate as much.
> 
> 2) Create a new URI that is defined to carry dialled digits.
> 
> Both of these have their own rather obvious problems.
> Can someone think of an alternate solution?
> 
> /a
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  9 14:23:37 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23246
	for <sipping-archive@odin.ietf.org>; Thu, 9 Jan 2003 14:23:36 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h09JZQc17581
	for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 14:35:26 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09JZQJ17578
	for <sipping-web-archive@optimus.ietf.org>; Thu, 9 Jan 2003 14:35:26 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23219
	for <sipping-web-archive@ietf.org>; Thu, 9 Jan 2003 14:23:05 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09JYMJ17526;
	Thu, 9 Jan 2003 14:34:22 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09JXeJ17432
	for <sipping@optimus.ietf.org>; Thu, 9 Jan 2003 14:33:40 -0500
Received: from imo-r02.mx.aol.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23162
	for <sipping@ietf.org>; Thu, 9 Jan 2003 14:21:19 -0500 (EST)
From: Mpierce1@aol.com
Received: from Mpierce1@aol.com
	by imo-r02.mx.aol.com (mail_out_v34.13.) id 7.fe.21b2f31b (17079);
	Thu, 9 Jan 2003 14:24:08 -0500 (EST)
Message-ID: <fe.21b2f31b.2b4f2658@aol.com>
Date: Thu, 9 Jan 2003 14:24:08 EST
Subject: Re: [Sipping] Comments on sos draft -03 (URI)
To: hgs@cs.columbia.edu
CC: Brian.Rosen@marconi.com, sipping@ietf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="part1_fe.21b2f31b.2b4f2658_boundary"
X-Mailer: AOL 6.0 for Windows XP US sub 51
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>


--part1_fe.21b2f31b.2b4f2658_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

In a message dated 1/8/2003 9:40:46 AM Eastern Standard Time, 
hgs@cs.columbia.edu writes:


> In other words, if a hotel in Europe 
> doesn't have room 911, it should allow this as an emergency number, to 
> accomodate the US or Canadian traveler.
> 


No, this is not correct. I doubt that any European regulatory body would 
accept this. If 911 is not assigned in the local environment, the call must 
go to "intercept".

Mike Pierce
Artel


--part1_fe.21b2f31b.2b4f2658_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

<HTML><FONT FACE=arial,helvetica><FONT  SIZE=2>In a message dated 1/8/2003 9:40:46 AM Eastern Standard Time, hgs@cs.columbia.edu writes:
<BR>
<BR>
<BR><BLOCKQUOTE TYPE=CITE style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">In other words, if a hotel in Europe 
<BR>doesn't have room 911, it should allow this as an emergency number, to 
<BR>accomodate the US or Canadian traveler.
<BR></FONT><FONT  COLOR="#000000" SIZE=3 FAMILY="SANSSERIF" FACE="Arial" LANG="0"></BLOCKQUOTE>
<BR></FONT><FONT  COLOR="#000000" SIZE=2 FAMILY="SANSSERIF" FACE="Arial" LANG="0">
<BR>
<BR>No, this is not correct. I doubt that any European regulatory body would accept this. If 911 is not assigned in the local environment, the call must go to "intercept".
<BR>
<BR>Mike Pierce
<BR>Artel
<BR></FONT></HTML>

--part1_fe.21b2f31b.2b4f2658_boundary--
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  9 14:23:56 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23306
	for <sipping-archive@odin.ietf.org>; Thu, 9 Jan 2003 14:23:56 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h09JZjq17629
	for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 14:35:45 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09JZjJ17626
	for <sipping-web-archive@optimus.ietf.org>; Thu, 9 Jan 2003 14:35:45 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23237
	for <sipping-web-archive@ietf.org>; Thu, 9 Jan 2003 14:23:24 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09JYIJ17502;
	Thu, 9 Jan 2003 14:34:18 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09JXRJ17420
	for <sipping@optimus.ietf.org>; Thu, 9 Jan 2003 14:33:27 -0500
Received: from imo-r08.mx.aol.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23157
	for <sipping@ietf.org>; Thu, 9 Jan 2003 14:21:07 -0500 (EST)
From: Mpierce1@aol.com
Received: from Mpierce1@aol.com
	by imo-r08.mx.aol.com (mail_out_v34.13.) id 7.183.14efad93 (17079);
	Thu, 9 Jan 2003 14:24:11 -0500 (EST)
Message-ID: <183.14efad93.2b4f265b@aol.com>
Date: Thu, 9 Jan 2003 14:24:11 EST
Subject: Re: [Sipping] New -sos- draft (04)
To: hgs@cs.columbia.edu, Duncan.Mills@gb.vodafone.co.uk
CC: sipping@ietf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="part1_183.14efad93.2b4f265b_boundary"
X-Mailer: AOL 6.0 for Windows XP US sub 51
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>


--part1_183.14efad93.2b4f265b_boundary
Content-Type: text/plain; charset="UTF-8"
Content-Language: en
Content-Transfer-Encoding: quoted-printable

In a message dated 1/9/2003 8:35:40 AM Eastern Standard Time,=20
hgs@cs.columbia.edu writes:


> Mills, Duncan, D, CND Tech Dev, VF UK wrote:
> > Henning,
> >
> > A very very minor comment in case you revise the draft again:
> >
> > In section 3.2 you talk about 118 being an ambiguous number, i.e. a
> > collision exists between a Japanese emergency number and a UK
> > directory services number.  I think it is actually Finland that uses
> > 118 as a directory services number, not the UK.
>=20
> Thanks for catching this. I had been confused by the new 118XXX numbers=20
> in the UK; see=20
> http://www.oftel.gov.uk/publications/consumer/2002/dq1202.htm. These=20
> 118XXX numbers would obviously not collide.
>=20
> >
> > Another well known collision exists for 192 which is currently one of
> > the UK's directory services number and is also an emergency number in
> > Brazil.

>=20

> Apparently, according to the Oftel page above, this number is to be=20

> withdrawn. ("After the last weekend in August 2003 the existing DQ=20

> numbers such as 192 will no longer work =E2=80=93 only the 118 numbers wil=
l be=20

> available.") Fortunately, 192 isn't on the list of 'default' emergency=20

> numbers.

>=20

>=20


[MAP] What the above examples demonstrate conclusively, I hope, is that no=20
specific list of emergency numbers can be built into a phone device. No=20
matter what is done today, the set will likely change in some way in the nea=
r=20
future, and all such phones would be obsolete. This leads back to the need t=
o=20
determine if and how the phone is downloaded with the current local dial=20
plan. (See Brian Rosen's e-mail this morning.)

Mike Pierce
Artel


--part1_183.14efad93.2b4f265b_boundary
Content-Type: text/html; charset="UTF-8"
Content-Language: en
Content-Transfer-Encoding: quoted-printable

<HTML><FONT FACE=3Darial,helvetica><FONT  SIZE=3D2>In a message dated 1/9/20=
03 8:35:40 AM Eastern Standard Time, hgs@cs.columbia.edu writes:
<BR>
<BR>
<BR><BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-=
LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">Mills, Duncan, D, CND Tech=20=
Dev, VF UK wrote:
<BR>&gt; Henning,
<BR>&gt;
<BR>&gt; A very very minor comment in case you revise the draft again:
<BR>&gt;
<BR>&gt; In section 3.2 you talk about 118 being an ambiguous number, i.e. a
<BR>&gt; collision exists between a Japanese emergency number and a UK
<BR>&gt; directory services number. &nbsp;I think it is actually Finland tha=
t uses
<BR>&gt; 118 as a directory services number, not the UK.
<BR>
<BR>Thanks for catching this. I had been confused by the new 118XXX numbers=20
<BR>in the UK; see=20
<BR>http://www.oftel.gov.uk/publications/consumer/2002/dq1202.htm. These=20
<BR>118XXX numbers would obviously not collide.
<BR>
<BR>&gt;
<BR>&gt; Another well known collision exists for 192 which is currently one=20=
of
<BR>&gt; the UK's directory services number and is also an emergency number=20=
in
<BR>&gt; Brazil.<BR><BR>Apparently, according to the Oftel page above, this=20=
number is to be <BR>withdrawn. ("After the last weekend in August 2003 the e=
xisting DQ <BR>numbers such as 192 will no longer work =E2=80=93 only the 11=
8 numbers will be <BR>available.") Fortunately, 192 isn't on the list of 'de=
fault' emergency <BR>numbers.<BR><BR></FONT><FONT  COLOR=3D"#000000" SIZE=
=3D3 FAMILY=3D"SANSSERIF" FACE=3D"Arial" LANG=3D"0"></BLOCKQUOTE>
<BR></FONT><FONT  COLOR=3D"#000000" SIZE=3D2 FAMILY=3D"SANSSERIF" FACE=3D"Ar=
ial" LANG=3D"0">
<BR>
<BR>[MAP] What the above examples demonstrate conclusively, I hope, is that=20=
no specific list of emergency numbers can be built into a phone device. No m=
atter what is done today, the set will likely change in some way in the near=
 future, and all such phones would be obsolete. This leads back to the need=20=
to determine if and how the phone is downloaded with the current local dial=20=
plan. (See Brian Rosen's e-mail this morning.)
<BR>
<BR>Mike Pierce
<BR>Artel
<BR></FONT></HTML>

--part1_183.14efad93.2b4f265b_boundary--
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  9 15:01:01 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24813
	for <sipping-archive@odin.ietf.org>; Thu, 9 Jan 2003 15:01:01 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h09KCpr21686
	for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 15:12:51 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09KCpJ21682
	for <sipping-web-archive@optimus.ietf.org>; Thu, 9 Jan 2003 15:12:51 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24730
	for <sipping-web-archive@ietf.org>; Thu, 9 Jan 2003 15:00:21 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09KBRJ21286;
	Thu, 9 Jan 2003 15:11:27 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09K9dJ20995
	for <sipping@optimus.ietf.org>; Thu, 9 Jan 2003 15:09:39 -0500
Received: from imo-r04.mx.aol.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24405
	for <sipping@ietf.org>; Thu, 9 Jan 2003 14:57:17 -0500 (EST)
From: Mpierce1@aol.com
Received: from Mpierce1@aol.com
	by imo-r04.mx.aol.com (mail_out_v34.13.) id e.e.2b13d0f0 (14374);
	Thu, 9 Jan 2003 14:59:58 -0500 (EST)
Message-ID: <e.2b13d0f0.2b4f2ebd@aol.com>
Date: Thu, 9 Jan 2003 14:59:57 EST
Subject: Re: [Sipping] Do Phones Have Dial Plans, or do Proxies map?  was  RE: [Sippin...
To: Brian.Rosen@marconi.com, pkyzivat@cisco.com
CC: hgs@cs.columbia.edu, sipping@ietf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="part1_e.2b13d0f0.2b4f2ebd_boundary"
X-Mailer: AOL 6.0 for Windows XP US sub 51
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>


--part1_e.2b13d0f0.2b4f2ebd_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

In a message dated 1/9/2003 2:08:43 PM Eastern Standard Time, 
Brian.Rosen@marconi.com writes:


> First we should decide if we put the dialing plan in the phone.
> 
[MAP] As I see it, there are only two possibilities to handle a SIP call (not 
just emergency calls):

1. The phone knows the dial plan for the area it is in
2. The outging proxy knows the dial plan (of the originating phone)

WIth option 1, it is clearly unworkable for the dial plan (including 
knowledge of what the emergency number is) to be built into a phone.

It would seem to be out of the question to expect an arbitrary proxy to know 
the dial plans for all areas of the world, so I must presume that the only 
workable scheme for option 2 is for the outgoing proxy to be "local" to the 
orginator.

(There is, in effect, another case, such as the satellite service some have 
mentioned, in which the orginator has no "local" dial plan, that is, there is 
no expectation of being able to reach "local" things like emergency, repair, 
the local TV station by dialing #13, the highway patrol by dialing #77, etc. 
The only thing that can be dialed is an E.164 number, or specific "service" 
numbers that the satallite service provider themselves defines and uses.)

So there are two possibilities (when there really is a "local" dial plan):

1. A phone is loaded with the dial plan when it "registers" for service, with 
the information coming from some "local" server. It can then know when 
dialing is complete without a "Send" key, and can send the appropriate 
tel:uri (E.164 number, SOS, etc.).
2. The phone knows nothing about the dial plan, depends on the user hitting a 
"Send" key (like cellualar) and the "local" outbound proxy does all 
interpretation of the dial digit string. The phone knows nothing about 
emergency calls.

Certainly both of these should be allowed.

(If you want an example of what could be required to send a dial plan to a 
phone, one can reference RFC 2705.)

Mike Pierce
Artel


--part1_e.2b13d0f0.2b4f2ebd_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

<HTML><FONT FACE=arial,helvetica><FONT  SIZE=2>In a message dated 1/9/2003 2:08:43 PM Eastern Standard Time, Brian.Rosen@marconi.com writes:
<BR>
<BR>
<BR><BLOCKQUOTE TYPE=CITE style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">First we should decide if we put the dialing plan in the phone.
<BR></FONT><FONT  COLOR="#000000" SIZE=3 FAMILY="SANSSERIF" FACE="Arial" LANG="0"></BLOCKQUOTE>
<BR></FONT><FONT  COLOR="#000000" SIZE=2 FAMILY="SANSSERIF" FACE="Arial" LANG="0">[MAP] As I see it, there are only two possibilities to handle a SIP call (not just emergency calls):
<BR>
<BR>1. The phone knows the dial plan for the area it is in
<BR>2. The outging proxy knows the dial plan (of the originating phone)
<BR>
<BR>WIth option 1, it is clearly unworkable for the dial plan (including knowledge of what the emergency number is) to be built into a phone.
<BR>
<BR>It would seem to be out of the question to expect an arbitrary proxy to know the dial plans for all areas of the world, so I must presume that the only workable scheme for option 2 is for the outgoing proxy to be "local" to the orginator.
<BR>
<BR>(There is, in effect, another case, such as the satellite service some have mentioned, in which the orginator has no "local" dial plan, that is, there is no expectation of being able to reach "local" things like emergency, repair, the local TV station by dialing #13, the highway patrol by dialing #77, etc. The only thing that can be dialed is an E.164 number, or specific "service" numbers that the satallite service provider themselves defines and uses.)
<BR>
<BR>So there are two possibilities (when there really is a "local" dial plan):
<BR>
<BR>1. A phone is loaded with the dial plan when it "registers" for service, with the information coming from some "local" server. It can then know when dialing is complete without a "Send" key, and can send the appropriate tel:uri (E.164 number, SOS, etc.).
<BR>2. The phone knows nothing about the dial plan, depends on the user hitting a "Send" key (like cellualar) and the "local" outbound proxy does all interpretation of the dial digit string. The phone knows nothing about emergency calls.
<BR>
<BR>Certainly both of these should be allowed.
<BR>
<BR>(If you want an example of what could be required to send a dial plan to a phone, one can reference RFC 2705.)
<BR>
<BR>Mike Pierce
<BR>Artel
<BR></FONT></HTML>

--part1_e.2b13d0f0.2b4f2ebd_boundary--
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  9 18:01:33 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29291
	for <sipping-archive@odin.ietf.org>; Thu, 9 Jan 2003 18:01:33 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h09NDQY01459
	for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 18:13:26 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09NDQJ01455
	for <sipping-web-archive@optimus.ietf.org>; Thu, 9 Jan 2003 18:13:26 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29286
	for <sipping-web-archive@ietf.org>; Thu, 9 Jan 2003 18:01:02 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09NBwJ01373;
	Thu, 9 Jan 2003 18:11:58 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09NAmJ01296
	for <sipping@optimus.ietf.org>; Thu, 9 Jan 2003 18:10:48 -0500
Received: from ihemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29133
	for <sipping@ietf.org>; Thu, 9 Jan 2003 17:58:24 -0500 (EST)
Received: from oh0012exch001p.wins.lucent.com (h135-7-157-6.lucent.com [135.7.157.6])
	by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h09N1eQ25540
	for <sipping@ietf.org>; Thu, 9 Jan 2003 18:01:40 -0500 (EST)
Received: by OH0012EXCH001P with Internet Mail Service (5.5.2653.19)
	id <Y5VBMD9H>; Thu, 9 Jan 2003 18:01:39 -0500
Message-ID: <4C37CF2D8DF07E4CA6357BAD5EB9A5D703F5AB11@oh0012itsa1.cb.lucent.com>
From: "Deb, Sunandita (Sunandita)" <sudeb@lucent.com>
To: "'sipping@ietf.org'" <sipping@ietf.org>
Date: Thu, 9 Jan 2003 18:01:30 -0500 
Importance: high
X-Priority: 1
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sipping] Mapping of ISDN PRI messages to SIP-T
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>


Hi,

I'd like to get some information regarding the mapping of ISDN PRI messages
to SIP-T messages. Has this work already been done? Is there any RFC
avaailable for it? Is there any RFC or any spec describing a mapping of ISUP
messages  to SIP-T? If I can get the latter, I can make an attempt to extend
it to the PRI to SIP-T mapping for my project.

Thanks,
Sunandita
sudeb@lucent.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  9 18:58:44 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00859
	for <sipping-archive@odin.ietf.org>; Thu, 9 Jan 2003 18:58:44 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0A0AcU04692
	for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 19:10:38 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A0AcJ04689
	for <sipping-web-archive@optimus.ietf.org>; Thu, 9 Jan 2003 19:10:38 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00837
	for <sipping-web-archive@ietf.org>; Thu, 9 Jan 2003 18:58:10 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A09PJ04614;
	Thu, 9 Jan 2003 19:09:25 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A08hJ04564
	for <sipping@optimus.ietf.org>; Thu, 9 Jan 2003 19:08:43 -0500
Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00815
	for <sipping@ietf.org>; Thu, 9 Jan 2003 18:56:16 -0500 (EST)
Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11])
	by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h09NxH802953;
	Thu, 9 Jan 2003 23:59:17 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19)
	id <ZH2JGASF>; Thu, 9 Jan 2003 19:01:40 -0500
Message-ID: <15A2739B7DAA624D8091C65981D7DA815EB511@stntexch2.va.neustar.com>
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: "'Rosen, Brian'" <Brian.Rosen@marconi.com>,
        "'Paul Kyzivat'"
	 <pkyzivat@cisco.com>
Cc: "'Henning Schulzrinne'" <hgs@cs.columbia.edu>,
        "'sipping@ietf.org'"
	 <sipping@ietf.org>
Subject: RE: [Sipping] Do Phones Have Dial Plans, or do Proxies map?  was 
	 RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
Date: Thu, 9 Jan 2003 19:01:40 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>


I feel pretty strongly that phone numbers should be converted into
fully-qualified E.164 numbers at the originating user agent. It is very
problematic, outside of an architecture that is constrained in a way that we
are unlikely to standardize, for a proxy server to figure out the context in
which a set of arbitrary digits were dialed. Of course, if you're dialing a
number that cannot be converted to E.164, then it needs to be sent as-is. 

This design decision has come up previously in the SIP-T work and in the tel
URL work.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: Thursday, January 09, 2003 10:45 AM
> To: 'Paul Kyzivat'
> Cc: 'Henning Schulzrinne'; 'sipping@ietf.org'
> Subject: RE: [Sipping] Do Phones Have Dial Plans, or do 
> Proxies map? was
> RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
> 
> 
> I think this response just restates the question.  
> I think we either say that phones essentially always put out 
> global numbers, or they put out dialing strings and a proxy 
> expands it.  We can probably agree on the tel uri prefix for
> either.  If a proxy expands dialing strings to phone numbers,
> then we probably do need some kind of context, as you point out.
> 
> First we should decide if we put the dialing plan in the phone.
> 
> BTW, I currently favor NOT putting the dialing plan in the UA,
> but I don't feel strongly about it.  I do feel strongly about
> standardizing this bit, because I surely want all sipphones to
> "play" in my system, and I don't want a boat-load of vendor specific
> code to make that work.
> 
> Our sip based enterprise system has a classical enterprise dialing 
> plan, although we interpret 7 or more digits as national or 
> international numbers, rather than requiring the "9" prefix.  
> That works because all internal numbers are less than 7 digits.  
> Proxies do the expansion.  There is vendor specific code in this 
> proxy because no two gateways we support work the same.  
> Hence this entire effort :)
> 
> Brian
> 
> > -----Original Message-----
> > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> > Sent: Thursday, January 09, 2003 1:13 PM
> > To: Rosen, Brian
> > Cc: 'Henning Schulzrinne'; 'sipping@ietf.org'
> > Subject: Re: [Sipping] Do Phones Have Dial Plans, or do 
> > Proxies map? was
> > RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
> > 
> > 
> > Unless we are going to require users to enter full URIs into 
> > the phone 
> > (including "tel:"), the phone MUST have some sort of dial 
> > plan. We only 
> > need to discuss how complex it is.
> > 
> > At one extreme it could simply be to prefix the entered digits with 
> > "tel:" and let a proxy do the rest.
> > 
> > At the other extreme it could do all sorts of complex 
> > transformations to 
> > turn short sequences into global tel: uris, or even sip uris, 
> > possibly 
> > even chosing different gateways based on dialed number.
> > 
> > As I mentioned in an earlier reply, simply slapping "tel:" on the 
> > entered digits doesn't create syntactically correct tel: uris 
> > according 
> > to the latest definition. To go that way, the tel: syntax 
> needs to be 
> > altered. Also, the tel: definition currently says that a 
> tel: address 
> > SHOULD always use global syntax unless there is no valid 
> > global address. 
> > Encoding dialed digits as a local tel: uri and defering 
> > conversion to a 
> > global address to a proxy would violate that rule.
> > 
> > One possibility is to define the minimal dial plan for a phone as: 
> > prefix the dialed digits with "tel:" and suffix the dialed 
> > digits with 
> > ";phone-context=XXX", where XXX needs to be learned or provisioned 
> > somewhere. The XXX is then effectively a name for the dial 
> plan to be 
> > used to expand the number. This gets around the syntax problem with 
> > using the tel: uri, though it still violates the semantic rule.
> > 
> > 	Paul
> > 
> > Rosen, Brian wrote:
> > > The systems I'm aware of use regexps in one form or another
> > > to mangle a string into a dialed number.  I don't have
> > > a problem making this a UA function, but if we do, I want
> > > to standardize the regexp and "Publish" it to the UA.
> > > 
> > > A lot of enterprise gateways have dial string to dialed 
> > number mapping.
> > > Some sipphones do.
> > > 
> > > Brian
> > > 
> > > 
> > > 
> > > 
> > >>-----Original Message-----
> > >>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> > >>Sent: Thursday, January 09, 2003 10:32 AM
> > >>To: Rosen, Brian
> > >>Cc: 'Paul Kyzivat'; 'sipping@ietf.org'
> > >>Subject: Re: [Sipping] Do Phones Have Dial Plans, or do 
> > >>Proxies map? was
> > >>RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
> > >>
> > >>
> > >>I would find it instructive how non-SIP systems have 
> solved similar 
> > >>problems. In web browsers and email, we have auto-completion 
> > >>functions 
> > >>and nick names, for examples.
> > >>
> > >>There's also the analogy with 'real names' (not the defunct 
> > >>company, the 
> > >>concept) which translates strings-nice-for-humans into URLs. 
> > >>See the CRN 
> > >>work, including the go: URL. (I'm not aware of 
> > implemenentations, but 
> > >>the concept may be relevant, in particular keeping the 
> > identifier and 
> > >>various 'nicknames' clearly distinct.)
> > >>
> > >>There are probably two sub-problems here:
> > >>
> > >>- Recognizing patterns so that one can keep the old 
> > >>"no-need-to-hit-dial" user interface.
> > >>
> > >>- Translating abbreviations such as extensions and local-area 
> > >>numbers to 
> > >>fully-expanded, globally unique identifiers.
> > >>
> > >>The former will always require downloading a pattern to an 
> > >>end system, 
> > >>the latter is a (local) translation service. The only 
> question then 
> > >>becomes if the translation is done in one or two steps, 
> > i.e., before 
> > >>issuing a SIP request or as part of a SIP request.
> > >>
> > >>Aside: There are clearly examles of widely-deployed systems 
> > where the 
> > >>phone has a dial-plan, downloaded via tftp.
> > >>
> > >>Rosen, Brian wrote:
> > >>
> > >>>This comes up a lot.  I think we should decide.
> > >>>
> > >>>Who translates a dial string into a tel uri?
> > >>>
> > >>>tel uris, as of now, explicitly don't handle dialing strings,
> > >>>only dialed numbers.  In essentially all existing systems,
> > >>>phones don't have dialing plans in them; central elements
> > >>>map dialing strings to dialed numbers.  What's our story?
> > >>>Does every UA that has a dial pad have to have a dialing plan 
> > >>>loaded in it that maps dialing strings to dialed numbers, 
> > >>>or does a proxy server do it?
> > >>>
> > >>>If it's the former, then how do we standardize the mapping?
> > >>>If it's the latter, then how does a UA send a dialing string?
> > >>>
> > >>>Brian
> > >>>
> > >>>
> > >>>
> > >>>>-----Original Message-----
> > >>>>From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> > >>>>Sent: Thursday, January 09, 2003 9:53 AM
> > >>>>To: 'sipping@ietf.org'
> > >>>>Subject: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
> > >>>>
> > >>>>
> > >>>>I have a few comments about 
> draft-schulzrinne-sipping-sos-04.txt.
> > >>>>(I haven't been following this work very closely, so 
> > >>>
> > >>perhaps some of 
> > >>
> > >>>>these pertain to things that were in earlier drafts.)
> > >>>>
> > >>>>I must say, these are really messy problems, so I am 
> glad you are 
> > >>>>working on them.
> > >>>>
> > >>>>Section 3.2 says:
> > >>>>
> > >>>>   ... a UAC MAY use a "tel" URI [3,4] without 
> > >>>
> > >>phone-context, such as
> > >>
> > >>>>   tel:911
> > >>>>   tel:112
> > >>>>
> > >>>>The latest and greatest definition of the tel: uri that I 
> > >>>
> > >>can find is 
> > >>
> > >>>>draft-antti-rfc2806bis-07.txt. According to that, the above 
> > >>>
> > >>tel: uris 
> > >>
> > >>>>are syntactically incorrect. Either the number must be global 
> > >>>>or else it 
> > >>>>must contain a phone-context parameter.
> > >>>>
> > >>>>Are there plans to change the definition of the tel uri, 
> > or is this 
> > >>>>language going to change?
> > >>>>
> > >>>>In the case of a UAC that is using a local outbound 
> proxy, is it 
> > >>>>required that the UAC specifically recognize these strings 
> > >>>>and deliver 
> > >>>>them to the proxy, or is it sufficient for it to deliver 
> > >>>
> > >>any and all 
> > >>
> > >>>>dialed digit strings to the proxy as tel uris without 
> > attempting to 
> > >>>>recognize them itself? Is it sufficient to determine that 
> > >>>
> > >>the dialed 
> > >>
> > >>>>number is complete by timeout on the input rather than by 
> > >>>
> > >>recognition?
> > >>
> > >>>>Section 5 specifies that the UAC should insert location 
> > >>>>information into 
> > >>>>emergency calls. However, presumably location information 
> > should in 
> > >>>>general not be placed in non-emergency calls, so it is 
> > >>>
> > >>important that 
> > >>
> > >>>>the UAC realize it is making an emergency call. In the case 
> > >>>
> > >>of dialed 
> > >>
> > >>>>digit strings, it may only be the outbound proxy that can 
> > >>>>determine if 
> > >>>>the call is an emergency call. One way to handle this would 
> > >>>>be for the 
> > >>>>local outbound proxy to redirect requests to tel: emergency 
> > >>>>numbers to 
> > >>>>the corresponding sip:sos number. Then the UAC would be able to 
> > >>>>positively determine this is an emergency call and include 
> > >>>>the location 
> > >>>>information.
> > >>>>
> > >>>>Section 9 says:
> > >>>>
> > >>>>   We propose a new DHCP option that enumerates the valid local
> > >>>>   emergency identifiers, as a list of "tel", "sip" or 
> > "sips" URIs.
> > >>>>
> > >>>>This doesn't seem sufficient. Most phone-like devices have 
> > >>>>provision for 
> > >>>>entering primarily sequences of digits, not tel: uris. It is 
> > >>>>up to the 
> > >>>>phone to translate a digit sequence into a valid uri. In 
> > >>>
> > >>general this 
> > >>
> > >>>>requires some sort of dial plan. Without the dial plan, the 
> > >>>
> > >>phone may 
> > >>
> > >>>>well not be able to generate anything that matches one of the 
> > >>>>specified 
> > >>>>tel uris.
> > >>>>
> > >>>>	Paul
> > >>>>
> > >>>>_______________________________________________
> > >>>>Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> >>>>This list is for NEW development of the application of SIP
> >>>>Use sip-implementors@cs.columbia.edu for questions on current sip
> >>>>Use sip@ietf.org for new developments of core SIP
> >>>>
> >>>
> >>>_______________________________________________
> >>>Sipping mailing list  
https://www1.ietf.org/mailman/listinfo/sipping
>>>This list is for NEW development of the application of SIP
>>>Use sip-implementors@cs.columbia.edu for questions on current sip
>>>Use sip@ietf.org for new developments of core SIP
>>
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  9 18:58:44 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00861
	for <sipping-archive@odin.ietf.org>; Thu, 9 Jan 2003 18:58:44 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0A0AcR04707
	for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 19:10:38 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A0AcJ04704
	for <sipping-web-archive@optimus.ietf.org>; Thu, 9 Jan 2003 19:10:38 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00839
	for <sipping-web-archive@ietf.org>; Thu, 9 Jan 2003 18:58:11 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A09JJ04590;
	Thu, 9 Jan 2003 19:09:21 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A08GJ04540
	for <sipping@optimus.ietf.org>; Thu, 9 Jan 2003 19:08:16 -0500
Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00785
	for <sipping@ietf.org>; Thu, 9 Jan 2003 18:55:50 -0500 (EST)
Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11])
	by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h09Nwt802941;
	Thu, 9 Jan 2003 23:58:55 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19)
	id <ZH2JGASB>; Thu, 9 Jan 2003 19:01:18 -0500
Message-ID: <15A2739B7DAA624D8091C65981D7DA815EB510@stntexch2.va.neustar.com>
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: "'Rosen, Brian'" <Brian.Rosen@marconi.com>,
        "'Drage, Keith (Keith)'"
	 <drage@lucent.com>,
        "'Henning Schulzrinne'" <hgs@cs.columbia.edu>
Cc: "'sipping@ietf.org'" <sipping@ietf.org>
Subject: RE: [Sipping] URIs for Gateways
Date: Thu, 9 Jan 2003 19:01:17 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>


I may have been a little thick up to this point - I now think that by
'gateway' you mean something that acts like a PBX (I was kind of thinking
you meant a PSTN gateway, which has very different requirement for all of
this). From the notes below, it sounds like in your case the PBX is a SIP UA
that has a set of hardwired phone lines (your 'ports'), each of which goes
to a single black phone. You want a proxy server to manage the mappings of
identifiers (be they tel URLs or SIP URIs) to particular PBXs and PBX ports,
because you want the PBXs themselves to be ignorant of the URIs that
identify the phones that they manage. Is that right?

Ordinarily, we say that in SIP architectures, features are pushed to the
edges, not to the core of the network. Abstract out the PBX for a minute,
and imagine coming forward with a SIP architecture in which you have a set
of user agents that are so simple that they don't know their own identity,
they can't learn it somehow from the network, and therefore cannot correctly
populate the From header field of requests they generate. Instead, they'd
like a proxy server to somehow populate this identity in requests as they
are sent through the network. This would be essentially the same problem you
brought to the list.

My reaction would probably be that RFC3261 assumes that SIP UAs have the
ability to populate a From header field. Even my 1G CDMA cell phone knows
its own phone number. A PBX usually means something with a lot of features.
Even if in your architecture you're trying to radically reduce the cost of
the PBX component, a PBX can be expected to more be complex than, say, the
sorts of simple SIP phones we see today (which are in my experience all
capable of mananging one identity, if not several, for their users). Is it
really that much harder for a PBX to look at the string 'port3' in the R-U
of a SIP request and map that to a hardware resource than it is for a PBX to
look at the string '+12025332600' in the R-U of a SIP request and map that
to a hardware resource? PBXs that are compliant SIP implementations will
have to perform a number of vastly more complicated operations.

In other words, it's hard for me to understand why the PBX UA (the edge)
isn't the right place to manage the mapping between an identifier (a phone
number) and a port. Doing this in a proxy (the core) introduces a number of
data synchronization questions as well as the protocol questions that have
run through this thread. Is there some special reason why this PBX cannot be
expected to do one of the simpler things that we ask of UAs? Is there a
particularly large number of ports that you imagine such a PBX would manage
(in the millions, maybe)? It would really help to have more background. The
motivation for this is a little obscure to me.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: Thursday, January 09, 2003 7:03 AM
> To: 'Peterson, Jon'; 'Drage, Keith (Keith)'; 'Henning Schulzrinne'
> Cc: 'sipping@ietf.org'
> Subject: RE: [Sipping] URIs for Gateways
> 
> 
> Note below
> 
> > What I suggested was that the From header hold the URI of the 
> > gateway - not
> > the 'real' SIP URI of the user - for PSTN-to-SIP calls. The 
> > From address in
> > this instance is not the address to which you should reply if 
> > you want to
> > reach the initiator of the session later. The tel URL of that 
> > user is in
> > fact the URI to which you should reply. I think this is a 
> > good place to put
> > it for this case, and it doesn't warp the Reply-To header in 
> > any way that I
> > can see. This is completely unrelated to where one would put 
> > the 'real' SIP
> > URI of the user.
> I see how it works in this case, but only if the UA knows 
> both identities.
> In some cases it doesn't now, but I think we might reasonably ask
> whether it should (ie the BCP I propose could state that gateways
> should know the telephone number it is connected to, and fill in
> From and Reply To as you suggest).  We want to build systems where
> a proxy knows this, and doesn't rely on the gateway.  Basically, we
> have ONE place that maintains the phone-number-to-user and 
> phone-number-
> to-port-on-gateway information, and all tel URIs are routed through
> that proxy.  It adds mappings and decides on which gateway will get
> the call.  UAs don't know the mapping, gateways don't know 
> the mapping,
> only the one proxy knows.  We now have mechanisms that attempt to
> keep gateway mapping systems accurate from the one database.  
> It takes 
> vendor specific code in the proxy that knows how to manipulate the 
> management port of each gateway in order to maintain the mappings.
> That's not a good system design, even if it does work.
> 
> > 
> > > It also has a serious problem that a proxy can't add it.
> > 
> > I think you mean that you want the proxy to be able to add 
> a telephone
> > number to a request for a SIP-to-PSTN call, or maybe to add 
> a SIP URI
> > representing the originating user to a request for a 
> PSTN-to-SIP call
> > (though this latter one is difficult - how would a user authenticate
> > themselves to an auth service through a PSTN gateway?). I agree that
> > Reply-To is not a good candidate for this usage - this is 
> > where it has been
> > argued that P-Asserted-Identity is a good candidate.
> Yes, you see what I mean.  Yes P-A-I would work, although this use
> does not meet the definition of P-A-I.  I'm also bothered that we use
> two different headers for what I think is the same thing (holding both
> a sip URI and a tel URI in the sip message for the "From" identity).
> 
> > 
> > There are some minor issues with this (such as how a proxy 
> > knows when and
> > why to add identities, and how authentication for particular 
> > identifies is
> > managed), but I think that if a proxy asserts an identity, it 
> > can and should
> > use the identity mechanisms we've already defined, which 
> were designed
> > specifically with proxies in mind. However, there are some 
> > reasons to ask
> > whether or not proxies are always the best entities to decide 
> > when synonym
> > identities should be added to a request.
> I agree that authentication in this case is a little tricky, but
> I don't think it's very hard.  
> 
> > 
> > > One of the requirements I have is that a proxy be able to
> > > do the translation.  Not every gateway can hold all the tables
> > > required for this kind of translation, and I don't think
> > > we want to force every gateway to have the tables.
> > > 
> > 
> > The whole issue of who should do 'translation' by various 
> > entities is a
> > little problematic, and ultimately this problem should be 
> > separable from the
> > selection of the headers we might use to express the results 
> > of translation.
> > Personally, I think ENUM is the right way to do telephone 
> > number to URI
> > translations - however, it is not servicable for the reverse, 
> > for URI to
> > telephone number translations. Having some kind of 'reverse 
> > ENUM' for this
> > purpose has been the subject of much speculation in ENUM 
> > circles, but it
> > currently is not well understood how it would work.
> This is only true for Service Provider gateways.  It is not true
> for enterprise gateways.  You would not want to use the currently
> defined ENUM, because it would require that every enterprise
> publish their internal mappings in the global ENUM DNS.  That
> is not acceptable, and there are no mechanisms to do that (it
> implies that, for example, an enterprise tells it's SP what the
> SIP URI associated with each extension is).
> 
> > 
> > ENUM is best performed by the initiator of the session, 
> rather than an
> > intermediary, for various reasons that are enumerated in 
> > sipping-e164-02.
> > Therefore, for PSTN-to-SIP calls, I think the PSTN gateway is 
> > the right
> > place to do an ENUM query. This does not require the gateway 
> > to have any
> > tables, or what have you. Intermediaries can also query ENUM 
> > and apply the
> > results to a message, even if it is sub-optimal for them to do so.
> When ENUM is used, I agree, best at the gateway, less optimal in
> an intermediary (proxy).  
> 
> > 
> > > I think your proposals on identity will not work unless
> > > the signer can be a proxy which later in the routing
> > > than my proxy that does the translation.  
> > 
> > Well, an authentication service, as I describe it, does the 
> > signing after a
> > request has been generated, yes. If a later proxy wants to 
> shove some
> > (authenticated) information into the request afterwards, that 
> > isn't possible
> > unless is supplies a separate signed body.
> It would be ugly, but possible, for an authentication to be performed
> first on From/To/Reply-To and then subsequently on P-A-I. 
> The idea of authenticating cryptographically the P-A-I header 
> amuses me.
> 
> > 
> > > If the gateway
> > > does the translation, then in theory there would have to be
> > > a trust relationship between the PSTN and the gateway. 
> > 
> > There is always, in effect, a trust relationship between the 
> > PSTN and a
> > gateway. The gateway is a node on the PSTN (whether it is a 
> > privileged node,
> > like an SS7 gateway, or a user node, like a CAS gateway), and 
> > nodes have a
> > certain defined trust relationship with the PSTN. I think the 
> > gateway is one
> > of the better candidates to do ENUM, and possibly to perform 
> > the reverse
> > operation (however that would work).
> Do SPs really trust CAS gateways?  I didn't think it's true, 
> although I don't know what actually happens if the gateway
> supplies a calling number that is not one of it's assigned DNs.
> I'm pretty sure it's NOT true of PRI gateways, but don't really
> know.  I don't think that it matters for this discussion.
> 
> See above for routing issues that argue against the gateway doing
> the mapping, at least for an enterprise system.
> 
> >  
> > > That won't work for an enterprise gateway, although I'm not
> > > sure that's a practical problem, because if the gateway
> > > translated, the PSTN is going to check that the number
> > > the gateway asserted is one of the identities that loop
> > > is allocated (PRIs have ranges).
> > > 
> > 
> > Presumably, gateways shouldn't trust authentication services 
> > that might give
> > them improper information. In fact, there are numerous restrictions
> > surrounding what sorts of phone numbers should be sent over 
> > many sorts of
> > ISUP trunks as well (as well as rules about when a CgPN must 
> > be present, as
> > opposed to may be present). An proxy or user agent that 
> > supplies originating
> > telephone numbers for SIP-to-PSTN calls should expect 
> > gateways to validate
> > them, and there should be some way to accomodate cases in 
> > which the gateway
> > cannot transmit these numbers to the PSTN, since it may be 
> > difficult for a
> > proxy to determine what sort of gateway a request will 
> > ultimately land on
> > (which is one of the reasons why proxies might not be the 
> > best place for
> > synonym identities to be managed).
> > 
> > > I don't see how ENUM is useful with identity assertion,
> > > although it's clearly applicable to the proxy that
> > > translates a SIP URI into a phone number or vice versa in
> > > the Request URI.  
> > 
> > It doesn't assert identity itself, certainly. The one place 
> > in which it is
> > conceivably useful for identity assertion is that ENUM could 
> > be queried for
> > a URI associated with the calling party's number in a 
> > PSTN-to-SIP call. This
> > could be useful for a number of reasons - that URI could be 
> stuck in a
> > header to indicate a SIP URI for the end user that is more 
> explicit or
> > recognizable than their telephone number.
> Agree.  This could be useful.  What header?
> 
> > 
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  9 20:13:10 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02865
	for <sipping-archive@odin.ietf.org>; Thu, 9 Jan 2003 20:13:10 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0A1P6E08822
	for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 20:25:06 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A1P6J08819
	for <sipping-web-archive@optimus.ietf.org>; Thu, 9 Jan 2003 20:25:06 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02851
	for <sipping-web-archive@ietf.org>; Thu, 9 Jan 2003 20:12:38 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A1NfJ08740;
	Thu, 9 Jan 2003 20:23:41 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A1MNJ08687
	for <sipping@optimus.ietf.org>; Thu, 9 Jan 2003 20:22:23 -0500
Received: from mta0 (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02806
	for <sipping@ietf.org>; Thu, 9 Jan 2003 20:09:51 -0500 (EST)
Received: from w07087a (mta0 [172.17.1.62])
 by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
 2002)) with ESMTPA id <0H8H00CD74MZ9B@mta0.huawei.com> for sipping@ietf.org;
 Fri, 10 Jan 2003 09:11:25 +0800 (CST)
Date: Fri, 10 Jan 2003 09:14:10 +0800
From: wenkai <wkai@huawei.com>
To: sipping@ietf.org
Message-id: <002801c2b845$94f91040$af064d0a@w07087a>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
Content-type: multipart/alternative;
 boundary="Boundary_(ID_6DNob1IWvEp7LlBW6Sbiww)"
X-Priority: 3
X-MSMail-priority: Normal
Subject: [Sipping] a question about 3pcc
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

--Boundary_(ID_6DNob1IWvEp7LlBW6Sbiww)
Content-type: text/plain; charset=gb2312
Content-Transfer-Encoding: 7BIT

Hi,
The following is the "Mid-Call Announcement" call flow from "draft-ietf-sipping-3pcc-02.txt". 
After hanging up with the media server, the controller reconnects the Pre-Paid user to the called party. I think the media stream(stream 3) established between Pre-Paid user and the Called Party maybe is not the same as the original media stream(stream 1).
In practice, maybe we want to have the same media codec as original one when we restore a call.
Could you please give the call flow to reach this requirment?

Best Regards
Kevin


     Pre-Paid User        Controller         Called Party        Media Server
          |                   |                   |                   |
          |..........stream 1.....................|                   |
          |                   |(1) INV SDP c=0    |                   |
          |                   |------------------>|                   |
          |                   |(2) 200 answer1    |                   |
          |                   |<------------------|                   |
          |                   |(3) ACK            |                   |
          |                   |------------------>|                   |
          |(4) INV no SDP     |                   |                   |
          |<------------------|                   |                   |
          |(5) 200 offer2     |                   |                   |
          |------------------>|                   |                   |
          |                   |(6) INV offer2     |                   |
          |                   |-------------------------------------->|
          |                   |(7) 200 answer2    |                   |
          |                   |<--------------------------------------|
          |(8) ACK answer2    |                   |                   |
          |<------------------|                   |                   |
          |                   |(9) ACK            |                   |
          |                   |-------------------------------------->|
          |(10) RTP           |                   |                   |
          |..........stream 2.........................................|
          |                   |(11) BYE           |                   |
          |                   |-------------------------------------->|
          |                   |(12) 200 OK        |                   |
          |                   |<--------------------------------------|
          |                   |(13) INV no SDP    |                   |
          |                   |------------------>|                   |
          |                   |(14) 200 offer3    |                   |
          |                   |<------------------|                   |
          |(15) INV offer3'   |                   |                   |
          |<------------------|                   |                   |
          |(16) 200 answer3'  |                   |                   |
          |------------------>|                   |                   |
          |                   |(17) ACK answer3'  |                   |
          |                   |------------------>|                   |
          |(18) ACK           |                   |                   |
          |<------------------|                   |                   |
          |(19) RTP           |                   |                   |
          |..........stream 3.....................|                   |

--Boundary_(ID_6DNob1IWvEp7LlBW6Sbiww)
Content-type: text/html; charset=gb2312
Content-Transfer-Encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=gb2312" http-equiv=Content-Type>
<META content="MSHTML 5.00.3315.2870" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>
<DIV><FONT face="Courier New" size=2>Hi,</FONT></DIV>
<DIV><FONT face="Courier New" size=2>The following is the "Mid-Call 
Announcement" call flow from "draft-ietf-sipping-3pcc-02.txt". </FONT></DIV>
<DIV><FONT face="Courier New" size=2>After hanging up with the media server, the 
controller reconnects the Pre-Paid user to the&nbsp;called party.&nbsp;I think 
the media stream(stream 3) established between Pre-Paid user and the Called 
Party maybe is not the same as&nbsp;the original media stream(stream 
1).</FONT></DIV>
<DIV><FONT face="Courier New" size=2>In practice, maybe we want to have the same 
media codec as&nbsp;original one when we restore a call.</FONT></DIV>
<DIV><FONT face="Courier New" size=2>Could&nbsp;you please give&nbsp;the call 
flow to reach this requirment?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face="Courier New" size=2>Best Regards</FONT></DIV>
<DIV><FONT face="Courier New" size=2>Kevin</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face="Courier New" size=2>&nbsp;&nbsp;&nbsp;&nbsp; Pre-Paid 
User&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Controller&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Called 
Party&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media Server</FONT></DIV>
<DIV><FONT face=Arial size=2><FONT face=Arial size=2><FONT face=Arial 
size=2><FONT face="Courier New" 
size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR></FONT></FONT></FONT></FONT><FONT face=Arial size=2><FONT 
face="Courier New" size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|..........stream 
1.....................|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR></FONT></FONT><FONT face="Courier New" 
size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|(1) INV SDP c=0&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|------------------&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|(2) 200 answer1&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&lt;------------------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|(3) ACK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|------------------&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |(4) INV no 
SDP&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&lt;------------------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |(5) 200 
offer2&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|------------------&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|(6) INV offer2&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|--------------------------------------&gt;|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|(7) 200 answer2&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&lt;--------------------------------------|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|(8) ACK answer2&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&lt;------------------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|(9) ACK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|--------------------------------------&gt;|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|(10) RTP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |..........stream 
2.........................................|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|(11) BYE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|--------------------------------------&gt;|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|(12) 200 OK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&lt;--------------------------------------|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|(13) INV no SDP&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|------------------&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|(14) 200 offer3&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&lt;------------------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |(15) INV 
offer3'&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&lt;------------------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |(16) 200 
answer3'&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|------------------&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|(17) ACK answer3'&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|------------------&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |(18) 
ACK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&lt;------------------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |(19) 
RTP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |..........stream 
3.....................|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|</FONT></DIV></FONT></DIV></BODY></HTML>

--Boundary_(ID_6DNob1IWvEp7LlBW6Sbiww)--
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  9 20:37:28 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03311
	for <sipping-archive@odin.ietf.org>; Thu, 9 Jan 2003 20:37:28 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0A1nPl10285
	for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 20:49:25 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A1nPJ10282
	for <sipping-web-archive@optimus.ietf.org>; Thu, 9 Jan 2003 20:49:25 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03303
	for <sipping-web-archive@ietf.org>; Thu, 9 Jan 2003 20:36:55 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A1mAJ10183;
	Thu, 9 Jan 2003 20:48:10 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A1lgJ10154
	for <sipping@optimus.ietf.org>; Thu, 9 Jan 2003 20:47:42 -0500
Received: from kcmso2.proxy.att.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03272
	for <sipping@ietf.org>; Thu, 9 Jan 2003 20:35:12 -0500 (EST)
Received: from attrh3i.attrh.att.com ([135.71.62.12])
	by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h0A1cTx4029914
	for <sipping@ietf.org>; Thu, 9 Jan 2003 19:38:30 -0600 (CST)
Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh3i.attrh.att.com (6.5.032)
        id 3DF6BD4E00FD84FF; Thu, 9 Jan 2003 20:38:28 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2B848.F8CF9A7F"
Subject: RE: [Sipping] a question about 3pcc
Date: Thu, 9 Jan 2003 20:38:27 -0500
Message-ID: <62DA45D4963FA747BA1B253E266760F9053B6613@OCCLUST04EVS1.ugd.att.com>
Thread-Topic: [Sipping] a question about 3pcc
Thread-Index: AcK4Rd6PBhj/gZuNSGOjl0DKbLdBhgAAfusw
From: "Roy, Radhika R, ALASO" <rrroy@att.com>
To: "wenkai" <wkai@huawei.com>, <sipping@ietf.org>
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C2B848.F8CF9A7F
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable

I think that Kevin is right.
=20
A media server (e.g., placed in the service provider's network) may =
support any number of standardized codecs that a user offers. So, =
negotiations of codecs may not be needed.
=20
For the callee, it may not be the case. As a result, negotiations of =
codecs may needed. Call flows need to be extended to cover that =
possibility.
=20
Radhika R. Roy
rrroy@att.com

-----Original Message-----
From: wenkai [mailto:wkai@huawei.com]
Sent: Thursday, January 09, 2003 8:14 PM
To: sipping@ietf.org
Subject: [Sipping] a question about 3pcc



Hi,
The following is the "Mid-Call Announcement" call flow from =
"draft-ietf-sipping-3pcc-02.txt".=20
After hanging up with the media server, the controller reconnects the =
Pre-Paid user to the called party. I think the media stream(stream 3) =
established between Pre-Paid user and the Called Party maybe is not the =
same as the original media stream(stream 1).
In practice, maybe we want to have the same media codec as original one =
when we restore a call.
Could you please give the call flow to reach this requirment?
=20
Best Regards
Kevin
=20
=20
     Pre-Paid User        Controller         Called Party        Media =
Server
          |                   |                   |                   |
          |..........stream 1.....................|                   |
          |                   |(1) INV SDP c=3D0    |                   =
|
          |                   |------------------>|                   |
          |                   |(2) 200 answer1    |                   |
          |                   |<------------------|                   |
          |                   |(3) ACK            |                   |
          |                   |------------------>|                   |
          |(4) INV no SDP     |                   |                   |
          |<------------------|                   |                   |
          |(5) 200 offer2     |                   |                   |
          |------------------>|                   |                   |
          |                   |(6) INV offer2     |                   |
          |                   |-------------------------------------->|
          |                   |(7) 200 answer2    |                   |
          |                   |<--------------------------------------|
          |(8) ACK answer2    |                   |                   |
          |<------------------|                   |                   |
          |                   |(9) ACK            |                   |
          |                   |-------------------------------------->|
          |(10) RTP           |                   |                   |
          |..........stream 2.........................................|
          |                   |(11) BYE           |                   |
          |                   |-------------------------------------->|
          |                   |(12) 200 OK        |                   |
          |                   |<--------------------------------------|
          |                   |(13) INV no SDP    |                   |
          |                   |------------------>|                   |
          |                   |(14) 200 offer3    |                   |
          |                   |<------------------|                   |
          |(15) INV offer3'   |                   |                   |
          |<------------------|                   |                   |
          |(16) 200 answer3'  |                   |                   |
          |------------------>|                   |                   |
          |                   |(17) ACK answer3'  |                   |
          |                   |------------------>|                   |
          |(18) ACK           |                   |                   |
          |<------------------|                   |                   |
          |(19) RTP           |                   |                   |
          |..........stream 3.....................|                   |


------_=_NextPart_001_01C2B848.F8CF9A7F
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dgb2312">


<META content=3D"MSHTML 6.00.2716.2200" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D722263001-10012003>I=20
think that Kevin is right.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D722263001-10012003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D722263001-10012003>A=20
media server&nbsp;(e.g., placed in the service provider's network) may =
support=20
any number of standardized codecs that a user offers. So, negotiations =
of codecs=20
may not be needed.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D722263001-10012003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D722263001-10012003>For=20
the callee, it may not be the case. As a result, negotiations of codecs =
may=20
needed. Call flows need to be extended to cover that=20
possibility.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D722263001-10012003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D722263001-10012003>Radhika R. Roy</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D722263001-10012003><A=20
href=3D"mailto:rrroy@att.com">rrroy@att.com</A></SPAN></FONT></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> wenkai=20
  [mailto:wkai@huawei.com]<BR><B>Sent:</B> Thursday, January 09, 2003 =
8:14=20
  PM<BR><B>To:</B> sipping@ietf.org<BR><B>Subject:</B> [Sipping] a =
question=20
  about 3pcc<BR><BR></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>
  <DIV><FONT face=3D"Courier New" size=3D2>Hi,</FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>The following is the =
"Mid-Call=20
  Announcement" call flow from "draft-ietf-sipping-3pcc-02.txt". =
</FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>After hanging up with the =
media server,=20
  the controller reconnects the Pre-Paid user to the&nbsp;called =
party.&nbsp;I=20
  think the media stream(stream 3) established between Pre-Paid user and =
the=20
  Called Party maybe is not the same as&nbsp;the original media =
stream(stream=20
  1).</FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>In practice, maybe we want to =
have the=20
  same media codec as&nbsp;original one when we restore a =
call.</FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>Could&nbsp;you please =
give&nbsp;the call=20
  flow to reach this requirment?</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>Best Regards</FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>Kevin</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; =
Pre-Paid=20
  User&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Controller&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Called=20
  Party&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media =
Server</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2><FONT =
face=3DArial=20
  size=3D2><FONT face=3D"Courier New"=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |<BR></FONT></FONT></FONT></FONT><FONT face=3DArial size=3D2><FONT=20
  face=3D"Courier New"=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |..........stream=20
  =
1.....................|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |<BR></FONT></FONT><FONT face=3D"Courier New"=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |(1) INV SDP c=3D0&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|------------------&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |(2) 200 answer1&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&lt;------------------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |(3) =
ACK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|------------------&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |(4) INV =
no=20
  SDP&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&lt;------------------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |(5) 200=20
  offer2&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|------------------&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |(6) INV offer2&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|--------------------------------------&gt;|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |(7) 200 answer2&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&lt;--------------------------------------|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |(8) ACK answer2&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&lt;------------------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |(9) =
ACK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|--------------------------------------&gt;|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |(10) RTP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|..........stream=20
  =
2.........................................|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |(11) BYE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|--------------------------------------&gt;|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |(12) 200 OK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&lt;--------------------------------------|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |(13) INV no SDP&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|------------------&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |(14) 200 offer3&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&lt;------------------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |(15) INV=20
  offer3'&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&lt;------------------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |(16) 200=20
  answer3'&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|------------------&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |(17) ACK answer3'&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|------------------&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |(18)=20
  ACK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&lt;------------------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |(19)=20
  RTP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|..........stream=20
  =
3.....................|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</FONT></DIV></FONT></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C2B848.F8CF9A7F--
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  9 21:08:10 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03777
	for <sipping-archive@odin.ietf.org>; Thu, 9 Jan 2003 21:08:10 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0A2K7E12136
	for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 21:20:07 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A2K7J12133
	for <sipping-web-archive@optimus.ietf.org>; Thu, 9 Jan 2003 21:20:07 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03761
	for <sipping-web-archive@ietf.org>; Thu, 9 Jan 2003 21:07:38 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A2J4J12083;
	Thu, 9 Jan 2003 21:19:04 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A2ISJ12052
	for <sipping@optimus.ietf.org>; Thu, 9 Jan 2003 21:18:28 -0500
Received: from mtiwmhc12.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03738
	for <sipping@ietf.org>; Thu, 9 Jan 2003 21:05:59 -0500 (EST)
Received: from cs.columbia.edu ([12.92.113.231])
          by mtiwmhc12.worldnet.att.net
          (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP
          id <20030110020916.YQDI12483.mtiwmhc12.worldnet.att.net@cs.columbia.edu>;
          Fri, 10 Jan 2003 02:09:16 +0000
Message-ID: <3E1E2AB8.9020204@cs.columbia.edu>
Date: Thu, 09 Jan 2003 21:06:48 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Adam Roach <adam@dynamicsoft.com>
CC: "Rosen, Brian" <Brian.Rosen@marconi.com>,
        "'Paul Kyzivat'" <pkyzivat@cisco.com>,
        "'sipping@ietf.org'" <sipping@ietf.org>
Subject: Re: [Sipping] Do Phones Have Dial Plans, or do Proxies map?  was
 	RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
References: <9BF66EBF6BEFD942915B4D4D45C051F3A643F9@DYN-TX-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

In case there's doubt: I was not suggesting that we do this. I was 
trying to find out from Brian what he meant, since the two problem have 
very different solution sets. The 'abbreviated dialing' case requires 
nothing except a suitable URI scheme and the translation services of an 
outbound proxy.

Adam Roach wrote:
>>- Recognizing patterns so that one can keep the old 
>>"no-need-to-hit-dial" user interface.
> 
> 
> AAAAAUUUUGGGHHHHH!!! AAAAAUUUUGGGHHHHH!!! AAAAAUUUUGGGHHHHH!!!
> 
> No!
> 
> Cell phones have sufficiently trained the public that it's
> okay to hit something like "OK" or "YES" or "DIAL" or "ENTER"
> after a phone number. It makes life so much easier for user
> interface designers and users alike. For the love of all that
> is good, let's not encourage backsliding.
> 
> /a

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  9 21:32:52 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04208
	for <sipping-archive@odin.ietf.org>; Thu, 9 Jan 2003 21:32:52 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0A2ioN13546
	for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 21:44:50 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A2ioJ13543
	for <sipping-web-archive@optimus.ietf.org>; Thu, 9 Jan 2003 21:44:50 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04192
	for <sipping-web-archive@ietf.org>; Thu, 9 Jan 2003 21:32:20 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A2hLJ13491;
	Thu, 9 Jan 2003 21:43:21 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A2gLJ13445
	for <sipping@optimus.ietf.org>; Thu, 9 Jan 2003 21:42:21 -0500
Received: from mtiwmhc12.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04146
	for <sipping@ietf.org>; Thu, 9 Jan 2003 21:29:52 -0500 (EST)
Received: from cs.columbia.edu ([12.92.113.231])
          by mtiwmhc12.worldnet.att.net
          (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP
          id <20030110023309.ZJGO12483.mtiwmhc12.worldnet.att.net@cs.columbia.edu>;
          Fri, 10 Jan 2003 02:33:09 +0000
Message-ID: <3E1E3052.1070207@cs.columbia.edu>
Date: Thu, 09 Jan 2003 21:30:42 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mpierce1@aol.com
CC: Brian.Rosen@marconi.com, sipping@ietf.org
Subject: Re: [Sipping] Comments on sos draft -03 (URI)
References: <fe.21b2f31b.2b4f2658@aol.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

I gather you're claiming that 3GPP is violating European telecom rules, 
given that its SIM is recognizing 911 (and other non-local emergency 
numbers)?

Mpierce1@aol.com wrote:

>> In other words, if a hotel in Europe
>> doesn't have room 911, it should allow this as an emergency number, to
>> accomodate the US or Canadian traveler.

> No, this is not correct. I doubt that any European regulatory body would 
> accept this. If 911 is not assigned in the local environment, the call 
> must go to "intercept".
> 
> Mike Pierce
> Artel

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  9 21:34:12 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04360
	for <sipping-archive@odin.ietf.org>; Thu, 9 Jan 2003 21:34:12 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0A2kAm13636
	for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 21:46:10 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A2kAJ13633
	for <sipping-web-archive@optimus.ietf.org>; Thu, 9 Jan 2003 21:46:10 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04300
	for <sipping-web-archive@ietf.org>; Thu, 9 Jan 2003 21:33:40 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A2j4J13598;
	Thu, 9 Jan 2003 21:45:04 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A2iXJ13530
	for <sipping@optimus.ietf.org>; Thu, 9 Jan 2003 21:44:33 -0500
Received: from mtiwmhc12.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04186
	for <sipping@ietf.org>; Thu, 9 Jan 2003 21:32:04 -0500 (EST)
Received: from cs.columbia.edu ([12.92.113.231])
          by mtiwmhc12.worldnet.att.net
          (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP
          id <20030110023521.ZKZY12483.mtiwmhc12.worldnet.att.net@cs.columbia.edu>;
          Fri, 10 Jan 2003 02:35:21 +0000
Message-ID: <3E1E30D6.1060506@cs.columbia.edu>
Date: Thu, 09 Jan 2003 21:32:54 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mpierce1@aol.com
CC: Brian.Rosen@marconi.com, sipping@ietf.org
Subject: Re: [Sipping] Comments on sos draft -03 (URI)
References: <fe.21b2f31b.2b4f2658@aol.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

> No, this is not correct. I doubt that any European regulatory body would 
> accept this. If 911 is not assigned in the local environment, the call 
> must go to "intercept".

It doesn't. Logically speaking, this is nothing but a local (private) 
emergency number. As noted by others, lots of companies have local 
emergency numbers (911 and 3333 were mentioned). As far as I know, 
nobody complains if that local emergency number dials the police 
department. Please tell me which rule is being violated here?

> 
> Mike Pierce
> Artel

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  9 22:47:41 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06153
	for <sipping-archive@odin.ietf.org>; Thu, 9 Jan 2003 22:47:41 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0A3xgK17198
	for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 22:59:42 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A3xfJ17195
	for <sipping-web-archive@optimus.ietf.org>; Thu, 9 Jan 2003 22:59:41 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06126
	for <sipping-web-archive@ietf.org>; Thu, 9 Jan 2003 22:47:10 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A3wPJ17148;
	Thu, 9 Jan 2003 22:58:25 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A3vHJ17107
	for <sipping@optimus.ietf.org>; Thu, 9 Jan 2003 22:57:17 -0500
Received: from mtiwmhc11.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06085
	for <sipping@ietf.org>; Thu, 9 Jan 2003 22:44:46 -0500 (EST)
Received: from cs.columbia.edu ([12.92.113.231])
          by mtiwmhc11.worldnet.att.net
          (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP
          id <20030110034802.EDKU9286.mtiwmhc11.worldnet.att.net@cs.columbia.edu>;
          Fri, 10 Jan 2003 03:48:02 +0000
Message-ID: <3E1E41DF.6040403@cs.columbia.edu>
Date: Thu, 09 Jan 2003 22:45:35 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Peterson, Jon" <jon.peterson@neustar.biz>
CC: "'Rosen, Brian'" <Brian.Rosen@marconi.com>,
        "'Paul Kyzivat'" <pkyzivat@cisco.com>,
        "'sipping@ietf.org'" <sipping@ietf.org>
Subject: Re: [Sipping] Do Phones Have Dial Plans, or do Proxies map?  was
 	 RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
References: <15A2739B7DAA624D8091C65981D7DA815EB511@stntexch2.va.neustar.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

There are probably three slightly different dial-plan issues to deal with:

(1) Extensions within a domain. The domain is likely defined by the 
outbound proxy server, so translating those into E.164 tel: URIs or SIP 
URIs (with E.164 user part) doesn't seem to cause undue problems.

(2) General local numbers, as in 456-7890 in the US. Again, for a 
corporate network with an outbound proxy server in the same location as 
the person dialing, this is well-defined.

(3) Service numbers, like 911 and 411.

I'm not implying that (1) and (2) should use tel: URIs without 
phone-context. (3) was somewhat more open since the context is a bit 
iffier. If 3GPP, say, designates 911 as a universal emergency number, it 
can't really have a (national prefix) context.

Even if you translate the digit string dialed to a tel: URI at the UA, 
you still need to get the regexp to the user, so that the UI can 
distinguish between things that should be come tel: URIs without 
phone-context and those that should get one or to add any of the missing 
digits. There are only three possible ways:

- from the home domain, using the yet-to-be-finalized SIP configuration 
work;

- via DHCP

- via some kind of "ask the outbound proxy" mechanism.

Since the outbound proxy needs to translate the tel: URIs, the third 
option seems like a good candidate. However, since the idea is to 
translate to global at the UA, even the home domain version would work, 
except that it would always have to generate a global tel: URI, not 
something with a phone-context.

As a side note, one may want to support local SIP 'dialing strings' as 
well, so that I can type 'alice' instead of 'sip:alice@example.com'.

One could return this, directly or via content-indirection, in an 
OPTIONS response addressed to sip:outbound.proxy.net.


Peterson, Jon wrote:
> I feel pretty strongly that phone numbers should be converted into
> fully-qualified E.164 numbers at the originating user agent. It is very
> problematic, outside of an architecture that is constrained in a way that we
> are unlikely to standardize, for a proxy server to figure out the context in
> which a set of arbitrary digits were dialed. Of course, if you're dialing a
> number that cannot be converted to E.164, then it needs to be sent as-is. 
> 
> This design decision has come up previously in the SIP-T work and in the tel
> URL work.
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan  9 23:27:40 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06917
	for <sipping-archive@odin.ietf.org>; Thu, 9 Jan 2003 23:27:40 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0A4det19995
	for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 23:39:40 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A4deJ19992
	for <sipping-web-archive@optimus.ietf.org>; Thu, 9 Jan 2003 23:39:40 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06912
	for <sipping-web-archive@ietf.org>; Thu, 9 Jan 2003 23:26:51 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A4cGJ19966;
	Thu, 9 Jan 2003 23:38:17 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A4bBJ19583
	for <sipping@optimus.ietf.org>; Thu, 9 Jan 2003 23:37:11 -0500
Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06866
	for <sipping@ietf.org>; Thu, 9 Jan 2003 23:24:38 -0500 (EST)
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15])
	by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h0A4Rd0E001295;
	Thu, 9 Jan 2003 20:27:39 -0800 (PST)
Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA)
	with SMTP id AAJ90618;
	Thu, 9 Jan 2003 20:27:38 -0800 (PST)
From: "Cullen Jennings" <fluffy@cisco.com>
To: "Adam Roach" <adam@dynamicsoft.com>,
        "'Henning Schulzrinne'" <hgs@cs.columbia.edu>,
        "Rosen, Brian" <Brian.Rosen@marconi.com>
Cc: "'Paul Kyzivat'" <pkyzivat@cisco.com>, <sipping@ietf.org>
Subject: RE: [Sipping] Do Phones Have Dial Plans, or do Proxies map?  was RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
Date: Thu, 9 Jan 2003 20:32:22 -0800
Message-ID: <DLEHICEBMNEIPCACNLPCCEPFCFAA.fluffy@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-reply-to: <9BF66EBF6BEFD942915B4D4D45C051F3A643F9@DYN-TX-EXCH-001.dynamicsoft.com>
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


I'd really love to agree with you but I suspect that several vendor's
marketing departments will consider it a "feature" not to have to hit send.
They will continue to use regular expressions of the MGCP digit map kind
combined with timers to decide when to send the INVITE.

When the phone sends and INVITE is an orthogonal issue from if the INVITE
contains the dialed digits or an E.164 number. When designing systems it
sure would be easier if every phone had a single globally unique number but
this is simply not plausible because the PSTN address space has been
constructed to be a scarce, and thus somewhat expense, resource. I still
think it should be possible, and well worth while, to figure out some common
normalized form that can represent E.164 number and phones without an E.164
number. It may be nothing more than a number with a + before it is an E.164
number and other numbers are a digit string that is interpreted purely in a
context that is known to the proxy that controls the domain of the AOR of
the UAC.

Cullen


> -----Original Message-----
> From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]On Behalf Of
> Adam Roach
> Sent: Thursday, January 09, 2003 8:26 AM
> To: 'Henning Schulzrinne'; Rosen, Brian
> Cc: 'Paul Kyzivat'; 'sipping@ietf.org'
> Subject: RE: [Sipping] Do Phones Have Dial Plans, or do Proxies map? was
> RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
>
>
> > - Recognizing patterns so that one can keep the old
> > "no-need-to-hit-dial" user interface.
>
> AAAAAUUUUGGGHHHHH!!! AAAAAUUUUGGGHHHHH!!! AAAAAUUUUGGGHHHHH!!!
>
> No!
>
> Cell phones have sufficiently trained the public that it's
> okay to hit something like "OK" or "YES" or "DIAL" or "ENTER"
> after a phone number. It makes life so much easier for user
> interface designers and users alike. For the love of all that
> is good, let's not encourage backsliding.
>
> /a
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP
>

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Fri Jan 10 00:47:00 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08329
	for <sipping-archive@odin.ietf.org>; Fri, 10 Jan 2003 00:47:00 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0A5x2Y23581
	for sipping-archive@odin.ietf.org; Fri, 10 Jan 2003 00:59:02 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A5x2J23577
	for <sipping-web-archive@optimus.ietf.org>; Fri, 10 Jan 2003 00:59:02 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08322
	for <sipping-web-archive@ietf.org>; Fri, 10 Jan 2003 00:46:18 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A5w5J23557;
	Fri, 10 Jan 2003 00:58:05 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A5vMJ23510
	for <sipping@optimus.ietf.org>; Fri, 10 Jan 2003 00:57:22 -0500
Received: from hss.hns.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08296
	for <sipping@ietf.org>; Fri, 10 Jan 2003 00:44:48 -0500 (EST)
From: hbhondwe@hss.hns.com
Received: from sampark.hss.hns.com (sampark [139.85.229.22])
	by hss.hns.com (8.11.6/8.11.2) with SMTP id h0A5Loa27574
	for <sipping@ietf.org>; Fri, 10 Jan 2003 10:51:50 +0530
Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 65256CAA.001F6E54 ; Fri, 10 Jan 2003 11:13:18 +0530
X-Lotus-FromDomain: HSSBLR
To: sipping@ietf.org
Message-ID: <65256CAA.001F6D1D.00@sampark.hss.hns.com>
Date: Fri, 10 Jan 2003 11:13:02 +0530
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: [Sipping] Comments: I-D ACTION:draft-miller-sip-tcap-00.txt
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>



Hi ,

I have a fundamental question on the the usage of SIP for transporting TCAP
messages.

If I understand correctly the figure 1 in the draft, is  something like the
following:


SIP Element                                 Signaling Gateway
SS7 Node

TCAP applications
PSTN Services
TCAP
TCAP
SIP---------------------IP--------------SIP||SS7--------------SS7----------
-----SS7


Here a TCAP peer will be running on the SIP Element and will use SIP to
exchange TCAP
messages with peers(i.e other TCAPs) in the PSTN network.

However, SIGTRAN protocols defined also by the SIGTRAN Working group of the
 IETF have been
especially designed for transporting Trunk/Access signaling over IP.

So, could one not better(IMO) accomplish this  by the following
configuration
using SIGTRAN?


SIP Element                             Signaling Gateway
                                   PSTN Node

TCAP applications

             PSTN Services
TCAP

                                      TCAP
SIGTRAN---------IP-------------SIGTRAN||SS7 ----------------SS7--------SS7
(SUA over SCTP)                  (SUA over SCTP)


The difference of course is that in this case the SIP Element and the
Signaling Gateway
will have to (also) support SIGTRAN.
They could continue to support SIP as well.

Or am i missing something?

thanks
harsh






This message is proprietary to Hughes Software Systems Limited (HSS) and is
intended solely for the use of the individual to whom it is addressed.  It
may contain privileged or confidential information and should not be
circulated or used for any purpose other than for what it is intended.  If
you have received this message in error, please notify the originator
immediately.  If you are not the intended recipient, you are notified that
you are strictly prohibited from using, copying, altering, or disclosing
the contents of this message.  HSS accepts no responsibility for loss or
damage arising from the use of the information transmitted by this email
including damage from virus.


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Fri Jan 10 01:42:10 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08988
	for <sipping-archive@odin.ietf.org>; Fri, 10 Jan 2003 01:42:10 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0A6sD627139
	for sipping-archive@odin.ietf.org; Fri, 10 Jan 2003 01:54:13 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A6sDJ27136
	for <sipping-web-archive@optimus.ietf.org>; Fri, 10 Jan 2003 01:54:13 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08982
	for <sipping-web-archive@ietf.org>; Fri, 10 Jan 2003 01:41:27 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A6rJJ27088;
	Fri, 10 Jan 2003 01:53:19 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A6qqJ27046
	for <sipping@optimus.ietf.org>; Fri, 10 Jan 2003 01:52:52 -0500
Received: from hss.hns.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08970
	for <sipping@ietf.org>; Fri, 10 Jan 2003 01:40:15 -0500 (EST)
From: hbhondwe@hss.hns.com
Received: from sampark.hss.hns.com (sampark [139.85.229.22])
	by hss.hns.com (8.11.6/8.11.2) with SMTP id h0A6HNa27962
	for <sipping@ietf.org>; Fri, 10 Jan 2003 11:47:23 +0530
Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 65256CAA.002486C7 ; Fri, 10 Jan 2003 12:08:57 +0530
X-Lotus-FromDomain: HSSBLR
To: sipping@ietf.org
Message-ID: <65256CAA.0024865B.00@sampark.hss.hns.com>
Date: Fri, 10 Jan 2003 12:08:55 +0530
Subject: Re: [Sipping] Comments: I-D ACTION:draft-miller-sip-tcap-00.txt
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>



sorry,text corrected in the following mail.




hbhondwe@hss.hns.com on 01/10/2003 11:13:02 AM

To:   sipping@ietf.org
cc:    (bcc: Harsh Bhondwe/HSSBLR)

Subject:  [Sipping] Comments: I-D ACTION:draft-miller-sip-tcap-00.txt






Hi ,

I have a fundamental question on the the usage of SIP for
transporting TCAP messages.

If I understand correctly the figure 1 in the draft, is
something like the following:


SIP Element           Signaling Gateway         SS7 Node

TCAP applications                               PSTN Services
TCAP                                            TCAP
SIP--------IP----------SIP||SS7--------SS7------SS7


Here a TCAP peer will be running on the SIP Element and will
use SIP to exchange TCAP messages with peers(i.e other TCAPs)
in the PSTN network.

However, SIGTRAN protocols defined also by the SIGTRAN
Working group of the  IETF have been especially designed
for transporting Trunk/Access signaling over IP.

So, could one not better accomplish this  by the
following configuration using SIGTRAN?


SIP Element                   Signaling Gateway        PSTN Node

TCAP applications                                   PSTN Services
TCAP                                                   TCAP
SIGTRAN---------IP-------------SIGTRAN||SS7 ---SS7-----SS7
(SUA over SCTP)                (SUA over SCTP)


The difference of course is that in this case the SIP
Element and the Signaling Gateway will have to (also)
support SIGTRAN.They could continue to support SIP as well.

Or am i missing something?

thanks
harsh





_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP




_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Fri Jan 10 02:13:42 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19343
	for <sipping-archive@odin.ietf.org>; Fri, 10 Jan 2003 02:13:42 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0A7PkI05017
	for sipping-archive@odin.ietf.org; Fri, 10 Jan 2003 02:25:46 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A7PjJ05014
	for <sipping-web-archive@optimus.ietf.org>; Fri, 10 Jan 2003 02:25:45 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19327
	for <sipping-web-archive@ietf.org>; Fri, 10 Jan 2003 02:12:53 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A7OWJ04923;
	Fri, 10 Jan 2003 02:24:32 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09BqdJ17026
	for <sipping@optimus.ietf.org>; Thu, 9 Jan 2003 06:52:39 -0500
Received: from mta0 (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07208
	for <sipping@ietf.org>; Thu, 9 Jan 2003 06:40:26 -0500 (EST)
Received: from w07087a (mta0 [172.17.1.62])
 by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
 2002)) with ESMTPA id <0H8G00KUI362BL@mta0.huawei.com> for sipping@ietf.org;
 Thu, 09 Jan 2003 19:42:03 +0800 (CST)
Date: Thu, 09 Jan 2003 19:44:48 +0800
From: wenkai <wkai@huawei.com>
To: sipping@ietf.org
Message-id: <000c01c2b7d4$83a036a0$af064d0a@w07087a>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
Content-type: multipart/alternative;
 boundary="Boundary_(ID_RLquw50LCqUi3x3SciZZRw)"
X-Priority: 3
X-MSMail-priority: Normal
Subject: [Sipping] a question about 3pcc
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

--Boundary_(ID_RLquw50LCqUi3x3SciZZRw)
Content-type: text/plain; charset=gb2312
Content-Transfer-Encoding: 7BIT

Hi,
The following is the "Mid-Call Announcement" call flow from "draft-ietf-sipping-3pcc-02.txt". 
After hanging up with the media server, the controller reconnects the Pre-Paid user to the called party. I think the media stream(stream 3) established between Pre-Paid user and the Called Party maybe is not the same as the original media stream(stream 1).
In practice, maybe we want to have the same media codec as original one when we restore a call.
Could you please give the call flow to reach this requirment?

Best Regards
Kevin


     Pre-Paid User        Controller         Called Party        Media Server
          |                   |                   |                   |
          |..........stream 1.....................|                   |
          |                   |(1) INV SDP c=0    |                   |
          |                   |------------------>|                   |
          |                   |(2) 200 answer1    |                   |
          |                   |<------------------|                   |
          |                   |(3) ACK            |                   |
          |                   |------------------>|                   |
          |(4) INV no SDP     |                   |                   |
          |<------------------|                   |                   |
          |(5) 200 offer2     |                   |                   |
          |------------------>|                   |                   |
          |                   |(6) INV offer2     |                   |
          |                   |-------------------------------------->|
          |                   |(7) 200 answer2    |                   |
          |                   |<--------------------------------------|
          |(8) ACK answer2    |                   |                   |
          |<------------------|                   |                   |
          |                   |(9) ACK            |                   |
          |                   |-------------------------------------->|
          |(10) RTP           |                   |                   |
          |..........stream 2.........................................|
          |                   |(11) BYE           |                   |
          |                   |-------------------------------------->|
          |                   |(12) 200 OK        |                   |
          |                   |<--------------------------------------|
          |                   |(13) INV no SDP    |                   |
          |                   |------------------>|                   |
          |                   |(14) 200 offer3    |                   |
          |                   |<------------------|                   |
          |(15) INV offer3'   |                   |                   |
          |<------------------|                   |                   |
          |(16) 200 answer3'  |                   |                   |
          |------------------>|                   |                   |
          |                   |(17) ACK answer3'  |                   |
          |                   |------------------>|                   |
          |(18) ACK           |                   |                   |
          |<------------------|                   |                   |
          |(19) RTP           |                   |                   |
          |..........stream 3.....................|                   |

--Boundary_(ID_RLquw50LCqUi3x3SciZZRw)
Content-type: text/html; charset=gb2312
Content-Transfer-Encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=gb2312" http-equiv=Content-Type>
<META content="MSHTML 5.00.3315.2870" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face="Courier New" size=2>Hi,</FONT></DIV>
<DIV><FONT face="Courier New" size=2>The following is the "Mid-Call 
Announcement" call flow from "draft-ietf-sipping-3pcc-02.txt". </FONT></DIV>
<DIV><FONT face="Courier New" size=2>After hanging up with the media server, the 
controller reconnects the Pre-Paid user to the&nbsp;called party.&nbsp;I think 
the media stream(stream 3) established between Pre-Paid user and the Called 
Party maybe is not the same as&nbsp;the original media stream(stream 
1).</FONT></DIV>
<DIV><FONT face="Courier New" size=2>In practice, maybe we want to have the same 
media codec as&nbsp;original one when we restore a call.</FONT></DIV>
<DIV><FONT face="Courier New" size=2>Could&nbsp;you please give&nbsp;the call 
flow to reach this requirment?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face="Courier New" size=2>Best Regards</FONT></DIV>
<DIV><FONT face="Courier New" size=2>Kevin</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face="Courier New" size=2>&nbsp;&nbsp;&nbsp;&nbsp; Pre-Paid 
User&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Controller&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Called 
Party&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media Server</FONT></DIV>
<DIV><FONT face=Arial size=2><FONT face=Arial size=2><FONT face=Arial 
size=2><FONT face="Courier New" 
size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR></FONT></FONT></FONT></FONT><FONT face=Arial size=2><FONT 
face="Courier New" size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|..........stream 
1.....................|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR></FONT></FONT><FONT face="Courier New" 
size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|(1) INV SDP c=0&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|------------------&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|(2) 200 answer1&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&lt;------------------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|(3) ACK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|------------------&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |(4) INV no 
SDP&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&lt;------------------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |(5) 200 
offer2&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|------------------&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|(6) INV offer2&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|--------------------------------------&gt;|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|(7) 200 answer2&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&lt;--------------------------------------|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|(8) ACK answer2&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&lt;------------------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|(9) ACK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|--------------------------------------&gt;|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|(10) RTP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |..........stream 
2.........................................|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|(11) BYE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|--------------------------------------&gt;|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|(12) 200 OK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&lt;--------------------------------------|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|(13) INV no SDP&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|------------------&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|(14) 200 offer3&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&lt;------------------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |(15) INV 
offer3'&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&lt;------------------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |(16) 200 
answer3'&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|------------------&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|(17) ACK answer3'&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|------------------&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |(18) 
ACK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&lt;------------------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |(19) 
RTP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |..........stream 
3.....................|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|</FONT></DIV></BODY></HTML>

--Boundary_(ID_RLquw50LCqUi3x3SciZZRw)--
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Fri Jan 10 08:27:16 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27502
	for <sipping-archive@odin.ietf.org>; Fri, 10 Jan 2003 08:27:16 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0ADdRO31649
	for sipping-archive@odin.ietf.org; Fri, 10 Jan 2003 08:39:27 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ADdRJ31646
	for <sipping-web-archive@optimus.ietf.org>; Fri, 10 Jan 2003 08:39:27 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27458
	for <sipping-web-archive@ietf.org>; Fri, 10 Jan 2003 08:25:57 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ADbWJ31531;
	Fri, 10 Jan 2003 08:37:32 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ADapJ30803
	for <sipping@optimus.ietf.org>; Fri, 10 Jan 2003 08:36:51 -0500
Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27434
	for <sipping@ietf.org>; Fri, 10 Jan 2003 08:24:08 -0500 (EST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA00061;
	Fri, 10 Jan 2003 08:27:24 -0500 (EST)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA22774;
	Fri, 10 Jan 2003 08:27:22 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <ZVACNFZM>; Fri, 10 Jan 2003 08:27:21 -0500
Message-ID: <313680C9A886D511A06000204840E1CF030B5D01@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Henning Schulzrinne'" <hgs@cs.columbia.edu>,
        Adam Roach
	 <adam@dynamicsoft.com>
Cc: "Rosen, Brian" <Brian.Rosen@marconi.com>,
        "'Paul Kyzivat'"
	 <pkyzivat@cisco.com>,
        "'sipping@ietf.org'" <sipping@ietf.org>
Subject: RE: [Sipping] Do Phones Have Dial Plans, or do Proxies map?  was 
	RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
Date: Fri, 10 Jan 2003 08:27:20 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

Actually, I'm happy with a "Dial" button.

I'll note most existing SIP phones don't do this (or at least don't
have a physical "Dial" button, I've seen some with softkeys).

However, the issue remains.  If I dial 6744 on my sip phone (and press
dial), the sipphone on my admin's desk should ring.  I should not have
to dial +17247426744.  The fact that I dialed a 4 digit number with
a 6 as the starting digit tells my system that it is an internal
extension.  A dial plan is the thing that "knows" this.

What do you want to have happen:
1) tel:6744; context=+1724742
2) tel:6744; context=marconi-pittsburgh-local-extension
3) tel:+17247426744

Note the last is problematic.  As Mike Pierce points out, not all
extensions have E.164s

And, to amplify the thread that started this, how many identities does
my admin's UA have to understand? 

Again, I'm not opposed to making dial string expansion be a requirement
of the UA, as long as we standardize the form of the expansion, and the
mechanism by which the UA learns it.

Brian

> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Thursday, January 09, 2003 9:07 PM
> To: Adam Roach
> Cc: Rosen, Brian; 'Paul Kyzivat'; 'sipping@ietf.org'
> Subject: Re: [Sipping] Do Phones Have Dial Plans, or do 
> Proxies map? was
> RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
> 
> 
> In case there's doubt: I was not suggesting that we do this. I was 
> trying to find out from Brian what he meant, since the two 
> problem have 
> very different solution sets. The 'abbreviated dialing' case requires 
> nothing except a suitable URI scheme and the translation 
> services of an 
> outbound proxy.
> 
> Adam Roach wrote:
> >>- Recognizing patterns so that one can keep the old 
> >>"no-need-to-hit-dial" user interface.
> > 
> > 
> > AAAAAUUUUGGGHHHHH!!! AAAAAUUUUGGGHHHHH!!! AAAAAUUUUGGGHHHHH!!!
> > 
> > No!
> > 
> > Cell phones have sufficiently trained the public that it's
> > okay to hit something like "OK" or "YES" or "DIAL" or "ENTER"
> > after a phone number. It makes life so much easier for user
> > interface designers and users alike. For the love of all that
> > is good, let's not encourage backsliding.
> > 
> > /a
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Fri Jan 10 08:29:15 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27579
	for <sipping-archive@odin.ietf.org>; Fri, 10 Jan 2003 08:29:15 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0ADfQk31767
	for sipping-archive@odin.ietf.org; Fri, 10 Jan 2003 08:41:26 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ADfQJ31764
	for <sipping-web-archive@optimus.ietf.org>; Fri, 10 Jan 2003 08:41:26 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27565
	for <sipping-web-archive@ietf.org>; Fri, 10 Jan 2003 08:28:10 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ADbLJ31369;
	Fri, 10 Jan 2003 08:37:21 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ADa7J30759
	for <sipping@optimus.ietf.org>; Fri, 10 Jan 2003 08:36:07 -0500
Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27421
	for <sipping@ietf.org>; Fri, 10 Jan 2003 08:23:24 -0500 (EST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA00025;
	Fri, 10 Jan 2003 08:26:40 -0500 (EST)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA22512;
	Fri, 10 Jan 2003 08:26:41 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <ZVACNFXL>; Fri, 10 Jan 2003 08:26:40 -0500
Message-ID: <313680C9A886D511A06000204840E1CF030B5D00@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Peterson, Jon'" <jon.peterson@neustar.biz>,
        "'Drage, Keith (Keith)'"
	 <drage@lucent.com>,
        "'Henning Schulzrinne'" <hgs@cs.columbia.edu>
Cc: "'sipping@ietf.org'" <sipping@ietf.org>
Subject: RE: [Sipping] URIs for Gateways
Date: Fri, 10 Jan 2003 08:26:40 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

Nope you have the wrong picture.  See below

 
> I may have been a little thick up to this point - I now think that by
> 'gateway' you mean something that acts like a PBX (I was kind 
> of thinking
> you meant a PSTN gateway, which has very different 
> requirement for all of
> this). From the notes below, it sounds like in your case the 
> PBX is a SIP UA
> that has a set of hardwired phone lines (your 'ports'), each 
> of which goes
> to a single black phone. 
No we have a set of gateways, that are SIP UAs, that are connected to
either a PSTN local loop (which may be an analog loop, DID trunk,
a BRI, PRI or CAS trunk, or to a PBX station loop, which may be analog
or digital, or in some cases a PRI connected to a PBX.  These
gateways provide the path for call.  In the former case, the site
has an all-VoIP phone system, and the gateways are the connection
to the PSTN.  In the latter case, there is a local PBX, but there
is also a set of VoIP stations.  The gateways provide the link between
these systems.

There are gateways that connect to phones, but this discussion is not 
about them.


>You want a proxy server to manage 
> the mappings of
> identifiers (be they tel URLs or SIP URIs) to particular PBXs 
> and PBX ports,
> because you want the PBXs themselves to be ignorant of the URIs that
> identify the phones that they manage. Is that right?
No, we want the proxy server to manage the mappings because the sip
identities in the sip phones are people with real sip URIs (like
alice@atlanta.com) and not tel uris.  However, each of the
sip uris ALSO has a telephone number.  If you call alice with either
sip:alice@atlanta.com or tel:+14125551212, or +14125551212 on the PSTN,
the call will go to Alice's sipphone.  The problem is that alice has 
two uris (one is a tel uri), and we don't want to have all the UAs 
registering twice under both identities.  Instead, we have a proxy 
server that understands the mapping.

> 
> Ordinarily, we say that in SIP architectures, features are 
> pushed to the
> edges, not to the core of the network. Abstract out the PBX 
> for a minute,
> and imagine coming forward with a SIP architecture in which 
> you have a set
> of user agents that are so simple that they don't know their 
> own identity,
> they can't learn it somehow from the network, and therefore 
> cannot correctly
> populate the From header field of requests they generate. 
> Instead, they'd
> like a proxy server to somehow populate this identity in 
> requests as they
> are sent through the network. This would be essentially the 
> same problem you
> brought to the list.
No the problem is that they have two identities, one of which
they "know", and we want them to be able to be reached by
any (there could be more than two) of these identities.

The relationship between the identities is in a centralized (well,
actually it's distributed, replicated) database. 
> 
> My reaction would probably be that RFC3261 assumes that SIP 
> UAs have the
> ability to populate a From header field. Even my 1G CDMA cell 
> phone knows
> its own phone number. A PBX usually means something with a 
> lot of features.
> Even if in your architecture you're trying to radically 
> reduce the cost of
> the PBX component, a PBX can be expected to more be complex 
> than, say, the
> sorts of simple SIP phones we see today (which are in my 
> experience all
> capable of mananging one identity, if not several, for their 
> users). Is it
> really that much harder for a PBX to look at the string 
> 'port3' in the R-U
> of a SIP request and map that to a hardware resource than it 
> is for a PBX to
> look at the string '+12025332600' in the R-U of a SIP request 
> and map that
> to a hardware resource? PBXs that are compliant SIP 
> implementations will
> have to perform a number of vastly more complicated operations.
Actually, I know of no sip UAs that handle multiple identities.
I don't have direct experience with 3G phones, so they might.
We have a half dozen sip phones, a half dozen soft phones,
probably 10 different vendors of gateways and they all have the
same characteristic that they only have one identity at a time.
 
> 
> In other words, it's hard for me to understand why the PBX UA 
> (the edge)
> isn't the right place to manage the mapping between an 
> identifier (a phone
> number) and a port. Doing this in a proxy (the core) 
> introduces a number of
> data synchronization questions as well as the protocol 
> questions that have
> run through this thread. Is there some special reason why 
> this PBX cannot be
> expected to do one of the simpler things that we ask of UAs? 
> Is there a
> particularly large number of ports that you imagine such a 
> PBX would manage
> (in the millions, maybe)? It would really help to have more 
> background. The
> motivation for this is a little obscure to me.
Small gateways are pretty simple.  There are between 1 and maybe
24 ports, each of which is a one line/loop connection, like an
analog loop.  Big gateways in this context handle 1-8 PRIs.
Each of the PRIs has blocks of directory numbers assigned to it.

There are the usual issues with assigning numbers to "phones" (I
used quotes, because it's actually users; we assign a number to
a user, not to a phone) = multiple "phones" can be assigned to one
number, multiple numbers can be assigned to one "phone".  There
are no gateways I know of that understand how to do this, 
although a SIP proxy servers could use the Single Line Extension 
and forking proxy mechanisms to simulate it.  The point here is 
that it's the PROXY that does the work, not the UA.

If we want to mandate that all sip UAs must handle multiple identities,
and standardize a way that it learns all the identities associated with 
any one of them, then we probably can avoid dealing with my "translator".

Brian
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Fri Jan 10 16:46:57 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17362
	for <sipping-archive@odin.ietf.org>; Fri, 10 Jan 2003 16:46:57 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0ALxJP32213
	for sipping-archive@odin.ietf.org; Fri, 10 Jan 2003 16:59:19 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ALxJJ32210
	for <sipping-web-archive@optimus.ietf.org>; Fri, 10 Jan 2003 16:59:19 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17355
	for <sipping-web-archive@ietf.org>; Fri, 10 Jan 2003 16:46:26 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ALwbJ32195;
	Fri, 10 Jan 2003 16:58:37 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ALvdJ32162
	for <sipping@optimus.ietf.org>; Fri, 10 Jan 2003 16:57:39 -0500
Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17329
	for <sipping@ietf.org>; Fri, 10 Jan 2003 16:44:46 -0500 (EST)
From: jh@lohi.eng.song.fi
Received: from harjus.eng.song.fi ([195.10.149.20])
	by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian))
	id 18X70T-00067r-00; Fri, 10 Jan 2003 23:48:01 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15903.16273.453205.50103@harjus.eng.song.fi>
Date: Fri, 10 Jan 2003 23:48:01 +0200
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
Cc: "'Peterson, Jon'" <jon.peterson@neustar.biz>,
        "'Drage, Keith (Keith)'"
	 <drage@lucent.com>,
        "'Henning Schulzrinne'" <hgs@cs.columbia.edu>,
        "'sipping@ietf.org'" <sipping@ietf.org>
Subject: RE: [Sipping] URIs for Gateways
In-Reply-To: <313680C9A886D511A06000204840E1CF030B5D00@whq-msgusr-02.pit.comms.marconi.com>
References: <313680C9A886D511A06000204840E1CF030B5D00@whq-msgusr-02.pit.comms.marconi.com>
X-Mailer: VM 7.03 under Emacs 21.2.1
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Rosen, Brian writes:

 > Actually, I know of no sip UAs that handle multiple identities.

on my desj i have cisco 7960 that understands lots of different
identities.  on my pc i have kphone that understand any number of
identities.  these can be phone numbers of email style sip uris.
in addition, in my proxy a user can have any number of aliases for
itself.  thus i don't really see what the problem is.

 > We have a half dozen sip phones, a half dozen soft phones,
 > probably 10 different vendors of gateways and they all have the
 > same characteristic that they only have one identity at a time.

looks you haven't got any good one.  keep on shopping and junk the
junk.  the same for your proxy and pstn gw.

-- juha

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Fri Jan 10 17:52:14 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19100
	for <sipping-archive@odin.ietf.org>; Fri, 10 Jan 2003 17:52:13 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0AN4bY04192
	for sipping-archive@odin.ietf.org; Fri, 10 Jan 2003 18:04:37 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AN4bJ04189
	for <sipping-web-archive@optimus.ietf.org>; Fri, 10 Jan 2003 18:04:37 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19091
	for <sipping-web-archive@ietf.org>; Fri, 10 Jan 2003 17:51:42 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AN3EJ04149;
	Fri, 10 Jan 2003 18:03:14 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AN2XJ04119
	for <sipping@optimus.ietf.org>; Fri, 10 Jan 2003 18:02:33 -0500
Received: from mail.pingtel.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19063
	for <sipping@ietf.org>; Fri, 10 Jan 2003 17:49:38 -0500 (EST)
Received: from pingtel.com (cdhcp144.pingtel.com [10.1.1.144])
	by mail.pingtel.com (8.11.6/8.11.6) with ESMTP id h0AMqkR03511;
	Fri, 10 Jan 2003 17:52:46 -0500
Message-ID: <3E1F4E91.C2F22A30@pingtel.com>
Date: Fri, 10 Jan 2003 17:52:01 -0500
From: "Daniel G. Petrie" <dpetrie@pingtel.com>
Organization: Pingtel Corp.  http://www.pingtel.com
X-Mailer: Mozilla 4.73 [en]C-{C-UDP; EBM-SONY1}  (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
CC: "'Henning Schulzrinne'" <hgs@cs.columbia.edu>,
        Adam Roach <adam@dynamicsoft.com>,
        "'Paul Kyzivat'" <pkyzivat@cisco.com>,
        "'sipping@ietf.org'" <sipping@ietf.org>
Subject: Re: [Sipping] Do Phones Have Dial Plans, or do Proxies map?  was RE: 
 [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
References: <313680C9A886D511A06000204840E1CF030B5D01@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

There is actually a third reason to have dial plans on the UA.  The
first two have already been brought up:

1) To know when the user is done dialing
2) To know how to form a canonical URL (tel , sip or sips)
3) To know how to route the INVITE to the correct outbound proxy

On the first one, knowing when the user is done dialing,  I am afraid, as
Cullen pointed out, the market (at least in North America) wants a phone
that knows when the user is done dialing.  There are too many people
who still like the pre-cell phone metaphor. Sorry but the people on this
list do not buy enough phones to decide this one ;-).

The UA needs to know how it is going to form a cannonical URL from
the mess of characters and digits the user entered.  So as Brian pointed
out you need some regexp to transform the entered characters into a
URL.   Well guess what, every proxy vendor wants this to be a little
different.   Some want short strings (AKA extensions) transformed
differently
than long strings (AKA E.164 numbers).  So call it what you want you
end up with the equivalent of a dial plan.  The best we can do here is
to come of with a standardized (or call it BCP) way to write the
transforms.  We can write a standard that says this is the one and
only transform, but no phone vendor that has a dial plan mechanism
will be able to drop their dial plan support because they have customers
using it.  However I am sure the market would be happy to push
vendors to support a standardized dial plan description mechanism.

The third use of dial plans is for routing purposes.  I know!  That is
what the proxy is supposed to do.  However there are several uses
for doing some simple routing from the phone base upon the "dialed
string":

a) Functional routing: where based upon the purpose of the call the
user wants the call routed differently.  For example I have a phone
at home from which I make personal calls via my favorite service
provider and from which I make business calls via my enterprise
IP PBX.  I want my private/personal calls private and my business
does not want to pay for my personal calls.   A simple, familiar
metaphor for this is to use a dialing prefix (e.g. dial 9 and number
for business call, dial 8 and number for personal calls).  The alternatives

would be to sell home/office users two phones (I wish that would fly)
or put a proxy in every home/office (I would not mind selling that
many proxies if that would fly as well).

b) Load balancing routing:  based upon my dialed string I may
want to use a different out bound proxy.   Domestic US calls
go to one proxy, international calls go to another, 911/emergency
calls go directly to the local emergency gateway.  Can this be
done by the proxy? Sometimes, if I can get to it, but once you
have a dial plan on the phone, this is just about free from
both an implementation and compute cost perspective (e.g.
loose routing with a Route header in the regexp/transform).

I am happy to remove functionality from the UA and not support
it, but I am afraid the dial plan is here to stay in the UA.  I  think
our best path forward is with a standard way to specify the dial plan
transforms.



"Rosen, Brian" wrote:

> Actually, I'm happy with a "Dial" button.
>
> I'll note most existing SIP phones don't do this (or at least don't
> have a physical "Dial" button, I've seen some with softkeys).
>
> However, the issue remains.  If I dial 6744 on my sip phone (and press
> dial), the sipphone on my admin's desk should ring.  I should not have
> to dial +17247426744.  The fact that I dialed a 4 digit number with
> a 6 as the starting digit tells my system that it is an internal
> extension.  A dial plan is the thing that "knows" this.
>
> What do you want to have happen:
> 1) tel:6744; context=+1724742
> 2) tel:6744; context=marconi-pittsburgh-local-extension
> 3) tel:+17247426744
>
> Note the last is problematic.  As Mike Pierce points out, not all
> extensions have E.164s
>
> And, to amplify the thread that started this, how many identities does
> my admin's UA have to understand?
>
> Again, I'm not opposed to making dial string expansion be a requirement
> of the UA, as long as we standardize the form of the expansion, and the
> mechanism by which the UA learns it.
>
> Brian
>
> > -----Original Message-----
> > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> > Sent: Thursday, January 09, 2003 9:07 PM
> > To: Adam Roach
> > Cc: Rosen, Brian; 'Paul Kyzivat'; 'sipping@ietf.org'
> > Subject: Re: [Sipping] Do Phones Have Dial Plans, or do
> > Proxies map? was
> > RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
> >
> >
> > In case there's doubt: I was not suggesting that we do this. I was
> > trying to find out from Brian what he meant, since the two
> > problem have
> > very different solution sets. The 'abbreviated dialing' case requires
> > nothing except a suitable URI scheme and the translation
> > services of an
> > outbound proxy.
> >
> > Adam Roach wrote:
> > >>- Recognizing patterns so that one can keep the old
> > >>"no-need-to-hit-dial" user interface.
> > >
> > >
> > > AAAAAUUUUGGGHHHHH!!! AAAAAUUUUGGGHHHHH!!! AAAAAUUUUGGGHHHHH!!!
> > >
> > > No!
> > >
> > > Cell phones have sufficiently trained the public that it's
> > > okay to hit something like "OK" or "YES" or "DIAL" or "ENTER"
> > > after a phone number. It makes life so much easier for user
> > > interface designers and users alike. For the love of all that
> > > is good, let's not encourage backsliding.
> > >
> > > /a
> >
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Sat Jan 11 10:39:57 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13428
	for <sipping-archive@odin.ietf.org>; Sat, 11 Jan 2003 10:39:57 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0BFqfi27968
	for sipping-archive@odin.ietf.org; Sat, 11 Jan 2003 10:52:41 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BFqeJ27965
	for <sipping-web-archive@optimus.ietf.org>; Sat, 11 Jan 2003 10:52:40 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13403
	for <sipping-web-archive@ietf.org>; Sat, 11 Jan 2003 10:39:25 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BFppJ27924;
	Sat, 11 Jan 2003 10:51:51 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BFoVJ27883
	for <sipping@optimus.ietf.org>; Sat, 11 Jan 2003 10:50:31 -0500
Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13374
	for <sipping@ietf.org>; Sat, 11 Jan 2003 10:37:16 -0500 (EST)
Received: from cs.columbia.edu (dclient13.netlab.uky.edu [204.198.76.127])
	(user=hgs10 mech=PLAIN bits=0)
	by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0BFeYSY003162
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Sat, 11 Jan 2003 10:40:34 -0500 (EST)
Message-ID: <3E1F2D76.3000500@cs.columbia.edu>
Date: Fri, 10 Jan 2003 15:30:46 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Drage, Keith (Keith)" <drage@lucent.com>
CC: "'Tom-PT Taylor'" <taylor@nortelnetworks.com>,
        "'sipping@ietf.org'" <sipping@ietf.org>
Subject: Re: [Sipping] Comments on sos draft -0
References: <475FF955A05DD411980D00508B6D5FB00439EB8F@en0033exch001u.uk.lucent.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Drage, Keith (Keith) wrote:
 > Is the number 3333 on an internal network an emergency number in the
 > terms of the sos draft?
 >
 > The way I read the defined sos url is that it only reachs public
 > emergency service centres. therefore the scope of the document with
 > regard to tel urls is to define the format of tel urls to reach those
 > same centres. Have I misunderstood the scope? We possible need to
 > extend Hennings proposed scope to make this clear.

Interesting question. I think the boundaries are kind of fuzzy. For 
example, most US universities have a campus police department; some even 
have a campus ambulance and fire department (UMass Amherst did, for 
example). If they are a state university, they are even public 
institutions. In some cases, they have separate identifiers from the 
public 911 system (99 on the Columbia campus), but they are otherwise 
indistinguishable from an ECC.

One solution might be to allow this as a qualification to 'sos', as in 
'sos.internal' or 'sos.private'.

 >
 > I do think we need to delve further into the subject of context,
 > possible in association with additional clarifications in the
 > rfc2806bis draft.

Agreed; in general, 'service numbers' are one of the major open issues 
for that draft.


 > It therefore seems to me that we could say the same about emergency
 > numbers that are globally unique.

I assume, globally unique here means that they are not assigned for 
another purpose (extensions don't count). For 800#, we agreed after a 
long debate that the assignment system guarantees that the same number 
will not be assigned to two logically separate entities. It would be 
nice if we could get all national regulators to agree that assigning 911 
to directory services would be a really dumb idea. I suspect that with 
3GPP standardization, that this would be extremely unlikely. We know 
that none of the emergency numbers on the list could be assigned in the 
US since these are valid area codes, not N11 codes.

 >
 > For those emergency numbers that are not globally unique (and we
 > probably need to include 118 and 119 in this list), then looking at
 > the existing RFC 2806 or at the bis, they probably do need a context.
 > What worries me is that the user sticks in an inappropriate context,
 > i.e. the one he uses for all his local calls, rather than one used
 > for national calls. Such inappropriate usage would cause calls to
 > fail. Would a special context used only for local service numbers be
 > appropriate here? My thinking here is that if we give the user
 > something real to code, then he will not be tempted to code something
 > inappropriate.

The problem is that 118 can mean two different things. I don't see how a 
'use whatever local context applies here' would help with distinguishing

118 - I mean emergency service
and
118 - I mean (Finnish) directory services

If we effectively standardize dial strings, it seems unnecessary to have 
the UA propagate the original number as a tel URI.

One possible algorithm:

- If digits dialed = one of the emergency dial strings (preconfigured or 
locally learned) --> generate 'sos' request

- Otherwise, make local dial-string translation translate this into one of:

. tel:+something global string
. tel:digits;phone-context=local-context

where the translation would include something like
9### -> tel:number;phone-context=+1
for national service numbers.

This could all be expressed through the same set of regexps, as in
911 -> sip:sos@example.com
112 -> sip:sos@example.com
3333 -> sip:sos.private@example.com

(Being offline, I don't have my Megaco dial string reference handy.)

Thus, maybe we can unify the local advertisement of dial strings with 
the local advertisement of emergency numbers. By virtue of the 
translation to 'sos', the UA can readily recognize that this is an 
emergency number.

Henning


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Sat Jan 11 10:39:58 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13441
	for <sipping-archive@odin.ietf.org>; Sat, 11 Jan 2003 10:39:58 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0BFqgj27983
	for sipping-archive@odin.ietf.org; Sat, 11 Jan 2003 10:52:42 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BFqgJ27980
	for <sipping-web-archive@optimus.ietf.org>; Sat, 11 Jan 2003 10:52:42 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13407
	for <sipping-web-archive@ietf.org>; Sat, 11 Jan 2003 10:39:27 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BFpwJ27948;
	Sat, 11 Jan 2003 10:51:58 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BFoWJ27887
	for <sipping@optimus.ietf.org>; Sat, 11 Jan 2003 10:50:32 -0500
Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13377
	for <sipping@ietf.org>; Sat, 11 Jan 2003 10:37:18 -0500 (EST)
Received: from cs.columbia.edu (dclient13.netlab.uky.edu [204.198.76.127])
	(user=hgs10 mech=PLAIN bits=0)
	by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0BFeaXZ005183
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Sat, 11 Jan 2003 10:40:36 -0500 (EST)
Message-ID: <3E1F3CDC.2080706@cs.columbia.edu>
Date: Fri, 10 Jan 2003 16:36:28 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Drage, Keith (Keith)" <drage@lucent.com>
CC: "'sipping@ietf.org'" <sipping@ietf.org>
Subject: Re: [Sipping] Comments on sos draft -03 (URI)
References: <475FF955A05DD411980D00508B6D5FB00439EB90@en0033exch001u.uk.lucent.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

 > Firstly I note that the requirement already was only a SHOULD rather
 > than a MUST. In the case where SHOULD is used I usually prefer to
 > specify some examples of where the SHOULD does not apply as guidance,
 > and this appeared to be the appropriate one.

 > I am not convinced by the argument; that may be answered by what do
 > we expect the UA to do if the OPTIONS request it sends to the tel url
 > it has been given fails? If the user dials that tel url, does the UA
 > continue to treat such a call as an emergency call, or does it flash
 > a message on the users display saying "I don't know what to do with
 > this"?

There are only two choices: try again and hope that it works (maybe 
because somebody botched the OPTIONS implementation) or fail without 
trying. I suspect the robust solution is:

- if OPTIONS doesn't work, warn the user that emergency calls for 
numbers X and Y may not work (but Z seems to). This will cause any 
failures to be discovered early, rather than at the time of emergency. 
One of the problems with the existing corporate emergency number systems 
is that I have no good way to "non-invasive" testing. The OPTIONS 
approach fixes this. 'Ping' has been a very useful network debugging 
tool - consider this the SIP equivalent.

In the translation model I posited in my earlier note, all numbers would 
be translated to sos@.

- if the user still tries to dial those numbers, I guess there's no harm 
in trying.


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Sat Jan 11 11:01:18 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13805
	for <sipping-archive@odin.ietf.org>; Sat, 11 Jan 2003 11:01:18 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0BGE2N29165
	for sipping-archive@odin.ietf.org; Sat, 11 Jan 2003 11:14:02 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BGE2J29162
	for <sipping-web-archive@optimus.ietf.org>; Sat, 11 Jan 2003 11:14:02 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13793
	for <sipping-web-archive@ietf.org>; Sat, 11 Jan 2003 11:00:47 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BGD9J29129;
	Sat, 11 Jan 2003 11:13:09 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BGC4J29099
	for <sipping@optimus.ietf.org>; Sat, 11 Jan 2003 11:12:04 -0500
Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13767
	for <sipping@ietf.org>; Sat, 11 Jan 2003 10:58:49 -0500 (EST)
Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66])
	(user=hgs10 mech=PLAIN bits=0)
	by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0BG26SY008672
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Sat, 11 Jan 2003 11:02:07 -0500 (EST)
Message-ID: <3E204003.6060809@cs.columbia.edu>
Date: Sat, 11 Jan 2003 11:02:11 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
CC: "'sipping@ietf.org'" <sipping@ietf.org>
Subject: Re: [Sipping] URIs for Gateways
References: <313680C9A886D511A06000204840E1CF030B5CE2@whq-msgusr-02.pit.comms.marconi.com>
In-Reply-To: <313680C9A886D511A06000204840E1CF030B5CE2@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

> 1. We add the possibility of a callerId string to a tel uri:
>    telephone-uri = "tel:" [callerIdName LWS] subscriber
>    callerIdName = quoted-string

LWS and quoted strings are not exactly the right syntactic approach for 
tel URIs. Something like a tel URI parameter is much more likely to work 
(and be backwards compatible).

> 
> 2. Gateways accept or send sip uris of the form:
>    sip:"Alice Toklas" 4125551212@gateway.atlanta.com; user=phone; port=3
> or tel uris of the form:
>    tel:"Alice Toklas" +14125551212; port=3

None of these are valid URIs...

> or "ordinary" sip uri's with extra information in a separate header 
> of the form:
>    <header> +14125551212; port=3
> 
> where <header> could be "P-Asserted-Identity", or it could be a new
> header we define for the purpose.
> 
> Then, we have the following possibilities:
> 
> SIP device to gateway (outgoing) call
>    To a phone number
>         use the phone number in the Request-URI & To:, probably
>         in a tel URI, or maybe phonenumber@localdomain; user=phone
> 
>         use normal sip URI in From:
>      
>         If a translator is available, it may assert the phone number
>         for the identity in the From: using <header>
> 
>         proxy may rewrite the Request-URI in the form of
>         sip: phone@gateway;user=phone;port=portnum
>    
>    To a sip URI
>         use the sip uri in the Request-URI and To:
>         use normal sip URI in From:
> 
>         proxy rewrites Request-URI, due to forwarding behavior,
>         ENUM lookup, etc, resulting in a tel URI or a user=phone sip
>         uri.  If necessary, a local incoming proxy can rewrite it to
>         add the port parameter to the Request-URI based on the From:
>     
>         If a translator is available, it may assert the phone number
>         for the identity in the From: using the <header>
> 
> Gateway to SIP device (incoming call)
>    With mapping
>         use the mapped uri in the Request-URI & To:
>           
>         (optionally) supply called number using <header>
>         This might be needed when multiple called numbers
>         map to the same uri.
>         
>         use sip:"callerId" phone@gateway; port=portnum or
>         a tel: uri in From:
> 
>    Without mapping
>         use a provisioned (per port) URI, a tel uri with the called 
>         number, or a sip uri with calledNumber@localdomain; user=phone
>         in the Request-URI & To:.  Gateways should support all 3,
>         choice should be made by provisioning.
> 
>         use sip:"callerId" phone@gateway; port=portnum or tel
>         uri in From: 
> 
>         proxy will rewrite the Request-URI with the correct sip URI
>         associated with the called number  
>   
> Brian
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Sat Jan 11 11:36:11 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14155
	for <sipping-archive@odin.ietf.org>; Sat, 11 Jan 2003 11:36:11 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0BGmuA30658
	for sipping-archive@odin.ietf.org; Sat, 11 Jan 2003 11:48:56 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BGmuJ30655
	for <sipping-web-archive@optimus.ietf.org>; Sat, 11 Jan 2003 11:48:56 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14145
	for <sipping-web-archive@ietf.org>; Sat, 11 Jan 2003 11:35:40 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BGmIJ30639;
	Sat, 11 Jan 2003 11:48:18 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BGlLJ30599
	for <sipping@optimus.ietf.org>; Sat, 11 Jan 2003 11:47:21 -0500
Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14103
	for <sipping@ietf.org>; Sat, 11 Jan 2003 11:34:05 -0500 (EST)
Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66])
	(user=hgs10 mech=PLAIN bits=0)
	by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0BGbNXZ019753
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Sat, 11 Jan 2003 11:37:24 -0500 (EST)
Message-ID: <3E204849.8000308@cs.columbia.edu>
Date: Sat, 11 Jan 2003 11:37:29 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Daniel G. Petrie" <dpetrie@pingtel.com>
CC: "'sipping@ietf.org'" <sipping@ietf.org>
Subject: Re: [Sipping] Do Phones Have Dial Plans, or do Proxies map?  was
 RE:  [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
References: <313680C9A886D511A06000204840E1CF030B5D01@whq-msgusr-02.pit.comms.marconi.com> <3E1F4E91.C2F22A30@pingtel.com>
In-Reply-To: <3E1F4E91.C2F22A30@pingtel.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Daniel G. Petrie wrote:
> There is actually a third reason to have dial plans on the UA.  The 
> first two have already been brought up:
> 
> 1) To know when the user is done dialing 2) To know how to form a
> canonical URL (tel , sip or sips) 3) To know how to route the INVITE
> to the correct outbound proxy
> 

I wrote up a five-minute skeleton of a proposal at
http://www.cs.columbia.edu/sip/draft/dialplan/dialplan.txt so that we
have something concrete to talk about, in the "provide text" spirit.

Another syntactic rendition would follow the XML example of DML, as in
draft-rosenberg-sipping-markup, as in

<dialstring>
<d>xxxx</>
<t>sip:+1-859-555-\0@example.com</>
</>

DML itself doesn't quite seem to fit, given the need for substitution,
but maybe it can be extended.

> a) Functional routing: where based upon the purpose of the call the 
> user wants the call routed differently.  For example I have a phone 
> at home from which I make personal calls via my favorite service 
> provider and from which I make business calls via my enterprise IP
> PBX.  I want my private/personal calls private and my business does
> not want to pay for my personal calls.   A simple, familiar metaphor
> for this is to use a dialing prefix (e.g. dial 9 and number for
> business call, dial 8 and number for personal calls).  The
> alternatives
> 
> would be to sell home/office users two phones (I wish that would fly)
>  or put a proxy in every home/office (I would not mind selling that 
> many proxies if that would fly as well).

This is roughly equivalent to the 'route' entries that we have for IPv4
routing on Unix and Windows machines.

> 
> b) Load balancing routing:  based upon my dialed string I may want to
> use a different out bound proxy.   Domestic US calls go to one proxy,
> international calls go to another, 911/emergency calls go directly to
> the local emergency gateway.  Can this be done by the proxy?
> Sometimes, if I can get to it, but once you have a dial plan on the
> phone, this is just about free from both an implementation and
> compute cost perspective (e.g. loose routing with a Route header in
> the regexp/transform).
> 
> I am happy to remove functionality from the UA and not support it,
> but I am afraid the dial plan is here to stay in the UA.  I  think 
> our best path forward is with a standard way to specify the dial plan
>  transforms.
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Sat Jan 11 11:38:52 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14205
	for <sipping-archive@odin.ietf.org>; Sat, 11 Jan 2003 11:38:52 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0BGpb330824
	for sipping-archive@odin.ietf.org; Sat, 11 Jan 2003 11:51:37 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BGpbJ30821
	for <sipping-web-archive@optimus.ietf.org>; Sat, 11 Jan 2003 11:51:37 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14197
	for <sipping-web-archive@ietf.org>; Sat, 11 Jan 2003 11:38:21 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BGp6J30800;
	Sat, 11 Jan 2003 11:51:06 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BGoeJ30763
	for <sipping@optimus.ietf.org>; Sat, 11 Jan 2003 11:50:40 -0500
Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14179
	for <sipping@ietf.org>; Sat, 11 Jan 2003 11:37:24 -0500 (EST)
Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66])
	(user=hgs10 mech=PLAIN bits=0)
	by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0BGegSY017581
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Sat, 11 Jan 2003 11:40:43 -0500 (EST)
Message-ID: <3E204910.4090305@cs.columbia.edu>
Date: Sat, 11 Jan 2003 11:40:48 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Daniel G. Petrie" <dpetrie@pingtel.com>
CC: "'sipping@ietf.org'" <sipping@ietf.org>
Subject: Re: [Sipping] Do Phones Have Dial Plans, or do Proxies map?  was
 RE:  [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
References: <313680C9A886D511A06000204840E1CF030B5D01@whq-msgusr-02.pit.comms.marconi.com> <3E1F4E91.C2F22A30@pingtel.com>
In-Reply-To: <3E1F4E91.C2F22A30@pingtel.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

I should note that 'routing' functionality is implicit in the 
translation mechanism I proposed. I would prefer to call it a 
translation functionality, to avoid the notion that it has to be as rich 
as the proxy routing capabilities. I don't want to encode things like

"Between 9 and 5, translate some-LD-number to @sprint.com, otherwise to 
@mci.com."

Least-cost routing should not be part of the dialplan... (Obviously, 
nothing prevents a local admin from updating the dialplan accordingly.)

> a) Functional routing: where based upon the purpose of the call the
> user wants the call routed differently.  For example I have a phone
> at home from which I make personal calls via my favorite service
> provider and from which I make business calls via my enterprise
> IP PBX.  I want my private/personal calls private and my business
> does not want to pay for my personal calls.   A simple, familiar
> metaphor for this is to use a dialing prefix (e.g. dial 9 and number
> for business call, dial 8 and number for personal calls).  The alternatives
> 
> would be to sell home/office users two phones (I wish that would fly)
> or put a proxy in every home/office (I would not mind selling that
> many proxies if that would fly as well).
> 
> b) Load balancing routing:  based upon my dialed string I may
> want to use a different out bound proxy.   Domestic US calls
> go to one proxy, international calls go to another, 911/emergency
> calls go directly to the local emergency gateway.  Can this be
> done by the proxy? Sometimes, if I can get to it, but once you
> have a dial plan on the phone, this is just about free from
> both an implementation and compute cost perspective (e.g.
> loose routing with a Route header in the regexp/transform).
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Sat Jan 11 18:18:30 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20765
	for <sipping-archive@odin.ietf.org>; Sat, 11 Jan 2003 18:18:30 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0BNVOa18420
	for sipping-archive@odin.ietf.org; Sat, 11 Jan 2003 18:31:24 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BNVNJ18417
	for <sipping-web-archive@optimus.ietf.org>; Sat, 11 Jan 2003 18:31:23 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20751
	for <sipping-web-archive@ietf.org>; Sat, 11 Jan 2003 18:17:55 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BNUYJ18389;
	Sat, 11 Jan 2003 18:30:34 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BNSHJ18347
	for <sipping@optimus.ietf.org>; Sat, 11 Jan 2003 18:28:17 -0500
Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20720
	for <sipping@ietf.org>; Sat, 11 Jan 2003 18:14:52 -0500 (EST)
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15])
	by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h0BNHbjS005123;
	Sat, 11 Jan 2003 15:17:37 -0800 (PST)
Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA)
	with SMTP id AAK59354;
	Sat, 11 Jan 2003 15:18:11 -0800 (PST)
From: "Cullen Jennings" <fluffy@cisco.com>
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
Cc: <sipping@ietf.org>
Subject: RE: [Sipping] Do Phones Have Dial Plans, or do Proxies map?  was RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
Date: Sat, 11 Jan 2003 15:22:58 -0800
Message-ID: <DLEHICEBMNEIPCACNLPCKEPICFAA.fluffy@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <313680C9A886D511A06000204840E1CF030B5D01@whq-msgusr-02.pit.comms.marconi.com>
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit



> -----Original Message-----
> From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]On Behalf Of
> Rosen, Brian
> 
> Again, I'm not opposed to making dial string expansion be a requirement
> of the UA, as long as we standardize the form of the expansion, and the
> mechanism by which the UA learns it.
> 

I think this is a path worth exploring. 


 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan 13 03:30:47 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04290
	for <sipping-archive@odin.ietf.org>; Mon, 13 Jan 2003 03:30:47 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0D8iJw04520
	for sipping-archive@odin.ietf.org; Mon, 13 Jan 2003 03:44:19 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0D8iJJ04517
	for <sipping-web-archive@optimus.ietf.org>; Mon, 13 Jan 2003 03:44:19 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04258
	for <sipping-web-archive@ietf.org>; Mon, 13 Jan 2003 03:30:15 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0D8hOJ04451;
	Mon, 13 Jan 2003 03:43:25 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0D8fCJ04369
	for <sipping@optimus.ietf.org>; Mon, 13 Jan 2003 03:41:12 -0500
Received: from mailgate.siemenscomms.co.uk (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04229
	for <sipping@ietf.org>; Mon, 13 Jan 2003 03:27:09 -0500 (EST)
Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk
 (PMDF V6.0-24 #45905) id <0H8N00C018YDZR@siemenscomms.co.uk> for
 sipping@ietf.org; Mon, 13 Jan 2003 08:30:13 +0000 (GMT)
Received: from beex10.siemenscomms.co.uk ([137.223.246.252])
 by siemenscomms.co.uk (PMDF V6.0-24 #45905)
 with ESMTP id <0H8N00BDB8YDYY@siemenscomms.co.uk>; Mon,
 13 Jan 2003 08:30:13 +0000 (GMT)
Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21)
	id <Z5DGZDF3>; Mon, 13 Jan 2003 08:30:26 +0000
Content-return: allowed
Date: Mon, 13 Jan 2003 08:30:31 +0000
From: "Elwell, John" <john.elwell@siemens.com>
To: "'Mary Barnes'" <mbarnes@nortelnetworks.com>,
        "'Mark Watson'" <mwatson@nortelnetworks.com>,
        "'Peterson, Jon'" <jon.peterson@neustar.biz>
Cc: "'sipping@ietf.org'" <sipping@ietf.org>
Message-id: <DE9048A49FFFE547BBC42F855DC8CC3740C06F@beex53.siemenscomms.co.uk>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Content-Transfer-Encoding: 7BIT
Subject: [Sipping] History information privacy requirements
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7BIT
Content-Transfer-Encoding: 7BIT

Mary and others,
 
I don't want to open up the whole discussion we had a few weeks ago, but
having read version 01 of the history requirements document I feel that we
perhaps need to make an addition.
 
Privacy requirements PRIV-req-1 and PRIV-req-2 both apply to information
about the originator of the request (according to the preceding sentence).
Privacy requirements of other users are not mentioned. I think they should
be discussed in the document, even if the conclusion is that no additional
requirements are placed on the solution.
 
1. Privacy requirements of the retargeted-to user.
 
1.1 This user may wish not to have his identity revealed to the originator.
This, of course, can apply to any request, not just requests that have
undergone retargeting. However, it is likely to be of greater relevance to a
request that has been retargeted. A destination user can protect his privacy
using RFC3323. It is important that the provisions of RFC3323 are not
compromised as a result of retargeting.
 
2. Privacy requirements of the retargeting user.
 
2.1 This user may be unwilling to disclose to the originator the fact that
retargeting has occurred
 
2.2 This user may be willing to disclose to the originator the fact that
retargeting has occurred but unwilling to disclose to the originator the
identity of the retargeted-to user.
 
2.3 This user may be unwilling to disclose to the retargeted-to user the
fact that retargeting has occurred
 
2.4 This user may be willing to disclose to the retargeted-to user the fact
that retargeting has occurred but unwilling to disclose to the retargeted-to
user the identity of the previous target.
 
NOTE. 2.3 and 2.4 are less convincing requirements, although I believe these
requirements are supported in public ISDN.
 
2.5 The retargeting user can also be a retargeted-to user of a previous
retarget. As such requirement 1.1 above can apply, i.e., the retargeting
user (retargeted-to user of previous retarget) is unwilling to disclose his
identity to the originating user.
 
2.6 The retargeting user has some of the characteristics of an originator if
the request is retargeted again further downstream. As such PRIV-req-1 and
PRIV-req-2 can apply to a retargeting user.
 
Regards,
 
John
 
John Elwell
e-mail: mailto:john.elwell@siemens.com <mailto:john.elwell@siemens.com>  

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan 13 03:30:47 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04300
	for <sipping-archive@odin.ietf.org>; Mon, 13 Jan 2003 03:30:47 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0D8iK004536
	for sipping-archive@odin.ietf.org; Mon, 13 Jan 2003 03:44:20 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0D8iJJ04533
	for <sipping-web-archive@optimus.ietf.org>; Mon, 13 Jan 2003 03:44:20 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04261
	for <sipping-web-archive@ietf.org>; Mon, 13 Jan 2003 03:30:16 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0D8hZJ04475;
	Mon, 13 Jan 2003 03:43:35 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0D8fhJ04381
	for <sipping@optimus.ietf.org>; Mon, 13 Jan 2003 03:41:43 -0500
Received: from mailgate.siemenscomms.co.uk (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04238
	for <sipping@ietf.org>; Mon, 13 Jan 2003 03:27:39 -0500 (EST)
Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk
 (PMDF V6.0-24 #45905) id <0H8N00D018Z805@siemenscomms.co.uk> for
 sipping@ietf.org; Mon, 13 Jan 2003 08:30:44 +0000 (GMT)
Received: from beex10.siemenscomms.co.uk ([137.223.246.252])
 by siemenscomms.co.uk (PMDF V6.0-24 #45905)
 with ESMTP id <0H8N00BM38Z8M7@siemenscomms.co.uk>; Mon,
 13 Jan 2003 08:30:44 +0000 (GMT)
Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21)
	id <Z5DGZDFX>; Mon, 13 Jan 2003 08:30:57 +0000
Content-return: allowed
Date: Mon, 13 Jan 2003 08:31:05 +0000
From: "Elwell, John" <john.elwell@siemens.com>
To: "'Mary Barnes'" <mbarnes@nortelnetworks.com>,
        "'Mark Watson'" <mwatson@nortelnetworks.com>
Cc: "'sipping@ietf.org'" <sipping@ietf.org>
Message-id: <DE9048A49FFFE547BBC42F855DC8CC3740C070@beex53.siemenscomms.co.uk>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Content-Transfer-Encoding: 7BIT
Subject: [Sipping] History information in provisional responses
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7BIT
Content-Transfer-Encoding: 7BIT

Mary and others,

In the solution draft, nothing is said about inclusion of history
information in provisional responses. I am thinking in particular of 180.
This might be of benefit to a human originator in particular.

Although in many cases a proxy will retarget a request fairly quickly (e.g.,
if the target user has moved or is busy), it may be programmed to retarget
only after alerting the target user for a certain time. If successful the
retarget will result in a 180 response from the retargeted-to user and
hopefully eventually a 200 response. This means the UAC could receive two
(or more) 180 responses. If the second and subsequent 180 responses were to
contain history information, this would give the originator an explanation
of what is happening and may persuade the originator to allow the request to
continue longer in order to give the retargeted-to user time to answer.

Another possible advantage is that on seeing history information in a 180
the originator might decide not to establish a session with the
retargeted-to user and might cancel the request immediately without waiting
for answer.

What are your thoughts on history information in provisional responses?
Obviously it would need to be done in a way that does not compromise privacy
requirements.

Regards,

John


John Elwell
e-mail: mailto:john.elwell@siemens.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan 13 13:48:45 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19647
	for <sipping-archive@odin.ietf.org>; Mon, 13 Jan 2003 13:48:45 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0DJ2VV13870
	for sipping-archive@odin.ietf.org; Mon, 13 Jan 2003 14:02:31 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DJ2VJ13867
	for <sipping-web-archive@optimus.ietf.org>; Mon, 13 Jan 2003 14:02:31 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19642
	for <sipping-web-archive@ietf.org>; Mon, 13 Jan 2003 13:48:14 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DJ1hJ13842;
	Mon, 13 Jan 2003 14:01:43 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DJ02J13775
	for <sipping@optimus.ietf.org>; Mon, 13 Jan 2003 14:00:02 -0500
Received: from mail.pingtel.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19597
	for <sipping@ietf.org>; Mon, 13 Jan 2003 13:45:43 -0500 (EST)
Received: from pingtel.com (cdhcp144.pingtel.com [10.1.1.144])
	by mail.pingtel.com (8.11.6/8.11.6) with ESMTP id h0DImvR21890;
	Mon, 13 Jan 2003 13:48:58 -0500
Message-ID: <3E2309E6.D2F68E1E@pingtel.com>
Date: Mon, 13 Jan 2003 13:48:07 -0500
From: "Daniel G. Petrie" <dpetrie@pingtel.com>
Organization: Pingtel Corp.  http://www.pingtel.com
X-Mailer: Mozilla 4.73 [en]C-{C-UDP; EBM-SONY1}  (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Henning Schulzrinne <hgs@cs.columbia.edu>
CC: "'sipping@ietf.org'" <sipping@ietf.org>
Subject: Re: [Sipping] Do Phones Have Dial Plans, or do Proxies map?  wasRE:  
 [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
References: <313680C9A886D511A06000204840E1CF030B5D01@whq-msgusr-02.pit.comms.marconi.com> <3E1F4E91.C2F22A30@pingtel.com> <3E204849.8000308@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

I have a preference for the XML container for the digit maps,
though either works for me. In either case I agree we should
use the RFC 3015 style digit map representation as opposed
to inventing another one.

I would generalize the rfc 3015 syntax to handle non-DTMF
characters as follows:
"x" represents any single character (not just digits)
"." represents any number of  characters (not just digits)

It also requires some sort of escaping mechanizm to be
able to explicitly include "x", ".", "T", etc.  in the digit map
(e.g. \x,  \., \T, etc.).

Is the grouping by curly backet {} neccessary?  There is
implicitly a fixed and variable part of the dial plan.  Why not
just have a verbs that represents the entire or variable part
of the dial plan?  Any part of the fix part of the dial plan
can easily be put back in the URL transform (e.g.
91xxxxxxxxxx tel:+\11 as opposed to 9{1xxxxxxxxxx} tel:+\1)

Also just to be explicit I am assuming that the range (e.g. [1-6])
and or (e.g.  911|9911) constructs of the RFC 3015 are intended to
be included, though not shown in your examples.  I feel they
at least SHOULD supported.

Is there any reason to exclude other URL types in the transfrom
that might result in non-SIP requests like HTTP?  I am not sure
this would make sense on all UAs, but it might on some.

Henning Schulzrinne wrote:

> Daniel G. Petrie wrote:
> > There is actually a third reason to have dial plans on the UA.  The
> > first two have already been brought up:
> >
> > 1) To know when the user is done dialing 2) To know how to form a
> > canonical URL (tel , sip or sips) 3) To know how to route the INVITE
> > to the correct outbound proxy
> >
>
> I wrote up a five-minute skeleton of a proposal at
> http://www.cs.columbia.edu/sip/draft/dialplan/dialplan.txt so that we
> have something concrete to talk about, in the "provide text" spirit.
>
> Another syntactic rendition would follow the XML example of DML, as in
> draft-rosenberg-sipping-markup, as in
>
> <dialstring>
> <d>xxxx</>
> <t>sip:+1-859-555-\0@example.com</>
> </>
>
> DML itself doesn't quite seem to fit, given the need for substitution,
> but maybe it can be extended.
>
> > a) Functional routing: where based upon the purpose of the call the
> > user wants the call routed differently.  For example I have a phone
> > at home from which I make personal calls via my favorite service
> > provider and from which I make business calls via my enterprise IP
> > PBX.  I want my private/personal calls private and my business does
> > not want to pay for my personal calls.   A simple, familiar metaphor
> > for this is to use a dialing prefix (e.g. dial 9 and number for
> > business call, dial 8 and number for personal calls).  The
> > alternatives
> >
> > would be to sell home/office users two phones (I wish that would fly)
> >  or put a proxy in every home/office (I would not mind selling that
> > many proxies if that would fly as well).
>
> This is roughly equivalent to the 'route' entries that we have for IPv4
> routing on Unix and Windows machines.
>
> >
> > b) Load balancing routing:  based upon my dialed string I may want to
> > use a different out bound proxy.   Domestic US calls go to one proxy,
> > international calls go to another, 911/emergency calls go directly to
> > the local emergency gateway.  Can this be done by the proxy?
> > Sometimes, if I can get to it, but once you have a dial plan on the
> > phone, this is just about free from both an implementation and
> > compute cost perspective (e.g. loose routing with a Route header in
> > the regexp/transform).
> >
> > I am happy to remove functionality from the UA and not support it,
> > but I am afraid the dial plan is here to stay in the UA.  I  think
> > our best path forward is with a standard way to specify the dial plan
> >  transforms.
> >
>
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Tue Jan 14 02:59:46 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18139
	for <sipping-archive@odin.ietf.org>; Tue, 14 Jan 2003 02:59:46 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0E8DnV08592
	for sipping-archive@odin.ietf.org; Tue, 14 Jan 2003 03:13:49 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E8DmJ08589
	for <sipping-web-archive@optimus.ietf.org>; Tue, 14 Jan 2003 03:13:48 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18130
	for <sipping-web-archive@ietf.org>; Tue, 14 Jan 2003 02:59:14 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E8D1J08547;
	Tue, 14 Jan 2003 03:13:01 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E8BHJ08483
	for <sipping@optimus.ietf.org>; Tue, 14 Jan 2003 03:11:17 -0500
Received: from alpha.jnpr.net (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18052
	for <sipping@ietf.org>; Tue, 14 Jan 2003 02:56:43 -0500 (EST)
Received: from muon.jnpr.net ([172.24.15.24]) by alpha.jnpr.net with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 14 Jan 2003 00:00:04 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Subject: RE: [Sipping] expert review for draft-dcsgroup-sipping-proxy-proxy
Date: Tue, 14 Jan 2003 00:00:04 -0800
Message-ID: <582ED0AECAB6E64B85FB508C956D597D048A2C@muon.jnpr.net>
Thread-Topic: [Sipping] expert review for draft-dcsgroup-sipping-proxy-proxy
Thread-Index: AcK7ovIdqfoJ6oWiTwOgP8gJyPPSgQ==
From: "Burcak Beser" <burcak@juniper.net>
To: <sipping@ietf.org>
Cc: "Burcak Beser" <burcak@juniper.net>
X-OriginalArrivalTime: 14 Jan 2003 08:00:04.0528 (UTC) FILETIME=[F2602B00:01C2BBA2]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0E8BHJ08484
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

Some issues/points:

1. The section '6 P-DCS-GATE' refers to PacketCable Dynamic Quality of
Service which no longer specifies the Gate Coordination. The term DCS
QoS mechanism should be used instead.

2. I know that because of the above issue the editor of the draft
decided to use old versions of the specifications DQoS
(PKT-SP-DQOS-I05-021127, the latest version is
http://www.packetcable.com/downloads/specs/PKT-SP-SEC-I07-021127.pdf)
and Security (pkt-sp-sec-i05-020116, the latest version is
http://www.packetcable.com/downloads/specs/pkt-sp-cmss-i02-021205.pdf).
Since it is very hard, if not impossible to find older versions of
CableLabs specifications; I do belive that referring an old version of
specification would cause problems due to the fact that people will use
the latest version that does not use the mechanism described. My
suggestion is to remove the references to PacketCable.

3. Another alternative is to remove the section 6 completely which would
result with dependency to DCS being removed as well. Since the remaining
headers are used in the currently used in PacketCable specifications,
the headers are not specific to DCS only. It is my expectation that this
will cause the intrellectual property notice to be dropped as well.

If necessary, I am planning to write an NCS architecture document which
would point the PacketCable architecture that is currently being used,
not as discussed long years ago for PacketCable.

4. I agree with Miguel about dropping the DCS portion from the headers.
Even PacketCable will use these headers in a non-DCS enviroment.

5. In section 8, the definition of Financial Entity ID (FEID) should be
as Financial-Entity-ID for consistency with other definitions.

6. The FEID is defined as 8 byte structure in text, where as the
specification referenced defines it as 'variable length ASII character
string, where first 8 bytes constitute MSO defined data, the rest
contains MSO's domain name.

7. The reference to pkt-sp-em-i03-011221, should be updated due to above
specified reasons. The correct reference is PKT-SP-EM-I05-021127.

8. I could not locate the definitions of Acct-Charge-URI,
Acct-Calling-URI, Acct-Called-URI, Acct-Routing-URI, and
Acct-Location-Routing-URI in the EM spec. 

9. Why not use the same approach as RKS-Group-ID not refer to EM spec,
for all these details. The parameters should be defined as more
generalized  which would make the definitions valid even if the specs
change in the future. (By the way any reasons to keep RKS-Group-ID?)

10. Both P-DCS-LAES and P-DCS-Laes are being used in section 9. I
suggest the use of P-DCS-LAES for consistency.

11. In section '10 Security Considerations' normative MUST is being used
where I believe that should be non-normative must.

12. The acknowledgements section is divided into two and gives the
impression that the DCS team and authors are a disjoint set, which is
not the case. I would like to see that the real authors of the draft (at
least Mike Mannette who wrote most of the initial text) should be
properly acknowledged.

13. Is there a reason for two editors instead of one, as suggested in
rfc-editor policies (http://www.rfc-editor.org/policy.html).

Burcak Beser

-----Original Message-----
From: Rohan Mahy [mailto:rohan@cisco.com]
Sent: Wednesday, December 11, 2002 2:06 PM
To: 'sipping@ietf.org'
Subject: [Sipping] expert review for draft-dcsgroup-sipping-proxy-proxy


Hi,

I'd like the SIPPING working group to provide expert review of:

http://www.ietf.org/internet-drafts/draft-dcsgroup-sipping-proxy-proxy- 
01.txt

The authors have requested individual publication of the P-Headers  
defined therein.  Expert Review will close on January 14, 2003

thanks,
-rohan

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Tue Jan 14 15:08:35 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09981
	for <sipping-archive@odin.ietf.org>; Tue, 14 Jan 2003 15:08:35 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0EKMqn28521
	for sipping-archive@odin.ietf.org; Tue, 14 Jan 2003 15:22:52 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EKMqJ28518
	for <sipping-web-archive@optimus.ietf.org>; Tue, 14 Jan 2003 15:22:52 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09969
	for <sipping-web-archive@ietf.org>; Tue, 14 Jan 2003 15:08:03 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EKLYJ28415;
	Tue, 14 Jan 2003 15:21:34 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EKKrJ28383
	for <sipping@optimus.ietf.org>; Tue, 14 Jan 2003 15:20:53 -0500
Received: from fox.iptel.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09892
	for <sipping@ietf.org>; Tue, 14 Jan 2003 15:06:04 -0500 (EST)
Received: from jku07.fokus.fraunhofer.de (nas-cbv-6-62-147-149-122.dial.proxad.net [62.147.149.122])
	by fox.iptel.org (8.11.6/8.11.6) with ESMTP id h0EK9K316630
	for <sipping@ietf.org>; Tue, 14 Jan 2003 21:09:20 +0100
Message-Id: <5.2.0.9.0.20030114183502.00b6bb38@mailhost.fokus.gmd.de>
X-Sender: jku@mailhost.fokus.gmd.de (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 14 Jan 2003 18:44:19 +0100
To: sipping@ietf.org
From: Jiri Kuthan <jiri.kuthan@fokus.fraunhofer.de>
Subject: RE: [Sipping] URIs for Gateways
In-Reply-To: <15903.16273.453205.50103@harjus.eng.song.fi>
References: <313680C9A886D511A06000204840E1CF030B5D00@whq-msgusr-02.pit.comms.marconi.com>
 <313680C9A886D511A06000204840E1CF030B5D00@whq-msgusr-02.pit.comms.marconi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

This discussion became somehow multithreaded, so let me please make
sure I'm catching up.

One problem I see is ability of a PSTN gateway to propagate a calling
number owned by a SIP caller down to PSTN. From: may or may not have
the number in userpart (for example because a caller prefers to
have "john" there). Perhaps some will agree that a gateway may not
be necessarily the best place for mapping of From/username->PSTN number.
Doing so in a proxy (a device which typically faetures lot of programmability)
seems reasonable to me. Then the missing piece is how to propagate
the PSTN number to the gateway. Using NAI as suggested here seems
a very good hit to me.

As for propagating the called number to PSTN -- I think that's about
r-uri -- that is the resource which hit the gateway and which identifies
the desired destination.

Is there any additional functionality/problems folks would like to have?
Is there any reason why NAI/r-uri should not be good enough for using 
in gateway's calling/caller-id PSTN signaling?

Thanks,

-Jiri

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Tue Jan 14 17:38:23 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14372
	for <sipping-archive@odin.ietf.org>; Tue, 14 Jan 2003 17:38:23 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0EMqgr08833
	for sipping-archive@odin.ietf.org; Tue, 14 Jan 2003 17:52:42 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EMqfJ08830
	for <sipping-web-archive@optimus.ietf.org>; Tue, 14 Jan 2003 17:52:41 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14331
	for <sipping-web-archive@ietf.org>; Tue, 14 Jan 2003 17:37:51 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EMpsJ08756;
	Tue, 14 Jan 2003 17:51:54 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EMoxJ08663
	for <sipping@optimus.ietf.org>; Tue, 14 Jan 2003 17:50:59 -0500
Received: from auemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14254
	for <sipping@ietf.org>; Tue, 14 Jan 2003 17:36:08 -0500 (EST)
Received: from oh0012exch001p.wins.lucent.com (h135-7-157-6.lucent.com [135.7.157.6])
	by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0EMdRK28359
	for <sipping@ietf.org>; Tue, 14 Jan 2003 17:39:27 -0500 (EST)
Received: by OH0012EXCH001P with Internet Mail Service (5.5.2653.19)
	id <Y5VBQBZZ>; Tue, 14 Jan 2003 17:39:26 -0500
Message-ID: <4C37CF2D8DF07E4CA6357BAD5EB9A5D703F5AB54@oh0012itsa1.cb.lucent.com>
From: "Deb, Sunandita (Sunandita)" <sudeb@lucent.com>
To: "'sipping@ietf.org'" <sipping@ietf.org>
Date: Tue, 14 Jan 2003 17:39:24 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sipping] difference between SIP and SIP-T
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>


Hi,

Can you please let me know the basic difference between SIP and SIP-T? Is
there any document describing the differences? My understanding is that SIP
works in the pure IP world but SIP-T will be able to interwork between TDM
and IP world and the SIP-T messages will have additional fields to include
the specific telephony parameters like calling party number, called party
number, originating line number etc.

Thanks,
Sunandita
(614) 860-6471 (w)
sudeb@lucent.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Tue Jan 14 19:02:57 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16605
	for <sipping-archive@odin.ietf.org>; Tue, 14 Jan 2003 19:02:57 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0F0HIn14473
	for sipping-archive@odin.ietf.org; Tue, 14 Jan 2003 19:17:18 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F0HIJ14470
	for <sipping-web-archive@optimus.ietf.org>; Tue, 14 Jan 2003 19:17:18 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16598
	for <sipping-web-archive@ietf.org>; Tue, 14 Jan 2003 19:02:26 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F0GKJ14437;
	Tue, 14 Jan 2003 19:16:20 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F0FsJ14399
	for <sipping@optimus.ietf.org>; Tue, 14 Jan 2003 19:15:54 -0500
Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16587
	for <sipping@ietf.org>; Tue, 14 Jan 2003 19:01:02 -0500 (EST)
Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id h0F04FTI011023;
	Tue, 14 Jan 2003 18:04:17 -0600
From: "Dean Willis" <dean.willis@softarmor.com>
To: "'Peterson, Jon'" <jon.peterson@neustar.biz>,
        "'Rosen, Brian'" <Brian.Rosen@marconi.com>,
        "'Drage, Keith \(Keith\)'" <drage@lucent.com>,
        "'Henning Schulzrinne'" <hgs@cs.columbia.edu>
Cc: <sipping@ietf.org>
Subject: RE: [Sipping] URIs for Gateways
Date: Tue, 14 Jan 2003 18:04:03 -0600
Message-ID: <005201c2bc29$9d797920$fe0c0c42@txdwillis>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <15A2739B7DAA624D8091C65981D7DA815EB4E6@stntexch2.va.neustar.com>
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


Jon said:
> Technologies like ENUM (when/where available) could enable 
> gateways to convert originating telephone numbers into URIs. 
> Of course, a gateway wouldn't be able to assert that identity 
> to an intermediary unless it possessed credentials 
> appropriate to that URI, which is unlikely.

I think the magic subtlety here is that the gateway would be asserting the
PSTN number with its OWN credentials, meaning "I, Gateway, believe that I
got this call from +1234567890, which I appear to be able to enum map to
1234567890@example.com". I think this should prove quite useful.

--
Dean

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Tue Jan 14 19:03:04 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16619
	for <sipping-archive@odin.ietf.org>; Tue, 14 Jan 2003 19:03:04 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0F0HPk14489
	for sipping-archive@odin.ietf.org; Tue, 14 Jan 2003 19:17:25 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F0HPJ14486
	for <sipping-web-archive@optimus.ietf.org>; Tue, 14 Jan 2003 19:17:25 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16602
	for <sipping-web-archive@ietf.org>; Tue, 14 Jan 2003 19:02:32 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F0GFJ14417;
	Tue, 14 Jan 2003 19:16:15 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F0FlJ14395
	for <sipping@optimus.ietf.org>; Tue, 14 Jan 2003 19:15:47 -0500
Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16575
	for <sipping@ietf.org>; Tue, 14 Jan 2003 19:00:55 -0500 (EST)
Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id h0F04FTF011023;
	Tue, 14 Jan 2003 18:04:15 -0600
From: "Dean Willis" <dean.willis@softarmor.com>
To: "'Deb, Sunandita \(Sunandita\)'" <sudeb@lucent.com>, <sipping@ietf.org>
Subject: RE: [Sipping] difference between SIP and SIP-T
Date: Tue, 14 Jan 2003 18:04:02 -0600
Message-ID: <004f01c2bc29$9ce21b20$fe0c0c42@txdwillis>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <4C37CF2D8DF07E4CA6357BAD5EB9A5D703F5AB54@oh0012itsa1.cb.lucent.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0F0FlJ14396
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit



Sunandita asked:
> Can you please let me know the basic difference between SIP 
> and SIP-T? Is there any document describing the differences? 
> My understanding is that SIP works in the pure IP world but 
> SIP-T will be able to interwork between TDM and IP world and 
> the SIP-T messages will have additional fields to include the 
> specific telephony parameters like calling party number, 
> called party number, originating line number etc.


In short, SIP-T is "HOW to do telephony interworking with SIP", and is NOT a
separate protocol. The SIP-T work did not require any changes or extensions
to the SIP protocol.

Since I like analogies, imagine that useful tool "the standard slotted
screwdriver". One may use it to drive screws. One may also use it to open
paint cans. One may use it as a scraper, or a wood chisel, or a box-cutter,
a hook-remover, a hasp-pin, a back scratcher, or any number of other things.


SIP is, like a screwdriver, a versatile tool. SIP-T is instructions on how
to use that tool for a particular task: interworking SS7 systems.

--
Dean


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Wed Jan 15 03:22:25 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19717
	for <sipping-archive@odin.ietf.org>; Wed, 15 Jan 2003 03:22:25 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0F8avi21713
	for sipping-archive@odin.ietf.org; Wed, 15 Jan 2003 03:36:57 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F8auJ21710
	for <sipping-web-archive@optimus.ietf.org>; Wed, 15 Jan 2003 03:36:56 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19683
	for <sipping-web-archive@ietf.org>; Wed, 15 Jan 2003 03:21:53 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F8YTJ21570;
	Wed, 15 Jan 2003 03:34:29 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F8XiJ21544
	for <sipping@optimus.ietf.org>; Wed, 15 Jan 2003 03:33:44 -0500
Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19598
	for <sipping@ietf.org>; Wed, 15 Jan 2003 03:18:40 -0500 (EST)
Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0F8LxAv013277;
	Wed, 15 Jan 2003 09:21:59 +0100 (MET)
Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55)
	id ZQ1GXDZA; Wed, 15 Jan 2003 09:21:59 +0100
Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.92])
	by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h0F8Lxu4004279;
	Wed, 15 Jan 2003 10:21:59 +0200 (EET)
Message-ID: <3E251A25.5F613C38@lmf.ericsson.se>
Date: Wed, 15 Jan 2003 10:21:57 +0200
X-Sybari-Trust: 6f39a15d 1864f774 206fc897 00000138
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: sipping <sipping@ietf.org>, Alan Johnston <alan.johnston@wcom.com>,
        Robert Sparks <rsparks@dynamicsoft.com>
CC: Miguel Angel <Miguel.A.Garcia@lmf.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sipping] From tag in CANCEL
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Alan,

in the service example draft,

http://www.ietf.org/internet-drafts/draft-ietf-sipping-service-examples-03.txt

Some CANCELs have a tag in the From header field and some don't. For
example, the CANCEL (F6) in page 73 does not have a tag, but the CANCEL
(F9) in page 135 has it.

Quoting from RFC 3261 (section 9.1):
" The
   Request-URI, Call-ID, To, the numeric part of CSeq, and From header
   fields in the CANCEL request MUST be identical to those in the
   request being cancelled, including tags."

Therefore, even if a CANCEL is generated by a proxy, it will have to
have the From tag.

The behavior regarding From tags for ACKs for non-2xx final responses
generated by proxies is the same (Section 17.1.1.3).

Regards,

Gonzalo
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Wed Jan 15 08:02:42 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24721
	for <sipping-archive@odin.ietf.org>; Wed, 15 Jan 2003 08:02:41 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0FDHJs08334
	for sipping-archive@odin.ietf.org; Wed, 15 Jan 2003 08:17:19 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FDHJJ08331
	for <sipping-web-archive@optimus.ietf.org>; Wed, 15 Jan 2003 08:17:19 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24711
	for <sipping-web-archive@ietf.org>; Wed, 15 Jan 2003 08:02:10 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FDFQJ08141;
	Wed, 15 Jan 2003 08:15:26 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FDDDJ08011
	for <sipping@optimus.ietf.org>; Wed, 15 Jan 2003 08:13:13 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24301;
	Wed, 15 Jan 2003 07:58:04 -0500 (EST)
Message-Id: <200301151258.HAA24301@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: sip@ietf.org, sipping@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 15 Jan 2003 07:58:03 -0500
Subject: [Sipping] I-D ACTION:draft-willis-sip-infopackage-00.txt
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Packaging and Negotiation of INFO Methods for the 
                          Session Initiation Protocol (SIP)
	Author(s)	: D. Willis
	Filename	: draft-willis-sip-infopackage-00.txt
	Pages		: 11
	Date		: 2003-1-14
	
The SIP INFO method (RFC 2976) establishes a method by which
applications may transfer application-specific information within a
SIP dialog.  However, RFC 2976 does not provide a mechanism for
describing and documenting an application of INFO, nor does it
provide a mechanism by which applications may negotiate such uses.
This document provides a framework for documenting and naming
specific uses of INFO (called INFO packages), for registering those
package names with IANA, and for negotiating the support for various
INFO packages between applications using SIP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-willis-sip-infopackage-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-willis-sip-infopackage-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-willis-sip-infopackage-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-1-14150945.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-willis-sip-infopackage-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-willis-sip-infopackage-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-1-14150945.I-D@ietf.org>

--OtherAccess--

--NextPart--


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Wed Jan 15 15:27:16 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09178
	for <sipping-archive@odin.ietf.org>; Wed, 15 Jan 2003 15:27:16 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0FKg3807764
	for sipping-archive@odin.ietf.org; Wed, 15 Jan 2003 15:42:03 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FKg3J07761
	for <sipping-web-archive@optimus.ietf.org>; Wed, 15 Jan 2003 15:42:03 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09173
	for <sipping-web-archive@ietf.org>; Wed, 15 Jan 2003 15:26:44 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FKelJ07695;
	Wed, 15 Jan 2003 15:40:47 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FKd4J07610
	for <sipping@optimus.ietf.org>; Wed, 15 Jan 2003 15:39:04 -0500
Received: from mail-blue.research.att.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09099
	for <sipping@ietf.org>; Wed, 15 Jan 2003 15:23:46 -0500 (EST)
Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26])
	by mail-blue.research.att.com (Postfix) with ESMTP id 5C4E74CEE4
	for <sipping@ietf.org>; Wed, 15 Jan 2003 15:27:06 -0500 (EST)
Received: from fish.research.att.com (fish.research.att.com [135.207.27.137])
	by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id PAA02339;
	Wed, 15 Jan 2003 15:27:03 -0500 (EST)
From: William Marshall <wtm@research.att.com>
Received: (from wtm@localhost)
	by fish.research.att.com (SGI-8.9.3/8.8.5) id PAA54736;
	Wed, 15 Jan 2003 15:27:03 -0500 (EST)
Date: Wed, 15 Jan 2003 15:27:03 -0500 (EST)
Message-Id: <200301152027.PAA54736@fish.research.att.com>
To: sipping@ietf.org
Subject: [Sipping] resolution of comments received during expert review of draft-dcsgroup-sipping-proxy-proxy-01
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

Based on feedback during the "expert review period" for the indicated
draft, the following changes have been incorporated in the recently
submitted version.  Until it appears in the archives, it may be found at 
 ftp://ftp.research.att.com/dist/wtm/draft-dcsgroup-sipping-proxy-proxy-02.txt
and a MSWord version with changebars from the previous submission is
 ftp://ftp.research.att.com/dist/wtm/draft-dcsgroup-sipping-proxy-proxy-02.doc

Specific comments received, and the resolution of them, follows.

Miguel Garcia wrote:
> 1) I would recommend you to not use "addr-spec" in the syntax of any 
> header, and instead, use "name-addr". "name-addr" contains an "addr-spec" 
> within quotes, and optionally, a display name. It is therefore, richer 
> and easier to parse. Besides, there are a few SIP headers (Route, 
> Record-Route) that only allow "name-addr". One of the few changes we 
> did in the last version of the 3GPP P-headers draft was to fix all the 
> relevant headers to include "name-addr" instead of "addr-spec".
> 
> So, for instance, the P-DCS-Trace-Party-ID syntax would become:
> 
>          P-DCS-Trace-Party-ID = "P-DCS-Trace-Party-ID" HCOLON name-addr

done.

Miguel Garcia wrote:
> 2) I miss in the document a table of new headers. Basically an 
> extension of Table 2 in RFC 3261. We have a similar one in section 
> 5.7 of the 3GPP P- headers.

added, although I believe all the information in that table appears
in the text already.

Miguel Garcia wrote:
> 3) With respect the name that you have chosen for the headers, I don't 
> understand why all of them are prepended by a "DCS" substring. I understand 
> that the headers were originally designed for the DCS architecture, but 
> once you publish the internet draft as an informational RFC, other 
> organizations (e.g., 3GPP) could "import" one or more headers in its 
> work. The fact that all the headers begin with "P-DCS-" will probably 
> give problems to some folks to use those headers outside their original 
> context. As an example, none of the 3GPP P- headers are named "P-3GPP-" 
> (I remember I fought this hard with some 3GPP folks). My recommendation 
> is to remove the "DCS" substring from the name of all these headers.
Burcak Beser wrote:
> 4. I agree with Miguel about dropping the DCS portion from the headers.
> Even PacketCable will use these headers in a non-DCS enviroment.

There is an issue of backward compatibility here, and changing the header
names at the last minute, after years and years, seems extremely bad.

But even more important is that removing "-DCS" from the names will leave
such names as P-Billing-Info, P-Gate, P-LAES, etc.  It would be very
presumptuous of us to assume that all Billing information can be stored
in the format we chose for P-Billing-Info, or that all other groups that
needed to pass such information would choose a non-conflicting name for
their header.  While we can claim to be first, and take all that is
available from IANA right now, that just doesn't seem fair to all.

PacketCable is using them in a non-DCS environment, and the current
released PacketCable spec (which was reviewed by all PacketCable vendors
and approved) mandates them.  With the "P-DCS-" prefix.

Miguel Garcia wrote:
> 4) Section 6.6. (Procedures at the proxy for P-DCS-Gate): "The 
> P-DCS-Gate header MUST NOT appear in any message other than the 
> initial INVITE request, or in the first reliable non-100 response 
> to that request". I have a question here: do you really mean in any 
> non-100 response to the request?? That will include, for instance, 
> 3xx and upper responses?? Perhaps do you mean "... any realiable 1xx 
> (except 100) or 2xx response ".

Good point.  This affects lots of other sections as well.  Changed throughout.

Miguel Garcia wrote:
> 5) Section 7.4 (about the P-DCS-OSPS header): " ... it MUST reject the 
> request with a 409-Conflict error code.". Well, first I guess you refer 
> to the 409 response rather than error code. But what is more important: 
> the 409 response is not longer defined in RFC 3261, so you should change 
> it to any other suitable response.

Changed to a 403 response.

Miguel Garcia wrote:
> 6) Section 7.6 (P-DCS-OSPS header): "If a proxy receives a P-DCS-OSPS 
> header in a request from an untrusted source, it MUST reject the request". 
> I find hard to understand why will you reject a request from an 
> untrusted source when it contains a header that you don't accept. I 
> consider it an easy denial of service attack to a proxy. I would think 
> that is logical to ignore and remove the header, and process the 
> request, if such request came from an untrusted source (similar 
> behaviour as for the P-Asserted-Identity). But if you have a very 
> good reason to reject requests in this case, I would say that you 
> should specify which response are you going to send back.

Having the option to remove the header seems like a reasonable addition.

Miguel Garcia wrote:
> 7) Section 8.1 (Syntax for P-DCS-Billing-Info): According to the 
> comment I gave in my point 1 above, the syntax of Acct-Charge-URI, 
> Acct-Calling-URI- Acct-Called-URI, Acct-Routing-URI and 
> Acct-Loc-Routing-URI should be "name-addr" for all of them. The 
> word "URI" is not defined in this document nor in RFC 3261. The 
> same applies for the Called-ID and Redirector in the 
> P-DCS-Redirect in section 9.1.

OK.  Note that in current use, they will all reduce to tel: URLs,
in order to be consistent with the PacketCable Event Messaging 
specification.  But it is nice to generalize the syntax for the future.

Miguel Garcia wrote:
> 8) Section 8.6.1. In this section, you mention several times the 
> "18x-Ringing" response. I am not sure what kind of response is that. 
> Do you mean a 180 Ringing only or any 1xx response (including 181, 
> 182, 183)?

What is meant is any 18x response, typically 180 or 183.  Changed
to "18x response".

Burcak Beser wrote:
> 1. The section '6 P-DCS-GATE' refers to PacketCable Dynamic Quality of
> Service which no longer specifies the Gate Coordination. The term DCS
> QoS mechanism should be used instead.
<points 2 and 3 are related to the same issue>

A note is added stating the manner in which the PacketCable Dynamic
Quality of Service specification currently uses Gate Coordination
(see Section 5.1.5 of PKT-SP-DQOS-I05-021127).

Burcak Beser wrote:
> 2. I know that because of the above issue the editor of the draft
> decided to use old versions of the specifications DQoS
> (PKT-SP-DQOS-I05-021127, the latest version is
> http://www.packetcable.com/downloads/specs/PKT-SP-SEC-I07-021127.pdf)
> and Security (pkt-sp-sec-i05-020116, the latest version is
> http://www.packetcable.com/downloads/specs/pkt-sp-cmss-i02-021205.pdf).
and
> 7. The reference to pkt-sp-em-i03-011221, should be updated due to above
> specified reasons. The correct reference is PKT-SP-EM-I05-021127.

The "above issue" (your item #1) had nothing to do with it.  The PacketCable
specs have been updated several times and the references are outdated.
All references in the draft have now been updated to the current versions 
of the PacketCable specs. However, we need to recognize that this problem 
will reappear.

Burcak Beser wrote:
> 5. In section 8, the definition of Financial Entity ID (FEID) should be
> as Financial-Entity-ID for consistency with other definitions.

done

Burcak Beser wrote:
> 6. The FEID is defined as 8 byte structure in text, where as the
> specification referenced defines it as 'variable length ASII character
> string, where first 8 bytes constitute MSO defined data, the rest
> contains MSO's domain name.

The Event Message spec (PKT-SP-EM-I05-021127) does state that the field
is an ASCII string, but further states that the first 8 bytes, which are
MSO-defined data, are zero filled.  The "zero fill" may be either 
binary or ascii.  The domain name (up to 239 bytes) is certainly
ASCII, and is passed as such.  The only way to guarantee passing the
MSO-defined data transparently is to separate out the first 8 bytes
from the last 239 bytes and treat them separately.

Burcak Beser wrote:
> 8. I could not locate the definitions of Acct-Charge-URI,
> Acct-Calling-URI, Acct-Called-URI, Acct-Routing-URI, and
> Acct-Location-Routing-URI in the EM spec. 

Perhaps it is not clear that Acct-Charge-URI corresponds to "Charge
Number" (EM attribute ID 16), and that Acct-Calling-URI corresponds
to "Calling Party Number" (EM attribute ID 4), etc.  Although I
think it is obvious to anyone looking at the SIG-START event, some
text added to make this correspondance explicit.

Burcak Beser wrote:
> 9. Why not use the same approach as RKS-Group-ID not refer to EM spec,
> for all these details. The parameters should be defined as more
> generalized  which would make the definitions valid even if the specs
> change in the future. (By the way any reasons to keep RKS-Group-ID?)

PKT-SP-CMSS-I02-021205 Section 8.4.1.2 makes extensive use of RKS-Group-ID.
It is not defined in the EM spec.

Burcak Beser wrote:
> 10. Both P-DCS-LAES and P-DCS-Laes are being used in section 9. I
> suggest the use of P-DCS-LAES for consistency.

done

Burcak Beser wrote:
> 11. In section '10 Security Considerations' normative MUST is being used
> where I believe that should be non-normative must.

Note how in other documents, such as draft-ietf-sip-call-auth-06, the IESG
demanded a normative MUST in the Security Considerations section.  Similar
situation and wording here.

Burcak Beser wrote:
> 12. The acknowledgements section is divided into two and gives the
> impression that the DCS team and authors are a disjoint set, which is
> not the case. I would like to see that the real authors of the draft (at
> least Mike Mannette who wrote most of the initial text) should be
> properly acknowledged.

This was discussed in Spring 1999, nearly four years ago, and the agreed
attribution of the co-authors has been maintained.

Burcak Beser wrote:
> 13. Is there a reason for two editors instead of one, as suggested in
> rfc-editor policies (http://www.rfc-editor.org/policy.html).

because there are two editors for this document.  Further, there are
other examples with multiple editors, e.g. RFC3312.


Further, based on comments received from PacketCable MSOs, a new
token value was added to the P-DCS-OSPS header in Section 7, value "RING",
in order to signal a need to perform the Basic-911 operator ringback
function in regulatory environments where it is mandated.

Second, the use of MUSTs in Section 9 for including P-DCS-LAES information
into SIP messages was changed to SHOULD, and an explanatory paragraph
added at the beginning of the section explaining the conditions under
which it is/isn't to be added.

Bill Marshall
wtm@research.att.com
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Wed Jan 15 16:06:18 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10013
	for <sipping-archive@odin.ietf.org>; Wed, 15 Jan 2003 16:06:18 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0FLL6M10005
	for sipping-archive@odin.ietf.org; Wed, 15 Jan 2003 16:21:06 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FLL5J10002
	for <sipping-web-archive@optimus.ietf.org>; Wed, 15 Jan 2003 16:21:05 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09989
	for <sipping-web-archive@ietf.org>; Wed, 15 Jan 2003 16:05:47 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FLKLJ09935;
	Wed, 15 Jan 2003 16:20:21 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FLJVJ09863
	for <sipping@optimus.ietf.org>; Wed, 15 Jan 2003 16:19:31 -0500
Received: from dgesmtp02.wcom.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09959
	for <sipping@ietf.org>; Wed, 15 Jan 2003 16:04:12 -0500 (EST)
Received: from pmismtp01.wcomnet.com ([166.38.62.36])
 by firewall.wcom.com (Iplanet MTA )
 with ESMTP id <0H8R00A6VXC0R5@firewall.wcom.com> for sipping@ietf.org; Wed,
 15 Jan 2003 21:07:12 +0000 (GMT)
Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com
 (iPlanet Messaging Server 5.1 HotFix 0.7 (built May  7 2002))
 with SMTP id <0H8R00101XC0RI@pmismtp01.wcomnet.com>; Wed,
 15 Jan 2003 21:07:12 +0000 (GMT)
Received: from ajohnston.wcom.com ([166.42.34.75])
 by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7
 2002)) with ESMTP id <0H8R001F0XBY4F@pmismtp01.wcomnet.com>; Wed,
 15 Jan 2003 21:07:12 +0000 (GMT)
Date: Wed, 15 Jan 2003 15:07:06 -0600
From: Alan Johnston <alan.johnston@wcom.com>
Subject: Re: [Sipping] From tag in CANCEL
In-reply-to: <3E251A25.5F613C38@lmf.ericsson.se>
X-Sender: Alan.Johnston@pop.mcit.com
To: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>,
        sipping <sipping@ietf.org>, Robert Sparks <rsparks@dynamicsoft.com>
Cc: Miguel Angel <Miguel.A.Garcia@lmf.ericsson.se>
Message-id: <5.1.1.6.0.20030115150430.03858f10@pop.mcit.com>
MIME-version: 1.0
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Content-type: text/plain; charset=us-ascii; format=flowed
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

Gonzalo,

Thanks for the comments.  Agreed - I will make the corrections on CANCEL 
tags.  I also plan to go over the Call Flows I-Ds one last time to make 
sure that the tag usage is correct there.

Thanks,
Alan.

At 10:21 AM 1/15/2003 +0200, Gonzalo Camarillo wrote:
>Alan,
>
>in the service example draft,
>
>http://www.ietf.org/internet-drafts/draft-ietf-sipping-service-examples-03.txt
>
>Some CANCELs have a tag in the From header field and some don't. For
>example, the CANCEL (F6) in page 73 does not have a tag, but the CANCEL
>(F9) in page 135 has it.
>
>Quoting from RFC 3261 (section 9.1):
>" The
>    Request-URI, Call-ID, To, the numeric part of CSeq, and From header
>    fields in the CANCEL request MUST be identical to those in the
>    request being cancelled, including tags."
>
>Therefore, even if a CANCEL is generated by a proxy, it will have to
>have the From tag.
>
>The behavior regarding From tags for ACKs for non-2xx final responses
>generated by proxies is the same (Section 17.1.1.3).
>
>Regards,
>
>Gonzalo
>_______________________________________________
>Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>This list is for NEW development of the application of SIP
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sip@ietf.org for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Wed Jan 15 18:54:05 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15106
	for <sipping-archive@odin.ietf.org>; Wed, 15 Jan 2003 18:54:05 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0G08tm23582
	for sipping-archive@odin.ietf.org; Wed, 15 Jan 2003 19:08:55 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G08tJ23578
	for <sipping-web-archive@optimus.ietf.org>; Wed, 15 Jan 2003 19:08:55 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15092
	for <sipping-web-archive@ietf.org>; Wed, 15 Jan 2003 18:53:33 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G08FJ23535;
	Wed, 15 Jan 2003 19:08:15 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G07VJ23427
	for <sipping@optimus.ietf.org>; Wed, 15 Jan 2003 19:07:31 -0500
Received: from zsc3s004.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15049
	for <sipping@ietf.org>; Wed, 15 Jan 2003 18:52:09 -0500 (EST)
Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0FNtSQ11916;
	Wed, 15 Jan 2003 15:55:29 -0800 (PST)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0FNteN28463;
	Wed, 15 Jan 2003 17:55:40 -0600 (CST)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <C2QDZ9R4>; Wed, 15 Jan 2003 17:55:27 -0600
Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7CC02@zrc2c000.us.nortel.com>
From: "Mary Barnes" <mbarnes@nortelnetworks.com>
To: "'Elwell, John'" <john.elwell@siemens.com>,
        "Mark Watson" <mwatson@nortelnetworks.com>
Cc: "'sipping@ietf.org'" <sipping@ietf.org>
Date: Wed, 15 Jan 2003 17:55:21 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2BCF1.90204790"
Subject: [Sipping] RE: History information in provisional responses
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2BCF1.90204790
Content-Type: text/plain;
	charset="ISO-8859-1"

John,

As long as the original request from the user had a Supported header with
HistInfo, a UAS should be able to include History-Info in the appropriate
provisional responses. I'll clearly state that when discussing responses in
the sections of 2.3.

Mary.

-----Original Message-----
From: Elwell, John [mailto:john.elwell@siemens.com]
Sent: Monday, January 13, 2003 2:31 AM
To: Barnes, Mary [NGC:B602:EXCH]; Watson, Mark [MOP:EP10:EXCH]
Cc: 'sipping@ietf.org'
Subject: History information in provisional responses


Mary and others,

In the solution draft, nothing is said about inclusion of history
information in provisional responses. I am thinking in particular of 180.
This might be of benefit to a human originator in particular.

Although in many cases a proxy will retarget a request fairly quickly (e.g.,
if the target user has moved or is busy), it may be programmed to retarget
only after alerting the target user for a certain time. If successful the
retarget will result in a 180 response from the retargeted-to user and
hopefully eventually a 200 response. This means the UAC could receive two
(or more) 180 responses. If the second and subsequent 180 responses were to
contain history information, this would give the originator an explanation
of what is happening and may persuade the originator to allow the request to
continue longer in order to give the retargeted-to user time to answer.

Another possible advantage is that on seeing history information in a 180
the originator might decide not to establish a session with the
retargeted-to user and might cancel the request immediately without waiting
for answer.

What are your thoughts on history information in provisional responses?
Obviously it would need to be done in a way that does not compromise privacy
requirements.

Regards,

John


John Elwell
e-mail: mailto:john.elwell@siemens.com


------_=_NextPart_001_01C2BCF1.90204790
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: History information in provisional responses</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>John,</FONT>
</P>

<P><FONT SIZE=3D2>As long as the original request from the user had a =
Supported header with HistInfo, a UAS should be able to include =
History-Info in the appropriate provisional responses. I'll clearly =
state that when discussing responses in the sections of 2.3.</FONT></P>

<P><FONT SIZE=3D2>Mary.</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Elwell, John [<A =
HREF=3D"mailto:john.elwell@siemens.com">mailto:john.elwell@siemens.com</=
A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, January 13, 2003 2:31 AM</FONT>
<BR><FONT SIZE=3D2>To: Barnes, Mary [NGC:B602:EXCH]; Watson, Mark =
[MOP:EP10:EXCH]</FONT>
<BR><FONT SIZE=3D2>Cc: 'sipping@ietf.org'</FONT>
<BR><FONT SIZE=3D2>Subject: History information in provisional =
responses</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Mary and others,</FONT>
</P>

<P><FONT SIZE=3D2>In the solution draft, nothing is said about =
inclusion of history</FONT>
<BR><FONT SIZE=3D2>information in provisional responses. I am thinking =
in particular of 180.</FONT>
<BR><FONT SIZE=3D2>This might be of benefit to a human originator in =
particular.</FONT>
</P>

<P><FONT SIZE=3D2>Although in many cases a proxy will retarget a =
request fairly quickly (e.g.,</FONT>
<BR><FONT SIZE=3D2>if the target user has moved or is busy), it may be =
programmed to retarget</FONT>
<BR><FONT SIZE=3D2>only after alerting the target user for a certain =
time. If successful the</FONT>
<BR><FONT SIZE=3D2>retarget will result in a 180 response from the =
retargeted-to user and</FONT>
<BR><FONT SIZE=3D2>hopefully eventually a 200 response. This means the =
UAC could receive two</FONT>
<BR><FONT SIZE=3D2>(or more) 180 responses. If the second and =
subsequent 180 responses were to</FONT>
<BR><FONT SIZE=3D2>contain history information, this would give the =
originator an explanation</FONT>
<BR><FONT SIZE=3D2>of what is happening and may persuade the originator =
to allow the request to</FONT>
<BR><FONT SIZE=3D2>continue longer in order to give the retargeted-to =
user time to answer.</FONT>
</P>

<P><FONT SIZE=3D2>Another possible advantage is that on seeing history =
information in a 180</FONT>
<BR><FONT SIZE=3D2>the originator might decide not to establish a =
session with the</FONT>
<BR><FONT SIZE=3D2>retargeted-to user and might cancel the request =
immediately without waiting</FONT>
<BR><FONT SIZE=3D2>for answer.</FONT>
</P>

<P><FONT SIZE=3D2>What are your thoughts on history information in =
provisional responses?</FONT>
<BR><FONT SIZE=3D2>Obviously it would need to be done in a way that =
does not compromise privacy</FONT>
<BR><FONT SIZE=3D2>requirements.</FONT>
</P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>John</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>John Elwell</FONT>
<BR><FONT SIZE=3D2>e-mail: <A =
HREF=3D"mailto:john.elwell@siemens.com">mailto:john.elwell@siemens.com</=
A></FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2BCF1.90204790--
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Wed Jan 15 18:54:09 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15120
	for <sipping-archive@odin.ietf.org>; Wed, 15 Jan 2003 18:54:09 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0G08xd23597
	for sipping-archive@odin.ietf.org; Wed, 15 Jan 2003 19:08:59 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G08xJ23594
	for <sipping-web-archive@optimus.ietf.org>; Wed, 15 Jan 2003 19:08:59 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15096
	for <sipping-web-archive@ietf.org>; Wed, 15 Jan 2003 18:53:37 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G08CJ23514;
	Wed, 15 Jan 2003 19:08:12 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G07KJ23392
	for <sipping@optimus.ietf.org>; Wed, 15 Jan 2003 19:07:20 -0500
Received: from zsc3s004.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15042
	for <sipping@ietf.org>; Wed, 15 Jan 2003 18:51:58 -0500 (EST)
Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0FNtBQ11880;
	Wed, 15 Jan 2003 15:55:11 -0800 (PST)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0FNtMN28427;
	Wed, 15 Jan 2003 17:55:22 -0600 (CST)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <C2QDZ9RM>; Wed, 15 Jan 2003 17:55:09 -0600
Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7CC01@zrc2c000.us.nortel.com>
From: "Mary Barnes" <mbarnes@nortelnetworks.com>
To: "'Elwell, John'" <john.elwell@siemens.com>,
        "Mark Watson" <mwatson@nortelnetworks.com>,
        "'Peterson, Jon'" <jon.peterson@neustar.biz>
Cc: "'sipping@ietf.org'" <sipping@ietf.org>,
        "'fluffy@cisco.com'"
	 <fluffy@cisco.com>
Date: Wed, 15 Jan 2003 17:55:07 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2BCF1.87F7CF20"
Subject: [Sipping] RE: History information privacy requirements
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2BCF1.87F7CF20
Content-Type: text/plain;
	charset="ISO-8859-1"

John,

The purpose of the requirements is to ensure that the protocol has the
necessary elements to support any privacy requirements.  The intent of
PRIV-Req-1 was to ensure that user requested privacy is maintained as
retargeting occurs and the intent of PRIV-Req-2 is to address the need for
any entity (Proxy or UAS) receiving the information to maintain the privacy,
with the implication that any privacy mechanism is based on RFC 3323. Now,
perhaps the problem is that these requirements are currently too general and
need to be more specific, although I think getting more specific involves
getting more solution oriented. I could see the need to add a bit more
background to section 5. 

You are correct that RFC3323 does briefly discuss the privacy requirements
of the destination, but I think the clear recommendation is that you would
have provided a URI that doesn't reveal any information that you wouldn't
want disclosed. It clearly does not specify how you can maintain
functionality if you apply privacy to things like Record Route and does
clearly state that there's no way to privacy protect information needed to
route a request, however, you can somehow "disguise" the URI so that it
minimizes the privacy impact. (Jon, please do clarify if I've misinterpreted
this here). 

As Mark pointed out in the conclusion to the previous thread, existing
networks might appear to have this as a requirement, but it's not a general
requirement for SIP.
http://www.ietf.org/mail-archive/working-groups/sipping/current/msg03509.htm
l
I'm only personally familiar with how this works in the US with my
understanding primarily based upon how my home service works, as specified
by an insert provided by SWBell in 1995.  It clearly states that even if one
activates the feature to block the calling line ID, that this information is
still sent to the network and may not be blocked on calls to 800/900
numbers.  The blocking of the called party is typically not provided for a
PSTN user (for the same reason it's not done for Request URIs - you can't
reach the guy if you do so and is entirely application specific.  There are
examples where the actual DN of a destination isn't revealed, but that's all
due to application specific logic and not the protocols (e.g call centers
internally route calls without providing an externally dialable destination
DN for the agents)).  

We can likely go on and on with anecdotal scenarios, but I really don't want
to get into a rathole discussion on the nature of privacy (and calling line
id blocking, etc.)  but I am certainly open for further discussion if you
point us to some regulatory specifications documenting the need for
supporting something more.

Regards,
Mary.

-----Original Message-----
From: Elwell, John [mailto:john.elwell@siemens.com]
Sent: Monday, January 13, 2003 2:31 AM
To: Barnes, Mary [NGC:B602:EXCH]; Watson, Mark [MOP:EP10:EXCH];
'Peterson, Jon'
Cc: 'sipping@ietf.org'
Subject: History information privacy requirements


Mary and others,
 
I don't want to open up the whole discussion we had a few weeks ago, but
having read version 01 of the history requirements document I feel that we
perhaps need to make an addition.
 
Privacy requirements PRIV-req-1 and PRIV-req-2 both apply to information
about the originator of the request (according to the preceding sentence).
Privacy requirements of other users are not mentioned. I think they should
be discussed in the document, even if the conclusion is that no additional
requirements are placed on the solution.
 
1. Privacy requirements of the retargeted-to user.
 
1.1 This user may wish not to have his identity revealed to the originator.
This, of course, can apply to any request, not just requests that have
undergone retargeting. However, it is likely to be of greater relevance to a
request that has been retargeted. A destination user can protect his privacy
using RFC3323. It is important that the provisions of RFC3323 are not
compromised as a result of retargeting.
 
2. Privacy requirements of the retargeting user.
 
2.1 This user may be unwilling to disclose to the originator the fact that
retargeting has occurred
 
2.2 This user may be willing to disclose to the originator the fact that
retargeting has occurred but unwilling to disclose to the originator the
identity of the retargeted-to user.
 
2.3 This user may be unwilling to disclose to the retargeted-to user the
fact that retargeting has occurred
 
2.4 This user may be willing to disclose to the retargeted-to user the fact
that retargeting has occurred but unwilling to disclose to the retargeted-to
user the identity of the previous target.
 
NOTE. 2.3 and 2.4 are less convincing requirements, although I believe these
requirements are supported in public ISDN.
 
2.5 The retargeting user can also be a retargeted-to user of a previous
retarget. As such requirement 1.1 above can apply, i.e., the retargeting
user (retargeted-to user of previous retarget) is unwilling to disclose his
identity to the originating user.
 
2.6 The retargeting user has some of the characteristics of an originator if
the request is retargeted again further downstream. As such PRIV-req-1 and
PRIV-req-2 can apply to a retargeting user.
 
Regards,
 
John
 
John Elwell
e-mail: mailto:john.elwell@siemens.com <mailto:john.elwell@siemens.com>  


------_=_NextPart_001_01C2BCF1.87F7CF20
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: History information privacy requirements</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>John,</FONT>
</P>

<P><FONT SIZE=3D2>The purpose of the requirements is to ensure that the =
protocol has the necessary elements to support any privacy =
requirements.&nbsp; The intent of PRIV-Req-1 was to ensure that user =
requested privacy is maintained as retargeting occurs and the intent of =
PRIV-Req-2 is to address the need for any entity (Proxy or UAS) =
receiving the information to maintain the privacy, with the implication =
that any privacy mechanism is based on RFC 3323. Now, perhaps the =
problem is that these requirements are currently too general and need =
to be more specific, although I think getting more specific involves =
getting more solution oriented. I could see the need to add a bit more =
background to section 5. </FONT></P>

<P><FONT SIZE=3D2>You are correct that RFC3323 does briefly discuss the =
privacy requirements of the destination, but I think the clear =
recommendation is that you would have provided a URI that doesn't =
reveal any information that you wouldn't want disclosed. It clearly =
does not specify how you can maintain functionality if you apply =
privacy to things like Record Route and does clearly state that there's =
no way to privacy protect information needed to route a request, =
however, you can somehow &quot;disguise&quot; the URI so that it =
minimizes the privacy impact. (Jon, please do clarify if I've =
misinterpreted this here). </FONT></P>

<P><FONT SIZE=3D2>As Mark pointed out in the conclusion to the previous =
thread, existing networks might appear to have this as a requirement, =
but it's not a general requirement for SIP.</FONT></P>

<P><FONT SIZE=3D2><A =
HREF=3D"http://www.ietf.org/mail-archive/working-groups/sipping/current/=
msg03509.html" =
TARGET=3D"_blank">http://www.ietf.org/mail-archive/working-groups/sippin=
g/current/msg03509.html</A></FONT>
<BR><FONT SIZE=3D2>I'm only personally familiar with how this works in =
the US with my understanding primarily based upon how my home service =
works, as specified by an insert provided by SWBell in 1995.&nbsp; It =
clearly states that even if one activates the feature to block the =
calling line ID, that this information is still sent to the network and =
may not be blocked on calls to 800/900 numbers.&nbsp; The blocking of =
the called party is typically not provided for a PSTN user (for the =
same reason it's not done for Request URIs - you can't reach the guy if =
you do so and is entirely application specific.&nbsp; There are =
examples where the actual DN of a destination isn't revealed, but =
that's all due to application specific logic and not the protocols (e.g =
call centers internally route calls without providing an externally =
dialable destination DN for the agents)).&nbsp; </FONT></P>

<P><FONT SIZE=3D2>We can likely go on and on with anecdotal scenarios, =
but I really don't want to get into a rathole discussion on the nature =
of privacy (and calling line id blocking, etc.)&nbsp; but I am =
certainly open for further discussion if you point us to some =
regulatory specifications documenting the need for supporting something =
more.</FONT></P>

<P><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>Mary.</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Elwell, John [<A =
HREF=3D"mailto:john.elwell@siemens.com">mailto:john.elwell@siemens.com</=
A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, January 13, 2003 2:31 AM</FONT>
<BR><FONT SIZE=3D2>To: Barnes, Mary [NGC:B602:EXCH]; Watson, Mark =
[MOP:EP10:EXCH];</FONT>
<BR><FONT SIZE=3D2>'Peterson, Jon'</FONT>
<BR><FONT SIZE=3D2>Cc: 'sipping@ietf.org'</FONT>
<BR><FONT SIZE=3D2>Subject: History information privacy =
requirements</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Mary and others,</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>I don't want to open up the whole discussion we had =
a few weeks ago, but</FONT>
<BR><FONT SIZE=3D2>having read version 01 of the history requirements =
document I feel that we</FONT>
<BR><FONT SIZE=3D2>perhaps need to make an addition.</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>Privacy requirements PRIV-req-1 and PRIV-req-2 both =
apply to information</FONT>
<BR><FONT SIZE=3D2>about the originator of the request (according to =
the preceding sentence).</FONT>
<BR><FONT SIZE=3D2>Privacy requirements of other users are not =
mentioned. I think they should</FONT>
<BR><FONT SIZE=3D2>be discussed in the document, even if the conclusion =
is that no additional</FONT>
<BR><FONT SIZE=3D2>requirements are placed on the solution.</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>1. Privacy requirements of the retargeted-to =
user.</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>1.1 This user may wish not to have his identity =
revealed to the originator.</FONT>
<BR><FONT SIZE=3D2>This, of course, can apply to any request, not just =
requests that have</FONT>
<BR><FONT SIZE=3D2>undergone retargeting. However, it is likely to be =
of greater relevance to a</FONT>
<BR><FONT SIZE=3D2>request that has been retargeted. A destination user =
can protect his privacy</FONT>
<BR><FONT SIZE=3D2>using RFC3323. It is important that the provisions =
of RFC3323 are not</FONT>
<BR><FONT SIZE=3D2>compromised as a result of retargeting.</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>2. Privacy requirements of the retargeting =
user.</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>2.1 This user may be unwilling to disclose to the =
originator the fact that</FONT>
<BR><FONT SIZE=3D2>retargeting has occurred</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>2.2 This user may be willing to disclose to the =
originator the fact that</FONT>
<BR><FONT SIZE=3D2>retargeting has occurred but unwilling to disclose =
to the originator the</FONT>
<BR><FONT SIZE=3D2>identity of the retargeted-to user.</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>2.3 This user may be unwilling to disclose to the =
retargeted-to user the</FONT>
<BR><FONT SIZE=3D2>fact that retargeting has occurred</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>2.4 This user may be willing to disclose to the =
retargeted-to user the fact</FONT>
<BR><FONT SIZE=3D2>that retargeting has occurred but unwilling to =
disclose to the retargeted-to</FONT>
<BR><FONT SIZE=3D2>user the identity of the previous target.</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>NOTE. 2.3 and 2.4 are less convincing requirements, =
although I believe these</FONT>
<BR><FONT SIZE=3D2>requirements are supported in public ISDN.</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>2.5 The retargeting user can also be a retargeted-to =
user of a previous</FONT>
<BR><FONT SIZE=3D2>retarget. As such requirement 1.1 above can apply, =
i.e., the retargeting</FONT>
<BR><FONT SIZE=3D2>user (retargeted-to user of previous retarget) is =
unwilling to disclose his</FONT>
<BR><FONT SIZE=3D2>identity to the originating user.</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>2.6 The retargeting user has some of the =
characteristics of an originator if</FONT>
<BR><FONT SIZE=3D2>the request is retargeted again further downstream. =
As such PRIV-req-1 and</FONT>
<BR><FONT SIZE=3D2>PRIV-req-2 can apply to a retargeting user.</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>John</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>John Elwell</FONT>
<BR><FONT SIZE=3D2>e-mail: <A =
HREF=3D"mailto:john.elwell@siemens.com">mailto:john.elwell@siemens.com</=
A> &lt;<A =
HREF=3D"mailto:john.elwell@siemens.com">mailto:john.elwell@siemens.com</=
A>&gt;&nbsp; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2BCF1.87F7CF20--
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan 16 08:12:29 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09332
	for <sipping-archive@odin.ietf.org>; Thu, 16 Jan 2003 08:12:29 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0GDRa220591
	for sipping-archive@odin.ietf.org; Thu, 16 Jan 2003 08:27:36 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GDRZJ20588
	for <sipping-web-archive@optimus.ietf.org>; Thu, 16 Jan 2003 08:27:35 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09311
	for <sipping-web-archive@ietf.org>; Thu, 16 Jan 2003 08:11:58 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GDNHJ20158;
	Thu, 16 Jan 2003 08:23:17 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GDM6J20076
	for <sipping@optimus.ietf.org>; Thu, 16 Jan 2003 08:22:06 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08897;
	Thu, 16 Jan 2003 08:06:29 -0500 (EST)
Message-Id: <200301161306.IAA08897@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: sipping@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Thu, 16 Jan 2003 08:06:29 -0500
Subject: [Sipping] I-D ACTION:draft-wu-sipping-floor-control-03.txt
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Use of Session Initiation Protocol (SIP) and Simple 
                          Object Access
                          Protocol (SOAP) for Conference Floor Control
	Author(s)	: X. Wu et al.
	Filename	: draft-wu-sipping-floor-control-03.txt
	Pages		: 33
	Date		: 2003-1-15
	
During a conference, floor control coordinates simultaneous access to
shared resource in multimedia conferences. Floor control allows
applications and users to gain safe and mutually exclusive or non-
exclusive access to the shared resources. This document defines an
approach of using Session Initiation Protocol (SIP) event
notification mechanism and Simple Object Access Protocol (SOAP) to
perform floor control.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-wu-sipping-floor-control-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-wu-sipping-floor-control-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-wu-sipping-floor-control-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-1-15125659.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-wu-sipping-floor-control-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-wu-sipping-floor-control-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-1-15125659.I-D@ietf.org>

--OtherAccess--

--NextPart--


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan 16 08:56:15 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10920
	for <sipping-archive@odin.ietf.org>; Thu, 16 Jan 2003 08:56:15 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0GEBNA24348
	for sipping-archive@odin.ietf.org; Thu, 16 Jan 2003 09:11:23 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GEBMJ24345
	for <sipping-web-archive@optimus.ietf.org>; Thu, 16 Jan 2003 09:11:22 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10900
	for <sipping-web-archive@ietf.org>; Thu, 16 Jan 2003 08:55:44 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GE7KJ23922;
	Thu, 16 Jan 2003 09:07:20 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GE5XJ23341
	for <sipping@optimus.ietf.org>; Thu, 16 Jan 2003 09:05:33 -0500
Received: from hss.hns.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10808
	for <sipping@ietf.org>; Thu, 16 Jan 2003 08:49:52 -0500 (EST)
From: hbhondwe@hss.hns.com
Received: from sampark.hss.hns.com (sampark [139.85.229.22])
	by hss.hns.com (8.11.6/8.11.2) with SMTP id h0GDQHa04305;
	Thu, 16 Jan 2003 18:56:17 +0530
Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 65256CB0.004BDA0B ; Thu, 16 Jan 2003 19:18:30 +0530
X-Lotus-FromDomain: HSSBLR
To: sipping@ietf.org
cc: fmiller@sentito.com
Message-ID: <65256CB0.004BD998.00@sampark.hss.hns.com>
Date: Thu, 16 Jan 2003 19:18:28 +0530
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: [Sipping] Comments: I-D ACTION:draft-miller-sip-tcap-00.txt : Reposting
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>



Reposting this mail as it did not receive a response on the list the first
time.





hbhondwe@hss.hns.com on 01/10/2003 11:13:02 AM

To:   sipping@ietf.org
cc:    (bcc: Harsh Bhondwe/HSSBLR)

Subject:  [Sipping] Comments: I-D ACTION:draft-miller-sip-tcap-00.txt






Hi ,

I have a fundamental question on the the usage of SIP for
transporting TCAP messages.

If I understand correctly the figure 1 in the draft, is
something like the following:


SIP Element           Signaling Gateway         SS7 Node

TCAP applications                               PSTN Services
TCAP                                            TCAP
SIP--------IP----------SIP||SS7--------SS7------SS7


Here a TCAP peer will be running on the SIP Element and will
use SIP to exchange TCAP messages with peers(i.e other TCAPs)
in the PSTN network.

However, SIGTRAN protocols defined also by the SIGTRAN
Working group of the  IETF have been especially designed
for transporting Trunk/Access signaling over IP.

So, could one not better accomplish this  by the
following configuration using SIGTRAN?


SIP Element                   Signaling Gateway        PSTN Node

TCAP applications                                   PSTN Services
TCAP                                                   TCAP
SIGTRAN---------IP-------------SIGTRAN||SS7 ---SS7-----SS7
(SUA over SCTP)                (SUA over SCTP)


The difference of course is that in this case the SIP
Element and the Signaling Gateway will have to (also)
support SIGTRAN.They could continue to support SIP as well.

Or am i missing something?

thanks
harsh





_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP




_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan 16 09:29:38 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12023
	for <sipping-archive@odin.ietf.org>; Thu, 16 Jan 2003 09:29:38 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0GEik726745
	for sipping-archive@odin.ietf.org; Thu, 16 Jan 2003 09:44:46 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GEikJ26741
	for <sipping-web-archive@optimus.ietf.org>; Thu, 16 Jan 2003 09:44:46 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11998
	for <sipping-web-archive@ietf.org>; Thu, 16 Jan 2003 09:29:06 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GEegJ26509;
	Thu, 16 Jan 2003 09:40:42 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GADKJ07698
	for <sipping@optimus.ietf.org>; Thu, 16 Jan 2003 05:13:20 -0500
Received: from bramg1.net.external.hp.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05872
	for <sipping@ietf.org>; Thu, 16 Jan 2003 04:57:45 -0500 (EST)
Received: from loire.grenoble.hp.com (loire.grenoble.hp.com [15.128.14.199])
	by bramg1.net.external.hp.com (Postfix) with ESMTP id 7EF8D85B
	for <sipping@ietf.org>; Thu, 16 Jan 2003 11:01:07 +0100 (MET)
Received: by loire.grenoble.hp.com with Internet Mail Service (5.5.2655.55)
	id <C08MY8FB>; Thu, 16 Jan 2003 11:01:07 +0100
Message-ID: <1FA8FB96ED5BD411911D00D0B77FC68E07FEE7C7@galilei.italy.hp.com>
From: "PRATI,LUCA (HP-Italy,ex1)" <luca.prati@hp.com>
To: "'sipping@ietf.org'" <sipping@ietf.org>
Subject: RE: [Sipping] Do Phones Have Dial Plans, or do Proxies map?  was 
	RE:  [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
Date: Thu, 16 Jan 2003 11:01:04 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>



Hi Folks,

how would you compare SIP/SIMPLE with XMPP from an Instant
Messaging/Presence Management perspective if this is a subject you've
tackled already?
 
No reference to XMPP in the huge (269 pages) RFC 3261 on SIP...
... and it looks that no reference to SIP in the XMPP drafts.
 
Thanks and kind regards

Luca
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan 16 09:29:42 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12036
	for <sipping-archive@odin.ietf.org>; Thu, 16 Jan 2003 09:29:42 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0GEipJ26760
	for sipping-archive@odin.ietf.org; Thu, 16 Jan 2003 09:44:51 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GEipJ26757
	for <sipping-web-archive@optimus.ietf.org>; Thu, 16 Jan 2003 09:44:51 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12007
	for <sipping-web-archive@ietf.org>; Thu, 16 Jan 2003 09:29:11 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GEejJ26535;
	Thu, 16 Jan 2003 09:40:45 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GAQ2J08146
	for <sipping@optimus.ietf.org>; Thu, 16 Jan 2003 05:26:02 -0500
Received: from gremg1.net.external.hp.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06016
	for <sipping@ietf.org>; Thu, 16 Jan 2003 05:10:27 -0500 (EST)
Received: from loire.grenoble.hp.com (loire.grenoble.hp.com [15.128.14.199])
	by gremg1.net.external.hp.com (Postfix) with ESMTP id 29163195
	for <sipping@ietf.org>; Thu, 16 Jan 2003 11:13:49 +0100 (MET)
Received: by loire.grenoble.hp.com with Internet Mail Service (5.5.2655.55)
	id <C08MY9QW>; Thu, 16 Jan 2003 11:13:48 +0100
Message-ID: <1FA8FB96ED5BD411911D00D0B77FC68E07FEE7DD@galilei.italy.hp.com>
From: "PRATI,LUCA (HP-Italy,ex1)" <luca.prati@hp.com>
To: sipping@ietf.org
Date: Thu, 16 Jan 2003 11:13:47 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sipping] SIP <-> XMPP
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

Hi Folks,
how would you compare SIP/SIMPLE with XMPP from an Instant
Messaging/Presence Management perspective if this is a subject you've
tackled already? 
No reference to XMPP in the huge (269 pages) RFC 3261 on SIP... and it looks
that no reference to SIP in the XMPP drafts. 
Thanks and kind regards,
Luca

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan 16 09:59:39 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13019
	for <sipping-archive@odin.ietf.org>; Thu, 16 Jan 2003 09:59:39 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0GFEmk28976
	for sipping-archive@odin.ietf.org; Thu, 16 Jan 2003 10:14:48 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GFEmJ28973
	for <sipping-web-archive@optimus.ietf.org>; Thu, 16 Jan 2003 10:14:48 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13015
	for <sipping-web-archive@ietf.org>; Thu, 16 Jan 2003 09:59:08 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GFAcJ28745;
	Thu, 16 Jan 2003 10:10:38 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GF9vJ28656
	for <sipping@optimus.ietf.org>; Thu, 16 Jan 2003 10:09:57 -0500
Received: from fmis401r.omnitel.it (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12838
	for <sipping@ietf.org>; Thu, 16 Jan 2003 09:54:16 -0500 (EST)
From: loretosa@vizzavi.it
Received: from fmis439.omnitel.it by fmis401r.omnitel.it
          via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; 16 Jan 2003 14:57:39 UT
Received: (private information removed)
Received: (private information removed)
Content-Class: urn:content-classes:message
To: <sipping@ietf.org>
Date: Thu, 16 Jan 2003 15:53:36 +0100
Message-ID: <676001c2bd6f$0c349f70$5dde010a@omnitel.it>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
X-Mailer: Microsoft CDO for Windows 2000
Thread-Index: AcK9bww0YkduIi2yTTGs1Xj8ryMsyg==
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0GF9vJ28657
Subject: [Sipping] state of the art
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

Hi all,

please can someone help me to do a summary about the state of the art of SIP, SIPPING, and SIMPLE:

what are the open issues ?
what are the problems and priorities about this standard in 3GPP ? 
what are the outlooks about the use of this protocol ?



Sal

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan 16 11:42:58 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15744
	for <sipping-archive@odin.ietf.org>; Thu, 16 Jan 2003 11:42:58 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0GGw7T04144
	for sipping-archive@odin.ietf.org; Thu, 16 Jan 2003 11:58:07 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GGw7J04139
	for <sipping-web-archive@optimus.ietf.org>; Thu, 16 Jan 2003 11:58:07 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15724
	for <sipping-web-archive@ietf.org>; Thu, 16 Jan 2003 11:42:26 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GGsCJ03891;
	Thu, 16 Jan 2003 11:54:12 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GGlFJ03568
	for <sipping@optimus.ietf.org>; Thu, 16 Jan 2003 11:47:15 -0500
Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15470
	for <sipping@ietf.org>; Thu, 16 Jan 2003 11:31:31 -0500 (EST)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id h0GGYMTF027448;
	Thu, 16 Jan 2003 10:34:22 -0600
Received: (from dwillis@localhost)
	by bdsl.greycouncil.com (8.12.5/8.12.5/Submit) id h0GGYM3w027446;
	Thu, 16 Jan 2003 10:34:22 -0600
X-Authentication-Warning: bdsl.greycouncil.com: dwillis set sender to dean.willis@softarmor.com using -f
Subject: Re: [Sipping] SIP <-> XMPP
From: Dean Willis <dean.willis@softarmor.com>
To: "PRATI,LUCA  ""(HP-Italy,ex1)" <luca.prati@hp.com>
Cc: sipping@ietf.org
In-Reply-To: <1FA8FB96ED5BD411911D00D0B77FC68E07FEE7DD@galilei.italy.hp.com>
References: <1FA8FB96ED5BD411911D00D0B77FC68E07FEE7DD@galilei.italy.hp.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1042734861.27238.18.camel@bdsl.greycouncil.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.1 
Date: 16 Jan 2003 10:34:22 -0600
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit



On Thu, 2003-01-16 at 04:13, PRATI,LUCA (HP-Italy,ex1) wrote:
> Hi Folks,
> how would you compare SIP/SIMPLE with XMPP from an Instant
> Messaging/Presence Management perspective if this is a subject you've
> tackled already? 
> No reference to XMPP in the huge (269 pages) RFC 3261 on SIP... and it looks
> that no reference to SIP in the XMPP drafts. 
> Thanks and kind regards,
> Luca


SCOPE ALERT: This probably belongs in the SIMPLE or XMPP working groups.

Historically speaking, XMPP was not on the radar screen of the IETF when
3261 was published. 

I believe there is a SIMPLE draft dealing with using SIP to set up an
XMPP session for messaging.


-- 
Dean Willis <dean.willis@softarmor.com>
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan 16 12:51:25 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17832
	for <sipping-archive@odin.ietf.org>; Thu, 16 Jan 2003 12:51:24 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0GI6aT09327
	for sipping-archive@odin.ietf.org; Thu, 16 Jan 2003 13:06:36 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GI6aJ09324
	for <sipping-web-archive@optimus.ietf.org>; Thu, 16 Jan 2003 13:06:36 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17804
	for <sipping-web-archive@ietf.org>; Thu, 16 Jan 2003 12:50:53 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GI2UJ09052;
	Thu, 16 Jan 2003 13:02:30 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GI0EJ08841
	for <sipping@optimus.ietf.org>; Thu, 16 Jan 2003 13:00:14 -0500
Received: from lor.jeremie.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17524
	for <sipping@ietf.org>; Thu, 16 Jan 2003 12:44:31 -0500 (EST)
Received: from localhost (stpeter@localhost)
	by lor.jeremie.com (8.9.3/8.9.3) with ESMTP id LAA18778;
	Thu, 16 Jan 2003 11:47:38 -0600
Date: Thu, 16 Jan 2003 11:47:38 -0600 (CST)
From: Peter Saint-Andre <stpeter@jabber.org>
X-Sender: stpeter@lor.jeremie.com
To: Dean Willis <dean.willis@softarmor.com>
cc: "PRATI,LUCA  (HP-Italy,ex1)" <luca.prati@hp.com>, sipping@ietf.org
Subject: Re: [Sipping] SIP <-> XMPP
In-Reply-To: <1042734861.27238.18.camel@bdsl.greycouncil.com>
Message-ID: <Pine.LNX.4.10.10301161145290.16539-100000@lor.jeremie.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

On 16 Jan 2003, Dean Willis wrote:

> Historically speaking, XMPP was not on the radar screen of the IETF when
> 3261 was published. 

True, so we would not expect mention of XMPP in 3261.

> I believe there is a SIMPLE draft dealing with using SIP to set up an
> XMPP session for messaging.

http://www.ietf.org/internet-drafts/draft-sparks-simple-jabber-sessions-00.txt

Peter

--
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.php

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan 16 13:13:16 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18725
	for <sipping-archive@odin.ietf.org>; Thu, 16 Jan 2003 13:13:16 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0GISSI11473
	for sipping-archive@odin.ietf.org; Thu, 16 Jan 2003 13:28:28 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GISSJ11470
	for <sipping-web-archive@optimus.ietf.org>; Thu, 16 Jan 2003 13:28:28 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18713
	for <sipping-web-archive@ietf.org>; Thu, 16 Jan 2003 13:12:44 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GIRDJ11386;
	Thu, 16 Jan 2003 13:27:13 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GIOhJ11306
	for <sipping@optimus.ietf.org>; Thu, 16 Jan 2003 13:24:43 -0500
Received: from mailgate.siemenscomms.co.uk (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18599
	for <sipping@ietf.org>; Thu, 16 Jan 2003 13:08:59 -0500 (EST)
Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk
 (PMDF V6.0-24 #45905) id <0H8T00601JW55J@siemenscomms.co.uk> for
 sipping@ietf.org; Thu, 16 Jan 2003 18:12:05 +0000 (GMT)
Received: from beex10.siemenscomms.co.uk ([137.223.246.252])
 by siemenscomms.co.uk (PMDF V6.0-24 #45905)
 with ESMTP id <0H8T005JEJW53F@siemenscomms.co.uk>; Thu,
 16 Jan 2003 18:12:05 +0000 (GMT)
Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21)
	id <C95K50BR>; Thu, 16 Jan 2003 18:12:19 +0000
Content-return: allowed
Date: Thu, 16 Jan 2003 18:12:30 +0000
From: "Elwell, John" <john.elwell@siemens.com>
To: Mary Barnes <mbarnes@nortelnetworks.com>,
        Mark Watson <mwatson@nortelnetworks.com>,
        "'Peterson, Jon'" <jon.peterson@neustar.biz>
Cc: "'sipping@ietf.org'" <sipping@ietf.org>,
        "'fluffy@cisco.com'" <fluffy@cisco.com>
Message-id: <DE9048A49FFFE547BBC42F855DC8CC375AEE1B@beex53.siemenscomms.co.uk>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Content-Transfer-Encoding: 7BIT
Subject: [Sipping] RE: History information privacy requirements
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7BIT
Content-Transfer-Encoding: 7BIT

Mary,
 
To pick up on a particular point, you wrote:
 
".... There are examples where the actual DN of a destination isn't
revealed, but that's all due to application specific logic and not the
protocols (e.g call centers internally route calls without providing an
externally dialable destination DN for the agents)...."
 
Applying this same principle to SIP, application logic at the proxy could
determine the retargeted to URI. There may be reasons for not disclosing
this URI to the caller. Obviously one way to achieve this is to omit history
information altogether. Then the caller will never discover the
retargeted-to URI unless the UAS sends it back, but RFC 3323 provides the
UAS with a way of preventing that. However, there may be good reason why the
proxy will wish to place history information in the request before sending
it on downstream, e.g., to prevent retrying targets that have already been
tried, to advise the callee where the call has come from. So there may be a
requirement to send history information downstream but prevent it going
upstream back to the caller. Either there has to be a protocol solution to
indicate this privacy requirement to downstream proxies and the UAS, or the
retargeting proxy has to be responsible for removing any history information
that might compromise the privacy requirement. Unfortunately the latter
works only for a proxy, not a redirect, but perhaps redirection is
inappropriate in this situation (since the redirection request could reach
the UAC).
 
So even if we say that we don't need protocol enhancements as such, the
section of the solution document that describes proxy behaviour should point
out the possible need to remove upstream history information.
 
I guess most of the additional privacy requirements I mentioned can be
solved by appropriate proxy behaviour without requiring any additional
protocol elements. But I had expected these requirements to be laid down in
the requirements document and text in the solutions document indicating what
action needs to be taken to fulfil these requirements.
 
Concerning regulatory requirements, these are not my primary concern. Even
if there is no regulatory requirement governing a certain aspect of privacy,
there may be business requirements, as in the example above where there is a
requirement not to reveal the identity of a call centre agent.
 
Regards,
 
John

John Elwell
e-mail: mailto:john.elwell@siemens.com <mailto:john.elwell@siemens.com>  
 

 -----Original Message-----
From: Mary Barnes [mailto:mbarnes@nortelnetworks.com]
Sent: 15 January 2003 23:55 PM
To: 'Elwell, John'; Mark Watson; 'Peterson, Jon'
Cc: 'sipping@ietf.org'; 'fluffy@cisco.com'
Subject: RE: History information privacy requirements



John, 

The purpose of the requirements is to ensure that the protocol has the
necessary elements to support any privacy requirements.  The intent of
PRIV-Req-1 was to ensure that user requested privacy is maintained as
retargeting occurs and the intent of PRIV-Req-2 is to address the need for
any entity (Proxy or UAS) receiving the information to maintain the privacy,
with the implication that any privacy mechanism is based on RFC 3323. Now,
perhaps the problem is that these requirements are currently too general and
need to be more specific, although I think getting more specific involves
getting more solution oriented. I could see the need to add a bit more
background to section 5. 

You are correct that RFC3323 does briefly discuss the privacy requirements
of the destination, but I think the clear recommendation is that you would
have provided a URI that doesn't reveal any information that you wouldn't
want disclosed. It clearly does not specify how you can maintain
functionality if you apply privacy to things like Record Route and does
clearly state that there's no way to privacy protect information needed to
route a request, however, you can somehow "disguise" the URI so that it
minimizes the privacy impact. (Jon, please do clarify if I've misinterpreted
this here). 

As Mark pointed out in the conclusion to the previous thread, existing
networks might appear to have this as a requirement, but it's not a general
requirement for SIP.

http://www.ietf.org/mail-archive/working-groups/sipping/current/msg03509.htm
l
<http://www.ietf.org/mail-archive/working-groups/sipping/current/msg03509.ht
ml>  
I'm only personally familiar with how this works in the US with my
understanding primarily based upon how my home service works, as specified
by an insert provided by SWBell in 1995.  It clearly states that even if one
activates the feature to block the calling line ID, that this information is
still sent to the network and may not be blocked on calls to 800/900
numbers.  The blocking of the called party is typically not provided for a
PSTN user (for the same reason it's not done for Request URIs - you can't
reach the guy if you do so and is entirely application specific.  There are
examples where the actual DN of a destination isn't revealed, but that's all
due to application specific logic and not the protocols (e.g call centers
internally route calls without providing an externally dialable destination
DN for the agents)).  

We can likely go on and on with anecdotal scenarios, but I really don't want
to get into a rathole discussion on the nature of privacy (and calling line
id blocking, etc.)  but I am certainly open for further discussion if you
point us to some regulatory specifications documenting the need for
supporting something more.

Regards, 
Mary. 

-----Original Message----- 
From: Elwell, John [ mailto:john.elwell@siemens.com
<mailto:john.elwell@siemens.com> ] 
Sent: Monday, January 13, 2003 2:31 AM 
To: Barnes, Mary [NGC:B602:EXCH]; Watson, Mark [MOP:EP10:EXCH]; 
'Peterson, Jon' 
Cc: 'sipping@ietf.org' 
Subject: History information privacy requirements 


Mary and others, 
  
I don't want to open up the whole discussion we had a few weeks ago, but 
having read version 01 of the history requirements document I feel that we 
perhaps need to make an addition. 
  
Privacy requirements PRIV-req-1 and PRIV-req-2 both apply to information 
about the originator of the request (according to the preceding sentence). 
Privacy requirements of other users are not mentioned. I think they should 
be discussed in the document, even if the conclusion is that no additional 
requirements are placed on the solution. 
  
1. Privacy requirements of the retargeted-to user. 
  
1.1 This user may wish not to have his identity revealed to the originator. 
This, of course, can apply to any request, not just requests that have 
undergone retargeting. However, it is likely to be of greater relevance to a

request that has been retargeted. A destination user can protect his privacy

using RFC3323. It is important that the provisions of RFC3323 are not 
compromised as a result of retargeting. 
  
2. Privacy requirements of the retargeting user. 
  
2.1 This user may be unwilling to disclose to the originator the fact that 
retargeting has occurred 
  
2.2 This user may be willing to disclose to the originator the fact that 
retargeting has occurred but unwilling to disclose to the originator the 
identity of the retargeted-to user. 
  
2.3 This user may be unwilling to disclose to the retargeted-to user the 
fact that retargeting has occurred 
  
2.4 This user may be willing to disclose to the retargeted-to user the fact 
that retargeting has occurred but unwilling to disclose to the retargeted-to

user the identity of the previous target. 
  
NOTE. 2.3 and 2.4 are less convincing requirements, although I believe these

requirements are supported in public ISDN. 
  
2.5 The retargeting user can also be a retargeted-to user of a previous 
retarget. As such requirement 1.1 above can apply, i.e., the retargeting 
user (retargeted-to user of previous retarget) is unwilling to disclose his 
identity to the originating user. 
  
2.6 The retargeting user has some of the characteristics of an originator if

the request is retargeted again further downstream. As such PRIV-req-1 and 
PRIV-req-2 can apply to a retargeting user. 
  
Regards, 
  
John 
  
John Elwell 
e-mail: mailto:john.elwell@siemens.com <mailto:john.elwell@siemens.com>  <
mailto:john.elwell@siemens.com <mailto:john.elwell@siemens.com> >  

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan 16 15:40:45 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23340
	for <sipping-archive@odin.ietf.org>; Thu, 16 Jan 2003 15:40:45 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0GKu1C22362
	for sipping-archive@odin.ietf.org; Thu, 16 Jan 2003 15:56:01 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GKu1J22359
	for <sipping-web-archive@optimus.ietf.org>; Thu, 16 Jan 2003 15:56:01 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23330
	for <sipping-web-archive@ietf.org>; Thu, 16 Jan 2003 15:40:13 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GKsmJ22266;
	Thu, 16 Jan 2003 15:54:48 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GKr2J22175
	for <sipping@optimus.ietf.org>; Thu, 16 Jan 2003 15:53:02 -0500
Received: from zsc3s004.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23264
	for <sipping@ietf.org>; Thu, 16 Jan 2003 15:37:15 -0500 (EST)
Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0GKeRw27675;
	Thu, 16 Jan 2003 12:40:27 -0800 (PST)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0GKebH26898;
	Thu, 16 Jan 2003 14:40:37 -0600 (CST)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <C2QD5KY4>; Thu, 16 Jan 2003 14:40:24 -0600
Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7CC0D@zrc2c000.us.nortel.com>
From: "Mary Barnes" <mbarnes@nortelnetworks.com>
To: "'Elwell, John'" <john.elwell@siemens.com>,
        "Mark Watson" <mwatson@nortelnetworks.com>,
        "'Peterson, Jon'" <jon.peterson@neustar.biz>
Cc: "'sipping@ietf.org'" <sipping@ietf.org>,
        "'fluffy@cisco.com'"
	 <fluffy@cisco.com>
Date: Thu, 16 Jan 2003 14:40:23 -0600
X-Mailer: Internet Mail Service (5.5.2653.19)
Subject: [Sipping] RE: History information privacy requirements
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

Hi John,

I do understand your concerns and I think we agree that this is an
application issue.
I think what we need to do is to add some text in section 5 (and actually I
think this text should replace what's currently the last paragraph of that
section) highlighting that there may also be application specific reasons
for not including the Request History Information in responses, but that the
these reasons don't impose any additional requirements on the protocol.  I
think there is alot of overlap with the concerns you have raised and the
general optionality aspects that are primarily controlled by the application
and local policy as to whether the information is captured, and if it is
captured whether it is included in requests beyond that domain or in
responses, etc. As with the optionality, I think we've previously agreed
(and documented in the requirements) that the solution does need to provide
some guidelines as to the aspects which must be addressed by applications
making use of this capability.  I can add similar wording to section 5. 

As to what's needed in the solution draft to address this, section 2.3.3
does describe that whether the information is included in the response is
also based upon local policy, which should thus encompass these privacy
aspects.  

Mary.


-----Original Message-----
From: Elwell, John [mailto:john.elwell@siemens.com]
Sent: Thursday, January 16, 2003 12:12 PM
To: Barnes, Mary [NGC:B602:EXCH]; Watson, Mark [MOP:EP10:EXCH];
'Peterson, Jon'
Cc: 'sipping@ietf.org'; 'fluffy@cisco.com'
Subject: RE: History information privacy requirements


Mary,
 
To pick up on a particular point, you wrote:
 
".... There are examples where the actual DN of a destination isn't
revealed, but that's all due to application specific logic and not the
protocols (e.g call centers internally route calls without providing an
externally dialable destination DN for the agents)...."
 
Applying this same principle to SIP, application logic at the proxy could
determine the retargeted to URI. There may be reasons for not disclosing
this URI to the caller. Obviously one way to achieve this is to omit history
information altogether. Then the caller will never discover the
retargeted-to URI unless the UAS sends it back, but RFC 3323 provides the
UAS with a way of preventing that. However, there may be good reason why the
proxy will wish to place history information in the request before sending
it on downstream, e.g., to prevent retrying targets that have already been
tried, to advise the callee where the call has come from. So there may be a
requirement to send history information downstream but prevent it going
upstream back to the caller. Either there has to be a protocol solution to
indicate this privacy requirement to downstream proxies and the UAS, or the
retargeting proxy has to be responsible for removing any history information
that might compromise the privacy requirement. Unfortunately the latter
works only for a proxy, not a redirect, but perhaps redirection is
inappropriate in this situation (since the redirection request could reach
the UAC).
 
So even if we say that we don't need protocol enhancements as such, the
section of the solution document that describes proxy behaviour should point
out the possible need to remove upstream history information.
 
I guess most of the additional privacy requirements I mentioned can be
solved by appropriate proxy behaviour without requiring any additional
protocol elements. But I had expected these requirements to be laid down in
the requirements document and text in the solutions document indicating what
action needs to be taken to fulfil these requirements.
 
Concerning regulatory requirements, these are not my primary concern. Even
if there is no regulatory requirement governing a certain aspect of privacy,
there may be business requirements, as in the example above where there is a
requirement not to reveal the identity of a call centre agent.
 
Regards,
 
John

John Elwell
e-mail: mailto:john.elwell@siemens.com <mailto:john.elwell@siemens.com>  
 
----remainder of thread deleted------

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan 16 17:43:37 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25820
	for <sipping-archive@odin.ietf.org>; Thu, 16 Jan 2003 17:43:37 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0GMwuo30393
	for sipping-archive@odin.ietf.org; Thu, 16 Jan 2003 17:58:56 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GMwuJ30390
	for <sipping-web-archive@optimus.ietf.org>; Thu, 16 Jan 2003 17:58:56 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25816
	for <sipping-web-archive@ietf.org>; Thu, 16 Jan 2003 17:43:04 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GMvjJ30333;
	Thu, 16 Jan 2003 17:57:45 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GMu7J30281
	for <sipping@optimus.ietf.org>; Thu, 16 Jan 2003 17:56:07 -0500
Received: from zsc3s004.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25796
	for <sipping@ietf.org>; Thu, 16 Jan 2003 17:40:15 -0500 (EST)
Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0GMhYw24368;
	Thu, 16 Jan 2003 14:43:35 -0800 (PST)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0GMhjH00670;
	Thu, 16 Jan 2003 16:43:46 -0600 (CST)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <C2QD5NXP>; Thu, 16 Jan 2003 16:43:32 -0600
Message-ID: <933FADF5E673D411B8A30002A5608A0E076E29A0@zrc2c012.us.nortel.com>
From: "Brian Stucker" <bstucker@nortelnetworks.com>
To: "Daniel G. Petrie" <dpetrie@pingtel.com>,
        "Rosen, Brian"
	 <Brian.Rosen@marconi.com>
Cc: "'Henning Schulzrinne'" <hgs@cs.columbia.edu>,
        Adam Roach
	 <adam@dynamicsoft.com>,
        "'Paul Kyzivat'" <pkyzivat@cisco.com>,
        "'sipping@ietf.org'" <sipping@ietf.org>
Subject: RE: [Sipping] Do Phones Have Dial Plans, or do Proxies map?  was 
	RE:  [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
Date: Thu, 16 Jan 2003 16:43:28 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2BDB0.AFC062F0"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2BDB0.AFC062F0
Content-Type: text/plain;
	charset="ISO-8859-1"

A few observations from left field...

We can "know" when a user is done dialing, if you don't want to click to
dial through other
means:

- The user picks up the handset after dialing (ala PBX phones).
- A timer pops in the digit collection routine on the UA (ala PSTN digit
collectors).
- The user hits an extra button to tell the device their done, so it doesn't
have
to read their mind as to when they may be finished (ala cell phones, and PBX
phones).

Really, no matter what, you're going to have to have a timer or an explicit
form of 
"punctuation" (ie a TALK/SEND/CALL/DIAL button) involved in the digit
collection
algorithm. Otherwise, how do you know when a user is continuing to enter
digits, or
has simply entered an invalid number? To use Henning's example of dialing
6744 to
ring his admin, what do you expect the UA to do when he dials 674? Sit there
forever
and wait for the other four to drop? 

You can still offer an auto-completed set of dialed digits for the user,
without 
having to understand what it is that they're dialing.

As for knowing how to form a canonical URL, other than some sort of very
bland BCP,
such as, use a tel url with a particular, one-size-fits-all, phone context
setting,
I doubt you'll be able to satisfy all of the demands that each
vendor/customer may
have in being able to route calls in a predictable manner.

As for the routing to the correct outbound proxy, it seems very artificial
to say that
a reason for having a dialplan in the UA is so that you can select an
outbound proxy
by making the election as part of the dialed digits.

I could argue that the functionality you describe can also be reasonably
handled by 
representing each outbound proxy as a "virtual line". People are used to the
idea, 
that to use your example, personal calls should not go through their
business's PBX, 
and vice-versa, that they have, at a minimum, two-lines (and possibly two
phones). 
One is hooked up to the business PBX, the other through another carrier for
private 
calls. Reducing this down to virtual lines on the UA seems reasonably
logical to me. 
You select the "private" line (which is configured to your private service
provider), 
and then dial to make a personal call. Likewise, you select the "business"
line (which 
is configured to your IP PBX), to make business calls. 

To me, there's a big difference in the UA being able to correctly format
it's request
to the outbound proxy, and the UA having to actually *understand* what is
sent to the
local outbound proxy. A dialplan, to me, infers that the UA has to actually
understand
to some degree, and interpret the digits prior to translations at the proxy.
This means
that some degree of translations are possible at two points in the network,
and now I
have to go about keeping them in-sync with one another to get predictable
results. Seems
like a dangerous mess, and one that the phone system has done without for a
very long
time.

If a dialplan is simply something that we use to format the digit stream
into a standard,
no matter what they dialed, layout so that the proxy can expect a
predictable format that
it will receive the digit stream in, that seems much more feasible and
reasonable. If this
is the case, SIP itself can be considered a dialplan, as the digits must be
transported in
a legally formatted SIP request.

Regards,

Brian



-----Original Message-----
From: Daniel G. Petrie [mailto:dpetrie@pingtel.com]
Sent: Friday, January 10, 2003 4:52 PM
To: Rosen, Brian
Cc: 'Henning Schulzrinne'; Adam Roach; 'Paul Kyzivat';
'sipping@ietf.org'
Subject: Re: [Sipping] Do Phones Have Dial Plans, or do Proxies map? was
RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt


There is actually a third reason to have dial plans on the UA.  The
first two have already been brought up:

1) To know when the user is done dialing
2) To know how to form a canonical URL (tel , sip or sips)
3) To know how to route the INVITE to the correct outbound proxy

On the first one, knowing when the user is done dialing,  I am afraid, as
Cullen pointed out, the market (at least in North America) wants a phone
that knows when the user is done dialing.  There are too many people
who still like the pre-cell phone metaphor. Sorry but the people on this
list do not buy enough phones to decide this one ;-).

The UA needs to know how it is going to form a cannonical URL from
the mess of characters and digits the user entered.  So as Brian pointed
out you need some regexp to transform the entered characters into a
URL.   Well guess what, every proxy vendor wants this to be a little
different.   Some want short strings (AKA extensions) transformed
differently
than long strings (AKA E.164 numbers).  So call it what you want you
end up with the equivalent of a dial plan.  The best we can do here is
to come of with a standardized (or call it BCP) way to write the
transforms.  We can write a standard that says this is the one and
only transform, but no phone vendor that has a dial plan mechanism
will be able to drop their dial plan support because they have customers
using it.  However I am sure the market would be happy to push
vendors to support a standardized dial plan description mechanism.

The third use of dial plans is for routing purposes.  I know!  That is
what the proxy is supposed to do.  However there are several uses
for doing some simple routing from the phone base upon the "dialed
string":

a) Functional routing: where based upon the purpose of the call the
user wants the call routed differently.  For example I have a phone
at home from which I make personal calls via my favorite service
provider and from which I make business calls via my enterprise
IP PBX.  I want my private/personal calls private and my business
does not want to pay for my personal calls.   A simple, familiar
metaphor for this is to use a dialing prefix (e.g. dial 9 and number
for business call, dial 8 and number for personal calls).  The alternatives

would be to sell home/office users two phones (I wish that would fly)
or put a proxy in every home/office (I would not mind selling that
many proxies if that would fly as well).

b) Load balancing routing:  based upon my dialed string I may
want to use a different out bound proxy.   Domestic US calls
go to one proxy, international calls go to another, 911/emergency
calls go directly to the local emergency gateway.  Can this be
done by the proxy? Sometimes, if I can get to it, but once you
have a dial plan on the phone, this is just about free from
both an implementation and compute cost perspective (e.g.
loose routing with a Route header in the regexp/transform).

I am happy to remove functionality from the UA and not support
it, but I am afraid the dial plan is here to stay in the UA.  I  think
our best path forward is with a standard way to specify the dial plan
transforms.



"Rosen, Brian" wrote:

> Actually, I'm happy with a "Dial" button.
>
> I'll note most existing SIP phones don't do this (or at least don't
> have a physical "Dial" button, I've seen some with softkeys).
>
> However, the issue remains.  If I dial 6744 on my sip phone (and press
> dial), the sipphone on my admin's desk should ring.  I should not have
> to dial +17247426744.  The fact that I dialed a 4 digit number with
> a 6 as the starting digit tells my system that it is an internal
> extension.  A dial plan is the thing that "knows" this.
>
> What do you want to have happen:
> 1) tel:6744; context=+1724742
> 2) tel:6744; context=marconi-pittsburgh-local-extension
> 3) tel:+17247426744
>
> Note the last is problematic.  As Mike Pierce points out, not all
> extensions have E.164s
>
> And, to amplify the thread that started this, how many identities does
> my admin's UA have to understand?
>
> Again, I'm not opposed to making dial string expansion be a requirement
> of the UA, as long as we standardize the form of the expansion, and the
> mechanism by which the UA learns it.
>
> Brian
>
> > -----Original Message-----
> > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> > Sent: Thursday, January 09, 2003 9:07 PM
> > To: Adam Roach
> > Cc: Rosen, Brian; 'Paul Kyzivat'; 'sipping@ietf.org'
> > Subject: Re: [Sipping] Do Phones Have Dial Plans, or do
> > Proxies map? was
> > RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
> >
> >
> > In case there's doubt: I was not suggesting that we do this. I was
> > trying to find out from Brian what he meant, since the two
> > problem have
> > very different solution sets. The 'abbreviated dialing' case requires
> > nothing except a suitable URI scheme and the translation
> > services of an
> > outbound proxy.
> >
> > Adam Roach wrote:
> > >>- Recognizing patterns so that one can keep the old
> > >>"no-need-to-hit-dial" user interface.
> > >
> > >
> > > AAAAAUUUUGGGHHHHH!!! AAAAAUUUUGGGHHHHH!!! AAAAAUUUUGGGHHHHH!!!
> > >
> > > No!
> > >
> > > Cell phones have sufficiently trained the public that it's
> > > okay to hit something like "OK" or "YES" or "DIAL" or "ENTER"
> > > after a phone number. It makes life so much easier for user
> > > interface designers and users alike. For the love of all that
> > > is good, let's not encourage backsliding.
> > >
> > > /a
> >
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP

------_=_NextPart_001_01C2BDB0.AFC062F0
Content-Type: text/html;
	charset="ISO-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: [Sipping] Do Phones Have Dial Plans, or do Proxies map?  was RE:  [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>A few observations from left field...</FONT>
</P>

<P><FONT SIZE=2>We can &quot;know&quot; when a user is done dialing, if you don't want to click to dial through other</FONT>
<BR><FONT SIZE=2>means:</FONT>
</P>

<P><FONT SIZE=2>- The user picks up the handset after dialing (ala PBX phones).</FONT>
<BR><FONT SIZE=2>- A timer pops in the digit collection routine on the UA (ala PSTN digit collectors).</FONT>
<BR><FONT SIZE=2>- The user hits an extra button to tell the device their done, so it doesn't have</FONT>
<BR><FONT SIZE=2>to read their mind as to when they may be finished (ala cell phones, and PBX phones).</FONT>
</P>

<P><FONT SIZE=2>Really, no matter what, you're going to have to have a timer or an explicit form of </FONT>
<BR><FONT SIZE=2>&quot;punctuation&quot; (ie a TALK/SEND/CALL/DIAL button) involved in the digit collection</FONT>
<BR><FONT SIZE=2>algorithm. Otherwise, how do you know when a user is continuing to enter digits, or</FONT>
<BR><FONT SIZE=2>has simply entered an invalid number? To use Henning's example of dialing 6744 to</FONT>
<BR><FONT SIZE=2>ring his admin, what do you expect the UA to do when he dials 674? Sit there forever</FONT>
<BR><FONT SIZE=2>and wait for the other four to drop? </FONT>
</P>

<P><FONT SIZE=2>You can still offer an auto-completed set of dialed digits for the user, without </FONT>
<BR><FONT SIZE=2>having to understand what it is that they're dialing.</FONT>
</P>

<P><FONT SIZE=2>As for knowing how to form a canonical URL, other than some sort of very bland BCP,</FONT>
<BR><FONT SIZE=2>such as, use a tel url with a particular, one-size-fits-all, phone context setting,</FONT>
<BR><FONT SIZE=2>I doubt you'll be able to satisfy all of the demands that each vendor/customer may</FONT>
<BR><FONT SIZE=2>have in being able to route calls in a predictable manner.</FONT>
</P>

<P><FONT SIZE=2>As for the routing to the correct outbound proxy, it seems very artificial to say that</FONT>
<BR><FONT SIZE=2>a reason for having a dialplan in the UA is so that you can select an outbound proxy</FONT>
<BR><FONT SIZE=2>by making the election as part of the dialed digits.</FONT>
</P>

<P><FONT SIZE=2>I could argue that the functionality you describe can also be reasonably handled by </FONT>
<BR><FONT SIZE=2>representing each outbound proxy as a &quot;virtual line&quot;. People are used to the idea, </FONT>
<BR><FONT SIZE=2>that to use your example, personal calls should not go through their business's PBX, </FONT>
<BR><FONT SIZE=2>and vice-versa, that they have, at a minimum, two-lines (and possibly two phones). </FONT>
<BR><FONT SIZE=2>One is hooked up to the business PBX, the other through another carrier for private </FONT>
<BR><FONT SIZE=2>calls. Reducing this down to virtual lines on the UA seems reasonably logical to me. </FONT>
<BR><FONT SIZE=2>You select the &quot;private&quot; line (which is configured to your private service provider), </FONT>
<BR><FONT SIZE=2>and then dial to make a personal call. Likewise, you select the &quot;business&quot; line (which </FONT>
<BR><FONT SIZE=2>is configured to your IP PBX), to make business calls. </FONT>
</P>

<P><FONT SIZE=2>To me, there's a big difference in the UA being able to correctly format it's request</FONT>
<BR><FONT SIZE=2>to the outbound proxy, and the UA having to actually *understand* what is sent to the</FONT>
<BR><FONT SIZE=2>local outbound proxy. A dialplan, to me, infers that the UA has to actually understand</FONT>
<BR><FONT SIZE=2>to some degree, and interpret the digits prior to translations at the proxy. This means</FONT>
<BR><FONT SIZE=2>that some degree of translations are possible at two points in the network, and now I</FONT>
<BR><FONT SIZE=2>have to go about keeping them in-sync with one another to get predictable results. Seems</FONT>
<BR><FONT SIZE=2>like a dangerous mess, and one that the phone system has done without for a very long</FONT>
<BR><FONT SIZE=2>time.</FONT>
</P>

<P><FONT SIZE=2>If a dialplan is simply something that we use to format the digit stream into a standard,</FONT>
<BR><FONT SIZE=2>no matter what they dialed, layout so that the proxy can expect a predictable format that</FONT>
<BR><FONT SIZE=2>it will receive the digit stream in, that seems much more feasible and reasonable. If this</FONT>
<BR><FONT SIZE=2>is the case, SIP itself can be considered a dialplan, as the digits must be transported in</FONT>
<BR><FONT SIZE=2>a legally formatted SIP request.</FONT>
</P>

<P><FONT SIZE=2>Regards,</FONT>
</P>

<P><FONT SIZE=2>Brian</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Daniel G. Petrie [<A HREF="mailto:dpetrie@pingtel.com">mailto:dpetrie@pingtel.com</A>]</FONT>
<BR><FONT SIZE=2>Sent: Friday, January 10, 2003 4:52 PM</FONT>
<BR><FONT SIZE=2>To: Rosen, Brian</FONT>
<BR><FONT SIZE=2>Cc: 'Henning Schulzrinne'; Adam Roach; 'Paul Kyzivat';</FONT>
<BR><FONT SIZE=2>'sipping@ietf.org'</FONT>
<BR><FONT SIZE=2>Subject: Re: [Sipping] Do Phones Have Dial Plans, or do Proxies map? was</FONT>
<BR><FONT SIZE=2>RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt</FONT>
</P>
<BR>

<P><FONT SIZE=2>There is actually a third reason to have dial plans on the UA.&nbsp; The</FONT>
<BR><FONT SIZE=2>first two have already been brought up:</FONT>
</P>

<P><FONT SIZE=2>1) To know when the user is done dialing</FONT>
<BR><FONT SIZE=2>2) To know how to form a canonical URL (tel , sip or sips)</FONT>
<BR><FONT SIZE=2>3) To know how to route the INVITE to the correct outbound proxy</FONT>
</P>

<P><FONT SIZE=2>On the first one, knowing when the user is done dialing,&nbsp; I am afraid, as</FONT>
<BR><FONT SIZE=2>Cullen pointed out, the market (at least in North America) wants a phone</FONT>
<BR><FONT SIZE=2>that knows when the user is done dialing.&nbsp; There are too many people</FONT>
<BR><FONT SIZE=2>who still like the pre-cell phone metaphor. Sorry but the people on this</FONT>
<BR><FONT SIZE=2>list do not buy enough phones to decide this one ;-).</FONT>
</P>

<P><FONT SIZE=2>The UA needs to know how it is going to form a cannonical URL from</FONT>
<BR><FONT SIZE=2>the mess of characters and digits the user entered.&nbsp; So as Brian pointed</FONT>
<BR><FONT SIZE=2>out you need some regexp to transform the entered characters into a</FONT>
<BR><FONT SIZE=2>URL.&nbsp;&nbsp; Well guess what, every proxy vendor wants this to be a little</FONT>
<BR><FONT SIZE=2>different.&nbsp;&nbsp; Some want short strings (AKA extensions) transformed</FONT>
<BR><FONT SIZE=2>differently</FONT>
<BR><FONT SIZE=2>than long strings (AKA E.164 numbers).&nbsp; So call it what you want you</FONT>
<BR><FONT SIZE=2>end up with the equivalent of a dial plan.&nbsp; The best we can do here is</FONT>
<BR><FONT SIZE=2>to come of with a standardized (or call it BCP) way to write the</FONT>
<BR><FONT SIZE=2>transforms.&nbsp; We can write a standard that says this is the one and</FONT>
<BR><FONT SIZE=2>only transform, but no phone vendor that has a dial plan mechanism</FONT>
<BR><FONT SIZE=2>will be able to drop their dial plan support because they have customers</FONT>
<BR><FONT SIZE=2>using it.&nbsp; However I am sure the market would be happy to push</FONT>
<BR><FONT SIZE=2>vendors to support a standardized dial plan description mechanism.</FONT>
</P>

<P><FONT SIZE=2>The third use of dial plans is for routing purposes.&nbsp; I know!&nbsp; That is</FONT>
<BR><FONT SIZE=2>what the proxy is supposed to do.&nbsp; However there are several uses</FONT>
<BR><FONT SIZE=2>for doing some simple routing from the phone base upon the &quot;dialed</FONT>
<BR><FONT SIZE=2>string&quot;:</FONT>
</P>

<P><FONT SIZE=2>a) Functional routing: where based upon the purpose of the call the</FONT>
<BR><FONT SIZE=2>user wants the call routed differently.&nbsp; For example I have a phone</FONT>
<BR><FONT SIZE=2>at home from which I make personal calls via my favorite service</FONT>
<BR><FONT SIZE=2>provider and from which I make business calls via my enterprise</FONT>
<BR><FONT SIZE=2>IP PBX.&nbsp; I want my private/personal calls private and my business</FONT>
<BR><FONT SIZE=2>does not want to pay for my personal calls.&nbsp;&nbsp; A simple, familiar</FONT>
<BR><FONT SIZE=2>metaphor for this is to use a dialing prefix (e.g. dial 9 and number</FONT>
<BR><FONT SIZE=2>for business call, dial 8 and number for personal calls).&nbsp; The alternatives</FONT>
</P>

<P><FONT SIZE=2>would be to sell home/office users two phones (I wish that would fly)</FONT>
<BR><FONT SIZE=2>or put a proxy in every home/office (I would not mind selling that</FONT>
<BR><FONT SIZE=2>many proxies if that would fly as well).</FONT>
</P>

<P><FONT SIZE=2>b) Load balancing routing:&nbsp; based upon my dialed string I may</FONT>
<BR><FONT SIZE=2>want to use a different out bound proxy.&nbsp;&nbsp; Domestic US calls</FONT>
<BR><FONT SIZE=2>go to one proxy, international calls go to another, 911/emergency</FONT>
<BR><FONT SIZE=2>calls go directly to the local emergency gateway.&nbsp; Can this be</FONT>
<BR><FONT SIZE=2>done by the proxy? Sometimes, if I can get to it, but once you</FONT>
<BR><FONT SIZE=2>have a dial plan on the phone, this is just about free from</FONT>
<BR><FONT SIZE=2>both an implementation and compute cost perspective (e.g.</FONT>
<BR><FONT SIZE=2>loose routing with a Route header in the regexp/transform).</FONT>
</P>

<P><FONT SIZE=2>I am happy to remove functionality from the UA and not support</FONT>
<BR><FONT SIZE=2>it, but I am afraid the dial plan is here to stay in the UA.&nbsp; I&nbsp; think</FONT>
<BR><FONT SIZE=2>our best path forward is with a standard way to specify the dial plan</FONT>
<BR><FONT SIZE=2>transforms.</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=2>&quot;Rosen, Brian&quot; wrote:</FONT>
</P>

<P><FONT SIZE=2>&gt; Actually, I'm happy with a &quot;Dial&quot; button.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; I'll note most existing SIP phones don't do this (or at least don't</FONT>
<BR><FONT SIZE=2>&gt; have a physical &quot;Dial&quot; button, I've seen some with softkeys).</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; However, the issue remains.&nbsp; If I dial 6744 on my sip phone (and press</FONT>
<BR><FONT SIZE=2>&gt; dial), the sipphone on my admin's desk should ring.&nbsp; I should not have</FONT>
<BR><FONT SIZE=2>&gt; to dial +17247426744.&nbsp; The fact that I dialed a 4 digit number with</FONT>
<BR><FONT SIZE=2>&gt; a 6 as the starting digit tells my system that it is an internal</FONT>
<BR><FONT SIZE=2>&gt; extension.&nbsp; A dial plan is the thing that &quot;knows&quot; this.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; What do you want to have happen:</FONT>
<BR><FONT SIZE=2>&gt; 1) tel:6744; context=+1724742</FONT>
<BR><FONT SIZE=2>&gt; 2) tel:6744; context=marconi-pittsburgh-local-extension</FONT>
<BR><FONT SIZE=2>&gt; 3) tel:+17247426744</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; Note the last is problematic.&nbsp; As Mike Pierce points out, not all</FONT>
<BR><FONT SIZE=2>&gt; extensions have E.164s</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; And, to amplify the thread that started this, how many identities does</FONT>
<BR><FONT SIZE=2>&gt; my admin's UA have to understand?</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; Again, I'm not opposed to making dial string expansion be a requirement</FONT>
<BR><FONT SIZE=2>&gt; of the UA, as long as we standardize the form of the expansion, and the</FONT>
<BR><FONT SIZE=2>&gt; mechanism by which the UA learns it.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; Brian</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; &gt; From: Henning Schulzrinne [<A HREF="mailto:hgs@cs.columbia.edu">mailto:hgs@cs.columbia.edu</A>]</FONT>
<BR><FONT SIZE=2>&gt; &gt; Sent: Thursday, January 09, 2003 9:07 PM</FONT>
<BR><FONT SIZE=2>&gt; &gt; To: Adam Roach</FONT>
<BR><FONT SIZE=2>&gt; &gt; Cc: Rosen, Brian; 'Paul Kyzivat'; 'sipping@ietf.org'</FONT>
<BR><FONT SIZE=2>&gt; &gt; Subject: Re: [Sipping] Do Phones Have Dial Plans, or do</FONT>
<BR><FONT SIZE=2>&gt; &gt; Proxies map? was</FONT>
<BR><FONT SIZE=2>&gt; &gt; RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; In case there's doubt: I was not suggesting that we do this. I was</FONT>
<BR><FONT SIZE=2>&gt; &gt; trying to find out from Brian what he meant, since the two</FONT>
<BR><FONT SIZE=2>&gt; &gt; problem have</FONT>
<BR><FONT SIZE=2>&gt; &gt; very different solution sets. The 'abbreviated dialing' case requires</FONT>
<BR><FONT SIZE=2>&gt; &gt; nothing except a suitable URI scheme and the translation</FONT>
<BR><FONT SIZE=2>&gt; &gt; services of an</FONT>
<BR><FONT SIZE=2>&gt; &gt; outbound proxy.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; Adam Roach wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&gt;- Recognizing patterns so that one can keep the old</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&gt;&quot;no-need-to-hit-dial&quot; user interface.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; AAAAAUUUUGGGHHHHH!!! AAAAAUUUUGGGHHHHH!!! AAAAAUUUUGGGHHHHH!!!</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; No!</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; Cell phones have sufficiently trained the public that it's</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; okay to hit something like &quot;OK&quot; or &quot;YES&quot; or &quot;DIAL&quot; or &quot;ENTER&quot;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; after a phone number. It makes life so much easier for user</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; interface designers and users alike. For the love of all that</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; is good, let's not encourage backsliding.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; /a</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; _______________________________________________</FONT>
<BR><FONT SIZE=2>&gt; Sipping mailing list&nbsp; <A HREF="https://www1.ietf.org/mailman/listinfo/sipping" TARGET="_blank">https://www1.ietf.org/mailman/listinfo/sipping</A></FONT>
<BR><FONT SIZE=2>&gt; This list is for NEW development of the application of SIP</FONT>
<BR><FONT SIZE=2>&gt; Use sip-implementors@cs.columbia.edu for questions on current sip</FONT>
<BR><FONT SIZE=2>&gt; Use sip@ietf.org for new developments of core SIP</FONT>
</P>

<P><FONT SIZE=2>_______________________________________________</FONT>
<BR><FONT SIZE=2>Sipping mailing list&nbsp; <A HREF="https://www1.ietf.org/mailman/listinfo/sipping" TARGET="_blank">https://www1.ietf.org/mailman/listinfo/sipping</A></FONT>
<BR><FONT SIZE=2>This list is for NEW development of the application of SIP</FONT>
<BR><FONT SIZE=2>Use sip-implementors@cs.columbia.edu for questions on current sip</FONT>
<BR><FONT SIZE=2>Use sip@ietf.org for new developments of core SIP</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2BDB0.AFC062F0--
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Fri Jan 17 05:26:10 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17510
	for <sipping-archive@odin.ietf.org>; Fri, 17 Jan 2003 05:26:10 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0HAfhk19261
	for sipping-archive@odin.ietf.org; Fri, 17 Jan 2003 05:41:43 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HAfgJ19258
	for <sipping-web-archive@optimus.ietf.org>; Fri, 17 Jan 2003 05:41:42 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17504
	for <sipping-web-archive@ietf.org>; Fri, 17 Jan 2003 05:25:38 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HAf0J19229;
	Fri, 17 Jan 2003 05:41:00 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HAdgJ19126
	for <sipping@optimus.ietf.org>; Fri, 17 Jan 2003 05:39:42 -0500
Received: from mailgate.siemenscomms.co.uk (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17455
	for <sipping@ietf.org>; Fri, 17 Jan 2003 05:23:37 -0500 (EST)
Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk
 (PMDF V6.0-24 #45905) id <0H8U00H01SZR08@siemenscomms.co.uk> for
 sipping@ietf.org; Fri, 17 Jan 2003 10:26:21 +0000 (GMT)
Received: from beex10.siemenscomms.co.uk ([137.223.246.252])
 by siemenscomms.co.uk (PMDF V6.0-24 #45905)
 with ESMTP id <0H8U00G2ASXUZ9@siemenscomms.co.uk>; Fri,
 17 Jan 2003 10:25:06 +0000 (GMT)
Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21)
	id <C95K618S>; Fri, 17 Jan 2003 10:25:19 +0000
Content-return: allowed
Date: Fri, 17 Jan 2003 10:25:31 +0000
From: "Elwell, John" <john.elwell@siemens.com>
To: "'Mary Barnes'" <mbarnes@nortelnetworks.com>,
        Mark Watson <mwatson@nortelnetworks.com>,
        "'Peterson, Jon'" <jon.peterson@neustar.biz>
Cc: "'sipping@ietf.org'" <sipping@ietf.org>,
        "'fluffy@cisco.com'" <fluffy@cisco.com>
Message-id: <DE9048A49FFFE547BBC42F855DC8CC3740C0A2@beex53.siemenscomms.co.uk>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Content-Transfer-Encoding: 7BIT
Subject: [Sipping] RE: History information privacy requirements
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7BIT
Content-Transfer-Encoding: 7BIT

Mary,

In-line.

Regards,

John
> -----Original Message-----
> From: Mary Barnes [mailto:mbarnes@nortelnetworks.com]
> Sent: 16 January 2003 20:40
> To: 'Elwell, John'; Mark Watson; 'Peterson, Jon'
> Cc: 'sipping@ietf.org'; 'fluffy@cisco.com'
> Subject: RE: History information privacy requirements
> 
> 
> Hi John,
> 
> I do understand your concerns and I think we agree that this is an
> application issue.
> I think what we need to do is to add some text in section 5 
> (and actually I
> think this text should replace what's currently the last 
> paragraph of that
> section) highlighting that there may also be application 
> specific reasons
> for not including the Request History Information in 
> responses, but that the
> these reasons don't impose any additional requirements on the 
> protocol.  I
> think there is alot of overlap with the concerns you have 
> raised and the
> general optionality aspects that are primarily controlled by 
> the application
> and local policy as to whether the information is captured, 
> and if it is
> captured whether it is included in requests beyond that domain or in
> responses, etc. As with the optionality, I think we've 
> previously agreed
> (and documented in the requirements) that the solution does 
> need to provide
> some guidelines as to the aspects which must be addressed by 
> applications
> making use of this capability.  I can add similar wording to 
> section 5.

[JRE] Good. I look forward to that in the next draft.

> 
> As to what's needed in the solution draft to address this, 
> section 2.3.3
> does describe that whether the information is included in the 
> response is
> also based upon local policy, which should thus encompass 
> these privacy
> aspects. 

[JRE] Yes, but there may also be cases where the proxy wishes to include
information in the request sent downstream but not in the response sent
upstream. It is not clear from the existing text that local policy could say
different things for the two directions. Also this may mean intercepting
History-info headers received in responses from downstream entities and
stripping out those that this proxy originally inserted if policy dictates
that they not be sent upstream.

> 
> Mary.
> 
> 
> -----Original Message-----
> From: Elwell, John [mailto:john.elwell@siemens.com]
> Sent: Thursday, January 16, 2003 12:12 PM
> To: Barnes, Mary [NGC:B602:EXCH]; Watson, Mark [MOP:EP10:EXCH];
> 'Peterson, Jon'
> Cc: 'sipping@ietf.org'; 'fluffy@cisco.com'
> Subject: RE: History information privacy requirements
> 
> 
> Mary,
>  
> To pick up on a particular point, you wrote:
>  
> ".... There are examples where the actual DN of a destination isn't
> revealed, but that's all due to application specific logic and not the
> protocols (e.g call centers internally route calls without 
> providing an
> externally dialable destination DN for the agents)...."
>  
> Applying this same principle to SIP, application logic at the 
> proxy could
> determine the retargeted to URI. There may be reasons for not 
> disclosing
> this URI to the caller. Obviously one way to achieve this is 
> to omit history
> information altogether. Then the caller will never discover the
> retargeted-to URI unless the UAS sends it back, but RFC 3323 
> provides the
> UAS with a way of preventing that. However, there may be good 
> reason why the
> proxy will wish to place history information in the request 
> before sending
> it on downstream, e.g., to prevent retrying targets that have 
> already been
> tried, to advise the callee where the call has come from. So 
> there may be a
> requirement to send history information downstream but 
> prevent it going
> upstream back to the caller. Either there has to be a 
> protocol solution to
> indicate this privacy requirement to downstream proxies and 
> the UAS, or the
> retargeting proxy has to be responsible for removing any 
> history information
> that might compromise the privacy requirement. Unfortunately 
> the latter
> works only for a proxy, not a redirect, but perhaps redirection is
> inappropriate in this situation (since the redirection 
> request could reach
> the UAC).
>  
> So even if we say that we don't need protocol enhancements as 
> such, the
> section of the solution document that describes proxy 
> behaviour should point
> out the possible need to remove upstream history information.
>  
> I guess most of the additional privacy requirements I mentioned can be
> solved by appropriate proxy behaviour without requiring any additional
> protocol elements. But I had expected these requirements to 
> be laid down in
> the requirements document and text in the solutions document 
> indicating what
> action needs to be taken to fulfil these requirements.
>  
> Concerning regulatory requirements, these are not my primary 
> concern. Even
> if there is no regulatory requirement governing a certain 
> aspect of privacy,
> there may be business requirements, as in the example above 
> where there is a
> requirement not to reveal the identity of a call centre agent.
>  
> Regards,
>  
> John
> 
> John Elwell
> e-mail: mailto:john.elwell@siemens.com 
> <mailto:john.elwell@siemens.com>  
>  
> ----remainder of thread deleted------
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Fri Jan 17 07:07:28 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18962
	for <sipping-archive@odin.ietf.org>; Fri, 17 Jan 2003 07:07:28 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0HCN2t25254
	for sipping-archive@odin.ietf.org; Fri, 17 Jan 2003 07:23:02 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HCN1J25251
	for <sipping-web-archive@optimus.ietf.org>; Fri, 17 Jan 2003 07:23:01 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18892
	for <sipping-web-archive@ietf.org>; Fri, 17 Jan 2003 07:06:54 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HCLHJ25192;
	Fri, 17 Jan 2003 07:21:17 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HCKvJ25169
	for <sipping@optimus.ietf.org>; Fri, 17 Jan 2003 07:20:57 -0500
Received: from znsgs01r.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18848
	for <sipping@ietf.org>; Fri, 17 Jan 2003 07:04:50 -0500 (EST)
Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124])
	by znsgs01r.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0HC7qK27990;
	Fri, 17 Jan 2003 12:07:52 GMT
Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19)
	id <ZFFSXSSQ>; Fri, 17 Jan 2003 12:07:52 -0000
Message-ID: <A3C2399B2FACD411A54200508BE39C74054F7AE3@zwcwd00r.europe.nortel.com>
From: "Mark Watson" <mwatson@nortelnetworks.com>
To: "'Elwell, John'" <john.elwell@siemens.com>,
        "Mary Barnes" <mbarnes@nortelnetworks.com>,
        "'Peterson, Jon'" <jon.peterson@neustar.biz>
Cc: "'sipping@ietf.org'" <sipping@ietf.org>,
        "'fluffy@cisco.com'"
	 <fluffy@cisco.com>
Date: Fri, 17 Jan 2003 12:07:51 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2BE21.0EE327A2"
Subject: [Sipping] RE: History information privacy requirements
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2BE21.0EE327A2
Content-Type: text/plain;
	charset="iso-8859-1"

John, All,

John suggests there may be a requirement for a proxy to 'strip out'
History-Info from a response as that response goes past. I think we should
be clear that this happens as a result of local policy (related to privacy)
*at the proxy doing the stripping*, and not policy somehow communicated from
elsewhere.

What we need to avoid is cases where a proxy knows there is some privacy
restriction associated with a piece of information, but it includes it in
the message anyway, and 'trusts' a later proxy to remove it. At least this
work should not assume such trust relationships.

I think it would be sufficient for the Request History work to require that
information which is known to be subject to a privacy requirement is just
not sent - and by 'sending' I include passing on received information when
you forward a request/response.

Other work (the generic privacy solution) can provide generic mechanisms for
sending information subject to privacy requirements around the network. Only
two ways to do this:
1) Encrypt it with a key known only to entities 'trusted' to have the
information
2) Send the message (securly) to an entity known to be able to provide the
required privacy protection (i.e. privacy service).

So, as far as Request History goes, do we need to say any more than 'local
policy at a proxy may identify privacy requirements associated with Request
History information. Request History information subject to privacy
requirements shall not be included in outgoing messages unless it is
protected as described in <general privacy mechanism>.'

...Mark

> -----Original Message-----
> From: Elwell, John [mailto:john.elwell@siemens.com]
> Sent: 17 January 2003 10:26
> To: Barnes, Mary [NGC:B602:EXCH]; Watson, Mark [MOP:EP10:EXCH];
> 'Peterson, Jon'
> Cc: 'sipping@ietf.org'; 'fluffy@cisco.com'
> Subject: RE: History information privacy requirements
> 
> 
> Mary,
> 
> In-line.
> 
> Regards,
> 
> John
> > -----Original Message-----
> > From: Mary Barnes [mailto:mbarnes@nortelnetworks.com]
> > Sent: 16 January 2003 20:40
> > To: 'Elwell, John'; Mark Watson; 'Peterson, Jon'
> > Cc: 'sipping@ietf.org'; 'fluffy@cisco.com'
> > Subject: RE: History information privacy requirements
> > 
> > 
> > Hi John,
> > 
> > I do understand your concerns and I think we agree that this is an
> > application issue.
> > I think what we need to do is to add some text in section 5 
> > (and actually I
> > think this text should replace what's currently the last 
> > paragraph of that
> > section) highlighting that there may also be application 
> > specific reasons
> > for not including the Request History Information in 
> > responses, but that the
> > these reasons don't impose any additional requirements on the 
> > protocol.  I
> > think there is alot of overlap with the concerns you have 
> > raised and the
> > general optionality aspects that are primarily controlled by 
> > the application
> > and local policy as to whether the information is captured, 
> > and if it is
> > captured whether it is included in requests beyond that domain or in
> > responses, etc. As with the optionality, I think we've 
> > previously agreed
> > (and documented in the requirements) that the solution does 
> > need to provide
> > some guidelines as to the aspects which must be addressed by 
> > applications
> > making use of this capability.  I can add similar wording to 
> > section 5.
> 
> [JRE] Good. I look forward to that in the next draft.
> 
> > 
> > As to what's needed in the solution draft to address this, 
> > section 2.3.3
> > does describe that whether the information is included in the 
> > response is
> > also based upon local policy, which should thus encompass 
> > these privacy
> > aspects. 
> 
> [JRE] Yes, but there may also be cases where the proxy wishes 
> to include
> information in the request sent downstream but not in the 
> response sent
> upstream. It is not clear from the existing text that local 
> policy could say
> different things for the two directions. Also this may mean 
> intercepting
> History-info headers received in responses from downstream 
> entities and
> stripping out those that this proxy originally inserted if 
> policy dictates
> that they not be sent upstream.
> 
> > 
> > Mary.
> > 
> > 
> > -----Original Message-----
> > From: Elwell, John [mailto:john.elwell@siemens.com]
> > Sent: Thursday, January 16, 2003 12:12 PM
> > To: Barnes, Mary [NGC:B602:EXCH]; Watson, Mark [MOP:EP10:EXCH];
> > 'Peterson, Jon'
> > Cc: 'sipping@ietf.org'; 'fluffy@cisco.com'
> > Subject: RE: History information privacy requirements
> > 
> > 
> > Mary,
> >  
> > To pick up on a particular point, you wrote:
> >  
> > ".... There are examples where the actual DN of a destination isn't
> > revealed, but that's all due to application specific logic 
> and not the
> > protocols (e.g call centers internally route calls without 
> > providing an
> > externally dialable destination DN for the agents)...."
> >  
> > Applying this same principle to SIP, application logic at the 
> > proxy could
> > determine the retargeted to URI. There may be reasons for not 
> > disclosing
> > this URI to the caller. Obviously one way to achieve this is 
> > to omit history
> > information altogether. Then the caller will never discover the
> > retargeted-to URI unless the UAS sends it back, but RFC 3323 
> > provides the
> > UAS with a way of preventing that. However, there may be good 
> > reason why the
> > proxy will wish to place history information in the request 
> > before sending
> > it on downstream, e.g., to prevent retrying targets that have 
> > already been
> > tried, to advise the callee where the call has come from. So 
> > there may be a
> > requirement to send history information downstream but 
> > prevent it going
> > upstream back to the caller. Either there has to be a 
> > protocol solution to
> > indicate this privacy requirement to downstream proxies and 
> > the UAS, or the
> > retargeting proxy has to be responsible for removing any 
> > history information
> > that might compromise the privacy requirement. Unfortunately 
> > the latter
> > works only for a proxy, not a redirect, but perhaps redirection is
> > inappropriate in this situation (since the redirection 
> > request could reach
> > the UAC).
> >  
> > So even if we say that we don't need protocol enhancements as 
> > such, the
> > section of the solution document that describes proxy 
> > behaviour should point
> > out the possible need to remove upstream history information.
> >  
> > I guess most of the additional privacy requirements I 
> mentioned can be
> > solved by appropriate proxy behaviour without requiring any 
> additional
> > protocol elements. But I had expected these requirements to 
> > be laid down in
> > the requirements document and text in the solutions document 
> > indicating what
> > action needs to be taken to fulfil these requirements.
> >  
> > Concerning regulatory requirements, these are not my primary 
> > concern. Even
> > if there is no regulatory requirement governing a certain 
> > aspect of privacy,
> > there may be business requirements, as in the example above 
> > where there is a
> > requirement not to reveal the identity of a call centre agent.
> >  
> > Regards,
> >  
> > John
> > 
> > John Elwell
> > e-mail: mailto:john.elwell@siemens.com 
> > <mailto:john.elwell@siemens.com>  
> >  
> > ----remainder of thread deleted------
> > 
> 

------_=_NextPart_001_01C2BE21.0EE327A2
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>RE: History information privacy requirements</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>John, All,</FONT>
</P>

<P><FONT SIZE=3D2>John suggests there may be a requirement for a proxy =
to 'strip out' History-Info from a response as that response goes past. =
I think we should be clear that this happens as a result of local =
policy (related to privacy) *at the proxy doing the stripping*, and not =
policy somehow communicated from elsewhere.</FONT></P>

<P><FONT SIZE=3D2>What we need to avoid is cases where a proxy knows =
there is some privacy restriction associated with a piece of =
information, but it includes it in the message anyway, and 'trusts' a =
later proxy to remove it. At least this work should not assume such =
trust relationships.</FONT></P>

<P><FONT SIZE=3D2>I think it would be sufficient for the Request =
History work to require that information which is known to be subject =
to a privacy requirement is just not sent - and by 'sending' I include =
passing on received information when you forward a =
request/response.</FONT></P>

<P><FONT SIZE=3D2>Other work (the generic privacy solution) can provide =
generic mechanisms for sending information subject to privacy =
requirements around the network. Only two ways to do this:</FONT></P>

<P><FONT SIZE=3D2>1) Encrypt it with a key known only to entities =
'trusted' to have the information</FONT>
<BR><FONT SIZE=3D2>2) Send the message (securly) to an entity known to =
be able to provide the required privacy protection (i.e. privacy =
service).</FONT></P>

<P><FONT SIZE=3D2>So, as far as Request History goes, do we need to say =
any more than 'local policy at a proxy may identify privacy =
requirements associated with Request History information. Request =
History information subject to privacy requirements shall not be =
included in outgoing messages unless it is protected as described in =
&lt;general privacy mechanism&gt;.'</FONT></P>

<P><FONT SIZE=3D2>...Mark</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Elwell, John [<A =
HREF=3D"mailto:john.elwell@siemens.com">mailto:john.elwell@siemens.com</=
A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: 17 January 2003 10:26</FONT>
<BR><FONT SIZE=3D2>&gt; To: Barnes, Mary [NGC:B602:EXCH]; Watson, Mark =
[MOP:EP10:EXCH];</FONT>
<BR><FONT SIZE=3D2>&gt; 'Peterson, Jon'</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: 'sipping@ietf.org'; =
'fluffy@cisco.com'</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: History information privacy =
requirements</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Mary,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; In-line.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; John</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: Mary Barnes [<A =
HREF=3D"mailto:mbarnes@nortelnetworks.com">mailto:mbarnes@nortelnetworks=
.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: 16 January 2003 20:40</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: 'Elwell, John'; Mark Watson; =
'Peterson, Jon'</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Cc: 'sipping@ietf.org'; =
'fluffy@cisco.com'</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: RE: History information privacy =
requirements</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Hi John,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I do understand your concerns and I think =
we agree that this is an</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; application issue.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I think what we need to do is to add some =
text in section 5 </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; (and actually I</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; think this text should replace what's =
currently the last </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; paragraph of that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; section) highlighting that there may also =
be application </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; specific reasons</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; for not including the Request History =
Information in </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; responses, but that the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; these reasons don't impose any additional =
requirements on the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; protocol.&nbsp; I</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; think there is alot of overlap with the =
concerns you have </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; raised and the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; general optionality aspects that are =
primarily controlled by </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the application</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; and local policy as to whether the =
information is captured, </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; and if it is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; captured whether it is included in =
requests beyond that domain or in</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; responses, etc. As with the optionality, I =
think we've </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; previously agreed</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; (and documented in the requirements) that =
the solution does </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; need to provide</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; some guidelines as to the aspects which =
must be addressed by </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; applications</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; making use of this capability.&nbsp; I can =
add similar wording to </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; section 5.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; [JRE] Good. I look forward to that in the next =
draft.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; As to what's needed in the solution draft =
to address this, </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; section 2.3.3</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; does describe that whether the information =
is included in the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; response is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; also based upon local policy, which should =
thus encompass </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; these privacy</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; aspects. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; [JRE] Yes, but there may also be cases where =
the proxy wishes </FONT>
<BR><FONT SIZE=3D2>&gt; to include</FONT>
<BR><FONT SIZE=3D2>&gt; information in the request sent downstream but =
not in the </FONT>
<BR><FONT SIZE=3D2>&gt; response sent</FONT>
<BR><FONT SIZE=3D2>&gt; upstream. It is not clear from the existing =
text that local </FONT>
<BR><FONT SIZE=3D2>&gt; policy could say</FONT>
<BR><FONT SIZE=3D2>&gt; different things for the two directions. Also =
this may mean </FONT>
<BR><FONT SIZE=3D2>&gt; intercepting</FONT>
<BR><FONT SIZE=3D2>&gt; History-info headers received in responses from =
downstream </FONT>
<BR><FONT SIZE=3D2>&gt; entities and</FONT>
<BR><FONT SIZE=3D2>&gt; stripping out those that this proxy originally =
inserted if </FONT>
<BR><FONT SIZE=3D2>&gt; policy dictates</FONT>
<BR><FONT SIZE=3D2>&gt; that they not be sent upstream.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Mary.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: Elwell, John [<A =
HREF=3D"mailto:john.elwell@siemens.com">mailto:john.elwell@siemens.com</=
A>]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: Thursday, January 16, 2003 12:12 =
PM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: Barnes, Mary [NGC:B602:EXCH]; Watson, =
Mark [MOP:EP10:EXCH];</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 'Peterson, Jon'</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Cc: 'sipping@ietf.org'; =
'fluffy@cisco.com'</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: RE: History information privacy =
requirements</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Mary,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To pick up on a particular point, you =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &quot;.... There are examples where the =
actual DN of a destination isn't</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; revealed, but that's all due to =
application specific logic </FONT>
<BR><FONT SIZE=3D2>&gt; and not the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; protocols (e.g call centers internally =
route calls without </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; providing an</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; externally dialable destination DN for the =
agents)....&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Applying this same principle to SIP, =
application logic at the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; proxy could</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; determine the retargeted to URI. There may =
be reasons for not </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; disclosing</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; this URI to the caller. Obviously one way =
to achieve this is </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; to omit history</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; information altogether. Then the caller =
will never discover the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; retargeted-to URI unless the UAS sends it =
back, but RFC 3323 </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; provides the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; UAS with a way of preventing that. =
However, there may be good </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; reason why the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; proxy will wish to place history =
information in the request </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; before sending</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; it on downstream, e.g., to prevent =
retrying targets that have </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; already been</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; tried, to advise the callee where the call =
has come from. So </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; there may be a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; requirement to send history information =
downstream but </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; prevent it going</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; upstream back to the caller. Either there =
has to be a </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; protocol solution to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; indicate this privacy requirement to =
downstream proxies and </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the UAS, or the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; retargeting proxy has to be responsible =
for removing any </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; history information</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; that might compromise the privacy =
requirement. Unfortunately </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the latter</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; works only for a proxy, not a redirect, =
but perhaps redirection is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; inappropriate in this situation (since the =
redirection </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; request could reach</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the UAC).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; So even if we say that we don't need =
protocol enhancements as </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; such, the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; section of the solution document that =
describes proxy </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; behaviour should point</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; out the possible need to remove upstream =
history information.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I guess most of the additional privacy =
requirements I </FONT>
<BR><FONT SIZE=3D2>&gt; mentioned can be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; solved by appropriate proxy behaviour =
without requiring any </FONT>
<BR><FONT SIZE=3D2>&gt; additional</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; protocol elements. But I had expected =
these requirements to </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; be laid down in</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the requirements document and text in the =
solutions document </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; indicating what</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; action needs to be taken to fulfil these =
requirements.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Concerning regulatory requirements, these =
are not my primary </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; concern. Even</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; if there is no regulatory requirement =
governing a certain </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; aspect of privacy,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; there may be business requirements, as in =
the example above </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; where there is a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; requirement not to reveal the identity of =
a call centre agent.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; John</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; John Elwell</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; e-mail: <A =
HREF=3D"mailto:john.elwell@siemens.com">mailto:john.elwell@siemens.com</=
A> </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &lt;<A =
HREF=3D"mailto:john.elwell@siemens.com">mailto:john.elwell@siemens.com</=
A>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; ----remainder of thread =
deleted------</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2BE21.0EE327A2--
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Fri Jan 17 12:37:04 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29451
	for <sipping-archive@odin.ietf.org>; Fri, 17 Jan 2003 12:37:04 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0HHqi217445
	for sipping-archive@odin.ietf.org; Fri, 17 Jan 2003 12:52:44 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HHqiJ17442
	for <sipping-web-archive@optimus.ietf.org>; Fri, 17 Jan 2003 12:52:44 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29423
	for <sipping-web-archive@ietf.org>; Fri, 17 Jan 2003 12:36:32 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HHpiJ17395;
	Fri, 17 Jan 2003 12:51:44 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HHncJ17279
	for <sipping@optimus.ietf.org>; Fri, 17 Jan 2003 12:49:38 -0500
Received: from mailgate.siemenscomms.co.uk (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29349
	for <sipping@ietf.org>; Fri, 17 Jan 2003 12:33:24 -0500 (EST)
Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk
 (PMDF V6.0-24 #45905) id <0H8V00601CWXD0@siemenscomms.co.uk> for
 sipping@ietf.org; Fri, 17 Jan 2003 17:36:33 +0000 (GMT)
Received: from beex10.siemenscomms.co.uk ([137.223.246.252])
 by siemenscomms.co.uk (PMDF V6.0-24 #45905)
 with ESMTP id <0H8V005LTCWW23@siemenscomms.co.uk>; Fri,
 17 Jan 2003 17:36:32 +0000 (GMT)
Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21)
	id <DD80L7PP>; Fri, 17 Jan 2003 17:36:46 +0000
Content-return: allowed
Date: Fri, 17 Jan 2003 17:36:52 +0000
From: "Elwell, John" <john.elwell@siemens.com>
To: "'Mark Watson'" <mwatson@nortelnetworks.com>,
        Mary Barnes <mbarnes@nortelnetworks.com>,
        "'Peterson, Jon'" <jon.peterson@neustar.biz>
Cc: "'sipping@ietf.org'" <sipping@ietf.org>,
        "'fluffy@cisco.com'" <fluffy@cisco.com>
Message-id: <DE9048A49FFFE547BBC42F855DC8CC3740C0A6@beex53.siemenscomms.co.uk>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Content-Transfer-Encoding: 7BIT
Subject: [Sipping] RE: History information privacy requirements
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7BIT
Content-Transfer-Encoding: 7BIT

Mark,
 
Although I think we have agreement on the general principles, I am still
concerned that the text you propose does not explicitly mention removing
information from responses.
 
Regards,
 
John

-----Original Message-----
From: Mark Watson [mailto:mwatson@nortelnetworks.com]
Sent: 17 January 2003 12:08
To: 'Elwell, John'; Mary Barnes; 'Peterson, Jon'
Cc: 'sipping@ietf.org'; 'fluffy@cisco.com'
Subject: RE: History information privacy requirements



John, All, 

John suggests there may be a requirement for a proxy to 'strip out'
History-Info from a response as that response goes past. I think we should
be clear that this happens as a result of local policy (related to privacy)
*at the proxy doing the stripping*, and not policy somehow communicated from
elsewhere.

What we need to avoid is cases where a proxy knows there is some privacy
restriction associated with a piece of information, but it includes it in
the message anyway, and 'trusts' a later proxy to remove it. At least this
work should not assume such trust relationships.

I think it would be sufficient for the Request History work to require that
information which is known to be subject to a privacy requirement is just
not sent - and by 'sending' I include passing on received information when
you forward a request/response.

Other work (the generic privacy solution) can provide generic mechanisms for
sending information subject to privacy requirements around the network. Only
two ways to do this:

1) Encrypt it with a key known only to entities 'trusted' to have the
information 
2) Send the message (securly) to an entity known to be able to provide the
required privacy protection (i.e. privacy service).

So, as far as Request History goes, do we need to say any more than 'local
policy at a proxy may identify privacy requirements associated with Request
History information. Request History information subject to privacy
requirements shall not be included in outgoing messages unless it is
protected as described in <general privacy mechanism>.'

...Mark 

> -----Original Message----- 
> From: Elwell, John [ mailto:john.elwell@siemens.com
<mailto:john.elwell@siemens.com> ] 
> Sent: 17 January 2003 10:26 
> To: Barnes, Mary [NGC:B602:EXCH]; Watson, Mark [MOP:EP10:EXCH]; 
> 'Peterson, Jon' 
> Cc: 'sipping@ietf.org'; 'fluffy@cisco.com' 
> Subject: RE: History information privacy requirements 
> 
> 
> Mary, 
> 
> In-line. 
> 
> Regards, 
> 
> John 
> > -----Original Message----- 
> > From: Mary Barnes [ mailto:mbarnes@nortelnetworks.com
<mailto:mbarnes@nortelnetworks.com> ] 
> > Sent: 16 January 2003 20:40 
> > To: 'Elwell, John'; Mark Watson; 'Peterson, Jon' 
> > Cc: 'sipping@ietf.org'; 'fluffy@cisco.com' 
> > Subject: RE: History information privacy requirements 
> > 
> > 
> > Hi John, 
> > 
> > I do understand your concerns and I think we agree that this is an 
> > application issue. 
> > I think what we need to do is to add some text in section 5 
> > (and actually I 
> > think this text should replace what's currently the last 
> > paragraph of that 
> > section) highlighting that there may also be application 
> > specific reasons 
> > for not including the Request History Information in 
> > responses, but that the 
> > these reasons don't impose any additional requirements on the 
> > protocol.  I 
> > think there is alot of overlap with the concerns you have 
> > raised and the 
> > general optionality aspects that are primarily controlled by 
> > the application 
> > and local policy as to whether the information is captured, 
> > and if it is 
> > captured whether it is included in requests beyond that domain or in 
> > responses, etc. As with the optionality, I think we've 
> > previously agreed 
> > (and documented in the requirements) that the solution does 
> > need to provide 
> > some guidelines as to the aspects which must be addressed by 
> > applications 
> > making use of this capability.  I can add similar wording to 
> > section 5. 
> 
> [JRE] Good. I look forward to that in the next draft. 
> 
> > 
> > As to what's needed in the solution draft to address this, 
> > section 2.3.3 
> > does describe that whether the information is included in the 
> > response is 
> > also based upon local policy, which should thus encompass 
> > these privacy 
> > aspects. 
> 
> [JRE] Yes, but there may also be cases where the proxy wishes 
> to include 
> information in the request sent downstream but not in the 
> response sent 
> upstream. It is not clear from the existing text that local 
> policy could say 
> different things for the two directions. Also this may mean 
> intercepting 
> History-info headers received in responses from downstream 
> entities and 
> stripping out those that this proxy originally inserted if 
> policy dictates 
> that they not be sent upstream. 
> 
> > 
> > Mary. 
> > 
> > 
> > -----Original Message----- 
> > From: Elwell, John [ mailto:john.elwell@siemens.com
<mailto:john.elwell@siemens.com> ] 
> > Sent: Thursday, January 16, 2003 12:12 PM 
> > To: Barnes, Mary [NGC:B602:EXCH]; Watson, Mark [MOP:EP10:EXCH]; 
> > 'Peterson, Jon' 
> > Cc: 'sipping@ietf.org'; 'fluffy@cisco.com' 
> > Subject: RE: History information privacy requirements 
> > 
> > 
> > Mary, 
> >  
> > To pick up on a particular point, you wrote: 
> >  
> > ".... There are examples where the actual DN of a destination isn't 
> > revealed, but that's all due to application specific logic 
> and not the 
> > protocols (e.g call centers internally route calls without 
> > providing an 
> > externally dialable destination DN for the agents)...." 
> >  
> > Applying this same principle to SIP, application logic at the 
> > proxy could 
> > determine the retargeted to URI. There may be reasons for not 
> > disclosing 
> > this URI to the caller. Obviously one way to achieve this is 
> > to omit history 
> > information altogether. Then the caller will never discover the 
> > retargeted-to URI unless the UAS sends it back, but RFC 3323 
> > provides the 
> > UAS with a way of preventing that. However, there may be good 
> > reason why the 
> > proxy will wish to place history information in the request 
> > before sending 
> > it on downstream, e.g., to prevent retrying targets that have 
> > already been 
> > tried, to advise the callee where the call has come from. So 
> > there may be a 
> > requirement to send history information downstream but 
> > prevent it going 
> > upstream back to the caller. Either there has to be a 
> > protocol solution to 
> > indicate this privacy requirement to downstream proxies and 
> > the UAS, or the 
> > retargeting proxy has to be responsible for removing any 
> > history information 
> > that might compromise the privacy requirement. Unfortunately 
> > the latter 
> > works only for a proxy, not a redirect, but perhaps redirection is 
> > inappropriate in this situation (since the redirection 
> > request could reach 
> > the UAC). 
> >  
> > So even if we say that we don't need protocol enhancements as 
> > such, the 
> > section of the solution document that describes proxy 
> > behaviour should point 
> > out the possible need to remove upstream history information. 
> >  
> > I guess most of the additional privacy requirements I 
> mentioned can be 
> > solved by appropriate proxy behaviour without requiring any 
> additional 
> > protocol elements. But I had expected these requirements to 
> > be laid down in 
> > the requirements document and text in the solutions document 
> > indicating what 
> > action needs to be taken to fulfil these requirements. 
> >  
> > Concerning regulatory requirements, these are not my primary 
> > concern. Even 
> > if there is no regulatory requirement governing a certain 
> > aspect of privacy, 
> > there may be business requirements, as in the example above 
> > where there is a 
> > requirement not to reveal the identity of a call centre agent. 
> >  
> > Regards, 
> >  
> > John 
> > 
> > John Elwell 
> > e-mail: mailto:john.elwell@siemens.com <mailto:john.elwell@siemens.com>

> > < mailto:john.elwell@siemens.com <mailto:john.elwell@siemens.com> >  
> >  
> > ----remainder of thread deleted------ 
> > 
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Fri Jan 17 12:42:42 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29551
	for <sipping-archive@odin.ietf.org>; Fri, 17 Jan 2003 12:42:42 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0HHwN217782
	for sipping-archive@odin.ietf.org; Fri, 17 Jan 2003 12:58:23 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HHwMJ17779
	for <sipping-web-archive@optimus.ietf.org>; Fri, 17 Jan 2003 12:58:22 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29544
	for <sipping-web-archive@ietf.org>; Fri, 17 Jan 2003 12:42:08 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HHv6J17689;
	Fri, 17 Jan 2003 12:57:06 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HHuDJ17598
	for <sipping@optimus.ietf.org>; Fri, 17 Jan 2003 12:56:13 -0500
Received: from znsgs01r.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29513
	for <sipping@ietf.org>; Fri, 17 Jan 2003 12:39:59 -0500 (EST)
Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124])
	by znsgs01r.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0HHhCK00113;
	Fri, 17 Jan 2003 17:43:12 GMT
Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19)
	id <ZFFSX96V>; Fri, 17 Jan 2003 17:43:12 -0000
Message-ID: <A3C2399B2FACD411A54200508BE39C74054F7AEC@zwcwd00r.europe.nortel.com>
From: "Mark Watson" <mwatson@nortelnetworks.com>
To: "'Elwell, John'" <john.elwell@siemens.com>,
        "Mary Barnes" <mbarnes@nortelnetworks.com>,
        "'Peterson, Jon'" <jon.peterson@neustar.biz>
Cc: "'sipping@ietf.org'" <sipping@ietf.org>,
        "'fluffy@cisco.com'"
	 <fluffy@cisco.com>
Date: Fri, 17 Jan 2003 17:43:12 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2BE4F.AB8D0A9A"
Subject: [Sipping] RE: History information privacy requirements
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2BE4F.AB8D0A9A
Content-Type: text/plain;
	charset="iso-8859-1"

Well, a response is an 'outgoing message' from the UAS and every proxy it
passes through. So the text below certainly includes removing information
from a response. This would occur if a proxy was aware of some privacy
requirement for the information that the original sender & other proxies in
the path was not aware of.

...Mark

> -----Original Message-----
> From: Elwell, John [mailto:john.elwell@siemens.com]
> Sent: 17 January 2003 17:37
> To: Watson, Mark [MOP:EP10:EXCH]; Barnes, Mary [NGC:B602:EXCH];
> 'Peterson, Jon'
> Cc: 'sipping@ietf.org'; 'fluffy@cisco.com'
> Subject: RE: History information privacy requirements
> 
> 
> Mark,
>  
> Although I think we have agreement on the general principles, 
> I am still
> concerned that the text you propose does not explicitly 
> mention removing
> information from responses.
>  
> Regards,
>  
> John
> 
> -----Original Message-----
> From: Mark Watson [mailto:mwatson@nortelnetworks.com]
> Sent: 17 January 2003 12:08
> To: 'Elwell, John'; Mary Barnes; 'Peterson, Jon'
> Cc: 'sipping@ietf.org'; 'fluffy@cisco.com'
> Subject: RE: History information privacy requirements
> 
> 
> 
> John, All, 
> 
> John suggests there may be a requirement for a proxy to 'strip out'
> History-Info from a response as that response goes past. I 
> think we should
> be clear that this happens as a result of local policy 
> (related to privacy)
> *at the proxy doing the stripping*, and not policy somehow 
> communicated from
> elsewhere.
> 
> What we need to avoid is cases where a proxy knows there is 
> some privacy
> restriction associated with a piece of information, but it 
> includes it in
> the message anyway, and 'trusts' a later proxy to remove it. 
> At least this
> work should not assume such trust relationships.
> 
> I think it would be sufficient for the Request History work 
> to require that
> information which is known to be subject to a privacy 
> requirement is just
> not sent - and by 'sending' I include passing on received 
> information when
> you forward a request/response.
> 
> Other work (the generic privacy solution) can provide generic 
> mechanisms for
> sending information subject to privacy requirements around 
> the network. Only
> two ways to do this:
> 
> 1) Encrypt it with a key known only to entities 'trusted' to have the
> information 
> 2) Send the message (securly) to an entity known to be able 
> to provide the
> required privacy protection (i.e. privacy service).
> 
> So, as far as Request History goes, do we need to say any 
> more than 'local
> policy at a proxy may identify privacy requirements 
> associated with Request
> History information. Request History information subject to privacy
> requirements shall not be included in outgoing messages unless it is
> protected as described in <general privacy mechanism>.'
> 
> ...Mark 
> 
> > -----Original Message----- 
> > From: Elwell, John [ mailto:john.elwell@siemens.com
> <mailto:john.elwell@siemens.com> ] 
> > Sent: 17 January 2003 10:26 
> > To: Barnes, Mary [NGC:B602:EXCH]; Watson, Mark [MOP:EP10:EXCH]; 
> > 'Peterson, Jon' 
> > Cc: 'sipping@ietf.org'; 'fluffy@cisco.com' 
> > Subject: RE: History information privacy requirements 
> > 
> > 
> > Mary, 
> > 
> > In-line. 
> > 
> > Regards, 
> > 
> > John 
> > > -----Original Message----- 
> > > From: Mary Barnes [ mailto:mbarnes@nortelnetworks.com
> <mailto:mbarnes@nortelnetworks.com> ] 
> > > Sent: 16 January 2003 20:40 
> > > To: 'Elwell, John'; Mark Watson; 'Peterson, Jon' 
> > > Cc: 'sipping@ietf.org'; 'fluffy@cisco.com' 
> > > Subject: RE: History information privacy requirements 
> > > 
> > > 
> > > Hi John, 
> > > 
> > > I do understand your concerns and I think we agree that 
> this is an 
> > > application issue. 
> > > I think what we need to do is to add some text in section 5 
> > > (and actually I 
> > > think this text should replace what's currently the last 
> > > paragraph of that 
> > > section) highlighting that there may also be application 
> > > specific reasons 
> > > for not including the Request History Information in 
> > > responses, but that the 
> > > these reasons don't impose any additional requirements on the 
> > > protocol.  I 
> > > think there is alot of overlap with the concerns you have 
> > > raised and the 
> > > general optionality aspects that are primarily controlled by 
> > > the application 
> > > and local policy as to whether the information is captured, 
> > > and if it is 
> > > captured whether it is included in requests beyond that 
> domain or in 
> > > responses, etc. As with the optionality, I think we've 
> > > previously agreed 
> > > (and documented in the requirements) that the solution does 
> > > need to provide 
> > > some guidelines as to the aspects which must be addressed by 
> > > applications 
> > > making use of this capability.  I can add similar wording to 
> > > section 5. 
> > 
> > [JRE] Good. I look forward to that in the next draft. 
> > 
> > > 
> > > As to what's needed in the solution draft to address this, 
> > > section 2.3.3 
> > > does describe that whether the information is included in the 
> > > response is 
> > > also based upon local policy, which should thus encompass 
> > > these privacy 
> > > aspects. 
> > 
> > [JRE] Yes, but there may also be cases where the proxy wishes 
> > to include 
> > information in the request sent downstream but not in the 
> > response sent 
> > upstream. It is not clear from the existing text that local 
> > policy could say 
> > different things for the two directions. Also this may mean 
> > intercepting 
> > History-info headers received in responses from downstream 
> > entities and 
> > stripping out those that this proxy originally inserted if 
> > policy dictates 
> > that they not be sent upstream. 
> > 
> > > 
> > > Mary. 
> > > 
> > > 
> > > -----Original Message----- 
> > > From: Elwell, John [ mailto:john.elwell@siemens.com
> <mailto:john.elwell@siemens.com> ] 
> > > Sent: Thursday, January 16, 2003 12:12 PM 
> > > To: Barnes, Mary [NGC:B602:EXCH]; Watson, Mark [MOP:EP10:EXCH]; 
> > > 'Peterson, Jon' 
> > > Cc: 'sipping@ietf.org'; 'fluffy@cisco.com' 
> > > Subject: RE: History information privacy requirements 
> > > 
> > > 
> > > Mary, 
> > >  
> > > To pick up on a particular point, you wrote: 
> > >  
> > > ".... There are examples where the actual DN of a 
> destination isn't 
> > > revealed, but that's all due to application specific logic 
> > and not the 
> > > protocols (e.g call centers internally route calls without 
> > > providing an 
> > > externally dialable destination DN for the agents)...." 
> > >  
> > > Applying this same principle to SIP, application logic at the 
> > > proxy could 
> > > determine the retargeted to URI. There may be reasons for not 
> > > disclosing 
> > > this URI to the caller. Obviously one way to achieve this is 
> > > to omit history 
> > > information altogether. Then the caller will never discover the 
> > > retargeted-to URI unless the UAS sends it back, but RFC 3323 
> > > provides the 
> > > UAS with a way of preventing that. However, there may be good 
> > > reason why the 
> > > proxy will wish to place history information in the request 
> > > before sending 
> > > it on downstream, e.g., to prevent retrying targets that have 
> > > already been 
> > > tried, to advise the callee where the call has come from. So 
> > > there may be a 
> > > requirement to send history information downstream but 
> > > prevent it going 
> > > upstream back to the caller. Either there has to be a 
> > > protocol solution to 
> > > indicate this privacy requirement to downstream proxies and 
> > > the UAS, or the 
> > > retargeting proxy has to be responsible for removing any 
> > > history information 
> > > that might compromise the privacy requirement. Unfortunately 
> > > the latter 
> > > works only for a proxy, not a redirect, but perhaps 
> redirection is 
> > > inappropriate in this situation (since the redirection 
> > > request could reach 
> > > the UAC). 
> > >  
> > > So even if we say that we don't need protocol enhancements as 
> > > such, the 
> > > section of the solution document that describes proxy 
> > > behaviour should point 
> > > out the possible need to remove upstream history information. 
> > >  
> > > I guess most of the additional privacy requirements I 
> > mentioned can be 
> > > solved by appropriate proxy behaviour without requiring any 
> > additional 
> > > protocol elements. But I had expected these requirements to 
> > > be laid down in 
> > > the requirements document and text in the solutions document 
> > > indicating what 
> > > action needs to be taken to fulfil these requirements. 
> > >  
> > > Concerning regulatory requirements, these are not my primary 
> > > concern. Even 
> > > if there is no regulatory requirement governing a certain 
> > > aspect of privacy, 
> > > there may be business requirements, as in the example above 
> > > where there is a 
> > > requirement not to reveal the identity of a call centre agent. 
> > >  
> > > Regards, 
> > >  
> > > John 
> > > 
> > > John Elwell 
> > > e-mail: mailto:john.elwell@siemens.com 
> <mailto:john.elwell@siemens.com>
> 
> > > < mailto:john.elwell@siemens.com 
> <mailto:john.elwell@siemens.com> >  
> > >  
> > > ----remainder of thread deleted------ 
> > > 
> > 
> 
> 

------_=_NextPart_001_01C2BE4F.AB8D0A9A
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>RE: History information privacy requirements</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Well, a response is an 'outgoing message' from the =
UAS and every proxy it passes through. So the text below certainly =
includes removing information from a response. This would occur if a =
proxy was aware of some privacy requirement for the information that =
the original sender &amp; other proxies in the path was not aware =
of.</FONT></P>

<P><FONT SIZE=3D2>...Mark</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Elwell, John [<A =
HREF=3D"mailto:john.elwell@siemens.com">mailto:john.elwell@siemens.com</=
A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: 17 January 2003 17:37</FONT>
<BR><FONT SIZE=3D2>&gt; To: Watson, Mark [MOP:EP10:EXCH]; Barnes, Mary =
[NGC:B602:EXCH];</FONT>
<BR><FONT SIZE=3D2>&gt; 'Peterson, Jon'</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: 'sipping@ietf.org'; =
'fluffy@cisco.com'</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: History information privacy =
requirements</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Mark,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; Although I think we have agreement on the =
general principles, </FONT>
<BR><FONT SIZE=3D2>&gt; I am still</FONT>
<BR><FONT SIZE=3D2>&gt; concerned that the text you propose does not =
explicitly </FONT>
<BR><FONT SIZE=3D2>&gt; mention removing</FONT>
<BR><FONT SIZE=3D2>&gt; information from responses.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; John</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Mark Watson [<A =
HREF=3D"mailto:mwatson@nortelnetworks.com">mailto:mwatson@nortelnetworks=
.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: 17 January 2003 12:08</FONT>
<BR><FONT SIZE=3D2>&gt; To: 'Elwell, John'; Mary Barnes; 'Peterson, =
Jon'</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: 'sipping@ietf.org'; =
'fluffy@cisco.com'</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: History information privacy =
requirements</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; John, All, </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; John suggests there may be a requirement for a =
proxy to 'strip out'</FONT>
<BR><FONT SIZE=3D2>&gt; History-Info from a response as that response =
goes past. I </FONT>
<BR><FONT SIZE=3D2>&gt; think we should</FONT>
<BR><FONT SIZE=3D2>&gt; be clear that this happens as a result of local =
policy </FONT>
<BR><FONT SIZE=3D2>&gt; (related to privacy)</FONT>
<BR><FONT SIZE=3D2>&gt; *at the proxy doing the stripping*, and not =
policy somehow </FONT>
<BR><FONT SIZE=3D2>&gt; communicated from</FONT>
<BR><FONT SIZE=3D2>&gt; elsewhere.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; What we need to avoid is cases where a proxy =
knows there is </FONT>
<BR><FONT SIZE=3D2>&gt; some privacy</FONT>
<BR><FONT SIZE=3D2>&gt; restriction associated with a piece of =
information, but it </FONT>
<BR><FONT SIZE=3D2>&gt; includes it in</FONT>
<BR><FONT SIZE=3D2>&gt; the message anyway, and 'trusts' a later proxy =
to remove it. </FONT>
<BR><FONT SIZE=3D2>&gt; At least this</FONT>
<BR><FONT SIZE=3D2>&gt; work should not assume such trust =
relationships.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I think it would be sufficient for the Request =
History work </FONT>
<BR><FONT SIZE=3D2>&gt; to require that</FONT>
<BR><FONT SIZE=3D2>&gt; information which is known to be subject to a =
privacy </FONT>
<BR><FONT SIZE=3D2>&gt; requirement is just</FONT>
<BR><FONT SIZE=3D2>&gt; not sent - and by 'sending' I include passing =
on received </FONT>
<BR><FONT SIZE=3D2>&gt; information when</FONT>
<BR><FONT SIZE=3D2>&gt; you forward a request/response.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Other work (the generic privacy solution) can =
provide generic </FONT>
<BR><FONT SIZE=3D2>&gt; mechanisms for</FONT>
<BR><FONT SIZE=3D2>&gt; sending information subject to privacy =
requirements around </FONT>
<BR><FONT SIZE=3D2>&gt; the network. Only</FONT>
<BR><FONT SIZE=3D2>&gt; two ways to do this:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 1) Encrypt it with a key known only to entities =
'trusted' to have the</FONT>
<BR><FONT SIZE=3D2>&gt; information </FONT>
<BR><FONT SIZE=3D2>&gt; 2) Send the message (securly) to an entity =
known to be able </FONT>
<BR><FONT SIZE=3D2>&gt; to provide the</FONT>
<BR><FONT SIZE=3D2>&gt; required privacy protection (i.e. privacy =
service).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; So, as far as Request History goes, do we need =
to say any </FONT>
<BR><FONT SIZE=3D2>&gt; more than 'local</FONT>
<BR><FONT SIZE=3D2>&gt; policy at a proxy may identify privacy =
requirements </FONT>
<BR><FONT SIZE=3D2>&gt; associated with Request</FONT>
<BR><FONT SIZE=3D2>&gt; History information. Request History =
information subject to privacy</FONT>
<BR><FONT SIZE=3D2>&gt; requirements shall not be included in outgoing =
messages unless it is</FONT>
<BR><FONT SIZE=3D2>&gt; protected as described in &lt;general privacy =
mechanism&gt;.'</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; ...Mark </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message----- </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: Elwell, John [ <A =
HREF=3D"mailto:john.elwell@siemens.com">mailto:john.elwell@siemens.com</=
A></FONT>
<BR><FONT SIZE=3D2>&gt; &lt;<A =
HREF=3D"mailto:john.elwell@siemens.com">mailto:john.elwell@siemens.com</=
A>&gt; ] </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: 17 January 2003 10:26 </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: Barnes, Mary [NGC:B602:EXCH]; Watson, =
Mark [MOP:EP10:EXCH]; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 'Peterson, Jon' </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Cc: 'sipping@ietf.org'; 'fluffy@cisco.com' =
</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: RE: History information privacy =
requirements </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Mary, </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; In-line. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Regards, </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; John </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; -----Original Message----- </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; From: Mary Barnes [ <A =
HREF=3D"mailto:mbarnes@nortelnetworks.com">mailto:mbarnes@nortelnetworks=
.com</A></FONT>
<BR><FONT SIZE=3D2>&gt; &lt;<A =
HREF=3D"mailto:mbarnes@nortelnetworks.com">mailto:mbarnes@nortelnetworks=
.com</A>&gt; ] </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Sent: 16 January 2003 20:40 </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; To: 'Elwell, John'; Mark Watson; =
'Peterson, Jon' </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Cc: 'sipping@ietf.org'; =
'fluffy@cisco.com' </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Subject: RE: History information =
privacy requirements </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Hi John, </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; I do understand your concerns and I =
think we agree that </FONT>
<BR><FONT SIZE=3D2>&gt; this is an </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; application issue. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; I think what we need to do is to add =
some text in section 5 </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; (and actually I </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; think this text should replace what's =
currently the last </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; paragraph of that </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; section) highlighting that there may =
also be application </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; specific reasons </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; for not including the Request History =
Information in </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; responses, but that the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; these reasons don't impose any =
additional requirements on the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; protocol.&nbsp; I </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; think there is alot of overlap with =
the concerns you have </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; raised and the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; general optionality aspects that are =
primarily controlled by </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; the application </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; and local policy as to whether the =
information is captured, </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; and if it is </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; captured whether it is included in =
requests beyond that </FONT>
<BR><FONT SIZE=3D2>&gt; domain or in </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; responses, etc. As with the =
optionality, I think we've </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; previously agreed </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; (and documented in the requirements) =
that the solution does </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; need to provide </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; some guidelines as to the aspects =
which must be addressed by </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; applications </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; making use of this capability.&nbsp; =
I can add similar wording to </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; section 5. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; [JRE] Good. I look forward to that in the =
next draft. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; As to what's needed in the solution =
draft to address this, </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; section 2.3.3 </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; does describe that whether the =
information is included in the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; response is </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; also based upon local policy, which =
should thus encompass </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; these privacy </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; aspects. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; [JRE] Yes, but there may also be cases =
where the proxy wishes </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; to include </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; information in the request sent downstream =
but not in the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; response sent </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; upstream. It is not clear from the =
existing text that local </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; policy could say </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; different things for the two directions. =
Also this may mean </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; intercepting </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; History-info headers received in responses =
from downstream </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; entities and </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; stripping out those that this proxy =
originally inserted if </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; policy dictates </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; that they not be sent upstream. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Mary. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; -----Original Message----- </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; From: Elwell, John [ <A =
HREF=3D"mailto:john.elwell@siemens.com">mailto:john.elwell@siemens.com</=
A></FONT>
<BR><FONT SIZE=3D2>&gt; &lt;<A =
HREF=3D"mailto:john.elwell@siemens.com">mailto:john.elwell@siemens.com</=
A>&gt; ] </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Sent: Thursday, January 16, 2003 =
12:12 PM </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; To: Barnes, Mary [NGC:B602:EXCH]; =
Watson, Mark [MOP:EP10:EXCH]; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; 'Peterson, Jon' </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Cc: 'sipping@ietf.org'; =
'fluffy@cisco.com' </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Subject: RE: History information =
privacy requirements </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Mary, </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; To pick up on a particular point, you =
wrote: </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &quot;.... There are examples where =
the actual DN of a </FONT>
<BR><FONT SIZE=3D2>&gt; destination isn't </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; revealed, but that's all due to =
application specific logic </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; and not the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; protocols (e.g call centers =
internally route calls without </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; providing an </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; externally dialable destination DN =
for the agents)....&quot; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Applying this same principle to SIP, =
application logic at the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; proxy could </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; determine the retargeted to URI. =
There may be reasons for not </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; disclosing </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; this URI to the caller. Obviously one =
way to achieve this is </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; to omit history </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; information altogether. Then the =
caller will never discover the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; retargeted-to URI unless the UAS =
sends it back, but RFC 3323 </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; provides the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; UAS with a way of preventing that. =
However, there may be good </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; reason why the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; proxy will wish to place history =
information in the request </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; before sending </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; it on downstream, e.g., to prevent =
retrying targets that have </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; already been </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; tried, to advise the callee where the =
call has come from. So </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; there may be a </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; requirement to send history =
information downstream but </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; prevent it going </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; upstream back to the caller. Either =
there has to be a </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; protocol solution to </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; indicate this privacy requirement to =
downstream proxies and </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; the UAS, or the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; retargeting proxy has to be =
responsible for removing any </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; history information </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; that might compromise the privacy =
requirement. Unfortunately </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; the latter </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; works only for a proxy, not a =
redirect, but perhaps </FONT>
<BR><FONT SIZE=3D2>&gt; redirection is </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; inappropriate in this situation =
(since the redirection </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; request could reach </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; the UAC). </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; So even if we say that we don't need =
protocol enhancements as </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; such, the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; section of the solution document that =
describes proxy </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; behaviour should point </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; out the possible need to remove =
upstream history information. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; I guess most of the additional =
privacy requirements I </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; mentioned can be </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; solved by appropriate proxy behaviour =
without requiring any </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; additional </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; protocol elements. But I had expected =
these requirements to </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; be laid down in </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; the requirements document and text in =
the solutions document </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; indicating what </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; action needs to be taken to fulfil =
these requirements. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Concerning regulatory requirements, =
these are not my primary </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; concern. Even </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; if there is no regulatory requirement =
governing a certain </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; aspect of privacy, </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; there may be business requirements, =
as in the example above </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; where there is a </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; requirement not to reveal the =
identity of a call centre agent. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Regards, </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; John </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; John Elwell </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; e-mail: <A =
HREF=3D"mailto:john.elwell@siemens.com">mailto:john.elwell@siemens.com</=
A> </FONT>
<BR><FONT SIZE=3D2>&gt; &lt;<A =
HREF=3D"mailto:john.elwell@siemens.com">mailto:john.elwell@siemens.com</=
A>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &lt; <A =
HREF=3D"mailto:john.elwell@siemens.com">mailto:john.elwell@siemens.com</=
A> </FONT>
<BR><FONT SIZE=3D2>&gt; &lt;<A =
HREF=3D"mailto:john.elwell@siemens.com">mailto:john.elwell@siemens.com</=
A>&gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; ----remainder of thread deleted------ =
</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2BE4F.AB8D0A9A--
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan 20 03:47:15 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14221
	for <sipping-archive@odin.ietf.org>; Mon, 20 Jan 2003 03:47:15 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0K94Dc02448
	for sipping-archive@odin.ietf.org; Mon, 20 Jan 2003 04:04:13 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0K94CJ02445
	for <sipping-web-archive@optimus.ietf.org>; Mon, 20 Jan 2003 04:04:12 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14208
	for <sipping-web-archive@ietf.org>; Mon, 20 Jan 2003 03:46:42 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0K92fJ02372;
	Mon, 20 Jan 2003 04:02:41 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0K8oWJ01592
	for <sipping@optimus.ietf.org>; Mon, 20 Jan 2003 03:50:32 -0500
Received: from mailgate.siemenscomms.co.uk (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13972
	for <sipping@ietf.org>; Mon, 20 Jan 2003 03:33:03 -0500 (EST)
Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk
 (PMDF V6.0-24 #45905) id <0H90004017WAQO@siemenscomms.co.uk> for
 sipping@ietf.org; Mon, 20 Jan 2003 08:36:10 +0000 (GMT)
Received: from beex10.siemenscomms.co.uk ([137.223.246.252])
 by siemenscomms.co.uk (PMDF V6.0-24 #45905)
 with ESMTP id <0H90003FI7W978@siemenscomms.co.uk>; Mon,
 20 Jan 2003 08:36:10 +0000 (GMT)
Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21)
	id <DD80MDLH>; Mon, 20 Jan 2003 08:36:26 +0000
Content-return: allowed
Date: Mon, 20 Jan 2003 08:36:33 +0000
From: "Elwell, John" <john.elwell@siemens.com>
To: "'Mark Watson'" <mwatson@nortelnetworks.com>,
        Mary Barnes <mbarnes@nortelnetworks.com>,
        "'Peterson, Jon'" <jon.peterson@neustar.biz>
Cc: "'sipping@ietf.org'" <sipping@ietf.org>,
        "'fluffy@cisco.com'" <fluffy@cisco.com>
Message-id: <DE9048A49FFFE547BBC42F855DC8CC3740C0A8@beex53.siemenscomms.co.uk>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Content-Transfer-Encoding: 7BIT
Subject: [Sipping] RE: History information privacy requirements
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7BIT
Content-Transfer-Encoding: 7BIT

Mark,
 
I understand that "outgoing messages" includes responses, but the text talks
only about "include" in outgoing messages, which might be interpreted as
insertion into the response as opposed to passing information on in the
response. Furthermore, we have to be careful when discussing passing
information on in the response, since the condition "unless it is protected
as described in <general privacy mechanism>" applies only to information
provided by the proxy concerned (i.e., sent downstream in the request and
received back again in the response). For this information, passing the
information on in the response towards the upstream entity should indeed be
subject to privacy protection and if not the information should be removed
from the response. Of course, the proxy concerned cannot be responsible for
privacy information inserted by other downstream entities and therefore such
information can be passed on unconditionally. I think the words you propose,
whilst "correct", do not adequately point out the implications.
 
Therefore perhaps the words could be extended as follows:
 
'Local policy at a proxy may identify privacy requirements associated with
Request History information. Request History information subject to privacy
requirements shall not be included in outgoing messages unless it is
protected as described in <general privacy mechanism>. Local policy can
apply different rules to the inclusion of Request History information in the
request and the inclusion of Request History information in the response. If
Request History information is subject to privacy requirements in the
response but not in the request, the proxy is responsible for removing from
any received response any Request History information that this proxy
inserted into the request.'

Regards,
 
John
 

-----Original Message-----
From: Mark Watson [mailto:mwatson@nortelnetworks.com]
Sent: 17 January 2003 17:43
To: 'Elwell, John'; Mary Barnes; 'Peterson, Jon'
Cc: 'sipping@ietf.org'; 'fluffy@cisco.com'
Subject: RE: History information privacy requirements



Well, a response is an 'outgoing message' from the UAS and every proxy it
passes through. So the text below certainly includes removing information
from a response. This would occur if a proxy was aware of some privacy
requirement for the information that the original sender & other proxies in
the path was not aware of.

...Mark 

> -----Original Message----- 
> From: Elwell, John [ mailto:john.elwell@siemens.com
<mailto:john.elwell@siemens.com> ] 
> Sent: 17 January 2003 17:37 
> To: Watson, Mark [MOP:EP10:EXCH]; Barnes, Mary [NGC:B602:EXCH]; 
> 'Peterson, Jon' 
> Cc: 'sipping@ietf.org'; 'fluffy@cisco.com' 
> Subject: RE: History information privacy requirements 
> 
> 
> Mark, 
>  
> Although I think we have agreement on the general principles, 
> I am still 
> concerned that the text you propose does not explicitly 
> mention removing 
> information from responses. 
>  
> Regards, 
>  
> John 
> 
> -----Original Message----- 
> From: Mark Watson [ mailto:mwatson@nortelnetworks.com
<mailto:mwatson@nortelnetworks.com> ] 
> Sent: 17 January 2003 12:08 
> To: 'Elwell, John'; Mary Barnes; 'Peterson, Jon' 
> Cc: 'sipping@ietf.org'; 'fluffy@cisco.com' 
> Subject: RE: History information privacy requirements 
> 
> 
> 
> John, All, 
> 
> John suggests there may be a requirement for a proxy to 'strip out' 
> History-Info from a response as that response goes past. I 
> think we should 
> be clear that this happens as a result of local policy 
> (related to privacy) 
> *at the proxy doing the stripping*, and not policy somehow 
> communicated from 
> elsewhere. 
> 
> What we need to avoid is cases where a proxy knows there is 
> some privacy 
> restriction associated with a piece of information, but it 
> includes it in 
> the message anyway, and 'trusts' a later proxy to remove it. 
> At least this 
> work should not assume such trust relationships. 
> 
> I think it would be sufficient for the Request History work 
> to require that 
> information which is known to be subject to a privacy 
> requirement is just 
> not sent - and by 'sending' I include passing on received 
> information when 
> you forward a request/response. 
> 
> Other work (the generic privacy solution) can provide generic 
> mechanisms for 
> sending information subject to privacy requirements around 
> the network. Only 
> two ways to do this: 
> 
> 1) Encrypt it with a key known only to entities 'trusted' to have the 
> information 
> 2) Send the message (securly) to an entity known to be able 
> to provide the 
> required privacy protection (i.e. privacy service). 
> 
> So, as far as Request History goes, do we need to say any 
> more than 'local 
> policy at a proxy may identify privacy requirements 
> associated with Request 
> History information. Request History information subject to privacy 
> requirements shall not be included in outgoing messages unless it is 
> protected as described in <general privacy mechanism>.' 
> 
> ...Mark 
> 
> > -----Original Message----- 
> > From: Elwell, John [ mailto:john.elwell@siemens.com
<mailto:john.elwell@siemens.com>  
> < mailto:john.elwell@siemens.com <mailto:john.elwell@siemens.com> > ] 
> > Sent: 17 January 2003 10:26 
> > To: Barnes, Mary [NGC:B602:EXCH]; Watson, Mark [MOP:EP10:EXCH]; 
> > 'Peterson, Jon' 
> > Cc: 'sipping@ietf.org'; 'fluffy@cisco.com' 
> > Subject: RE: History information privacy requirements 
> > 
> > 
> > Mary, 
> > 
> > In-line. 
> > 
> > Regards, 
> > 
> > John 
> > > -----Original Message----- 
> > > From: Mary Barnes [ mailto:mbarnes@nortelnetworks.com
<mailto:mbarnes@nortelnetworks.com>  
> < mailto:mbarnes@nortelnetworks.com <mailto:mbarnes@nortelnetworks.com> >
] 
> > > Sent: 16 January 2003 20:40 
> > > To: 'Elwell, John'; Mark Watson; 'Peterson, Jon' 
> > > Cc: 'sipping@ietf.org'; 'fluffy@cisco.com' 
> > > Subject: RE: History information privacy requirements 
> > > 
> > > 
> > > Hi John, 
> > > 
> > > I do understand your concerns and I think we agree that 
> this is an 
> > > application issue. 
> > > I think what we need to do is to add some text in section 5 
> > > (and actually I 
> > > think this text should replace what's currently the last 
> > > paragraph of that 
> > > section) highlighting that there may also be application 
> > > specific reasons 
> > > for not including the Request History Information in 
> > > responses, but that the 
> > > these reasons don't impose any additional requirements on the 
> > > protocol.  I 
> > > think there is alot of overlap with the concerns you have 
> > > raised and the 
> > > general optionality aspects that are primarily controlled by 
> > > the application 
> > > and local policy as to whether the information is captured, 
> > > and if it is 
> > > captured whether it is included in requests beyond that 
> domain or in 
> > > responses, etc. As with the optionality, I think we've 
> > > previously agreed 
> > > (and documented in the requirements) that the solution does 
> > > need to provide 
> > > some guidelines as to the aspects which must be addressed by 
> > > applications 
> > > making use of this capability.  I can add similar wording to 
> > > section 5. 
> > 
> > [JRE] Good. I look forward to that in the next draft. 
> > 
> > > 
> > > As to what's needed in the solution draft to address this, 
> > > section 2.3.3 
> > > does describe that whether the information is included in the 
> > > response is 
> > > also based upon local policy, which should thus encompass 
> > > these privacy 
> > > aspects. 
> > 
> > [JRE] Yes, but there may also be cases where the proxy wishes 
> > to include 
> > information in the request sent downstream but not in the 
> > response sent 
> > upstream. It is not clear from the existing text that local 
> > policy could say 
> > different things for the two directions. Also this may mean 
> > intercepting 
> > History-info headers received in responses from downstream 
> > entities and 
> > stripping out those that this proxy originally inserted if 
> > policy dictates 
> > that they not be sent upstream. 
> > 
> > > 
> > > Mary. 
> > > 
> > > 
> > > -----Original Message----- 
> > > From: Elwell, John [ mailto:john.elwell@siemens.com
<mailto:john.elwell@siemens.com>  
> < mailto:john.elwell@siemens.com <mailto:john.elwell@siemens.com> > ] 
> > > Sent: Thursday, January 16, 2003 12:12 PM 
> > > To: Barnes, Mary [NGC:B602:EXCH]; Watson, Mark [MOP:EP10:EXCH]; 
> > > 'Peterson, Jon' 
> > > Cc: 'sipping@ietf.org'; 'fluffy@cisco.com' 
> > > Subject: RE: History information privacy requirements 
> > > 
> > > 
> > > Mary, 
> > >  
> > > To pick up on a particular point, you wrote: 
> > >  
> > > ".... There are examples where the actual DN of a 
> destination isn't 
> > > revealed, but that's all due to application specific logic 
> > and not the 
> > > protocols (e.g call centers internally route calls without 
> > > providing an 
> > > externally dialable destination DN for the agents)...." 
> > >  
> > > Applying this same principle to SIP, application logic at the 
> > > proxy could 
> > > determine the retargeted to URI. There may be reasons for not 
> > > disclosing 
> > > this URI to the caller. Obviously one way to achieve this is 
> > > to omit history 
> > > information altogether. Then the caller will never discover the 
> > > retargeted-to URI unless the UAS sends it back, but RFC 3323 
> > > provides the 
> > > UAS with a way of preventing that. However, there may be good 
> > > reason why the 
> > > proxy will wish to place history information in the request 
> > > before sending 
> > > it on downstream, e.g., to prevent retrying targets that have 
> > > already been 
> > > tried, to advise the callee where the call has come from. So 
> > > there may be a 
> > > requirement to send history information downstream but 
> > > prevent it going 
> > > upstream back to the caller. Either there has to be a 
> > > protocol solution to 
> > > indicate this privacy requirement to downstream proxies and 
> > > the UAS, or the 
> > > retargeting proxy has to be responsible for removing any 
> > > history information 
> > > that might compromise the privacy requirement. Unfortunately 
> > > the latter 
> > > works only for a proxy, not a redirect, but perhaps 
> redirection is 
> > > inappropriate in this situation (since the redirection 
> > > request could reach 
> > > the UAC). 
> > >  
> > > So even if we say that we don't need protocol enhancements as 
> > > such, the 
> > > section of the solution document that describes proxy 
> > > behaviour should point 
> > > out the possible need to remove upstream history information. 
> > >  
> > > I guess most of the additional privacy requirements I 
> > mentioned can be 
> > > solved by appropriate proxy behaviour without requiring any 
> > additional 
> > > protocol elements. But I had expected these requirements to 
> > > be laid down in 
> > > the requirements document and text in the solutions document 
> > > indicating what 
> > > action needs to be taken to fulfil these requirements. 
> > >  
> > > Concerning regulatory requirements, these are not my primary 
> > > concern. Even 
> > > if there is no regulatory requirement governing a certain 
> > > aspect of privacy, 
> > > there may be business requirements, as in the example above 
> > > where there is a 
> > > requirement not to reveal the identity of a call centre agent. 
> > >  
> > > Regards, 
> > >  
> > > John 
> > > 
> > > John Elwell 
> > > e-mail: mailto:john.elwell@siemens.com
<mailto:john.elwell@siemens.com>  
> < mailto:john.elwell@siemens.com <mailto:john.elwell@siemens.com> > 
> 
> > > < mailto:john.elwell@siemens.com <mailto:john.elwell@siemens.com>  
> < mailto:john.elwell@siemens.com <mailto:john.elwell@siemens.com> > >  
> > >  
> > > ----remainder of thread deleted------ 
> > > 
> > 
> 
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan 20 06:31:32 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16691
	for <sipping-archive@odin.ietf.org>; Mon, 20 Jan 2003 06:31:32 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0KBmYx12852
	for sipping-archive@odin.ietf.org; Mon, 20 Jan 2003 06:48:34 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KBmYJ12849
	for <sipping-web-archive@optimus.ietf.org>; Mon, 20 Jan 2003 06:48:34 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16613
	for <sipping-web-archive@ietf.org>; Mon, 20 Jan 2003 06:31:00 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KBlkJ12805;
	Mon, 20 Jan 2003 06:47:46 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KBknJ12726
	for <sipping@optimus.ietf.org>; Mon, 20 Jan 2003 06:46:49 -0500
Received: from mip.miptel.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16424
	for <sipping@ietf.org>; Mon, 20 Jan 2003 06:29:14 -0500 (EST)
Received: from khlee ([61.250.222.86])
	by mip.miptel.com (8.11.3/8.11.3) with ESMTP id h0KBhbF05464
	for <sipping@ietf.org>; Mon, 20 Jan 2003 20:43:37 +0900
From: "Lee Kyung Hee" <khlee@miptel.com>
To: <sipping@ietf.org>
Date: Mon, 20 Jan 2003 20:31:12 +0900
Message-ID: <000001c2c077$6fa41260$56defa3d@khlee>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0001_01C2C0C2.DF8D4100"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Subject: [Sipping] rfc3323 - privacy include TLS, S/MIME?
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C2C0C2.DF8D4100
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Privacy include TLS, S/MIME?
We want implement rfc2833.
So then, Do we must implement TLS, S/MIME??
 
Best regards.
Lee Kyung Hee.

------=_NextPart_000_0001_01C2C0C2.DF8D4100
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C2C0C2.DF23D0D0">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:DontDisplayPageBoundaries/>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  =
<w:DisplayHorizontalDrawingGridEvery>0</w:DisplayHorizontalDrawingGridEve=
ry>
  =
<w:DisplayVerticalDrawingGridEvery>2</w:DisplayVerticalDrawingGridEvery>
  <w:Compatibility>
   <w:SpaceForUL/>
   <w:BalanceSingleByteDoubleByteWidth/>
   <w:DoNotLeaveBackslashAlone/>
   <w:ULTrailSpace/>
   <w:DoNotExpandShiftReturn/>
   <w:AdjustLineHeightInTable/>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
   <w:UseFELayout/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Batang;
	panose-1:2 3 6 0 0 1 1 1 1 1;
	mso-font-alt:Batang;
	mso-font-charset:129;
	mso-generic-font-family:roman;
	mso-font-pitch:variable;
	mso-font-signature:-1342176593 1775729915 48 0 524447 0;}
@font-face
	{font-family:Gulim;
	panose-1:2 11 6 0 0 1 1 1 1 1;
	mso-font-alt:Gulim;
	mso-font-charset:129;
	mso-generic-font-family:modern;
	mso-font-pitch:variable;
	mso-font-signature:-1342176593 1775729915 48 0 524447 0;}
@font-face
	{font-family:Gulim;
	panose-1:2 11 6 0 0 1 1 1 1 1;
	mso-font-charset:129;
	mso-generic-font-family:modern;
	mso-font-pitch:variable;
	mso-font-signature:-1342176593 1775729915 48 0 524447 0;}
@font-face
	{font-family:Batang;
	panose-1:2 3 6 0 0 1 1 1 1 1;
	mso-font-charset:129;
	mso-generic-font-family:roman;
	mso-font-pitch:variable;
	mso-font-signature:-1342176593 1775729915 48 0 524447 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0cm;
	margin-bottom:.0001pt;
	text-align:justify;
	text-justify:inter-ideograph;
	mso-pagination:none;
	text-autospace:none;
	word-break:break-hangul;
	font-size:10.0pt;
	mso-bidi-font-size:12.0pt;
	font-family:Batang;
	mso-hansi-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";
	mso-font-kerning:1.0pt;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Gulim;
	mso-ascii-font-family:Gulim;
	mso-fareast-font-family:Gulim;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:windowtext;}
span.GramE
	{mso-style-name:"";
	mso-gram-e:yes;}
 /* Page Definitions */
 @page
	{mso-page-border-surround-header:no;
	mso-page-border-surround-footer:no;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:99.25pt 3.0cm 3.0cm 3.0cm;
	mso-header-margin:42.55pt;
	mso-footer-margin:49.6pt;
	mso-paper-source:0;
	layout-grid:18.0pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"\D45C\C900 \D45C";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-para-margin:0cm;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=3DKO link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:40.0pt'>

<div class=3DSection1 style=3D'layout-grid:18.0pt'>

<p class=3DMsoNormal><font size=3D2 face=3D&#44404;&#47548;><span =
lang=3DEN-US
style=3D'font-size:10.0pt;mso-bidi-font-size:10.0pt;font-family:Gulim;mso=
-hansi-font-family:
Arial;mso-bidi-font-family:Arial'>Privacy <span =
class=3DGramE>include</span> TLS,
S/MIME?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D&#44404;&#47548;><span =
lang=3DEN-US
style=3D'font-size:10.0pt;mso-bidi-font-size:10.0pt;font-family:Gulim;mso=
-hansi-font-family:
Arial;mso-bidi-font-family:Arial'>We want implement =
rfc2833.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D&#44404;&#47548;><span =
lang=3DEN-US
style=3D'font-size:10.0pt;mso-bidi-font-size:10.0pt;font-family:Gulim;mso=
-hansi-font-family:
Arial;mso-bidi-font-family:Arial'>So then, <span class=3DGramE>Do</span> =
we must
implement TLS, S/MIME??<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D&#44404;&#47548;><span =
lang=3DEN-US
style=3D'font-size:10.0pt;mso-bidi-font-size:10.0pt;font-family:Gulim;mso=
-hansi-font-family:
Arial;mso-bidi-font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D&#44404;&#47548;><span =
lang=3DEN-US
style=3D'font-size:10.0pt;mso-bidi-font-size:10.0pt;font-family:Gulim;mso=
-hansi-font-family:
Arial;mso-bidi-font-family:Arial'>Best =
regards.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D&#44404;&#47548;><span =
lang=3DEN-US
style=3D'font-size:10.0pt;mso-bidi-font-size:10.0pt;font-family:Gulim;mso=
-hansi-font-family:
Arial;mso-bidi-font-family:Arial'>Lee Kyung Hee.</span></font><span =
lang=3DEN-US><o:p></o:p></span></p>

</div>

</body>

</html>

------=_NextPart_000_0001_01C2C0C2.DF8D4100--

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan 20 09:28:12 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20937
	for <sipping-archive@odin.ietf.org>; Mon, 20 Jan 2003 09:28:12 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0KEjGx23549
	for sipping-archive@odin.ietf.org; Mon, 20 Jan 2003 09:45:16 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KEjGJ23546
	for <sipping-web-archive@optimus.ietf.org>; Mon, 20 Jan 2003 09:45:16 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20924
	for <sipping-web-archive@ietf.org>; Mon, 20 Jan 2003 09:27:41 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KEiLJ23486;
	Mon, 20 Jan 2003 09:44:21 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0JItNJ15476
	for <sipping@optimus.ietf.org>; Sun, 19 Jan 2003 13:55:23 -0500
Received: from kcmso2.proxy.att.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23672
	for <sipping@ietf.org>; Sun, 19 Jan 2003 13:38:11 -0500 (EST)
Received: from maillennium.att.com ([135.25.114.99])
	by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h0JIfah6014553
	for <sipping@ietf.org>; Sun, 19 Jan 2003 12:41:36 -0600 (CST)
Received: from fisherlatitude (<unknown.domain>[135.210.86.178])
          by maillennium.att.com (mailgw1) with SMTP
          id <20030119184105gw100kschue>; Sun, 19 Jan 2003 18:41:05 +0000
From: "Steve Fisher" <sfisher1@att.com>
To: "'Eric Burger'" <eburger@snowshore.com>
Cc: <sipping@ietf.org>
Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps?
Date: Sun, 19 Jan 2003 13:41:26 -0500
Message-ID: <000001c2bfea$6021de40$b256d287@fisherlatitude>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
In-Reply-To: <4A3384433CE2AB46A63468CB207E209D2DF65E@zoe.office.snowshore.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Eric,

I've been meeting with several colleagues over the past few weeks
discussing KPML and we had some comments and questions that we thought
we'd pass on:

1) We very much prefer the use of SIP NOTIFY, instead of HTTP, to notify
application servers when a UA has detected the specified key presses.
Given that all entities, and the network infrastructure that connects
them, are already SIP-capable, it would be much simpler to have the
notification also be over SIP. Further, it seems to us that this would
be an appropriate use of the NOTIFY method, and thus would not be
abusing SIP simply for convenience. 

2) It seems to us that the "subscription" could be established as part
of the session setup process (and not via a SUBSCRIBE, for the reasons
you indicated). This also seems to us to be a reasonable use of SIP,
since detecting key presses is one aspect of the session. We envisioned
that this would occur along the lines of what's described in
draft-jennings-sip-app-info-00, although the KPML would be "inlined",
rather than fetched via HTTP. 

3) The other area of debate that we had concerned the appropriate place
to put the logic for managing the "digit maps". In the KPML draft, you
wrote:

	An interested application could request notifications of every
key 
	press.  However, many of the use cases for such signaling has
the 
	application interested in only one or a few keystrokes.  Thus we

	need a mechanism for specifying to the user device what stimulus
the 
	application would like notification of. 

Our concern is that the specific mechanism defined in KPML will impose
significant requirements on the KPML interpreters, which will frequently
be either inexpensive devices, or will be PSTN gateways that are
optimized for media processing at scale, and not for the type of
processing required by KPML. We were wondering if you are open to an
alternative approach, in which the application servers indicate to the
device which key presses they're interested in, but not the ordering of
those digits, leaving it to the application servers to manage the
sequencing of the key presses (checking intervals, etc.). Thus, this
mechanism would not be as simple as "signal for all key presses", but
would not require that the devices maintain any state other than the
list of key presses and the name of the Application Server to NOTIFY
(i.e. no state machines, regular expression interpreters, etc.).

What do you think?

Steve Fisher
Division Manager
AT&T Labs


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan 20 18:11:15 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03874
	for <sipping-archive@odin.ietf.org>; Mon, 20 Jan 2003 18:11:15 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0KNSVB23098
	for sipping-archive@odin.ietf.org; Mon, 20 Jan 2003 18:28:31 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KNSVJ23095
	for <sipping-web-archive@optimus.ietf.org>; Mon, 20 Jan 2003 18:28:31 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03861
	for <sipping-web-archive@ietf.org>; Mon, 20 Jan 2003 18:10:44 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KNRvJ23074;
	Mon, 20 Jan 2003 18:27:57 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KNOeJ22905
	for <sipping@optimus.ietf.org>; Mon, 20 Jan 2003 18:24:40 -0500
Received: from hoemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03794
	for <sipping@ietf.org>; Mon, 20 Jan 2003 18:06:53 -0500 (EST)
Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35])
	by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0KNAH725092
	for <sipping@ietf.org>; Mon, 20 Jan 2003 18:10:18 -0500 (EST)
Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2653.19)
	id <YSRT7TB3>; Mon, 20 Jan 2003 18:10:17 -0500
Message-ID: <E4BB443436F22D4AB9E84B06AB7C4CE0022221FA@nj7460exch004u.ho.lucent.com>
From: "Jain, Rajnish (Rajnish)" <rajnishjain@lucent.com>
To: "'Steve Fisher'" <sfisher1@att.com>,
        "'Eric Burger'"
	 <eburger@snowshore.com>
Cc: sipping@ietf.org
Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs a
	nd apps?
Date: Mon, 20 Jan 2003 18:10:14 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

Steve, Eric,
I just wanted to add that,  I second Steve's proposal wrt using 
SIP NOTIFY (w/ KPML inline) instead of HTTP POST for DTMF digit 
reporting.

Rajnish

-----Original Message-----
From: Steve Fisher [mailto:sfisher1@att.com]
Sent: Sunday, January 19, 2003 1:41 PM
To: 'Eric Burger'
Cc: sipping@ietf.org
Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs
and apps?


Eric,

I've been meeting with several colleagues over the past few weeks
discussing KPML and we had some comments and questions that we thought
we'd pass on:

1) We very much prefer the use of SIP NOTIFY, instead of HTTP, to notify
application servers when a UA has detected the specified key presses.
Given that all entities, and the network infrastructure that connects
them, are already SIP-capable, it would be much simpler to have the
notification also be over SIP. Further, it seems to us that this would
be an appropriate use of the NOTIFY method, and thus would not be
abusing SIP simply for convenience. 

2) It seems to us that the "subscription" could be established as part
of the session setup process (and not via a SUBSCRIBE, for the reasons
you indicated). This also seems to us to be a reasonable use of SIP,
since detecting key presses is one aspect of the session. We envisioned
that this would occur along the lines of what's described in
draft-jennings-sip-app-info-00, although the KPML would be "inlined",
rather than fetched via HTTP. 

3) The other area of debate that we had concerned the appropriate place
to put the logic for managing the "digit maps". In the KPML draft, you
wrote:

	An interested application could request notifications of every
key 
	press.  However, many of the use cases for such signaling has
the 
	application interested in only one or a few keystrokes.  Thus we

	need a mechanism for specifying to the user device what stimulus
the 
	application would like notification of. 

Our concern is that the specific mechanism defined in KPML will impose
significant requirements on the KPML interpreters, which will frequently
be either inexpensive devices, or will be PSTN gateways that are
optimized for media processing at scale, and not for the type of
processing required by KPML. We were wondering if you are open to an
alternative approach, in which the application servers indicate to the
device which key presses they're interested in, but not the ordering of
those digits, leaving it to the application servers to manage the
sequencing of the key presses (checking intervals, etc.). Thus, this
mechanism would not be as simple as "signal for all key presses", but
would not require that the devices maintain any state other than the
list of key presses and the name of the Application Server to NOTIFY
(i.e. no state machines, regular expression interpreters, etc.).

What do you think?

Steve Fisher
Division Manager
AT&T Labs


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan 20 22:08:56 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07915
	for <sipping-archive@odin.ietf.org>; Mon, 20 Jan 2003 22:08:56 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0L3QFt03593
	for sipping-archive@odin.ietf.org; Mon, 20 Jan 2003 22:26:15 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L3QFJ03590
	for <sipping-web-archive@optimus.ietf.org>; Mon, 20 Jan 2003 22:26:15 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07909
	for <sipping-web-archive@ietf.org>; Mon, 20 Jan 2003 22:08:24 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L3PcJ03543;
	Mon, 20 Jan 2003 22:25:38 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L3OJJ03486
	for <sipping@optimus.ietf.org>; Mon, 20 Jan 2003 22:24:19 -0500
Received: from zoe.office.snowshore.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07859
	for <sipping@ietf.org>; Mon, 20 Jan 2003 22:06:28 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps?
Date: Mon, 20 Jan 2003 22:09:53 -0500
Message-ID: <4A3384433CE2AB46A63468CB207E209D248669@zoe.office.snowshore.com>
Thread-Topic: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps?
Thread-Index: AcLAkrzoIQKTCOLwTMuZkvJz9kq4UwAKUiIg
From: "Eric Burger" <eburger@snowshore.com>
To: "Steve Fisher" <sfisher1@att.com>
Cc: <sipping@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0L3OJJ03487
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

I fully agree on items 1 & 2 in your message, as it is the direction MSCML is going (NOTIFY for INFO).

On item 3, I'm personally not that fond of the idea of an application doing per-digit collection.  This is more especially so if the application server is doing timing related activities.  Remember, SIP does not have timely delivery.  For that matter, in a wireless network, you are virtually guaranteed to have SLOW signaling (as you will be traversing at least two proxies, probably more in reality).

I would offer three possible directions to go:

A. Use H.248:
If you really want to manage digit detectors and get per-digit notifications, treat the gateway as a device.  My guess is that you will find (1) you will use digit maps and (2) you can't do it, because two devices cannot control the same resources in H.248.

B. Send RFC2833 events to the application:
If the application wants digit events with timing, then it should get an RFC2833 stream.  That may be easier for a cheap device to do than for it to have a KPML interpreter.  This does constitute a "send everything" policy, however.  On the other hand, once one goes down the road of sending digit masks (or maps), you might as well go all the way (see C, below).

C. Use markup:
There is an area of "It is, or it isn't."  Either a device will be able to interpret KPML (which doesn't even really need DOM or SAX) or it won't.  At some point one has to say that the device is "too stupid."  That is, it isn't worth trying to run stuff on it.

> -----Original Message-----
> From: Steve Fisher [mailto:sfisher1@att.com]
> Sent: Sunday, January 19, 2003 1:41 PM
> To: Eric Burger
> Cc: sipping@ietf.org
> Subject: RE: [Sipping] Stimulus Signaling/Markup between 
> complex SIP UAs
> and apps?
> 
> 
> Eric,
> 
> I've been meeting with several colleagues over the past few weeks
> discussing KPML and we had some comments and questions that we thought
> we'd pass on:
> 
> 1) We very much prefer the use of SIP NOTIFY, instead of 
> HTTP, to notify
> application servers when a UA has detected the specified key presses.
> Given that all entities, and the network infrastructure that connects
> them, are already SIP-capable, it would be much simpler to have the
> notification also be over SIP. Further, it seems to us that this would
> be an appropriate use of the NOTIFY method, and thus would not be
> abusing SIP simply for convenience. 
> 
> 2) It seems to us that the "subscription" could be established as part
> of the session setup process (and not via a SUBSCRIBE, for the reasons
> you indicated). This also seems to us to be a reasonable use of SIP,
> since detecting key presses is one aspect of the session. We 
> envisioned
> that this would occur along the lines of what's described in
> draft-jennings-sip-app-info-00, although the KPML would be "inlined",
> rather than fetched via HTTP. 
> 
> 3) The other area of debate that we had concerned the 
> appropriate place
> to put the logic for managing the "digit maps". In the KPML draft, you
> wrote:
> 
> 	An interested application could request notifications of every
> key 
> 	press.  However, many of the use cases for such signaling has
> the 
> 	application interested in only one or a few keystrokes.  Thus we
> 
> 	need a mechanism for specifying to the user device what stimulus
> the 
> 	application would like notification of. 
> 
> Our concern is that the specific mechanism defined in KPML will impose
> significant requirements on the KPML interpreters, which will 
> frequently
> be either inexpensive devices, or will be PSTN gateways that are
> optimized for media processing at scale, and not for the type of
> processing required by KPML. We were wondering if you are open to an
> alternative approach, in which the application servers indicate to the
> device which key presses they're interested in, but not the 
> ordering of
> those digits, leaving it to the application servers to manage the
> sequencing of the key presses (checking intervals, etc.). Thus, this
> mechanism would not be as simple as "signal for all key presses", but
> would not require that the devices maintain any state other than the
> list of key presses and the name of the Application Server to NOTIFY
> (i.e. no state machines, regular expression interpreters, etc.).
> 
> What do you think?
> 
> Steve Fisher
> Division Manager
> AT&T Labs
> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Tue Jan 21 12:25:57 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05951
	for <sipping-archive@odin.ietf.org>; Tue, 21 Jan 2003 12:25:57 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0LHhZb02382
	for sipping-archive@odin.ietf.org; Tue, 21 Jan 2003 12:43:35 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LHhZJ02379
	for <sipping-web-archive@optimus.ietf.org>; Tue, 21 Jan 2003 12:43:35 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05929
	for <sipping-web-archive@ietf.org>; Tue, 21 Jan 2003 12:25:26 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LHgtJ02275;
	Tue, 21 Jan 2003 12:42:55 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LHcNJ02006
	for <sipping@optimus.ietf.org>; Tue, 21 Jan 2003 12:38:23 -0500
Received: from zoe.office.snowshore.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05746
	for <sipping@ietf.org>; Tue, 21 Jan 2003 12:20:14 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps?
Date: Tue, 21 Jan 2003 12:23:40 -0500
Message-ID: <4A3384433CE2AB46A63468CB207E209D097BE0@zoe.office.snowshore.com>
Thread-Topic: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps?
Thread-Index: AcLA2R1RTPUJn9r/Ssq80ZoFb6yOXAAmJmog
From: "Eric Burger" <eburger@snowshore.com>
To: "Jain, Rajnish (Rajnish)" <rajnishjain@lucent.com>,
        "Steve Fisher" <sfisher1@att.com>
Cc: <sipping@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h0LHcNJ02007
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

As far as delivering the script is concerned, draft-jennings-sipping-app-info addresses in-line delivery with the cid: type.
 
I third the motion for SIP NOTIFY for reporting :-)  The new draft should be out within 2 weeks.

	-----Original Message----- 
	From: Jain, Rajnish (Rajnish) [mailto:rajnishjain@lucent.com] 
	Sent: Mon 1/20/2003 6:10 PM 
	To: 'Steve Fisher'; Eric Burger 
	Cc: sipping@ietf.org 
	Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps?
	
	

	Steve, Eric,
	I just wanted to add that,  I second Steve's proposal wrt using
	SIP NOTIFY (w/ KPML inline) instead of HTTP POST for DTMF digit
	reporting.
	
	Rajnish
	
	-----Original Message-----
	From: Steve Fisher [mailto:sfisher1@att.com]
	Sent: Sunday, January 19, 2003 1:41 PM
	To: 'Eric Burger'
	Cc: sipping@ietf.org
	Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs
	and apps?
	
	
	Eric,
	
	I've been meeting with several colleagues over the past few weeks
	discussing KPML and we had some comments and questions that we thought
	we'd pass on:
	
	1) We very much prefer the use of SIP NOTIFY, instead of HTTP, to notify
	application servers when a UA has detected the specified key presses.
	Given that all entities, and the network infrastructure that connects
	them, are already SIP-capable, it would be much simpler to have the
	notification also be over SIP. Further, it seems to us that this would
	be an appropriate use of the NOTIFY method, and thus would not be
	abusing SIP simply for convenience.
	
	2) It seems to us that the "subscription" could be established as part
	of the session setup process (and not via a SUBSCRIBE, for the reasons
	you indicated). This also seems to us to be a reasonable use of SIP,
	since detecting key presses is one aspect of the session. We envisioned
	that this would occur along the lines of what's described in
	draft-jennings-sip-app-info-00, although the KPML would be "inlined",
	rather than fetched via HTTP.
	
	3) The other area of debate that we had concerned the appropriate place
	to put the logic for managing the "digit maps". In the KPML draft, you
	wrote:
	
	        An interested application could request notifications of every
	key
	        press.  However, many of the use cases for such signaling has
	the
	        application interested in only one or a few keystrokes.  Thus we
	
	        need a mechanism for specifying to the user device what stimulus
	the
	        application would like notification of.
	
	Our concern is that the specific mechanism defined in KPML will impose
	significant requirements on the KPML interpreters, which will frequently
	be either inexpensive devices, or will be PSTN gateways that are
	optimized for media processing at scale, and not for the type of
	processing required by KPML. We were wondering if you are open to an
	alternative approach, in which the application servers indicate to the
	device which key presses they're interested in, but not the ordering of
	those digits, leaving it to the application servers to manage the
	sequencing of the key presses (checking intervals, etc.). Thus, this
	mechanism would not be as simple as "signal for all key presses", but
	would not require that the devices maintain any state other than the
	list of key presses and the name of the Application Server to NOTIFY
	(i.e. no state machines, regular expression interpreters, etc.).
	
	What do you think?
	
	Steve Fisher
	Division Manager
	AT&T Labs
	
	
	_______________________________________________
	Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
	This list is for NEW development of the application of SIP
	Use sip-implementors@cs.columbia.edu for questions on current sip
	Use sip@ietf.org for new developments of core SIP
	

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Tue Jan 21 12:34:40 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06228
	for <sipping-archive@odin.ietf.org>; Tue, 21 Jan 2003 12:34:39 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0LHqHS02849
	for sipping-archive@odin.ietf.org; Tue, 21 Jan 2003 12:52:17 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LHqHJ02846
	for <sipping-web-archive@optimus.ietf.org>; Tue, 21 Jan 2003 12:52:17 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06220
	for <sipping-web-archive@ietf.org>; Tue, 21 Jan 2003 12:34:08 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LHpEJ02750;
	Tue, 21 Jan 2003 12:51:14 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LHogJ02715
	for <sipping@optimus.ietf.org>; Tue, 21 Jan 2003 12:50:42 -0500
Received: from zoe.office.snowshore.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06184
	for <sipping@ietf.org>; Tue, 21 Jan 2003 12:32:33 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps?
Date: Tue, 21 Jan 2003 12:35:58 -0500
Message-ID: <4A3384433CE2AB46A63468CB207E209D097BE7@zoe.office.snowshore.com>
Thread-Topic: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps?
Thread-Index: AcLBUBKmAcj30MmOSb+CFfONFr6OlAAI1l3P
From: "Eric Burger" <eburger@snowshore.com>
To: "Steve Fisher" <sfisher1@att.com>
Cc: <sipping@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h0LHogJ02716
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

KPML and MSCML will be revved within 2 weeks.
 
In-line delivery of KPML is already covered in draft-jennings-sipping-app-info (the cid: scheme).
 
In-line delivery of MSCML is already covered in draft-vandyke-mscml.

	-----Original Message----- 
	From: Steve Fisher [mailto:sfisher1@att.com] 
	Sent: Tue 1/21/2003 8:21 AM 
	To: Eric Burger 
	Cc: sipping@ietf.org 
	Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps?
	
	

	Eric,
	
	Thanks for the quick reply. Does the design team intend to create new
	versions of draft-burger-sipping-kpml-00 and
	draft-jennings-sip-app-info-00 to reflect "inline" KPML and the use of
	NOTIFY instead of HTTP?
	
	Also, do you plan on issuing a new version of the MSCML draft?
	
	Thanks!
	Steve
	
	-----Original Message-----
	From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf
	Of Eric Burger
	Sent: Monday, January 20, 2003 10:10 PM
	To: Steve Fisher
	Cc: sipping@ietf.org
	Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs
	and apps?
	
	
	I fully agree on items 1 & 2 in your message, as it is the direction
	MSCML is going (NOTIFY for INFO).
	
	On item 3, I'm personally not that fond of the idea of an application
	doing per-digit collection.  This is more especially so if the
	application server is doing timing related activities.  Remember, SIP
	does not have timely delivery.  For that matter, in a wireless network,
	you are virtually guaranteed to have SLOW signaling (as you will be
	traversing at least two proxies, probably more in reality).
	
	I would offer three possible directions to go:
	
	A. Use H.248:
	If you really want to manage digit detectors and get per-digit
	notifications, treat the gateway as a device.  My guess is that you will
	find (1) you will use digit maps and (2) you can't do it, because two
	devices cannot control the same resources in H.248.
	
	B. Send RFC2833 events to the application:
	If the application wants digit events with timing, then it should get an
	RFC2833 stream.  That may be easier for a cheap device to do than for it
	to have a KPML interpreter.  This does constitute a "send everything"
	policy, however.  On the other hand, once one goes down the road of
	sending digit masks (or maps), you might as well go all the way (see C,
	below).
	
	C. Use markup:
	There is an area of "It is, or it isn't."  Either a device will be able
	to interpret KPML (which doesn't even really need DOM or SAX) or it
	won't.  At some point one has to say that the device is "too stupid."
	That is, it isn't worth trying to run stuff on it.
	
	> -----Original Message-----
	> From: Steve Fisher [mailto:sfisher1@att.com]
	> Sent: Sunday, January 19, 2003 1:41 PM
	> To: Eric Burger
	> Cc: sipping@ietf.org
	> Subject: RE: [Sipping] Stimulus Signaling/Markup between
	> complex SIP UAs
	> and apps?
	>
	>
	> Eric,
	>
	> I've been meeting with several colleagues over the past few weeks
	> discussing KPML and we had some comments and questions that we thought
	
	> we'd pass on:
	>
	> 1) We very much prefer the use of SIP NOTIFY, instead of
	> HTTP, to notify
	> application servers when a UA has detected the specified key presses.
	> Given that all entities, and the network infrastructure that connects
	> them, are already SIP-capable, it would be much simpler to have the
	> notification also be over SIP. Further, it seems to us that this would
	> be an appropriate use of the NOTIFY method, and thus would not be
	> abusing SIP simply for convenience.
	>
	> 2) It seems to us that the "subscription" could be established as part
	
	> of the session setup process (and not via a SUBSCRIBE, for the reasons
	
	> you indicated). This also seems to us to be a reasonable use of SIP,
	> since detecting key presses is one aspect of the session. We
	> envisioned that this would occur along the lines of what's described
	> in draft-jennings-sip-app-info-00, although the KPML would be
	> "inlined", rather than fetched via HTTP.
	>
	> 3) The other area of debate that we had concerned the
	> appropriate place
	> to put the logic for managing the "digit maps". In the KPML draft, you
	> wrote:
	>
	>       An interested application could request notifications of every
	key
	>       press.  However, many of the use cases for such signaling has
	> the
	>       application interested in only one or a few keystrokes.  Thus we
	>
	>       need a mechanism for specifying to the user device what stimulus
	the
	>       application would like notification of.
	>
	> Our concern is that the specific mechanism defined in KPML will impose
	
	> significant requirements on the KPML interpreters, which will
	> frequently be either inexpensive devices, or will be PSTN gateways
	> that are optimized for media processing at scale, and not for the type
	
	> of processing required by KPML. We were wondering if you are open to
	> an alternative approach, in which the application servers indicate to
	> the device which key presses they're interested in, but not the
	> ordering of
	> those digits, leaving it to the application servers to manage the
	> sequencing of the key presses (checking intervals, etc.). Thus, this
	> mechanism would not be as simple as "signal for all key presses", but
	> would not require that the devices maintain any state other than the
	> list of key presses and the name of the Application Server to NOTIFY
	> (i.e. no state machines, regular expression interpreters, etc.).
	>
	> What do you think?
	>
	> Steve Fisher
	> Division Manager
	> AT&T Labs
	>
	>
	> _______________________________________________
	> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
	> This list is for NEW development of the application of SIP Use
	> sip-implementors@cs.columbia.edu for questions on current sip Use
	> sip@ietf.org for new developments of core SIP
	>
	_______________________________________________
	Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
	This list is for NEW development of the application of SIP
	Use sip-implementors@cs.columbia.edu for questions on current sip Use
	sip@ietf.org for new developments of core SIP
	
	

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Wed Jan 22 03:03:42 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18537
	for <sipping-archive@odin.ietf.org>; Wed, 22 Jan 2003 03:03:42 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0M8Lc501601
	for sipping-archive@odin.ietf.org; Wed, 22 Jan 2003 03:21:38 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M8LcJ01598
	for <sipping-web-archive@optimus.ietf.org>; Wed, 22 Jan 2003 03:21:38 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18529
	for <sipping-web-archive@ietf.org>; Wed, 22 Jan 2003 03:03:10 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M8JWJ01478;
	Wed, 22 Jan 2003 03:19:32 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M8ILJ01422
	for <sipping@optimus.ietf.org>; Wed, 22 Jan 2003 03:18:21 -0500
Received: from wire.cs.nthu.edu.tw (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18426;
	Wed, 22 Jan 2003 02:59:53 -0500 (EST)
From: shunchao@wire.cs.nthu.edu.tw
Received: (from shunchao@localhost)
	by wire.cs.nthu.edu.tw (8.11.6/8.11.6) id h0M83SK20521;
	Wed, 22 Jan 2003 16:03:28 +0800
Date: Wed, 22 Jan 2003 16:03:28 +0800
To: sip@ietf.org, sipping@ietf.org
Message-ID: <20030122160328.A20304@wire.cs.nthu.edu.tw>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
Subject: [Sipping] IEEE JSAC - All-IP WIRELESS NETWORKS , CALL FOR PAPERS
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

			CALL FOR PAPERS

	   IEEE Journal on Selected Areas in Communications
		       ALL-IP WIRELESS NETWORKS

IP  (Internet Protocol),  which is  already a  universal network-layer
protocol  for  wireline  packet  networks,  is  becoming  a  promising
universal  network-layer  protocol   over  all  wireless  systems.  IP
provides a  globally successful  open infrastructure for  creating and
providing services  and applications. An all-IP  wireless and wireline
network could  make wireless networks more robust,  scalable, and cost
effective. It will also  enable the abundant applications and software
technologies  developed  for IP  networks  to  be  used over  wireless
networks. Today's  many different wireless systems,  ranging from PANs
(Personal  Area  Networks), wireless  LANs  (Local  Area Networks)  to
wide-area cellular  systems, are often not compatible  with each other
which makes it  difficult for a user to roam from  one radio system to
another. No wireless technology has  emerged as a common and long-term
universal solution. With  IP as the common network  layer protocol, an
IP-based  mobile device  (with multiple  radio interfaces  or software
defined radio) could roam between different wireless systems.

The papers  in this issue  will focus on state-of-the-art  research in
all-IP wireless networks. Submission  for Beyond 3G (B3G) systems will
be included. We solicit papers covering a variety of topics including,
but not limited to, the following topics:

  o   Systems and Architecture 
  o   Access Protocols 
  o   Transport Protocols 
  o   Signaling Protocols 
  o   Resource Management 
  o   Power Control and Management 
  o   QoS Provisioning 
  o   Security 
  o   Mobile VoIP 
  o   Video over Wireless Internet 
  o   Network Performance Analysis 
  o   Internetworking 
  o   System Integration 

Only  original and  unpublished  research papers  will be  considered.
Authors should  follow the IEEE  J-SAC manuscript format  described in
the Information for  Authors on the inside back cover  of any issue of
J-SAC.   There will be  one round  of reviews  and acceptance  will be
limited to papers needing only moderate revisions. Prospective authors
should submit a pdf version of their complete manuscript (which should
be  compressed  if   the  file  size  exceeds  1   Mbyte)  online  via
http://wire.cs.nthu.edu.tw/~jsac according to the following timetable:

      Manuscript Submission:   FEBRUARY 1, 2003
      Acceptance Notification: June 1, 2003
      Final Manuscript Due:    September 1, 2003
      Publication:             1st Quarter 2004


      Prathima Agrawal
      Telcordia Technologies
      Room 1J244B
      445 South St
      Morristown, NJ 07960 USA

      Tao Zhang
      Telcordia Technologies
      Room 1J214B
      445 South St
      Morristown, NJ 07960 USA

      Cormac J. Sreenan
      Dept of Computer Science
      University College Cork
      Cork, Ireland

      Jyh-Cheng Chen
      Dept of Computer Science and
      Inst of Communications Engineering
      National Tsing Hua Univ
      Hsinchu, Taiwan


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Wed Jan 22 23:10:35 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16586
	for <sipping-archive@odin.ietf.org>; Wed, 22 Jan 2003 23:10:35 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0N4Sut12905
	for sipping-archive@odin.ietf.org; Wed, 22 Jan 2003 23:28:56 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N4SuJ12902
	for <sipping-web-archive@optimus.ietf.org>; Wed, 22 Jan 2003 23:28:56 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16569
	for <sipping-web-archive@ietf.org>; Wed, 22 Jan 2003 23:10:04 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N4P8J12707;
	Wed, 22 Jan 2003 23:25:08 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N4NHJ12631
	for <sipping@optimus.ietf.org>; Wed, 22 Jan 2003 23:23:17 -0500
Received: from mail.deldsl.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16336
	for <sipping@ietf.org>; Wed, 22 Jan 2003 23:04:22 -0500 (EST)
Received: from dexceldesigns.com ([202.131.154.221])
	by mail.deldsl.com (8.11.0/8.8.7) with ESMTP id h0N9U6512404
	for <sipping@ietf.org>; Thu, 23 Jan 2003 09:30:18 GMT
Message-ID: <001a01c2c296$265a24c0$17010a64@DOMAIN.dexceldesigns.com>
From: margaretmary <margaret_mary@dexceldesigns.com>
To: <sipping@ietf.org>
Date: Thu, 23 Jan 2003 09:46:06 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;	boundary="----=_NextPart_000_0017_01C2C2C4.400197E0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
X-Mailserver: Sent using PostMaster (v4.1.13)
Subject: [Sipping] query on conference server
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0017_01C2C2C4.400197E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

hello sir,

Can any one tell me about the conference server application using SIP.

Are these two drafts "Models for Multi Party Conferencing SIP" and " A =
Multi-Party Application Framework for SIP"  specify for conference =
server application.

Is their any other draft for this, please tell me.

Is it a simple SIP User Agent required to develop conference server.
can SIP proxy server /Redirect server can come along with conference =
server.

Please help me out with this.
Since i am new to SIPPING




Regards,
Margaret


------=_NextPart_000_0017_01C2C2C4.400197E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>hello sir,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Can any one tell me about the =
conference server=20
application using SIP.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Are these two drafts&nbsp;"Models for =
Multi Party=20
Conferencing SIP" and " A Multi-Party Application Framework for =

SIP"&nbsp;=20
specify for conference server application.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Is their any other draft for this, =
please tell=20
me.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Is it a simple SIP User Agent required =
to develop=20
conference server.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>can SIP proxy server /Redirect server =
can come=20
along with conference server.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Please help me out with =
this.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Since i am new to SIPPING</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial =
size=3D2>Regards,<BR>Margaret<BR></FONT></DIV></BODY></HTML>

<br>--------------------------------------------------------------<br>Dexcel Electronics Designs (P) Ltd., Bangalore, India<br>
------=_NextPart_000_0017_01C2C2C4.400197E0--

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan 23 07:50:00 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04981
	for <sipping-archive@odin.ietf.org>; Thu, 23 Jan 2003 07:50:00 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0ND8UT22973
	for sipping-archive@odin.ietf.org; Thu, 23 Jan 2003 08:08:30 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ND8UJ22970
	for <sipping-web-archive@optimus.ietf.org>; Thu, 23 Jan 2003 08:08:30 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04946
	for <sipping-web-archive@ietf.org>; Thu, 23 Jan 2003 07:49:29 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ND7pJ22914;
	Thu, 23 Jan 2003 08:07:51 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ND5eJ22136
	for <sipping@optimus.ietf.org>; Thu, 23 Jan 2003 08:05:40 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04750;
	Thu, 23 Jan 2003 07:46:39 -0500 (EST)
Message-Id: <200301231246.HAA04750@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: sipping@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Thu, 23 Jan 2003 07:46:38 -0500
Subject: [Sipping] I-D ACTION:draft-niemi-sipping-event-throttle-reqs-00.txt
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Requirements for Limiting the Rate of Event 
                          Notifications
	Author(s)	: A. Niemi
	Filename	: draft-niemi-sipping-event-throttle-reqs-00.txt
	Pages		: 8
	Date		: 2003-1-22
	
All event packages are required to specify a maximum rate at which
event notifications are generated by a single notifier.  Such a limit
is provided in order to reduce network congestion.  In addition to
the fixed limits introduced by specific event packages, further
mechanisms for limiting the rate of event notification are also
allowed to be defined by event package specifications but none have
been specified so far.  This memo discusses the requirements for a
throttle mechanism that allows a subscriber to further limit the rate
of event notification.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-niemi-sipping-event-throttle-reqs-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-niemi-sipping-event-throttle-reqs-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-niemi-sipping-event-throttle-reqs-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-1-22111439.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-niemi-sipping-event-throttle-reqs-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-niemi-sipping-event-throttle-reqs-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-1-22111439.I-D@ietf.org>

--OtherAccess--

--NextPart--


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan 23 08:38:48 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07094
	for <sipping-archive@odin.ietf.org>; Thu, 23 Jan 2003 08:38:48 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0NDvKN26320
	for sipping-archive@odin.ietf.org; Thu, 23 Jan 2003 08:57:20 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NDvKJ26317
	for <sipping-web-archive@optimus.ietf.org>; Thu, 23 Jan 2003 08:57:20 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07075
	for <sipping-web-archive@ietf.org>; Thu, 23 Jan 2003 08:38:17 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NDuXJ26263;
	Thu, 23 Jan 2003 08:56:33 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LDaTJ16356
	for <sipping@optimus.ietf.org>; Tue, 21 Jan 2003 08:36:29 -0500
Received: from kcmso2.proxy.att.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28319
	for <sipping@ietf.org>; Tue, 21 Jan 2003 08:18:24 -0500 (EST)
Received: from maillennium.att.com ([135.25.114.99])
	by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h0LDLph6001968
	for <sipping@ietf.org>; Tue, 21 Jan 2003 07:21:51 -0600 (CST)
Received: from fisherlatitude (<unknown.domain>[135.210.114.145])
          by maillennium.att.com (mailgw1) with SMTP
          id <20030121132119gw100kscdke>; Tue, 21 Jan 2003 13:21:19 +0000
From: "Steve Fisher" <sfisher1@att.com>
To: "'Eric Burger'" <eburger@snowshore.com>
Cc: <sipping@ietf.org>
Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps?
Date: Tue, 21 Jan 2003 08:21:42 -0500
Message-ID: <000601c2c150$09f2b280$9172d287@fisherlatitude>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <4A3384433CE2AB46A63468CB207E209D248669@zoe.office.snowshore.com>
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Eric,

Thanks for the quick reply. Does the design team intend to create new
versions of draft-burger-sipping-kpml-00 and
draft-jennings-sip-app-info-00 to reflect "inline" KPML and the use of
NOTIFY instead of HTTP?

Also, do you plan on issuing a new version of the MSCML draft?

Thanks!
Steve

-----Original Message-----
From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf
Of Eric Burger
Sent: Monday, January 20, 2003 10:10 PM
To: Steve Fisher
Cc: sipping@ietf.org
Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs
and apps?


I fully agree on items 1 & 2 in your message, as it is the direction
MSCML is going (NOTIFY for INFO).

On item 3, I'm personally not that fond of the idea of an application
doing per-digit collection.  This is more especially so if the
application server is doing timing related activities.  Remember, SIP
does not have timely delivery.  For that matter, in a wireless network,
you are virtually guaranteed to have SLOW signaling (as you will be
traversing at least two proxies, probably more in reality).

I would offer three possible directions to go:

A. Use H.248:
If you really want to manage digit detectors and get per-digit
notifications, treat the gateway as a device.  My guess is that you will
find (1) you will use digit maps and (2) you can't do it, because two
devices cannot control the same resources in H.248.

B. Send RFC2833 events to the application:
If the application wants digit events with timing, then it should get an
RFC2833 stream.  That may be easier for a cheap device to do than for it
to have a KPML interpreter.  This does constitute a "send everything"
policy, however.  On the other hand, once one goes down the road of
sending digit masks (or maps), you might as well go all the way (see C,
below).

C. Use markup:
There is an area of "It is, or it isn't."  Either a device will be able
to interpret KPML (which doesn't even really need DOM or SAX) or it
won't.  At some point one has to say that the device is "too stupid."
That is, it isn't worth trying to run stuff on it.

> -----Original Message-----
> From: Steve Fisher [mailto:sfisher1@att.com]
> Sent: Sunday, January 19, 2003 1:41 PM
> To: Eric Burger
> Cc: sipping@ietf.org
> Subject: RE: [Sipping] Stimulus Signaling/Markup between
> complex SIP UAs
> and apps?
> 
> 
> Eric,
> 
> I've been meeting with several colleagues over the past few weeks 
> discussing KPML and we had some comments and questions that we thought

> we'd pass on:
> 
> 1) We very much prefer the use of SIP NOTIFY, instead of
> HTTP, to notify
> application servers when a UA has detected the specified key presses.
> Given that all entities, and the network infrastructure that connects
> them, are already SIP-capable, it would be much simpler to have the
> notification also be over SIP. Further, it seems to us that this would
> be an appropriate use of the NOTIFY method, and thus would not be
> abusing SIP simply for convenience. 
> 
> 2) It seems to us that the "subscription" could be established as part

> of the session setup process (and not via a SUBSCRIBE, for the reasons

> you indicated). This also seems to us to be a reasonable use of SIP, 
> since detecting key presses is one aspect of the session. We 
> envisioned that this would occur along the lines of what's described 
> in draft-jennings-sip-app-info-00, although the KPML would be 
> "inlined", rather than fetched via HTTP.
> 
> 3) The other area of debate that we had concerned the
> appropriate place
> to put the logic for managing the "digit maps". In the KPML draft, you
> wrote:
> 
> 	An interested application could request notifications of every
key
> 	press.  However, many of the use cases for such signaling has
> the 
> 	application interested in only one or a few keystrokes.  Thus we
> 
> 	need a mechanism for specifying to the user device what stimulus
the
> 	application would like notification of. 
> 
> Our concern is that the specific mechanism defined in KPML will impose

> significant requirements on the KPML interpreters, which will 
> frequently be either inexpensive devices, or will be PSTN gateways 
> that are optimized for media processing at scale, and not for the type

> of processing required by KPML. We were wondering if you are open to 
> an alternative approach, in which the application servers indicate to 
> the device which key presses they're interested in, but not the
> ordering of
> those digits, leaving it to the application servers to manage the
> sequencing of the key presses (checking intervals, etc.). Thus, this
> mechanism would not be as simple as "signal for all key presses", but
> would not require that the devices maintain any state other than the
> list of key presses and the name of the Application Server to NOTIFY
> (i.e. no state machines, regular expression interpreters, etc.).
> 
> What do you think?
> 
> Steve Fisher
> Division Manager
> AT&T Labs
> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP Use 
> sip-implementors@cs.columbia.edu for questions on current sip Use 
> sip@ietf.org for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip Use
sip@ietf.org for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan 23 16:45:41 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21024
	for <sipping-archive@odin.ietf.org>; Thu, 23 Jan 2003 16:45:40 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0NM4Ni28401
	for sipping-archive@odin.ietf.org; Thu, 23 Jan 2003 17:04:23 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NM4MJ28394
	for <sipping-web-archive@optimus.ietf.org>; Thu, 23 Jan 2003 17:04:22 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21008
	for <sipping-web-archive@ietf.org>; Thu, 23 Jan 2003 16:45:09 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NM3SJ28343;
	Thu, 23 Jan 2003 17:03:29 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NM1jJ28282
	for <sipping@optimus.ietf.org>; Thu, 23 Jan 2003 17:01:45 -0500
Received: from dgesmtp02.wcom.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20943
	for <sipping@ietf.org>; Thu, 23 Jan 2003 16:42:32 -0500 (EST)
Received: from pmismtp02.wcomnet.com ([166.38.62.37])
 by firewall.wcom.com (Iplanet MTA )
 with ESMTP id <0H9600CISSDZ5U@firewall.wcom.com> for sipping@ietf.org; Thu,
 23 Jan 2003 21:44:23 +0000 (GMT)
Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com
 (iPlanet Messaging Server 5.1 HotFix 0.7 (built May  7 2002))
 with SMTP id <0H9600I01S6D6C@pmismtp02.wcomnet.com>; Thu,
 23 Jan 2003 21:44:23 +0000 (GMT)
Received: from ajohnston.wcom.com ([166.42.33.61])
 by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7
 2002)) with ESMTP id <0H9600I1FSCGAT@pmismtp02.wcomnet.com>; Thu,
 23 Jan 2003 21:43:30 +0000 (GMT)
Date: Thu, 23 Jan 2003 15:43:25 -0600
From: Alan Johnston <alan.johnston@wcom.com>
Subject: Re: [Sipping] query on conference server
In-reply-to: <001a01c2c296$265a24c0$17010a64@DOMAIN.dexceldesigns.com>
X-Sender: Alan.Johnston@pop.mcit.com
To: margaretmary <margaret_mary@dexceldesigns.com>, sipping@ietf.org
Message-id: <5.1.1.6.0.20030123153908.03e6b1c0@pop.mcit.com>
MIME-version: 1.0
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Content-type: text/plain; charset=us-ascii; format=flowed
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

Hi Margaret,

There is a SIPPING design team working on conferencing.  Information about 
the work is at:

      http://www.softarmor.com/sipping/teams/conf/

I'd recommend you start reading the conferencing framework document which 
may answer your questions:

    http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-conferencing-framework-00.txt

Thanks,
Alan Johnston
WorldCom
sip:alan@digitalari.com

At 09:46 AM 1/23/2003 +0530, margaretmary wrote:
>hello sir,
>
>Can any one tell me about the conference server application using SIP.
>
>Are these two drafts "Models for Multi Party Conferencing SIP" and " A 
>Multi-Party Application Framework for SIP"  specify for conference server 
>application.
>
>Is their any other draft for this, please tell me.
>
>Is it a simple SIP User Agent required to develop conference server.
>can SIP proxy server /Redirect server can come along with conference server.
>
>Please help me out with this.
>Since i am new to SIPPING
>
>
>
>
>Regards,
>Margaret
>
>--------------------------------------------------------------
>Dexcel Electronics Designs (P) Ltd., Bangalore, India

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Fri Jan 24 04:22:45 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13918
	for <sipping-archive@odin.ietf.org>; Fri, 24 Jan 2003 04:22:45 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0O9ffs16048
	for sipping-archive@odin.ietf.org; Fri, 24 Jan 2003 04:41:41 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O9ffJ16045
	for <sipping-web-archive@optimus.ietf.org>; Fri, 24 Jan 2003 04:41:41 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13883
	for <sipping-web-archive@ietf.org>; Fri, 24 Jan 2003 04:22:14 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O9eWJ15980;
	Fri, 24 Jan 2003 04:40:32 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O9b0J15197
	for <sipping@optimus.ietf.org>; Fri, 24 Jan 2003 04:37:00 -0500
Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13839
	for <sipping@ietf.org>; Fri, 24 Jan 2003 04:17:33 -0500 (EST)
From: aki.niemi@nokia.com
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0O9NLt04642
	for <sipping@ietf.org>; Fri, 24 Jan 2003 11:23:21 +0200 (EET)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5ffc540d0fac158f23077@esvir03nok.nokia.com> for <sipping@ietf.org>;
 Fri, 24 Jan 2003 11:20:59 +0200
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Fri, 24 Jan 2003 11:20:59 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Fri, 24 Jan 2003 11:20:59 +0200
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901ADD1D4@esebe013.ntc.nokia.com>
Thread-Topic: Event notification rate limiting requirements
Thread-Index: AcLDiehMGkk5LTXaRPOpoRstiCSBEA==
To: <sipping@ietf.org>
X-OriginalArrivalTime: 24 Jan 2003 09:20:59.0867 (UTC) FILETIME=[E8839AB0:01C2C389]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0O9b0J15198
Subject: [Sipping] Event notification rate limiting requirements
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

Hi All,

In IETF55 it was agreed that the filtering requirements need to be package specific, while rate limiting might be generic across all packages.

There is now a new draft available that discusses the requirements for a generic event notification rate limiting mechanism, or event throttle mechanism:

http://www.ietf.org/internet-drafts/draft-niemi-sipping-event-throttle-reqs-00.txt

One issue that has come up is that there are scenarios, where throttles in fact need to be closely combined with event filters. For example, assigning specific throttles to notifications from specific presentities in a presence-list event requires that a single event subscription applies several different throttles.

So the main question is: should there be a generic throttle mechanism, or are throttles event-package or filter-specific? Or do we in fact need both types?

Any comments?

Cheers,
Aki
 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Fri Jan 24 10:51:51 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23106
	for <sipping-archive@odin.ietf.org>; Fri, 24 Jan 2003 10:51:51 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0OGAt408955
	for sipping-archive@odin.ietf.org; Fri, 24 Jan 2003 11:10:55 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OGAtJ08952
	for <sipping-web-archive@optimus.ietf.org>; Fri, 24 Jan 2003 11:10:55 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23097
	for <sipping-web-archive@ietf.org>; Fri, 24 Jan 2003 10:51:20 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OGAGJ08934;
	Fri, 24 Jan 2003 11:10:16 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OG7nJ08782
	for <sipping@optimus.ietf.org>; Fri, 24 Jan 2003 11:07:49 -0500
Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23041
	for <sipping@ietf.org>; Fri, 24 Jan 2003 10:48:14 -0500 (EST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA21687;
	Fri, 24 Jan 2003 10:51:41 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA11303;
	Fri, 24 Jan 2003 10:51:41 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19)
	id <D3QL5X3F>; Fri, 24 Jan 2003 10:51:40 -0500
Message-ID: <313680C9A886D511A06000204840E1CF030B5D63@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'jh@lohi.eng.song.fi'" <jh@lohi.eng.song.fi>,
        Henning Schulzrinne
	 <hgs@cs.columbia.edu>
Cc: Christer Holmberg <christer.holmberg@lmf.ericsson.se>,
        "Conroy, Lawrence (SMTP)" <lwc@roke.co.uk>,
        "'sipping@ietf.org'"
	 <sipping@ietf.org>
Date: Fri, 24 Jan 2003 10:51:37 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sipping] RE: [Iptel] Re: [Sip] TEL-URL local numbers
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

[I put this on sipping because it's a sip issue.  When we settle what
we want in a tel uri, we can go to IPTEL to get it]

We just went through a thread on dial string expansion.
This is just more of the same issue.

At this point, I think we should take a step back and figure
out where we want to end up, because it seems to me that
we are going to have to make something non-backwards-compatible.

I think there are only two reasonable endpoints:
1. The UA does it all.  UAs never send anything that can't be
sent to the right gateway and succeed.  Proxies can route to the
appropriate gateway, but they never add (or subtract) anything
from a tel uri (or any other header) - the UA always sends
a full phone number (of course, redirect is still possible).
  
This means that the UA has a dialing plan, which it must learn 
from the local environment, so that it can translate from 
something the user enters into a full address.  It also
means context disappears as a concept (it's in the dialing plan).

2. The UA sends a dialing string and downstream proxies
translate to routable numbers.  We can argue what tel URIs
and headers look like to do this.  It's possible a proxy
adds a context if it knows some of the expansion rules.
but not all of them.

It doesn't seem reasonable to me to try to walk a tightrope
between these two extremes.  We keep getting tripped by
reality.

Brian

> -----Original Message-----
> From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi]
> Sent: Friday, January 24, 2003 9:17 AM
> To: Henning Schulzrinne
> Cc: Christer Holmberg; Conroy, Lawrence (SMTP); iptel@ietf.org
> Subject: Re: [Iptel] Re: [Sip] TEL-URL local numbers
> 
> 
> Henning Schulzrinne writes:
> 
>  > 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).
> 
> 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?
> 
>  > 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.
> 
> 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.
> 
>  > 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.
> 
> 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
> 
> 
> 
> _______________________________________________
> Iptel mailing list
> Iptel@ietf.org
> https://www.ietf.org/mailman/listinfo/iptel
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Fri Jan 24 13:36:22 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28003
	for <sipping-archive@odin.ietf.org>; Fri, 24 Jan 2003 13:36:22 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0OItSo20343
	for sipping-archive@odin.ietf.org; Fri, 24 Jan 2003 13:55:28 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OItSJ20340
	for <sipping-web-archive@optimus.ietf.org>; Fri, 24 Jan 2003 13:55:28 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27994
	for <sipping-web-archive@ietf.org>; Fri, 24 Jan 2003 13:35:50 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OIsZJ20304;
	Fri, 24 Jan 2003 13:54:35 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OIpuJ20213
	for <sipping@optimus.ietf.org>; Fri, 24 Jan 2003 13:51:56 -0500
Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27864
	for <sipping@ietf.org>; Fri, 24 Jan 2003 13:32:18 -0500 (EST)
Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0OIZUKV007470;
	Fri, 24 Jan 2003 19:35:30 +0100 (MET)
Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55)
	id ZGNPAXRA; Fri, 24 Jan 2003 19:35:30 +0100
Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.106.10])
	by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h0OIZUH7017361;
	Fri, 24 Jan 2003 20:35:30 +0200 (EET)
Message-ID: <3E318782.BCB9C2DA@lmf.ericsson.se>
Date: Fri, 24 Jan 2003 20:35:46 +0200
X-Sybari-Trust: d49d07d1 9ffcebbb c096fb41 00000138
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
CC: "'jh@lohi.eng.song.fi'" <jh@lohi.eng.song.fi>,
        Henning Schulzrinne <hgs@cs.columbia.edu>,
        "Conroy, Lawrence (SMTP)" <lwc@roke.co.uk>,
        "'sipping@ietf.org'" <sipping@ietf.org>
References: <313680C9A886D511A06000204840E1CF030B5D63@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


Hi,

> [I put this on sipping because it's a sip issue.  When we settle what
> we want in a tel uri, we can go to IPTEL to get it]
>
> We just went through a thread on dial string expansion.
> This is just more of the same issue.
>
> At this point, I think we should take a step back and figure
> out where we want to end up, because it seems to me that
> we are going to have to make something non-backwards-compatible.
>
> I think there are only two reasonable endpoints:
> 1. The UA does it all.  UAs never send anything that can't be
> sent to the right gateway and succeed.  Proxies can route to the
> appropriate gateway, but they never add (or subtract) anything
> from a tel uri (or any other header) - the UA always sends
> a full phone number (of course, redirect is still possible).

[CHH] I don't think that is true. Proxies can replace the Request-URI, and
who says that the replacement can't be the same header as received, but with
some additional parameters?

> This means that the UA has a dialing plan, which it must learn
> from the local environment, so that it can translate from
> something the user enters into a full address.  It also
> means context disappears as a concept (it's in the dialing plan).

[CHH] I don't think the UAC has to send something which can be routed all
the way to the UAS. Intermediate proxies can take the Request-URI,  do
whatever lookups to find where to route the message, and, again, replace the
received Request-URI value with a new value if needed.

Regards,

Christer Holmberg
Ericsson Finland




>
>
> 2. The UA sends a dialing string and downstream proxies
> translate to routable numbers.  We can argue what tel URIs
> and headers look like to do this.  It's possible a proxy
> adds a context if it knows some of the expansion rules.
> but not all of them.
>
> It doesn't seem reasonable to me to try to walk a tightrope
> between these two extremes.  We keep getting tripped by
> reality.
>
> Brian
>
> > -----Original Message-----
> > From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi]
> > Sent: Friday, January 24, 2003 9:17 AM
> > To: Henning Schulzrinne
> > Cc: Christer Holmberg; Conroy, Lawrence (SMTP); iptel@ietf.org
> > Subject: Re: [Iptel] Re: [Sip] TEL-URL local numbers
> >
> >
> > Henning Schulzrinne writes:
> >
> >  > 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).
> >
> > 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?
> >
> >  > 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.
> >
> > 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.
> >
> >  > 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.
> >
> > 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
> >
> >
> >
> > _______________________________________________
> > Iptel mailing list
> > Iptel@ietf.org
> > https://www.ietf.org/mailman/listinfo/iptel
> >

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Fri Jan 24 13:53:33 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28531
	for <sipping-archive@odin.ietf.org>; Fri, 24 Jan 2003 13:53:33 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0OJCdR21872
	for sipping-archive@odin.ietf.org; Fri, 24 Jan 2003 14:12:39 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OJCdJ21869
	for <sipping-web-archive@optimus.ietf.org>; Fri, 24 Jan 2003 14:12:39 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28519
	for <sipping-web-archive@ietf.org>; Fri, 24 Jan 2003 13:53:01 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OJC8J21851;
	Fri, 24 Jan 2003 14:12:08 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OJ9vJ21759
	for <sipping@optimus.ietf.org>; Fri, 24 Jan 2003 14:09:57 -0500
Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28485
	for <sipping@ietf.org>; Fri, 24 Jan 2003 13:50:19 -0500 (EST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA00650;
	Fri, 24 Jan 2003 13:53:44 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA09886;
	Fri, 24 Jan 2003 13:53:45 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19)
	id <D3QL580H>; Fri, 24 Jan 2003 13:53:44 -0500
Message-ID: <313680C9A886D511A06000204840E1CF030B5D66@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Christer Holmberg'" <christer.holmberg@lmf.ericsson.se>
Cc: "'jh@lohi.eng.song.fi'" <jh@lohi.eng.song.fi>,
        Henning Schulzrinne
	 <hgs@cs.columbia.edu>,
        "Conroy, Lawrence (SMTP)" <lwc@roke.co.uk>,
        "'sipping@ietf.org'" <sipping@ietf.org>
Date: Fri, 24 Jan 2003 13:53:43 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sipping] RE: [Iptel] Re: [Sip] TEL-URL local numbers
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

Either we treat a tel URI like a sip URI, which means you can
do substitution on the Request-URI, but we have no concept of
"context" or we should implement dial strings and let the
proxies do the expansion.  It doesn't make any sense to me
to have the UA have some knowledge of translating dial strings
to fully routable numbers, but not all the knowledge.

This thread, and the dial string thread have yielded lots of
examples of why context is not a functional mechanism.  So,
I propose we get rid of it, one way or the other.

Brian

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se]
> Sent: Friday, January 24, 2003 1:36 PM
> To: Rosen, Brian
> Cc: 'jh@lohi.eng.song.fi'; Henning Schulzrinne; Conroy, 
> Lawrence (SMTP);
> 'sipping@ietf.org'
> Subject: Re: [Iptel] Re: [Sip] TEL-URL local numbers
> 
> 
> 
> Hi,
> 
> > [I put this on sipping because it's a sip issue.  When we 
> settle what
> > we want in a tel uri, we can go to IPTEL to get it]
> >
> > We just went through a thread on dial string expansion.
> > This is just more of the same issue.
> >
> > At this point, I think we should take a step back and figure
> > out where we want to end up, because it seems to me that
> > we are going to have to make something non-backwards-compatible.
> >
> > I think there are only two reasonable endpoints:
> > 1. The UA does it all.  UAs never send anything that can't be
> > sent to the right gateway and succeed.  Proxies can route to the
> > appropriate gateway, but they never add (or subtract) anything
> > from a tel uri (or any other header) - the UA always sends
> > a full phone number (of course, redirect is still possible).
> 
> [CHH] I don't think that is true. Proxies can replace the 
> Request-URI, and
> who says that the replacement can't be the same header as 
> received, but with
> some additional parameters?
> 
> > This means that the UA has a dialing plan, which it must learn
> > from the local environment, so that it can translate from
> > something the user enters into a full address.  It also
> > means context disappears as a concept (it's in the dialing plan).
> 
> [CHH] I don't think the UAC has to send something which can 
> be routed all
> the way to the UAS. Intermediate proxies can take the Request-URI,  do
> whatever lookups to find where to route the message, and, 
> again, replace the
> received Request-URI value with a new value if needed.
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> 
> 
> 
> >
> >
> > 2. The UA sends a dialing string and downstream proxies
> > translate to routable numbers.  We can argue what tel URIs
> > and headers look like to do this.  It's possible a proxy
> > adds a context if it knows some of the expansion rules.
> > but not all of them.
> >
> > It doesn't seem reasonable to me to try to walk a tightrope
> > between these two extremes.  We keep getting tripped by
> > reality.
> >
> > Brian
> >
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Fri Jan 24 14:36:46 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00095
	for <sipping-archive@odin.ietf.org>; Fri, 24 Jan 2003 14:36:46 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0OJtsS24445
	for sipping-archive@odin.ietf.org; Fri, 24 Jan 2003 14:55:54 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OJtsJ24442
	for <sipping-web-archive@optimus.ietf.org>; Fri, 24 Jan 2003 14:55:54 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00078
	for <sipping-web-archive@ietf.org>; Fri, 24 Jan 2003 14:36:15 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OJsBJ24342;
	Fri, 24 Jan 2003 14:54:11 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OJpSJ24192
	for <sipping@optimus.ietf.org>; Fri, 24 Jan 2003 14:51:28 -0500
Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29843
	for <sipping@ietf.org>; Fri, 24 Jan 2003 14:31:49 -0500 (EST)
Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66])
	(user=hgs10 mech=PLAIN bits=0)
	by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0OJYxdS009008
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Fri, 24 Jan 2003 14:35:07 -0500 (EST)
Message-ID: <3E319568.2060905@cs.columbia.edu>
Date: Fri, 24 Jan 2003 14:35:04 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
CC: "'Christer Holmberg'" <christer.holmberg@lmf.ericsson.se>,
        "'jh@lohi.eng.song.fi'" <jh@lohi.eng.song.fi>,
        "Conroy, Lawrence (SMTP)" <lwc@roke.co.uk>,
        "'sipping@ietf.org'" <sipping@ietf.org>
References: <313680C9A886D511A06000204840E1CF030B5D66@whq-msgusr-02.pit.comms.marconi.com>
In-Reply-To: <313680C9A886D511A06000204840E1CF030B5D66@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

There seem to be at least three scenarios:

(1) The end system has a dialplan, learned automatically, and can easily 
translate dialed digits into an E.164 number. We clearly need this and I 
should have a micro-draft on this shortly. This hinges on the whole UA 
configuration mess, which has not made much progress. I think this 
solution has the greatest flexibility, as it allows users to carry their 
dialplans with them as well as get local ones. It also allows inspection 
- a device can easily display what will happen to a digit string. If the 
proxy does translation, you only find out when what you thought was a 
local extension gets translated to dial-a-prayer. (Or, worse, doesn't 
get answered at all, in which case one may not suspect anything amiss.)

(2) However, there are apparently some numbers that are not translatable 
to E.164 numbers. Effectively, they are a different namespace that is 
valid only locally. As I've mentioned before, IBM has two phone 
namespaces internally, judging from their business cards. The extension 
is *not* directly related to the externally reachable number. Thus, the 
end system cannot produce an E.164 number without doing some kind of 
directory lookup.

(3) The end system has no dialplan (e.g., because the current products 
don't support this). Then, the local proxy needs to do the translation. 
Here, there seem to be two options:

(3a) Allow this non-unique, non-global dialed number and effectively 
declare it "whatever this happens to mean at the first proxy this 
request meets - and good luck".

(3b) Mark with context, so that you can detect if expectation and 
reality don't match.

In general, as 2806bis tries to express, globally unique URIs are best 
for everyone - no confusion, no ambiguity. The question is whether we 
can get rid of the cases (2) and (3) above that don't work that way. I 
don't think just having (3a) is a viable option if we want to build 
reliable and testable systems.

Rosen, Brian wrote:
> Either we treat a tel URI like a sip URI, which means you can
> do substitution on the Request-URI, but we have no concept of
> "context" or we should implement dial strings and let the
> proxies do the expansion.  It doesn't make any sense to me
> to have the UA have some knowledge of translating dial strings
> to fully routable numbers, but not all the knowledge.
> 
> This thread, and the dial string thread have yielded lots of
> examples of why context is not a functional mechanism.  So,
> I propose we get rid of it, one way or the other.

I have heard examples of why it might be inconvenient for current 
shipping phones. I have not heard why it would not work.

> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Fri Jan 24 15:34:59 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01675
	for <sipping-archive@odin.ietf.org>; Fri, 24 Jan 2003 15:34:59 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0OKs9t27902
	for sipping-archive@odin.ietf.org; Fri, 24 Jan 2003 15:54:09 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OKs9J27899
	for <sipping-web-archive@optimus.ietf.org>; Fri, 24 Jan 2003 15:54:09 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01657
	for <sipping-web-archive@ietf.org>; Fri, 24 Jan 2003 15:34:28 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OKqHJ27849;
	Fri, 24 Jan 2003 15:52:17 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OKmqJ27718
	for <sipping@optimus.ietf.org>; Fri, 24 Jan 2003 15:48:52 -0500
Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01539
	for <sipping@ietf.org>; Fri, 24 Jan 2003 15:29:11 -0500 (EST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA05387;
	Fri, 24 Jan 2003 15:32:36 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA25705;
	Fri, 24 Jan 2003 15:32:38 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19)
	id <D3QL6BRC>; Fri, 24 Jan 2003 15:32:37 -0500
Message-ID: <313680C9A886D511A06000204840E1CF030B5D69@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Henning Schulzrinne'" <hgs@cs.columbia.edu>
Cc: "'Christer Holmberg'" <christer.holmberg@lmf.ericsson.se>,
        "'jh@lohi.eng.song.fi'" <jh@lohi.eng.song.fi>,
        "Conroy, Lawrence (SMTP)"
	 <lwc@roke.co.uk>,
        "'sipping@ietf.org'" <sipping@ietf.org>
Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
Date: Fri, 24 Jan 2003 15:32:36 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

Okay, let's get specific, because it's hard on my head to deal
with too many abstractions.

Around here, I can dial 7844 to get a local extension,
9-1-703-559-2348 to reach a colleague in one of our outlying offices,
or 304-2349 to reach the same colleague using our internal network.
Just for the moment, ignore the possibility that some entity could
recognize that 9-1-703-559-2348 could be translated into 304-2348.
The point is that in my domain, 304-2348 is a routable number,
but not a global number.  We in fact do have numbers that are
routable, but not accessible as E.164s.

We have a gateway to our PBX.  If you send it a uri of the
form tel:3042348, it will dial it correctly.  However, if you
send that uri to a gateway in my home, it won't dial my colleague.
Until a year ago, it would have connected you to 724-304-2349,
but today you would just get an intercept.

So, what is my "context"? And how do I use it?
Right now, my sipphone is dumb, it sends dial strings.  My proxy
has a dial plan, and it expands dial strings to numbers.
You are advocating that we move the dial plan processing into
the UA.  I'll agree that that would work.

What I don't understand is what I can then do with context.  
If I have the dial plan in the UA, then what it emits is a legal 
number in the domain represented by that dial plan. 
Subsequent proxies should be able to route it.  
They might even substitute the number in the Request-URI 
(doing the translation from 9-1-703-559-2348 to 304-2348 
for example).  I might indeed know that the local context
is "Marconi Pittsburgh", but what would any downstream entity do
with that?  Any call within the domain has that context, and 
if the call got outside the domain, the number is probably wrong.
For example, the "304" doesn't work in Marconi, UK, they have a 
different prefix.  The only way that the call can get outside 
the domain is to have some routing error.  If I had the context,
I could return an error if I didn't understand it. I think we get
into heaps of trouble when the routing sends you through a domain
that doesn't know the context, but can route the number 
none-the-less, to a domain that does understand the context
(Marconi Pittsburgh -> WorldCom -> Marconi UK)

The same problem can happen with a sip uri, and we don't do anything 
to detect or repair damage in that case, why would we do so in 
this case?  Not all sip uri's are globally routable!

My home proxy would know that 304-2348 is not a legal number,
because the local (ie home) dialing plan wouldn't include it.
The closest I can come to having a use for context is that
if I had a contact database, I could have 304-2348 in it with
a context of "Marconi Pittsburgh".  Then, my UA could figure
out that it can't use that number unless I'm in that domain.
That is not something we could really say is part of our charter.

Brian

> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Friday, January 24, 2003 2:35 PM
> To: Rosen, Brian
> Cc: 'Christer Holmberg'; 'jh@lohi.eng.song.fi'; Conroy, 
> Lawrence (SMTP);
> 'sipping@ietf.org'
> Subject: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
> 
> 
> There seem to be at least three scenarios:
> 
> (1) The end system has a dialplan, learned automatically, and 
> can easily 
> translate dialed digits into an E.164 number. We clearly need 
> this and I 
> should have a micro-draft on this shortly. This hinges on the 
> whole UA 
> configuration mess, which has not made much progress. I think this 
> solution has the greatest flexibility, as it allows users to 
> carry their 
> dialplans with them as well as get local ones. It also allows 
> inspection 
> - a device can easily display what will happen to a digit 
> string. If the 
> proxy does translation, you only find out when what you thought was a 
> local extension gets translated to dial-a-prayer. (Or, worse, doesn't 
> get answered at all, in which case one may not suspect 
> anything amiss.)
> 
> (2) However, there are apparently some numbers that are not 
> translatable 
> to E.164 numbers. Effectively, they are a different namespace that is 
> valid only locally. As I've mentioned before, IBM has two phone 
> namespaces internally, judging from their business cards. The 
> extension 
> is *not* directly related to the externally reachable number. 
> Thus, the 
> end system cannot produce an E.164 number without doing some kind of 
> directory lookup.
> 
> (3) The end system has no dialplan (e.g., because the current 
> products 
> don't support this). Then, the local proxy needs to do the 
> translation. 
> Here, there seem to be two options:
> 
> (3a) Allow this non-unique, non-global dialed number and effectively 
> declare it "whatever this happens to mean at the first proxy this 
> request meets - and good luck".
> 
> (3b) Mark with context, so that you can detect if expectation and 
> reality don't match.
> 
> In general, as 2806bis tries to express, globally unique URIs 
> are best 
> for everyone - no confusion, no ambiguity. The question is whether we 
> can get rid of the cases (2) and (3) above that don't work 
> that way. I 
> don't think just having (3a) is a viable option if we want to build 
> reliable and testable systems.
> 
> Rosen, Brian wrote:
> > Either we treat a tel URI like a sip URI, which means you can
> > do substitution on the Request-URI, but we have no concept of
> > "context" or we should implement dial strings and let the
> > proxies do the expansion.  It doesn't make any sense to me
> > to have the UA have some knowledge of translating dial strings
> > to fully routable numbers, but not all the knowledge.
> > 
> > This thread, and the dial string thread have yielded lots of
> > examples of why context is not a functional mechanism.  So,
> > I propose we get rid of it, one way or the other.
> 
> I have heard examples of why it might be inconvenient for current 
> shipping phones. I have not heard why it would not work.
> 
> > 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Fri Jan 24 15:53:48 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02071
	for <sipping-archive@odin.ietf.org>; Fri, 24 Jan 2003 15:53:47 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0OLCvJ29126
	for sipping-archive@odin.ietf.org; Fri, 24 Jan 2003 16:12:57 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OLCvJ29123
	for <sipping-web-archive@optimus.ietf.org>; Fri, 24 Jan 2003 16:12:57 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02055
	for <sipping-web-archive@ietf.org>; Fri, 24 Jan 2003 15:53:16 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OLCGJ29107;
	Fri, 24 Jan 2003 16:12:16 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OL9gJ29010
	for <sipping@optimus.ietf.org>; Fri, 24 Jan 2003 16:09:42 -0500
Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01929
	for <sipping@ietf.org>; Fri, 24 Jan 2003 15:50:01 -0500 (EST)
Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66])
	(user=hgs10 mech=PLAIN bits=0)
	by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0OKrRdS017534
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Fri, 24 Jan 2003 15:53:29 -0500 (EST)
Message-ID: <3E31A7CB.6020006@cs.columbia.edu>
Date: Fri, 24 Jan 2003 15:53:31 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
CC: "'sipping@ietf.org'" <sipping@ietf.org>
Subject: Re: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
References: <313680C9A886D511A06000204840E1CF030B5D69@whq-msgusr-02.pit.comms.marconi.com>
In-Reply-To: <313680C9A886D511A06000204840E1CF030B5D69@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

> Just for the moment, ignore the possibility that some entity could
> recognize that 9-1-703-559-2348 could be translated into 304-2348.
> The point is that in my domain, 304-2348 is a routable number,
> but not a global number.  We in fact do have numbers that are
> routable, but not accessible as E.164s.

Glad there's another example...

> What I don't understand is what I can then do with context.  
> If I have the dial plan in the UA, then what it emits is a legal 
> number in the domain represented by that dial plan. 
> Subsequent proxies should be able to route it.  
> They might even substitute the number in the Request-URI 
> (doing the translation from 9-1-703-559-2348 to 304-2348 
> for example).  I might indeed know that the local context
> is "Marconi Pittsburgh", but what would any downstream entity do
> with that?  Any call within the domain has that context, and 

Leaving aside that existing SIP phones aren't configured with this 
(which is presumably a fixable problem):

Your phone in your office would be configured with the context, just 
like it now gets configured with the local outbound proxy. This 
configuration can be part of the permanent device configuration or it 
can be acquired dynamically from the outbound proxy. Both approaches 
have value:

(1) Device-associated configuration of the context means that the dial 
strings have the same meaning (or no meaning) wherever you take the 
phone, but you'll never get a dial string that means something to mean 
something else in a different place.

(2) Proxy-associated configuration of the context has the opposite 
properties: you guarantee that the dial string is meant to be translated 
by it, but you might mistakenly dial your intra-office extension at home 
and get whatever the proxy makes it to be.

Both are valid and useful depending on the type of user interface 
characteristics you want, but you need the context to reliable detect 
what's going on, rather than having the proxy guess.

One way to think of the context is as a token that identifies the 
translation table ("dialing plan").


> if the call got outside the domain, the number is probably wrong.
> For example, the "304" doesn't work in Marconi, UK, they have a 
> different prefix.  The only way that the call can get outside 
> the domain is to have some routing error.  If I had the context,
> I could return an error if I didn't understand it. I think we get
> into heaps of trouble when the routing sends you through a domain
> that doesn't know the context, but can route the number 
> none-the-less, to a domain that does understand the context
> (Marconi Pittsburgh -> WorldCom -> Marconi UK)

That was never the intent. All tel URIs are either resolved by the first 
proxy or they are ditched with an error response (404, presumably). The 
context intentionally does not have enough information to route it to 
some other entity. (It comes close in the DNS form, but I don't want to 
go there.)

> 
> The same problem can happen with a sip uri, and we don't do anything 
> to detect or repair damage in that case, why would we do so in 
> this case?  Not all sip uri's are globally routable!

They should be globally unique, even if they are not globally routable. 
A SIP URI should never mean Alice in one place and Bob in another.

> 
> My home proxy would know that 304-2348 is not a legal number,
> because the local (ie home) dialing plan wouldn't include it.

You are lucky in this case. For many dialing plans, the shape of the 
number may well be the same.

> The closest I can come to having a use for context is that
> if I had a contact database, I could have 304-2348 in it with
> a context of "Marconi Pittsburgh".  Then, my UA could figure
> out that it can't use that number unless I'm in that domain.
> That is not something we could really say is part of our charter.
> 
> Brian
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Fri Jan 24 16:25:55 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02874
	for <sipping-archive@odin.ietf.org>; Fri, 24 Jan 2003 16:25:54 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0OLj5p31003
	for sipping-archive@odin.ietf.org; Fri, 24 Jan 2003 16:45:05 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OLj5J31000
	for <sipping-web-archive@optimus.ietf.org>; Fri, 24 Jan 2003 16:45:05 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02854
	for <sipping-web-archive@ietf.org>; Fri, 24 Jan 2003 16:25:23 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OLiPJ30939;
	Fri, 24 Jan 2003 16:44:25 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OLefJ30768
	for <sipping@optimus.ietf.org>; Fri, 24 Jan 2003 16:40:41 -0500
Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02762
	for <sipping@ietf.org>; Fri, 24 Jan 2003 16:20:59 -0500 (EST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA07747;
	Fri, 24 Jan 2003 16:24:25 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA04049;
	Fri, 24 Jan 2003 16:24:26 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19)
	id <D3QL6DQ0>; Fri, 24 Jan 2003 16:24:26 -0500
Message-ID: <313680C9A886D511A06000204840E1CF030B5D6D@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Henning Schulzrinne'" <hgs@cs.columbia.edu>
Cc: "'sipping@ietf.org'" <sipping@ietf.org>
Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
Date: Fri, 24 Jan 2003 16:24:25 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

> Your phone in your office would be configured with the context, just 
> like it now gets configured with the local outbound proxy. This 
> configuration can be part of the permanent device configuration or it 
> can be acquired dynamically from the outbound proxy. Both approaches 
> have value:
> 
> (1) Device-associated configuration of the context means that 
> the dial 
> strings have the same meaning (or no meaning) wherever you take the 
> phone, but you'll never get a dial string that means 
> something to mean 
> something else in a different place.
> 
> (2) Proxy-associated configuration of the context has the opposite 
> properties: you guarantee that the dial string is meant to be 
> translated 
> by it, but you might mistakenly dial your intra-office 
> extension at home 
> and get whatever the proxy makes it to be.
There is a third possibility, which is that the dialing plan
is associated with the AOR.  I dial the same way on every
sipphone I register with, wherever I am.

We've been around this dilemma (do you want the dial string to remain
constant when you roam, or do you want the local context).  As you
seem to agree, there is no really right answer.  We've come to
the conclusion that it should be the local dialing plan for where
you are.  There seem to be fewer problems and it's the way the PSTN
and all PBXs work now.

I actually think we are best to standardize the behavior one way or
the other.  It is a standards issue, regardless of how we implement
it (if you substitute "dialing plan" for "context" your explanation
above makes the same argument).
> 
> Both are valid and useful depending on the type of user interface 
> characteristics you want, but you need the context to reliable detect 
> what's going on, rather than having the proxy guess.
I don't think so, or rather, I think there are too many problems to
make it be that way.  This whole thread is about problems with
context.

As yet another example, what is my context?  Is it "Marconi Pittsburgh".
Is that globally unique?  Or is it "+1724742"?  That's globally unique,
but may or may not be useable by my first hop proxy.

I think we either get rid of it, making the dialing plan the last word,
or make the dialing plan the job of the first hop proxy.  I fail to see
the advantage of dialing plan in the UA and first hop proxy interpreting
context.

> 
> One way to think of the context is as a token that identifies the 
> translation table ("dialing plan").
Yeah, I got that.

...snip...

> That was never the intent. All tel URIs are either resolved 
> by the first 
> proxy or they are ditched with an error response (404, 
> presumably). The 
> context intentionally does not have enough information to route it to 
> some other entity. (It comes close in the DNS form, but I 
> don't want to 
> go there.)
To me, that makes context even less interesting.  You require the
first hop proxy to understand all contexts that could be generated by
any UA it serves.  That would make it pretty hard for you to bring
your office phone home if your ISP provided your first hop proxy. 

I think it's best to either have the dialing plan have to make sense
to the first hop proxy (by making the local domain the source of
the dialing plan, your #2 above), or make the proxy responsible for
turning digit strings into routable numbers.  I don't see enough
utility in having the dialing plan associated with the phone itself.

Brian
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Fri Jan 24 16:30:23 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02984
	for <sipping-archive@odin.ietf.org>; Fri, 24 Jan 2003 16:30:23 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0OLnY531164
	for sipping-archive@odin.ietf.org; Fri, 24 Jan 2003 16:49:34 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OLnYJ31161
	for <sipping-web-archive@optimus.ietf.org>; Fri, 24 Jan 2003 16:49:34 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02950
	for <sipping-web-archive@ietf.org>; Fri, 24 Jan 2003 16:29:52 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OLn5J31133;
	Fri, 24 Jan 2003 16:49:05 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OLkQJ31060
	for <sipping@optimus.ietf.org>; Fri, 24 Jan 2003 16:46:26 -0500
Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02923
	for <sipping@ietf.org>; Fri, 24 Jan 2003 16:26:44 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.40])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0OLUEYH008268;
	Fri, 24 Jan 2003 16:30:15 -0500 (EST)
Message-ID: <3E31B05F.5050706@dynamicsoft.com>
Date: Fri, 24 Jan 2003 16:30:07 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Alan Johnston <alan.johnston@wcom.com>
CC: margaretmary <margaret_mary@dexceldesigns.com>, sipping@ietf.org
Subject: Re: [Sipping] query on conference server
References: <5.1.1.6.0.20030123153908.03e6b1c0@pop.mcit.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

One additional note. The "models for multiparty conferencing in sip" is 
not going to move forward. Its content has been moved into the framework 
document Alan has pointed out, along with other documents that the 
framework references.

To briefly answer your questions, a conference server (called a focus in 
SIP) is a SIP user agent. Proxies don't know anything about conferences. 
They just route requests to URIs, and a URI might represent a conference.

-Jonathan R.

Alan Johnston wrote:
> Hi Margaret,
> 
> There is a SIPPING design team working on conferencing.  Information 
> about the work is at:
> 
>      http://www.softarmor.com/sipping/teams/conf/
> 
> I'd recommend you start reading the conferencing framework document 
> which may answer your questions:
> 
>    
> http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-conferencing-framework-00.txt 
> 
> 
> Thanks,
> Alan Johnston
> WorldCom
> sip:alan@digitalari.com
> 
> At 09:46 AM 1/23/2003 +0530, margaretmary wrote:
> 
>> hello sir,
>>
>> Can any one tell me about the conference server application using SIP.
>>
>> Are these two drafts "Models for Multi Party Conferencing SIP" and " A 
>> Multi-Party Application Framework for SIP"  specify for conference 
>> server application.
>>
>> Is their any other draft for this, please tell me.
>>
>> Is it a simple SIP User Agent required to develop conference server.
>> can SIP proxy server /Redirect server can come along with conference 
>> server.
>>
>> Please help me out with this.
>> Since i am new to SIPPING
>>
>>
>>
>>
>> Regards,
>> Margaret
>>
>> --------------------------------------------------------------
>> Dexcel Electronics Designs (P) Ltd., Bangalore, India
> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP
> 

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Fri Jan 24 16:42:56 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03333
	for <sipping-archive@odin.ietf.org>; Fri, 24 Jan 2003 16:42:56 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0OM27K32258
	for sipping-archive@odin.ietf.org; Fri, 24 Jan 2003 17:02:07 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OM27J32255
	for <sipping-web-archive@optimus.ietf.org>; Fri, 24 Jan 2003 17:02:07 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03329
	for <sipping-web-archive@ietf.org>; Fri, 24 Jan 2003 16:42:25 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OM1PJ32016;
	Fri, 24 Jan 2003 17:01:25 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OLwHJ31570
	for <sipping@optimus.ietf.org>; Fri, 24 Jan 2003 16:58:17 -0500
Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03131
	for <sipping@ietf.org>; Fri, 24 Jan 2003 16:38:35 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.40])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0OLg4YH008290;
	Fri, 24 Jan 2003 16:42:05 -0500 (EST)
Message-ID: <3E31B325.60906@dynamicsoft.com>
Date: Fri, 24 Jan 2003 16:41:57 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Peter Saint-Andre <stpeter@jabber.org>
CC: Dean Willis <dean.willis@softarmor.com>,
        "PRATI,LUCA (HP-Italy,ex1)" <luca.prati@hp.com>, sipping@ietf.org
Subject: Re: [Sipping] SIP <-> XMPP
References: <Pine.LNX.4.10.10301161145290.16539-100000@lor.jeremie.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

One final note.

Like many technologies, there are ways they can work together, and ways 
they overlap in functionality. The draft below explains ways in which 
SIP can be used to set up XMPP session, and in that way, they are 
complementary.  In other ways, there is overlap. XMPP has its own 
presence mechanism, as does SIP (the SIMPLE specs). SIP can also do IM 
using the page mode messaging (rfc 3428) which does not require XMPP.

I won't attempt to go into a pro/con analysis here, but just want to 
make sure the various angles of the relationship are understood.

-Jonathan R.

Peter Saint-Andre wrote:
> On 16 Jan 2003, Dean Willis wrote:
> 
> 
>>Historically speaking, XMPP was not on the radar screen of the IETF when
>>3261 was published. 
> 
> 
> True, so we would not expect mention of XMPP in 3261.
> 
> 
>>I believe there is a SIMPLE draft dealing with using SIP to set up an
>>XMPP session for messaging.
> 
> 
> http://www.ietf.org/internet-drafts/draft-sparks-simple-jabber-sessions-00.txt
> 
> Peter
> 
> --
> Peter Saint-Andre
> Jabber Software Foundation
> http://www.jabber.org/people/stpeter.php
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP
> 

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Fri Jan 24 18:05:00 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04961
	for <sipping-archive@odin.ietf.org>; Fri, 24 Jan 2003 18:05:00 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0ONODP04335
	for sipping-archive@odin.ietf.org; Fri, 24 Jan 2003 18:24:13 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ONOCJ04332
	for <sipping-web-archive@optimus.ietf.org>; Fri, 24 Jan 2003 18:24:13 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04954
	for <sipping-web-archive@ietf.org>; Fri, 24 Jan 2003 18:04:28 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ONMTJ04254;
	Fri, 24 Jan 2003 18:22:29 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ONJNJ04140
	for <sipping@optimus.ietf.org>; Fri, 24 Jan 2003 18:19:23 -0500
Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04775
	for <sipping@ietf.org>; Fri, 24 Jan 2003 17:59:39 -0500 (EST)
Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66])
	(user=hgs10 mech=PLAIN bits=0)
	by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0ON37dS029180
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Fri, 24 Jan 2003 18:03:08 -0500 (EST)
Message-ID: <3E31C62F.3080904@cs.columbia.edu>
Date: Fri, 24 Jan 2003 18:03:11 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
CC: "'sipping@ietf.org'" <sipping@ietf.org>
Subject: Re: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
References: <313680C9A886D511A06000204840E1CF030B5D6D@whq-msgusr-02.pit.comms.marconi.com>
In-Reply-To: <313680C9A886D511A06000204840E1CF030B5D6D@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

> As yet another example, what is my context?  Is it "Marconi Pittsburgh".
> Is that globally unique?  Or is it "+1724742"?  That's globally unique,
> but may or may not be useable by my first hop proxy.

The point is that you and your first hop proxy better agree on 
something, choosing one of the mechanism in 2806bis, such as a prefix or 
a domain name. What you pick is immaterial - it is invisible to the user.

If you can't agree on that, it is very unlikely that you can agree on 
what actually happens in the translation. Once you have automated 
configuration (at the device, AOR or outbound proxy level), it doesn't 
matter what it is called, as long as you pick something that's unique. 
2806bis provides two reasonable mechanisms. I don't see this as an issue.

> 
> I think we either get rid of it, making the dialing plan the last word,
> or make the dialing plan the job of the first hop proxy.  I fail to see
> the advantage of dialing plan in the UA and first hop proxy interpreting
> context.

You would never have both at the same time in the same installation, but 
I don't think we're in the business of picking architectures here. My 
proposal allows choice. If you don't like to run context in your 
products or installation, don't. I happen to think that UA-translation 
is best, as it is in the endsystem-is-smart spirit, but others seem to 
want proxy translation. Proxy translation without context is extremely 
brittle.


> To me, that makes context even less interesting.  You require the
> first hop proxy to understand all contexts that could be generated by
> any UA it serves.  That would make it pretty hard for you to bring
> your office phone home if your ISP provided your first hop proxy. 
> 
> I think it's best to either have the dialing plan have to make sense
> to the first hop proxy (by making the local domain the source of
> the dialing plan, your #2 above), or make the proxy responsible for
> turning digit strings into routable numbers.  I don't see enough
> utility in having the dialing plan associated with the phone itself.

The point is that I want to be warned if the translation is done by 
somebody that shouldn't. This becomes even more important when you put 
tel URIs on web pages.

Henning

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Fri Jan 24 18:25:00 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05232
	for <sipping-archive@odin.ietf.org>; Fri, 24 Jan 2003 18:25:00 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0ONiDG05608
	for sipping-archive@odin.ietf.org; Fri, 24 Jan 2003 18:44:13 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ONiDJ05605
	for <sipping-web-archive@optimus.ietf.org>; Fri, 24 Jan 2003 18:44:13 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05229
	for <sipping-web-archive@ietf.org>; Fri, 24 Jan 2003 18:24:28 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ONgCJ05560;
	Fri, 24 Jan 2003 18:42:12 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ONbpJ05422
	for <sipping@optimus.ietf.org>; Fri, 24 Jan 2003 18:37:51 -0500
Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05184
	for <sipping@ietf.org>; Fri, 24 Jan 2003 18:18:06 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0ONMGb6005409;
	Fri, 24 Jan 2003 18:22:17 -0500 (EST)
Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAY53228;
	Fri, 24 Jan 2003 18:26:29 -0500 (EST)
Message-ID: <3E31CA76.4040603@cisco.com>
Date: Fri, 24 Jan 2003 18:21:26 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
CC: "'Henning Schulzrinne'" <hgs@cs.columbia.edu>,
        "'Christer Holmberg'" <christer.holmberg@lmf.ericsson.se>,
        "'jh@lohi.eng.song.fi'" <jh@lohi.eng.song.fi>,
        "Conroy, Lawrence (SMTP)" <lwc@roke.co.uk>,
        "'sipping@ietf.org'" <sipping@ietf.org>
Subject: Re: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
References: <313680C9A886D511A06000204840E1CF030B5D69@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Brian,

I think you have provided some good questions to pursue, and I don't 
have the final answers on them. But I will venture an opinion:

If your phone had an internal dial plan, it should know the context it 
is in. So if from your phone you dial 304-2349, it could translate that 
to something like:

	tel:304-2349;phone-context=pittsburgh.marconi.com

This is then sent to your local proxy, which understands the context and 
knows how to route the call.

Now suppose that same phone calls me at sip:pkyzivat@cisco.com. It isn't 
a globally routable phone, so it puts that same address in the From 
header. My phone is smart and remembers the From address for future 
reference, in my address book.

I may eventually try to return the call using the saved url. Two things 
can happen:
1a) the proxy I use never heard of the context, and fails the call. 
(That would certainly be the case if I tried it from inside Cisco.

2a) maybe I was visiting a marconi facility and have plugged into the 
network there. With a great deal of luck and provisioning, I might find 
myself sending requests to a marconi proxy that understands the context 
and can route the call. This could even work if I was visiting marconi 
in the UK.

OTOH, suppose the phone doesn't bother with context and simply encodes 
the dial string as tel:3042349. Then different things happen in the 
cases above:
1b) if my local proxy uses the same sorts of conventions, it will try to 
interpret the number 3042349 in my local context. With luck it will just 
fail. It is also possible that it might work, which would be worse since 
it will be calling the wrong destination.

2b) if I happen to be visiting marconi pittsburg, the call will perhaps 
work. If I am visiting marconi uk I guess it will fail.

I think including the context in numbers helps. It ensures that numbers 
are at least universally unambiguous even when they aren't universally 
dialable.

	Paul

Rosen, Brian wrote:
> Okay, let's get specific, because it's hard on my head to deal
> with too many abstractions.
> 
> Around here, I can dial 7844 to get a local extension,
> 9-1-703-559-2348 to reach a colleague in one of our outlying offices,
> or 304-2349 to reach the same colleague using our internal network.
> Just for the moment, ignore the possibility that some entity could
> recognize that 9-1-703-559-2348 could be translated into 304-2348.
> The point is that in my domain, 304-2348 is a routable number,
> but not a global number.  We in fact do have numbers that are
> routable, but not accessible as E.164s.
> 
> We have a gateway to our PBX.  If you send it a uri of the
> form tel:3042348, it will dial it correctly.  However, if you
> send that uri to a gateway in my home, it won't dial my colleague.
> Until a year ago, it would have connected you to 724-304-2349,
> but today you would just get an intercept.
> 
> So, what is my "context"? And how do I use it?
> Right now, my sipphone is dumb, it sends dial strings.  My proxy
> has a dial plan, and it expands dial strings to numbers.
> You are advocating that we move the dial plan processing into
> the UA.  I'll agree that that would work.
> 
> What I don't understand is what I can then do with context.  
> If I have the dial plan in the UA, then what it emits is a legal 
> number in the domain represented by that dial plan. 
> Subsequent proxies should be able to route it.  
> They might even substitute the number in the Request-URI 
> (doing the translation from 9-1-703-559-2348 to 304-2348 
> for example).  I might indeed know that the local context
> is "Marconi Pittsburgh", but what would any downstream entity do
> with that?  Any call within the domain has that context, and 
> if the call got outside the domain, the number is probably wrong.
> For example, the "304" doesn't work in Marconi, UK, they have a 
> different prefix.  The only way that the call can get outside 
> the domain is to have some routing error.  If I had the context,
> I could return an error if I didn't understand it. I think we get
> into heaps of trouble when the routing sends you through a domain
> that doesn't know the context, but can route the number 
> none-the-less, to a domain that does understand the context
> (Marconi Pittsburgh -> WorldCom -> Marconi UK)
> 
> The same problem can happen with a sip uri, and we don't do anything 
> to detect or repair damage in that case, why would we do so in 
> this case?  Not all sip uri's are globally routable!
> 
> My home proxy would know that 304-2348 is not a legal number,
> because the local (ie home) dialing plan wouldn't include it.
> The closest I can come to having a use for context is that
> if I had a contact database, I could have 304-2348 in it with
> a context of "Marconi Pittsburgh".  Then, my UA could figure
> out that it can't use that number unless I'm in that domain.
> That is not something we could really say is part of our charter.
> 
> Brian
> 
> 
>>-----Original Message-----
>>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
>>Sent: Friday, January 24, 2003 2:35 PM
>>To: Rosen, Brian
>>Cc: 'Christer Holmberg'; 'jh@lohi.eng.song.fi'; Conroy, 
>>Lawrence (SMTP);
>>'sipping@ietf.org'
>>Subject: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
>>
>>
>>There seem to be at least three scenarios:
>>
>>(1) The end system has a dialplan, learned automatically, and 
>>can easily 
>>translate dialed digits into an E.164 number. We clearly need 
>>this and I 
>>should have a micro-draft on this shortly. This hinges on the 
>>whole UA 
>>configuration mess, which has not made much progress. I think this 
>>solution has the greatest flexibility, as it allows users to 
>>carry their 
>>dialplans with them as well as get local ones. It also allows 
>>inspection 
>>- a device can easily display what will happen to a digit 
>>string. If the 
>>proxy does translation, you only find out when what you thought was a 
>>local extension gets translated to dial-a-prayer. (Or, worse, doesn't 
>>get answered at all, in which case one may not suspect 
>>anything amiss.)
>>
>>(2) However, there are apparently some numbers that are not 
>>translatable 
>>to E.164 numbers. Effectively, they are a different namespace that is 
>>valid only locally. As I've mentioned before, IBM has two phone 
>>namespaces internally, judging from their business cards. The 
>>extension 
>>is *not* directly related to the externally reachable number. 
>>Thus, the 
>>end system cannot produce an E.164 number without doing some kind of 
>>directory lookup.
>>
>>(3) The end system has no dialplan (e.g., because the current 
>>products 
>>don't support this). Then, the local proxy needs to do the 
>>translation. 
>>Here, there seem to be two options:
>>
>>(3a) Allow this non-unique, non-global dialed number and effectively 
>>declare it "whatever this happens to mean at the first proxy this 
>>request meets - and good luck".
>>
>>(3b) Mark with context, so that you can detect if expectation and 
>>reality don't match.
>>
>>In general, as 2806bis tries to express, globally unique URIs 
>>are best 
>>for everyone - no confusion, no ambiguity. The question is whether we 
>>can get rid of the cases (2) and (3) above that don't work 
>>that way. I 
>>don't think just having (3a) is a viable option if we want to build 
>>reliable and testable systems.
>>
>>Rosen, Brian wrote:
>>
>>>Either we treat a tel URI like a sip URI, which means you can
>>>do substitution on the Request-URI, but we have no concept of
>>>"context" or we should implement dial strings and let the
>>>proxies do the expansion.  It doesn't make any sense to me
>>>to have the UA have some knowledge of translating dial strings
>>>to fully routable numbers, but not all the knowledge.
>>>
>>>This thread, and the dial string thread have yielded lots of
>>>examples of why context is not a functional mechanism.  So,
>>>I propose we get rid of it, one way or the other.
>>
>>I have heard examples of why it might be inconvenient for current 
>>shipping phones. I have not heard why it would not work.
>>
>>
>>_______________________________________________
>>Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>>This list is for NEW development of the application of SIP
>>Use sip-implementors@cs.columbia.edu for questions on current sip
>>Use sip@ietf.org for new developments of core SIP
>>
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Fri Jan 24 18:42:38 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05502
	for <sipping-archive@odin.ietf.org>; Fri, 24 Jan 2003 18:42:38 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0P01qT06216
	for sipping-archive@odin.ietf.org; Fri, 24 Jan 2003 19:01:52 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P01qJ06213
	for <sipping-web-archive@optimus.ietf.org>; Fri, 24 Jan 2003 19:01:52 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05488
	for <sipping-web-archive@ietf.org>; Fri, 24 Jan 2003 18:42:07 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P01GJ06200;
	Fri, 24 Jan 2003 19:01:16 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ONwFJ06077
	for <sipping@optimus.ietf.org>; Fri, 24 Jan 2003 18:58:15 -0500
Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05470
	for <sipping@ietf.org>; Fri, 24 Jan 2003 18:38:30 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0ONgftQ007207;
	Fri, 24 Jan 2003 18:42:42 -0500 (EST)
Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAY53375;
	Fri, 24 Jan 2003 18:46:54 -0500 (EST)
Message-ID: <3E31CF40.7080806@cisco.com>
Date: Fri, 24 Jan 2003 18:41:52 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Henning Schulzrinne <hgs@cs.columbia.edu>
CC: "Rosen, Brian" <Brian.Rosen@marconi.com>,
        "'Christer Holmberg'" <christer.holmberg@lmf.ericsson.se>,
        "'jh@lohi.eng.song.fi'" <jh@lohi.eng.song.fi>,
        "Conroy, Lawrence (SMTP)" <lwc@roke.co.uk>,
        "'sipping@ietf.org'" <sipping@ietf.org>
Subject: Re: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
References: <313680C9A886D511A06000204840E1CF030B5D66@whq-msgusr-02.pit.comms.marconi.com> <3E319568.2060905@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Henning Schulzrinne wrote:
> There seem to be at least three scenarios:
> 
> (1) The end system has a dialplan, learned automatically, and can easily 
> translate dialed digits into an E.164 number. ...  It also allows inspection
> - a device can easily display what will happen to a digit string. If the 
> proxy does translation, you only find out when what you thought was a 
> local extension gets translated to dial-a-prayer. (Or, worse, doesn't 
> get answered at all, in which case one may not suspect anything amiss.)

There is a solution to this problem when using proxy expansion: The 
proxy can do the expansion and then return the result as a redirect 
(probably 301). The phone will then retry, but can display the new number.

But this doesn't work for From. The calling phone had better know an 
expanded form of its own address.

	Paul

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Fri Jan 24 22:24:04 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08741
	for <sipping-archive@odin.ietf.org>; Fri, 24 Jan 2003 22:24:04 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0P3hMN18667
	for sipping-archive@odin.ietf.org; Fri, 24 Jan 2003 22:43:22 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P3hLJ18664
	for <sipping-web-archive@optimus.ietf.org>; Fri, 24 Jan 2003 22:43:21 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08737
	for <sipping-web-archive@ietf.org>; Fri, 24 Jan 2003 22:23:33 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P3dYJ18513;
	Fri, 24 Jan 2003 22:39:34 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P3Z6J17735
	for <sipping@optimus.ietf.org>; Fri, 24 Jan 2003 22:35:06 -0500
Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08679
	for <sipping@ietf.org>; Fri, 24 Jan 2003 22:15:17 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.40])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0P3InYH008480;
	Fri, 24 Jan 2003 22:18:49 -0500 (EST)
Message-ID: <3E320215.8050607@dynamicsoft.com>
Date: Fri, 24 Jan 2003 22:18:45 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@cisco.com>
CC: sipping@ietf.org
Subject: Re: [Sipping] I-D ACTION:draft-rosenberg-sipping-session-policy-req-00.txt
References: <200301071328.IAA12023@ietf.org> <3E1B024A.1020309@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Sorry for taking so long to respond. Comments inline.

Paul Kyzivat wrote:
> This document provides many detailed requirements. But I am still left 
> with a feeling of uncertainty about the overall scope. For instance:
> 
> - I'm not sure what is in scope and out of scope for a media policy. Is 
> there anything that can be negotiated via an offer/answer exchange that 
> is out of scope? Certain specific features that are encoded in SDP are 
> called out specifically. This might imply that it is intended that 
> features not mentioned are out of scope.

Well, Section 3.2 listed a very specific set of policies. Its not any 
apsect of the O/A exchange. Anything else is out of scope. Of course, I 
am happy to discuss the scope.

> 
> An example of a specific feature not mentioned, is the a=direction 
> attribute used by comedia. It is possible to imagine an intermediate 
> node might want to alter an a=direction:both to be only 
> a=direction:active. Does this need to be listed as a requirement before 
> it can be addressed by policy?

Yes.

> 
> I am somewhat concerned that this is a slippery slope. Unless we can 
> clearly define what is in scope and what is out, I think we will find 
> that we are simply defining a new representation of SDP, one syntactic 
> element at a time. At the least, this seems to require a sort of 
> meta-model for offers and answers that transcends SDP and SDPng.

Nowhere in this document does it describe the syntax or encoding. It may 
very well be that the right way to do this is to have the proxy include 
some kind of SDP. But, thats mechanism. For now, I am trying to focus on 
requirements, and their implications on the overall information flow.


> 
> - Continuing the scope question a bit, is there any intent to support 
> policies that can't already be expressed via an offer/answer exchange? 
> (I don't think so, but just checking.)

As above, the set of policies that are to be enabled are explicitly 
enumerated.

> 
> - There is much mention of proxies as the nodes that want to specify 
> policy. But I think there are other kinds of servers that may also take 
> on this role. Specifically, a B2BUA may also want to work cooperatively 
> with the endpoints in same way. Of course a B2BUA already has more 
> capabilities to modify the SDP directly, but it may want to be more 
> subtle and friendly in its manipulations. For instance, this mechanism 
> may permit a more extended pre-alert negotiation than is currently 
> possible. So I would like to see these requirements phrased to permit a 
> B2BUA as a policy setter if that makes sense.

I suppose it makes sense, but I must admit the central aim was to allow 
these intermediary things to be standards compliant proxies, yet carry 
out the policy actions that people want to see.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Fri Jan 24 22:26:23 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08761
	for <sipping-archive@odin.ietf.org>; Fri, 24 Jan 2003 22:26:23 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0P3jf218750
	for sipping-archive@odin.ietf.org; Fri, 24 Jan 2003 22:45:41 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P3jfJ18747
	for <sipping-web-archive@optimus.ietf.org>; Fri, 24 Jan 2003 22:45:41 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08758
	for <sipping-web-archive@ietf.org>; Fri, 24 Jan 2003 22:25:52 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P3g5J18630;
	Fri, 24 Jan 2003 22:42:05 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P3dOJ18507
	for <sipping@optimus.ietf.org>; Fri, 24 Jan 2003 22:39:24 -0500
Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08712
	for <sipping@ietf.org>; Fri, 24 Jan 2003 22:19:35 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.40])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0P3LNYH008484;
	Fri, 24 Jan 2003 22:21:23 -0500 (EST)
Message-ID: <3E3202AF.7000803@dynamicsoft.com>
Date: Fri, 24 Jan 2003 22:21:19 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
CC: "'Paul Kyzivat'" <pkyzivat@cisco.com>, sipping@ietf.org
Subject: Re: [Sipping] I-D ACTION:draft-rosenberg-sipping-session-policy-r
 eq-00.txt
References: <313680C9A886D511A06000204840E1CF030B5CCF@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit



Rosen, Brian wrote:
> Agree.  I specifically want to have the mechanism allowed to
> specify the bandwidth parameters (I ask for a 6MB video stream,
> the proxy tells me I can only send 4, everything else is the same).
> So, is this in scope or out?

I'd be happy to add it in.

> 
> I'll point out that this is an interesting one because there is no
> middle box; there is simply a bandwidth manager that is doing
> something much better than simplistic call admission control. However,
> I don't see any reason to judge why one SDP parameter is subject
> to policy, and another one is not.  

Well, I am willing to consider that this itself may be a requirement, 
i.e., that its a requirement for a proxy to be able to ask the client to 
do any specific modification to its SDP. However, generally a 
requirements process is about determining exactly what the real problem 
is, and not putting in everything under the sun. Practically speaking, I 
suspect proxies really are interested in a limited number of things. SO 
long as the mechanism is extensible to other aspects of the session, is 
there really a compelling need to support everything at the outset?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Fri Jan 24 23:10:33 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09589
	for <sipping-archive@odin.ietf.org>; Fri, 24 Jan 2003 23:10:33 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0P4Tqd20233
	for sipping-archive@odin.ietf.org; Fri, 24 Jan 2003 23:29:52 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P4TpJ20230
	for <sipping-web-archive@optimus.ietf.org>; Fri, 24 Jan 2003 23:29:51 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09563
	for <sipping-web-archive@ietf.org>; Fri, 24 Jan 2003 23:10:01 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P4THJ20214;
	Fri, 24 Jan 2003 23:29:17 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P4Q0J20156
	for <sipping@optimus.ietf.org>; Fri, 24 Jan 2003 23:26:00 -0500
Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09553
	for <sipping@ietf.org>; Fri, 24 Jan 2003 23:06:10 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.40])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0P49aYH008502;
	Fri, 24 Jan 2003 23:09:37 -0500 (EST)
Message-ID: <3E320DFC.90805@dynamicsoft.com>
Date: Fri, 24 Jan 2003 23:09:32 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
CC: "'Henning Schulzrinne'" <hgs@cs.columbia.edu>,
        Adam Roach <adam@dynamicsoft.com>,
        "'Paul Kyzivat'" <pkyzivat@cisco.com>,
        "'sipping@ietf.org'" <sipping@ietf.org>
Subject: Re: [Sipping] Do Phones Have Dial Plans, or do Proxies map?  was
 	RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
References: <313680C9A886D511A06000204840E1CF030B5D01@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Slightly old thread here, but I wanted to add my own two cents.

Firstly, I too support the development of some kind of dial plan 
document that can be downloaded into a UA. I think such a mechanism 
should be incorporated into some kind of BCP that describes the 
construction of enterprise phoen systems with SIP; I believe Brian 
mentioned he is working on such a thing.

More inline.

Rosen, Brian wrote:
> Actually, I'm happy with a "Dial" button.
> 
> I'll note most existing SIP phones don't do this (or at least don't
> have a physical "Dial" button, I've seen some with softkeys).
> 
> However, the issue remains.  If I dial 6744 on my sip phone (and press
> dial), the sipphone on my admin's desk should ring.  I should not have
> to dial +17247426744.  The fact that I dialed a 4 digit number with
> a 6 as the starting digit tells my system that it is an internal
> extension.  A dial plan is the thing that "knows" this.
> 
> What do you want to have happen:
> 1) tel:6744; context=+1724742
> 2) tel:6744; context=marconi-pittsburgh-local-extension
> 3) tel:+17247426744

The notion of an identity that exists within a local context is exactly 
what a SIP URI is for. I always thought that if the user entered 6744, 
the most likely result would be the following URI:

sip:6744@example.com

where example.com is the local domain, configured into the phone. Unlike 
the tel URI, which has no clear way to determine where to go to resolve 
a number with a local context, the SIP URI does.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Fri Jan 24 23:19:15 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09713
	for <sipping-archive@odin.ietf.org>; Fri, 24 Jan 2003 23:19:15 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0P4cYo21146
	for sipping-archive@odin.ietf.org; Fri, 24 Jan 2003 23:38:34 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P4cYJ21143
	for <sipping-web-archive@optimus.ietf.org>; Fri, 24 Jan 2003 23:38:34 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09710
	for <sipping-web-archive@ietf.org>; Fri, 24 Jan 2003 23:18:44 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P4c6J21122;
	Fri, 24 Jan 2003 23:38:06 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P4XGJ20322
	for <sipping@optimus.ietf.org>; Fri, 24 Jan 2003 23:33:16 -0500
Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09642
	for <sipping@ietf.org>; Fri, 24 Jan 2003 23:13:26 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.40])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0P4GuYH008505;
	Fri, 24 Jan 2003 23:16:59 -0500 (EST)
Message-ID: <3E320FB4.9080304@dynamicsoft.com>
Date: Fri, 24 Jan 2003 23:16:52 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: wenkai <wkai@huawei.com>
CC: sipping@ietf.org
Subject: Re: [Sipping] a question about 3pcc
References: <002801c2b845$94f91040$af064d0a@w07087a>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit



wenkai wrote:
> Hi,
> The following is the "Mid-Call Announcement" call flow from 
> "draft-ietf-sipping-3pcc-02.txt".
> After hanging up with the media server, the controller reconnects the 
> Pre-Paid user to the called party. I think the media stream(stream 3) 
> established between Pre-Paid user and the Called Party maybe is not the 
> same as the original media stream(stream 1).
> In practice, maybe we want to have the same media codec as original one 
> when we restore a call.
> Could you please give the call flow to reach this requirment?

The media is re-established to the caller with an offer/answer exchange.
Everything is done with sequences of offer/answer exchanges. Codec
negotiation is fundamental to this exchange. So, if the called party
decides, when its reconnected to the caller, to all of a sudden expand
its proposed list of codecs (which it may do in offer3), the caller can
pick the one it wants - which can be the one it was using before - in
the answer (answer3).

So, in summary, negotiation is already part of the flow below, and it
would allow the caller to make sure the same codec is used throughout.

-Jonathan R.

>  
> Best Regards
> Kevin
>  
>  
>      Pre-Paid User        Controller         Called Party        Media 
> Server
>           |                   |                   |                   |
>           |..........stream 1.....................|                   |
>           |                   |(1) INV SDP c=0    |                   |
>           |                   |------------------>|                   |
>           |                   |(2) 200 answer1    |                   |
>           |                   |<------------------|                   |
>           |                   |(3) ACK            |                   |
>           |                   |------------------>|                   |
>           |(4) INV no SDP     |                   |                   |
>           |<------------------|                   |                   |
>           |(5) 200 offer2     |                   |                   |
>           |------------------>|                   |                   |
>           |                   |(6) INV offer2     |                   |
>           |                   |-------------------------------------->|
>           |                   |(7) 200 answer2    |                   |
>           |                   |<--------------------------------------|
>           |(8) ACK answer2    |                   |                   |
>           |<------------------|                   |                   |
>           |                   |(9) ACK            |                   |
>           |                   |-------------------------------------->|
>           |(10) RTP           |                   |                   |
>           |..........stream 2.........................................|
>           |                   |(11) BYE           |                   |
>           |                   |-------------------------------------->|
>           |                   |(12) 200 OK        |                   |
>           |                   |<--------------------------------------|
>           |                   |(13) INV no SDP    |                   |
>           |                   |------------------>|                   |
>           |                   |(14) 200 offer3    |                   |
>           |                   |<------------------|                   |
>           |(15) INV offer3'   |                   |                   |
>           |<------------------|                   |                   |
>           |(16) 200 answer3'  |                   |                   |
>           |------------------>|                   |                   |
>           |                   |(17) ACK answer3'  |                   |
>           |                   |------------------>|                   |
>           |(18) ACK           |                   |                   |
>           |<------------------|                   |                   |
>           |(19) RTP           |                   |                   |
>           |..........stream 3.....................|                   |

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Sat Jan 25 00:12:03 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10501
	for <sipping-archive@odin.ietf.org>; Sat, 25 Jan 2003 00:12:03 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0P5VOh23595
	for sipping-archive@odin.ietf.org; Sat, 25 Jan 2003 00:31:24 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P5VOJ23592
	for <sipping-web-archive@optimus.ietf.org>; Sat, 25 Jan 2003 00:31:24 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10495
	for <sipping-web-archive@ietf.org>; Sat, 25 Jan 2003 00:11:32 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P5UUJ23535;
	Sat, 25 Jan 2003 00:30:30 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P5RGJ23454
	for <sipping@optimus.ietf.org>; Sat, 25 Jan 2003 00:27:16 -0500
Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10468
	for <sipping@ietf.org>; Sat, 25 Jan 2003 00:07:25 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.40])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0P5AvYH008512;
	Sat, 25 Jan 2003 00:10:57 -0500 (EST)
Message-ID: <3E321C5D.3050200@dynamicsoft.com>
Date: Sat, 25 Jan 2003 00:10:53 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: aki.niemi@nokia.com
CC: sipping@ietf.org
Subject: Re: [Sipping] Event notification rate limiting requirements
References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901ADD1D4@esebe013.ntc.nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Thanks for writing this up.

It seems to me that the main issue is, as you point out, how this 
relates to filters. The question really is, how is it that the notifier 
reduces the notification rate to the desired limit? I can see a few 
choices here:

1. the notifier implements a simple, package-independent algorithm that 
merely drops notifications that would cause the notification rate to be 
exceeded.

2. the notifier implements a vendor-proprietary algorithm that 
selectively discards notifications in an intelligent, package-specific 
way, meeting the desired notification rate limit.

3. the notifier implements a subscriber-provided filter, and its up to 
the definition of this filter to make sure that the rate is kept low enough

4. the notifier implements a subscriber-provided filter, and if the 
resulting notification rate is still not below the limit, it implements 
1 or 2 above.


Approach 1 is a mistake, I think. You need to intelligently filter in 
order to still provide a useful service (approach 2). In the case of 
buddy list presence, for example, the PA may choose an algorithm which 
round-robins through the buddy list, selecting the next buddy whose 
state has changed since the last notification to the watcher, and sends 
their state to the watcher. THis guarantees that no buddy is "starved" 
in terms of getting its updates through to the watcher.

I would tend to think that approach 2 (having the client provide just 
the rate, and having the server implement a proprietary algorithm to 
meet it) is useful, as is supplying a filter to limit the rate, along 
with the orthogonal combination of the two.

A few comments on the requirements:

>  REQ3: The subscriber SHOULD be allowed to indicate support for the
>          throttle mechanism without requiring it.

what is the point of this requiremetn?

>  REQ8: The notifier MUST be allowed to use a maximum rate lower than
>          the one given by the subscriber.

is this implying some kind of rate negotiation mechanism, akin to the 
Expires value in registrations? If so, there are some more requirements 
you need, such as conveying the final maximum rate back to the client.

Is the assumption that the rate is a limit on the peak transmission 
rate, or is it a leaky-bucket style limit which provides an average 
maximum but allows for small bursts?

-Jonathan R.

aki.niemi@nokia.com wrote:
 > Hi All,
 >
 > In IETF55 it was agreed that the filtering requirements need to be
 > package specific, while rate limiting might be generic across all
 > packages.
 >
 > There is now a new draft available that discusses the requirements
 > for a generic event notification rate limiting mechanism, or event
 > throttle mechanism:
 >
 > http://www.ietf.org/internet-drafts/draft-niemi-sipping-event-throttl-
 > e-reqs-00.txt
 >
 > One issue that has come up is that there are scenarios, where
 > throttles in fact need to be closely combined with event filters. For
 > example, assigning specific throttles to notifications from specific
 > presentities in a presence-list event requires that a single event
 > subscription applies several different throttles.
 >
 > So the main question is: should there be a generic throttle
 > mechanism, or are throttles event-package or filter-specific? Or do
 > we in fact need both types?
 >
 > Any comments?
 >
 > Cheers, Aki
 >
 > _______________________________________________ Sipping mailing list
 > https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW
 > development of the application of SIP Use
 > sip-implementors@cs.columbia.edu for questions on current sip Use
 > sip@ietf.org for new developments of core SIP
 >

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Sat Jan 25 03:51:39 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22080
	for <sipping-archive@odin.ietf.org>; Sat, 25 Jan 2003 03:51:39 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0P9B3p11552
	for sipping-archive@odin.ietf.org; Sat, 25 Jan 2003 04:11:03 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P9B2J11549
	for <sipping-web-archive@optimus.ietf.org>; Sat, 25 Jan 2003 04:11:03 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22075
	for <sipping-web-archive@ietf.org>; Sat, 25 Jan 2003 03:51:07 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P9AQJ11530;
	Sat, 25 Jan 2003 04:10:26 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P8v7J10324
	for <sipping@optimus.ietf.org>; Sat, 25 Jan 2003 03:57:08 -0500
Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22007
	for <sipping@ietf.org>; Sat, 25 Jan 2003 03:37:12 -0500 (EST)
From: jh@lohi.eng.song.fi
Received: from harjus.eng.song.fi ([195.10.149.20])
	by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian))
	id 18cLrj-00050f-00; Sat, 25 Jan 2003 10:40:39 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15922.19847.493726.836956@harjus.eng.song.fi>
Date: Sat, 25 Jan 2003 10:40:39 +0200
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
Cc: "'Henning Schulzrinne'" <hgs@cs.columbia.edu>,
        "'sipping@ietf.org'" <sipping@ietf.org>
Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
In-Reply-To: <313680C9A886D511A06000204840E1CF030B5D6D@whq-msgusr-02.pit.comms.marconi.com>
References: <313680C9A886D511A06000204840E1CF030B5D6D@whq-msgusr-02.pit.comms.marconi.com>
X-Mailer: VM 7.03 under Emacs 21.2.1
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Rosen, Brian writes:

 > I actually think we are best to standardize the behavior one way or
 > the other.  It is a standards issue, regardless of how we implement
 > it (if you substitute "dialing plan" for "context" your explanation
 > above makes the same argument).

i don't agree that is the task of a standards body to decide that a user
needs to always the local dial plan.  it should be up to the user to
decide if he/she wants local dialing or "home" dialing.  

one way of making this decision is by the phone's preloaded route
set.  en empty route set results in local dialing via the outbound proxy
and a route set that includes the user's home proxy results in "home"
dialing.

why would i need in addition to the preloaded route set specify the
context of the number in the tel uri?  looks to me that brian raised
the same issue.

-- juha

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Sun Jan 26 19:54:44 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24030
	for <sipping-archive@odin.ietf.org>; Sun, 26 Jan 2003 19:54:44 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0R1EwL02378
	for sipping-archive@odin.ietf.org; Sun, 26 Jan 2003 20:14:58 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0R1EwJ02375
	for <sipping-web-archive@optimus.ietf.org>; Sun, 26 Jan 2003 20:14:58 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24023
	for <sipping-web-archive@ietf.org>; Sun, 26 Jan 2003 19:54:12 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0R1ENJ02358;
	Sun, 26 Jan 2003 20:14:23 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0R1ApJ02266
	for <sipping@optimus.ietf.org>; Sun, 26 Jan 2003 20:10:51 -0500
Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23992
	for <sipping@ietf.org>; Sun, 26 Jan 2003 19:50:06 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0R0rvnB018297;
	Sun, 26 Jan 2003 19:53:58 -0500 (EST)
Received: from cisco.com (rtp-vpn1-523.cisco.com [10.82.226.11])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAY57150;
	Sun, 26 Jan 2003 19:58:09 -0500 (EST)
Message-ID: <3E3482F2.8020505@cisco.com>
Date: Sun, 26 Jan 2003 19:53:06 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: "Rosen, Brian" <Brian.Rosen@marconi.com>,
        "'Henning Schulzrinne'" <hgs@cs.columbia.edu>,
        Adam Roach <adam@dynamicsoft.com>,
        "'sipping@ietf.org'" <sipping@ietf.org>
Subject: Re: [Sipping] Do Phones Have Dial Plans, or do Proxies map?  was
 	RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
References: <313680C9A886D511A06000204840E1CF030B5D01@whq-msgusr-02.pit.comms.marconi.com> <3E320DFC.90805@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:
> 
>> However, the issue remains.  If I dial 6744 on my sip phone (and press
>> dial), the sipphone on my admin's desk should ring.  I should not have
>> to dial +17247426744.  The fact that I dialed a 4 digit number with
>> a 6 as the starting digit tells my system that it is an internal
>> extension.  A dial plan is the thing that "knows" this.
>>
>> What do you want to have happen:
>> 1) tel:6744; context=+1724742
>> 2) tel:6744; context=marconi-pittsburgh-local-extension
>> 3) tel:+17247426744
> 
> 
> The notion of an identity that exists within a local context is exactly 
> what a SIP URI is for. I always thought that if the user entered 6744, 
> the most likely result would be the following URI:
> 
> sip:6744@example.com
> 
> where example.com is the local domain, configured into the phone. Unlike 
> the tel URI, which has no clear way to determine where to go to resolve 
> a number with a local context, the SIP URI does.

I don't think there is any single right answer to this.

But if the device has the form factor of a phone, with only a number pad 
rather than a full keyboard for entering the address, then I think

	sip:6744@example.com;user=phone

would be a better choice than omitting the user=phone. This makes 
explicit a request to have the address interpretted (and probably 
expanded) as a phone number.

And I think another choice that is at least as good is:

	tel:6744;phone-context=example.com

It expresses the same intent more explicitly, and is not overtly 
dependent on the sip protocol. This doesn't matter a great deal in the 
request uri, but it might matter in the From address, because that might 
be captured by the recipient and saved for use in other contexts.

The definition of the tel: uri specifies that a local number should only 
be used if there is no global number. (This is of course helpful because 
it maximizes the number of contexts in which the address may be 
successfully used.) So ideally,

	tel:+17247426744

would really be preferred. It requires that the phone contain the dial 
plan expansion. All these other possibilities are when there are good 
reasons why that can't or shouldn't be done.

There is a lot to be said for canonical forms for addresses too. If a 
non-canonical form is used in the To address, it might not be understood 
by the recipient. For instance, suppose Alice calls Bob, but Bob has his 
calls forwarded to Charlie. Perhaps Charlie's phone checks the To 
address to see if the call was intended for him. If not it puts up a 
special indicator of a forwarded call and attempts to show who the call 
was actually for. If the To header has the full global form of the 
number called, then it is easy to figure out it is Bob's address. But if 
the To address has some local short form that makes sense only in 
Alice's domain, then Charlie's phone can't do much more than display it, 
and Charlie himself may be equally unlikely to recognize it.

	Paul

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Sun Jan 26 20:19:12 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24323
	for <sipping-archive@odin.ietf.org>; Sun, 26 Jan 2003 20:19:12 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0R1dOw03674
	for sipping-archive@odin.ietf.org; Sun, 26 Jan 2003 20:39:24 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0R1dOJ03671
	for <sipping-web-archive@optimus.ietf.org>; Sun, 26 Jan 2003 20:39:24 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24315
	for <sipping-web-archive@ietf.org>; Sun, 26 Jan 2003 20:18:41 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0R1ctJ03572;
	Sun, 26 Jan 2003 20:38:55 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0R1I2J02519
	for <sipping@optimus.ietf.org>; Sun, 26 Jan 2003 20:18:02 -0500
Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24116
	for <sipping@ietf.org>; Sun, 26 Jan 2003 19:57:17 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0R11RnW018591;
	Sun, 26 Jan 2003 20:01:27 -0500 (EST)
Received: from cisco.com (rtp-vpn1-523.cisco.com [10.82.226.11])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAY57157;
	Sun, 26 Jan 2003 20:05:39 -0500 (EST)
Message-ID: <3E3484B4.3000405@cisco.com>
Date: Sun, 26 Jan 2003 20:00:36 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: aki.niemi@nokia.com, sipping@ietf.org
Subject: Re: [Sipping] Event notification rate limiting requirements
References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901ADD1D4@esebe013.ntc.nokia.com> <3E321C5D.3050200@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:
> 
> Is the assumption that the rate is a limit on the peak transmission 
> rate, or is it a leaky-bucket style limit which provides an average 
> maximum but allows for small bursts?

This is important! For instance, I believe the limit on presence 
notifications is currently 5 seconds. Now suppose you have a phone that 
changes presence state to indicate "On the Phone". This means that there 
are two presence changes per call. Now limiting calls to one every 10 
seconds may be reasonable. But saying that you must wait 5 seconds after 
completing one call before answering another (or reporting it) isn't so 
reasonable.

	Paul

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan 27 04:26:53 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10642
	for <sipping-archive@odin.ietf.org>; Mon, 27 Jan 2003 04:26:53 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0R9lGh07350
	for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 04:47:16 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0R9lGJ07347
	for <sipping-web-archive@optimus.ietf.org>; Mon, 27 Jan 2003 04:47:16 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10638
	for <sipping-web-archive@ietf.org>; Mon, 27 Jan 2003 04:26:20 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0R9jsJ07242;
	Mon, 27 Jan 2003 04:45:55 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0R9gcJ07094
	for <sipping@optimus.ietf.org>; Mon, 27 Jan 2003 04:42:38 -0500
Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10582
	for <sipping@ietf.org>; Mon, 27 Jan 2003 04:21:43 -0500 (EST)
From: hisham.khartabil@nokia.com
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0R9Rag02669
	for <sipping@ietf.org>; Mon, 27 Jan 2003 11:27:36 +0200 (EET)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T600bcaf78dac158f24077@esvir04nok.ntc.nokia.com>;
 Mon, 27 Jan 2003 11:25:11 +0200
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Mon, 27 Jan 2003 11:25:11 +0200
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Sipping] query on conference server
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
Date: Mon, 27 Jan 2003 11:25:10 +0200
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE719B@esebe019.ntc.nokia.com>
Thread-Topic: [Sipping] query on conference server
Thread-Index: AcLD8V1kZBDfMhfVS3yM3ks8PUmAvAB9EAKQ
To: <jdrosen@dynamicsoft.com>, <alan.johnston@wcom.com>
Cc: <margaret_mary@dexceldesigns.com>, <sipping@ietf.org>
X-OriginalArrivalTime: 27 Jan 2003 09:25:11.0402 (UTC) FILETIME=[FDAE0CA0:01C2C5E5]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0R9gdJ07095
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

Is focus a conference server or an instance of a conference? I thought it was the latter, unless you mean the server of a particular conference is a focus.

Regards,
Hisham

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Friday, January 24, 2003 11:30 PM
> To: Alan Johnston
> Cc: margaretmary; sipping@ietf.org
> Subject: Re: [Sipping] query on conference server
> 
> 
> One additional note. The "models for multiparty conferencing 
> in sip" is 
> not going to move forward. Its content has been moved into 
> the framework 
> document Alan has pointed out, along with other documents that the 
> framework references.
> 
> To briefly answer your questions, a conference server (called 
> a focus in 
> SIP) is a SIP user agent. Proxies don't know anything about 
> conferences. 
> They just route requests to URIs, and a URI might represent a 
> conference.
> 
> -Jonathan R.
> 
> Alan Johnston wrote:
> > Hi Margaret,
> > 
> > There is a SIPPING design team working on conferencing.  
> Information 
> > about the work is at:
> > 
> >      http://www.softarmor.com/sipping/teams/conf/
> > 
> > I'd recommend you start reading the conferencing framework document 
> > which may answer your questions:
> > 
> >    
> > 
> http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-co
> nferencing-framework-00.txt 
> > 
> > 
> > Thanks,
> > Alan Johnston
> > WorldCom
> > sip:alan@digitalari.com
> > 
> > At 09:46 AM 1/23/2003 +0530, margaretmary wrote:
> > 
> >> hello sir,
> >>
> >> Can any one tell me about the conference server 
> application using SIP.
> >>
> >> Are these two drafts "Models for Multi Party Conferencing 
> SIP" and " A 
> >> Multi-Party Application Framework for SIP"  specify for conference 
> >> server application.
> >>
> >> Is their any other draft for this, please tell me.
> >>
> >> Is it a simple SIP User Agent required to develop 
> conference server.
> >> can SIP proxy server /Redirect server can come along with 
> conference 
> >> server.
> >>
> >> Please help me out with this.
> >> Since i am new to SIPPING
> >>
> >>
> >>
> >>
> >> Regards,
> >> Margaret
> >>
> >> --------------------------------------------------------------
> >> Dexcel Electronics Designs (P) Ltd., Bangalore, India
> > 
> > 
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sip@ietf.org for new developments of core SIP
> > 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan 27 04:47:00 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10896
	for <sipping-archive@odin.ietf.org>; Mon, 27 Jan 2003 04:46:59 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0RA7Nj08725
	for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 05:07:23 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RA7NJ08722
	for <sipping-web-archive@optimus.ietf.org>; Mon, 27 Jan 2003 05:07:23 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10893
	for <sipping-web-archive@ietf.org>; Mon, 27 Jan 2003 04:46:28 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RA6nJ08181;
	Mon, 27 Jan 2003 05:06:49 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RA38J08004
	for <sipping@optimus.ietf.org>; Mon, 27 Jan 2003 05:03:08 -0500
Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10843
	for <sipping@ietf.org>; Mon, 27 Jan 2003 04:42:13 -0500 (EST)
From: hisham.khartabil@nokia.com
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0R9m8g21869
	for <sipping@ietf.org>; Mon, 27 Jan 2003 11:48:08 +0200 (EET)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T600bddc191ac158f23077@esvir03nok.nokia.com>;
 Mon, 27 Jan 2003 11:45:42 +0200
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Mon, 27 Jan 2003 11:45:42 +0200
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Sipping] Event notification rate limiting requirements
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
Date: Mon, 27 Jan 2003 11:45:42 +0200
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE719C@esebe019.ntc.nokia.com>
Thread-Topic: [Sipping] Event notification rate limiting requirements
Thread-Index: AcLFo2oQvQGoBCg5TMCDC3ERD0GmgQARUXWA
To: <pkyzivat@cisco.com>, <jdrosen@dynamicsoft.com>
Cc: <aki.niemi@nokia.com>, <sipping@ietf.org>
X-OriginalArrivalTime: 27 Jan 2003 09:45:42.0729 (UTC) FILETIME=[DB9BA390:01C2C5E8]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0RA38J08005
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

We have to have a number here that doesn't jeopardise a service but also doesn't wake watchers susceptible to DoS attacks.

Regards,
Hisham

> -----Original Message-----
> From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Monday, January 27, 2003 3:01 AM
> To: Jonathan Rosenberg
> Cc: Niemi Aki (NMP/Helsinki); sipping@ietf.org
> Subject: Re: [Sipping] Event notification rate limiting requirements
> 
> 
> Jonathan Rosenberg wrote:
> > 
> > Is the assumption that the rate is a limit on the peak transmission 
> > rate, or is it a leaky-bucket style limit which provides an average 
> > maximum but allows for small bursts?
> 
> This is important! For instance, I believe the limit on presence 
> notifications is currently 5 seconds. Now suppose you have a 
> phone that 
> changes presence state to indicate "On the Phone". This means 
> that there 
> are two presence changes per call. Now limiting calls to one every 10 
> seconds may be reasonable. But saying that you must wait 5 
> seconds after 
> completing one call before answering another (or reporting 
> it) isn't so 
> reasonable.
> 
> 	Paul
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan 27 06:33:26 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12282
	for <sipping-archive@odin.ietf.org>; Mon, 27 Jan 2003 06:33:26 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0RBrqU14844
	for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 06:53:52 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RBrqJ14841
	for <sipping-web-archive@optimus.ietf.org>; Mon, 27 Jan 2003 06:53:52 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12279
	for <sipping-web-archive@ietf.org>; Mon, 27 Jan 2003 06:32:54 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RBrCJ14806;
	Mon, 27 Jan 2003 06:53:12 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RBpSJ14715
	for <sipping@optimus.ietf.org>; Mon, 27 Jan 2003 06:51:28 -0500
Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12227
	for <sipping@ietf.org>; Mon, 27 Jan 2003 06:30:31 -0500 (EST)
From: aki.niemi@nokia.com
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0RBWvn28066
	for <sipping@ietf.org>; Mon, 27 Jan 2003 13:32:57 +0200 (EET)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T600c40e349ac158f25117@esvir05nok.ntc.nokia.com>;
 Mon, 27 Jan 2003 13:33:59 +0200
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Mon, 27 Jan 2003 13:33:59 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Sipping] Event notification rate limiting requirements
Date: Mon, 27 Jan 2003 13:33:57 +0200
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901ADD1EB@esebe013.ntc.nokia.com>
Thread-Topic: [Sipping] Event notification rate limiting requirements
Thread-Index: AcLEMCadrtdES+TVQryKAg+tt0lgpgBpgLTQ
To: <jdrosen@dynamicsoft.com>
Cc: <sipping@ietf.org>
X-OriginalArrivalTime: 27 Jan 2003 11:33:59.0271 (UTC) FILETIME=[FBD94770:01C2C5F7]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0RBpSJ14716
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

Hi,

Comments inline.

> It seems to me that the main issue is, as you point out, how this 
> relates to filters. The question really is, how is it that 
> the notifier 
> reduces the notification rate to the desired limit? I can see a few 
> choices here:
> 
> 1. the notifier implements a simple, package-independent 
> algorithm that 
> merely drops notifications that would cause the notification 
> rate to be 
> exceeded.
> 
> 2. the notifier implements a vendor-proprietary algorithm that 
> selectively discards notifications in an intelligent, 
> package-specific 
> way, meeting the desired notification rate limit.
> 
> 3. the notifier implements a subscriber-provided filter, and 
> its up to 
> the definition of this filter to make sure that the rate is 
> kept low enough
> 
> 4. the notifier implements a subscriber-provided filter, and if the 
> resulting notification rate is still not below the limit, it 
> implements 
> 1 or 2 above.
> 
> 
> Approach 1 is a mistake, I think. You need to intelligently filter in 
> order to still provide a useful service (approach 2). In the case of 
> buddy list presence, for example, the PA may choose an 
> algorithm which 
> round-robins through the buddy list, selecting the next buddy whose 
> state has changed since the last notification to the watcher, 
> and sends 
> their state to the watcher. THis guarantees that no buddy is 
> "starved" 
> in terms of getting its updates through to the watcher.

I think this sounds reasonable. And I agree, option 1 doesn't sound usable. So in my opinion, option 4 combined with option 2 is the preferred approach.
 
> I would tend to think that approach 2 (having the client provide just 
> the rate, and having the server implement a proprietary algorithm to 
> meet it) is useful, as is supplying a filter to limit the rate, along 
> with the orthogonal combination of the two.

I agree.
 
> A few comments on the requirements:
> 
> >  REQ3: The subscriber SHOULD be allowed to indicate support for the
> >          throttle mechanism without requiring it.
>
> what is the point of this requiremetn?

This means that the client provides the rate but doesn't require that the server abide by it. This is less strict than REQ2 in which a client provided rate is required to be used by the notifier. So REQ3 tries to lay out the leaky-bucket style limit you mention below.
 
> >  REQ8: The notifier MUST be allowed to use a maximum rate lower than
> >          the one given by the subscriber.
> 
> is this implying some kind of rate negotiation mechanism, akin to the 
> Expires value in registrations? If so, there are some more 
> requirements 
> you need, such as conveying the final maximum rate back to the client.

This tries to say that the notifier is always allowed to send less frequent notifications than what the throttle indicates, e.g., based on some local policy decision. Since the client is only really interested in limiting the rate to a specific maximum, it doesn't really matter what the actual rate is as long as it stays below the given maximum.

In any case, with a very low maximum rate, say once per subscription expiration, the net effect would actually be equivalent to polling -- a throttle might limit the notifications to exactly two per subscription.

So I'm open to suggestions on whether there is a requirement here to have a way for the notifier to at least decline a client provided rate, if it is unacceptable.

> Is the assumption that the rate is a limit on the peak transmission 
> rate, or is it a leaky-bucket style limit which provides an average 
> maximum but allows for small bursts?

Both, I guess. In one model, the throttle would be given as advice to the notifier, and in the other, its use would be strictly required. In other words, a throttle could be given two ways <solution_space>with "Require" and without it.</solution_space> ;)

Overall, the model I had in mind is the one that the MWI uses. The throttle would set a minimum quarantine period for the notifications. Like in the mwi, the way notifications would be handled in this quarantine (e.g., does state get replaced and how) would have to be package specific, just like you say in option 2 above.

I'm beginning to think maybe some of this discussion should already be present in the requirements I-D?

Cheers,
Aki
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan 27 07:05:47 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13189
	for <sipping-archive@odin.ietf.org>; Mon, 27 Jan 2003 07:05:47 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0RCQEW16780
	for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 07:26:14 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RCQEJ16777
	for <sipping-web-archive@optimus.ietf.org>; Mon, 27 Jan 2003 07:26:14 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13184
	for <sipping-web-archive@ietf.org>; Mon, 27 Jan 2003 07:05:15 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RCPNJ16723;
	Mon, 27 Jan 2003 07:25:23 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RCL0J16511
	for <sipping@optimus.ietf.org>; Mon, 27 Jan 2003 07:21:00 -0500
Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13078
	for <sipping@ietf.org>; Mon, 27 Jan 2003 07:00:01 -0500 (EST)
From: hisham.khartabil@nokia.com
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0RC5ug03912
	for <sipping@ietf.org>; Mon, 27 Jan 2003 14:05:56 +0200 (EET)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T600c5be9aaac158f23077@esvir03nok.nokia.com>;
 Mon, 27 Jan 2003 14:03:30 +0200
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Mon, 27 Jan 2003 14:03:30 +0200
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Sipping] Event notification rate limiting requirements
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
Date: Mon, 27 Jan 2003 14:03:30 +0200
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE71A1@esebe019.ntc.nokia.com>
Thread-Topic: [Sipping] Event notification rate limiting requirements
Thread-Index: AcLEMCadrtdES+TVQryKAg+tt0lgpgBpgLTQAAkf2yA=
To: <aki.niemi@nokia.com>, <jdrosen@dynamicsoft.com>
Cc: <sipping@ietf.org>
X-OriginalArrivalTime: 27 Jan 2003 12:03:30.0652 (UTC) FILETIME=[1BAC91C0:01C2C5FC]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0RCL0J16512
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit



> -----Original Message-----
> From: ext aki.niemi@nokia.com [mailto:aki.niemi@nokia.com]
> Sent: Monday, January 27, 2003 1:34 PM
> To: jdrosen@dynamicsoft.com
> Cc: sipping@ietf.org
> Subject: RE: [Sipping] Event notification rate limiting requirements
> 
>
>  
> > >  REQ8: The notifier MUST be allowed to use a maximum rate 
> lower than
> > >          the one given by the subscriber.
> > 
> > is this implying some kind of rate negotiation mechanism, 
> akin to the 
> > Expires value in registrations? If so, there are some more 
> > requirements 
> > you need, such as conveying the final maximum rate back to 
> the client.
> 
> This tries to say that the notifier is always allowed to send 
> less frequent notifications than what the throttle indicates, 
> e.g., based on some local policy decision. Since the client 
> is only really interested in limiting the rate to a specific 
> maximum, it doesn't really matter what the actual rate is as 
> long as it stays below the given maximum.
> 
> In any case, with a very low maximum rate, say once per 
> subscription expiration, the net effect would actually be 
> equivalent to polling -- a throttle might limit the 
> notifications to exactly two per subscription.
> 
> So I'm open to suggestions on whether there is a requirement 
> here to have a way for the notifier to at least decline a 
> client provided rate, if it is unacceptable.
> 
> > Is the assumption that the rate is a limit on the peak transmission 
> > rate, or is it a leaky-bucket style limit which provides an average 
> > maximum but allows for small bursts?
> 
> Both, I guess. In one model, the throttle would be given as 
> advice to the notifier, and in the other, its use would be 
> strictly required. In other words, a throttle could be given 
> two ways <solution_space>with "Require" and without 
> it.</solution_space> ;)
> 

I viewed this requirement from another angle; the notifier must be also able to increase the rate limit, or simply reject the request if the rate is too low. One reason for this is that local policies at servers, say Presence server, may have a limit on the frequency of notifications for security as well as bandwidth reasons. In this case, you don't want the subscriber to override this limit, hence the requirement I state above.

To be in line with registration, one would suggest rejecting the request if rate limit is too low compared to local server policy. But is it needed? Can a server just increase the limit? Do the same reasonings applied to registration apply here? (I can't remember them anymore). Certainly a require-header type solution means rejecting the request, but lets examine the requirements first.

> I'm beginning to think maybe some of this discussion should 
> already be present in the requirements I-D?

I guess.

Regards,
Hisham


> 
> Cheers,
> Aki
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan 27 07:32:18 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14058
	for <sipping-archive@odin.ietf.org>; Mon, 27 Jan 2003 07:32:18 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0RCqkb18514
	for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 07:52:46 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RCqjJ18511
	for <sipping-web-archive@optimus.ietf.org>; Mon, 27 Jan 2003 07:52:45 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14048
	for <sipping-web-archive@ietf.org>; Mon, 27 Jan 2003 07:31:46 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RCpWJ18485;
	Mon, 27 Jan 2003 07:51:32 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RCo8J18440
	for <sipping@optimus.ietf.org>; Mon, 27 Jan 2003 07:50:08 -0500
Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14024
	for <sipping@ietf.org>; Mon, 27 Jan 2003 07:29:08 -0500 (EST)
From: aki.niemi@nokia.com
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0RCZ3g28599
	for <sipping@ietf.org>; Mon, 27 Jan 2003 14:35:03 +0200 (EET)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T600c76926fac158f23077@esvir03nok.nokia.com>;
 Mon, 27 Jan 2003 14:32:37 +0200
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Mon, 27 Jan 2003 14:32:37 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Sipping] Event notification rate limiting requirements
Date: Mon, 27 Jan 2003 14:32:37 +0200
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945132@esebe013.ntc.nokia.com>
Thread-Topic: [Sipping] Event notification rate limiting requirements
Thread-Index: AcLEMCadrtdES+TVQryKAg+tt0lgpgBpgLTQAAkf2yAAAHIVgA==
To: <hisham.khartabil@nokia.com>, <jdrosen@dynamicsoft.com>
Cc: <sipping@ietf.org>
X-OriginalArrivalTime: 27 Jan 2003 12:32:37.0594 (UTC) FILETIME=[2CEEC3A0:01C2C600]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0RCo8J18441
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

Hi Hisham,

Inline.

> > > >  REQ8: The notifier MUST be allowed to use a maximum rate 
> > lower than
> > > >          the one given by the subscriber.
> > > 
> > > is this implying some kind of rate negotiation mechanism, 
> > akin to the 
> > > Expires value in registrations? If so, there are some more 
> > > requirements 
> > > you need, such as conveying the final maximum rate back to 
> > the client.
> > 
> > This tries to say that the notifier is always allowed to send 
> > less frequent notifications than what the throttle indicates, 
> > e.g., based on some local policy decision. Since the client 
> > is only really interested in limiting the rate to a specific 
> > maximum, it doesn't really matter what the actual rate is as 
> > long as it stays below the given maximum.
> > 
> > In any case, with a very low maximum rate, say once per 
> > subscription expiration, the net effect would actually be 
> > equivalent to polling -- a throttle might limit the 
> > notifications to exactly two per subscription.
> > 
> > So I'm open to suggestions on whether there is a requirement 
> > here to have a way for the notifier to at least decline a 
> > client provided rate, if it is unacceptable.
> > 
> > > Is the assumption that the rate is a limit on the peak 
> transmission 
> > > rate, or is it a leaky-bucket style limit which provides 
> an average 
> > > maximum but allows for small bursts?
> > 
> > Both, I guess. In one model, the throttle would be given as 
> > advice to the notifier, and in the other, its use would be 
> > strictly required. In other words, a throttle could be given 
> > two ways <solution_space>with "Require" and without 
> > it.</solution_space> ;)
> > 
> 
> I viewed this requirement from another angle; the notifier 
> must be also able to increase the rate limit, or simply 
> reject the request if the rate is too low. One reason for 
> this is that local policies at servers, say Presence server, 
> may have a limit on the frequency of notifications for 
> security as well as bandwidth reasons. In this case, you 
> don't want the subscriber to override this limit, hence the 
> requirement I state above.

"Rate" may be confusing me here. In terms of quarantine period, or time between two consecutive notifications, Are you saying that the notifier should be able to increase the quarantine time, or decrease it?

If you mean increasing the time, I think that's what the requirements already say (a lower rate means higher time between notifications). And this is similar to the registrar declining with a min-expires - it's saving its own resources, by sending less frequent notifications.

If it's decrease, then I agree we would need some way for the notifier to either reject, or reject and adjust the client-given rate. I just don't see a huge need for this. If we assume more frequent notifications require more resources - this behavior would make things "worse" for the notifier.

Having said that, I believe rejecting (or making recommendations to that effect) throttles with ridiculously low rates may be a good idea, e.g., when the throttle achieves the same effect as doing a fetch every few hours or once a week...

> To be in line with registration, one would suggest rejecting 
> the request if rate limit is too low compared to local server 
> policy. But is it needed? Can a server just increase the 
> limit? Do the same reasonings applied to registration apply 
> here? (I can't remember them anymore). Certainly a 
> require-header type solution means rejecting the request, but 
> lets examine the requirements first.

To be in line with registrations, I don't think we necessarily need the ability to reject a throttle - with the above exceptions.
 
> > I'm beginning to think maybe some of this discussion should 
> > already be present in the requirements I-D?
> 
> I guess.

I'll fire up my emacs then. ;)

Cheers,
Aki
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan 27 07:38:17 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14393
	for <sipping-archive@odin.ietf.org>; Mon, 27 Jan 2003 07:38:17 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0RCwje18698
	for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 07:58:45 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RCwjJ18695
	for <sipping-web-archive@optimus.ietf.org>; Mon, 27 Jan 2003 07:58:45 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14343
	for <sipping-web-archive@ietf.org>; Mon, 27 Jan 2003 07:37:46 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RCwDJ18668;
	Mon, 27 Jan 2003 07:58:13 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RCvaJ18649
	for <sipping@optimus.ietf.org>; Mon, 27 Jan 2003 07:57:36 -0500
Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14274
	for <sipping@ietf.org>; Mon, 27 Jan 2003 07:36:37 -0500 (EST)
From: aki.niemi@nokia.com
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0RCgWg04846
	for <sipping@ietf.org>; Mon, 27 Jan 2003 14:42:32 +0200 (EET)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T600c7d6e6bac158f24077@esvir04nok.ntc.nokia.com>;
 Mon, 27 Jan 2003 14:40:07 +0200
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Mon, 27 Jan 2003 14:40:07 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Sipping] Event notification rate limiting requirements
Date: Mon, 27 Jan 2003 14:40:06 +0200
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901ADD1F0@esebe013.ntc.nokia.com>
Thread-Topic: [Sipping] Event notification rate limiting requirements
Thread-Index: AcLFn4l9vrW/NDZfQky3haoE8G0/IAAYUR1Q
To: <pkyzivat@cisco.com>, <jdrosen@dynamicsoft.com>
Cc: <sipping@ietf.org>
X-OriginalArrivalTime: 27 Jan 2003 12:40:07.0185 (UTC) FILETIME=[38E8E810:01C2C601]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0RCvaJ18650
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

Hi,

> Jonathan Rosenberg wrote:
> > 
> > Is the assumption that the rate is a limit on the peak transmission 
> > rate, or is it a leaky-bucket style limit which provides an average 
> > maximum but allows for small bursts?
> 
> This is important! For instance, I believe the limit on presence 
> notifications is currently 5 seconds. Now suppose you have a 
> phone that 
> changes presence state to indicate "On the Phone". This means 
> that there 
> are two presence changes per call. Now limiting calls to one every 10 
> seconds may be reasonable. But saying that you must wait 5 
> seconds after 
> completing one call before answering another (or reporting 
> it) isn't so 
> reasonable.

I agree. But isn't then the use of a throttle mechanism ill-adviced, if one requires more frequent updates than what a throttled subscription would give?

Cheers,
Aki
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan 27 07:48:08 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14576
	for <sipping-archive@odin.ietf.org>; Mon, 27 Jan 2003 07:48:08 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0RD8aV19817
	for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 08:08:36 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RD8aJ19814
	for <sipping-web-archive@optimus.ietf.org>; Mon, 27 Jan 2003 08:08:36 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14561
	for <sipping-web-archive@ietf.org>; Mon, 27 Jan 2003 07:47:37 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RD86J19791;
	Mon, 27 Jan 2003 08:08:06 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RD7TJ19719
	for <sipping@optimus.ietf.org>; Mon, 27 Jan 2003 08:07:29 -0500
Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14507
	for <sipping@ietf.org>; Mon, 27 Jan 2003 07:46:28 -0500 (EST)
From: hisham.khartabil@nokia.com
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0RCmun02134
	for <sipping@ietf.org>; Mon, 27 Jan 2003 14:48:56 +0200 (EET)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T600c86743fac158f25117@esvir05nok.ntc.nokia.com>;
 Mon, 27 Jan 2003 14:49:58 +0200
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Mon, 27 Jan 2003 14:49:57 +0200
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Sipping] Event notification rate limiting requirements
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
Date: Mon, 27 Jan 2003 14:49:57 +0200
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE71A8@esebe019.ntc.nokia.com>
Thread-Topic: [Sipping] Event notification rate limiting requirements
Thread-Index: AcLEMCadrtdES+TVQryKAg+tt0lgpgBpgLTQAAkf2yAAAHIVgAABLtJQ
To: <aki.niemi@nokia.com>, <jdrosen@dynamicsoft.com>
Cc: <sipping@ietf.org>
X-OriginalArrivalTime: 27 Jan 2003 12:49:57.0473 (UTC) FILETIME=[98BFB510:01C2C602]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0RD7TJ19720
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

I guess I confused myself as well as others.

Yes, lower rate means higher period of time between notifies.

I was talking about subscribers increasing the rate to a number that is higher than the server's allowed maximum. If the server has a rate limit of the typical once per 5 seconds, the subscriber must not be able to increase this rate to, say, 5 times per 5 seconds. 

So the requirement is: The notifier must be able to reject a subscription containing a rate limit higher that is local configured maximum.

You are talking about the subscriber lowering that rate to a ridiculously low rate as to once per hour. I think this is ok and no need to reject those types of requests.

Regards,
Hisham



> -----Original Message-----
> From: Niemi Aki (NMP/Helsinki) 
> Sent: Monday, January 27, 2003 2:33 PM
> To: Khartabil Hisham (NMP/Helsinki); 'jdrosen@dynamicsoft.com'
> Cc: 'sipping@ietf.org'
> Subject: RE: [Sipping] Event notification rate limiting requirements
> 
> 
> Hi Hisham,
> 
> Inline.
> 
> > > > >  REQ8: The notifier MUST be allowed to use a maximum rate 
> > > lower than
> > > > >          the one given by the subscriber.
> > > > 
> > > > is this implying some kind of rate negotiation mechanism, 
> > > akin to the 
> > > > Expires value in registrations? If so, there are some more 
> > > > requirements 
> > > > you need, such as conveying the final maximum rate back to 
> > > the client.
> > > 
> > > This tries to say that the notifier is always allowed to send 
> > > less frequent notifications than what the throttle indicates, 
> > > e.g., based on some local policy decision. Since the client 
> > > is only really interested in limiting the rate to a specific 
> > > maximum, it doesn't really matter what the actual rate is as 
> > > long as it stays below the given maximum.
> > > 
> > > In any case, with a very low maximum rate, say once per 
> > > subscription expiration, the net effect would actually be 
> > > equivalent to polling -- a throttle might limit the 
> > > notifications to exactly two per subscription.
> > > 
> > > So I'm open to suggestions on whether there is a requirement 
> > > here to have a way for the notifier to at least decline a 
> > > client provided rate, if it is unacceptable.
> > > 
> > > > Is the assumption that the rate is a limit on the peak 
> > transmission 
> > > > rate, or is it a leaky-bucket style limit which provides 
> > an average 
> > > > maximum but allows for small bursts?
> > > 
> > > Both, I guess. In one model, the throttle would be given as 
> > > advice to the notifier, and in the other, its use would be 
> > > strictly required. In other words, a throttle could be given 
> > > two ways <solution_space>with "Require" and without 
> > > it.</solution_space> ;)
> > > 
> > 
> > I viewed this requirement from another angle; the notifier 
> > must be also able to increase the rate limit, or simply 
> > reject the request if the rate is too low. One reason for 
> > this is that local policies at servers, say Presence server, 
> > may have a limit on the frequency of notifications for 
> > security as well as bandwidth reasons. In this case, you 
> > don't want the subscriber to override this limit, hence the 
> > requirement I state above.
> 
> "Rate" may be confusing me here. In terms of quarantine 
> period, or time between two consecutive notifications, Are 
> you saying that the notifier should be able to increase the 
> quarantine time, or decrease it?
> 
> If you mean increasing the time, I think that's what the 
> requirements already say (a lower rate means higher time 
> between notifications). And this is similar to the registrar 
> declining with a min-expires - it's saving its own resources, 
> by sending less frequent notifications.
> 
> If it's decrease, then I agree we would need some way for the 
> notifier to either reject, or reject and adjust the 
> client-given rate. I just don't see a huge need for this. If 
> we assume more frequent notifications require more resources 
> - this behavior would make things "worse" for the notifier.
> 
> Having said that, I believe rejecting (or making 
> recommendations to that effect) throttles with ridiculously 
> low rates may be a good idea, e.g., when the throttle 
> achieves the same effect as doing a fetch every few hours or 
> once a week...
> 
> > To be in line with registration, one would suggest rejecting 
> > the request if rate limit is too low compared to local server 
> > policy. But is it needed? Can a server just increase the 
> > limit? Do the same reasonings applied to registration apply 
> > here? (I can't remember them anymore). Certainly a 
> > require-header type solution means rejecting the request, but 
> > lets examine the requirements first.
> 
> To be in line with registrations, I don't think we 
> necessarily need the ability to reject a throttle - with the 
> above exceptions.
>  
> > > I'm beginning to think maybe some of this discussion should 
> > > already be present in the requirements I-D?
> > 
> > I guess.
> 
> I'll fire up my emacs then. ;)
> 
> Cheers,
> Aki
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan 27 07:57:27 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14814
	for <sipping-archive@odin.ietf.org>; Mon, 27 Jan 2003 07:57:27 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0RDHt920151
	for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 08:17:55 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RDHtJ20148
	for <sipping-web-archive@optimus.ietf.org>; Mon, 27 Jan 2003 08:17:55 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14802
	for <sipping-web-archive@ietf.org>; Mon, 27 Jan 2003 07:56:56 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RDHFJ20115;
	Mon, 27 Jan 2003 08:17:15 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RDGfJ20088
	for <sipping@optimus.ietf.org>; Mon, 27 Jan 2003 08:16:41 -0500
Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14782
	for <sipping@ietf.org>; Mon, 27 Jan 2003 07:55:41 -0500 (EST)
From: aki.niemi@nokia.com
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0RD1bg20838
	for <sipping@ietf.org>; Mon, 27 Jan 2003 15:01:37 +0200 (EET)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T600c8ecca5ac158f24077@esvir04nok.ntc.nokia.com>;
 Mon, 27 Jan 2003 14:59:05 +0200
Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Mon, 27 Jan 2003 14:59:05 +0200
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Mon, 27 Jan 2003 14:59:04 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Sipping] Event notification rate limiting requirements
Date: Mon, 27 Jan 2003 14:59:04 +0200
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901ADD1F2@esebe013.ntc.nokia.com>
Thread-Topic: [Sipping] Event notification rate limiting requirements
Thread-Index: AcLEMCadrtdES+TVQryKAg+tt0lgpgBpgLTQAAkf2yAAAHIVgAABLtJQAABtPjA=
To: <hisham.khartabil@nokia.com>, <jdrosen@dynamicsoft.com>
Cc: <sipping@ietf.org>
X-OriginalArrivalTime: 27 Jan 2003 12:59:04.0544 (UTC) FILETIME=[DED41E00:01C2C603]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0RDGfJ20089
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

I'm still confused... Hey, it's Monday so bear with me ;)

> I guess I confused myself as well as others.
> 
> Yes, lower rate means higher period of time between notifies.
> 
> I was talking about subscribers increasing the rate to a 
> number that is higher than the server's allowed maximum. If 
> the server has a rate limit of the typical once per 5 
> seconds, the subscriber must not be able to increase this 
> rate to, say, 5 times per 5 seconds. 
> 
> So the requirement is: The notifier must be able to reject a 
> subscription containing a rate limit higher that is local 
> configured maximum.

My point was that there is no need to reject such a limit, as long as the notifier MUST be allowed to use a lower rate. So the notifier may accept, and still abide by its own internal default policy of 1 notification per 5 seconds. The subscriber is still happy, since its max rate is not exceeded. Such a throttle will be utterly useless, but won't break anything...
 
> You are talking about the subscriber lowering that rate to a 
> ridiculously low rate as to once per hour. I think this is ok 
> and no need to reject those types of requests.

Except if the effects of such a filter become worse than for example, polling at the same frequency.

Cheers,
Aki
 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan 27 08:31:09 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15410
	for <sipping-archive@odin.ietf.org>; Mon, 27 Jan 2003 08:31:09 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0RDpaA22029
	for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 08:51:36 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RDpaJ22026
	for <sipping-web-archive@optimus.ietf.org>; Mon, 27 Jan 2003 08:51:36 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15387
	for <sipping-web-archive@ietf.org>; Mon, 27 Jan 2003 08:30:38 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RDoIJ21928;
	Mon, 27 Jan 2003 08:50:18 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RDjvJ21693
	for <sipping@optimus.ietf.org>; Mon, 27 Jan 2003 08:45:57 -0500
Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15290
	for <sipping@ietf.org>; Mon, 27 Jan 2003 08:24:56 -0500 (EST)
From: hisham.khartabil@nokia.com
Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])
	by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0RDRPn05506
	for <sipping@ietf.org>; Mon, 27 Jan 2003 15:27:25 +0200 (EET)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T600ca9ad7aac158f21084@esvir01nok.ntc.nokia.com>;
 Mon, 27 Jan 2003 15:28:27 +0200
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Mon, 27 Jan 2003 15:28:26 +0200
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Sipping] Event notification rate limiting requirements
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
Date: Mon, 27 Jan 2003 15:28:26 +0200
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE71AA@esebe019.ntc.nokia.com>
Thread-Topic: [Sipping] Event notification rate limiting requirements
Thread-Index: AcLEMCadrtdES+TVQryKAg+tt0lgpgBpgLTQAAkf2yAAAHIVgAABLtJQAABtPjAAAK2GMA==
To: <aki.niemi@nokia.com>, <jdrosen@dynamicsoft.com>
Cc: <sipping@ietf.org>
X-OriginalArrivalTime: 27 Jan 2003 13:28:26.0980 (UTC) FILETIME=[F9528240:01C2C607]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0RDjvJ21694
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit



> -----Original Message-----
> From: Niemi Aki (NMP/Helsinki) 
> Sent: Monday, January 27, 2003 2:59 PM
> To: Khartabil Hisham (NMP/Helsinki); 'jdrosen@dynamicsoft.com'
> Cc: 'sipping@ietf.org'
> Subject: RE: [Sipping] Event notification rate limiting requirements
> 
> 
> I'm still confused... Hey, it's Monday so bear with me ;)
> 
> > I guess I confused myself as well as others.
> > 
> > Yes, lower rate means higher period of time between notifies.
> > 
> > I was talking about subscribers increasing the rate to a 
> > number that is higher than the server's allowed maximum. If 
> > the server has a rate limit of the typical once per 5 
> > seconds, the subscriber must not be able to increase this 
> > rate to, say, 5 times per 5 seconds. 
> > 
> > So the requirement is: The notifier must be able to reject a 
> > subscription containing a rate limit higher that is local 
> > configured maximum.
> 
> My point was that there is no need to reject such a limit, as 
> long as the notifier MUST be allowed to use a lower rate. So 
> the notifier may accept, and still abide by its own internal 
> default policy of 1 notification per 5 seconds. The 
> subscriber is still happy, since its max rate is not 
> exceeded. Such a throttle will be utterly useless, but won't 
> break anything...


Looking at the registration solution; a registrar can lower the expiration time and therefore increase the rate of registration requests. The registrar must not increase the expiration time, i.e. registrar cannot lower the rate of registration and must reject with 423.

I don't have strong feeling either way. Any other opinions?


>  
> > You are talking about the subscriber lowering that rate to a 
> > ridiculously low rate as to once per hour. I think this is ok 
> > and no need to reject those types of requests.
> 
> Except if the effects of such a filter become worse than for 
> example, polling at the same frequency.

Polling, aka fetching, has an extra subscribe/200 that can be avoided with this mechanism.

I used this example in a separate discussion and I'll use it again here: If Aki was driving down from Lapland to Helsinki, I'm interested to get his presence info once every hour or so. By subscribing to his presence and limiting the rate of notifications to 1 per hour is a good thing. I get the notifications automatically. I don't have to manually subscribe every hour and waste bandwidth.

The only scenario where I think a subscription with rate limit may be rejected is when the rate allows 0 notifies to be sent with the subscription duration. I.e. Subscription duration is 1 hour and rate limit is once per 2 hours. I think this scenario is worse than fetching (It might be ok to accept the subscription and only generate the first notify).

Regards,
Hisham

> 
> Cheers,
> Aki
>  
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan 27 08:39:28 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15627
	for <sipping-archive@odin.ietf.org>; Mon, 27 Jan 2003 08:39:28 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0RDxtt22585
	for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 08:59:55 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RDxtJ22582
	for <sipping-web-archive@optimus.ietf.org>; Mon, 27 Jan 2003 08:59:55 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15621
	for <sipping-web-archive@ietf.org>; Mon, 27 Jan 2003 08:38:57 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RDxJJ22526;
	Mon, 27 Jan 2003 08:59:19 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RDwUJ22462
	for <sipping@optimus.ietf.org>; Mon, 27 Jan 2003 08:58:30 -0500
Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15586
	for <sipping@ietf.org>; Mon, 27 Jan 2003 08:37:31 -0500 (EST)
Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66])
	(user=hgs10 mech=PLAIN bits=0)
	by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0RDeqUP011116
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Mon, 27 Jan 2003 08:40:53 -0500 (EST)
Message-ID: <3E353700.3040506@cs.columbia.edu>
Date: Mon, 27 Jan 2003 08:41:20 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@cisco.com>
CC: Jonathan Rosenberg <jdrosen@dynamicsoft.com>, aki.niemi@nokia.com,
        sipping@ietf.org
Subject: Re: [Sipping] Event notification rate limiting requirements
References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901ADD1D4@esebe013.ntc.nokia.com> <3E321C5D.3050200@dynamicsoft.com> <3E3484B4.3000405@cisco.com>
In-Reply-To: <3E3484B4.3000405@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Complexity can get out of hand pretty quickly here. Once you have a 
leaky bucket with queueing, you have to start worrying about removing 
pending announcements that cancel each other. No point sending 'on the 
phone' 30 minutes later if the person has long since ceased talking, 
particularly since the user interface may not be able to tell whether 
this notification is still current or not, particularly after you 
gateway into other systems.

If you just drop notifications, you can get 'stuck' in the wrong state, 
like 'talking on the phone', for very long periods of time.

Paul Kyzivat wrote:
> Jonathan Rosenberg wrote:
> 
>>
>> Is the assumption that the rate is a limit on the peak transmission 
>> rate, or is it a leaky-bucket style limit which provides an average 
>> maximum but allows for small bursts?
> 
> 
> This is important! For instance, I believe the limit on presence 
> notifications is currently 5 seconds. Now suppose you have a phone that 
> changes presence state to indicate "On the Phone". This means that there 
> are two presence changes per call. Now limiting calls to one every 10 
> seconds may be reasonable. But saying that you must wait 5 seconds after 
> completing one call before answering another (or reporting it) isn't so 
> reasonable.
> 
>     Paul
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan 27 08:49:17 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15824
	for <sipping-archive@odin.ietf.org>; Mon, 27 Jan 2003 08:49:17 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0RE9jN23698
	for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 09:09:45 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RE9jJ23695
	for <sipping-web-archive@optimus.ietf.org>; Mon, 27 Jan 2003 09:09:45 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15821
	for <sipping-web-archive@ietf.org>; Mon, 27 Jan 2003 08:48:46 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RE99J23653;
	Mon, 27 Jan 2003 09:09:09 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RE8tJ23624
	for <sipping@optimus.ietf.org>; Mon, 27 Jan 2003 09:08:55 -0500
Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15790
	for <sipping@ietf.org>; Mon, 27 Jan 2003 08:47:56 -0500 (EST)
Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66])
	(user=hgs10 mech=PLAIN bits=0)
	by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0RDpNUP015299
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Mon, 27 Jan 2003 08:51:24 -0500 (EST)
Message-ID: <3E353977.2030802@cs.columbia.edu>
Date: Mon, 27 Jan 2003 08:51:51 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: hisham.khartabil@nokia.com
CC: aki.niemi@nokia.com, jdrosen@dynamicsoft.com, sipping@ietf.org
Subject: Re: [Sipping] Event notification rate limiting requirements
References: <2038BCC78B1AD641891A0D1AE133DBB7FE71AA@esebe019.ntc.nokia.com>
In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7FE71AA@esebe019.ntc.nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

> I used this example in a separate discussion and I'll use it again
> here: If Aki was driving down from Lapland to Helsinki, I'm
> interested to get his presence info once every hour or so. By
> subscribing to his presence and limiting the rate of notifications to
> 1 per hour is a good thing. I get the notifications automatically. I
> don't have to manually subscribe every hour and waste bandwidth.

There are two classes of notifications: stateless and stateful. Presence 
(closed/busy) is stateful, in that it persists at the receiver until the 
next announcement. Location is stateless - the accuracy of estimation of 
the variable just decreases as the rate of updates decreases. In many 
cases, physical constraints limit the error. If I know you are in a land 
vehicle, I can draw a circle around a last position report that 
increases its radius at around 70 mph and have high confidence that the 
entity hasn't suddenly gone into hyperspace.

It's relatively easy to ratelimit the latter, much harder to ratelimit 
the former.

> 
> The only scenario where I think a subscription with rate limit may be
> rejected is when the rate allows 0 notifies to be sent with the
> subscription duration. I.e. Subscription duration is 1 hour and rate
> limit is once per 2 hours. I think this scenario is worse than
> fetching (It might be ok to accept the subscription and only generate
> the first notify).
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan 27 09:05:38 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16069
	for <sipping-archive@odin.ietf.org>; Mon, 27 Jan 2003 09:05:37 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0REQ6924333
	for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 09:26:06 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0REQ5J24330
	for <sipping-web-archive@optimus.ietf.org>; Mon, 27 Jan 2003 09:26:05 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16062
	for <sipping-web-archive@ietf.org>; Mon, 27 Jan 2003 09:05:06 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0REPGJ24297;
	Mon, 27 Jan 2003 09:25:16 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0REO9J24241
	for <sipping@optimus.ietf.org>; Mon, 27 Jan 2003 09:24:09 -0500
Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16036
	for <sipping@ietf.org>; Mon, 27 Jan 2003 09:03:09 -0500 (EST)
From: hisham.khartabil@nokia.com
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0RE5an10828
	for <sipping@ietf.org>; Mon, 27 Jan 2003 16:05:36 +0200 (EET)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T600ccca2dcac158f25117@esvir05nok.ntc.nokia.com>;
 Mon, 27 Jan 2003 16:06:38 +0200
Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Mon, 27 Jan 2003 16:06:36 +0200
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Mon, 27 Jan 2003 16:06:36 +0200
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Sipping] Event notification rate limiting requirements
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
Date: Mon, 27 Jan 2003 16:06:36 +0200
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE71AD@esebe019.ntc.nokia.com>
Thread-Topic: [Sipping] Event notification rate limiting requirements
Thread-Index: AcLGCtMqj1YkMIuqTRqfJ5QdiRHT6wAAU3RQ
To: <hgs@cs.columbia.edu>, <pkyzivat@cisco.com>
Cc: <jdrosen@dynamicsoft.com>, <aki.niemi@nokia.com>, <sipping@ietf.org>
X-OriginalArrivalTime: 27 Jan 2003 14:06:36.0498 (UTC) FILETIME=[4DFB3B20:01C2C60D]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0REO9J24242
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

One would think that there is only one notify in the queue that gets replaced by an update to, for example, presence of a presentity.

If I am "on the phone" for 20 mins (which results in another presence state change to "available" after that), but my watcher is notified every 30 mins. Then I would expect the presence service to send the newest notify which carries the info that I'm available.

-5 mins - "available"
<-- NOTIFY to watcher "available"
0 mins - "on the phone"
20 mins - "available"
30 mins - "available"
<-- NOTIFY to watcher "available"

You don't want to queue and send all notifies, just the most recent one at the time of sending a notify.

/Hisham


> -----Original Message-----
> From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Monday, January 27, 2003 3:41 PM
> To: Paul Kyzivat
> Cc: Jonathan Rosenberg; Niemi Aki (NMP/Helsinki); sipping@ietf.org
> Subject: Re: [Sipping] Event notification rate limiting requirements
> 
> 
> Complexity can get out of hand pretty quickly here. Once you have a 
> leaky bucket with queueing, you have to start worrying about removing 
> pending announcements that cancel each other. No point 
> sending 'on the 
> phone' 30 minutes later if the person has long since ceased talking, 
> particularly since the user interface may not be able to tell whether 
> this notification is still current or not, particularly after you 
> gateway into other systems.
> 
> If you just drop notifications, you can get 'stuck' in the 
> wrong state, 
> like 'talking on the phone', for very long periods of time.
> 
> Paul Kyzivat wrote:
> > Jonathan Rosenberg wrote:
> > 
> >>
> >> Is the assumption that the rate is a limit on the peak 
> transmission 
> >> rate, or is it a leaky-bucket style limit which provides 
> an average 
> >> maximum but allows for small bursts?
> > 
> > 
> > This is important! For instance, I believe the limit on presence 
> > notifications is currently 5 seconds. Now suppose you have 
> a phone that 
> > changes presence state to indicate "On the Phone". This 
> means that there 
> > are two presence changes per call. Now limiting calls to 
> one every 10 
> > seconds may be reasonable. But saying that you must wait 5 
> seconds after 
> > completing one call before answering another (or reporting 
> it) isn't so 
> > reasonable.
> > 
> >     Paul
> > 
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sip@ietf.org for new developments of core SIP
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan 27 09:17:34 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16276
	for <sipping-archive@odin.ietf.org>; Mon, 27 Jan 2003 09:17:34 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0REc2d25431
	for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 09:38:02 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0REc2J25428
	for <sipping-web-archive@optimus.ietf.org>; Mon, 27 Jan 2003 09:38:02 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16264
	for <sipping-web-archive@ietf.org>; Mon, 27 Jan 2003 09:17:02 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0REbHJ25160;
	Mon, 27 Jan 2003 09:37:17 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0REa1J24698
	for <sipping@optimus.ietf.org>; Mon, 27 Jan 2003 09:36:01 -0500
Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16236
	for <sipping@ietf.org>; Mon, 27 Jan 2003 09:15:01 -0500 (EST)
From: hisham.khartabil@nokia.com
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0REKtg01014
	for <sipping@ietf.org>; Mon, 27 Jan 2003 16:20:55 +0200 (EET)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T600cd7813cac158f24077@esvir04nok.ntc.nokia.com>;
 Mon, 27 Jan 2003 16:18:30 +0200
Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Mon, 27 Jan 2003 16:18:30 +0200
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Mon, 27 Jan 2003 16:18:29 +0200
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Sipping] Event notification rate limiting requirements
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
Date: Mon, 27 Jan 2003 16:18:29 +0200
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE71AE@esebe019.ntc.nokia.com>
Thread-Topic: [Sipping] Event notification rate limiting requirements
Thread-Index: AcLGCzPKBHKM8ZC6TMOnBGpkQebmRQAAl6tA
To: <hgs@cs.columbia.edu>
Cc: <aki.niemi@nokia.com>, <jdrosen@dynamicsoft.com>, <sipping@ietf.org>
X-OriginalArrivalTime: 27 Jan 2003 14:18:29.0738 (UTC) FILETIME=[F71B04A0:01C2C60E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0REa1J24699
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

If the presence info sent to the watcher is the most recently available, then fetching is no more accurate than what I described. If the location entity, that reports one's position to the presence server, only sends updates every 30 mins, and the presence server sends the watcher that last presence update when the rate limit allows it to, then its as accurate as it can get, stateless or not.

Regards,
Hisham 

> -----Original Message-----
> From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Monday, January 27, 2003 3:52 PM
> To: Khartabil Hisham (NMP/Helsinki)
> Cc: Niemi Aki (NMP/Helsinki); jdrosen@dynamicsoft.com; 
> sipping@ietf.org
> Subject: Re: [Sipping] Event notification rate limiting requirements
> 
> 
> > I used this example in a separate discussion and I'll use it again
> > here: If Aki was driving down from Lapland to Helsinki, I'm
> > interested to get his presence info once every hour or so. By
> > subscribing to his presence and limiting the rate of 
> notifications to
> > 1 per hour is a good thing. I get the notifications automatically. I
> > don't have to manually subscribe every hour and waste bandwidth.
> 
> There are two classes of notifications: stateless and 
> stateful. Presence 
> (closed/busy) is stateful, in that it persists at the 
> receiver until the 
> next announcement. Location is stateless - the accuracy of 
> estimation of 
> the variable just decreases as the rate of updates decreases. In many 
> cases, physical constraints limit the error. If I know you 
> are in a land 
> vehicle, I can draw a circle around a last position report that 
> increases its radius at around 70 mph and have high 
> confidence that the 
> entity hasn't suddenly gone into hyperspace.
> 
> It's relatively easy to ratelimit the latter, much harder to 
> ratelimit 
> the former.
> 
> > 
> > The only scenario where I think a subscription with rate 
> limit may be
> > rejected is when the rate allows 0 notifies to be sent with the
> > subscription duration. I.e. Subscription duration is 1 hour and rate
> > limit is once per 2 hours. I think this scenario is worse than
> > fetching (It might be ok to accept the subscription and 
> only generate
> > the first notify).
> > 
> 
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan 27 09:40:55 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16503
	for <sipping-archive@odin.ietf.org>; Mon, 27 Jan 2003 09:40:55 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0RF1OS26287
	for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 10:01:24 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RF1OJ26284
	for <sipping-web-archive@optimus.ietf.org>; Mon, 27 Jan 2003 10:01:24 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16498
	for <sipping-web-archive@ietf.org>; Mon, 27 Jan 2003 09:40:23 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RF0cJ26255;
	Mon, 27 Jan 2003 10:00:38 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RExQJ26150
	for <sipping@optimus.ietf.org>; Mon, 27 Jan 2003 09:59:26 -0500
Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16483
	for <sipping@ietf.org>; Mon, 27 Jan 2003 09:38:25 -0500 (EST)
Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66])
	(user=hgs10 mech=PLAIN bits=0)
	by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0REfndS011892
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Mon, 27 Jan 2003 09:41:50 -0500 (EST)
Message-ID: <3E354548.4030908@cs.columbia.edu>
Date: Mon, 27 Jan 2003 09:42:16 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@cisco.com>
CC: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "Rosen, Brian" <Brian.Rosen@marconi.com>,
        Adam Roach <adam@dynamicsoft.com>,
        "'sipping@ietf.org'" <sipping@ietf.org>
Subject: Re: [Sipping] Do Phones Have Dial Plans, or do Proxies map?  was
 	RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
References: <313680C9A886D511A06000204840E1CF030B5D01@whq-msgusr-02.pit.comms.marconi.com> <3E320DFC.90805@dynamicsoft.com> <3E3482F2.8020505@cisco.com>
In-Reply-To: <3E3482F2.8020505@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

> I don't think there is any single right answer to this.

But we may be able to avoid many of the fruitless discussions by 
recommending easier alternatives in certain cases. Let me try to 
summarize and see if we can agree on this:

- For web pages and other non-SIP contexts such as address books, global 
tel URIs are preferred since they avoid extraneous information. Local 
tel URIs would be used only in exceptional cases, but the context is 
extremely important here in case a web page "leaks" to another context.

- For SIP phones, local dialplans should translate dialed digits into 
either global tel URIs or SIP URIs within either the local SIP domain 
(if the dialing plan is local) or the user's AOR domain. This affords 
maximum flexibility - users can decide whether they want to take their 
dialing plan with them or use the local one in places they visit.

One way to learn about the dialing plan is to send OPTIONS to the 
outbound proxy (found via DHCP, say), either directly or via content 
indirection.

- If there is no dialing plan, a translation into a SIP URI with the 
digits + local domain seems safest.

- Local tel URIs without context MUST NOT be used in From and Reply-To, 
Local tel URIs with context SHOULD NOT be used in that context.

- Local tel URIs without context are a bad idea in To headers. My 
inclination is MUST NOT. (This is nothing new, since context is required 
anyway.)

- There may be cases for a context-based local tel URI in SIP phones, 
but I'm having a hard time seeing the advantage compared to the SIP URI 
with user=phone. The SIP URI allows much more flexibility in terms of 
who does the resolution, rather than just rejecting out-of-context URIs.

- Given the above, I can't see a case for a context-free local tel URI 
(tel:1234). Using a SIP URI seems much less likely to cause trouble and 
requires no more configuration beyond knowing the outbound proxy server.

I'm considering adding a non-normative annex to 2806bis to capture these 
guidelines.


> 
> But if the device has the form factor of a phone, with only a number pad 
> rather than a full keyboard for entering the address, then I think
> 
>     sip:6744@example.com;user=phone
> 
> would be a better choice than omitting the user=phone. This makes 
> explicit a request to have the address interpretted (and probably 
> expanded) as a phone number.
> 
> And I think another choice that is at least as good is:
> 
>     tel:6744;phone-context=example.com
> 
> It expresses the same intent more explicitly, and is not overtly 
> dependent on the sip protocol. This doesn't matter a great deal in the 
> request uri, but it might matter in the From address, because that might 
> be captured by the recipient and saved for use in other contexts.
> 
> The definition of the tel: uri specifies that a local number should only 
> be used if there is no global number. (This is of course helpful because 
> it maximizes the number of contexts in which the address may be 
> successfully used.) So ideally,
> 
>     tel:+17247426744
> 
> would really be preferred. It requires that the phone contain the dial 
> plan expansion. All these other possibilities are when there are good 
> reasons why that can't or shouldn't be done.
> 
> There is a lot to be said for canonical forms for addresses too. If a 
> non-canonical form is used in the To address, it might not be understood 
> by the recipient. For instance, suppose Alice calls Bob, but Bob has his 
> calls forwarded to Charlie. Perhaps Charlie's phone checks the To 
> address to see if the call was intended for him. If not it puts up a 
> special indicator of a forwarded call and attempts to show who the call 
> was actually for. If the To header has the full global form of the 
> number called, then it is easy to figure out it is Bob's address. But if 
> the To address has some local short form that makes sense only in 
> Alice's domain, then Charlie's phone can't do much more than display it, 
> and Charlie himself may be equally unlikely to recognize it.
> 
>     Paul

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan 27 09:53:11 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16757
	for <sipping-archive@odin.ietf.org>; Mon, 27 Jan 2003 09:53:10 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0RFDex27374
	for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 10:13:40 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RFDeJ27371
	for <sipping-web-archive@optimus.ietf.org>; Mon, 27 Jan 2003 10:13:40 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16677
	for <sipping-web-archive@ietf.org>; Mon, 27 Jan 2003 09:52:39 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RFDBJ27335;
	Mon, 27 Jan 2003 10:13:11 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RFCDJ27308
	for <sipping@optimus.ietf.org>; Mon, 27 Jan 2003 10:12:13 -0500
Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16661
	for <sipping@ietf.org>; Mon, 27 Jan 2003 09:51:13 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0REtEdi021969;
	Mon, 27 Jan 2003 09:55:15 -0500 (EST)
Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAY58909;
	Mon, 27 Jan 2003 09:59:26 -0500 (EST)
Message-ID: <3E354820.5010401@cisco.com>
Date: Mon, 27 Jan 2003 09:54:24 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: sipping@ietf.org
CC: Henning Schulzrinne <hgs@cs.columbia.edu>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>, aki.niemi@nokia.com,
        hisham.khartabil@nokia.com
Subject: Re: [Sipping] Event notification rate limiting requirements
References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901ADD1D4@esebe013.ntc.nokia.com> <3E321C5D.3050200@dynamicsoft.com> <3E3484B4.3000405@cisco.com> <3E353700.3040506@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Replying to a bunch of comments:

My point is that a single number, strictly enforced, isn't sufficient to 
achieve this. In general it may be rare for a call to last less than 30 
seconds, so I am satisfied to limit to an average rate of no more than 2 
notifications per 30 seconds. But limiting to one notification per 15 
seconds may be unacceptable, because in general it means 15 seconds of 
idle time before another call.

Hisham's approach has a fatal flaw. Suppose I want to call you, but you 
are on the phone most of the time - you take 30 second breaks between 30 
minute phone calls. At what rate must you accept notifications in order 
to have a chance to get a call through to me? If there is no averaging, 
you probably have to set your rate at no less than 4/minute (15 seconds) 
to have a chance. But you don't want to be getting them at that rate 
continuously.

Perhaps it is sufficient to specify this as two numbers: N/T. (Than is, 
N notifications per time interval T.) At least that seems sufficient for 
this case. And it isn't inordinately complex to implement.

So, as a client you will in general get better results with (X*N)/(X*T) 
than with N/T, at the cost of some potential bursts of X messages. In my 
example an X of 2 is sufficient because the presentity is alternating 
between two states.

	Paul

hisham.khartabil@nokia.com wrote:
 > We have to have a number here that doesn't jeopardise a service but 
also doesn't wake watchers susceptible to DoS attacks.

aki.niemi@nokia.com wrote:
 >
 > I agree. But isn't then the use of a throttle mechanism ill-adviced, 
if one requires more frequent updates than what a throttled subscription 
would give?

Henning Schulzrinne wrote:
> Complexity can get out of hand pretty quickly here. Once you have a 
> leaky bucket with queueing, you have to start worrying about removing 
> pending announcements that cancel each other. No point sending 'on the 
> phone' 30 minutes later if the person has long since ceased talking, 
> particularly since the user interface may not be able to tell whether 
> this notification is still current or not, particularly after you 
> gateway into other systems.
> 
> If you just drop notifications, you can get 'stuck' in the wrong state, 
> like 'talking on the phone', for very long periods of time.

hisham.khartabil@nokia.com wrote:
> One would think that there is only one notify in the queue that gets replaced by an update to, for example, presence of a presentity.
> 
> If I am "on the phone" for 20 mins (which results in another presence state change to "available" after that), but my watcher is notified every 30 mins. Then I would expect the presence service to send the newest notify which carries the info that I'm available.
> 
> -5 mins - "available"
> <-- NOTIFY to watcher "available"
> 0 mins - "on the phone"
> 20 mins - "available"
> 30 mins - "available"
> <-- NOTIFY to watcher "available"
> 
> You don't want to queue and send all notifies, just the most recent one at the time of sending a notify.

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan 27 14:10:12 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23138
	for <sipping-archive@odin.ietf.org>; Mon, 27 Jan 2003 14:10:12 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0RJUmC10870
	for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 14:30:48 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RJUmJ10867
	for <sipping-web-archive@optimus.ietf.org>; Mon, 27 Jan 2003 14:30:48 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23133
	for <sipping-web-archive@ietf.org>; Mon, 27 Jan 2003 14:09:41 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RJQWJ10690;
	Mon, 27 Jan 2003 14:26:32 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RJNvJ10588
	for <sipping@optimus.ietf.org>; Mon, 27 Jan 2003 14:23:57 -0500
Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22955
	for <sipping@ietf.org>; Mon, 27 Jan 2003 14:02:48 -0500 (EST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA23904;
	Mon, 27 Jan 2003 14:06:13 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA12356;
	Mon, 27 Jan 2003 14:06:11 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19)
	id <D3QL7KX6>; Mon, 27 Jan 2003 14:06:10 -0500
Message-ID: <313680C9A886D511A06000204840E1CF030B5D74@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Henning Schulzrinne'" <hgs@cs.columbia.edu>
Cc: "'sipping@ietf.org'" <sipping@ietf.org>
Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
Date: Mon, 27 Jan 2003 14:06:08 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

I can see including a context token as a confirmation, or even selection
of the dial plan domain to be interpreted by a proxy.  I see the value.  
The text in 2806bis can get considerably smaller and more focused, right?
It would seem that most of the confusion on context then goes away.

So, summarizing:
 a) The preferred mechanism is UA has dialing plan.  We will standardize
	a notation, and a method to learn it
 b) We support a proxy translation of dial string to routable numbers.  
	We should choose ONE way to send a dial string.  
	I personally like sip:dialsting@domain, with or without user=phone.

	It could have the context parameter.
	If we use a tel uri, then text in 2806bis about dial strings must
change
 c) The context is either learned from the environment (DHCP?), 
	or provisioned.  It is always included in the URI when the number
	is not known to be directly routable (not correct to say global)

A UAC either expands dialstrings to routable numbers and emits a tel uri,
or it sends dialstrings with a context.  A proxy server either routes
a tel uri without a context, or expands a dialstring to a routable uri
from the dialstring+context.

Contexts need to be unique within the domain of a proxy server and all
the UAs that might get service from it.  I think that if you allow
contexts to be provisioned in the phone, that we should have some kind
of naming convention or something.  If they were always learned, then
they would just have to be unique within the domain they were learned
from.



Brian

> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Friday, January 24, 2003 6:03 PM
> To: Rosen, Brian
> Cc: 'sipping@ietf.org'
> Subject: Re: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
> 
> 
> > As yet another example, what is my context?  Is it "Marconi 
> Pittsburgh".
> > Is that globally unique?  Or is it "+1724742"?  That's 
> globally unique,
> > but may or may not be useable by my first hop proxy.
> 
> The point is that you and your first hop proxy better agree on 
> something, choosing one of the mechanism in 2806bis, such as 
> a prefix or 
> a domain name. What you pick is immaterial - it is invisible 
> to the user.
> 
> If you can't agree on that, it is very unlikely that you can agree on 
> what actually happens in the translation. Once you have automated 
> configuration (at the device, AOR or outbound proxy level), 
> it doesn't 
> matter what it is called, as long as you pick something 
> that's unique. 
> 2806bis provides two reasonable mechanisms. I don't see this 
> as an issue.
> 
> > 
> > I think we either get rid of it, making the dialing plan 
> the last word,
> > or make the dialing plan the job of the first hop proxy.  I 
> fail to see
> > the advantage of dialing plan in the UA and first hop proxy 
> interpreting
> > context.
> 
> You would never have both at the same time in the same 
> installation, but 
> I don't think we're in the business of picking architectures here. My 
> proposal allows choice. If you don't like to run context in your 
> products or installation, don't. I happen to think that 
> UA-translation 
> is best, as it is in the endsystem-is-smart spirit, but 
> others seem to 
> want proxy translation. Proxy translation without context is 
> extremely 
> brittle.
> 
> 
> > To me, that makes context even less interesting.  You require the
> > first hop proxy to understand all contexts that could be 
> generated by
> > any UA it serves.  That would make it pretty hard for you to bring
> > your office phone home if your ISP provided your first hop proxy. 
> > 
> > I think it's best to either have the dialing plan have to make sense
> > to the first hop proxy (by making the local domain the source of
> > the dialing plan, your #2 above), or make the proxy responsible for
> > turning digit strings into routable numbers.  I don't see enough
> > utility in having the dialing plan associated with the phone itself.
> 
> The point is that I want to be warned if the translation is done by 
> somebody that shouldn't. This becomes even more important 
> when you put 
> tel URIs on web pages.
> 
> Henning
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan 27 14:12:06 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23218
	for <sipping-archive@odin.ietf.org>; Mon, 27 Jan 2003 14:12:06 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0RJWgi10977
	for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 14:32:42 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RJWgJ10974
	for <sipping-web-archive@optimus.ietf.org>; Mon, 27 Jan 2003 14:32:42 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23196
	for <sipping-web-archive@ietf.org>; Mon, 27 Jan 2003 14:11:35 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RJV9J10911;
	Mon, 27 Jan 2003 14:31:09 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RJUUJ10853
	for <sipping@optimus.ietf.org>; Mon, 27 Jan 2003 14:30:30 -0500
Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23112
	for <sipping@ietf.org>; Mon, 27 Jan 2003 14:09:22 -0500 (EST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA24227;
	Mon, 27 Jan 2003 14:12:49 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA13098;
	Mon, 27 Jan 2003 14:12:46 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19)
	id <D3QL7K67>; Mon, 27 Jan 2003 14:12:45 -0500
Message-ID: <313680C9A886D511A06000204840E1CF030B5D76@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Paul Kyzivat'" <pkyzivat@cisco.com>,
        Henning Schulzrinne
	 <hgs@cs.columbia.edu>
Cc: "'Christer Holmberg'" <christer.holmberg@lmf.ericsson.se>,
        "'jh@lohi.eng.song.fi'" <jh@lohi.eng.song.fi>,
        "Conroy, Lawrence (SMTP)"
	 <lwc@roke.co.uk>,
        "'sipping@ietf.org'" <sipping@ietf.org>
Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
Date: Mon, 27 Jan 2003 14:12:44 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

This is actually an interesting problem.
In my environment, if I dial 304-3859, then I would
show my FROM as 300-7826, because if I'm calling within
my local network, then my network number is the best way
to call me back.  If I call the same fellow at
703-455-7826, then I might show my +17247426826 as
my From:

If I had the dialing plan in the UA, I could do this.
If the expansion is in a proxy, it can't modify From:.

I don't think we do anything about it.  It's more argument
why dial plan expansion in the UA is a better way to go.

Brian

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Friday, January 24, 2003 6:42 PM
> To: Henning Schulzrinne
> Cc: Rosen, Brian; 'Christer Holmberg'; 'jh@lohi.eng.song.fi'; Conroy,
> Lawrence (SMTP); 'sipping@ietf.org'
> Subject: Re: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
> 
> 
> Henning Schulzrinne wrote:
> > There seem to be at least three scenarios:
> > 
> > (1) The end system has a dialplan, learned automatically, 
> and can easily 
> > translate dialed digits into an E.164 number. ...  It also 
> allows inspection
> > - a device can easily display what will happen to a digit 
> string. If the 
> > proxy does translation, you only find out when what you 
> thought was a 
> > local extension gets translated to dial-a-prayer. (Or, 
> worse, doesn't 
> > get answered at all, in which case one may not suspect 
> anything amiss.)
> 
> There is a solution to this problem when using proxy expansion: The 
> proxy can do the expansion and then return the result as a redirect 
> (probably 301). The phone will then retry, but can display 
> the new number.
> 
> But this doesn't work for From. The calling phone had better know an 
> expanded form of its own address.
> 
> 	Paul
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan 27 14:22:45 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23482
	for <sipping-archive@odin.ietf.org>; Mon, 27 Jan 2003 14:22:45 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0RJhL812109
	for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 14:43:21 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RJhLJ12106
	for <sipping-web-archive@optimus.ietf.org>; Mon, 27 Jan 2003 14:43:21 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23477
	for <sipping-web-archive@ietf.org>; Mon, 27 Jan 2003 14:22:13 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RJdAJ11964;
	Mon, 27 Jan 2003 14:39:10 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RJcrJ11929
	for <sipping@optimus.ietf.org>; Mon, 27 Jan 2003 14:38:53 -0500
Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23340
	for <sipping@ietf.org>; Mon, 27 Jan 2003 14:17:45 -0500 (EST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA24559;
	Mon, 27 Jan 2003 14:21:14 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA13888;
	Mon, 27 Jan 2003 14:21:16 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19)
	id <D3QL7LA2>; Mon, 27 Jan 2003 14:21:15 -0500
Message-ID: <313680C9A886D511A06000204840E1CF030B5D78@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Paul Kyzivat'" <pkyzivat@cisco.com>
Cc: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>,
        "'sipping@ietf.org'"
	 <sipping@ietf.org>
Subject: RE: [Sipping] URIs for Gateways
Date: Mon, 27 Jan 2003 14:21:13 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

Sorry about the tardy reply
> Some of your comments seem so confusing to me that I think I must be 
> misunderstanding them in some fundamental way.
> 
> Are you talking about a situation where a particular port on 
> a gateway 
> is intended to map 1:1 to a particular phone number in the 
> PSTN and to a 
> particular sip uri in the sip network? (To be specific, lets 
> call these 
> +1-987-654-3210, sip:foo@bar.com, sip:port3@gw.bar.com.)
Yes, or at least, yes for many interesting systems
There are two cases:
	a) the SIP system is the only phone system at the site,
		gateways are connected to the PSTN.  For small
		sites, you have one line of gateway per user to
		get CallerID correct.  If you don't need outgoing
		CallerId, then you can use "pool" mode and this
		problem doesn't arise.  For large sites, you use
		PRI and the outgoing callerId is set by the gateway.

	b) The sip system is connected to a PBX.  In this case
		you are pretty much forced to have port of gateway
		per user unless you can have a PRI interface to the
		PBX operating as a "remote". 
  
> Do you then want take all outbound calls to the pstn from 
> sip:foo@bar to 
> be routed thru sip:port3@gw.bar.com, and all inbound calls 
> from the pstn 
> to arrive at port3 on the gateway and then be sent to sip:foo@bar.com?
Yes if it's a small site and line per gateway.  With PRI type
gateways the port number often doesn't matter (although it may).
> 
> If the above are true, do you then want to put knowledge of these 
> mappings in your translator proxy rather than in the gateway?
Many small gateways have the mappings in the gateway.  Many larger
gateways don't.  The reason we use a translator is mostly because
the sipphones don't "know" their PSTN numbers, they know their
SIP identities, and even if they did, they don't put both numbers
out on an INVITE.  You don't have to do that, but it's pretty 
helpful.

> 
> Under those assumptions, I can start to make some sense of your 
> comments. If the gw always sends inbound calls from the pstn to the 
> translator, putting the port address (sip:port2@gw.bar.com) 
> in the From 
> header, then I suppose the translator could use the from 
> address to map 
> sip:port3@gw.bar.com to sip:foo@bar.com.
Most gateways we have use the port number as the user in the From.
Yes, the translator can map.  Gateways that have mapping functions
can send calls directly to the associated user, meaning you don't
need the translator, but some of the larger gateways don't map.

> 
> But it seems like an odd thing to do. It would make way more 
> sense to me 
> in this case for the gw to put tel:+1-987-654-3210 in the To 
> and request 
> addresses, and then send the request to the translator. The 
> translator 
> could then look that up and forward the request to sip:foo@bar.com.
Not really arguing with you.  I think that is better.  It's not
what most of them do, although I've seen a couple that do.

> 
> Going the other way - a call from sip:foo@bar.com to some 
> phone number 
> in the pstn (e.g. +1-789-456-0123), I would expect the UAC to put its 
> own address in the From, and a tel: uri in the To and request 
> uris. Then 
> it would probably deliver this to the translator. The 
> translator would 
> look up +1-789-456-0123,  and discover it isn't in the sip 
> network and 
> so must be in the pstn. Given the assumptions I think you are 
> making, it 
> would then decide it must route this call to the gateway port 
> associated 
> with the caller. So it would look up the From address 
> (sip:foo@bar.com) 
> and translate it to a gateway address (sip:port3@gw.bar.com) 
> and forward 
> the request there. But that breaks down, because the gw has 
> no good way 
> to learn called number.
right
> 
> This simplest answer I can see to this is for the translator 
> to simply 
> translate the From address to the FQDN of the gateway, and 
> then to use 
> that to convert the request address from tel: format to sip format: 
> <sip:+1-789-456-0123@gw.bar.com;user=phone> and also insert an NAI of 
> the caller as tel:+1-987-654-3210. This gets the call to the right 
> gateway with the necessary information. It would be up to the 
> gateway to 
> figure out that calls from NAI tel:+1-987-654-3210 should use port3.
Yes, that could work, but you lose the port number.  The gateway may
need to know what port number to use.  It actually is not much of
a problem, because mapping gateways usually map the From: sip identity 
into which port to use.  The bigger gateways which tend to not
have mapping usually don't need ports (next available DS0 is
usually enough).  However, I don't think you can REQUIRE mapping in
small gateways, and if there is trunk differentiation on a large
gateway, you may have to differentiate ports.  For example, you may
have local (ILEC) trunks on ports 1-4 and long distance (IXC) trunks
on ports 5-7.  A proxy that did least cost routing would need to
specify the port (actually, a port group would be best).

> 
> Further comments inline below.
> 
> 	Paul
> 
> Rosen, Brian wrote:
> > 
> > Let's start with inbound calls.  The gateway has calling and called
> > numbers, it may have a calledId name.  If it has mapping, it has the
> > sip URI of the intended recipient.  I now see that this works:
> > 
> > The text of 3325 talks about asserting the identity of the entity
> > the message is from.  For an inbound call, this is really 
> the gateway,
> > but in this case, I think we would assume that we would use it for
> > the calling party identity as you say.  Two of them can be 
> used to get
> > both the number and the name.  The Request URI, if the gateway
> > has mapping, could be the end UAS, but if it doesn't, 
> either it has to be
> > a translator URI, or it just sends it with a tel URI, and 
> the proxies
> > handle it. 
> 
> The last makes the most sense to me.
> 
> > The gateway could use a tel URI as the From field which
> > would be the called party number,
>                 ^^^^^^
>                 calling???
> 
> I hope this was a typo. Why would you put the *called* number in the 
>  From field?
I was confused.  This confuses me often, sorry.
Let's see, the gateway knows:
What port the call came in on
The callerId information from the call (calling party name 
  and number).
Some gateways would know the called party number, 
  but not all would.

Every gateway can be told where to send INVITES.  Gateways
that map have a URI per port.  Gateways that don't either have
a fixed URI, or a domain+calling number.  It never made too
much sense to me to used the calling number in the Request-URI,
but I can show you several gateways that do that.
> 
> > but it would have to get the port
> > number in as a parameter to the tel URI because if translation is
> > needed, that information is essential to the translation.
> 
> Why? It would be a lot simpler if the gw at least knew, or could get, 
> the phone number corresponding to each port, so it can form a 
> tel: uri 
> to use as the To address. Then the translator will have 
> something useful 
> to work from.
> 
> > If the gateway doesn't have translation, the translator takes the
> > called party from the Request URI, or if necessary, the From:
>                                                            ^^^^^
>                                                            ?????
> The above is still worrying me.
> 
> > and changes the Request URI to the sip URI of the UAS.  Okay,
> > that works.  Never saw a gateway that came even close to it (okay,
> > well I've seen some gateways take a tel uri in the Request URI 
> > for the calling number), but it seems to work.
> > 
> > On outgoing calls, the originating UAC could construct a tel URI, 
> > or a phone number@gateway sip uri for the Request URI and To: and 
> > it would clearly put it's sip URI, not it's phone number in 
> the From. 
> > If there was a translator, it would put a P-Asserted-Identity of the
> >>From (the sip UAC) as a phone number (and name if it wanted).  
> 
> Tat seems ok.
> 
> > It would have to add the port number to the Request URI as 
> a parameter
> > to the tel URI and forward it to the gateway. 
> 
> See above for a way to finesse this.
> 
>  > I guess the UAC could
> > put the P-Asserted-Identity in the original INVITE just 
> like the gateway
> > does if there is no translator.  I'm not sure I understand how
> > routing is done if the proxy that knows which gateway is associated
> > with the user's line (or destination phone number if that's 
> the routing
> > decision) would construct a Request URI with the port@gateway 
> > addressing and still keep the number to dial.  That means the
> > routing gateway has to be next-to-last proxy in the path, which is
> > clearly not always true. 
> 
> Possible answer above.
> 
> > Probably not the thread for a discussion like this, but it does seem
> > to me that the "right" way we want to move to is to have the UAC set
> > identity correctly, and have the trusted proxy sign it to 
> authenticate
> > it.  I think there is then no reason to keep P-Asserted-Identity for
> > any NAI application, including 3G and PSTN interwork.  The only
> > thing that won't do is allow the "trusted" network to have some
> > identity that the UAC is unaware of.  I don't think that is a good
> > plan although you still need the phone number AND the UAC sip uri,
> > which is what we are really talking about, so the P-A-I morphs
> > into a UAC (or local, untrusted, proxy) thing, and not a trusted
> > proxy thing, and the trusted proxy signs it, authenticating it.
> 
> I'm not confident that I understand all the issues yet. Jon's 
> proposal 
> seems pretty heavyweight - so I am not yet confident that it can be a 
> total solution on its own. Also, I think as long as we have 
> to deal with 
> the PSTN, which assumes trusted network components, we may 
> continue to 
> need the NAI approach. But maybe not.
> 
> 	Paul
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan 27 14:32:18 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23770
	for <sipping-archive@odin.ietf.org>; Mon, 27 Jan 2003 14:32:18 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0RJqtS12444
	for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 14:52:55 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RJqsJ12441
	for <sipping-web-archive@optimus.ietf.org>; Mon, 27 Jan 2003 14:52:54 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23728
	for <sipping-web-archive@ietf.org>; Mon, 27 Jan 2003 14:31:46 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RJp9J12347;
	Mon, 27 Jan 2003 14:51:09 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RJlSJ12206
	for <sipping@optimus.ietf.org>; Mon, 27 Jan 2003 14:47:28 -0500
Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23582
	for <sipping@ietf.org>; Mon, 27 Jan 2003 14:26:20 -0500 (EST)
Received: from cia.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0RJUYN9016031;
	Mon, 27 Jan 2003 14:30:34 -0500 (EST)
Received: from mhammer-w2k02.cisco.com (hrn2-dhcp-161-44-87-77.cisco.com [161.44.87.77])
	by cia.cisco.com (Mirapoint)
	with ESMTP id ABN71776;
	Mon, 27 Jan 2003 14:19:42 -0500 (EST)
Message-Id: <4.3.2.7.2.20030127142021.03e5dc80@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 27 Jan 2003 14:29:42 -0500
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
From: Michael Hammer <mhammer@cisco.com>
Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
Cc: "'Henning Schulzrinne'" <hgs@cs.columbia.edu>,
        "'sipping@ietf.org'" <sipping@ietf.org>
In-Reply-To: <313680C9A886D511A06000204840E1CF030B5D74@whq-msgusr-02.pit
 .comms.marconi.com>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

<html>
<font size=3>Brian,<br>
<br>
You use context in singular fashion as though the UAC only has one.&nbsp;
Could it not be operating within multiple contexts?&nbsp; I can imagine
that it may have to learn and store more than one, depending on who is
intended to consume the URI.&nbsp; (such as a home and visited
context)<br>
<br>
I would hope that &quot;A proxy server either routes a tel uri without a
context&quot; means that a proxy can accept such a tel uri as an incoming
value, but never as an outgoing value.<br>
<br>
Wouldn't the context need to be globally unique, so that a tel uri that
leaves the domain can be understood.&nbsp; Did you mean that the tel:
value must be only unique within the identified context?&nbsp; Or did you
mean to say that there are multiple contexts passed out by a proxy server
that will make all addresses unique before exiting the domain of that
proxy?&nbsp; Not sure I followed that last paragraph fully.<br>
<br>
Mike<br>
<br>
<br>
At 02:06 PM 1/27/2003 -0500, Rosen, Brian wrote:<br>
<blockquote type=cite cite>I can see including a context token as a
confirmation, or even selection<br>
of the dial plan domain to be interpreted by a proxy.&nbsp; I see the
value.&nbsp; <br>
The text in 2806bis can get considerably smaller and more focused,
right?<br>
It would seem that most of the confusion on context then goes away.<br>
<br>
So, summarizing:<br>
&nbsp;a) The preferred mechanism is UA has dialing plan.&nbsp; We will
standardize<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>a
notation, and a method to learn it<br>
&nbsp;b) We support a proxy translation of dial string to routable
numbers.&nbsp; <br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>We should
choose ONE way to send a dial string.&nbsp; <br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>I
personally like sip:dialsting@domain, with or without user=phone.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>It could
have the context parameter.<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>If we use
a tel uri, then text in 2806bis about dial strings must<br>
change<br>
&nbsp;c) The context is either learned from the environment (DHCP?),
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>or
provisioned.&nbsp; It is always included in the URI when the number<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>is not
known to be directly routable (not correct to say global)<br>
<br>
A UAC either expands dialstrings to routable numbers and emits a tel
uri,<br>
or it sends dialstrings with a context.&nbsp; A proxy server either
routes<br>
a tel uri without a context, or expands a dialstring to a routable
uri<br>
from the dialstring+context.<br>
<br>
Contexts need to be unique within the domain of a proxy server and
all<br>
the UAs that might get service from it.&nbsp; I think that if you
allow<br>
contexts to be provisioned in the phone, that we should have some
kind<br>
of naming convention or something.&nbsp; If they were always learned,
then<br>
they would just have to be unique within the domain they were
learned<br>
from.<br>
<br>
<br>
<br>
Brian<br>
<br>
&gt; -----Original Message-----<br>
&gt; From: Henning Schulzrinne
[<a href="mailto:hgs@cs.columbia.edu" eudora="autourl">mailto:hgs@cs.columbia.edu</a>]<br>
&gt; Sent: Friday, January 24, 2003 6:03 PM<br>
&gt; To: Rosen, Brian<br>
&gt; Cc: 'sipping@ietf.org'<br>
&gt; Subject: Re: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local
numbers<br>
&gt; <br>
&gt; <br>
&gt; &gt; As yet another example, what is my context?&nbsp; Is it
&quot;Marconi <br>
&gt; Pittsburgh&quot;.<br>
&gt; &gt; Is that globally unique?&nbsp; Or is it
&quot;+1724742&quot;?&nbsp; That's <br>
&gt; globally unique,<br>
&gt; &gt; but may or may not be useable by my first hop proxy.<br>
&gt; <br>
&gt; The point is that you and your first hop proxy better agree on 
<br>
&gt; something, choosing one of the mechanism in 2806bis, such as <br>
&gt; a prefix or <br>
&gt; a domain name. What you pick is immaterial - it is invisible <br>
&gt; to the user.<br>
&gt; <br>
&gt; If you can't agree on that, it is very unlikely that you can agree
on <br>
&gt; what actually happens in the translation. Once you have automated
<br>
&gt; configuration (at the device, AOR or outbound proxy level), <br>
&gt; it doesn't <br>
&gt; matter what it is called, as long as you pick something <br>
&gt; that's unique. <br>
&gt; 2806bis provides two reasonable mechanisms. I don't see this <br>
&gt; as an issue.<br>
&gt; <br>
&gt; &gt; <br>
&gt; &gt; I think we either get rid of it, making the dialing plan <br>
&gt; the last word,<br>
&gt; &gt; or make the dialing plan the job of the first hop proxy.&nbsp;
I <br>
&gt; fail to see<br>
&gt; &gt; the advantage of dialing plan in the UA and first hop proxy
<br>
&gt; interpreting<br>
&gt; &gt; context.<br>
&gt; <br>
&gt; You would never have both at the same time in the same <br>
&gt; installation, but <br>
&gt; I don't think we're in the business of picking architectures here.
My <br>
&gt; proposal allows choice. If you don't like to run context in your
<br>
&gt; products or installation, don't. I happen to think that <br>
&gt; UA-translation <br>
&gt; is best, as it is in the endsystem-is-smart spirit, but <br>
&gt; others seem to <br>
&gt; want proxy translation. Proxy translation without context is <br>
&gt; extremely <br>
&gt; brittle.<br>
&gt; <br>
&gt; <br>
&gt; &gt; To me, that makes context even less interesting.&nbsp; You
require the<br>
&gt; &gt; first hop proxy to understand all contexts that could be <br>
&gt; generated by<br>
&gt; &gt; any UA it serves.&nbsp; That would make it pretty hard for you
to bring<br>
&gt; &gt; your office phone home if your ISP provided your first hop
proxy. <br>
&gt; &gt; <br>
&gt; &gt; I think it's best to either have the dialing plan have to make
sense<br>
&gt; &gt; to the first hop proxy (by making the local domain the source
of<br>
&gt; &gt; the dialing plan, your #2 above), or make the proxy responsible
for<br>
&gt; &gt; turning digit strings into routable numbers.&nbsp; I don't see
enough<br>
&gt; &gt; utility in having the dialing plan associated with the phone
itself.<br>
&gt; <br>
&gt; The point is that I want to be warned if the translation is done by
<br>
&gt; somebody that shouldn't. This becomes even more important <br>
&gt; when you put <br>
&gt; tel URIs on web pages.<br>
&gt; <br>
&gt; Henning<br>
&gt; <br>
_______________________________________________<br>
Sipping mailing list&nbsp;
<a href="https://www1.ietf.org/mailman/listinfo/sipping" eudora="autourl">https://www1.ietf.org/mailman/listinfo/sipping</a><br>
This list is for NEW development of the application of SIP<br>
Use sip-implementors@cs.columbia.edu for questions on current sip<br>
Use sip@ietf.org for new developments of core SIP
</font></blockquote></html>

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan 27 14:47:53 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24236
	for <sipping-archive@odin.ietf.org>; Mon, 27 Jan 2003 14:47:53 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0RK8S713718
	for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 15:08:28 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RK8SJ13715
	for <sipping-web-archive@optimus.ietf.org>; Mon, 27 Jan 2003 15:08:28 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24220
	for <sipping-web-archive@ietf.org>; Mon, 27 Jan 2003 14:47:22 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RK7NJ13538;
	Mon, 27 Jan 2003 15:07:23 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RK6OJ12945
	for <sipping@optimus.ietf.org>; Mon, 27 Jan 2003 15:06:24 -0500
Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24111
	for <sipping@ietf.org>; Mon, 27 Jan 2003 14:45:18 -0500 (EST)
From: jh@lohi.eng.song.fi
Received: from harjus.eng.song.fi ([195.10.149.20])
	by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian))
	id 18dFFL-0000vv-00; Mon, 27 Jan 2003 21:48:43 +0200
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
Cc: "'Paul Kyzivat'" <pkyzivat@cisco.com>,
        Henning Schulzrinne
	 <hgs@cs.columbia.edu>,
        "'Christer Holmberg'" <christer.holmberg@lmf.ericsson.se>,
        "Conroy, Lawrence (SMTP)"
	 <lwc@roke.co.uk>,
        "'sipping@ietf.org'" <sipping@ietf.org>
Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
In-Reply-To: <313680C9A886D511A06000204840E1CF030B5D76@whq-msgusr-02.pit.comms.marconi.com>
References: <313680C9A886D511A06000204840E1CF030B5D76@whq-msgusr-02.pit.comms.marconi.com>
X-Mailer: VM 7.03 under Emacs 21.2.1
Message-Id: <E18dFFL-0000vv-00@lohi.eng.song.fi>
Date: Mon, 27 Jan 2003 21:48:43 +0200
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

Rosen, Brian writes:

 > In my environment, if I dial 304-3859, then I would
 > show my FROM as 300-7826, because if I'm calling within
 > my local network, then my network number is the best way
 > to call me back.  If I call the same fellow at
 > 703-455-7826, then I might show my +17247426826 as
 > my From:

no matter how you call, it makes sense to always have a globally unique
uri in the from field.

-- juha

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan 27 14:48:05 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24249
	for <sipping-archive@odin.ietf.org>; Mon, 27 Jan 2003 14:48:05 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0RK8eN13740
	for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 15:08:40 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RK8eJ13737
	for <sipping-web-archive@optimus.ietf.org>; Mon, 27 Jan 2003 15:08:40 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24233
	for <sipping-web-archive@ietf.org>; Mon, 27 Jan 2003 14:47:34 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RK84J13696;
	Mon, 27 Jan 2003 15:08:04 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RK7UJ13578
	for <sipping@optimus.ietf.org>; Mon, 27 Jan 2003 15:07:30 -0500
Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24181
	for <sipping@ietf.org>; Mon, 27 Jan 2003 14:46:24 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0RJoJOf019072;
	Mon, 27 Jan 2003 14:50:19 -0500 (EST)
Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAY61988;
	Mon, 27 Jan 2003 14:54:32 -0500 (EST)
Message-ID: <3E358D49.3010108@cisco.com>
Date: Mon, 27 Jan 2003 14:49:29 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
CC: Henning Schulzrinne <hgs@cs.columbia.edu>,
        "'Christer Holmberg'" <christer.holmberg@lmf.ericsson.se>,
        "'jh@lohi.eng.song.fi'" <jh@lohi.eng.song.fi>,
        "Conroy, Lawrence (SMTP)" <lwc@roke.co.uk>,
        "'sipping@ietf.org'" <sipping@ietf.org>
Subject: Re: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
References: <313680C9A886D511A06000204840E1CF030B5D76@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Brian,

I think it is a *bad* idea for the UAC to be trying to figure out the 
best representation of the From address based on the To address. There 
are all sorts of cases where this does the wrong thing.

It makes way more sense for the UAC to represent the From address with 
maximal information, in the most universally understood form possible, 
and for each UAS to then transform the From into the form that is "best" 
for its user. (With the possibility of configuring the definition of 
"best".)

So I might dial a coworker using "1234", my From address is populated 
with my global address tel:+197855554321. My coworker's phone then might 
"reverse engineer" the dial plan to realize that number could be dialed 
as "4321", and so displays the number that way.

If my number wasn't globally reachable, my From address could be 
tel:4321;phone-context=lowell.cisco.com. Once again, the recipients 
phone could reverse engineer the dial plan and still show the number as 
just 4321.

If somebody called in from outside (From:tel:+12125554321), then the 
reverse engineering of the dial plan might result in it being displayed 
as: 9-1-212-555-4321.

Reverse engineering the dial plan imposes some new requirements. For 
one, it can't easily be done in the proxy, because there is no good way 
to convey it.

	Paul

Rosen, Brian wrote:
> This is actually an interesting problem.
> In my environment, if I dial 304-3859, then I would
> show my FROM as 300-7826, because if I'm calling within
> my local network, then my network number is the best way
> to call me back.  If I call the same fellow at
> 703-455-7826, then I might show my +17247426826 as
> my From:
> 
> If I had the dialing plan in the UA, I could do this.
> If the expansion is in a proxy, it can't modify From:.
> 
> I don't think we do anything about it.  It's more argument
> why dial plan expansion in the UA is a better way to go.
> 
> Brian
> 
> 
>>-----Original Message-----
>>From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
[snip]
>>But this doesn't work for From. The calling phone had better know an 
>>expanded form of its own address.

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan 27 16:24:41 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27409
	for <sipping-archive@odin.ietf.org>; Mon, 27 Jan 2003 16:24:41 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0RLjIM19158
	for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 16:45:18 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RLjIJ19155
	for <sipping-web-archive@optimus.ietf.org>; Mon, 27 Jan 2003 16:45:18 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27361
	for <sipping-web-archive@ietf.org>; Mon, 27 Jan 2003 16:24:09 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RLh0J19043;
	Mon, 27 Jan 2003 16:43:00 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RLfZJ18987
	for <sipping@optimus.ietf.org>; Mon, 27 Jan 2003 16:41:35 -0500
Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27210
	for <sipping@ietf.org>; Mon, 27 Jan 2003 16:20:26 -0500 (EST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA00162;
	Mon, 27 Jan 2003 16:23:54 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA05201;
	Mon, 27 Jan 2003 16:23:56 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19)
	id <D3QL7QH9>; Mon, 27 Jan 2003 16:23:55 -0500
Message-ID: <313680C9A886D511A06000204840E1CF030B5D7C@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Michael Hammer'" <mhammer@cisco.com>
Cc: "'Henning Schulzrinne'" <hgs@cs.columbia.edu>,
        "'sipping@ietf.org'"
	 <sipping@ietf.org>
Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
Date: Mon, 27 Jan 2003 16:23:54 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

>You use context in singular fashion as though the UAC only has one.  
>Could it not be operating within multiple contexts?  I can imagine 
>that it may have to learn and store more than one, depending on who
>is intended to consume the URI.  (such as a home and visited context)
I don't know.  I guess I'm not opposed if it doesn't make things
a lot more complicated.  

I think as a practical matter, it's pretty hard to manage more than one.
You would need some kind of UI that let you choose, so that your
dial string could be interpreted differently.  That's an 
implementation issue.

From a standards perspective, you can only get one from something like
DHCP.  You could get one each for every AOR if you had more than one,
if instead of learning through DHCP it was, say, PUBLISHED as a 
consequence of registration.  I've thought of that.  You also get one 
per phone if it's provisioned in the phone.

On the other hand, there is no reason to restrict the UA from having
more than one.

>I would hope that "A proxy server either routes a tel uri without a 
>context" means that a proxy can accept such a tel uri as an incoming 
>value, but never as an outgoing value.
Confusion.  A tel uri without a context means it's either global or 
at least routable with no further expansion.  So, a proxy server would
definitely put such a uri as an outgoing value.


>Wouldn't the context need to be globally unique, so that a tel uri 
>that leaves the domain can be understood.  Did you mean that the 
>tel: value must be only unique within the identified context?  Or 
>did you mean to say that there are multiple contexts passed out by 
>a proxy server that will make all addresses unique before exiting 
>the domain of that proxy?  Not sure I followed that last paragraph fully.
I thought that contexts needed to be globally unique but Henning
asserted otherwise.   As long as the UA and the interpreting proxy
agree on a naming, it's okay.  How it figures that out is not
specified.  I think that's okay; if Marconi's domain has a convention
that, say, contexts are of the form "<location>-marconi", and
all contexts the UA learns/provisioned are in that form, all is well.

So, the requirement is that the proxy understand the context, or it
will return an error.  The proxy has to output a routable (which could
be global) tel uri for the combination of dial string and context,
for all contexts it implements.

Actually, it's not clear to me that we have to be quite so 
restrictive. It is possible that the rule is actually that the proxy 
has to be able to either translate to a fully routable tel uri OR that 
it has to forward it to a proxy that can do that.  If, for example, 
I send 8977@pitt.marconi.com; context="coventry-marconi", the local 
(roaming) proxy at pit could forward the call to coventry.marconi.com 
for processing using the coventry-marconi context.  The pitt proxy
would need routing rules to be able to do that.

Having said that, if my home is pitt, I roam to coventry and invite
someone in coventry, I don't want pitt's routing to send the call to
a gateway in Pittsburgh!  If pitt expands the number to a globally
routable number and redirects the call, coventry can "least cost
route" it.

Brian

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan 27 16:43:06 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28029
	for <sipping-archive@odin.ietf.org>; Mon, 27 Jan 2003 16:43:06 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0RM3iA20436
	for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 17:03:44 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RM3iJ20432
	for <sipping-web-archive@optimus.ietf.org>; Mon, 27 Jan 2003 17:03:44 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28011
	for <sipping-web-archive@ietf.org>; Mon, 27 Jan 2003 16:42:34 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RM28J20357;
	Mon, 27 Jan 2003 17:02:08 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RM13J20194
	for <sipping@optimus.ietf.org>; Mon, 27 Jan 2003 17:01:03 -0500
Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27935
	for <sipping@ietf.org>; Mon, 27 Jan 2003 16:39:54 -0500 (EST)
Received: from cia.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0RLi6or006030;
	Mon, 27 Jan 2003 16:44:07 -0500 (EST)
Received: from mhammer-w2k02.cisco.com (hrn2-dhcp-161-44-87-77.cisco.com [161.44.87.77])
	by cia.cisco.com (Mirapoint)
	with ESMTP id ABN73603;
	Mon, 27 Jan 2003 16:33:16 -0500 (EST)
Message-Id: <4.3.2.7.2.20030127163253.00b45788@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 27 Jan 2003 16:43:15 -0500
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
From: Michael Hammer <mhammer@cisco.com>
Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
Cc: "'Henning Schulzrinne'" <hgs@cs.columbia.edu>,
        "'sipping@ietf.org'" <sipping@ietf.org>
In-Reply-To: <313680C9A886D511A06000204840E1CF030B5D7C@whq-msgusr-02.pit
 .comms.marconi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

Brian,

I'm following you now.  Part of my problem was reading the statements 
within the context of "how to handle non-global tel: URI."  I was reading 
it as forwarding on to an arbitrary server with a non-global URI without 
context.  The onward routing with global URI or full context is now 
clear.  Your example option of configuration to route by exception handling 
to another proxy that is expected to figure it out shows that this will be 
implementation dependent.

Mike


At 04:23 PM 1/27/2003 -0500, Rosen, Brian wrote:
> >You use context in singular fashion as though the UAC only has one.
> >Could it not be operating within multiple contexts?  I can imagine
> >that it may have to learn and store more than one, depending on who
> >is intended to consume the URI.  (such as a home and visited context)
>I don't know.  I guess I'm not opposed if it doesn't make things
>a lot more complicated.
>
>I think as a practical matter, it's pretty hard to manage more than one.
>You would need some kind of UI that let you choose, so that your
>dial string could be interpreted differently.  That's an
>implementation issue.
>
> From a standards perspective, you can only get one from something like
>DHCP.  You could get one each for every AOR if you had more than one,
>if instead of learning through DHCP it was, say, PUBLISHED as a
>consequence of registration.  I've thought of that.  You also get one
>per phone if it's provisioned in the phone.
>
>On the other hand, there is no reason to restrict the UA from having
>more than one.
>
> >I would hope that "A proxy server either routes a tel uri without a
> >context" means that a proxy can accept such a tel uri as an incoming
> >value, but never as an outgoing value.
>Confusion.  A tel uri without a context means it's either global or
>at least routable with no further expansion.  So, a proxy server would
>definitely put such a uri as an outgoing value.
>
>
> >Wouldn't the context need to be globally unique, so that a tel uri
> >that leaves the domain can be understood.  Did you mean that the
> >tel: value must be only unique within the identified context?  Or
> >did you mean to say that there are multiple contexts passed out by
> >a proxy server that will make all addresses unique before exiting
> >the domain of that proxy?  Not sure I followed that last paragraph fully.
>I thought that contexts needed to be globally unique but Henning
>asserted otherwise.   As long as the UA and the interpreting proxy
>agree on a naming, it's okay.  How it figures that out is not
>specified.  I think that's okay; if Marconi's domain has a convention
>that, say, contexts are of the form "<location>-marconi", and
>all contexts the UA learns/provisioned are in that form, all is well.
>
>So, the requirement is that the proxy understand the context, or it
>will return an error.  The proxy has to output a routable (which could
>be global) tel uri for the combination of dial string and context,
>for all contexts it implements.
>
>Actually, it's not clear to me that we have to be quite so
>restrictive. It is possible that the rule is actually that the proxy
>has to be able to either translate to a fully routable tel uri OR that
>it has to forward it to a proxy that can do that.  If, for example,
>I send 8977@pitt.marconi.com; context="coventry-marconi", the local
>(roaming) proxy at pit could forward the call to coventry.marconi.com
>for processing using the coventry-marconi context.  The pitt proxy
>would need routing rules to be able to do that.
>
>Having said that, if my home is pitt, I roam to coventry and invite
>someone in coventry, I don't want pitt's routing to send the call to
>a gateway in Pittsburgh!  If pitt expands the number to a globally
>routable number and redirects the call, coventry can "least cost
>route" it.
>
>Brian

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan 27 16:47:40 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28135
	for <sipping-archive@odin.ietf.org>; Mon, 27 Jan 2003 16:47:39 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0RM8Hb21333
	for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 17:08:17 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RM8HJ21330
	for <sipping-web-archive@optimus.ietf.org>; Mon, 27 Jan 2003 17:08:17 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28124
	for <sipping-web-archive@ietf.org>; Mon, 27 Jan 2003 16:47:08 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RM2BJ20377;
	Mon, 27 Jan 2003 17:02:11 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RM1LJ20319
	for <sipping@optimus.ietf.org>; Mon, 27 Jan 2003 17:01:21 -0500
Received: from dewberry.cc.columbia.edu (dewberry.cc.columbia.edu [128.59.59.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27754
	for <sipping@ietf.org>; Mon, 27 Jan 2003 16:38:01 -0500 (EST)
Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66])
	(user=hgs10 mech=PLAIN bits=0)
	by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0RLd5Sr014937
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Mon, 27 Jan 2003 16:39:07 -0500 (EST)
Message-ID: <3E35A713.2060900@cs.columbia.edu>
Date: Mon, 27 Jan 2003 16:39:31 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
CC: "'Michael Hammer'" <mhammer@cisco.com>,
        "'sipping@ietf.org'" <sipping@ietf.org>
Subject: Re: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
References: <313680C9A886D511A06000204840E1CF030B5D7C@whq-msgusr-02.pit.comms.marconi.com>
In-Reply-To: <313680C9A886D511A06000204840E1CF030B5D7C@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

> I thought that contexts needed to be globally unique but Henning
> asserted otherwise.   As long as the UA and the interpreting proxy

Wait - where did I say that the context identifier is not globally 
unique? That's the whole point of the identifier... It may not be 
uniquely determined in the sense that a single context could have 
several different possible names (all unique), so there is way of just 
guessing the right name. For example, you can name your context 
marconi.com, your global phone prefix or some other DNS-based identifier 
that's yours.

> agree on a naming, it's okay.  How it figures that out is not
> specified.  I think that's okay; if Marconi's domain has a convention
> that, say, contexts are of the form "<location>-marconi", and
> all contexts the UA learns/provisioned are in that form, all is well.
> 

> Actually, it's not clear to me that we have to be quite so 
> restrictive. It is possible that the rule is actually that the proxy 
> has to be able to either translate to a fully routable tel uri OR that 
> it has to forward it to a proxy that can do that.  If, for example, 
> I send 8977@pitt.marconi.com; context="coventry-marconi", the local 
> (roaming) proxy at pit could forward the call to coventry.marconi.com 
> for processing using the coventry-marconi context.  The pitt proxy
> would need routing rules to be able to do that.

I agree it shouldn't be outlawed, but it will always be manual 
configuration, with the attendant problems.

> 
> Having said that, if my home is pitt, I roam to coventry and invite
> someone in coventry, I don't want pitt's routing to send the call to
> a gateway in Pittsburgh!  If pitt expands the number to a globally
> routable number and redirects the call, coventry can "least cost
> route" it.

Once you get through all the complexity, I suspect that it's easier to 
just use SIP URIs with phone user parts. However, since the point is to 
document all the variations and this is certainly one of them.

> 
> Brian

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Mon Jan 27 18:06:50 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00270
	for <sipping-archive@odin.ietf.org>; Mon, 27 Jan 2003 18:06:50 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0RNRUr25426
	for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 18:27:30 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RNRUJ25423
	for <sipping-web-archive@optimus.ietf.org>; Mon, 27 Jan 2003 18:27:30 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00259
	for <sipping-web-archive@ietf.org>; Mon, 27 Jan 2003 18:06:19 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RNOoJ25330;
	Mon, 27 Jan 2003 18:24:50 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RNNxJ25271
	for <sipping@optimus.ietf.org>; Mon, 27 Jan 2003 18:23:59 -0500
Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00166
	for <sipping@ietf.org>; Mon, 27 Jan 2003 18:02:48 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0RN6vJ0016913;
	Mon, 27 Jan 2003 18:06:58 -0500 (EST)
Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAY63723;
	Mon, 27 Jan 2003 18:11:10 -0500 (EST)
Message-ID: <3E35BB5F.4040903@cisco.com>
Date: Mon, 27 Jan 2003 18:06:07 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
CC: "'Michael Hammer'" <mhammer@cisco.com>,
        "'Henning Schulzrinne'" <hgs@cs.columbia.edu>,
        "'sipping@ietf.org'" <sipping@ietf.org>
Subject: Re: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
References: <313680C9A886D511A06000204840E1CF030B5D7C@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit



Rosen, Brian wrote:
> 
> Actually, it's not clear to me that we have to be quite so 
> restrictive. It is possible that the rule is actually that the proxy 
> has to be able to either translate to a fully routable tel uri OR that 
> it has to forward it to a proxy that can do that.  If, for example, 
> I send 8977@pitt.marconi.com; context="coventry-marconi", the local 
> (roaming) proxy at pit could forward the call to coventry.marconi.com 
> for processing using the coventry-marconi context.  The pitt proxy
> would need routing rules to be able to do that.

Detail: I can't quite figure out what you intend. I think you are 
proposing sending to

sip:8977;phone-context=coventry-marconi@pitt.marconi.com;user=phone

but that isn't quite legal. Things that would be are:

tel:8977;phone-context=coventry.marconi.com
sip:8977;phone-context=coventry.marconi.com@pitt.marconi.com;user=phone

There there isn't necessarily any relationship between the proxy names 
and the context names, but I have made them the same to suggest there 
might be a meaningful relationship in this case.

> Having said that, if my home is pitt, I roam to coventry and invite
> someone in coventry, I don't want pitt's routing to send the call to
> a gateway in Pittsburgh!  If pitt expands the number to a globally
> routable number and redirects the call, coventry can "least cost
> route" it.

There are several possibilities here. (I assume when you roam to 
coventry your outbound calls transit the coventry.marconi.com proxy first.)

1) if you use the tel: form above, the proxy naturally understands the 
context and routes the call directly. Your home proxy isn't involved at all.

2) if you use the sip form above, the coventry proxy is supposed to 
honor the domain, and forward the call to the pitt.marconi.com proxy.

2a) the pitt proxy might use a pitt gateway - your worst fear confirmed

2b) the pitt proxy might redirect to some global number (e.g. 
tel:+445558977) and then the local proxy would use a local gateway to 
get there.

Now instead, assume that you had roamed to coventry and are trying to 
dial a number 1234 in pitt:

3) you might use tel:1234;phone-context=pitt.marconi.com and send it to 
the coventry proxy.

3a) the coventry proxy might know the context and know that the best way 
to get the call there. For instance it might by default forward the call 
to the pitt.marconi.com proxy, but if that fails it could also know to 
translate the address and use a local GW.

3b) the coventry proxy might not know the context, but might have a 
convention to automatically route calls to unknown FQDN style contexts 
to a sip proxy with that name.

4) you might use 
sip:1234;phone-context=pitt.marconi.com@pitt.marconi.com and send it to 
the coventry proxy. In this case the coventry proxy must forward to the 
pitt proxy which will then probably use a local gw.  This is almost as 
good as (3a) except with the sip path is down between convenry and pitt.


My conclusion is that using a tel: gives the most options to do things well.

	Paul

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Tue Jan 28 08:30:29 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25519
	for <sipping-archive@odin.ietf.org>; Tue, 28 Jan 2003 08:30:29 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0SDpRH20254
	for sipping-archive@odin.ietf.org; Tue, 28 Jan 2003 08:51:27 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SDpRJ20251
	for <sipping-web-archive@optimus.ietf.org>; Tue, 28 Jan 2003 08:51:27 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25516
	for <sipping-web-archive@ietf.org>; Tue, 28 Jan 2003 08:29:57 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SDoVJ20191;
	Tue, 28 Jan 2003 08:50:31 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SDnxJ20134
	for <sipping@optimus.ietf.org>; Tue, 28 Jan 2003 08:49:59 -0500
Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25509
	for <sipping@ietf.org>; Tue, 28 Jan 2003 08:28:30 -0500 (EST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA17030;
	Tue, 28 Jan 2003 08:32:00 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA18549;
	Tue, 28 Jan 2003 08:32:00 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19)
	id <D3QL797M>; Tue, 28 Jan 2003 08:32:00 -0500
Message-ID: <313680C9A886D511A06000204840E1CF030B5D82@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Paul Kyzivat'" <pkyzivat@cisco.com>
Cc: "'Michael Hammer'" <mhammer@cisco.com>,
        "'Henning Schulzrinne'"
	 <hgs@cs.columbia.edu>,
        "'sipping@ietf.org'" <sipping@ietf.org>
Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
Date: Tue, 28 Jan 2003 08:31:59 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

I observe that if you know a context name you (can) know the domain that
the context is valid in.  That is true however the UA learns the
context.  

If we make a naming convention on contexts that includes the domain
(ie. contextname@domain), then a proxy can, if it does not understand
that context, forward to a proxy in the domain which would. 

I'll note that I really dislike putting parameters in the 'user' part
of a uri.  URI parameters are inexpensive, we should use them.
On the other hand, I'd prefer ONE way to do things.  So, a tel uri,
with a uri parameter of context, might be the best one way to go,
rather than putting more stuff into sip:... ;user=phone.
The contrary point of view is that the sip form has a domain,
which makes it more easily routable by intermediaries, most of whom
won't know how to route a generic tel uri.

It might be interesting to document somewhere that redirect should
be used when a proxy interprets a context where the call did not
originate in the domain of the proxy that does the interpretation.
Might be best if that was only if the translated number is globally
routable (otherwise you could have a translated number that
is a different destination in the originating domain than in the
translating domain).  If it's not globally routable, then the
translating domain is probably best to just route the call rather
than redirecting it.

Brian

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Monday, January 27, 2003 6:06 PM
> To: Rosen, Brian
> Cc: 'Michael Hammer'; 'Henning Schulzrinne'; 'sipping@ietf.org'
> Subject: Re: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
> 
> 
> 
> 
> Rosen, Brian wrote:
> > 
> > Actually, it's not clear to me that we have to be quite so 
> > restrictive. It is possible that the rule is actually that 
> the proxy 
> > has to be able to either translate to a fully routable tel 
> uri OR that 
> > it has to forward it to a proxy that can do that.  If, for example, 
> > I send 8977@pitt.marconi.com; context="coventry-marconi", the local 
> > (roaming) proxy at pit could forward the call to 
> coventry.marconi.com 
> > for processing using the coventry-marconi context.  The pitt proxy
> > would need routing rules to be able to do that.
> 
> Detail: I can't quite figure out what you intend. I think you are 
> proposing sending to
> 
> sip:8977;phone-context=coventry-marconi@pitt.marconi.com;user=phone
> 
> but that isn't quite legal. Things that would be are:
> 
> tel:8977;phone-context=coventry.marconi.com
> sip:8977;phone-context=coventry.marconi.com@pitt.marconi.com;u
> ser=phone
> 
> There there isn't necessarily any relationship between the 
> proxy names 
> and the context names, but I have made them the same to suggest there 
> might be a meaningful relationship in this case.
> 
> > Having said that, if my home is pitt, I roam to coventry and invite
> > someone in coventry, I don't want pitt's routing to send the call to
> > a gateway in Pittsburgh!  If pitt expands the number to a globally
> > routable number and redirects the call, coventry can "least cost
> > route" it.
> 
> There are several possibilities here. (I assume when you roam to 
> coventry your outbound calls transit the coventry.marconi.com 
> proxy first.)
> 
> 1) if you use the tel: form above, the proxy naturally 
> understands the 
> context and routes the call directly. Your home proxy isn't 
> involved at all.
> 
> 2) if you use the sip form above, the coventry proxy is supposed to 
> honor the domain, and forward the call to the pitt.marconi.com proxy.
> 
> 2a) the pitt proxy might use a pitt gateway - your worst fear 
> confirmed
> 
> 2b) the pitt proxy might redirect to some global number (e.g. 
> tel:+445558977) and then the local proxy would use a local gateway to 
> get there.
> 
> Now instead, assume that you had roamed to coventry and are trying to 
> dial a number 1234 in pitt:
> 
> 3) you might use tel:1234;phone-context=pitt.marconi.com and 
> send it to 
> the coventry proxy.
> 
> 3a) the coventry proxy might know the context and know that 
> the best way 
> to get the call there. For instance it might by default 
> forward the call 
> to the pitt.marconi.com proxy, but if that fails it could 
> also know to 
> translate the address and use a local GW.
> 
> 3b) the coventry proxy might not know the context, but might have a 
> convention to automatically route calls to unknown FQDN style 
> contexts 
> to a sip proxy with that name.
> 
> 4) you might use 
> sip:1234;phone-context=pitt.marconi.com@pitt.marconi.com and 
> send it to 
> the coventry proxy. In this case the coventry proxy must 
> forward to the 
> pitt proxy which will then probably use a local gw.  This is 
> almost as 
> good as (3a) except with the sip path is down between 
> convenry and pitt.
> 
> 
> My conclusion is that using a tel: gives the most options to 
> do things well.
> 
> 	Paul
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Tue Jan 28 10:21:26 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27688
	for <sipping-archive@odin.ietf.org>; Tue, 28 Jan 2003 10:21:25 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0SFgPa27554
	for sipping-archive@odin.ietf.org; Tue, 28 Jan 2003 10:42:25 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SFgOJ27551
	for <sipping-web-archive@optimus.ietf.org>; Tue, 28 Jan 2003 10:42:24 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27677
	for <sipping-web-archive@ietf.org>; Tue, 28 Jan 2003 10:20:54 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SFfXJ27508;
	Tue, 28 Jan 2003 10:41:33 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SFetJ27456
	for <sipping@optimus.ietf.org>; Tue, 28 Jan 2003 10:40:55 -0500
Received: from elmer.LEAPSTONE.COM (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27638
	for <sipping@ietf.org>; Tue, 28 Jan 2003 10:19:24 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
Date: Tue, 28 Jan 2003 10:23:46 -0500
Message-ID: <59A835EDCDDBEB46BC75402F4604D5520107A920@elmer>
Thread-Topic: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
Thread-Index: AcLG0jrBwsycvyEIQ32Tqb/eBS6cdQADK9fg
From: "Dusan Mudric" <dmudric@LEAPSTONE.com>
To: "Rosen, Brian" <Brian.Rosen@marconi.com>,
        "Paul Kyzivat" <pkyzivat@cisco.com>
Cc: "Michael Hammer" <mhammer@cisco.com>,
        "Henning Schulzrinne" <hgs@cs.columbia.edu>, <sipping@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0SFetJ27457
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

With introduction of a new technology, VoIP, legacy attributes should stay at the edge. By introducing Tel routing in IP, unnecessary dimension is used. IP already has a clean way to route. 

Why not just keep tel numbers in PSTN and names and IP's in IP? Every tel number has its owner with a name. It would be straightforward to route from IP to PSTN edge based on the name and at the edge translate that name into a tel number. From PSTN to IP, translate a virtual tel number into a name and get to the IP UA. In the near future, when everybody switches to IP (I wish :-) ), we will call friends by names only.

Dusan Mudric

-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Tuesday, January 28, 2003 8:32 AM
To: 'Paul Kyzivat'
Cc: 'Michael Hammer'; 'Henning Schulzrinne'; 'sipping@ietf.org'
Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers


I observe that if you know a context name you (can) know the domain that
the context is valid in.  That is true however the UA learns the
context.  

If we make a naming convention on contexts that includes the domain
(ie. contextname@domain), then a proxy can, if it does not understand
that context, forward to a proxy in the domain which would. 

I'll note that I really dislike putting parameters in the 'user' part
of a uri.  URI parameters are inexpensive, we should use them.
On the other hand, I'd prefer ONE way to do things.  So, a tel uri,
with a uri parameter of context, might be the best one way to go,
rather than putting more stuff into sip:... ;user=phone.
The contrary point of view is that the sip form has a domain,
which makes it more easily routable by intermediaries, most of whom
won't know how to route a generic tel uri.

It might be interesting to document somewhere that redirect should
be used when a proxy interprets a context where the call did not
originate in the domain of the proxy that does the interpretation.
Might be best if that was only if the translated number is globally
routable (otherwise you could have a translated number that
is a different destination in the originating domain than in the
translating domain).  If it's not globally routable, then the
translating domain is probably best to just route the call rather
than redirecting it.

Brian

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Monday, January 27, 2003 6:06 PM
> To: Rosen, Brian
> Cc: 'Michael Hammer'; 'Henning Schulzrinne'; 'sipping@ietf.org'
> Subject: Re: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
> 
> 
> 
> 
> Rosen, Brian wrote:
> > 
> > Actually, it's not clear to me that we have to be quite so 
> > restrictive. It is possible that the rule is actually that 
> the proxy 
> > has to be able to either translate to a fully routable tel 
> uri OR that 
> > it has to forward it to a proxy that can do that.  If, for example, 
> > I send 8977@pitt.marconi.com; context="coventry-marconi", the local 
> > (roaming) proxy at pit could forward the call to 
> coventry.marconi.com 
> > for processing using the coventry-marconi context.  The pitt proxy
> > would need routing rules to be able to do that.
> 
> Detail: I can't quite figure out what you intend. I think you are 
> proposing sending to
> 
> sip:8977;phone-context=coventry-marconi@pitt.marconi.com;user=phone
> 
> but that isn't quite legal. Things that would be are:
> 
> tel:8977;phone-context=coventry.marconi.com
> sip:8977;phone-context=coventry.marconi.com@pitt.marconi.com;u
> ser=phone
> 
> There there isn't necessarily any relationship between the 
> proxy names 
> and the context names, but I have made them the same to suggest there 
> might be a meaningful relationship in this case.
> 
> > Having said that, if my home is pitt, I roam to coventry and invite
> > someone in coventry, I don't want pitt's routing to send the call to
> > a gateway in Pittsburgh!  If pitt expands the number to a globally
> > routable number and redirects the call, coventry can "least cost
> > route" it.
> 
> There are several possibilities here. (I assume when you roam to 
> coventry your outbound calls transit the coventry.marconi.com 
> proxy first.)
> 
> 1) if you use the tel: form above, the proxy naturally 
> understands the 
> context and routes the call directly. Your home proxy isn't 
> involved at all.
> 
> 2) if you use the sip form above, the coventry proxy is supposed to 
> honor the domain, and forward the call to the pitt.marconi.com proxy.
> 
> 2a) the pitt proxy might use a pitt gateway - your worst fear 
> confirmed
> 
> 2b) the pitt proxy might redirect to some global number (e.g. 
> tel:+445558977) and then the local proxy would use a local gateway to 
> get there.
> 
> Now instead, assume that you had roamed to coventry and are trying to 
> dial a number 1234 in pitt:
> 
> 3) you might use tel:1234;phone-context=pitt.marconi.com and 
> send it to 
> the coventry proxy.
> 
> 3a) the coventry proxy might know the context and know that 
> the best way 
> to get the call there. For instance it might by default 
> forward the call 
> to the pitt.marconi.com proxy, but if that fails it could 
> also know to 
> translate the address and use a local GW.
> 
> 3b) the coventry proxy might not know the context, but might have a 
> convention to automatically route calls to unknown FQDN style 
> contexts 
> to a sip proxy with that name.
> 
> 4) you might use 
> sip:1234;phone-context=pitt.marconi.com@pitt.marconi.com and 
> send it to 
> the coventry proxy. In this case the coventry proxy must 
> forward to the 
> pitt proxy which will then probably use a local gw.  This is 
> almost as 
> good as (3a) except with the sip path is down between 
> convenry and pitt.
> 
> 
> My conclusion is that using a tel: gives the most options to 
> do things well.
> 
> 	Paul
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Tue Jan 28 11:38:55 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00297
	for <sipping-archive@odin.ietf.org>; Tue, 28 Jan 2003 11:38:55 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0SGxuL01596
	for sipping-archive@odin.ietf.org; Tue, 28 Jan 2003 11:59:56 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SGxuJ01593
	for <sipping-web-archive@optimus.ietf.org>; Tue, 28 Jan 2003 11:59:56 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00282
	for <sipping-web-archive@ietf.org>; Tue, 28 Jan 2003 11:38:23 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SGw6J01420;
	Tue, 28 Jan 2003 11:58:07 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SGuYJ01337
	for <sipping@optimus.ietf.org>; Tue, 28 Jan 2003 11:56:34 -0500
Received: from elmer.LEAPSTONE.COM (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00165
	for <sipping@ietf.org>; Tue, 28 Jan 2003 11:35:01 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
Date: Tue, 28 Jan 2003 11:39:27 -0500
Message-ID: <59A835EDCDDBEB46BC75402F4604D5520B5ADB@elmer>
Thread-Topic: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
Thread-Index: AcLG4sltLIzEsdlFT/muKtTIZJfXfwACPTVg
From: "Dusan Mudric" <dmudric@LEAPSTONE.com>
To: "Michael Hammer" <mhammer@cisco.com>
Cc: <sipping@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0SGuYJ01338
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

There are translators at the IP-PSTN edges. Existing tel number subscribers get registered at the PSTN-IP edge device with {name, tel_number}, which we already have in telephone books. Their names are visible from the edge device to the rest of the IP world. When an IP UA-A calls a party B in a PSTN by name, the call gets routed to the edge device that registered a PSTN subscriber B. From there on, a PSTN routs the call to a party B based on its tel number.

Dusan

-----Original Message-----
From: Michael Hammer [mailto:mhammer@cisco.com]
Sent: Tuesday, January 28, 2003 10:34 AM
To: Dusan Mudric
Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers


How would you route to someone who has only a telephone number and no SIP 
address?

The SIP network is only useful if it can route to everyone on the PSTN.

Mike


At 10:23 AM 1/28/2003 -0500, you wrote:
>With introduction of a new technology, VoIP, legacy attributes should stay 
>at the edge. By introducing Tel routing in IP, unnecessary dimension is 
>used. IP already has a clean way to route.
>
>Why not just keep tel numbers in PSTN and names and IP's in IP? Every tel 
>number has its owner with a name. It would be straightforward to route 
>from IP to PSTN edge based on the name and at the edge translate that name 
>into a tel number. From PSTN to IP, translate a virtual tel number into a 
>name and get to the IP UA. In the near future, when everybody switches to 
>IP (I wish :-) ), we will call friends by names only.
>
>Dusan Mudric
>
>-----Original Message-----
>From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
>Sent: Tuesday, January 28, 2003 8:32 AM
>To: 'Paul Kyzivat'
>Cc: 'Michael Hammer'; 'Henning Schulzrinne'; 'sipping@ietf.org'
>Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
>
>
>I observe that if you know a context name you (can) know the domain that
>the context is valid in.  That is true however the UA learns the
>context.
>
>If we make a naming convention on contexts that includes the domain
>(ie. contextname@domain), then a proxy can, if it does not understand
>that context, forward to a proxy in the domain which would.
>
>I'll note that I really dislike putting parameters in the 'user' part
>of a uri.  URI parameters are inexpensive, we should use them.
>On the other hand, I'd prefer ONE way to do things.  So, a tel uri,
>with a uri parameter of context, might be the best one way to go,
>rather than putting more stuff into sip:... ;user=phone.
>The contrary point of view is that the sip form has a domain,
>which makes it more easily routable by intermediaries, most of whom
>won't know how to route a generic tel uri.
>
>It might be interesting to document somewhere that redirect should
>be used when a proxy interprets a context where the call did not
>originate in the domain of the proxy that does the interpretation.
>Might be best if that was only if the translated number is globally
>routable (otherwise you could have a translated number that
>is a different destination in the originating domain than in the
>translating domain).  If it's not globally routable, then the
>translating domain is probably best to just route the call rather
>than redirecting it.
>
>Brian
>
> > -----Original Message-----
> > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> > Sent: Monday, January 27, 2003 6:06 PM
> > To: Rosen, Brian
> > Cc: 'Michael Hammer'; 'Henning Schulzrinne'; 'sipping@ietf.org'
> > Subject: Re: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
> >
> >
> >
> >
> > Rosen, Brian wrote:
> > >
> > > Actually, it's not clear to me that we have to be quite so
> > > restrictive. It is possible that the rule is actually that
> > the proxy
> > > has to be able to either translate to a fully routable tel
> > uri OR that
> > > it has to forward it to a proxy that can do that.  If, for example,
> > > I send 8977@pitt.marconi.com; context="coventry-marconi", the local
> > > (roaming) proxy at pit could forward the call to
> > coventry.marconi.com
> > > for processing using the coventry-marconi context.  The pitt proxy
> > > would need routing rules to be able to do that.
> >
> > Detail: I can't quite figure out what you intend. I think you are
> > proposing sending to
> >
> > sip:8977;phone-context=coventry-marconi@pitt.marconi.com;user=phone
> >
> > but that isn't quite legal. Things that would be are:
> >
> > tel:8977;phone-context=coventry.marconi.com
> > sip:8977;phone-context=coventry.marconi.com@pitt.marconi.com;u
> > ser=phone
> >
> > There there isn't necessarily any relationship between the
> > proxy names
> > and the context names, but I have made them the same to suggest there
> > might be a meaningful relationship in this case.
> >
> > > Having said that, if my home is pitt, I roam to coventry and invite
> > > someone in coventry, I don't want pitt's routing to send the call to
> > > a gateway in Pittsburgh!  If pitt expands the number to a globally
> > > routable number and redirects the call, coventry can "least cost
> > > route" it.
> >
> > There are several possibilities here. (I assume when you roam to
> > coventry your outbound calls transit the coventry.marconi.com
> > proxy first.)
> >
> > 1) if you use the tel: form above, the proxy naturally
> > understands the
> > context and routes the call directly. Your home proxy isn't
> > involved at all.
> >
> > 2) if you use the sip form above, the coventry proxy is supposed to
> > honor the domain, and forward the call to the pitt.marconi.com proxy.
> >
> > 2a) the pitt proxy might use a pitt gateway - your worst fear
> > confirmed
> >
> > 2b) the pitt proxy might redirect to some global number (e.g.
> > tel:+445558977) and then the local proxy would use a local gateway to
> > get there.
> >
> > Now instead, assume that you had roamed to coventry and are trying to
> > dial a number 1234 in pitt:
> >
> > 3) you might use tel:1234;phone-context=pitt.marconi.com and
> > send it to
> > the coventry proxy.
> >
> > 3a) the coventry proxy might know the context and know that
> > the best way
> > to get the call there. For instance it might by default
> > forward the call
> > to the pitt.marconi.com proxy, but if that fails it could
> > also know to
> > translate the address and use a local GW.
> >
> > 3b) the coventry proxy might not know the context, but might have a
> > convention to automatically route calls to unknown FQDN style
> > contexts
> > to a sip proxy with that name.
> >
> > 4) you might use
> > sip:1234;phone-context=pitt.marconi.com@pitt.marconi.com and
> > send it to
> > the coventry proxy. In this case the coventry proxy must
> > forward to the
> > pitt proxy which will then probably use a local gw.  This is
> > almost as
> > good as (3a) except with the sip path is down between
> > convenry and pitt.
> >
> >
> > My conclusion is that using a tel: gives the most options to
> > do things well.
> >
> >       Paul
> >
>_______________________________________________
>Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>This list is for NEW development of the application of SIP
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sip@ietf.org for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Tue Jan 28 13:08:52 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02594
	for <sipping-archive@odin.ietf.org>; Tue, 28 Jan 2003 13:08:52 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0SITtP07883
	for sipping-archive@odin.ietf.org; Tue, 28 Jan 2003 13:29:55 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SITtJ07880
	for <sipping-web-archive@optimus.ietf.org>; Tue, 28 Jan 2003 13:29:55 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02588
	for <sipping-web-archive@ietf.org>; Tue, 28 Jan 2003 13:08:20 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SIQTJ07771;
	Tue, 28 Jan 2003 13:26:29 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SIOgJ07686
	for <sipping@optimus.ietf.org>; Tue, 28 Jan 2003 13:24:42 -0500
Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02511
	for <sipping@ietf.org>; Tue, 28 Jan 2003 13:03:06 -0500 (EST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA03129;
	Tue, 28 Jan 2003 13:06:35 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA08619;
	Tue, 28 Jan 2003 13:06:36 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19)
	id <D3QL8LPH>; Tue, 28 Jan 2003 13:06:36 -0500
Message-ID: <313680C9A886D511A06000204840E1CF030B5D8B@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Dusan Mudric'" <dmudric@leapstone.com>
Cc: sipping@ietf.org
Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
Date: Tue, 28 Jan 2003 13:06:34 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

The assumption you are making is that every person who does not
have a sipphone is in a database that the gateway can access.

I think that's pretty tough to arrange.

Also has the small problem of multiple people with the same name.

Brian

> -----Original Message-----
> From: Dusan Mudric [mailto:dmudric@leapstone.com]
> Sent: Tuesday, January 28, 2003 11:39 AM
> To: Michael Hammer
> Cc: sipping@ietf.org
> Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
> 
> 
> There are translators at the IP-PSTN edges. Existing tel 
> number subscribers get registered at the PSTN-IP edge device 
> with {name, tel_number}, which we already have in telephone 
> books. Their names are visible from the edge device to the 
> rest of the IP world. When an IP UA-A calls a party B in a 
> PSTN by name, the call gets routed to the edge device that 
> registered a PSTN subscriber B. From there on, a PSTN routs 
> the call to a party B based on its tel number.
> 
> Dusan
> 
> -----Original Message-----
> From: Michael Hammer [mailto:mhammer@cisco.com]
> Sent: Tuesday, January 28, 2003 10:34 AM
> To: Dusan Mudric
> Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
> 
> 
> How would you route to someone who has only a telephone 
> number and no SIP 
> address?
> 
> The SIP network is only useful if it can route to everyone on 
> the PSTN.
> 
> Mike
> 
> 
> At 10:23 AM 1/28/2003 -0500, you wrote:
> >With introduction of a new technology, VoIP, legacy 
> attributes should stay 
> >at the edge. By introducing Tel routing in IP, unnecessary 
> dimension is 
> >used. IP already has a clean way to route.
> >
> >Why not just keep tel numbers in PSTN and names and IP's in 
> IP? Every tel 
> >number has its owner with a name. It would be 
> straightforward to route 
> >from IP to PSTN edge based on the name and at the edge 
> translate that name 
> >into a tel number. From PSTN to IP, translate a virtual tel 
> number into a 
> >name and get to the IP UA. In the near future, when 
> everybody switches to 
> >IP (I wish :-) ), we will call friends by names only.
> >
> >Dusan Mudric
> >
> >-----Original Message-----
> >From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> >Sent: Tuesday, January 28, 2003 8:32 AM
> >To: 'Paul Kyzivat'
> >Cc: 'Michael Hammer'; 'Henning Schulzrinne'; 'sipping@ietf.org'
> >Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
> >
> >
> >I observe that if you know a context name you (can) know the 
> domain that
> >the context is valid in.  That is true however the UA learns the
> >context.
> >
> >If we make a naming convention on contexts that includes the domain
> >(ie. contextname@domain), then a proxy can, if it does not understand
> >that context, forward to a proxy in the domain which would.
> >
> >I'll note that I really dislike putting parameters in the 'user' part
> >of a uri.  URI parameters are inexpensive, we should use them.
> >On the other hand, I'd prefer ONE way to do things.  So, a tel uri,
> >with a uri parameter of context, might be the best one way to go,
> >rather than putting more stuff into sip:... ;user=phone.
> >The contrary point of view is that the sip form has a domain,
> >which makes it more easily routable by intermediaries, most of whom
> >won't know how to route a generic tel uri.
> >
> >It might be interesting to document somewhere that redirect should
> >be used when a proxy interprets a context where the call did not
> >originate in the domain of the proxy that does the interpretation.
> >Might be best if that was only if the translated number is globally
> >routable (otherwise you could have a translated number that
> >is a different destination in the originating domain than in the
> >translating domain).  If it's not globally routable, then the
> >translating domain is probably best to just route the call rather
> >than redirecting it.
> >
> >Brian
> >
> > > -----Original Message-----
> > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> > > Sent: Monday, January 27, 2003 6:06 PM
> > > To: Rosen, Brian
> > > Cc: 'Michael Hammer'; 'Henning Schulzrinne'; 'sipping@ietf.org'
> > > Subject: Re: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
> > >
> > >
> > >
> > >
> > > Rosen, Brian wrote:
> > > >
> > > > Actually, it's not clear to me that we have to be quite so
> > > > restrictive. It is possible that the rule is actually that
> > > the proxy
> > > > has to be able to either translate to a fully routable tel
> > > uri OR that
> > > > it has to forward it to a proxy that can do that.  If, 
> for example,
> > > > I send 8977@pitt.marconi.com; 
> context="coventry-marconi", the local
> > > > (roaming) proxy at pit could forward the call to
> > > coventry.marconi.com
> > > > for processing using the coventry-marconi context.  The 
> pitt proxy
> > > > would need routing rules to be able to do that.
> > >
> > > Detail: I can't quite figure out what you intend. I think you are
> > > proposing sending to
> > >
> > > 
> sip:8977;phone-context=coventry-marconi@pitt.marconi.com;user=phone
> > >
> > > but that isn't quite legal. Things that would be are:
> > >
> > > tel:8977;phone-context=coventry.marconi.com
> > > sip:8977;phone-context=coventry.marconi.com@pitt.marconi.com;u
> > > ser=phone
> > >
> > > There there isn't necessarily any relationship between the
> > > proxy names
> > > and the context names, but I have made them the same to 
> suggest there
> > > might be a meaningful relationship in this case.
> > >
> > > > Having said that, if my home is pitt, I roam to 
> coventry and invite
> > > > someone in coventry, I don't want pitt's routing to 
> send the call to
> > > > a gateway in Pittsburgh!  If pitt expands the number to 
> a globally
> > > > routable number and redirects the call, coventry can "least cost
> > > > route" it.
> > >
> > > There are several possibilities here. (I assume when you roam to
> > > coventry your outbound calls transit the coventry.marconi.com
> > > proxy first.)
> > >
> > > 1) if you use the tel: form above, the proxy naturally
> > > understands the
> > > context and routes the call directly. Your home proxy isn't
> > > involved at all.
> > >
> > > 2) if you use the sip form above, the coventry proxy is 
> supposed to
> > > honor the domain, and forward the call to the 
> pitt.marconi.com proxy.
> > >
> > > 2a) the pitt proxy might use a pitt gateway - your worst fear
> > > confirmed
> > >
> > > 2b) the pitt proxy might redirect to some global number (e.g.
> > > tel:+445558977) and then the local proxy would use a 
> local gateway to
> > > get there.
> > >
> > > Now instead, assume that you had roamed to coventry and 
> are trying to
> > > dial a number 1234 in pitt:
> > >
> > > 3) you might use tel:1234;phone-context=pitt.marconi.com and
> > > send it to
> > > the coventry proxy.
> > >
> > > 3a) the coventry proxy might know the context and know that
> > > the best way
> > > to get the call there. For instance it might by default
> > > forward the call
> > > to the pitt.marconi.com proxy, but if that fails it could
> > > also know to
> > > translate the address and use a local GW.
> > >
> > > 3b) the coventry proxy might not know the context, but 
> might have a
> > > convention to automatically route calls to unknown FQDN style
> > > contexts
> > > to a sip proxy with that name.
> > >
> > > 4) you might use
> > > sip:1234;phone-context=pitt.marconi.com@pitt.marconi.com and
> > > send it to
> > > the coventry proxy. In this case the coventry proxy must
> > > forward to the
> > > pitt proxy which will then probably use a local gw.  This is
> > > almost as
> > > good as (3a) except with the sip path is down between
> > > convenry and pitt.
> > >
> > >
> > > My conclusion is that using a tel: gives the most options to
> > > do things well.
> > >
> > >       Paul
> > >
> >_______________________________________________
> >Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> >This list is for NEW development of the application of SIP
> >Use sip-implementors@cs.columbia.edu for questions on current sip
> >Use sip@ietf.org for new developments of core SIP
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Tue Jan 28 14:05:32 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03917
	for <sipping-archive@odin.ietf.org>; Tue, 28 Jan 2003 14:05:32 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0SJQaF11512
	for sipping-archive@odin.ietf.org; Tue, 28 Jan 2003 14:26:36 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SJQaJ11509
	for <sipping-web-archive@optimus.ietf.org>; Tue, 28 Jan 2003 14:26:36 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03901
	for <sipping-web-archive@ietf.org>; Tue, 28 Jan 2003 14:04:59 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SJNYJ11402;
	Tue, 28 Jan 2003 14:23:34 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SJM1J11329
	for <sipping@optimus.ietf.org>; Tue, 28 Jan 2003 14:22:01 -0500
Received: from elmer.LEAPSTONE.COM (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03731
	for <sipping@ietf.org>; Tue, 28 Jan 2003 14:00:24 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
Date: Tue, 28 Jan 2003 14:04:51 -0500
Message-ID: <59A835EDCDDBEB46BC75402F4604D5520107A923@elmer>
Thread-Topic: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
Thread-Index: AcLG+CPjcKvkLeriQEqDOm+zokAi6QABkoVw
From: "Dusan Mudric" <dmudric@LEAPSTONE.com>
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
Cc: <sipping@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0SJM1J11330
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit



>The assumption you are making is that every person who does not
>have a sipphone is in a database that the gateway can access.
>
>I think that's pretty tough to arrange.

It's feasible. It will be even tougher to introduce, maintain and phase out another (telephone number based) routing schema in IP.

>
>Also has the small problem of multiple people with the same name.

That was just an example. A globally unique or unique name within a domain is what everybody got accustomed to using emails.

>
>Brian

> -----Original Message-----
> From: Dusan Mudric [mailto:dmudric@leapstone.com]
> Sent: Tuesday, January 28, 2003 11:39 AM
> To: Michael Hammer
> Cc: sipping@ietf.org
> Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
> 
> 
> There are translators at the IP-PSTN edges. Existing tel 
> number subscribers get registered at the PSTN-IP edge device 
> with {name, tel_number}, which we already have in telephone 
> books. Their names are visible from the edge device to the 
> rest of the IP world. When an IP UA-A calls a party B in a 
> PSTN by name, the call gets routed to the edge device that 
> registered a PSTN subscriber B. From there on, a PSTN routs 
> the call to a party B based on its tel number.
> 
> Dusan
> 
> -----Original Message-----
> From: Michael Hammer [mailto:mhammer@cisco.com]
> Sent: Tuesday, January 28, 2003 10:34 AM
> To: Dusan Mudric
> Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
> 
> 
> How would you route to someone who has only a telephone 
> number and no SIP 
> address?
> 
> The SIP network is only useful if it can route to everyone on 
> the PSTN.
> 
> Mike
> 
> 
> At 10:23 AM 1/28/2003 -0500, you wrote:
> >With introduction of a new technology, VoIP, legacy 
> attributes should stay 
> >at the edge. By introducing Tel routing in IP, unnecessary 
> dimension is 
> >used. IP already has a clean way to route.
> >
> >Why not just keep tel numbers in PSTN and names and IP's in 
> IP? Every tel 
> >number has its owner with a name. It would be 
> straightforward to route 
> >from IP to PSTN edge based on the name and at the edge 
> translate that name 
> >into a tel number. From PSTN to IP, translate a virtual tel 
> number into a 
> >name and get to the IP UA. In the near future, when 
> everybody switches to 
> >IP (I wish :-) ), we will call friends by names only.
> >
> >Dusan Mudric
> >
> >-----Original Message-----
> >From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> >Sent: Tuesday, January 28, 2003 8:32 AM
> >To: 'Paul Kyzivat'
> >Cc: 'Michael Hammer'; 'Henning Schulzrinne'; 'sipping@ietf.org'
> >Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
> >
> >
> >I observe that if you know a context name you (can) know the 
> domain that
> >the context is valid in.  That is true however the UA learns the
> >context.
> >
> >If we make a naming convention on contexts that includes the domain
> >(ie. contextname@domain), then a proxy can, if it does not understand
> >that context, forward to a proxy in the domain which would.
> >
> >I'll note that I really dislike putting parameters in the 'user' part
> >of a uri.  URI parameters are inexpensive, we should use them.
> >On the other hand, I'd prefer ONE way to do things.  So, a tel uri,
> >with a uri parameter of context, might be the best one way to go,
> >rather than putting more stuff into sip:... ;user=phone.
> >The contrary point of view is that the sip form has a domain,
> >which makes it more easily routable by intermediaries, most of whom
> >won't know how to route a generic tel uri.
> >
> >It might be interesting to document somewhere that redirect should
> >be used when a proxy interprets a context where the call did not
> >originate in the domain of the proxy that does the interpretation.
> >Might be best if that was only if the translated number is globally
> >routable (otherwise you could have a translated number that
> >is a different destination in the originating domain than in the
> >translating domain).  If it's not globally routable, then the
> >translating domain is probably best to just route the call rather
> >than redirecting it.
> >
> >Brian
> >
> > > -----Original Message-----
> > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> > > Sent: Monday, January 27, 2003 6:06 PM
> > > To: Rosen, Brian
> > > Cc: 'Michael Hammer'; 'Henning Schulzrinne'; 'sipping@ietf.org'
> > > Subject: Re: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
> > >
> > >
> > >
> > >
> > > Rosen, Brian wrote:
> > > >
> > > > Actually, it's not clear to me that we have to be quite so
> > > > restrictive. It is possible that the rule is actually that
> > > the proxy
> > > > has to be able to either translate to a fully routable tel
> > > uri OR that
> > > > it has to forward it to a proxy that can do that.  If, 
> for example,
> > > > I send 8977@pitt.marconi.com; 
> context="coventry-marconi", the local
> > > > (roaming) proxy at pit could forward the call to
> > > coventry.marconi.com
> > > > for processing using the coventry-marconi context.  The 
> pitt proxy
> > > > would need routing rules to be able to do that.
> > >
> > > Detail: I can't quite figure out what you intend. I think you are
> > > proposing sending to
> > >
> > > 
> sip:8977;phone-context=coventry-marconi@pitt.marconi.com;user=phone
> > >
> > > but that isn't quite legal. Things that would be are:
> > >
> > > tel:8977;phone-context=coventry.marconi.com
> > > sip:8977;phone-context=coventry.marconi.com@pitt.marconi.com;u
> > > ser=phone
> > >
> > > There there isn't necessarily any relationship between the
> > > proxy names
> > > and the context names, but I have made them the same to 
> suggest there
> > > might be a meaningful relationship in this case.
> > >
> > > > Having said that, if my home is pitt, I roam to 
> coventry and invite
> > > > someone in coventry, I don't want pitt's routing to 
> send the call to
> > > > a gateway in Pittsburgh!  If pitt expands the number to 
> a globally
> > > > routable number and redirects the call, coventry can "least cost
> > > > route" it.
> > >
> > > There are several possibilities here. (I assume when you roam to
> > > coventry your outbound calls transit the coventry.marconi.com
> > > proxy first.)
> > >
> > > 1) if you use the tel: form above, the proxy naturally
> > > understands the
> > > context and routes the call directly. Your home proxy isn't
> > > involved at all.
> > >
> > > 2) if you use the sip form above, the coventry proxy is 
> supposed to
> > > honor the domain, and forward the call to the 
> pitt.marconi.com proxy.
> > >
> > > 2a) the pitt proxy might use a pitt gateway - your worst fear
> > > confirmed
> > >
> > > 2b) the pitt proxy might redirect to some global number (e.g.
> > > tel:+445558977) and then the local proxy would use a 
> local gateway to
> > > get there.
> > >
> > > Now instead, assume that you had roamed to coventry and 
> are trying to
> > > dial a number 1234 in pitt:
> > >
> > > 3) you might use tel:1234;phone-context=pitt.marconi.com and
> > > send it to
> > > the coventry proxy.
> > >
> > > 3a) the coventry proxy might know the context and know that
> > > the best way
> > > to get the call there. For instance it might by default
> > > forward the call
> > > to the pitt.marconi.com proxy, but if that fails it could
> > > also know to
> > > translate the address and use a local GW.
> > >
> > > 3b) the coventry proxy might not know the context, but 
> might have a
> > > convention to automatically route calls to unknown FQDN style
> > > contexts
> > > to a sip proxy with that name.
> > >
> > > 4) you might use
> > > sip:1234;phone-context=pitt.marconi.com@pitt.marconi.com and
> > > send it to
> > > the coventry proxy. In this case the coventry proxy must
> > > forward to the
> > > pitt proxy which will then probably use a local gw.  This is
> > > almost as
> > > good as (3a) except with the sip path is down between
> > > convenry and pitt.
> > >
> > >
> > > My conclusion is that using a tel: gives the most options to
> > > do things well.
> > >
> > >       Paul
> > >
> >_______________________________________________
> >Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> >This list is for NEW development of the application of SIP
> >Use sip-implementors@cs.columbia.edu for questions on current sip
> >Use sip@ietf.org for new developments of core SIP
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Tue Jan 28 14:12:12 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04136
	for <sipping-archive@odin.ietf.org>; Tue, 28 Jan 2003 14:12:12 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0SJXHg11833
	for sipping-archive@odin.ietf.org; Tue, 28 Jan 2003 14:33:17 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SJXHJ11830
	for <sipping-web-archive@optimus.ietf.org>; Tue, 28 Jan 2003 14:33:17 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04123
	for <sipping-web-archive@ietf.org>; Tue, 28 Jan 2003 14:11:40 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SJSGJ11597;
	Tue, 28 Jan 2003 14:28:16 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SJQwJ11532
	for <sipping@optimus.ietf.org>; Tue, 28 Jan 2003 14:26:58 -0500
Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03912
	for <sipping@ietf.org>; Tue, 28 Jan 2003 14:05:19 -0500 (EST)
Received: from cia.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0SJ9cnU006123;
	Tue, 28 Jan 2003 14:09:38 -0500 (EST)
Received: from mhammer-w2k02.cisco.com (hrn2-dhcp-161-44-87-85.cisco.com [161.44.87.85])
	by cia.cisco.com (Mirapoint)
	with ESMTP id ABN82179;
	Tue, 28 Jan 2003 13:58:47 -0500 (EST)
Message-Id: <4.3.2.7.2.20030128135439.00b38e08@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 28 Jan 2003 14:08:46 -0500
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
From: Michael Hammer <mhammer@cisco.com>
Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
Cc: "'Dusan Mudric'" <dmudric@leapstone.com>, sipping@ietf.org
In-Reply-To: <313680C9A886D511A06000204840E1CF030B5D8B@whq-msgusr-02.pit
 .comms.marconi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

Actually, every UAC would need to be able to access such a directory of 
every PSTN phone number in the world and a map to a SIP address to avoid 
sending a tel: URI into the SIP network.  And it would have to change every 
time a new person gets a new phone number or a phone number changes.  Why 
should the SIP community set up a directory to create and manage SIP 
addresses which map to PSTN phone numbers for non-SIP users?

Mike


At 01:06 PM 1/28/2003 -0500, Rosen, Brian wrote:
>The assumption you are making is that every person who does not
>have a sipphone is in a database that the gateway can access.
>
>I think that's pretty tough to arrange.
>
>Also has the small problem of multiple people with the same name.
>
>Brian
>
> > -----Original Message-----
> > From: Dusan Mudric [mailto:dmudric@leapstone.com]
> > Sent: Tuesday, January 28, 2003 11:39 AM
> > To: Michael Hammer
> > Cc: sipping@ietf.org
> > Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
> >
> >
> > There are translators at the IP-PSTN edges. Existing tel
> > number subscribers get registered at the PSTN-IP edge device
> > with {name, tel_number}, which we already have in telephone
> > books. Their names are visible from the edge device to the
> > rest of the IP world. When an IP UA-A calls a party B in a
> > PSTN by name, the call gets routed to the edge device that
> > registered a PSTN subscriber B. From there on, a PSTN routs
> > the call to a party B based on its tel number.
> >
> > Dusan
> >
> > -----Original Message-----
> > From: Michael Hammer [mailto:mhammer@cisco.com]
> > Sent: Tuesday, January 28, 2003 10:34 AM
> > To: Dusan Mudric
> > Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
> >
> >
> > How would you route to someone who has only a telephone
> > number and no SIP
> > address?
> >
> > The SIP network is only useful if it can route to everyone on
> > the PSTN.
> >
> > Mike
> >
> >
> > At 10:23 AM 1/28/2003 -0500, you wrote:
> > >With introduction of a new technology, VoIP, legacy
> > attributes should stay
> > >at the edge. By introducing Tel routing in IP, unnecessary
> > dimension is
> > >used. IP already has a clean way to route.
> > >
> > >Why not just keep tel numbers in PSTN and names and IP's in
> > IP? Every tel
> > >number has its owner with a name. It would be
> > straightforward to route
> > >from IP to PSTN edge based on the name and at the edge
> > translate that name
> > >into a tel number. From PSTN to IP, translate a virtual tel
> > number into a
> > >name and get to the IP UA. In the near future, when
> > everybody switches to
> > >IP (I wish :-) ), we will call friends by names only.
> > >
> > >Dusan Mudric
> > >
> > >-----Original Message-----
> > >From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > >Sent: Tuesday, January 28, 2003 8:32 AM
> > >To: 'Paul Kyzivat'
> > >Cc: 'Michael Hammer'; 'Henning Schulzrinne'; 'sipping@ietf.org'
> > >Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
> > >
> > >
> > >I observe that if you know a context name you (can) know the
> > domain that
> > >the context is valid in.  That is true however the UA learns the
> > >context.
> > >
> > >If we make a naming convention on contexts that includes the domain
> > >(ie. contextname@domain), then a proxy can, if it does not understand
> > >that context, forward to a proxy in the domain which would.
> > >
> > >I'll note that I really dislike putting parameters in the 'user' part
> > >of a uri.  URI parameters are inexpensive, we should use them.
> > >On the other hand, I'd prefer ONE way to do things.  So, a tel uri,
> > >with a uri parameter of context, might be the best one way to go,
> > >rather than putting more stuff into sip:... ;user=phone.
> > >The contrary point of view is that the sip form has a domain,
> > >which makes it more easily routable by intermediaries, most of whom
> > >won't know how to route a generic tel uri.
> > >
> > >It might be interesting to document somewhere that redirect should
> > >be used when a proxy interprets a context where the call did not
> > >originate in the domain of the proxy that does the interpretation.
> > >Might be best if that was only if the translated number is globally
> > >routable (otherwise you could have a translated number that
> > >is a different destination in the originating domain than in the
> > >translating domain).  If it's not globally routable, then the
> > >translating domain is probably best to just route the call rather
> > >than redirecting it.
> > >
> > >Brian
> > >
> > > > -----Original Message-----
> > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> > > > Sent: Monday, January 27, 2003 6:06 PM
> > > > To: Rosen, Brian
> > > > Cc: 'Michael Hammer'; 'Henning Schulzrinne'; 'sipping@ietf.org'
> > > > Subject: Re: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
> > > >
> > > >
> > > >
> > > >
> > > > Rosen, Brian wrote:
> > > > >
> > > > > Actually, it's not clear to me that we have to be quite so
> > > > > restrictive. It is possible that the rule is actually that
> > > > the proxy
> > > > > has to be able to either translate to a fully routable tel
> > > > uri OR that
> > > > > it has to forward it to a proxy that can do that.  If,
> > for example,
> > > > > I send 8977@pitt.marconi.com;
> > context="coventry-marconi", the local
> > > > > (roaming) proxy at pit could forward the call to
> > > > coventry.marconi.com
> > > > > for processing using the coventry-marconi context.  The
> > pitt proxy
> > > > > would need routing rules to be able to do that.
> > > >
> > > > Detail: I can't quite figure out what you intend. I think you are
> > > > proposing sending to
> > > >
> > > >
> > sip:8977;phone-context=coventry-marconi@pitt.marconi.com;user=phone
> > > >
> > > > but that isn't quite legal. Things that would be are:
> > > >
> > > > tel:8977;phone-context=coventry.marconi.com
> > > > sip:8977;phone-context=coventry.marconi.com@pitt.marconi.com;u
> > > > ser=phone
> > > >
> > > > There there isn't necessarily any relationship between the
> > > > proxy names
> > > > and the context names, but I have made them the same to
> > suggest there
> > > > might be a meaningful relationship in this case.
> > > >
> > > > > Having said that, if my home is pitt, I roam to
> > coventry and invite
> > > > > someone in coventry, I don't want pitt's routing to
> > send the call to
> > > > > a gateway in Pittsburgh!  If pitt expands the number to
> > a globally
> > > > > routable number and redirects the call, coventry can "least cost
> > > > > route" it.
> > > >
> > > > There are several possibilities here. (I assume when you roam to
> > > > coventry your outbound calls transit the coventry.marconi.com
> > > > proxy first.)
> > > >
> > > > 1) if you use the tel: form above, the proxy naturally
> > > > understands the
> > > > context and routes the call directly. Your home proxy isn't
> > > > involved at all.
> > > >
> > > > 2) if you use the sip form above, the coventry proxy is
> > supposed to
> > > > honor the domain, and forward the call to the
> > pitt.marconi.com proxy.
> > > >
> > > > 2a) the pitt proxy might use a pitt gateway - your worst fear
> > > > confirmed
> > > >
> > > > 2b) the pitt proxy might redirect to some global number (e.g.
> > > > tel:+445558977) and then the local proxy would use a
> > local gateway to
> > > > get there.
> > > >
> > > > Now instead, assume that you had roamed to coventry and
> > are trying to
> > > > dial a number 1234 in pitt:
> > > >
> > > > 3) you might use tel:1234;phone-context=pitt.marconi.com and
> > > > send it to
> > > > the coventry proxy.
> > > >
> > > > 3a) the coventry proxy might know the context and know that
> > > > the best way
> > > > to get the call there. For instance it might by default
> > > > forward the call
> > > > to the pitt.marconi.com proxy, but if that fails it could
> > > > also know to
> > > > translate the address and use a local GW.
> > > >
> > > > 3b) the coventry proxy might not know the context, but
> > might have a
> > > > convention to automatically route calls to unknown FQDN style
> > > > contexts
> > > > to a sip proxy with that name.
> > > >
> > > > 4) you might use
> > > > sip:1234;phone-context=pitt.marconi.com@pitt.marconi.com and
> > > > send it to
> > > > the coventry proxy. In this case the coventry proxy must
> > > > forward to the
> > > > pitt proxy which will then probably use a local gw.  This is
> > > > almost as
> > > > good as (3a) except with the sip path is down between
> > > > convenry and pitt.
> > > >
> > > >
> > > > My conclusion is that using a tel: gives the most options to
> > > > do things well.
> > > >
> > > >       Paul
> > > >
> > >_______________________________________________
> > >Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > >This list is for NEW development of the application of SIP
> > >Use sip-implementors@cs.columbia.edu for questions on current sip
> > >Use sip@ietf.org for new developments of core SIP
> >
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sip@ietf.org for new developments of core SIP
> >
>_______________________________________________
>Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>This list is for NEW development of the application of SIP
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sip@ietf.org for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Tue Jan 28 16:53:00 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09169
	for <sipping-archive@odin.ietf.org>; Tue, 28 Jan 2003 16:53:00 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0SME7f24176
	for sipping-archive@odin.ietf.org; Tue, 28 Jan 2003 17:14:07 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SME7J24173
	for <sipping-web-archive@optimus.ietf.org>; Tue, 28 Jan 2003 17:14:07 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09134
	for <sipping-web-archive@ietf.org>; Tue, 28 Jan 2003 16:52:28 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SM80J23799;
	Tue, 28 Jan 2003 17:08:02 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SM5AJ23056
	for <sipping@optimus.ietf.org>; Tue, 28 Jan 2003 17:05:10 -0500
Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08902
	for <sipping@ietf.org>; Tue, 28 Jan 2003 16:43:30 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0SLlfbV001638;
	Tue, 28 Jan 2003 16:47:42 -0500 (EST)
Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAY71000;
	Tue, 28 Jan 2003 16:51:53 -0500 (EST)
Message-ID: <3E36FA4B.3060902@cisco.com>
Date: Tue, 28 Jan 2003 16:46:51 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
CC: "'Michael Hammer'" <mhammer@cisco.com>,
        "'Henning Schulzrinne'" <hgs@cs.columbia.edu>,
        "'sipping@ietf.org'" <sipping@ietf.org>
Subject: Re: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
References: <313680C9A886D511A06000204840E1CF030B5D82@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit



Rosen, Brian wrote:
> I observe that if you know a context name you (can) know the domain that
> the context is valid in.  That is true however the UA learns the
> context.  

No. At least all I suggested is that if you know the context name you 
may be able to guess *a* (not *the*) domain the context is valid in. The 
context may be valid in many domains. (In fact, I gave an example where 
a context was valid in two domains.)

> If we make a naming convention on contexts that includes the domain
> (ie. contextname@domain), then a proxy can, if it does not understand
> that context, forward to a proxy in the domain which would.

Well, that particular convention won't work, but yes I was suggesting a 
convention with this property - if the context is in FQDN format, try 
using that as a next hop domain name.

> I'll note that I really dislike putting parameters in the 'user' part
> of a uri. 

Why? The sip representation of a tel: url uses them. Life is tough.

 > URI parameters are inexpensive, we should use them.

Parsing is parsing. What does it matter which part of the url you parse 
to get them?

If you use a tel: url directly, then they are url parameters. Does that 
make you happier?

> On the other hand, I'd prefer ONE way to do things.  So, a tel uri,
> with a uri parameter of context, might be the best one way to go,
> rather than putting more stuff into sip:... ;user=phone.
> The contrary point of view is that the sip form has a domain,
> which makes it more easily routable by intermediaries, most of whom
> won't know how to route a generic tel uri.

Its ok to switch to the sip: form once you are in a position to 
intelligently decide what domain to use. From then on intermediaries 
don't need to understand tel:

This decision can even be made in the UAC if its smart enough. But this 
still leaves the To in tel: form. It isn't used in routing so it can and 
should stay that way.

> It might be interesting to document somewhere that redirect should
> be used when a proxy interprets a context where the call did not
> originate in the domain of the proxy that does the interpretation.
> Might be best if that was only if the translated number is globally
> routable (otherwise you could have a translated number that
> is a different destination in the originating domain than in the
> translating domain).  If it's not globally routable, then the
> translating domain is probably best to just route the call rather
> than redirecting it.

It might take a lot of talking to come to agreement on the details. But 
perhaps we could agree that when a proxy decides a translation is 
something the caller would like to know it should use a redirect, and 
when the UAC receives such a redirect is should display the action to 
the caller.

	Paul

>>-----Original Message-----
>>From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
>>Sent: Monday, January 27, 2003 6:06 PM
>>To: Rosen, Brian
>>Cc: 'Michael Hammer'; 'Henning Schulzrinne'; 'sipping@ietf.org'
>>Subject: Re: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
>>
>>
>>
>>
>>Rosen, Brian wrote:
>>
>>>Actually, it's not clear to me that we have to be quite so 
>>>restrictive. It is possible that the rule is actually that 
>>
>>the proxy 
>>
>>>has to be able to either translate to a fully routable tel 
>>
>>uri OR that 
>>
>>>it has to forward it to a proxy that can do that.  If, for example, 
>>>I send 8977@pitt.marconi.com; context="coventry-marconi", the local 
>>>(roaming) proxy at pit could forward the call to 
>>
>>coventry.marconi.com 
>>
>>>for processing using the coventry-marconi context.  The pitt proxy
>>>would need routing rules to be able to do that.
>>
>>Detail: I can't quite figure out what you intend. I think you are 
>>proposing sending to
>>
>>sip:8977;phone-context=coventry-marconi@pitt.marconi.com;user=phone
>>
>>but that isn't quite legal. Things that would be are:
>>
>>tel:8977;phone-context=coventry.marconi.com
>>sip:8977;phone-context=coventry.marconi.com@pitt.marconi.com;u
>>ser=phone
>>
>>There there isn't necessarily any relationship between the 
>>proxy names 
>>and the context names, but I have made them the same to suggest there 
>>might be a meaningful relationship in this case.
>>
>>
>>>Having said that, if my home is pitt, I roam to coventry and invite
>>>someone in coventry, I don't want pitt's routing to send the call to
>>>a gateway in Pittsburgh!  If pitt expands the number to a globally
>>>routable number and redirects the call, coventry can "least cost
>>>route" it.
>>
>>There are several possibilities here. (I assume when you roam to 
>>coventry your outbound calls transit the coventry.marconi.com 
>>proxy first.)
>>
>>1) if you use the tel: form above, the proxy naturally 
>>understands the 
>>context and routes the call directly. Your home proxy isn't 
>>involved at all.
>>
>>2) if you use the sip form above, the coventry proxy is supposed to 
>>honor the domain, and forward the call to the pitt.marconi.com proxy.
>>
>>2a) the pitt proxy might use a pitt gateway - your worst fear 
>>confirmed
>>
>>2b) the pitt proxy might redirect to some global number (e.g. 
>>tel:+445558977) and then the local proxy would use a local gateway to 
>>get there.
>>
>>Now instead, assume that you had roamed to coventry and are trying to 
>>dial a number 1234 in pitt:
>>
>>3) you might use tel:1234;phone-context=pitt.marconi.com and 
>>send it to 
>>the coventry proxy.
>>
>>3a) the coventry proxy might know the context and know that 
>>the best way 
>>to get the call there. For instance it might by default 
>>forward the call 
>>to the pitt.marconi.com proxy, but if that fails it could 
>>also know to 
>>translate the address and use a local GW.
>>
>>3b) the coventry proxy might not know the context, but might have a 
>>convention to automatically route calls to unknown FQDN style 
>>contexts 
>>to a sip proxy with that name.
>>
>>4) you might use 
>>sip:1234;phone-context=pitt.marconi.com@pitt.marconi.com and 
>>send it to 
>>the coventry proxy. In this case the coventry proxy must 
>>forward to the 
>>pitt proxy which will then probably use a local gw.  This is 
>>almost as 
>>good as (3a) except with the sip path is down between 
>>convenry and pitt.
>>
>>
>>My conclusion is that using a tel: gives the most options to 
>>do things well.
>>
>>	Paul
>>
> 
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan 30 07:58:39 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26252
	for <sipping-archive@odin.ietf.org>; Thu, 30 Jan 2003 07:58:39 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0UDKYB30298
	for sipping-archive@odin.ietf.org; Thu, 30 Jan 2003 08:20:34 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UDKYJ30295
	for <sipping-web-archive@optimus.ietf.org>; Thu, 30 Jan 2003 08:20:34 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26234
	for <sipping-web-archive@ietf.org>; Thu, 30 Jan 2003 07:58:07 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UDJaJ30204;
	Thu, 30 Jan 2003 08:19:36 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UDHDJ30125
	for <sipping@optimus.ietf.org>; Thu, 30 Jan 2003 08:17:13 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26119;
	Thu, 30 Jan 2003 07:54:47 -0500 (EST)
Message-Id: <200301301254.HAA26119@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sipping@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Thu, 30 Jan 2003 07:54:47 -0500
Subject: [Sipping] I-D ACTION:draft-ietf-sipping-qsig2sip-00.txt
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF.

	Title		: Interworking between SIP and QSIG
	Author(s)	: J. Elwell
	Filename	: draft-ietf-sipping-qsig2sip-00.txt
	Pages		: 54
	Date		: 2003-1-29
	
This document specifies interworking between the Session Initiation 
Protocol (SIP) and QSIG within corporate telecommunication networks 
(also known as enterprise networks). SIP is an Internet application-
layer control (signalling) protocol for creating, modifying, and 
terminating sessions with one or more participants. These sessions 
include, in particular, telephone calls. QSIG is a signalling 
protocol for creating, modifying and terminating circuit-switched 
calls, in particular telephone calls, within Private Integrated 
Services Networks (PISNs). QSIG is specified in a number of ECMA 
Standards and published also as ISO/IEC standards. 
As the support of telephony within corporate networks evolves from 
circuit-switched technology to Internet technology, the two 
technologies will co-exist in many networks for a period, perhaps 
several years. Therefore there is a need to be able to establish, 
modify and terminate sessions involving a participant in the SIP 
network and a participant in the QSIG network. Such calls are 
supported by gateways that perform interworking between SIP and QSIG. 
This document is a product of the authors' activities in ECMA 
(www.ecma.ch) on interoperability of QSIG with IP networks.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-qsig2sip-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sipping-qsig2sip-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sipping-qsig2sip-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-1-29154918.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sipping-qsig2sip-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sipping-qsig2sip-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-1-29154918.I-D@ietf.org>

--OtherAccess--

--NextPart--


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan 30 10:20:52 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00826
	for <sipping-archive@odin.ietf.org>; Thu, 30 Jan 2003 10:20:52 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0UFNuH07796
	for sipping-archive@odin.ietf.org; Thu, 30 Jan 2003 10:23:56 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UFNuJ07792
	for <sipping-web-archive@optimus.ietf.org>; Thu, 30 Jan 2003 10:23:56 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00817
	for <sipping-web-archive@ietf.org>; Thu, 30 Jan 2003 10:20:20 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UFN7J07734;
	Thu, 30 Jan 2003 10:23:07 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UFIOJ07149
	for <sipping@optimus.ietf.org>; Thu, 30 Jan 2003 10:18:24 -0500
Received: from mailgate.siemenscomms.co.uk (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00680
	for <sipping@ietf.org>; Thu, 30 Jan 2003 10:14:49 -0500 (EST)
Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk
 (PMDF V6.0-24 #45905) id <0H9J00D019600G@siemenscomms.co.uk> for
 sipping@ietf.org; Thu, 30 Jan 2003 15:18:01 +0000 (GMT)
Received: from beex10.siemenscomms.co.uk ([137.223.246.252])
 by siemenscomms.co.uk (PMDF V6.0-24 #45905)
 with ESMTP id <0H9J00C4I95AXH@siemenscomms.co.uk> for sipping@ietf.org; Thu,
 30 Jan 2003 15:17:34 +0000 (GMT)
Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21)
	id <D6VF61N0>; Thu, 30 Jan 2003 15:17:52 +0000
Content-return: allowed
Date: Thu, 30 Jan 2003 15:18:07 +0000
From: "Elwell, John" <john.elwell@siemens.com>
Subject: RE: [Sipping] I-D ACTION:draft-ietf-sipping-qsig2sip-00.txt
To: "'sipping@ietf.org'" <sipping@ietf.org>
Message-id: <DE9048A49FFFE547BBC42F855DC8CC3740C0EE@beex53.siemenscomms.co.uk>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Content-Transfer-Encoding: 7BIT
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7BIT
Content-Transfer-Encoding: 7BIT

Compared with draft-elwell-sipping-qsig2sip-03 the following changes have
been made:

- change to wording of first bullet of 8.2.1.3 concerning handling of 180
response;
- changes to some references and definitions.

The authors feel that this draft is now quite mature and that working group
last call could be considered soon.

John Elwell
e-mail: mailto:john.elwell@siemens.com

> -----Original Message-----
> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> Sent: 30 January 2003 12:55
> Cc: sipping@ietf.org
> Subject: [Sipping] I-D ACTION:draft-ietf-sipping-qsig2sip-00.txt
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> This draft is a work item of the Session Initiation Proposal 
> Investigation Working Group of the IETF.
> 
> 	Title		: Interworking between SIP and QSIG
> 	Author(s)	: J. Elwell
> 	Filename	: draft-ietf-sipping-qsig2sip-00.txt
> 	Pages		: 54
> 	Date		: 2003-1-29
> 	
> This document specifies interworking between the Session Initiation 
> Protocol (SIP) and QSIG within corporate telecommunication networks 
> (also known as enterprise networks). SIP is an Internet application-
> layer control (signalling) protocol for creating, modifying, and 
> terminating sessions with one or more participants. These sessions 
> include, in particular, telephone calls. QSIG is a signalling 
> protocol for creating, modifying and terminating circuit-switched 
> calls, in particular telephone calls, within Private Integrated 
> Services Networks (PISNs). QSIG is specified in a number of ECMA 
> Standards and published also as ISO/IEC standards. 
> As the support of telephony within corporate networks evolves from 
> circuit-switched technology to Internet technology, the two 
> technologies will co-exist in many networks for a period, perhaps 
> several years. Therefore there is a need to be able to establish, 
> modify and terminate sessions involving a participant in the SIP 
> network and a participant in the QSIG network. Such calls are 
> supported by gateways that perform interworking between SIP and QSIG. 
> This document is a product of the authors' activities in ECMA 
> (www.ecma.ch) on interoperability of QSIG with IP networks.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-sipping-qsig2sip-00.txt
> 
> To remove yourself from the IETF Announcement list, send a message to 
> ietf-announce-request with the word unsubscribe in the body 
> of the message.
> 
> Internet-Drafts are also available by anonymous FTP. Login 
> with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-ietf-sipping-qsig2sip-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	mailserv@ietf.org.
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-sipping-qsig2sip-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan 30 10:45:27 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01958
	for <sipping-archive@odin.ietf.org>; Thu, 30 Jan 2003 10:45:27 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0UFmVZ09985
	for sipping-archive@odin.ietf.org; Thu, 30 Jan 2003 10:48:31 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UFmVJ09982
	for <sipping-web-archive@optimus.ietf.org>; Thu, 30 Jan 2003 10:48:31 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01893
	for <sipping-web-archive@ietf.org>; Thu, 30 Jan 2003 10:44:55 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UFlvJ09858;
	Thu, 30 Jan 2003 10:47:57 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UFijJ09676
	for <sipping@optimus.ietf.org>; Thu, 30 Jan 2003 10:44:45 -0500
Received: from zoe.office.snowshore.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01812
	for <sipping@ietf.org>; Thu, 30 Jan 2003 10:41:08 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Sipping] Do Phones Have Dial Plans, or do Proxies map?  was RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
Date: Thu, 30 Jan 2003 10:44:41 -0500
Message-ID: <4A3384433CE2AB46A63468CB207E209D24871C@zoe.office.snowshore.com>
Thread-Topic: [Sipping] Do Phones Have Dial Plans, or do Proxies map?  was RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
Thread-Index: AcK38cohl2KDlweyR5aGeUEnMoefnQP9kEBA
From: "Eric Burger" <eburger@snowshore.com>
To: "Rosen, Brian" <Brian.Rosen@marconi.com>,
        "Paul Kyzivat" <pkyzivat@cisco.com>, <sipping@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0UFijJ09677
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

Why are we doing it at all?

Can't it be a local matter?

For example, a PingTel phone "does it all".

A Marconi IP PBX has a local understanding between the phone and the outbound proxy.

Is there real value in casting this in stone?

> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: Thursday, January 09, 2003 10:12 AM
> To: 'Paul Kyzivat'; 'sipping@ietf.org'
> Subject: [Sipping] Do Phones Have Dial Plans, or do Proxies 
> map? was RE:
> [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
> 
> 
> This comes up a lot.  I think we should decide.
> 
> Who translates a dial string into a tel uri?
> 
> tel uris, as of now, explicitly don't handle dialing strings,
> only dialed numbers.  In essentially all existing systems,
> phones don't have dialing plans in them; central elements
> map dialing strings to dialed numbers.  What's our story?
> Does every UA that has a dial pad have to have a dialing plan 
> loaded in it that maps dialing strings to dialed numbers, 
> or does a proxy server do it?
> 
> If it's the former, then how do we standardize the mapping?
> If it's the latter, then how does a UA send a dialing string?
> 
> Brian
> 
> > -----Original Message-----
> > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> > Sent: Thursday, January 09, 2003 9:53 AM
> > To: 'sipping@ietf.org'
> > Subject: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
> > 
> > 
> > I have a few comments about draft-schulzrinne-sipping-sos-04.txt.
> > (I haven't been following this work very closely, so 
> perhaps some of 
> > these pertain to things that were in earlier drafts.)
> > 
> > I must say, these are really messy problems, so I am glad you are 
> > working on them.
> > 
> > Section 3.2 says:
> > 
> >     ... a UAC MAY use a "tel" URI [3,4] without 
> phone-context, such as
> > 
> >     tel:911
> >     tel:112
> > 
> > The latest and greatest definition of the tel: uri that I 
> can find is 
> > draft-antti-rfc2806bis-07.txt. According to that, the above 
> tel: uris 
> > are syntactically incorrect. Either the number must be global 
> > or else it 
> > must contain a phone-context parameter.
> > 
> > Are there plans to change the definition of the tel uri, or is this 
> > language going to change?
> > 
> > In the case of a UAC that is using a local outbound proxy, is it 
> > required that the UAC specifically recognize these strings 
> > and deliver 
> > them to the proxy, or is it sufficient for it to deliver 
> any and all 
> > dialed digit strings to the proxy as tel uris without attempting to 
> > recognize them itself? Is it sufficient to determine that 
> the dialed 
> > number is complete by timeout on the input rather than by 
> recognition?
> > 
> > Section 5 specifies that the UAC should insert location 
> > information into 
> > emergency calls. However, presumably location information should in 
> > general not be placed in non-emergency calls, so it is 
> important that 
> > the UAC realize it is making an emergency call. In the case 
> of dialed 
> > digit strings, it may only be the outbound proxy that can 
> > determine if 
> > the call is an emergency call. One way to handle this would 
> > be for the 
> > local outbound proxy to redirect requests to tel: emergency 
> > numbers to 
> > the corresponding sip:sos number. Then the UAC would be able to 
> > positively determine this is an emergency call and include 
> > the location 
> > information.
> > 
> > Section 9 says:
> > 
> >     We propose a new DHCP option that enumerates the valid local
> >     emergency identifiers, as a list of "tel", "sip" or "sips" URIs.
> > 
> > This doesn't seem sufficient. Most phone-like devices have 
> > provision for 
> > entering primarily sequences of digits, not tel: uris. It is 
> > up to the 
> > phone to translate a digit sequence into a valid uri. In 
> general this 
> > requires some sort of dial plan. Without the dial plan, the 
> phone may 
> > well not be able to generate anything that matches one of the 
> > specified 
> > tel uris.
> > 
> > 	Paul
> > 
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sip@ietf.org for new developments of core SIP
> > 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Thu Jan 30 10:45:32 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01971
	for <sipping-archive@odin.ietf.org>; Thu, 30 Jan 2003 10:45:32 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0UFmb010009
	for sipping-archive@odin.ietf.org; Thu, 30 Jan 2003 10:48:37 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UFmbJ10006
	for <sipping-web-archive@optimus.ietf.org>; Thu, 30 Jan 2003 10:48:37 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01900
	for <sipping-web-archive@ietf.org>; Thu, 30 Jan 2003 10:44:59 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UFlxJ09881;
	Thu, 30 Jan 2003 10:47:59 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UFimJ09680
	for <sipping@optimus.ietf.org>; Thu, 30 Jan 2003 10:44:48 -0500
Received: from zoe.office.snowshore.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01817
	for <sipping@ietf.org>; Thu, 30 Jan 2003 10:41:10 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Sipping] RFC 3351 and Generic Transcoding
Date: Thu, 30 Jan 2003 10:44:41 -0500
Message-ID: <4A3384433CE2AB46A63468CB207E209D24871D@zoe.office.snowshore.com>
Thread-Topic: [Sipping] RFC 3351 and Generic Transcoding
Thread-Index: AcKdJoP3GDzzn6gnRi2BfhvQOTx8FAqwftQQ
From: "Eric Burger" <eburger@snowshore.com>
To: "A vWijk" <A.vWijk@viataal.nl>, <sipping@ietf.org>,
        <mwatson@nortelnetworks.com>
Cc: <Gonzalo.Camarillo@lmf.ericsson.se>, <drage@lucent.com>,
        <Guido.Gybels@rnid.org.uk>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0UFimJ09682
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

I would offer that the burden of transcoding is "whomever wishes to pay."

If you notice you cannot match any of the offered SDP, you can request a transcoding service.  In the worst case, both parties invoke transcoding services.  Is that really likely to happen often?  If not, I wouldn't worry about it.

> -----Original Message-----
> From: A vWijk [mailto:A.vWijk@viataal.nl]
> Sent: Friday, December 06, 2002 7:49 AM
> To: sipping@ietf.org; mwatson@nortelnetworks.com
> Cc: Gonzalo.Camarillo@lmf.ericsson.se; drage@lucent.com;
> Guido.Gybels@rnid.org.uk; Eric Burger
> Subject: RE: [Sipping] RFC 3351 and Generic Transcoding
> 
> 
> Hello everybody,
> 
> The negotiation of who will/can insert the transcoding 
> service is something that is required, but we have to look at 
> it on HOW to do so.
> It would be useless if both users start the same transcoding service.
> 
> I am thinking perhaps that any user can invoke the 
> transcoding service by default, but that the other party has 
> to be notified that such a tanscoding service is inserted.
> The RNID and ViaTaal plan to describe usecases and scenarios 
> on when a transcoding service will be invoked/inserted (among others).
> Ofcourse, our angle will be the hearing impaired. But the 
> solution will be just as useful for interworking between 3GPP 
> and 3GPP2 systems etc.
> 
> Basically it boils down that A and B have to decide which of 
> them invokes the transcoding service.
> Perhaps a SIP NOTIFY message? We should indeed look deeper at this.
> Perhaps combined with a master/slave setting in the caller 
> preferences (let's make Jonathan crazy :-)? Meaning that the 
> Master will send a message to the slave UA that the 
> transcoding service is to be inserted? And that the slave UA 
> will by default wait for such a message unless timed out on 
> which it will then invoke the transcoding service itself.
> 
> This is just from the top of my mind. I haven't had time to 
> play with those scenarios yet.
> 
> greetz
> 
> Arnoud van Wijk
> 
> 
> ****************************************
> 
> Gonzalo,
> 
> I imagine the requirement from 3GPP will be something like:
> 1) Insertion of a transcoding device between two UAs which do 
> not support a
> common codec.
> 2) Achieve (1) when only 1 of the end devices (UAC or UAS) 
> supports the
> procedures for inviting/inserting/invoking the transcoding service
> 3) Achieve (1) when neither of the devices (UAC and UAS) support the
> procedures for inviting/inserting/invoking the transcoding service
> 
> I guess the requirements in RFC3351 probably cover (1) and 
> perhaps (2),
> although I do not remember much about negotiation of who 
> will/can insert the
> transcoding service. I'm not sure (3) has been addressed anywhere.
> 
> I think (3) is required for interworking between 3GPP and 
> 3GPP2 systems
> (where the terminals may not support a common codec). I am 
> assuming that the
> first release of the 3GPP2 SIP system will not include 
> mandatory support at
> the UA for the procedures for inviting/inserting/invoking the 
> transcoding
> service. Happy to be proved wrong on this!
> 
> As Keith says, some review is required in 3GPP & when this is 
> done I hope
> 3GPP will be able to provide a concrete statement of transcoding
> requirements.
> 
> Regards,
> 
> Mark
> 
> 
> > -----Original Message-----
> > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] 
> > Sent: 26 November 2002 06:42
> > To: Drage, Keith (Keith)
> > Cc: Guido Gybels; sipping@ietf.org; Eric Burger
> > Subject: Re: [Sipping] RFC 3351 and Generic Transcoding
> > 
> > 
> > Keith,
> > 
> > we have heard several times from several folks that we might 
> > be missing
> > requirements. What we would like to have is *examples* of such
> > requirements. This way we can decide whether we have to 
> come up with a
> > more formal document on requirements or, on the other hand, we are
> > already taking them into account.
> > 
> > I am not assuming that new requirements will be related to SDP. I am
> > only guessing, since I have not seen any new requirement so far.
> > 
> > Thanks,
> > 
> > Gonzalo
> > 
> > 
> > "Drage, Keith (Keith)" wrote:
> > > 
> > > If you are referring to what I said in plenary, then it was 
> > not this.
> > > 
> > > To further clarify what I said in plenary:
> > > 
> > > RFC3351 was developed as a set of requirements for the hard 
> > of hearing, not as a general set of transcoding requirements. 
> > Presumably, as it had that limited scope, that was what it 
> > was reviewed for.
> > > 
> > > Now that the design team has decided to design a solution 
> > for general transcoding, the SIPPING group should do a quick 
> > pass through RFC 3351 to see if any requirements are missed.
> > > 
> > > At the moment I do not have any requirements in mind, 
> > related to SIP, SDP or otherwise, but please do not assume 
> > that they can only be SDP issues.
> > > 
> > > As I said in an earlier mail, it will take some time to get 
> > a review by some interested 3GPP people, but I am sure that 
> > it would be appropriate to try and take into account 3GPP 
> > Release 6 requirements now rather than when the design 
> > process has solidified.
> > > 
> > > Keith
> > > 
> > > Keith Drage
> > > Lucent Technologies
> > > Tel: +44 1793 776249
> > > Email: drage@lucent.com 
> > > 
> > > > -----Original Message-----
> > > > From: Gonzalo Camarillo 
> [mailto:Gonzalo.Camarillo@lmf.ericsson.se] 
> > > > Sent: 25 November 2002 12:14
> > > > To: Guido Gybels
> > > > Cc: sipping@ietf.org; Eric Burger
> > > > Subject: Re: [Sipping] RFC 3351 and Generic Transcoding
> > > >
> > > >
> > > > Folks,
> > > >
> > > > as Eric pointed out, some folks said that there are SIP 
> > requirements
> > > > beyong RFC 3351 that we have to take into consideration.
> > > >
> > > > It seems to me that what people have in mind will be 
> > requirements that
> > > > are more related to SDP than to SIP (i.e., they would affect the
> > > > plumbing draft rather than the framework that describes SIP
> > > > procedures),
> > > > but in any event we would like to hear them all.
> > > >
> > > > We will be working on SDP issues (i.e., media policies) 
> > together with
> > > > the conferencing team.
> > > >
> > > > Thanks,
> > > >
> > > > Gonzalo
> > > > _______________________________________________
> > > > Sipping mailing list  
> > https://www1.ietf.org/mailman/listinfo/sipping 
> > > > This list is for NEW development of the application of SIP
> > > > Use sip-implementors@cs.columbia.edu for questions on 
> current sip
> > > > Use sip@ietf.org for new developments of core SIP
> > > >
> > > _______________________________________________
> > > Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping 
> > > This list is for NEW development of the application of SIP
> > > Use sip-implementors@cs.columbia.edu for questions on current sip
> > > Use sip@ietf.org for new developments of core SIP
> > 
> > -- 
> > Gonzalo Camarillo         Phone :  +358  9 299 33 71
> > Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
> > Telecom R&D               Fax   :  +358  9 299 30 52
> > FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com 
> > Finland                   http://www.hut.fi/~gonzalo 
> > _______________________________________________
> > Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping 
> > This list is for NEW development of the application of SIP
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sip@ietf.org for new developments of core SIP
> > 
> 
> ------_=_NextPart_001_01C29D13.1BC2EB76
> Content-Type: text/html;
> 	charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
> 
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> <HTML>
> <HEAD>
> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
> charset=3Diso-8859-1">
> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
> 5.5.2655.35">
> <TITLE>RE: [Sipping] RFC 3351 and Generic Transcoding</TITLE>
> </HEAD>
> <BODY>
> 
> <P><FONT SIZE=3D2>Gonzalo,</FONT>
> </P>
> 
> <P><FONT SIZE=3D2>I imagine the requirement from 3GPP will be 
> something =
> like:</FONT>
> <BR><FONT SIZE=3D2>1) Insertion of a transcoding device 
> between two UAs =
> which do not support a common codec.</FONT>
> <BR><FONT SIZE=3D2>2) Achieve (1) when only 1 of the end 
> devices (UAC =
> or UAS) supports the procedures for inviting/inserting/invoking the =
> transcoding service</FONT></P>
> 
> <P><FONT SIZE=3D2>3) Achieve (1) when neither of the devices 
> (UAC and =
> UAS) support the procedures for inviting/inserting/invoking the =
> transcoding service</FONT></P>
> 
> <P><FONT SIZE=3D2>I guess the requirements in RFC3351 probably cover =
> (1) and perhaps (2), although I do not remember much about 
> negotiation =
> of who will/can insert the transcoding service. I'm not sure (3) has =
> been addressed anywhere.</FONT></P>
> 
> <P><FONT SIZE=3D2>I think (3) is required for interworking 
> between 3GPP =
> and 3GPP2 systems (where the terminals may not support a 
> common codec). =
> I am assuming that the first release of the 3GPP2 SIP system 
> will not =
> include mandatory support at the UA for the procedures for =
> inviting/inserting/invoking the transcoding service. Happy to 
> be proved =
> wrong on this!</FONT></P>
> 
> <P><FONT SIZE=3D2>As Keith says, some review is required in 
> 3GPP &amp; =
> when this is done I hope 3GPP will be able to provide a concrete =
> statement of transcoding requirements.</FONT></P>
> 
> <P><FONT SIZE=3D2>Regards,</FONT>
> </P>
> 
> <P><FONT SIZE=3D2>Mark</FONT>
> </P>
> <BR>
> 
> <P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
> <BR><FONT SIZE=3D2>&gt; From: Gonzalo Camarillo [<A =
> HREF=3D"mailto:Gonzalo.Camarillo@lmf.ericsson.se">mailto:Gonza
> lo.Camaril=
> lo@lmf.ericsson.se</A>]</FONT>
> <BR><FONT SIZE=3D2>&gt; Sent: 26 November 2002 06:42</FONT>
> <BR><FONT SIZE=3D2>&gt; To: Drage, Keith (Keith)</FONT>
> <BR><FONT SIZE=3D2>&gt; Cc: Guido Gybels; sipping@ietf.org; Eric =
> Burger</FONT>
> <BR><FONT SIZE=3D2>&gt; Subject: Re: [Sipping] RFC 3351 and Generic =
> Transcoding</FONT>
> <BR><FONT SIZE=3D2>&gt; </FONT>
> <BR><FONT SIZE=3D2>&gt; </FONT>
> <BR><FONT SIZE=3D2>&gt; Keith,</FONT>
> <BR><FONT SIZE=3D2>&gt; </FONT>
> <BR><FONT SIZE=3D2>&gt; we have heard several times from 
> several folks =
> that we might </FONT>
> <BR><FONT SIZE=3D2>&gt; be missing</FONT>
> <BR><FONT SIZE=3D2>&gt; requirements. What we would like to have is =
> *examples* of such</FONT>
> <BR><FONT SIZE=3D2>&gt; requirements. This way we can decide 
> whether we =
> have to come up with a</FONT>
> <BR><FONT SIZE=3D2>&gt; more formal document on requirements 
> or, on the =
> other hand, we are</FONT>
> <BR><FONT SIZE=3D2>&gt; already taking them into account.</FONT>
> <BR><FONT SIZE=3D2>&gt; </FONT>
> <BR><FONT SIZE=3D2>&gt; I am not assuming that new 
> requirements will be =
> related to SDP. I am</FONT>
> <BR><FONT SIZE=3D2>&gt; only guessing, since I have not seen any new =
> requirement so far.</FONT>
> <BR><FONT SIZE=3D2>&gt; </FONT>
> <BR><FONT SIZE=3D2>&gt; Thanks,</FONT>
> <BR><FONT SIZE=3D2>&gt; </FONT>
> <BR><FONT SIZE=3D2>&gt; Gonzalo</FONT>
> <BR><FONT SIZE=3D2>&gt; </FONT>
> <BR><FONT SIZE=3D2>&gt; </FONT>
> <BR><FONT SIZE=3D2>&gt; &quot;Drage, Keith (Keith)&quot; wrote:</FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; </FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; If you are referring to what I said in =
> plenary, then it was </FONT>
> <BR><FONT SIZE=3D2>&gt; not this.</FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; </FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; To further clarify what I said in =
> plenary:</FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; </FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; RFC3351 was developed as a set of =
> requirements for the hard </FONT>
> <BR><FONT SIZE=3D2>&gt; of hearing, not as a general set of 
> transcoding =
> requirements. </FONT>
> <BR><FONT SIZE=3D2>&gt; Presumably, as it had that limited 
> scope, that =
> was what it </FONT>
> <BR><FONT SIZE=3D2>&gt; was reviewed for.</FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; </FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; Now that the design team has decided to =
> design a solution </FONT>
> <BR><FONT SIZE=3D2>&gt; for general transcoding, the SIPPING group =
> should do a quick </FONT>
> <BR><FONT SIZE=3D2>&gt; pass through RFC 3351 to see if any =
> requirements are missed.</FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; </FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; At the moment I do not have any =
> requirements in mind, </FONT>
> <BR><FONT SIZE=3D2>&gt; related to SIP, SDP or otherwise, but 
> please do =
> not assume </FONT>
> <BR><FONT SIZE=3D2>&gt; that they can only be SDP issues.</FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; </FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; As I said in an earlier mail, it 
> will take =
> some time to get </FONT>
> <BR><FONT SIZE=3D2>&gt; a review by some interested 3GPP 
> people, but I =
> am sure that </FONT>
> <BR><FONT SIZE=3D2>&gt; it would be appropriate to try and take into =
> account 3GPP </FONT>
> <BR><FONT SIZE=3D2>&gt; Release 6 requirements now rather 
> than when the =
> design </FONT>
> <BR><FONT SIZE=3D2>&gt; process has solidified.</FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; </FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; Keith</FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; </FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; Keith Drage</FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; Lucent Technologies</FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; Tel: +44 1793 776249</FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; Email: drage@lucent.com</FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; </FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; &gt; -----Original Message-----</FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; &gt; From: Gonzalo Camarillo [<A =
> HREF=3D"mailto:Gonzalo.Camarillo@lmf.ericsson.se">mailto:Gonza
> lo.Camaril=
> lo@lmf.ericsson.se</A>]</FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; &gt; Sent: 25 November 2002 12:14</FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; &gt; To: Guido Gybels</FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; &gt; Cc: sipping@ietf.org; Eric =
> Burger</FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; &gt; Subject: Re: [Sipping] RFC 
> 3351 and =
> Generic Transcoding</FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; &gt; Folks,</FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; &gt; as Eric pointed out, some 
> folks said =
> that there are SIP </FONT>
> <BR><FONT SIZE=3D2>&gt; requirements</FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; &gt; beyong RFC 3351 that we 
> have to take =
> into consideration.</FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; &gt; It seems to me that what 
> people have =
> in mind will be </FONT>
> <BR><FONT SIZE=3D2>&gt; requirements that</FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; &gt; are more related to SDP 
> than to SIP =
> (i.e., they would affect the</FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; &gt; plumbing draft rather than the =
> framework that describes SIP</FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; &gt; procedures),</FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; &gt; but in any event we would like to =
> hear them all.</FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; &gt; We will be working on SDP issues =
> (i.e., media policies) </FONT>
> <BR><FONT SIZE=3D2>&gt; together with</FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; &gt; the conferencing team.</FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; &gt; Thanks,</FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; &gt; Gonzalo</FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; &gt; =
> _______________________________________________</FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; &gt; Sipping mailing list&nbsp; </FONT>
> <BR><FONT SIZE=3D2>&gt; <A =
> HREF=3D"https://www1.ietf.org/mailman/listinfo/sipping" =
> TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/sippi
> ng</A></FO=
> NT>
> <BR><FONT SIZE=3D2>&gt; &gt; &gt; This list is for NEW 
> development of =
> the application of SIP</FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; &gt; Use 
> sip-implementors@cs.columbia.edu =
> for questions on current sip</FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; &gt; Use sip@ietf.org for new 
> developments =
> of core SIP</FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; =
> _______________________________________________</FONT>
> <BR><FONT SIZE=3D2>&gt; &gt; Sippin
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Fri Jan 31 11:36:11 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11375
	for <sipping-archive@odin.ietf.org>; Fri, 31 Jan 2003 11:36:10 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0VGdjT04655
	for sipping-archive@odin.ietf.org; Fri, 31 Jan 2003 11:39:45 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VGdjJ04652
	for <sipping-web-archive@optimus.ietf.org>; Fri, 31 Jan 2003 11:39:45 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11353
	for <sipping-web-archive@ietf.org>; Fri, 31 Jan 2003 11:35:39 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VGd2J04613;
	Fri, 31 Jan 2003 11:39:02 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VGbTJ04544
	for <sipping@optimus.ietf.org>; Fri, 31 Jan 2003 11:37:29 -0500
Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11320
	for <sipping@ietf.org>; Fri, 31 Jan 2003 11:33:23 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.40])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0VGaqYH013071;
	Fri, 31 Jan 2003 11:36:52 -0500 (EST)
Message-ID: <3E3AA61E.7060305@dynamicsoft.com>
Date: Fri, 31 Jan 2003 11:36:46 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Henning Schulzrinne <hgs@cs.columbia.edu>
CC: hisham.khartabil@nokia.com, aki.niemi@nokia.com, sipping@ietf.org
Subject: Re: [Sipping] Event notification rate limiting requirements
References: <2038BCC78B1AD641891A0D1AE133DBB7FE71AA@esebe019.ntc.nokia.com> <3E353977.2030802@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

inline.

Henning Schulzrinne wrote:
 >> I used this example in a separate discussion and I'll use it again
 >> here: If Aki was driving down from Lapland to Helsinki, I'm
 >> interested to get his presence info once every hour or so. By
 >> subscribing to his presence and limiting the rate of notifications
 >> to 1 per hour is a good thing. I get the notifications
 >> automatically. I don't have to manually subscribe every hour and
 >> waste bandwidth.
 >
 >
 > There are two classes of notifications: stateless and stateful.
 > Presence (closed/busy) is stateful, in that it persists at the
 > receiver until the next announcement. Location is stateless - the
 > accuracy of estimation of the variable just decreases as the rate of
 > updates decreases. In many cases, physical constraints limit the
 > error. If I know you are in a land vehicle, I can draw a circle
 > around a last position report that increases its radius at around 70
 > mph and have high confidence that the entity hasn't suddenly gone
 > into hyperspace.
 >
 > It's relatively easy to ratelimit the latter, much harder to
 > ratelimit the former.

True. Inevitably the result of the rate-limiting will be inaccurate or
obsolete information for longer periods of time. I think that is the
consequence of asking for lower notification rates. Is there any other
choice?

Aki Niemi wrote:
 > I was talking about subscribers increasing the rate to a
 >> number that is higher than the server's allowed maximum. If the
 >> server has a rate limit of the typical once per 5 seconds, the
 >> subscriber must not be able to increase this rate to, say, 5 times
 >> per 5 seconds.
 >>
 >> So the requirement is: The notifier must be able to reject a
 >> subscription containing a rate limit higher that is local
 >> configured maximum.
 >
 >
 > My point was that there is no need to reject such a limit, as long as
 > the notifier MUST be allowed to use a lower rate. So the notifier may
 > accept, and still abide by its own internal default policy of 1
 > notification per 5 seconds. The subscriber is still happy, since its
 > max rate is not exceeded. Such a throttle will be utterly useless,
 > but won't break anything.

Indeed. In fact, the server needs to support the peak notification rate 
for the presentity anyway. Thats because their may be subscribers who 
don't even have rate limiting, and in that case, they get the regular rate.

The only case where this doesnt hold is the "stateless" data, such as 
location, that Hennign mentions above. IN that case, there is no natural 
notification rate of the data. It changes infinitely fast 
(theoretically). So, the server has its own maximum rate that it will 
send notifications at. In such a case, does the subscriber need to know 
that its requested rate won't be honored, and it willg et a lower rate? 
Perhaps. It depends on the application of the location data. If its 
being used in some kind of tracking application, the lower rate may be 
insufficient.

However, one could say the same about presence genreally. I might have 
some application where I NEED to know the presence of your cell phone, 
and if I dont get it, the subscription is useless. That would require 
some kind of presence-require mechanism. I would rather lump all of 
these together and deal with them in the future if a true need arises.

So, to summarize my ramble, I do not think at this time that there is a 
need to reject a subscription because the requested rate is too high.


-Jonathan R.


-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Fri Jan 31 11:37:02 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11415
	for <sipping-archive@odin.ietf.org>; Fri, 31 Jan 2003 11:37:02 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0VGebo04765
	for sipping-archive@odin.ietf.org; Fri, 31 Jan 2003 11:40:37 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VGeaJ04762
	for <sipping-web-archive@optimus.ietf.org>; Fri, 31 Jan 2003 11:40:36 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11391
	for <sipping-web-archive@ietf.org>; Fri, 31 Jan 2003 11:36:30 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VGe5J04704;
	Fri, 31 Jan 2003 11:40:05 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VGcGJ04581
	for <sipping@optimus.ietf.org>; Fri, 31 Jan 2003 11:38:16 -0500
Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11328
	for <sipping@ietf.org>; Fri, 31 Jan 2003 11:34:10 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.40])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0VGbjYH013075;
	Fri, 31 Jan 2003 11:37:46 -0500 (EST)
Message-ID: <3E3AA654.9080308@dynamicsoft.com>
Date: Fri, 31 Jan 2003 11:37:40 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: hisham.khartabil@nokia.com
CC: alan.johnston@wcom.com, margaret_mary@dexceldesigns.com, sipping@ietf.org
Subject: Re: [Sipping] query on conference server
References: <2038BCC78B1AD641891A0D1AE133DBB7FE719B@esebe019.ntc.nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

It is an instance. Sorry for being inaccurate with my terminology.

-Jonathan R.

hisham.khartabil@nokia.com wrote:
 > Is focus a conference server or an instance of a conference? I
 > thought it was the latter, unless you mean the server of a particular
 > conference is a focus.
 >
 > Regards, Hisham
 >
 >
 >> -----Original Message----- From: ext Jonathan Rosenberg
 >> [mailto:jdrosen@dynamicsoft.com] Sent: Friday, January 24, 2003
 >> 11:30 PM To: Alan Johnston Cc: margaretmary; sipping@ietf.org
 >> Subject: Re: [Sipping] query on conference server
 >>
 >>
 >> One additional note. The "models for multiparty conferencing in
 >> sip" is not going to move forward. Its content has been moved into
 >>  the framework document Alan has pointed out, along with other
 >> documents that the framework references.
 >>
 >> To briefly answer your questions, a conference server (called a
 >> focus in SIP) is a SIP user agent. Proxies don't know anything
 >> about conferences. They just route requests to URIs, and a URI
 >> might represent a conference.
 >>
 >> -Jonathan R.
 >>
 >> Alan Johnston wrote:
 >>
 >>> Hi Margaret,
 >>>
 >>> There is a SIPPING design team working on conferencing.
 >>
 >> Information
 >>
 >>> about the work is at:
 >>>
 >>> http://www.softarmor.com/sipping/teams/conf/
 >>>
 >>> I'd recommend you start reading the conferencing framework
 >>> document which may answer your questions:
 >>>
 >>>
 >>>
 >>
 >> http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-co
 >> nferencing-framework-00.txt
 >>
 >>>
 >>> Thanks, Alan Johnston WorldCom sip:alan@digitalari.com
 >>>
 >>> At 09:46 AM 1/23/2003 +0530, margaretmary wrote:
 >>>
 >>>
 >>>> hello sir,
 >>>>
 >>>> Can any one tell me about the conference server
 >>>
 >> application using SIP.
 >>
 >>>> Are these two drafts "Models for Multi Party Conferencing
 >>>
 >> SIP" and " A
 >>
 >>>> Multi-Party Application Framework for SIP"  specify for
 >>>> conference server application.
 >>>>
 >>>> Is their any other draft for this, please tell me.
 >>>>
 >>>> Is it a simple SIP User Agent required to develop
 >>>
 >> conference server.
 >>
 >>>> can SIP proxy server /Redirect server can come along with
 >>>
 >> conference
 >>
 >>>> server.
 >>>>
 >>>> Please help me out with this. Since i am new to SIPPING
 >>>>
 >>>>
 >>>>
 >>>>
 >>>> Regards, Margaret
 >>>>
 >>>> --------------------------------------------------------------
 >>>> Dexcel Electronics Designs (P) Ltd., Bangalore, India
 >>>
 >>>
 >>> _______________________________________________ Sipping mailing
 >>> list  https://www1.ietf.org/mailman/listinfo/sipping This list is
 >>> for NEW development of the application of SIP Use
 >>> sip-implementors@cs.columbia.edu for questions on current sip Use
 >>> sip@ietf.org for new developments of core SIP
 >>>
 >>
 >> -- Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
 >> Chief Scientist                             First Floor dynamicsoft
 >> East Hanover, NJ 07936 jdrosen@dynamicsoft.com
 >> FAX:   (973) 952-5050 http://www.jdrosen.net
 >> PHONE: (973) 952-5000 http://www.dynamicsoft.com
 >>
 >> _______________________________________________ Sipping mailing
 >> list  https://www1.ietf.org/mailman/listinfo/sipping This list is
 >> for NEW development of the application of SIP Use
 >> sip-implementors@cs.columbia.edu for questions on current sip Use
 >> sip@ietf.org for new developments of core SIP
 >>
 >
 >

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP



From mailnull@www1.ietf.org  Fri Jan 31 15:31:58 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17994
	for <sipping-archive@odin.ietf.org>; Fri, 31 Jan 2003 15:31:58 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0VKZbU17539
	for sipping-archive@odin.ietf.org; Fri, 31 Jan 2003 15:35:37 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VKZbJ17536
	for <sipping-web-archive@optimus.ietf.org>; Fri, 31 Jan 2003 15:35:37 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17977
	for <sipping-web-archive@ietf.org>; Fri, 31 Jan 2003 15:31:27 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VKYpJ17491;
	Fri, 31 Jan 2003 15:34:51 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VKWqJ17407
	for <sipping@optimus.ietf.org>; Fri, 31 Jan 2003 15:32:52 -0500
Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17932
	for <sipping@ietf.org>; Fri, 31 Jan 2003 15:28:41 -0500 (EST)
Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66])
	(user=hgs10 mech=PLAIN bits=0)
	by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0VKW9HA025026
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Fri, 31 Jan 2003 15:32:10 -0500 (EST)
Message-ID: <3E3ADD4E.4070901@cs.columbia.edu>
Date: Fri, 31 Jan 2003 15:32:14 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: hisham.khartabil@nokia.com, aki.niemi@nokia.com, sipping@ietf.org
Subject: Re: [Sipping] Event notification rate limiting requirements
References: <2038BCC78B1AD641891A0D1AE133DBB7FE71AA@esebe019.ntc.nokia.com> <3E353977.2030802@cs.columbia.edu> <3E3AA61E.7060305@dynamicsoft.com>
In-Reply-To: <3E3AA61E.7060305@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

> True. Inevitably the result of the rate-limiting will be inaccurate or
> obsolete information for longer periods of time. I think that is the
> consequence of asking for lower notification rates. Is there any other
> choice?

In practice, I suspect that people will use rate-limiting for things 
like location information where reducing the rate reduces the accuracy 
in some predictable fashion, rather than where one 'throttled' 
notification turns the information from useful to completely misleading.

However, we can leave this up to the subscriber and the implementation. 
In many cases, the better thing is to provide several different 
subscriptions, e.g., one that tracks my detailed presence state (do not 
disturb, individual media reachability, etc.), another one that 
basically only tells me if (sum of all OPEN) has changed from zero to 
some positive number. (A poor man's version of a filter.)
Henning

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP