From mailnull@www1.ietf.org  Tue Oct  1 06:06:57 2002
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 GAA05447
	for <sip-archive@odin.ietf.org>; Tue, 1 Oct 2002 06:06:57 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g91A8P525880
	for sip-archive@odin.ietf.org; Tue, 1 Oct 2002 06:08:25 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91A82v25506;
	Tue, 1 Oct 2002 06:08:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91A4jv24007
	for <sip@optimus.ietf.org>; Tue, 1 Oct 2002 06:04:45 -0400
Received: from nt-mail.radvision.com ([212.143.185.30])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05311
	for <sip@ietf.org>; Tue, 1 Oct 2002 06:02:46 -0400 (EDT)
Received: by nt-mail.tlv.radvision.com with Internet Mail Service (5.5.2650.21)
	id <T2K8A63H>; Tue, 1 Oct 2002 13:02:44 +0300
Message-ID: <EE5AF23B5764D511A6B900508BB82A0B23AA18@nt-mail.tlv.radvision.com>
From: Avital Yardeni <Avital@radvision.com>
To: "'sip@ietf.org'" <sip@ietf.org>
Date: Tue, 1 Oct 2002 13:02:39 +0300 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sip] RFC 3261 in PDF format
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>


Hi,

Is there any place that I can found RFC 3261 in *.pdf format instead of
*.txt format.

Thanks,
Avital Yardeni.

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



From mailnull@www1.ietf.org  Tue Oct  1 07:15:28 2002
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 HAA08232
	for <sip-archive@odin.ietf.org>; Tue, 1 Oct 2002 07:15:28 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g91BGvV13322
	for sip-archive@odin.ietf.org; Tue, 1 Oct 2002 07:16:57 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91BGYv13104;
	Tue, 1 Oct 2002 07:16:34 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91BFEv12178
	for <sip@optimus.ietf.org>; Tue, 1 Oct 2002 07:15:14 -0400
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08048
	for <sip@ietf.org>; Tue, 1 Oct 2002 07:13:14 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g91BFCOW028412;
	Tue, 1 Oct 2002 13:15:12 +0200 (MEST)
Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.51])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g91BFBG3003448;
	Tue, 1 Oct 2002 14:15:11 +0300 (EET DST)
Message-ID: <3D9983BE.ED02397E@lmf.ericsson.se>
Date: Tue, 01 Oct 2002 14:15:10 +0300
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: Avital Yardeni <Avital@radvision.com>
CC: "'sip@ietf.org'" <sip@ietf.org>
Subject: Re: [Sip] RFC 3261 in PDF format
References: <EE5AF23B5764D511A6B900508BB82A0B23AA18@nt-mail.tlv.radvision.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

We are working on it, but it is not available yet.

Gonzalo

Avital Yardeni wrote:
> 
> Hi,
> 
> Is there any place that I can found RFC 3261 in *.pdf format instead of
> *.txt format.
> 
> Thanks,
> Avital Yardeni.
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of 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
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Tue Oct  1 07:41:24 2002
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 HAA09670
	for <sip-archive@odin.ietf.org>; Tue, 1 Oct 2002 07:41:24 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g91BgrP22716
	for sip-archive@odin.ietf.org; Tue, 1 Oct 2002 07:42:53 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91BgOv22656;
	Tue, 1 Oct 2002 07:42:24 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91BcNv21466
	for <sip@optimus.ietf.org>; Tue, 1 Oct 2002 07:38:23 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09358;
	Tue, 1 Oct 2002 07:36:22 -0400 (EDT)
Message-Id: <200210011136.HAA09358@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Tue, 01 Oct 2002 07:36:22 -0400
Subject: [Sip] I-D ACTION:draft-ietf-sip-symmetric-response-00.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-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 Protocol Working Group of the IETF.

	Title		: An Extension to the Session Initiation Protocol (SIP) 
                          for Symmetric Response Routing
	Author(s)	: J. Rosenberg, J. Weinberger, H. Schulzrinne
	Filename	: draft-ietf-sip-symmetric-response-00.txt
	Pages		: 12
	Date		: 2002-9-30
	
The Session Initiation Protocol (SIP) operates over UDP and TCP. When
used with UDP, responses to requests are returned to the source
address the request came from, and to the port written into the
topmost Via header field value of the request. This behavior is not
desirable in many cases, most notably, when the client is behind a
Network Address Translator (NAT). This extension defines a new
parameter for the Via header field, called 'rport', that allows a
client to request that the server send the response back to the
source IP address and port where the request came from.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-symmetric-response-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-sip-symmetric-response-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-sip-symmetric-response-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:	<2002-9-30144719.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-symmetric-response-00.txt

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

Content-Type: text/plain
Content-ID:	<2002-9-30144719.I-D@ietf.org>

--OtherAccess--

--NextPart--


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



From mailnull@www1.ietf.org  Tue Oct  1 12:15:43 2002
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 MAA24911
	for <sip-archive@odin.ietf.org>; Tue, 1 Oct 2002 12:15:43 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g91GHEb13938
	for sip-archive@odin.ietf.org; Tue, 1 Oct 2002 12:17:14 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91GEbv13774;
	Tue, 1 Oct 2002 12:14:37 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91GBSv13644
	for <sip@optimus.ietf.org>; Tue, 1 Oct 2002 12:11:28 -0400
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24462
	for <sip@ietf.org>; Tue, 1 Oct 2002 12:09:25 -0400 (EDT)
Received: from sponge.cisco.com (IDENT:mirapoint@sponge.cisco.com [64.101.128.87])
	by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g91GAlB6019653
	for <sip@ietf.org>; Tue, 1 Oct 2002 09:10:47 -0700 (PDT)
Received: from ARUNVENKW2Kl (arunvenk-w2-2.cisco.com [64.101.164.93])
	by sponge.cisco.com (Mirapoint)
	with SMTP id ABK80707;
	Tue, 1 Oct 2002 11:10:46 -0500 (CDT)
From: "Arunachalam Venkatraman" <arunvenk@cisco.com>
To: <sip@ietf.org>
Date: Tue, 1 Oct 2002 11:10:46 -0500
Message-ID: <GFEJJOMGHDNDPFCCCIGNIEAMCNAA.arunvenk@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 V5.50.4807.1700
In-Reply-To: <1292.10.10.13.93.1030700996.squirrel@btlmail.bplmail.com>
Content-Transfer-Encoding: 7bit
Subject: [Sip] RFC3261: Authorization versus Proxy-Authorization in CANCEL
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

In Table 2 and Table 3 in Section 20 of RFC3261, the Authorization header is
shown to be Optional on a  CANCEL while the Proxy-Authorization header is
not applicable on a CANCEL.

What is the reason for this difference?

      Header field          where   proxy ACK BYE CAN INV OPT REG
      ___________________________________________________________
      Authorization           R            o   o   o   o   o   o
      Proxy-Authorization     R      dr    o   o   -   o   o   o

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



From mailnull@www1.ietf.org  Thu Oct  3 00:32:29 2002
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 AAA16919
	for <sip-archive@odin.ietf.org>; Thu, 3 Oct 2002 00:32:29 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g934Y6e10062
	for sip-archive@odin.ietf.org; Thu, 3 Oct 2002 00:34:06 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g934XSv10031;
	Thu, 3 Oct 2002 00:33:28 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g934Ucv09925
	for <sip@optimus.ietf.org>; Thu, 3 Oct 2002 00:30:38 -0400
Received: from bdsl.66.12.12.130.gte.net (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16836
	for <sip@ietf.org>; Thu, 3 Oct 2002 00:28:28 -0400 (EDT)
Received: from dwillis9 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g934UcT18425
	for <sip@ietf.org>; Wed, 2 Oct 2002 23:30:38 -0500
Message-ID: <008001c26a95$9877e1e0$1a02a8c0@dwillis9>
From: "Dean Willis" <dean.willis@softarmor.com>
To: <sip@ietf.org>
Date: Wed, 2 Oct 2002 23:30:25 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Content-Transfer-Encoding: 7bit
Subject: [Sip] test
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

This is a test -- haven't seen anything in a day, so I'm a wondering . . .

--
Dean

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



From mailnull@www1.ietf.org  Thu Oct  3 07:17:29 2002
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 HAA02289
	for <sip-archive@odin.ietf.org>; Thu, 3 Oct 2002 07:17:29 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g93BIxC07124
	for sip-archive@odin.ietf.org; Thu, 3 Oct 2002 07:18:59 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93BIZv07073;
	Thu, 3 Oct 2002 07:18:35 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93BDNv06762
	for <sip@optimus.ietf.org>; Thu, 3 Oct 2002 07:13:23 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01857;
	Thu, 3 Oct 2002 07:11:21 -0400 (EDT)
Message-Id: <200210031111.HAA01857@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Thu, 03 Oct 2002 07:11:21 -0400
Subject: [Sip] I-D ACTION:draft-idnani-sip-comb-reg-subscr-00.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

--NextPart

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


	Title		: SIP Combined Registration and Subscription
	Author(s)	: A. Idnani, T. Hallin, S. Upp
	Filename	: draft-idnani-sip-comb-reg-subscr-00.txt
	Pages		: 10
	Date		: 2002-10-2
	
This memo proposes that the headers of REGISTER and SUBSCRIBE be    
combined, so that a REGISTER message can also be treated as an    
implicit subscription for events. This memo identifies the need for    
doing this, and then explains how combining the Registration and 
Subscription solves the problem. It also presents an example flow    
demonstrating the use of this combined registration and subscription.   
The headers being combined will be made optional in the REGISTER and   
SUBSCRIBE messages - depending on where they do not appear as of    
today - so that backward compatibility is maintained.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-idnani-sip-comb-reg-subscr-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-idnani-sip-comb-reg-subscr-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-idnani-sip-comb-reg-subscr-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:	<2002-10-2132814.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-idnani-sip-comb-reg-subscr-00.txt

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

Content-Type: text/plain
Content-ID:	<2002-10-2132814.I-D@ietf.org>

--OtherAccess--

--NextPart--


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



From mailnull@www1.ietf.org  Thu Oct  3 07:27:35 2002
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 HAA02696
	for <sip-archive@odin.ietf.org>; Thu, 3 Oct 2002 07:27:35 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g93BT4e07938
	for sip-archive@odin.ietf.org; Thu, 3 Oct 2002 07:29:04 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93BSjv07864;
	Thu, 3 Oct 2002 07:28:45 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93BEcv06877
	for <sip@optimus.ietf.org>; Thu, 3 Oct 2002 07:14:38 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02127;
	Thu, 3 Oct 2002 07:12:37 -0400 (EDT)
Message-Id: <200210031112.HAA02127@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Thu, 03 Oct 2002 07:12:37 -0400
Subject: [Sip] I-D ACTION:draft-idnani-sip-contact-timestamp-00.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

--NextPart

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


	Title		: New Parameter for Contact Header
	Author(s)	: A. Idnani
	Filename	: draft-idnani-sip-contact-timestamp-00.txt
	Pages		: 7
	Date		: 2002-10-2
	
This memo proposes a new parameter for the SIP Contact header This  
memo identifies the need for the new parameter, and then goes ahead  
and defines the new parameter, and the algorithm for using the new 
parameter. It also presents an example flow demonstrating the use of 
the new parameter. The new parameter being defined is an optional 
parameter, and is not required to be supported by the SIP servers and 
UAs to be interoperational.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-idnani-sip-contact-timestamp-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-idnani-sip-contact-timestamp-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-idnani-sip-contact-timestamp-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:	<2002-10-2140807.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-idnani-sip-contact-timestamp-00.txt

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

Content-Type: text/plain
Content-ID:	<2002-10-2140807.I-D@ietf.org>

--OtherAccess--

--NextPart--


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



From mailnull@www1.ietf.org  Thu Oct  3 08:00:54 2002
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 IAA03647
	for <sip-archive@odin.ietf.org>; Thu, 3 Oct 2002 08:00:54 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g93C2Pm10199
	for sip-archive@odin.ietf.org; Thu, 3 Oct 2002 08:02:25 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93C0Zv10091;
	Thu, 3 Oct 2002 08:00:35 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93BvPv09923
	for <sip@optimus.ietf.org>; Thu, 3 Oct 2002 07:57:25 -0400
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 HAA03530
	for <sip@ietf.org>; Thu, 3 Oct 2002 07:55:23 -0400 (EDT)
Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net
          via smtpd (for [132.151.6.1]) with SMTP; 3 Oct 2002 11:57:23 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"
Date: Thu, 3 Oct 2002 12:57:25 +0100
Message-ID: <45730E094814E44488F789C1CDED27AE018C24B2@GBNEWP0758M.eu.ubiquity.net>
Thread-Topic: Retransmission of INVITEs
Thread-Index: AcJq1Aok+lk5+Os8Tz6IqM1DZejkpw==
From: "James Undery" <jundery@ubiquity.net>
To: "SIP (E-mail)" <sip@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g93BvPv09924
Subject: [Sip] Retransmission of INVITEs
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit

Hi,

	Whilst refreshing my knowledge of retransmission I came across a problem I thought had been resolved, and yet can't find it in the SIP archives. Retransmission of INVITEs cease upon receipt of provisional responses (the reliability of final responses is left to the server transaction), however, this introduces a problem for 100 responses (not generic 1xxs). The problem is a UAC sends an INVITE, a proxy responds with 100 and then promptly dies. The UAC has ceased retransmission of the INVITE waiting for a response that'll never come. My favoured solution would be for 100s to INVITEs to step the retransmission to T2 and have non 100 provisional responses stop retransmission. Anyway is this a non problem / stupid solution?

James

P.S. I am far less concerned about proxy failure once the request has actually reached the UAS, so ignored that.
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Thu Oct  3 08:44:09 2002
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 IAA04913
	for <sip-archive@odin.ietf.org>; Thu, 3 Oct 2002 08:44:09 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g93CjeI13117
	for sip-archive@odin.ietf.org; Thu, 3 Oct 2002 08:45:40 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93CjAv13062;
	Thu, 3 Oct 2002 08:45:10 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93CdVv12802
	for <sip@optimus.ietf.org>; Thu, 3 Oct 2002 08:39:31 -0400
Received: from WS0005.indiatimes.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04676
	for <sip@ietf.org>; Thu, 3 Oct 2002 08:37:19 -0400 (EDT)
Received: from 192.168.57.15 (a3 [192.168.57.23])
	by WS0005.indiatimes.com (8.9.3/8.9.3) with SMTP id RAA05586
	for <sip@ietf.org>; Thu, 3 Oct 2002 17:48:29 +0530
From: "shilpa_ramesh" <shilpa_ramesh@indiatimes.com>
Message-Id: <200210031218.RAA05586@WS0005.indiatimes.com>
To: <sip@ietf.org>
Reply-To: "shilpa_ramesh"<shilpa_ramesh@indiatimes.com>
Date: Thu, 03 Oct 2002 17:42:39 +0530
X-URL: http://indiatimes.com
Content-Type: multipart/alternative;
	   boundary="=_MAILER_ATTACH_BOUNDARY1_200210341742391801979802"
MIME-Version: 1.0
Subject: [Sip] Hello all
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

--=_MAILER_ATTACH_BOUNDARY1_200210341742391801979802
Content-Type: text/plain; charset=us-ascii

Hello ALL,


I am new to SIP..could anyone tell me how to go abt this....it will be of great help to me...


thanking you...


Shilpa.B.R
Get Your Private, Free E-mail from Indiatimes at  http://email.indiatimes.com
Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in
Change the way you talk. Indiatimes presents "Valufon", Your PC to Phone service with clear voice at rates far less than the normal ISD rates. Go to http://www.valufon.indiatimes.com. Choose your plan. BUY NOW.

--=_MAILER_ATTACH_BOUNDARY1_200210341742391801979802
Content-Type: text/html; charset=us-ascii

<P>Hello ALL,</P>
<P>I am new to SIP..could anyone tell me how to go abt this....it will be of great help to me...</P>
<P>thanking you...</P>
<P>Shilpa.B.R</P>
<hr><font face="Arial" size="2"><b>Get Your Private, Free E-mail from Indiatimes at  </font><a href="http://email.indiatimes.com"><font face="Arial" size="2">http://email.indiatimes.com</font></a></b><br>Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from <A href="http://www.planetm.co.in">http://www.planetm.co.in</A><br><font face="Arial" size="2">Change the way you talk. Indiatimes presents "Valufon", Your PC to Phone service with clear voice at rates far less than the normal ISD rates. Go to <a href="http://www.valufon.indiatimes.com">http://www.valufon.indiatimes.com</a>. Choose your plan. BUY NOW.</font>

--=_MAILER_ATTACH_BOUNDARY1_200210341742391801979802--

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



From mailnull@www1.ietf.org  Thu Oct  3 11:23:56 2002
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 LAA17668
	for <sip-archive@odin.ietf.org>; Thu, 3 Oct 2002 11:23:56 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g93FPTY27035
	for sip-archive@odin.ietf.org; Thu, 3 Oct 2002 11:25:29 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93FKvv26624;
	Thu, 3 Oct 2002 11:20:57 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93FDov25829
	for <sip@optimus.ietf.org>; Thu, 3 Oct 2002 11:13:50 -0400
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 LAA16215
	for <sip@ietf.org>; Thu, 3 Oct 2002 11:11:46 -0400 (EDT)
Received: from dgismtp01.wcomnet.com ([166.38.58.141])
 by firewall.wcom.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May  7
 2002)) with ESMTP id <0H3E00E7PVHIY7@firewall.wcom.com> for sip@ietf.org; Thu,
 03 Oct 2002 15:10:30 +0000 (GMT)
Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com
 (iPlanet Messaging Server 5.1 HotFix 0.7 (built May  7 2002))
 with SMTP id <0H3E00F01VHIZZ@dgismtp01.wcomnet.com>; Thu,
 03 Oct 2002 15:10:30 +0000 (GMT)
Received: from ajohnston.wcom.com ([166.42.32.73])
 by dgismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7
 2002)) with ESMTP id <0H3E00FB7VHG1B@dgismtp01.wcomnet.com>; Thu,
 03 Oct 2002 15:10:29 +0000 (GMT)
Date: Thu, 03 Oct 2002 10:10:18 -0500
From: Alan Johnston <alan.johnston@wcom.com>
Subject: Re: [Sip] RFC3261: Authorization versus Proxy-Authorization in CANCEL
In-reply-to: <GFEJJOMGHDNDPFCCCIGNIEAMCNAA.arunvenk@cisco.com>
X-Sender: Alan.Johnston@pop.mcit.com
To: Arunachalam Venkatraman <arunvenk@cisco.com>, sip@ietf.org
Message-id: <5.1.1.6.0.20021003100608.022b08e8@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
References: <1292.10.10.13.93.1030700996.squirrel@btlmail.bplmail.com>
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

Hi Arunachalam,

A CANCEL can not be challenged with either a 407 or a 401 because it can 
not be resubmitted with an incremented CSeq (the CSeq must be identical to 
the INVITE it is matching).

The row of Table 2 for Authorization should show a "-" for CANCEL to 
indicate that it is not applicable.

Thanks,
Alan Johnston
WorldCom
sip:alan@digitalari.com

At 11:10 AM 10/1/2002 -0500, Arunachalam Venkatraman wrote:
>In Table 2 and Table 3 in Section 20 of RFC3261, the Authorization header is
>shown to be Optional on a  CANCEL while the Proxy-Authorization header is
>not applicable on a CANCEL.
>
>What is the reason for this difference?
>
>       Header field          where   proxy ACK BYE CAN INV OPT REG
>       ___________________________________________________________
>       Authorization           R            o   o   o   o   o   o
>       Proxy-Authorization     R      dr    o   o   -   o   o   o
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip

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



From mailnull@www1.ietf.org  Thu Oct  3 12:25:05 2002
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 MAA22588
	for <sip-archive@odin.ietf.org>; Thu, 3 Oct 2002 12:25:05 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g93GQda32412
	for sip-archive@odin.ietf.org; Thu, 3 Oct 2002 12:26:39 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93GPov32324;
	Thu, 3 Oct 2002 12:25:50 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93GK9v32096
	for <sip@optimus.ietf.org>; Thu, 3 Oct 2002 12:20:09 -0400
Received: from mailgw2.technion.ac.il (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22030
	for <sip@ietf.org>; Thu, 3 Oct 2002 12:18:04 -0400 (EDT)
Received: by mailgw2.technion.ac.il (Postfix, from userid 60999)
	id 3AC3536DC8; Thu,  3 Oct 2002 19:11:06 +0300 (IDT)
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
	by mailgw2.technion.ac.il (Postfix) with ESMTP id 9B20336DC3
	for <sarab@CS.TECHNION.AC.IL>; Thu,  3 Oct 2002 19:11:02 +0300 (IDT)
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id LAA02237
	for ietf-123-outbound.07@ietf.org; Thu, 3 Oct 2002 11:15:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA00231
	for <all-ietf@loki.ietf.org>; Thu, 3 Oct 2002 07:14:36 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02127;
	Thu, 3 Oct 2002 07:12:37 -0400 (EDT)
Message-Id: <200210031112.HAA02127@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Date: Thu, 03 Oct 2002 07:12:37 -0400
Subject: [Sip] I-D ACTION:draft-idnani-sip-contact-timestamp-00.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

--NextPart

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


	Title		: New Parameter for Contact Header
	Author(s)	: A. Idnani
	Filename	: draft-idnani-sip-contact-timestamp-00.txt
	Pages		: 7
	Date		: 2002-10-2
	
This memo proposes a new parameter for the SIP Contact header This  
memo identifies the need for the new parameter, and then goes ahead  
and defines the new parameter, and the algorithm for using the new 
parameter. It also presents an example flow demonstrating the use of 
the new parameter. The new parameter being defined is an optional 
parameter, and is not required to be supported by the SIP servers and 
UAs to be interoperational.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-idnani-sip-contact-timestamp-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-idnani-sip-contact-timestamp-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-idnani-sip-contact-timestamp-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:	<2002-10-2140807.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-idnani-sip-contact-timestamp-00.txt

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

Content-Type: text/plain
Content-ID:	<2002-10-2140807.I-D@ietf.org>

--OtherAccess--

--NextPart--


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



From mailnull@www1.ietf.org  Thu Oct  3 13:07:42 2002
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 NAA25179
	for <sip-archive@odin.ietf.org>; Thu, 3 Oct 2002 13:07:42 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g93H9G802986
	for sip-archive@odin.ietf.org; Thu, 3 Oct 2002 13:09:16 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93H0Yv02017;
	Thu, 3 Oct 2002 13:00:34 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93GuPv01852
	for <sip@optimus.ietf.org>; Thu, 3 Oct 2002 12:56:25 -0400
Received: from ajax.cnchost.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24410
	for <sip@ietf.org>; Thu, 3 Oct 2002 12:54:19 -0400 (EDT)
Received: from laptopeng3 (mtdc-216-194-193-131.mdtechdevctr.com [216.194.193.131])
	by ajax.cnchost.com
	id MAA16986; Thu, 3 Oct 2002 12:56:16 -0400 (EDT)
	[ConcentricHost SMTP Relay 1.14]
Message-ID: <03cd01c26afd$f5c65080$1fe4b4cc@laptopeng3>
From: "Medhavi Bhatia" <mbhatia@nextone.com>
To: "James Undery" <jundery@ubiquity.net>, "SIP \(E-mail\)" <sip@ietf.org>
References: <45730E094814E44488F789C1CDED27AE018C24B2@GBNEWP0758M.eu.ubiquity.net>
Subject: Re: [Sip] Retransmission of INVITEs
Date: Thu, 3 Oct 2002 12:57:29 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

James,

I dont understand why the retransmission will be necessary in this case
after the 100. Since it is a UA, the user is already
monitoring the call, so he will hangup when no response is received. If its
a B2BUA/proxy, timer C should take care of this.

-Medhavi.

----- Original Message -----
From: "James Undery" <jundery@ubiquity.net>
To: "SIP (E-mail)" <sip@ietf.org>
Sent: Thursday, October 03, 2002 7:57 AM
Subject: [Sip] Retransmission of INVITEs


Hi,

Whilst refreshing my knowledge of retransmission I came across a problem I
thought had been resolved, and yet can't find it in the SIP archives.
Retransmission of INVITEs cease upon receipt of provisional responses (the
reliability of final responses is left to the server transaction), however,
this introduces a problem for 100 responses (not generic 1xxs). The problem
is a UAC sends an INVITE, a proxy responds with 100 and then promptly dies.
The UAC has ceased retransmission of the INVITE waiting for a response
that'll never come. My favoured solution would be for 100s to INVITEs to
step the retransmission to T2 and have non 100 provisional responses stop
retransmission. Anyway is this a non problem / stupid solution?

James

P.S. I am far less concerned about proxy failure once the request has
actually reached the UAS, so ignored that.
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


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



From mailnull@www1.ietf.org  Thu Oct  3 14:16:04 2002
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 OAA28833
	for <sip-archive@odin.ietf.org>; Thu, 3 Oct 2002 14:16:04 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g93IHbK06839
	for sip-archive@odin.ietf.org; Thu, 3 Oct 2002 14:17:37 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93IGvv06765;
	Thu, 3 Oct 2002 14:16:57 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93I8Ov06471
	for <sip@optimus.ietf.org>; Thu, 3 Oct 2002 14:08:24 -0400
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 OAA28472
	for <sip@ietf.org>; Thu, 3 Oct 2002 14:06:20 -0400 (EDT)
Received: from sponge.cisco.com (IDENT:mirapoint@sponge.cisco.com [64.101.128.87])
	by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g93I8BaW021384;
	Thu, 3 Oct 2002 11:08:11 -0700 (PDT)
Received: from ARUNVENKW2Kl (arunvenk-w2kl.cisco.com [64.101.150.156])
	by sponge.cisco.com (Mirapoint)
	with SMTP id ABL08890;
	Thu, 3 Oct 2002 13:08:18 -0500 (CDT)
From: "Arunachalam Venkatraman" <arunvenk@cisco.com>
To: "James Undery" <jundery@ubiquity.net>, "SIP \(E-mail\)" <sip@ietf.org>
Subject: RE: [Sip] Retransmission of INVITEs
Date: Thu, 3 Oct 2002 13:08:17 -0500
Message-ID: <GFEJJOMGHDNDPFCCCIGNEEBBCNAA.arunvenk@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)
In-Reply-To: <45730E094814E44488F789C1CDED27AE018C24B2@GBNEWP0758M.eu.ubiquity.net>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

James
What is the problem with this scenario that you are seeking to solve?

If the calling user does not get a response in a certain time the user will
hang up.

If the UAC is concerned about the calling user(possibly automata or truant
caller) not giving up on the call, then a timer can be run to CANCEL the
INVITE.

If the INVITE is expected to take a long time to elicit a response from the
called user, then it is recommended that an INVITE be re-sent before 3
minutes have elapsed (even thoug a 100 TRYING has been received), since
intervening proxies run a timer > 3minutes before CANCELing the INVITE.

Venkat

-----Original Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of James
Undery
Sent: Thursday, October 03, 2002 6:57 AM
To: SIP (E-mail)
Subject: [Sip] Retransmission of INVITEs


Hi,

	Whilst refreshing my knowledge of retransmission I came across a problem I
thought had been resolved, and yet can't find it in the SIP archives.
Retransmission of INVITEs cease upon receipt of provisional responses (the
reliability of final responses is left to the server transaction), however,
this introduces a problem for 100 responses (not generic 1xxs). The problem
is a UAC sends an INVITE, a proxy responds with 100 and then promptly dies.
The UAC has ceased retransmission of the INVITE waiting for a response
that'll never come. My favoured solution would be for 100s to INVITEs to
step the retransmission to T2 and have non 100 provisional responses stop
retransmission. Anyway is this a non problem / stupid solution?

James

P.S. I am far less concerned about proxy failure once the request has
actually reached the UAS, so ignored that.
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip

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



From mailnull@www1.ietf.org  Thu Oct  3 14:27:52 2002
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 OAA29466
	for <sip-archive@odin.ietf.org>; Thu, 3 Oct 2002 14:27:52 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g93ITPD07496
	for sip-archive@odin.ietf.org; Thu, 3 Oct 2002 14:29:25 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93ISmv07463;
	Thu, 3 Oct 2002 14:28:48 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93IPMv07326
	for <sip@optimus.ietf.org>; Thu, 3 Oct 2002 14:25:22 -0400
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 OAA29256
	for <sip@ietf.org>; Thu, 3 Oct 2002 14:23:17 -0400 (EDT)
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 g93IOR9H019593;
	Thu, 3 Oct 2002 14:24:30 -0400 (EDT)
Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <S3PQX40D>; Thu, 3 Oct 2002 12:04:25 -0500
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A641ED@DYN-TX-EXCH-001.dynamicsoft.com>
From: Adam Roach <adam@dynamicsoft.com>
To: sip@ietf.org
Cc: "'Ajaykumar.Idnani@motorola.com'" <Ajaykumar.Idnani@motorola.com>,
        "'Steve.Upp@motorola.com'" <Steve.Upp@motorola.com>,
        "'thallin@motorola.com'" <thallin@motorola.com>
Date: Thu, 3 Oct 2002 12:04:18 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sip] Comments on draft-idnani-sip-comb-reg-subscr-00.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

I have a several comments on the draft "SIP Combined Registration
and Subscription".

General Priciple:
-----------------

1) As a working group, we long ago reached the conclusion that
   combining multiple operations into a single request is a
   really bad idea, and have worked hard to avoid it. This is
   why, for example, uploading of CPL scripts in REGISTER messages
   has been depricated. Among other problems, it becomes
   impossible to describe what failed in partial-failure scenarios.

2) Another principle we have embraced is that we will design the
   tools for creating powerful services in such a way that they
   work as independantly of each other as possible. This is often
   stated as selecting generality over efficiency. This is, for
   example, why we have selected to standardize the general
   capability described by the "REFER" draft instead of the
   onetime competing proposal for a "TRANSFER" verb.

Process:
--------

Currently, the way of getting work items onto the SIP working
group agenda is to formulate a group of requirement in the
SIPPING working group, and then develop the acutal mechanism
in the SIP working group.

Specific Mechanism:
-------------------

1) It is not clear how the proposed mechanism solves the problem
   described in the introduction. However,
   the described mechanism doesn't solve this problem any better
   than a standard REGISTER and SUBSCRIBE message sent
   separately. Has there been some sort of major cut-and-paste
   error, or did I miss the linkage?

2) The draft proposes:

      This memo also proposes that a NOTIFY SHOULD not be sent      
      immediately on receiving the REGISTER, since the proxy UA would      
      have all the required information on presence, or would get it in
      the 200 OK response. So a NOTIFY SHOULD only be sent when the      
      presence information changes like when the old contact is removed,

      or a new contact address is added,  the old contact SHOULD to be      
      informed of this change.

   Unfortunately, this isn't a workable solution. The immediate NOTIFY
   was placed in RFC3265 quite purposefully to solve a wide variety
   of problems. Forking of requests is the most obvious, but it serves
   other important purposes, such as communicating the state of the
   subscription itself (in addition to the resource), and providing
   a final negotiated expiration time.

3) In many, if not most, cases, the subscriber will want information
   about more than one resource (that is, he will want to subscribe
   to more than one resouce, and often, more than one type of event
   package). It is not clear how the proposed mechanism could
   handle this case.

4) One of the more important bits of information when subscribing
   for presence is the identity contained in the Request-URI.
   However, for REGISTER messages, this Request-URI is required
   to contain the identity of the registrar. It is highly
   doubtful that the intention is to subscribe to the presence
   of the registrar. So, from the current description, it
   is not clear at all to which resource the subscription would be.

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



From mailnull@www1.ietf.org  Thu Oct  3 15:22:57 2002
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 PAA02171
	for <sip-archive@odin.ietf.org>; Thu, 3 Oct 2002 15:22:57 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g93JOVO10533
	for sip-archive@odin.ietf.org; Thu, 3 Oct 2002 15:24:31 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93JNEv10432;
	Thu, 3 Oct 2002 15:23:14 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93JJGv10304
	for <sip@optimus.ietf.org>; Thu, 3 Oct 2002 15:19:16 -0400
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 PAA01782
	for <sip@ietf.org>; Thu, 3 Oct 2002 15:17:12 -0400 (EDT)
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 g93JJE8g014994
	for <sip@ietf.org>; Thu, 3 Oct 2002 15:19:15 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAS03777;
	Thu, 3 Oct 2002 15:23:59 -0400 (EDT)
Message-ID: <3D9C982D.BF96C897@cisco.com>
Date: Thu, 03 Oct 2002 15:19:09 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@ietf.org
References: <200210031112.HAA02127@ietf.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Re: I-D ACTION:draft-idnani-sip-contact-timestamp-00.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

The general concept here seems interesting, but I have some issues with the details:

The idea seems to be to provide enough information so that different UAs representing the "same" device can cooperate to minimize multiple registrations of that device. But while the "created" timestamp is helpful for this purpose, it doesn't seem sufficient. For a UA to use the created timestamps for this purpose, it must assume that multiple contacts registered for the same Address of Record do in fact represent the "same" device. But this need not be the case. It could be that other things are also registered, as alternatives providing voicemail support, or to support other media, or whatever.

To achieve your purpose, I think you need something else, such as a deviceid parameter, that can be used by multiple UAs representing the same device to indicate the identity of that device. With that, a UA making a registration would want to check for the existence of another registration with a newer timestamp and the same deviceid before deciding to unregister itself. (Conceivably you could use the user part of the sip address for this purpose. But doing so presumes that all UAs representing the device agree on how to represent the name of the device as a user part in the url. This is probably not a good assumption.)

Another issue is that your technique for assigning timestamps assumes that the timestamp is assigned by the registrar only when a REGISTER with a new callid is received. That assumes that subsequent REGISTER messages under the same callid are only refreshes of the same contact address. This need not be the case. It is quite legal for subsequent REGISTERs to add new contact addresses. In this case, the newly added contact addresses should receive new timestamps. 

Finally, you haven't said what should happen if a Contact header in a REGISTER message happens to contain a "created=" parameter. This is currently legal, as an extension parameter. Should this be an error, should the registrar accept the parameter and avoid assigning its own, or should it replace the value with the timestamp it assigns? 

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



From mailnull@www1.ietf.org  Thu Oct  3 16:35:11 2002
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 QAA03989
	for <sip-archive@odin.ietf.org>; Thu, 3 Oct 2002 16:35:11 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g93KakK13970
	for sip-archive@odin.ietf.org; Thu, 3 Oct 2002 16:36:46 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93KaFv13945;
	Thu, 3 Oct 2002 16:36:15 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93KWHv13828
	for <sip@optimus.ietf.org>; Thu, 3 Oct 2002 16:32:17 -0400
Received: from motgate.mot.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03831
	for <sip@ietf.org>; Thu, 3 Oct 2002 16:30:11 -0400 (EDT)
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id NAA29365 for <sip@ietf.org>; Thu, 3 Oct 2002 13:32:11 -0700 (MST)]
Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id NAA00687 for <sip@ietf.org>; Thu, 3 Oct 2002 13:32:10 -0700 (MST)]
Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52)
	id <R807PXR7>; Thu, 3 Oct 2002 15:32:10 -0500
Message-ID: <A5B4C9A2AD89D411AB3E009027B0DA1E05133A94@IL27EXM09.cig.mot.com>
From: Idnani Ajaykumar-AIDNANI1 <Ajaykumar.Idnani@motorola.com>
To: "'Paul Kyzivat'" <pkyzivat@cisco.com>, sip@ietf.org
Subject: RE: [Sip] Re: I-D ACTION:draft-idnani-sip-contact-timestamp-00.tx
	t
Date: Thu, 3 Oct 2002 15:32:10 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.52)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

Paul,

My comments are inline.

-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@cisco.com] 
Sent: Thursday, October 03, 2002 2:19 PM
To: sip@ietf.org
Subject: [Sip] Re: I-D ACTION:draft-idnani-sip-contact-timestamp-00.txt

The general concept here seems interesting, but I have some issues with the details:

The idea seems to be to provide enough information so that different UAs representing the "same" device can cooperate to minimize multiple registrations of that device. But while the "created" timestamp is helpful for this purpose, it doesn't seem sufficient. For a UA to use the created timestamps for this purpose, it must assume that multiple contacts registered for the same Address of Record do in fact represent the "same" device. But this need not be the case. It could be that other things are also registered, as alternatives providing voicemail support, or to support other media, or whatever.

[Ajay says] You are right, the "created" parameter only provides a means of identifying the time at which the contact addresses were created. The UA is completely free as to what it does with that information. In the case I have listed in the draft the UA knows that the device can have only one contact address. But you are right if there are multiple contact addresses then we would need a mechanism to identify the contact addresses from the same device.

To achieve your purpose, I think you need something else, such as a deviceid parameter, that can be used by multiple UAs representing the same device to indicate the identity of that device. With that, a UA making a registration would want to check for the existence of another registration with a newer timestamp and the same deviceid before deciding to unregister itself. (Conceivably you could use the user part of the sip address for this purpose. But doing so presumes that all UAs representing the device agree on how to represent the name of the device as a user part in the url. This is probably not a good assumption.)

[Ajay says] A "deviceid" parameter with the contact address is a good idea. There used to be a SIP draft which talked about a "tag" parameter with contact addresses, which solved the same purpose, however the Registrar behavior for handling the tag parameter was to replace the contact address with the new one.

Another issue is that your technique for assigning timestamps assumes that the timestamp is assigned by the registrar only when a REGISTER with a new callid is received. That assumes that subsequent REGISTER messages under the same callid are only refreshes of the same contact address. This need not be the case. It is quite legal for subsequent REGISTERs to add new contact addresses. In this case, the newly added contact addresses should receive new timestamps. 

[Ajay says] Yes. I guess I really meant when a new contact address is added. I was just trying to simplify the process by looking at the CSeq and check if it is 1 REGISTER. But in the case where more contact addresses are added through subsequent REGISTER messages, then these contact addresses should also receive new timestamps.

Finally, you haven't said what should happen if a Contact header in a REGISTER message happens to contain a "created=" parameter. This is currently legal, as an extension parameter. Should this be an error, should the registrar accept the parameter and avoid assigning its own, or should it replace the value with the timestamp it assigns? 

[Ajay says] In the case where the "created" parameter is found on the REGISTER message the parameter should be ignored. The idea was to have a central authority record the timestamp, rather than the UA, in which case we would need to deal with the case of clocks being out of sync.

Thank you for your inputs.
- Ajay

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



From mailnull@www1.ietf.org  Thu Oct  3 17:35:14 2002
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 RAA05935
	for <sip-archive@odin.ietf.org>; Thu, 3 Oct 2002 17:35:14 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g93Laof17871
	for sip-archive@odin.ietf.org; Thu, 3 Oct 2002 17:36:50 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93LZcv17816;
	Thu, 3 Oct 2002 17:35:38 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93LW7v17698
	for <sip@optimus.ietf.org>; Thu, 3 Oct 2002 17:32:07 -0400
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 RAA05826
	for <sip@ietf.org>; Thu, 3 Oct 2002 17:30:00 -0400 (EDT)
Received: from jku07.iptel.org (port-212-202-169-236.reverse.qdsl-home.de [212.202.169.236])
	by fox.iptel.org (8.11.6/8.11.6) with ESMTP id g93LUvn16025;
	Thu, 3 Oct 2002 23:30:58 +0200
Message-Id: <5.1.0.14.0.20021003232430.00b3d3a8@mailhost.fokus.gmd.de>
X-Sender: jiri@iptel.org
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 03 Oct 2002 23:29:20 +0200
To: "Medhavi Bhatia" <mbhatia@nextone.com>,
        "James Undery" <jundery@ubiquity.net>, "SIP \(E-mail\)" <sip@ietf.org>
From: Jiri Kuthan <jiri@iptel.org>
Subject: Re: [Sip] Retransmission of INVITEs
In-Reply-To: <03cd01c26afd$f5c65080$1fe4b4cc@laptopeng3>
References: <45730E094814E44488F789C1CDED27AE018C24B2@GBNEWP0758M.eu.ubiquity.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

I don't understand what you don't understand.

The problem is an INVITE gets lost, nobody learns that,
caller gets never a final reply and eventually hangs up
even if there is a callee willing to have a call and
restarted proxy willing to help set up the call.

I think James' T2 proposal is fair enough.

-Jiri

At 06:57 PM 10/3/2002, Medhavi Bhatia wrote:
>James,
>
>I dont understand why the retransmission will be necessary in this case
>after the 100. Since it is a UA, the user is already
>monitoring the call, so he will hangup when no response is received. If its
>a B2BUA/proxy, timer C should take care of this.
>
>-Medhavi.
>
>----- Original Message -----
>From: "James Undery" <jundery@ubiquity.net>
>To: "SIP (E-mail)" <sip@ietf.org>
>Sent: Thursday, October 03, 2002 7:57 AM
>Subject: [Sip] Retransmission of INVITEs
>
>
>Hi,
>
>Whilst refreshing my knowledge of retransmission I came across a problem I
>thought had been resolved, and yet can't find it in the SIP archives.
>Retransmission of INVITEs cease upon receipt of provisional responses (the
>reliability of final responses is left to the server transaction), however,
>this introduces a problem for 100 responses (not generic 1xxs). The problem
>is a UAC sends an INVITE, a proxy responds with 100 and then promptly dies.
>The UAC has ceased retransmission of the INVITE waiting for a response
>that'll never come. My favoured solution would be for 100s to INVITEs to
>step the retransmission to T2 and have non 100 provisional responses stop
>retransmission. Anyway is this a non problem / stupid solution?
>
>James
>
>P.S. I am far less concerned about proxy failure once the request has
>actually reached the UAS, so ignored that.
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip
>
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip 

--
Jiri Kuthan            http://iptel.org/~jiri/

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



From mailnull@www1.ietf.org  Thu Oct  3 18:06:14 2002
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 SAA06708
	for <sip-archive@odin.ietf.org>; Thu, 3 Oct 2002 18:06:14 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g93M7ov20119
	for sip-archive@odin.ietf.org; Thu, 3 Oct 2002 18:07:50 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93M6cv19477;
	Thu, 3 Oct 2002 18:06:38 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93M3fv19402
	for <sip@optimus.ietf.org>; Thu, 3 Oct 2002 18:03:41 -0400
Received: from ajax.cnchost.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06555
	for <sip@ietf.org>; Thu, 3 Oct 2002 18:01:33 -0400 (EDT)
Received: from laptopeng3 (mtdc-216-194-193-131.mdtechdevctr.com [216.194.193.131])
	by ajax.cnchost.com
	id SAA01326; Thu, 3 Oct 2002 18:03:17 -0400 (EDT)
	[ConcentricHost SMTP Relay 1.14]
Message-ID: <057201c26b28$d9b029e0$1fe4b4cc@laptopeng3>
From: "Medhavi Bhatia" <mbhatia@nextone.com>
To: "James Undery" <jundery@ubiquity.net>, "SIP \(E-mail\)" <sip@ietf.org>,
        "Jiri Kuthan" <jiri@iptel.org>
References: <45730E094814E44488F789C1CDED27AE018C24B2@GBNEWP0758M.eu.ubiquity.net> <5.1.0.14.0.20021003232430.00b3d3a8@mailhost.fokus.gmd.de>
Subject: Re: [Sip] Retransmission of INVITEs
Date: Thu, 3 Oct 2002 18:04:30 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

I was talking from a protocol perspective (as to resources getting released
on proxies
and all). I agree with you guys that from the user perspective,
the choice is nothing versus a busy tone after a while (if T2 is
incorporated). Is that
right ?

In the latter case, the retransmission stops when a 180 is received. What
happens
if the same situation arises (proxy dies etc) ?

-Medhavi.

----- Original Message -----
From: "Jiri Kuthan" <jiri@iptel.org>
To: "Medhavi Bhatia" <mbhatia@nextone.com>; "James Undery"
<jundery@ubiquity.net>; "SIP (E-mail)" <sip@ietf.org>
Sent: Thursday, October 03, 2002 5:29 PM
Subject: Re: [Sip] Retransmission of INVITEs


I don't understand what you don't understand.

The problem is an INVITE gets lost, nobody learns that,
caller gets never a final reply and eventually hangs up
even if there is a callee willing to have a call and
restarted proxy willing to help set up the call.

I think James' T2 proposal is fair enough.

-Jiri

At 06:57 PM 10/3/2002, Medhavi Bhatia wrote:
>James,
>
>I dont understand why the retransmission will be necessary in this case
>after the 100. Since it is a UA, the user is already
>monitoring the call, so he will hangup when no response is received. If its
>a B2BUA/proxy, timer C should take care of this.
>
>-Medhavi.
>
>----- Original Message -----
>From: "James Undery" <jundery@ubiquity.net>
>To: "SIP (E-mail)" <sip@ietf.org>
>Sent: Thursday, October 03, 2002 7:57 AM
>Subject: [Sip] Retransmission of INVITEs
>
>
>Hi,
>
>Whilst refreshing my knowledge of retransmission I came across a problem I
>thought had been resolved, and yet can't find it in the SIP archives.
>Retransmission of INVITEs cease upon receipt of provisional responses (the
>reliability of final responses is left to the server transaction), however,
>this introduces a problem for 100 responses (not generic 1xxs). The problem
>is a UAC sends an INVITE, a proxy responds with 100 and then promptly dies.
>The UAC has ceased retransmission of the INVITE waiting for a response
>that'll never come. My favoured solution would be for 100s to INVITEs to
>step the retransmission to T2 and have non 100 provisional responses stop
>retransmission. Anyway is this a non problem / stupid solution?
>
>James
>
>P.S. I am far less concerned about proxy failure once the request has
>actually reached the UAS, so ignored that.
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip
>
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip

--
Jiri Kuthan            http://iptel.org/~jiri/



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



From mailnull@www1.ietf.org  Thu Oct  3 21:23:44 2002
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 VAA10231
	for <sip-archive@odin.ietf.org>; Thu, 3 Oct 2002 21:23:44 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g941PLi28878
	for sip-archive@odin.ietf.org; Thu, 3 Oct 2002 21:25:21 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g941Opv28839;
	Thu, 3 Oct 2002 21:24:51 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g941Jsv28696
	for <sip@optimus.ietf.org>; Thu, 3 Oct 2002 21:19:54 -0400
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 VAA10176
	for <sip@ietf.org>; Thu, 3 Oct 2002 21:17:31 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g941Ii9H021649;
	Thu, 3 Oct 2002 21:18:44 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <S3Q8M0NC>; Thu, 3 Oct 2002 21:19:28 -0400
Message-ID: <1407568FD28578458C2F1FFFF30B82BB549508@DYN-EXCH-001.dynamicsoft.com>
From: Igor Slepchin <ISlepchin@dynamicsoft.com>
To: "'Jiri Kuthan'" <jiri@iptel.org>, Medhavi Bhatia <mbhatia@nextone.com>,
        James Undery <jundery@ubiquity.net>, "SIP (E-mail)" <sip@ietf.org>
Subject: RE: [Sip] Retransmission of INVITEs
Date: Thu, 3 Oct 2002 21:19:18 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

I'm actually not sure this problem needs to be solved at transport level.
Even TCP does not provide this kind of reliability - if a TCP segment gets
ACK'ed by the TCP stack and then never delivered or processed to/by the
application, say, because the box dies, the sending application will think
the message was delivered.

The way I see it, the scenario is not that much different from the proxy
failing after forwarding the INVITE when response failover is not available.
In both cases the previous hop will need to detect a failure and take some
action to recover.

Thank you,
Igor Slepchin


> -----Original Message-----
> From: Jiri Kuthan [mailto:jiri@iptel.org]
> 
> I don't understand what you don't understand.
> 
> The problem is an INVITE gets lost, nobody learns that,
> caller gets never a final reply and eventually hangs up
> even if there is a callee willing to have a call and
> restarted proxy willing to help set up the call.
> 
> I think James' T2 proposal is fair enough.
> 
> -Jiri
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Fri Oct  4 02:00:44 2002
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 CAA15700
	for <sip-archive@odin.ietf.org>; Fri, 4 Oct 2002 02:00:43 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9462OQ08221
	for sip-archive@odin.ietf.org; Fri, 4 Oct 2002 02:02:24 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9461Fv08125;
	Fri, 4 Oct 2002 02:01:15 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g945uGv07945
	for <sip@optimus.ietf.org>; Fri, 4 Oct 2002 01:56:16 -0400
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 BAA14572
	for <sip@ietf.org>; Fri, 4 Oct 2002 01:53:49 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.52])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g945tmYH004532;
	Fri, 4 Oct 2002 01:55:48 -0400 (EDT)
Message-ID: <3D9D2D63.8020707@dynamicsoft.com>
Date: Fri, 04 Oct 2002 01:55:47 -0400
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: Igor Slepchin <ISlepchin@dynamicsoft.com>
CC: "'Jiri Kuthan'" <jiri@iptel.org>, Medhavi Bhatia <mbhatia@nextone.com>,
        James Undery <jundery@ubiquity.net>, "SIP (E-mail)" <sip@ietf.org>
Subject: Re: [Sip] Retransmission of INVITEs
References: <1407568FD28578458C2F1FFFF30B82BB549508@DYN-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit



Igor Slepchin wrote:
> I'm actually not sure this problem needs to be solved at transport level.
> Even TCP does not provide this kind of reliability - if a TCP segment gets
> ACK'ed by the TCP stack and then never delivered or processed to/by the
> application, say, because the box dies, the sending application will think
> the message was delivered.

I'm also not sure the problem needs to be solved, but for a different 
reason. It takes very specific timing to manifest itself; a proxy has to 
fail at the very instant between sending a 100 and proxying a request. 
Response failover, which SIP does provide, is meant to address failures 
between proxying a request and receiving a response, but the duration of 
that window of opportunity is orders of magnitude larger.

That said, the problem is more easily solved with TCP. If a client opens 
a TCP connection to a server, sends a request, but the connection closes 
before getting a non-100 response, it opens a connection to a backup 
server.  One can argue that this failure case is already covered in 
section 4.3 of rfc3263, although this was not really the intent.

In the case of UDP, it does require behavior akin to what James is 
proposing. An alternative would be to send the 100 after proxying the 
request. In any case, if we are moving away from UDP in the draft 
version of SIP, its not clear we need to solve this problem for UDP when 
a TCP solution is trivial.

-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

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



From mailnull@www1.ietf.org  Fri Oct  4 02:07:18 2002
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 CAA24002
	for <sip-archive@odin.ietf.org>; Fri, 4 Oct 2002 02:07:18 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9468xV11167
	for sip-archive@odin.ietf.org; Fri, 4 Oct 2002 02:08:59 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94689v10858;
	Fri, 4 Oct 2002 02:08:09 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94656v08792
	for <sip@optimus.ietf.org>; Fri, 4 Oct 2002 02:05:06 -0400
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 CAA18624
	for <sip@ietf.org>; Fri, 4 Oct 2002 02:02:54 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.52])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g9464uYH004539;
	Fri, 4 Oct 2002 02:04:56 -0400 (EDT)
Message-ID: <3D9D2F87.5090301@dynamicsoft.com>
Date: Fri, 04 Oct 2002 02:04:55 -0400
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: sip@ietf.org
Subject: Re: [Sip] Re: I-D ACTION:draft-idnani-sip-contact-timestamp-00.txt
References: <200210031112.HAA02127@ietf.org> <3D9C982D.BF96C897@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit



Paul Kyzivat wrote:
 > To achieve your purpose, I think you need something else, such as a
 > deviceid parameter, that can be used by multiple UAs representing the
 > same device to indicate the identity of that device. With that, a UA
 > making a registration would want to check for the existence of
 > another registration with a newer timestamp and the same deviceid
 > before deciding to unregister itself. (Conceivably you could use the
 > user part of the sip address for this purpose. But doing so presumes
 > that all UAs representing the device agree on how to represent the
 > name of the device as a user part in the url. This is probably not a
 > good assumption.)

Actually, I think its the right assumption.

If you eliminate the gateways which are assumed in the draft, and the 
UA's were pure SIP UA, how would this work? When the UA roams, it 
acquires a new IP address. So, it needs to unregister the old one. It 
can do that directly because it still remembers the URI with which it 
registered previsously, and so can unregister it.

I would argue that, in the case of a gatewayed system, it should work 
identically. It would be the responsibility of the gateways to extract a 
  consistent identity from the devices in order to properly identify the 
old registration in order to remove it. Using some kind of identifier in 
the user part of the URI is the right way to do it.

This would probably be one of several mapping functions that would be 
needed to properly build this gateway function. It seems better to push 
all these things into a gateway specification rather than burden SIP 
with them. We already have a way to identify a device - using the URI.

-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

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



From mailnull@www1.ietf.org  Fri Oct  4 04:42:23 2002
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 EAA26214
	for <sip-archive@odin.ietf.org>; Fri, 4 Oct 2002 04:42:22 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g948i3125255
	for sip-archive@odin.ietf.org; Fri, 4 Oct 2002 04:44:03 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g948hIv25220;
	Fri, 4 Oct 2002 04:43:18 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g948a2v24472
	for <sip@optimus.ietf.org>; Fri, 4 Oct 2002 04:36:02 -0400
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 EAA26113
	for <sip@ietf.org>; Fri, 4 Oct 2002 04:33:49 -0400 (EDT)
From: duncan.mills@vf.vodafone.co.uk
Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id JAA21895; Fri, 4 Oct 2002 09:35:47 +0100 (BST)
Received: from putney.vfl.vodafone (putney [10.33.112.118])
	by mailguard3 (4.6.1.91) with ESMTP id ;
	Fri, 04 Oct 2002 09:38:09 +0100
Received: by putney.vfl.vodafone with Internet Mail Service (5.5.2653.19)
	id <4HQFVCL7>; Fri, 4 Oct 2002 09:35:29 +0100
Message-ID: <DDC3D921FB67D211AAD100A0C9E58F53107E8608@hampstead.vfl.vodafone>
To: adam@dynamicsoft.com, sip@ietf.org, Ajaykumar.Idnani@motorola.com,
        Steve.Upp@motorola.com, thallin@motorola.com
Subject: RE: [Sip] Comments on draft-idnani-sip-comb-reg-subscr-00.txt
Date: Fri, 4 Oct 2002 09:34:33 +0100 
X-Mailer: Internet Mail Service (5.5.2653.19)
MIME-Version: 1.0 (Generated by Clearswift ES version 4.6.1.122)
Content-Type: text/plain;	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

All,

I was expecting comments similar to Adam's, and fully understand them.

However, I would support a more general version of this draft.  For
instance, the real gain I can see (as Adam says, this is only an
optimisation, which SIPPING won't allow) is that one REGISTER request does
the same thing as a REGISTER + X * SUBSCRIBE requests.  But- In the above
draft, the SIP nodes are all in the core network anyway, so this saving is
surely less valuable?

Now, in the 3GPP situation where we send SIP messages across the radio
interface, there is a strong requirement to save radio bandwidth.
Additionally, we also use the SUBSCRIBE/NOTIFY procedures for events other
than presence, so any kind of implicit subscription is attractive...

But isn't the problem with implicit subscription the fact that there is no
call-id for the NOTIFY request to use?  Is there no way around this?

Duncan

-----Original Message-----
From: Adam Roach [mailto:adam@dynamicsoft.com]
Sent: 03 October 2002 18:04
To: sip@ietf.org
Cc: 'Ajaykumar.Idnani@motorola.com'; 'Steve.Upp@motorola.com';
'thallin@motorola.com'
Subject: [Sip] Comments on draft-idnani-sip-comb-reg-subscr-00.txt


I have a several comments on the draft "SIP Combined Registration
and Subscription".

General Priciple:
-----------------

1) As a working group, we long ago reached the conclusion that
   combining multiple operations into a single request is a
   really bad idea, and have worked hard to avoid it. This is
   why, for example, uploading of CPL scripts in REGISTER messages
   has been depricated. Among other problems, it becomes
   impossible to describe what failed in partial-failure scenarios.

2) Another principle we have embraced is that we will design the
   tools for creating powerful services in such a way that they
   work as independantly of each other as possible. This is often
   stated as selecting generality over efficiency. This is, for
   example, why we have selected to standardize the general
   capability described by the "REFER" draft instead of the
   onetime competing proposal for a "TRANSFER" verb.

Process:
--------

Currently, the way of getting work items onto the SIP working
group agenda is to formulate a group of requirement in the
SIPPING working group, and then develop the acutal mechanism
in the SIP working group.

Specific Mechanism:
-------------------

1) It is not clear how the proposed mechanism solves the problem
   described in the introduction. However,
   the described mechanism doesn't solve this problem any better
   than a standard REGISTER and SUBSCRIBE message sent
   separately. Has there been some sort of major cut-and-paste
   error, or did I miss the linkage?

2) The draft proposes:

      This memo also proposes that a NOTIFY SHOULD not be sent      
      immediately on receiving the REGISTER, since the proxy UA would      
      have all the required information on presence, or would get it in
      the 200 OK response. So a NOTIFY SHOULD only be sent when the      
      presence information changes like when the old contact is removed,

      or a new contact address is added,  the old contact SHOULD to be      
      informed of this change.

   Unfortunately, this isn't a workable solution. The immediate NOTIFY
   was placed in RFC3265 quite purposefully to solve a wide variety
   of problems. Forking of requests is the most obvious, but it serves
   other important purposes, such as communicating the state of the
   subscription itself (in addition to the resource), and providing
   a final negotiated expiration time.

3) In many, if not most, cases, the subscriber will want information
   about more than one resource (that is, he will want to subscribe
   to more than one resouce, and often, more than one type of event
   package). It is not clear how the proposed mechanism could
   handle this case.

4) One of the more important bits of information when subscribing
   for presence is the identity contained in the Request-URI.
   However, for REGISTER messages, this Request-URI is required
   to contain the identity of the registrar. It is highly
   doubtful that the intention is to subscribe to the presence
   of the registrar. So, from the current description, it
   is not clear at all to which resource the subscription would be.

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



From mailnull@www1.ietf.org  Fri Oct  4 05:51:59 2002
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 FAA27228
	for <sip-archive@odin.ietf.org>; Fri, 4 Oct 2002 05:51:59 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g949rU428651
	for sip-archive@odin.ietf.org; Fri, 4 Oct 2002 05:53:30 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g949r6v28629;
	Fri, 4 Oct 2002 05:53:06 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g949nHv28510
	for <sip@optimus.ietf.org>; Fri, 4 Oct 2002 05:49:17 -0400
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 FAA27186
	for <sip@ietf.org>; Fri, 4 Oct 2002 05:47:15 -0400 (EDT)
Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net
          via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; 4 Oct 2002 09:49:16 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: [Sip] Retransmission of INVITEs
Date: Fri, 4 Oct 2002 10:49:18 +0100
Message-ID: <45730E094814E44488F789C1CDED27AE018C24B5@GBNEWP0758M.eu.ubiquity.net>
Thread-Topic: [Sip] Retransmission of INVITEs
Thread-Index: AcJriQGVj4zUh9vXQZigqGl2333YiwAARFVQ
From: "James Undery" <jundery@ubiquity.net>
To: "Jiri Kuthan" <jiri.kuthan@fokus.fraunhofer.de>,
        "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>,
        "Igor Slepchin" <ISlepchin@dynamicsoft.com>
Cc: "Jiri Kuthan" <jiri@iptel.org>, "Medhavi Bhatia" <mbhatia@nextone.com>,
        "SIP (E-mail)" <sip@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g949nHv28511
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit

I'd agree the probability of failure is small, however, the case I am thinking about is with an application server, that allows multiple service composition including 3pcc. The application server can't really control the latency introduced by applications and so the window of failure is larger than for a "vanilla" proxy, that combined with the automaton initiating the call is a cause for concern.

On the subject of expense of the change, switching to 100s causing T2 separated retransmissions and non 100 1xx stopping retransmission seems an inexpensive backwardly compatible change.

James

> -----Original Message-----
> From: Jiri Kuthan [mailto:jiri.kuthan@fokus.fraunhofer.de]

> I agree the probability of this failure is low and fixing it
> is expensive. Note that the failure can even occur in your 
> counterexample, when proxy's outbound request gets lost,
> and that the implementation order first-relay-then-100
> breaks stopping retransmissions asap using 100.
> 
> So the question is still whether this little robustness
> risk is worth the extra retransmissions.
> 
> My 2 cents are reliability is good even if expensive.
> 
> -Jiri
> 
> At 07:55 AM 10/4/2002, Jonathan Rosenberg wrote:
> 
> 
> >Igor Slepchin wrote:
> >>I'm actually not sure this problem needs to be solved at 
> transport level.
> >>Even TCP does not provide this kind of reliability - if a 
> TCP segment gets
> >>ACK'ed by the TCP stack and then never delivered or 
> processed to/by the
> >>application, say, because the box dies, the sending 
> application will think
> >>the message was delivered.
> >
> >I'm also not sure the problem needs to be solved, but for a 
> different reason. It takes very specific timing to manifest 
> itself; a proxy has to fail at the very instant between 
> sending a 100 and proxying a request. Response failover, 
> which SIP does provide, is meant to address failures between 
> proxying a request and receiving a response, but the duration 
> of that window of opportunity is orders of magnitude larger.
> >
> >That said, the problem is more easily solved with TCP. If a 
> client opens a TCP connection to a server, sends a request, 
> but the connection closes before getting a non-100 response, 
> it opens a connection to a backup server.  One can argue that 
> this failure case is already covered in section 4.3 of 
> rfc3263, although this was not really the intent.
> >
> >In the case of UDP, it does require behavior akin to what 
> James is proposing. An alternative would be to send the 100 
> after proxying the request. In any case, if we are moving 
> away from UDP in the draft version of SIP, its not clear we 
> need to solve this problem for UDP when a TCP solution is trivial.
> >
> >-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
> >
> >_______________________________________________
> >Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >This list is for NEW development of the core SIP Protocol
> >Use sip-implementors@cs.columbia.edu for questions on current sip
> >Use sipping@ietf.org for new developments on the application of sip
> 
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Fri Oct  4 08:32:23 2002
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 IAA01119
	for <sip-archive@odin.ietf.org>; Fri, 4 Oct 2002 08:32:23 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g94CXv503982
	for sip-archive@odin.ietf.org; Fri, 4 Oct 2002 08:33:57 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94CWwv03944;
	Fri, 4 Oct 2002 08:32:58 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94CTYv03818
	for <sip@optimus.ietf.org>; Fri, 4 Oct 2002 08:29:34 -0400
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 IAA00946
	for <sip@ietf.org>; Fri, 4 Oct 2002 08:27:29 -0400 (EDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g94CTPZC026520;
	Fri, 4 Oct 2002 08:29:25 -0400 (EDT)
Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66])
	(authenticated bits=0)
	by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g94CTM5T002224
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Fri, 4 Oct 2002 08:29:23 -0400 (EDT)
Message-ID: <3D9D8970.2090600@cs.columbia.edu>
Date: Fri, 04 Oct 2002 08:28:32 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2a) Gecko/20020910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: Igor Slepchin <ISlepchin@dynamicsoft.com>,
        "'Jiri Kuthan'" <jiri@iptel.org>, Medhavi Bhatia <mbhatia@nextone.com>,
        James Undery <jundery@ubiquity.net>, "SIP (E-mail)" <sip@ietf.org>
Subject: Re: [Sip] Retransmission of INVITEs
References: <1407568FD28578458C2F1FFFF30B82BB549508@DYN-EXCH-001.dynamicsoft.com> <3D9D2D63.8020707@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

> I'm also not sure the problem needs to be solved, but for a different 
> reason. It takes very specific timing to manifest itself; a proxy has to 
> fail at the very instant between sending a 100 and proxying a request. 
> Response failover, which SIP does provide, is meant to address failures 
> between proxying a request and receiving a response, but the duration of 
> that window of opportunity is orders of magnitude larger.
> 
> That said, the problem is more easily solved with TCP. If a client opens 
> a TCP connection to a server, sends a request, but the connection closes 
> before getting a non-100 response, it opens a connection to a backup 
> server.  One can argue that this failure case is already covered in 
> section 4.3 of rfc3263, although this was not really the intent.

This isn't quite true in all cases. If the server crashes without saying 
farewell at the TCP level, the caller side wouldn't notice. If the 100 
has been ACK'ed at TCP level, the caller's TCP is not waiting for 
anything and thus will gladly sit there doing nothing for months. (I'm 
ignoring TCP-level keep-alives which are rarely turned on and have much 
longer timescales as well as their own set of problems.)

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



From mailnull@www1.ietf.org  Fri Oct  4 08:46:54 2002
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 IAA01524
	for <sip-archive@odin.ietf.org>; Fri, 4 Oct 2002 08:46:54 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g94CmRI04929
	for sip-archive@odin.ietf.org; Fri, 4 Oct 2002 08:48:27 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94ClRv04872;
	Fri, 4 Oct 2002 08:47:27 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94Ci1v04779
	for <sip@optimus.ietf.org>; Fri, 4 Oct 2002 08:44:01 -0400
Received: from cozumel.we-host.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA01353
	for <sip@ietf.org>; Fri, 4 Oct 2002 08:41:56 -0400 (EDT)
Received: (qmail 934 invoked from network); 4 Oct 2002 12:43:48 -0000
Received: from adsl-65-71-246-65.dsl.rcsntx.swbell.net (HELO StephenJames) (65.71.246.65)
  by cozumel.we-host.com with SMTP; 4 Oct 2002 12:43:48 -0000
Message-ID: <001601c26ba3$adfaa0c0$6779a8c0@StephenJames>
From: "Stephen James" <sjames@voiceramp.com>
To: <sip@ietf.org>
References: <DDC3D921FB67D211AAD100A0C9E58F53107E8608@hampstead.vfl.vodafone>
Subject: Re: [Sip] Comments on draft-idnani-sip-comb-reg-subscr-00.txt
Date: Fri, 4 Oct 2002 07:43:45 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

What is the general opinion or policy on using the Content of the REGISTER
for this? Supposedly, the Regstrar in this case is expected to have extended
functionality to support combined REGISTER/SUBSCRIBE, could the a new
content type be developed for Subscriptions that could be contained in the
REGISTER message. By placing such elements as Subscription Call-ID and
request URL into this new content type, some of the problems described below
could be circumvented.

----- Original Message -----
From: <duncan.mills@vf.vodafone.co.uk>
To: <adam@dynamicsoft.com>; <sip@ietf.org>; <Ajaykumar.Idnani@motorola.com>;
<Steve.Upp@motorola.com>; <thallin@motorola.com>
Sent: Friday, October 04, 2002 3:34 AM
Subject: RE: [Sip] Comments on draft-idnani-sip-comb-reg-subscr-00.txt


> All,
>
> I was expecting comments similar to Adam's, and fully understand them.
>
> However, I would support a more general version of this draft.  For
> instance, the real gain I can see (as Adam says, this is only an
> optimisation, which SIPPING won't allow) is that one REGISTER request does
> the same thing as a REGISTER + X * SUBSCRIBE requests.  But- In the above
> draft, the SIP nodes are all in the core network anyway, so this saving is
> surely less valuable?
>
> Now, in the 3GPP situation where we send SIP messages across the radio
> interface, there is a strong requirement to save radio bandwidth.
> Additionally, we also use the SUBSCRIBE/NOTIFY procedures for events other
> than presence, so any kind of implicit subscription is attractive...
>
> But isn't the problem with implicit subscription the fact that there is no
> call-id for the NOTIFY request to use?  Is there no way around this?
>
> Duncan
>
> -----Original Message-----
> From: Adam Roach [mailto:adam@dynamicsoft.com]
> Sent: 03 October 2002 18:04
> To: sip@ietf.org
> Cc: 'Ajaykumar.Idnani@motorola.com'; 'Steve.Upp@motorola.com';
> 'thallin@motorola.com'
> Subject: [Sip] Comments on draft-idnani-sip-comb-reg-subscr-00.txt
>
>
> I have a several comments on the draft "SIP Combined Registration
> and Subscription".
>
> General Priciple:
> -----------------
>
> 1) As a working group, we long ago reached the conclusion that
>    combining multiple operations into a single request is a
>    really bad idea, and have worked hard to avoid it. This is
>    why, for example, uploading of CPL scripts in REGISTER messages
>    has been depricated. Among other problems, it becomes
>    impossible to describe what failed in partial-failure scenarios.
>
> 2) Another principle we have embraced is that we will design the
>    tools for creating powerful services in such a way that they
>    work as independantly of each other as possible. This is often
>    stated as selecting generality over efficiency. This is, for
>    example, why we have selected to standardize the general
>    capability described by the "REFER" draft instead of the
>    onetime competing proposal for a "TRANSFER" verb.
>
> Process:
> --------
>
> Currently, the way of getting work items onto the SIP working
> group agenda is to formulate a group of requirement in the
> SIPPING working group, and then develop the acutal mechanism
> in the SIP working group.
>
> Specific Mechanism:
> -------------------
>
> 1) It is not clear how the proposed mechanism solves the problem
>    described in the introduction. However,
>    the described mechanism doesn't solve this problem any better
>    than a standard REGISTER and SUBSCRIBE message sent
>    separately. Has there been some sort of major cut-and-paste
>    error, or did I miss the linkage?
>
> 2) The draft proposes:
>
>       This memo also proposes that a NOTIFY SHOULD not be sent
>       immediately on receiving the REGISTER, since the proxy UA would
>       have all the required information on presence, or would get it in
>       the 200 OK response. So a NOTIFY SHOULD only be sent when the
>       presence information changes like when the old contact is removed,
>
>       or a new contact address is added,  the old contact SHOULD to be
>       informed of this change.
>
>    Unfortunately, this isn't a workable solution. The immediate NOTIFY
>    was placed in RFC3265 quite purposefully to solve a wide variety
>    of problems. Forking of requests is the most obvious, but it serves
>    other important purposes, such as communicating the state of the
>    subscription itself (in addition to the resource), and providing
>    a final negotiated expiration time.
>
> 3) In many, if not most, cases, the subscriber will want information
>    about more than one resource (that is, he will want to subscribe
>    to more than one resouce, and often, more than one type of event
>    package). It is not clear how the proposed mechanism could
>    handle this case.
>
> 4) One of the more important bits of information when subscribing
>    for presence is the identity contained in the Request-URI.
>    However, for REGISTER messages, this Request-URI is required
>    to contain the identity of the registrar. It is highly
>    doubtful that the intention is to subscribe to the presence
>    of the registrar. So, from the current description, it
>    is not clear at all to which resource the subscription would be.
>
> /a
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>


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



From mailnull@www1.ietf.org  Fri Oct  4 08:55:42 2002
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 IAA01907
	for <sip-archive@odin.ietf.org>; Fri, 4 Oct 2002 08:55:42 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g94CvG105209
	for sip-archive@odin.ietf.org; Fri, 4 Oct 2002 08:57:16 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94CuQv05171;
	Fri, 4 Oct 2002 08:56:26 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g949Jev26859
	for <sip@optimus.ietf.org>; Fri, 4 Oct 2002 05:19:40 -0400
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 FAA26810
	for <sip@ietf.org>; Fri, 4 Oct 2002 05:17:38 -0400 (EDT)
Received: from jku07.fokus.fraunhofer.de (port-212-202-169-236.reverse.qdsl-home.de [212.202.169.236])
	by fox.iptel.org (8.11.6/8.11.6) with ESMTP id g949JMn02711;
	Fri, 4 Oct 2002 11:19:22 +0200
Message-Id: <5.1.0.14.0.20021004111508.00b3d590@mailhost.fokus.gmd.de>
X-Sender: jku@mailhost.fokus.gmd.de
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 04 Oct 2002 11:15:38 +0200
To: Igor Slepchin <ISlepchin@dynamicsoft.com>,
        "'Jiri Kuthan'" <jiri@iptel.org>, Medhavi Bhatia <mbhatia@nextone.com>,
        James Undery <jundery@ubiquity.net>, "SIP (E-mail)" <sip@ietf.org>
From: Jiri Kuthan <jiri.kuthan@fokus.fraunhofer.de>
Subject: RE: [Sip] Retransmission of INVITEs
In-Reply-To: <1407568FD28578458C2F1FFFF30B82BB549508@DYN-EXCH-001.dynami
 csoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

At 03:19 AM 10/4/2002, Igor Slepchin wrote:
>I'm actually not sure this problem needs to be solved at transport level.
>Even TCP does not provide this kind of reliability - if a TCP segment gets
>ACK'ed by the TCP stack and then never delivered or processed to/by the
>application, say, because the box dies, the sending application will think
>the message was delivered.
>
>The way I see it, the scenario is not that much different from the proxy
>failing after forwarding the INVITE when response failover is not available.
>In both cases the previous hop will need to detect a failure and take some
>action to recover.

The problem is the previous hop thinks evertyhing is ok.

-Jiri

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



From mailnull@www1.ietf.org  Fri Oct  4 08:57:51 2002
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 IAA02075
	for <sip-archive@odin.ietf.org>; Fri, 4 Oct 2002 08:57:51 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g94CxOq05351
	for sip-archive@odin.ietf.org; Fri, 4 Oct 2002 08:59:24 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94CwVv05267;
	Fri, 4 Oct 2002 08:58:31 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g949Wmv27393
	for <sip@optimus.ietf.org>; Fri, 4 Oct 2002 05:32:48 -0400
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 FAA27001
	for <sip@ietf.org>; Fri, 4 Oct 2002 05:30:46 -0400 (EDT)
Received: from jku07.fokus.fraunhofer.de (port-212-202-169-236.reverse.qdsl-home.de [212.202.169.236])
	by fox.iptel.org (8.11.6/8.11.6) with ESMTP id g949WYn02811;
	Fri, 4 Oct 2002 11:32:34 +0200
Message-Id: <5.1.0.14.0.20021004112032.03df0d28@mailhost.fokus.gmd.de>
X-Sender: jku@mailhost.fokus.gmd.de
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 04 Oct 2002 11:28:54 +0200
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        Igor Slepchin <ISlepchin@dynamicsoft.com>
From: Jiri Kuthan <jiri.kuthan@fokus.fraunhofer.de>
Subject: Re: [Sip] Retransmission of INVITEs
Cc: "'Jiri Kuthan'" <jiri@iptel.org>, Medhavi Bhatia <mbhatia@nextone.com>,
        James Undery <jundery@ubiquity.net>, "SIP (E-mail)" <sip@ietf.org>
In-Reply-To: <3D9D2D63.8020707@dynamicsoft.com>
References: <1407568FD28578458C2F1FFFF30B82BB549508@DYN-EXCH-001.dynamicsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

I agree the probability of this failure is low and fixing it
is expensive. Note that the failure can even occur in your 
counterexample, when proxy's outbound request gets lost,
and that the implementation order first-relay-then-100
breaks stopping retransmissions asap using 100.

So the question is still whether this little robustness
risk is worth the extra retransmissions.

My 2 cents are reliability is good even if expensive.

-Jiri

At 07:55 AM 10/4/2002, Jonathan Rosenberg wrote:


>Igor Slepchin wrote:
>>I'm actually not sure this problem needs to be solved at transport level.
>>Even TCP does not provide this kind of reliability - if a TCP segment gets
>>ACK'ed by the TCP stack and then never delivered or processed to/by the
>>application, say, because the box dies, the sending application will think
>>the message was delivered.
>
>I'm also not sure the problem needs to be solved, but for a different reason. It takes very specific timing to manifest itself; a proxy has to fail at the very instant between sending a 100 and proxying a request. Response failover, which SIP does provide, is meant to address failures between proxying a request and receiving a response, but the duration of that window of opportunity is orders of magnitude larger.
>
>That said, the problem is more easily solved with TCP. If a client opens a TCP connection to a server, sends a request, but the connection closes before getting a non-100 response, it opens a connection to a backup server.  One can argue that this failure case is already covered in section 4.3 of rfc3263, although this was not really the intent.
>
>In the case of UDP, it does require behavior akin to what James is proposing. An alternative would be to send the 100 after proxying the request. In any case, if we are moving away from UDP in the draft version of SIP, its not clear we need to solve this problem for UDP when a TCP solution is trivial.
>
>-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
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip

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



From mailnull@www1.ietf.org  Fri Oct  4 09:01:03 2002
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 JAA02171
	for <sip-archive@odin.ietf.org>; Fri, 4 Oct 2002 09:01:03 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g94D2bk05542
	for sip-archive@odin.ietf.org; Fri, 4 Oct 2002 09:02:37 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94D2Gv05533;
	Fri, 4 Oct 2002 09:02:16 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94Cxqv05369
	for <sip@optimus.ietf.org>; Fri, 4 Oct 2002 08:59:52 -0400
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 IAA02070
	for <sip@ietf.org>; Fri, 4 Oct 2002 08:57:47 -0400 (EDT)
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 g94CxkDE016891;
	Fri, 4 Oct 2002 08:59:47 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAS07649;
	Fri, 4 Oct 2002 09:04:31 -0400 (EDT)
Message-ID: <3D9D90BD.1076B856@cisco.com>
Date: Fri, 04 Oct 2002 08:59:41 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: sip@ietf.org
Subject: Re: [Sip] Re: I-D ACTION:draft-idnani-sip-contact-timestamp-00.txt
References: <200210031112.HAA02127@ietf.org> <3D9C982D.BF96C897@cisco.com> <3D9D2F87.5090301@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit



Jonathan Rosenberg wrote:
> 
> Paul Kyzivat wrote:
>  > To achieve your purpose, I think you need something else, such as a
>  > deviceid parameter, that can be used by multiple UAs representing the
>  > same device to indicate the identity of that device. With that, a UA
>  > making a registration would want to check for the existence of
>  > another registration with a newer timestamp and the same deviceid
>  > before deciding to unregister itself. (Conceivably you could use the
>  > user part of the sip address for this purpose. But doing so presumes
>  > that all UAs representing the device agree on how to represent the
>  > name of the device as a user part in the url. This is probably not a
>  > good assumption.)
> 
> Actually, I think its the right assumption.
> 
> If you eliminate the gateways which are assumed in the draft, and the
> UA's were pure SIP UA, how would this work? When the UA roams, it
> acquires a new IP address. So, it needs to unregister the old one. It
> can do that directly because it still remembers the URI with which it
> registered previsously, and so can unregister it.
> 
> I would argue that, in the case of a gatewayed system, it should work
> identically. It would be the responsibility of the gateways to extract a
>   consistent identity from the devices in order to properly identify the
> old registration in order to remove it. Using some kind of identifier in
> the user part of the URI is the right way to do it.
> 
> This would probably be one of several mapping functions that would be
> needed to properly build this gateway function. It seems better to push
> all these things into a gateway specification rather than burden SIP
> with them. We already have a way to identify a device - using the URI.

I don't have any particular vested interest in this, so I am satisfied to defer to those that do, if this makes sense to them. 

Perhaps I misunderstand the use case. In the draft the issue was managing the transition between 

	Contact: sip:userA@proxyUA1.visited.com
and	Contact: sip:userA@proxyUA2.visited.com

where both are registered to:

	sip:userA@home.com

Presumably this should also apply if the transition was between 

	Contact: sip:userA@proxyUA1.cellprovider1.com
and	Contact: sip:userA@proxyUA2.cellprovider2.com

The trouble with using the user part is that the user part is supposed to be uninterpretted by all except those within the domain part. So proxyUA1.cellprovider1.com has no business ascribing any particular meaning to the user part of sip:userA@proxyUA2.cellprovider2.com.

It *may* be acceptable for proxyUA1.visited.com to presume to know something about the user part of sip:userA@proxyUA2.visited.com. 

I suppose it may be ok in the cellprovider1/cellprovider2 case if they have some specific business agreement. But I doubt one could reasonably expect to expect IETF to standardize this kind of assumption.

In any case, it seems that minimally the spec should say what kind of matching of contacts is required before deciding that one should defer to another.

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



From mailnull@www1.ietf.org  Fri Oct  4 12:16:10 2002
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 MAA10920
	for <sip-archive@odin.ietf.org>; Fri, 4 Oct 2002 12:16:10 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g94GHiK17920
	for sip-archive@odin.ietf.org; Fri, 4 Oct 2002 12:17:44 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94GH8v17889;
	Fri, 4 Oct 2002 12:17:08 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94GD7v17734
	for <sip@optimus.ietf.org>; Fri, 4 Oct 2002 12:13:07 -0400
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 MAA10150
	for <sip@ietf.org>; Fri, 4 Oct 2002 12:11:01 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g94GBj9H024460;
	Fri, 4 Oct 2002 12:11:45 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <S3Q8NAW7>; Fri, 4 Oct 2002 12:12:30 -0400
Message-ID: <1407568FD28578458C2F1FFFF30B82BB549509@DYN-EXCH-001.dynamicsoft.com>
From: Igor Slepchin <ISlepchin@dynamicsoft.com>
To: "'Jiri Kuthan'" <jiri.kuthan@fokus.fraunhofer.de>,
        Igor Slepchin
	 <ISlepchin@dynamicsoft.com>,
        "'Jiri Kuthan'" <jiri@iptel.org>, Medhavi Bhatia <mbhatia@nextone.com>,
        James Undery <jundery@ubiquity.net>, "SIP (E-mail)" <sip@ietf.org>
Subject: RE: [Sip] Retransmission of INVITEs
Date: Fri, 4 Oct 2002 12:12:22 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

The previous hop will realize there was a failure after timing out without
receiving a final response and can retry sending the request to a backup in
that case. This is fairly similar to non-INVITE failure case where the
previous hop will failover after transaction timeout though timeout in
INVITE case may admittedly be longer. The main difference is that in INVITE
case the previous hop may not know that the problem occurred in the next
hop, but if there is lots of traffic going on between these servers, the
previous hop most likely will have detected the failure by then anyway. 

In any case, if the application is really concerned about this kind of
failures, I think it can retransmit INVITEs even after a 100: not
retransmitting them is a SHOULD strength in the spec...

Thank you,
Igor Slepchin


> -----Original Message-----
> From: Jiri Kuthan [mailto:jiri.kuthan@fokus.fraunhofer.de]
> 
> The problem is the previous hop thinks evertyhing is ok.
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Fri Oct  4 15:25:50 2002
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 PAA17881
	for <sip-archive@odin.ietf.org>; Fri, 4 Oct 2002 15:25:50 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g94JRQR27949
	for sip-archive@odin.ietf.org; Fri, 4 Oct 2002 15:27:26 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94JPFv27899;
	Fri, 4 Oct 2002 15:25:17 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94JLXv27787
	for <sip@optimus.ietf.org>; Fri, 4 Oct 2002 15:21:33 -0400
Received: from magus.nostrum.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17780
	for <sip@ietf.org>; Fri, 4 Oct 2002 15:19:25 -0400 (EDT)
Received: from dynamicsoft.com (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g94JLMpA044060;
	Fri, 4 Oct 2002 14:21:23 -0500 (CDT)
Message-ID: <3D9DEA23.7090403@dynamicsoft.com>
Date: Fri, 04 Oct 2002 14:21:07 -0500
From: Ben Campbell <bcampbell@dynamicsoft.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: duncan.mills@vf.vodafone.co.uk
CC: adam@dynamicsoft.com, sip@ietf.org, Ajaykumar.Idnani@motorola.com,
        Steve.Upp@motorola.com, thallin@motorola.com
Subject: Re: [Sip] Comments on draft-idnani-sip-comb-reg-subscr-00.txt
References: <DDC3D921FB67D211AAD100A0C9E58F53107E8608@hampstead.vfl.vodafone>
X-Enigmail-Version: 0.65.2.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

duncan.mills@vf.vodafone.co.uk wrote:
> All,
> 
> I was expecting comments similar to Adam's, and fully understand them.
> 
> However, I would support a more general version of this draft.  For
> instance, the real gain I can see (as Adam says, this is only an
> optimisation, which SIPPING won't allow) is that one REGISTER request does
> the same thing as a REGISTER + X * SUBSCRIBE requests.  But- In the above
> draft, the SIP nodes are all in the core network anyway, so this saving is
> surely less valuable?

Having a single request perform multiple, otherwise orthagonal, 
operations is a recipe for trouble. You get into situations where one 
operation succeeds, and another fails. There is no way to communicate 
compound results like that back to the requestor.

If you are concerned about the X * subscribe issue for situations where 
you are subscribing to a large number of resources (common for presence 
applications, I suggest you look at the collections draft and related 
discussion instead. If instead, you are concerned about the idea of 
sending a few SUBSCRIBEs for different purposes (i.e. different event 
packages) then I think the added complexity and brittleness introduced 
by combining the operations greatly outweighs the gain of saving a small 
number of transactions.


> 
> Now, in the 3GPP situation where we send SIP messages across the radio
> interface, there is a strong requirement to save radio bandwidth.
> Additionally, we also use the SUBSCRIBE/NOTIFY procedures for events other
> than presence, so any kind of implicit subscription is attractive...
> 
> But isn't the problem with implicit subscription the fact that there is no
> call-id for the NOTIFY request to use?  Is there no way around this?
> 
> Duncan
> 
> -----Original Message-----
> From: Adam Roach [mailto:adam@dynamicsoft.com]
> Sent: 03 October 2002 18:04
> To: sip@ietf.org
> Cc: 'Ajaykumar.Idnani@motorola.com'; 'Steve.Upp@motorola.com';
> 'thallin@motorola.com'
> Subject: [Sip] Comments on draft-idnani-sip-comb-reg-subscr-00.txt
> 
> 
> I have a several comments on the draft "SIP Combined Registration
> and Subscription".
> 
> General Priciple:
> -----------------
> 
> 1) As a working group, we long ago reached the conclusion that
>    combining multiple operations into a single request is a
>    really bad idea, and have worked hard to avoid it. This is
>    why, for example, uploading of CPL scripts in REGISTER messages
>    has been depricated. Among other problems, it becomes
>    impossible to describe what failed in partial-failure scenarios.
> 
> 2) Another principle we have embraced is that we will design the
>    tools for creating powerful services in such a way that they
>    work as independantly of each other as possible. This is often
>    stated as selecting generality over efficiency. This is, for
>    example, why we have selected to standardize the general
>    capability described by the "REFER" draft instead of the
>    onetime competing proposal for a "TRANSFER" verb.
> 
> Process:
> --------
> 
> Currently, the way of getting work items onto the SIP working
> group agenda is to formulate a group of requirement in the
> SIPPING working group, and then develop the acutal mechanism
> in the SIP working group.
> 
> Specific Mechanism:
> -------------------
> 
> 1) It is not clear how the proposed mechanism solves the problem
>    described in the introduction. However,
>    the described mechanism doesn't solve this problem any better
>    than a standard REGISTER and SUBSCRIBE message sent
>    separately. Has there been some sort of major cut-and-paste
>    error, or did I miss the linkage?
> 
> 2) The draft proposes:
> 
>       This memo also proposes that a NOTIFY SHOULD not be sent      
>       immediately on receiving the REGISTER, since the proxy UA would      
>       have all the required information on presence, or would get it in
>       the 200 OK response. So a NOTIFY SHOULD only be sent when the      
>       presence information changes like when the old contact is removed,
> 
>       or a new contact address is added,  the old contact SHOULD to be      
>       informed of this change.
> 
>    Unfortunately, this isn't a workable solution. The immediate NOTIFY
>    was placed in RFC3265 quite purposefully to solve a wide variety
>    of problems. Forking of requests is the most obvious, but it serves
>    other important purposes, such as communicating the state of the
>    subscription itself (in addition to the resource), and providing
>    a final negotiated expiration time.
> 
> 3) In many, if not most, cases, the subscriber will want information
>    about more than one resource (that is, he will want to subscribe
>    to more than one resouce, and often, more than one type of event
>    package). It is not clear how the proposed mechanism could
>    handle this case.
> 
> 4) One of the more important bits of information when subscribing
>    for presence is the identity contained in the Request-URI.
>    However, for REGISTER messages, this Request-URI is required
>    to contain the identity of the registrar. It is highly
>    doubtful that the intention is to subscribe to the presence
>    of the registrar. So, from the current description, it
>    is not clear at all to which resource the subscription would be.
> 
> /a
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 


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



From mailnull@www1.ietf.org  Fri Oct  4 16:14:09 2002
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 QAA19982
	for <sip-archive@odin.ietf.org>; Fri, 4 Oct 2002 16:14:09 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g94KFiG30617
	for sip-archive@odin.ietf.org; Fri, 4 Oct 2002 16:15:44 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94KEfv30563;
	Fri, 4 Oct 2002 16:14:41 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94KCgv30492
	for <sip@optimus.ietf.org>; Fri, 4 Oct 2002 16:12:42 -0400
Received: from motgate4.mot.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19781
	for <sip@ietf.org>; Fri, 4 Oct 2002 16:10:35 -0400 (EDT)
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate4.mot.com (motgate4 2.1) with ESMTP id NAA28112 for <sip@ietf.org>; Fri, 4 Oct 2002 13:12:35 -0700 (MST)]
Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id NAA12168 for <sip@ietf.org>; Fri, 4 Oct 2002 13:12:35 -0700 (MST)]
Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52)
	id <P4H3T10P>; Fri, 4 Oct 2002 15:12:35 -0500
Message-ID: <A5B4C9A2AD89D411AB3E009027B0DA1E05133A97@IL27EXM09.cig.mot.com>
From: Idnani Ajaykumar-AIDNANI1 <Ajaykumar.Idnani@motorola.com>
To: "'Paul Kyzivat'" <pkyzivat@cisco.com>,
        Jonathan Rosenberg
	 <jdrosen@dynamicsoft.com>
Cc: sip@ietf.org
Subject: RE: [Sip] Re: I-D ACTION:draft-idnani-sip-contact-timestamp-00.tx
	t
Date: Fri, 4 Oct 2002 15:12:22 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.52)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

Jonathan, Paul,

Thank you for your comments. My comments are inline....

-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@cisco.com] 
Sent: Friday, October 04, 2002 8:00 AM
To: Jonathan Rosenberg
Cc: sip@ietf.org
Subject: Re: [Sip] Re: I-D ACTION:draft-idnani-sip-contact-timestamp-00.txt



Jonathan Rosenberg wrote:
> 
> Paul Kyzivat wrote:
>  > To achieve your purpose, I think you need something else, such as a
>  > deviceid parameter, that can be used by multiple UAs representing the
>  > same device to indicate the identity of that device. With that, a UA
>  > making a registration would want to check for the existence of
>  > another registration with a newer timestamp and the same deviceid
>  > before deciding to unregister itself. (Conceivably you could use the
>  > user part of the sip address for this purpose. But doing so presumes
>  > that all UAs representing the device agree on how to represent the
>  > name of the device as a user part in the url. This is probably not a
>  > good assumption.)
> 
> Actually, I think its the right assumption.
> 
> If you eliminate the gateways which are assumed in the draft, and the
> UA's were pure SIP UA, how would this work? When the UA roams, it
> acquires a new IP address. So, it needs to unregister the old one. It
> can do that directly because it still remembers the URI with which it
> registered previsously, and so can unregister it.
> 
> I would argue that, in the case of a gatewayed system, it should work
> identically. It would be the responsibility of the gateways to extract a
>   consistent identity from the devices in order to properly identify the
> old registration in order to remove it. Using some kind of identifier in
> the user part of the URI is the right way to do it.
> 
> This would probably be one of several mapping functions that would be
> needed to properly build this gateway function. It seems better to push
> all these things into a gateway specification rather than burden SIP
> with them. We already have a way to identify a device - using the URI.

[Ajay says] I seem to agree with you Jonathan. Anyway how the device is
identified is not in the scope of the draft. It is assumed that the gateway
UA is intelligent enough to deduce that using one of the several ways like
userid, some parameter on the contact / From / To address - like tag, or
some other mechanism. The only new thing the draft suggests is a "created"
parameter for the contact address. How the UA uses this information is
completely up to the UA. It could use it to deregister an old address or it
could ignore it, in which case we could have INVITEs being sent / forked to
multiple contacts.

I don't have any particular vested interest in this, so I am satisfied to
defer to those that do, if this makes sense to them. 

Perhaps I misunderstand the use case. In the draft the issue was managing
the transition between 

	Contact: sip:userA@proxyUA1.visited.com
and	Contact: sip:userA@proxyUA2.visited.com

where both are registered to:

	sip:userA@home.com

Presumably this should also apply if the transition was between 

	Contact: sip:userA@proxyUA1.cellprovider1.com
and	Contact: sip:userA@proxyUA2.cellprovider2.com

The trouble with using the user part is that the user part is supposed to be
uninterpretted by all except those within the domain part. So
proxyUA1.cellprovider1.com has no business ascribing any particular meaning
to the user part of sip:userA@proxyUA2.cellprovider2.com.

It *may* be acceptable for proxyUA1.visited.com to presume to know something
about the user part of sip:userA@proxyUA2.visited.com. 

I suppose it may be ok in the cellprovider1/cellprovider2 case if they have
some specific business agreement. But I doubt one could reasonably expect to
expect IETF to standardize this kind of assumption.

[Ajay says] I don't think I understand completely what you are trying to say
here. But if the visited domain is a cellprovider, then there is a
possibility that the user part could be / carry a cell#. Yes! The cell
providers may need some business agreement in such a case.  In the worst
case if the user address cannot be used to uniquely identify a user across
cell providers than you would end up with more than one contacts, which
would only make the SIP servers / UACs to send / fork INVITEs to more than
one contacts. 

In any case, it seems that minimally the spec should say what kind of
matching of contacts is required before deciding that one should defer to
another.

[Ajay says] Again I think this is out of scope for the draft. What
techniques are used by the contact to identify the user uniquely and should
there be some matching criteria for the contacts is totally dependent on how
the gateway is implemented.

Hope I answered your questions. Feel free to comment if you find any more
issues with the draft.

Thanks
- Ajay

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



From mailnull@www1.ietf.org  Fri Oct  4 22:41:46 2002
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 WAA28854
	for <sip-archive@odin.ietf.org>; Fri, 4 Oct 2002 22:41:46 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g952hPC16561
	for sip-archive@odin.ietf.org; Fri, 4 Oct 2002 22:43:25 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g952gFv16459;
	Fri, 4 Oct 2002 22:42:15 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g952dsv16383
	for <sip@optimus.ietf.org>; Fri, 4 Oct 2002 22:39:54 -0400
Received: from services1.dasecurenetworks.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28713
	for <sip@ietf.org>; Fri, 4 Oct 2002 22:37:41 -0400 (EDT)
Received: from infravast.com (adsl-64-219-190-5.dsl.rcsntx.swbell.net [64.219.190.5])
	by services1.dasecurenetworks.com (8.11.6/8.9.3) with ESMTP id g952RDO24821
	for <sip@ietf.org>; Fri, 4 Oct 2002 21:27:13 -0500
Message-ID: <3D9E50F6.DBC50ACD@infravast.com>
Date: Fri, 04 Oct 2002 21:39:50 -0500
From: Chris Martin <chris@infravast.com>
Reply-To: chris@infravast.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686)
X-Accept-Language: en
MIME-Version: 1.0
CC: sip@ietf.org
Subject: Re: [Sip] I-D ACTION:draft-idnani-sip-comb-reg-subscr-00.txt
References: <200210031111.HAA01857@ietf.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

You wrote in the draft that:
  "When the MS moves to another SIP gateway, the   
   new gateway would also send a SIP REGISTER to the SIP Registrar,
and    
   record itself as being in the path to the MS. However the data at
the   
   old SIP gateway has not been updated, and the old SIP gateway is
not    
   aware of the fact that the MS has moved to a new SIP gateway."

Couldnt the policy on the SIP registrar be set up to recognize only the
last registration recieved? 

I would think that the SIP registrar and location server would maintain
the current location of the MS throughout its travels through the mobile
network. The Proxy UA's (SIP gateway) should merely perform their
function and merely time out the registration based on the Expires
value.

Section 2 describes the presence mechanism call flow, and I have some
questions here:

   "In the above diagram a watcher (some UA) subscribes for the
presence    
   data of PUA with the presence server. The Presence server
immediately   
   replies back with the current presence data of the PUA in the
NOTIFY    
   message.

   At a later time, when the PUA updates its presence data by some
means   
   (could use SIP REGISTER message), the presence server again
notifies    
   the watcher, with the new presence data."

First the watcher, is it a remote device based on the SIP side of the
mobile network talking inbound to the MS? Or is it an MS talking
outbound to the SIP network via the Proxy UA? (I think that section 4
answers my question about the direction as it describes the presence
server..but just in cas I leave this question here).

Also, I didnt see any messages to the PUA from the presence server, only
a notify message.

In section 3, I dont see why the SIP registrar would need to do anything
but let the Proxy UA expire the original registration (if it even needs
to maintain this information at all), could you explain that part of
scenario for me, or point me to more documentation on the mobile aspect
of this?
 
I think I will stop my questions here...

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



From mailnull@www1.ietf.org  Fri Oct  4 22:49:51 2002
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 WAA28946
	for <sip-archive@odin.ietf.org>; Fri, 4 Oct 2002 22:49:51 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g952pUH16734
	for sip-archive@odin.ietf.org; Fri, 4 Oct 2002 22:51:30 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g952pDv16722;
	Fri, 4 Oct 2002 22:51:13 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g952oOv16701
	for <sip@optimus.ietf.org>; Fri, 4 Oct 2002 22:50:24 -0400
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 WAA28932
	for <sip@ietf.org>; Fri, 4 Oct 2002 22:48:15 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.85])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g952oFYH005039;
	Fri, 4 Oct 2002 22:50:15 -0400 (EDT)
Message-ID: <3D9E5366.2060903@dynamicsoft.com>
Date: Fri, 04 Oct 2002 22:50:14 -0400
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: Stephen James <sjames@voiceramp.com>
CC: sip@ietf.org
Subject: Re: [Sip] Comments on draft-idnani-sip-comb-reg-subscr-00.txt
References: <DDC3D921FB67D211AAD100A0C9E58F53107E8608@hampstead.vfl.vodafone> <001601c26ba3$adfaa0c0$6779a8c0@StephenJames>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit



Stephen James wrote:
> What is the general opinion or policy on using the Content of the REGISTER
> for this? Supposedly, the Regstrar in this case is expected to have extended
> functionality to support combined REGISTER/SUBSCRIBE, could the a new
> content type be developed for Subscriptions that could be contained in the
> REGISTER message. By placing such elements as Subscription Call-ID and
> request URL into this new content type, some of the problems described below
> could be circumvented.

This is effectively tunneling SIP in SIP. I don't see the benefit of 
that. It has none of the "overhead" reduction benefits that the draft is 
aiming for, but breaks interoperability by effectively defining a new 
protocol.

To address the original proposal, I do not think it is a good idea to 
combine REGISTER and SUBSCRIBE. Adam makes many good points on the 
problems associated with this idea. Some additional ones to consider:

* The accept header indicates body types that the UA can accept. In 
SUBSCRIBE, it refers to allowed body types in NOTIFY, in REGISTER, to 
allowed body types in the response. When present in a "combined" 
SUBSCRIBE/REGISTER, there would be no way to know which one it refers 
to. It is very possible that certain types would be supported for one 
case and not the other.

* Same as above for accept-encoding.

* the client has no way to know whether the resource that the UA wants 
to subscribe to is available from the registrar. This will lead to 
frequent "guess-and-check" attempts that are wasteful.

* a user might be authorized to register, but not authorized to 
subscribe to a resource. There is no way to differentiate which is the 
case based on the response code (this is one example of the failure 
problem that Adam points out).

There are other problems; these are just a few I came up with.

I'll also note this tidbit in the draft:
> Notice Regarding Intellectual Property Rights
> 
>    The IETF has been notified of intellectual property rights claimed 
>    in regard to some or all of the specification contained in this 
>    document.  For more information consult the online list of claimed 
>    rights


I am reluctant to pursue patented technologies generally; I am less 
interested in doing so to define optimizations that introduce many new 
problems.

-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

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



From mailnull@www1.ietf.org  Fri Oct  4 23:07:29 2002
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 XAA29075
	for <sip-archive@odin.ietf.org>; Fri, 4 Oct 2002 23:07:29 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g95398Z17601
	for sip-archive@odin.ietf.org; Fri, 4 Oct 2002 23:09:08 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9538Kv17589;
	Fri, 4 Oct 2002 23:08:20 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g95379v17305
	for <sip@optimus.ietf.org>; Fri, 4 Oct 2002 23:07:09 -0400
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 XAA29069
	for <sip@ietf.org>; Fri, 4 Oct 2002 23:04:59 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.85])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g9536wYH005049;
	Fri, 4 Oct 2002 23:06:58 -0400 (EDT)
Message-ID: <3D9E5751.8010300@dynamicsoft.com>
Date: Fri, 04 Oct 2002 23:06:57 -0400
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: Rohan Mahy <rohan@cisco.com>
CC: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>, sip@ietf.org,
        Keith Drage <drage@lucent.com>
Subject: Re: [Sip] Re: Question about caller preferences
References: <B395901C-D49C-11D6-8705-0003938AF740@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

inline.

Rohan Mahy wrote:
> Jonathan,
> 
> So are you saying that:
> 
>     Reject-Contact: *;class="personal"
> 
> should assume a mobility attribute of "any"  (Reject any personal 
> contact whether mobile or not), and:
> 
>     Accept-Contact: *;class="business"
> 
> should also assume a mobility attribute of any (accept any business 
> contact regardless of other attributes)?
> (if so, i think this is goodness).

Yes, that is how the matching will work. The above Reject-Contact would 
reject a contact like this:

sip:user@domain;class="personal";mobility="mobile"

Its important to note that Reject-Contact is particularly troublesome as 
currently defined. Thats because the above reject-contact would also 
match this contact:

sip:user@domain;mobility="fixed"

thats because lack of information on an attribute implies that any value 
is supported, including, in this case, a value of "personal" for the 
class attribute.

For this reason, I plan to introduce a different semantic - "reject this 
contact if it DOESNT match this rule". So, to avoid personal UAs:

Require-Contact: *;class="!personal"

so, a contact like this:

sip:user@domain;mobility="fixed"

does match the rule (since class isn't specified, it is assumed to have 
both values - personal and business, and therefore the value of business 
matches the rule of !personal), and therefore stays. But, a contact like 
this:

sip:user@domain;class="personal"

does not match the rule, and therefore, the contact is rejected.



> 
> What would the status be of unincluded attributes in a REGISTER?  Is the 
> semantic "unknown", "none", or "any"?
> 
>     Contact: <sip:rmahy@dhcp2357.cisco.com>;class=business
>     Contact: <sip:rohan@iptel.org>;class=personal

The semantics are unchanged. In all cases, the parameters specify a 
predicate that defines a feature set. If an attribute is not explicitly 
specified, the feature set includes all possible values of that attribute.

-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

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



From mailnull@www1.ietf.org  Sat Oct  5 16:01:15 2002
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 QAA22889
	for <sip-archive@odin.ietf.org>; Sat, 5 Oct 2002 16:01:15 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g95K2qO32007
	for sip-archive@odin.ietf.org; Sat, 5 Oct 2002 16:02:52 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g95K2Av31985;
	Sat, 5 Oct 2002 16:02:11 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g95JwVv31898
	for <sip@optimus.ietf.org>; Sat, 5 Oct 2002 15:58:31 -0400
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 PAA22700
	for <sip@ietf.org>; Sat, 5 Oct 2002 15:56:22 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.76])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g95JwPYH005221
	for <sip@ietf.org>; Sat, 5 Oct 2002 15:58:26 -0400 (EDT)
Message-ID: <3D9F4461.9040800@dynamicsoft.com>
Date: Sat, 05 Oct 2002 15:58:25 -0400
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: sip@ietf.org
Subject: [Fwd: [Sip] I-D ACTION:draft-ietf-sip-symmetric-response-00.txt]
Content-Type: multipart/mixed;
 boundary="------------090407080704010407070902"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.
--------------090407080704010407070902
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Folks,

This draft is an update to draft-ietf-sip-nat-02. The name has been 
changed to reflect the fact that it is not NAT traversal for sip. Some 
of the other changes in this version:

* addition of an UNSAF considerations section, addressing the issues 
pointed out in 
http://www.ietf.org/internet-drafts/draft-iab-unsaf-considerations-02.txt.

* clarification that responses need to be sent from the address/port on 
which the request was received

* addition of branch IDs to the example via headers

* updated references

It also incorporates the various comments received during working group 
last call. I believe this document is now ready to go to iesg.

Thanks,
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

--------------090407080704010407070902
Content-Type: message/rfc822;
 name="[Sip] I-D ACTION:draft-ietf-sip-symmetric-response-00.txt"
Content-Disposition: inline;
 filename="[Sip] I-D ACTION:draft-ietf-sip-symmetric-response-00.txt"

Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-001.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id S3Q8MYHJ; Tue, 1 Oct 2002 07:54:53 -0400
Received: from www1.ietf.org (ietf.org [132.151.1.19])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g91Bs1sr007907;
	Tue, 1 Oct 2002 07:54:01 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91Bg9v22622;
	Tue, 1 Oct 2002 07:42:09 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91BcNv21466
	for <sip@optimus.ietf.org>; Tue, 1 Oct 2002 07:38:23 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09358;
	Tue, 1 Oct 2002 07:36:22 -0400 (EDT)
Message-Id: <200210011136.HAA09358@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Tue, 01 Oct 2002 07:36:22 -0400
Subject: [Sip] I-D ACTION:draft-ietf-sip-symmetric-response-00.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-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 Protocol Working Group of the IETF.

	Title		: An Extension to the Session Initiation Protocol (SIP) 
                          for Symmetric Response Routing
	Author(s)	: J. Rosenberg, J. Weinberger, H. Schulzrinne
	Filename	: draft-ietf-sip-symmetric-response-00.txt
	Pages		: 12
	Date		: 2002-9-30
	
The Session Initiation Protocol (SIP) operates over UDP and TCP. When
used with UDP, responses to requests are returned to the source
address the request came from, and to the port written into the
topmost Via header field value of the request. This behavior is not
desirable in many cases, most notably, when the client is behind a
Network Address Translator (NAT). This extension defines a new
parameter for the Via header field, called 'rport', that allows a
client to request that the server send the response back to the
source IP address and port where the request came from.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-symmetric-response-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-sip-symmetric-response-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-sip-symmetric-response-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:	<2002-9-30144719.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-symmetric-response-00.txt

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


--OtherAccess--

--NextPart--


--------------090407080704010407070902--

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



From mailnull@www1.ietf.org  Sun Oct  6 21:56:01 2002
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 VAA26315
	for <sip-archive@odin.ietf.org>; Sun, 6 Oct 2002 21:56:01 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g971vgR11201
	for sip-archive@odin.ietf.org; Sun, 6 Oct 2002 21:57:42 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g971uQv11156;
	Sun, 6 Oct 2002 21:56:26 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g971pPv11038
	for <sip@optimus.ietf.org>; Sun, 6 Oct 2002 21:51:25 -0400
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 VAA26261
	for <sip@ietf.org>; Sun, 6 Oct 2002 21:49:14 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.76])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g971pAYH005627;
	Sun, 6 Oct 2002 21:51:11 -0400 (EDT)
Message-ID: <3DA0E88D.8040606@dynamicsoft.com>
Date: Sun, 06 Oct 2002 21:51:09 -0400
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: pnath@hss.hns.com
CC: sip@ietf.org
References: <65256C38.0033E7C3.00@sampark.hss.hns.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Re: draft-ietf-sip-update-02.txt- Sending 500 response
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Pankaj,

You are correct that this is an error in the specification, and also 
correct in the needed fix. I will make this change during authors 48 
hours (now in progress).

Thanks,
Jonathan R.

pnath@hss.hns.com wrote:
> 
> Hello
>        I have doubt regarding the following  statement of the
> draft-ietf-sip-update-02.txt
> 
> "A UAS that receives an UPDATE before it has generated a final
> response to a previous UPDATE or INVITE on the same dialog
>  MUST return a 500 response to the new UPDATE, and MUST
> include a Retry-After field with a Retry-After header field with a
> randomly chosen  value between 0 and 10 seconds."
> 
>>From my understanding, the UPDATE method allows the caller or
> callee to provide updated session information before a final response
> to the initial INVITE request is generated. So, why need to send the 500
>  response to UPDATE request where the UAS has not generated a final
> response to a previous  INVITE  on the same dialog.
> 
> I think the statement should be
> "A UAS that receives an UPDATE before it has generated a final
> response to a previous UPDATE or re-INVITE on the same dialog
>  MUST return a 500 response to the new UPDATE, and MUST
> include a Retry-After field with a Retry-After header field with a
> randomly chosen  value between 0 and 10 seconds."
> 
> Please correct me if I am wrong.
> 
> 
> Regds
> Pankaj Nath
> 
> 
> 
> 
> 
> 
> 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.
> 
> 

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

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



From mailnull@www1.ietf.org  Mon Oct  7 08:55:57 2002
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 IAA16782
	for <sip-archive@odin.ietf.org>; Mon, 7 Oct 2002 08:55:57 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g97CvWj17175
	for sip-archive@odin.ietf.org; Mon, 7 Oct 2002 08:57:32 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g97Csbv17090;
	Mon, 7 Oct 2002 08:54:38 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g97CqXv17038
	for <sip@optimus.ietf.org>; Mon, 7 Oct 2002 08:52:33 -0400
Received: from em.njupt.edu.cn (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA16688
	for <sip@ietf.org>; Mon, 7 Oct 2002 08:50:14 -0400 (EDT)
Message-Id: <200210071250.IAA16688@ietf.org>
Received: (qmail 19162 invoked from network); 7 Oct 2002 13:14:01 -0000
Received: from unknown (HELO toto) (10.10.3.123)
  by em.njupt.edu.cn with SMTP; 7 Oct 2002 13:14:01 -0000
Date: Mon, 7 Oct 2002 20:55:4 +0800
From: feng zhang <y01317@njupt.edu.cn>
Reply-To: y01317@njupt.edu.cn
To: "sip@ietf.org" <sip@ietf.org>
Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-symmetric-response-00.txt
Organization: NUPT-CED202
X-mailer: FoxMail 4.0 beta 2 [cn]
Mime-Version: 1.0
Content-Type: text/plain;
      charset="GB2312"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id g97CqXv17039
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit

Hi All,

   Can anybody tell me what's the difference between this draft and 
draft-ietf-sip-nat-02.txt(July 1, 2002)? I think they are the SAME!

Best Regards.
>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>This draft is a work item of the Session Initiation Protocol Working Group of the IETF.
>
>	Title		: An Extension to the Session Initiation Protocol (SIP) 
>                          for Symmetric Response Routing
>	Author(s)	: J. Rosenberg, J. Weinberger, H. Schulzrinne
>	Filename	: draft-ietf-sip-symmetric-response-00.txt
>	Pages		: 12
>	Date		: 2002-9-30
>	
>The Session Initiation Protocol (SIP) operates over UDP and TCP. When
>used with UDP, responses to requests are returned to the source
>address the request came from, and to the port written into the
>topmost Via header field value of the request. This behavior is not
>desirable in many cases, most notably, when the client is behind a
>Network Address Translator (NAT). This extension defines a new
>parameter for the Via header field, called 'rport', that allows a
>client to request that the server send the response back to the
>source IP address and port where the request came from.

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



From mailnull@www1.ietf.org  Mon Oct  7 09:57:40 2002
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 JAA18996
	for <sip-archive@odin.ietf.org>; Mon, 7 Oct 2002 09:57:40 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g97DxGw20030
	for sip-archive@odin.ietf.org; Mon, 7 Oct 2002 09:59:16 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g97DwXv20003;
	Mon, 7 Oct 2002 09:58:33 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94Kuhv32757
	for <sip@optimus.ietf.org>; Fri, 4 Oct 2002 16:56:43 -0400
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 QAA21528
	for <sip@ietf.org>; Fri, 4 Oct 2002 16:54:35 -0400 (EDT)
Received: from jku07.fokus.fraunhofer.de (port-212-202-171-171.reverse.qdsl-home.de [212.202.171.171])
	by fox.iptel.org (8.11.6/8.11.6) with ESMTP id g94Ktwn06792;
	Fri, 4 Oct 2002 22:55:58 +0200
Message-Id: <5.1.0.14.0.20021004221532.03e50f20@mailhost.fokus.gmd.de>
X-Sender: jku@mailhost.fokus.gmd.de
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 04 Oct 2002 22:54:19 +0200
To: Igor Slepchin <ISlepchin@dynamicsoft.com>,
        "'Jiri Kuthan'" <jiri.kuthan@fokus.gmd.de>,
        Igor Slepchin <ISlepchin@dynamicsoft.com>,
        "'Jiri Kuthan'" <jiri@iptel.org>, Medhavi Bhatia <mbhatia@nextone.com>,
        James Undery <jundery@ubiquity.net>, "SIP (E-mail)" <sip@ietf.org>
From: Jiri Kuthan <jiri.kuthan@fokus.fraunhofer.de>
Subject: RE: [Sip] Retransmission of INVITEs
In-Reply-To: <1407568FD28578458C2F1FFFF30B82BB549509@DYN-EXCH-001.dynami
 csoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

At 06:12 PM 10/4/2002, Igor Slepchin wrote:
>The previous hop will realize there was a failure after timing out without
>receiving a final response and can retry sending the request to a backup in
>that case. 

Forking might work but dimensioning the "on_no_final_reply" timer is
a social issue which I would better avoid. It is simply not easy to 
distinguish between a failure and downstream server (or callee) which 
has not decided to send a final reply yet for INVITE. 

>This is fairly similar to non-INVITE failure case 

Not really as typically humans are not involved in non-INVITES
and loooong no_final_reply period of time is valid for INVITEs,
for example if the humans are government buerocrats or myself
seeking my cell in all my coat's pockets.

>where the
>previous hop will failover after transaction timeout though timeout in
>INVITE case may admittedly be longer. The main difference is that in INVITE
>case the previous hop may not know that the problem occurred in the next
>hop, but if there is lots of traffic going on between these servers, the
>previous hop most likely will have detected the failure by then anyway. 

A phone will have no heavy traffic.

>In any case, if the application is really concerned about this kind of
>failures, I think it can retransmit INVITEs even after a 100: 

I agree as for implementations -- that breaks nothing and you can 
label your implementation as "added-value reliability UAC" ;-)

As for the specification, the INVITE UAC state machine simply
ignores this case. That's why it was raised on [sip] and not
[sip-implementers] and deserves IMHO an improvement.

-Jiri

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



From mailnull@www1.ietf.org  Mon Oct  7 16:17:08 2002
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 QAA04022
	for <sip-archive@odin.ietf.org>; Mon, 7 Oct 2002 16:17:07 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g97KIlD07743
	for sip-archive@odin.ietf.org; Mon, 7 Oct 2002 16:18:47 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g97KIMv07731;
	Mon, 7 Oct 2002 16:18:22 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g97KFov07618
	for <sip@optimus.ietf.org>; Mon, 7 Oct 2002 16:15:50 -0400
Received: from bdsl.66.12.12.130.gte.net (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03940
	for <sip@ietf.org>; Mon, 7 Oct 2002 16:13:40 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g97KFiT25124;
	Mon, 7 Oct 2002 15:15:44 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: <duncan.mills@vf.vodafone.co.uk>, <adam@dynamicsoft.com>, <sip@ietf.org>,
        <Ajaykumar.Idnani@motorola.com>, <Steve.Upp@motorola.com>,
        <thallin@motorola.com>
Subject: RE: [Sip] Comments on draft-idnani-sip-comb-reg-subscr-00.txt
Date: Mon, 7 Oct 2002 15:15:24 -0500
Message-ID: <006701c26e3e$45f7a340$d1036e3f@TXDWILLIS2>
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
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <DDC3D921FB67D211AAD100A0C9E58F53107E8608@hampstead.vfl.vodafone>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit


Duncan wrote:
> However, I would support a more general version of this 
> draft.  For instance, the real gain I can see (as Adam says, 
> this is only an optimisation, which SIPPING won't allow) is 
> that one REGISTER request does the same thing as a REGISTER + 
> X * SUBSCRIBE requests.  But- In the above draft, the SIP 
> nodes are all in the core network anyway, so this saving is 
> surely less valuable?
> 
> Now, in the 3GPP situation where we send SIP messages across 
> the radio interface, there is a strong requirement to save 
> radio bandwidth. Additionally, we also use the 
> SUBSCRIBE/NOTIFY procedures for events other than presence, 
> so any kind of implicit subscription is attractive...

Perhaps I'm confused about something, but as I recall, the things in IMS
being subscibed to via SUBSCRIBE are not served from the registrar that
services the REGISTER request. In other words, the SUBSCRIBEs don't go
to the same destinations as do the REGISTERs, so combining them doesn't
seem to make a lot of sense in any case. We should have called REGISTER
something like "SETCONTACT" -- it would have avoided a lot of this
discussion.

It would seem far more effective to use a server process that aggregates
notifications and subscriptions, as is done in the "presencelist" work.
In this model one subscribes to a list served by a server, then that
server subscribes to each element of the list, aggregates state, and
filters and returns appropriate notifications to the subscriber thereby
reducing over-the-air traffic tremendously. This effectively replaces
many SUBSCRIBEs with one SUBSCRIBs, and may replace many NOTIFYs with
fewer NOTIFYs, depending on how thoseare handled.
 
> But isn't the problem with implicit subscription the fact 
> that there is no call-id for the NOTIFY request to use?  Is 
> there no way around this?

That's one problem. There are also issues with knowing how to filter
notifications and how to negotiate whether implicit subscription is
supported and lots of other things. We had not finished enumerating the
issues before deciding implicit subscriptions were just dangerous.

--
Dean

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



From mailnull@www1.ietf.org  Mon Oct  7 17:45:11 2002
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 RAA07471
	for <sip-archive@odin.ietf.org>; Mon, 7 Oct 2002 17:45:11 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g97Lkql12454
	for sip-archive@odin.ietf.org; Mon, 7 Oct 2002 17:46:52 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g97Ljxv12423;
	Mon, 7 Oct 2002 17:45:59 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g97LiBv12336
	for <sip@optimus.ietf.org>; Mon, 7 Oct 2002 17:44:11 -0400
Received: from bdsl.66.12.12.130.gte.net (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07335
	for <sip@ietf.org>; Mon, 7 Oct 2002 17:41:59 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g97LiFT25476;
	Mon, 7 Oct 2002 16:44:15 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: <y01317@njupt.edu.cn>, <sip@ietf.org>
Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-symmetric-response-00.txt
Date: Mon, 7 Oct 2002 16:43:55 -0500
Message-ID: <009b01c26e4a$a28dc330$d1036e3f@TXDWILLIS2>
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
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <200210071250.IAA16688@ietf.org>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit


Feng Zhang asked:
>    Can anybody tell me what's the difference between this draft and 
> draft-ietf-sip-nat-02.txt(July 1, 2002)? I think they are the SAME!


It's a slight update -- Jonathan has separate mail to the list
discussing changes.

The name change was requested by the AD. This isn't a general NAT
protocol draft, therefore the NAT in the name was considered
problematic. 


I quote from Jonathan's note:

--------------------------
This draft is an update to draft-ietf-sip-nat-02. The name has been 
changed to reflect the fact that it is not NAT traversal for sip. Some 
of the other changes in this version:

* addition of an UNSAF considerations section, addressing the issues 
pointed out in 
http://www.ietf.org/internet-drafts/draft-iab-unsaf-considerations-02.tx
t.

* clarification that responses need to be sent from the address/port on 
which the request was received

* addition of branch IDs to the example via headers

* updated references

It also incorporates the various comments received during working group 
last call. I believe this document is now ready to go to iesg.
---------------------------

--
Dean

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



From mailnull@www1.ietf.org  Mon Oct  7 21:41:12 2002
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 VAA13286
	for <sip-archive@odin.ietf.org>; Mon, 7 Oct 2002 21:41:12 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g981grA23539
	for sip-archive@odin.ietf.org; Mon, 7 Oct 2002 21:42:53 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g981fxv23477;
	Mon, 7 Oct 2002 21:41:59 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g981blv23314
	for <sip@optimus.ietf.org>; Mon, 7 Oct 2002 21:37:47 -0400
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 VAA13115
	for <sip@ietf.org>; Mon, 7 Oct 2002 21:35:34 -0400 (EDT)
Received: from jku07.iptel.org (external.lecstar.net [65.243.117.2])
	by fox.iptel.org (8.11.6/8.11.6) with ESMTP id g981bVn22475
	for <sip@ietf.org>; Tue, 8 Oct 2002 03:37:31 +0200
Message-Id: <5.1.0.14.0.20021008033520.00b3e910@iptel.org>
X-Sender: jiri@iptel.org
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 08 Oct 2002 03:37:32 +0200
To: sip@ietf.org
From: Jiri Kuthan <jiri@iptel.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [Sip] New SIP Server Available
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

I'm glad to announce availability of a free, open-source SIP
server to the SIP community.

http://www.iptel.org/ser/

-Jiri

--
Jiri Kuthan            http://iptel.org/~jiri/

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



From mailnull@www1.ietf.org  Tue Oct  8 16:17:32 2002
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 QAA29326
	for <sip-archive@odin.ietf.org>; Tue, 8 Oct 2002 16:17:32 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g98KJBe28287
	for sip-archive@odin.ietf.org; Tue, 8 Oct 2002 16:19:11 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98KHOv28203;
	Tue, 8 Oct 2002 16:17:24 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98K89v27966
	for <sip@optimus.ietf.org>; Tue, 8 Oct 2002 16:08:09 -0400
Received: from kevlar.softarmor.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28993;
	Tue, 8 Oct 2002 16:05:59 -0400 (EDT)
Received: from TXDWILLIS2 (localhost.localdomain [127.0.0.1])
	by kevlar.softarmor.com (8.11.6/8.11.6) with ESMTP id g98KPZT14348;
	Tue, 8 Oct 2002 15:25:43 -0500
From: "Dean Willis" <dwillis@dynamicsoft.com>
To: <sip@ietf.org>, <sipping@ietf.org>, <simple@ietf.org>
Date: Tue, 8 Oct 2002 15:07:30 -0500
Message-ID: <000301c26f06$5d88f9a0$958cfea9@TXDWILLIS2>
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
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Content-Transfer-Encoding: 7bit
Subject: [Sip] Supplementatry web site down for maintenance this afternoon
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

The www.softarmor.com/.... Web site is down this afternoon -- I'm having
to replace a disk drive, and decided I might as well upgrade the OS
concurrently.

If you NEED stuff off of there, please look at
http://kevlar.softarmor.com/.... instead.

--
Dean

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



From mailnull@www1.ietf.org  Wed Oct  9 01:54:27 2002
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 BAA11056
	for <sip-archive@odin.ietf.org>; Wed, 9 Oct 2002 01:54:27 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g995uBt22435
	for sip-archive@odin.ietf.org; Wed, 9 Oct 2002 01:56:11 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g995nbv22334;
	Wed, 9 Oct 2002 01:49:37 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g995lov22283
	for <sip@optimus.ietf.org>; Wed, 9 Oct 2002 01:47:50 -0400
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 BAA10966
	for <sip@ietf.org>; Wed, 9 Oct 2002 01:45:34 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.81])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g995lBYH007470;
	Wed, 9 Oct 2002 01:47:11 -0400 (EDT)
Message-ID: <3DA3C2DE.60404@dynamicsoft.com>
Date: Wed, 09 Oct 2002 01:47:10 -0400
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: Jiri Kuthan <jiri.kuthan@fokus.fraunhofer.de>
CC: Igor Slepchin <ISlepchin@dynamicsoft.com>,
        "'Jiri Kuthan'" <jiri.kuthan@fokus.gmd.de>,
        "'Jiri Kuthan'" <jiri@iptel.org>, Medhavi Bhatia <mbhatia@nextone.com>,
        James Undery <jundery@ubiquity.net>, "SIP (E-mail)" <sip@ietf.org>
Subject: Re: [Sip] Retransmission of INVITEs
References: <5.1.0.14.0.20021004221532.03e50f20@mailhost.fokus.gmd.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit



Jiri Kuthan wrote:

>>In any case, if the application is really concerned about this kind of
>>failures, I think it can retransmit INVITEs even after a 100: 
> 
> 
> I agree as for implementations -- that breaks nothing and you can 
> label your implementation as "added-value reliability UAC" ;-)
> 
> As for the specification, the INVITE UAC state machine simply
> ignores this case. That's why it was raised on [sip] and not
> [sip-implementers] and deserves IMHO an improvement.

Well, it doesnt ignore it - it merely lumps it into another case (called 
party never answers) which requires the UAC at some point to give up and 
cancel. So, there is a call failure here when possibly there need not 
be. Thats not a bug in the spec, its a potential new feature if you want 
to add support for it.

Anyway, nitpicks like that aside, there are some side effects to the 
proposed solution. Presumably, on retransmitting the INVITE and getting 
a failure, the client would try a backup server. Now, the problem is 
that the client cannot distinguish the case where the proxy failed 
before proxying the request, or after (but in both cases, before a final 
response or non-100 1xx). If it fails after proxying, trying a backup 
effectively results in a forked request. This can have unintended 
consequences. In a PSTN termination case, two PSTN gateways might get 
copies of the forked INVITE and then both make calls into the PSTN. If 
these happen to be for an 800 number or multiline call, you end up with 
potentially two calls created. Granted, one of them should be cancelled, 
but this is still undesirable behavior.

My other concern is that the solution is UDP specific, and doesn't work 
for TCP. If we want to support this failure case for TCP, and we further 
assume failures without graceful closing of the connection, the client 
won't detect the failure as Henning pointed out. We could retransmit the 
INVITE on the TCP connection (yuck!), which is effectively like 
implementing application layer keepalives over TCP. I wonder what is the 
issue with TCP keepalives that make them infrequently used?

Also, the retransmits over UDP exacerbate the bandwidth consumption of 
SIP for the common case where there is no failure. I guess this is not 
too bad if you stop retransmitting after non-100 1xx...

-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

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



From mailnull@www1.ietf.org  Wed Oct  9 04:49:52 2002
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 EAA07478
	for <sip-archive@odin.ietf.org>; Wed, 9 Oct 2002 04:49:51 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g998pb207430
	for sip-archive@odin.ietf.org; Wed, 9 Oct 2002 04:51:37 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g998pAv07410;
	Wed, 9 Oct 2002 04:51:11 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g998n3v07325
	for <sip@optimus.ietf.org>; Wed, 9 Oct 2002 04:49:03 -0400
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 EAA07379
	for <sip@ietf.org>; Wed, 9 Oct 2002 04:46:47 -0400 (EDT)
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 g998mcw23214
	for <sip@ietf.org>; Wed, 9 Oct 2002 11:48:38 +0300 (EET DST)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5dd560c6d5ac158f25830@esvir05nok.ntc.nokia.com> for <sip@ietf.org>;
 Wed, 9 Oct 2002 11:44:07 +0300
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 9 Oct 2002 11:44:06 +0300
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: Wed, 9 Oct 2002 11:44:06 +0300
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C206D6@esebe019.ntc.nokia.com>
Thread-Topic: Bug in absolute-URI grammar
Thread-Index: AcJHe7Mv7ka3OCNNSLibnvYigBRsWAn85J9A
To: <sip@ietf.org>
X-OriginalArrivalTime: 09 Oct 2002 08:44:06.0851 (UTC) FILETIME=[0740E930:01C26F70]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g998n4v07326
Subject: [Sip] Bug in absolute-URI grammar
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit

I sent this a while ago and am resending. I also have a further comment/question:

net-path       =  "//" authority [ abs-path ]
authority      =  srvr / reg-name
srvr           =  [ [ userinfo "@" ] hostport ]
reg-name       =  1*( unreserved / escaped / "$" / ","
                  / ";" / ":" / "@" / "&" / "=" / "+" )

How can a parser distinguish between srvr and reg-name? the @ sign is allowed in both?

Regards,
Hisham

> -----Original Message-----
> From: ext hisham.khartabil@nokia.com 
> [mailto:hisham.khartabil@nokia.com]
> Sent: Monday, August 19, 2002 3:27 PM
> To: sip@ietf.org
> Subject: [Sip] Bug in absolute-URI grammar
> 
> 
> srvr           =  [ [ userinfo "@" ] hostport ]
> 
> should be
> 
> srvr           =  [ [ userinfo ] hostport ]
> 
> Regards,
> Hisham
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Wed Oct  9 07:31:40 2002
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 HAA10481
	for <sip-archive@odin.ietf.org>; Wed, 9 Oct 2002 07:31:40 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g99BXHQ14971
	for sip-archive@odin.ietf.org; Wed, 9 Oct 2002 07:33:17 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99BW4v14930;
	Wed, 9 Oct 2002 07:32:04 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99BUpv14873
	for <sip@optimus.ietf.org>; Wed, 9 Oct 2002 07:30:51 -0400
Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10334
	for <sip@ietf.org>; Wed, 9 Oct 2002 07:28:44 -0400 (EDT)
Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP for sip@ietf.org; Wed, 9 Oct 2002 13:22:19 +0200
Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <4QRGWD40>; Wed, 9 Oct 2002 13:22:19 +0200
Message-Id: <C835D57E3730D6119F5000A0C9F019A90201DD11@U8P13.blf01.telekom.de>
From: "Jesske, R" <R.Jesske@telekom.de>
To: sip@ietf.org
Cc: "Poetzl, Joachim" <Joachim.Poetzl@telekom.de>,
        "Alexeitsev, D" <D.Alexeitsev@telekom.de>,
        "Tolksdorf, Christian" <Christian.Tolksdorf@telekom.de>,
        Robert.Benz@telekom.de, "Pinker, Gerold" <Gerold.Pinker@telekom.de>
Date: Wed, 9 Oct 2002 13:22:14 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sip] RFC 2976 INFO Method
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

Dear all,
With publishing RFC 3261 SIP the "old" RFC 2543 is now obsolete. My question is now what is the status of RFC 2976 INFO Method, is it also obsolete? Because this RFC is referring to RFC 2543. 

Best Regards

Roland


Deutsche Telekom AG
T Com Zentrale
Section T38; Signalling, Gateways and Switching Systems 
Roland Jesske, T38a12
Am Kavalleriesand 3, 64295 Darmstadt, Germany
Phone:  +49 6151 83-5940 
Fax:    +49 6151 83-4577 
mailto: r.jesske@telekom.de 



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



From mailnull@www1.ietf.org  Wed Oct  9 08:00:55 2002
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 IAA11767
	for <sip-archive@odin.ietf.org>; Wed, 9 Oct 2002 08:00:55 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g99C2W116480
	for sip-archive@odin.ietf.org; Wed, 9 Oct 2002 08:02:32 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99C1Xv16434;
	Wed, 9 Oct 2002 08:01:33 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99C0Jv16360
	for <sip@optimus.ietf.org>; Wed, 9 Oct 2002 08:00:19 -0400
Received: from beamer.mchh.siemens.de (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11607
	for <sip@ietf.org>; Wed, 9 Oct 2002 07:58:10 -0400 (EDT)
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226])
	by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id OAA24178;
	Wed, 9 Oct 2002 14:00:08 +0200 (MET DST)
Received: from mchh9ega.mchh.siemens.de (mchh9ega.mchh.siemens.de [139.21.194.56])
	by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id OAA28658;
	Wed, 9 Oct 2002 14:00:07 +0200 (MET DST)
Received: by mchh9ega.mchh.siemens.de with Internet Mail Service (5.5.2653.19)
	id <4PYM63TS>; Wed, 9 Oct 2002 14:00:06 +0200
Message-ID: <B3028CA9D0B8D511874E0002A53F24D566D218@mchh9mla.mchh.siemens.de>
From: Beckmann Mark ICM MP P PS 4 SAL 2 <mark.beckmann@siemens.com>
To: sip@ietf.org
Cc: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>,
        "Miguel A. Garcia"
	 <Miguel.A.Garcia@ericsson.com>,
        Keith Drage <drage@lucent.com>,
        Mayer Georg ICM N PG SP ST N 1 <georg.mayer@icn.siemens.de>
Subject: RE: [Sip] Re: Question about caller preferences
Date: Wed, 9 Oct 2002 14:00:02 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

Hi,

I have another question about the caller preferences, especially regarding
the method tag of the contact parameter.

Perhaps, this was discussed before on the list. In the draft, however, I
couldn't find any hint whether it is possible to indicate the "direction",
in which a UA supports a specific method.

For example a UA that indicates support for the methods SUBSCRIBE and NOTIFY
would add a contact parameter as follows:

Contact: <sip:ua.example.com>;methods="SUBSCRIBE,NOTIFY"

Now, does this mean the UA has to accept and be able to send both methods? I
would guess that for some UAs it would make sense to support the ability to
subscribe to an event and receive NOTIFYs, but not to accept SUBSCRIBEs and
send NOTIFYs itself.

Regards,

Mark

Mark Beckmann			Siemens AG

ICM MP P PS 4S2
P.O.Box 100702			phone: +49 (5341) 906 1814
D-38228 Salzgitter   		fax:   +49 (5341) 906 2010

mailto: Mark.Beckmann@siemens.com



> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Thursday, September 26, 2002 7:21 PM
> To: Miguel A. Garcia
> Cc: sip@ietf.org; Keith Drage
> Subject: [Sip] Re: Question about caller preferences
> 
> 
> inline.
> 
> Miguel A. Garcia wrote:
>  > Hi:
>  >
>  > I had a discussion with some folks about the caller preferences
>  > draft, and we have some questions that we weren't able to answer by
>  > reading the document.
>  >
>  > We understand that by not publishing the support for a feature set,
>  > the UA is not providing any information. Therefore, the feature set
>  > may or may not be supported at the UA.
> 
> Actually, RFC 2533 (which we are using) does say something concrete 
> about what it means to say nothing about a feature tag. It means that 
> you are supporting all values. This means you need to be 
> careful about 
> the semantics of the headers - the existing Reject-Contact 
> semantic of 
> "reject this contact if its feature set matches" is bad, 
> because it will 
> cause a UA to be rejected even if it has said nothing about a 
> particular 
> feature tag!
> 
>  >
>  > But the question is, if the UA decides to provide 
> information about a
>  > supported feature set, shall that information be complete?
> 
> Yes.
> 
>  >
>  > We are thinking of the methods parameter in the Contact header for
>  > registration. In case the methods parameter is included, 
> shall it be
>  > complete and list all the methods supported by the UA?
> 
> Yes.
> 
> There was a thread on the list (likely followed by no one) between 
> myself, Juha, and Paul K. on this exact issue. Our conclusion 
> was that 
> it was reasonable to mandate that a UA include all values it supports 
> for a feature tag, when it includes that feature tag.
> 
>  >
>  > Example:
>  >
>  > Contact:
>  > 
> <sip:ua.example.com>;methods="INVITE,ACK,BYE,CANCEL,OPTIONS,REGISTER,-
>  > UPDATE,SUBSCRIBE,NOTIFY,PRACK,MESSAGE"
>  >
>  > Some folks think that the complete list is not essential. In my
>  > opinion, if a feature is present, it should be complete. In this
>  > case, all the methods supported by the UA must be present.
> 
> That is correct.
> 
>  >
>  > Other folks didn't see the need to publish the support for methods
>  > like ACK (implicitly supported if INVITE is supported), or NOTIFY
>  > (implicitly supported if SUBSCRIBE is supported).
>  >
>  > In my opinion, that assumption is always wrong, because the methods
>  > parameter indicates support for SIP methods, not for SIP
>  > capabilities.
> 
> I would agree. Without listing all methods, you put the burden on the 
> server to lean what other methods a UA will support based on 
> the ones it 
> listed. That won't always be a trivial exercise.
> 
>  >
>  > I would like to hear the opinion of the WG to give us some 
> guidance.
>  >
>  > Last, but not least, whatever is the correct thing to do, can you
>  > please add a very clear sentence to the caller preferences 
> draft, so
>  > that there is no doubt as with respect the interpretation?
> 
> Yes. I have already done that in my working draft as a result of the 
> aforementioned thread with Paul K. and Juha.
> 
> -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
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Wed Oct  9 08:28:59 2002
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 IAA12624
	for <sip-archive@odin.ietf.org>; Wed, 9 Oct 2002 08:28:59 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g99CUaj17913
	for sip-archive@odin.ietf.org; Wed, 9 Oct 2002 08:30:36 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99CUBv17902;
	Wed, 9 Oct 2002 08:30:11 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99CROv17816
	for <sip@optimus.ietf.org>; Wed, 9 Oct 2002 08:27:24 -0400
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 IAA12526
	for <sip@ietf.org>; Wed, 9 Oct 2002 08:25:15 -0400 (EDT)
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 g99CR7w08658
	for <sip@ietf.org>; Wed, 9 Oct 2002 15:27:07 +0300 (EET DST)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5dd62d20e5ac158f2143d@esvir01nok.ntc.nokia.com>;
 Wed, 9 Oct 2002 15:27:20 +0300
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 9 Oct 2002 15:27:19 +0300
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: [Sip] Re: Question about caller preferences
Date: Wed, 9 Oct 2002 15:27:17 +0300
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C206DB@esebe019.ntc.nokia.com>
Thread-Topic: [Sip] Re: Question about caller preferences
Thread-Index: AcJvjDvza/3/aHyTTO+nn40nGjewtgAAsP0g
To: <mark.beckmann@siemens.com>, <sip@ietf.org>
Cc: <jdrosen@dynamicsoft.com>, <Miguel.A.Garcia@ericsson.com>,
        <drage@lucent.com>, <georg.mayer@icn.siemens.de>
X-OriginalArrivalTime: 09 Oct 2002 12:27:19.0167 (UTC) FILETIME=[35B228F0:01C26F8F]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g99CROv17817
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit

Its for receiving. When a UA registers with contact that has methods-param, its indicating the methods it understands and capable of handling when receiving.

Regards,
Hisham

> -----Original Message-----
> From: ext Beckmann Mark ICM MP P PS 4 SAL 2
> [mailto:mark.beckmann@siemens.com]
> Sent: Wednesday, October 09, 2002 3:00 PM
> To: sip@ietf.org
> Cc: 'Jonathan Rosenberg'; Miguel A. Garcia; Keith Drage; 
> Mayer Georg ICM
> N PG SP ST N 1
> Subject: RE: [Sip] Re: Question about caller preferences
> 
> 
> Hi,
> 
> I have another question about the caller preferences, 
> especially regarding
> the method tag of the contact parameter.
> 
> Perhaps, this was discussed before on the list. In the draft, 
> however, I
> couldn't find any hint whether it is possible to indicate the 
> "direction",
> in which a UA supports a specific method.
> 
> For example a UA that indicates support for the methods 
> SUBSCRIBE and NOTIFY
> would add a contact parameter as follows:
> 
> Contact: <sip:ua.example.com>;methods="SUBSCRIBE,NOTIFY"
> 
> Now, does this mean the UA has to accept and be able to send 
> both methods? I
> would guess that for some UAs it would make sense to support 
> the ability to
> subscribe to an event and receive NOTIFYs, but not to accept 
> SUBSCRIBEs and
> send NOTIFYs itself.
> 
> Regards,
> 
> Mark
> 
> Mark Beckmann			Siemens AG
> 
> ICM MP P PS 4S2
> P.O.Box 100702			phone: +49 (5341) 906 1814
> D-38228 Salzgitter   		fax:   +49 (5341) 906 2010
> 
> mailto: Mark.Beckmann@siemens.com
> 
> 
> 
> > -----Original Message-----
> > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> > Sent: Thursday, September 26, 2002 7:21 PM
> > To: Miguel A. Garcia
> > Cc: sip@ietf.org; Keith Drage
> > Subject: [Sip] Re: Question about caller preferences
> > 
> > 
> > inline.
> > 
> > Miguel A. Garcia wrote:
> >  > Hi:
> >  >
> >  > I had a discussion with some folks about the caller preferences
> >  > draft, and we have some questions that we weren't able 
> to answer by
> >  > reading the document.
> >  >
> >  > We understand that by not publishing the support for a 
> feature set,
> >  > the UA is not providing any information. Therefore, the 
> feature set
> >  > may or may not be supported at the UA.
> > 
> > Actually, RFC 2533 (which we are using) does say something concrete 
> > about what it means to say nothing about a feature tag. It 
> means that 
> > you are supporting all values. This means you need to be 
> > careful about 
> > the semantics of the headers - the existing Reject-Contact 
> > semantic of 
> > "reject this contact if its feature set matches" is bad, 
> > because it will 
> > cause a UA to be rejected even if it has said nothing about a 
> > particular 
> > feature tag!
> > 
> >  >
> >  > But the question is, if the UA decides to provide 
> > information about a
> >  > supported feature set, shall that information be complete?
> > 
> > Yes.
> > 
> >  >
> >  > We are thinking of the methods parameter in the Contact 
> header for
> >  > registration. In case the methods parameter is included, 
> > shall it be
> >  > complete and list all the methods supported by the UA?
> > 
> > Yes.
> > 
> > There was a thread on the list (likely followed by no one) between 
> > myself, Juha, and Paul K. on this exact issue. Our conclusion 
> > was that 
> > it was reasonable to mandate that a UA include all values 
> it supports 
> > for a feature tag, when it includes that feature tag.
> > 
> >  >
> >  > Example:
> >  >
> >  > Contact:
> >  > 
> > 
> <sip:ua.example.com>;methods="INVITE,ACK,BYE,CANCEL,OPTIONS,REGISTER,-
> >  > UPDATE,SUBSCRIBE,NOTIFY,PRACK,MESSAGE"
> >  >
> >  > Some folks think that the complete list is not essential. In my
> >  > opinion, if a feature is present, it should be complete. In this
> >  > case, all the methods supported by the UA must be present.
> > 
> > That is correct.
> > 
> >  >
> >  > Other folks didn't see the need to publish the support 
> for methods
> >  > like ACK (implicitly supported if INVITE is supported), or NOTIFY
> >  > (implicitly supported if SUBSCRIBE is supported).
> >  >
> >  > In my opinion, that assumption is always wrong, because 
> the methods
> >  > parameter indicates support for SIP methods, not for SIP
> >  > capabilities.
> > 
> > I would agree. Without listing all methods, you put the 
> burden on the 
> > server to lean what other methods a UA will support based on 
> > the ones it 
> > listed. That won't always be a trivial exercise.
> > 
> >  >
> >  > I would like to hear the opinion of the WG to give us some 
> > guidance.
> >  >
> >  > Last, but not least, whatever is the correct thing to do, can you
> >  > please add a very clear sentence to the caller preferences 
> > draft, so
> >  > that there is no doubt as with respect the interpretation?
> > 
> > Yes. I have already done that in my working draft as a 
> result of the 
> > aforementioned thread with Paul K. and Juha.
> > 
> > -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
> > 
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip
> > 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Wed Oct  9 11:35:05 2002
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 LAA22156
	for <sip-archive@odin.ietf.org>; Wed, 9 Oct 2002 11:35:04 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g99Faga30037
	for sip-archive@odin.ietf.org; Wed, 9 Oct 2002 11:36:42 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99Fa7v30012;
	Wed, 9 Oct 2002 11:36:07 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99E8Dv24268
	for <sip@optimus.ietf.org>; Wed, 9 Oct 2002 10:08:13 -0400
Received: from zrha220a.siemens-sbs.ch (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17759
	for <sip@ietf.org>; Wed, 9 Oct 2002 10:06:03 -0400 (EDT)
Received: from fw3ext.siemens.ch (fw3ext.siemens-sbs.ch [194.204.64.99])
	by zrha220a.siemens-sbs.ch (Build 101 8.9.3/NT-8.9.3) with ESMTP id QAA15912
	for <sip@ietf.org>; Wed, 09 Oct 2002 16:09:25 +0200
Received: from zrha221a.siemens.ch by fw3ext.siemens.ch
          via smtpd (for zrha220a.siemens-sbs.ch [194.204.64.135]) with ESMTP; Wed, 9 Oct 2002 16:08:09 +0200
Received: from zrha131a.zrh.siemens.ch (ZRHA131A.zrh.siemens.ch [139.16.10.12])
	by zrha221a.zrh.siemens.ch (Build 101 8.9.3/NT-8.9.3) with ESMTP id QAA20383
	for <sip@ietf.org>; Wed, 09 Oct 2002 16:10:31 +0200
Received: by ZRHA131A.zrh.siemens.ch with Internet Mail Service (5.5.2653.19)
	id <4BK9L5V2>; Wed, 9 Oct 2002 16:08:09 +0200
Message-ID: <9F4C9ED01351D111B85F006097BC499804970E80@ZRHA133A.zrh.siemens.ch>
From: Baker Shaun <shaun.baker@siemens.com>
To: sip@ietf.org
Subject: [Sip] New SIP Client and SIP-H323 GW Available
Date: Wed, 9 Oct 2002 16:08:07 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

Following this lead, there is a free, though not open-source, SIP client and
also a SIP-H323 Gateway available to anyone is the SIP community:

http://www.mysip.ch

-Shaun.

-----Original Message-----
From: Jiri Kuthan [mailto:jiri@iptel.org]
Sent: Dienstag, 8. Oktober 2002 03:38
To: sip@ietf.org
Subject: [Sip] New SIP Server Available


I'm glad to announce availability of a free, open-source SIP
server to the SIP community.

http://www.iptel.org/ser/

-Jiri

--
Jiri Kuthan            http://iptel.org/~jiri/

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



From mailnull@www1.ietf.org  Wed Oct  9 11:56:05 2002
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 LAA22955
	for <sip-archive@odin.ietf.org>; Wed, 9 Oct 2002 11:56:05 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g99Fvik31514
	for sip-archive@odin.ietf.org; Wed, 9 Oct 2002 11:57:44 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99FvEv31500;
	Wed, 9 Oct 2002 11:57:14 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99Fuov31465
	for <sip@optimus.ietf.org>; Wed, 9 Oct 2002 11:56:50 -0400
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 LAA22924
	for <sip@ietf.org>; Wed, 9 Oct 2002 11:54:41 -0400 (EDT)
Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44])
	by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g99FuaaW000074;
	Wed, 9 Oct 2002 08:56:36 -0700 (PDT)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134])
	by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA)
	with ESMTP id ABB62967;
	Wed, 9 Oct 2002 08:54:37 -0700 (PDT)
Date: Wed, 9 Oct 2002 08:54:47 -0700
Subject: Re: [Sip] RFC 2976 INFO Method
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v546)
Cc: sip@ietf.org, "Poetzl, Joachim" <Joachim.Poetzl@telekom.de>,
        "Alexeitsev, D" <D.Alexeitsev@telekom.de>,
        "Tolksdorf, Christian" <Christian.Tolksdorf@telekom.de>,
        Robert.Benz@telekom.de, "Pinker, Gerold" <Gerold.Pinker@telekom.de>
To: "Jesske, R" <R.Jesske@telekom.de>
From: Rohan Mahy <rohan@cisco.com>
In-Reply-To: <C835D57E3730D6119F5000A0C9F019A90201DD11@U8P13.blf01.telekom.de>
Message-Id: <6F9B2E78-DB9F-11D6-A081-0003938AF740@cisco.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.546)
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi,

INFO is not obsolete.  3261 Obsoletes 2543, so the effect of this is 
that any RFC which contains 2543 as a normative reference is to 
effectively update that reference.

thanks,
-rohan


On Wednesday, October 9, 2002, at 04:22 AM, Jesske, R wrote:

> Dear all,
> With publishing RFC 3261 SIP the "old" RFC 2543 is now obsolete. My 
> question is now what is the status of RFC 2976 INFO Method, is it also 
> obsolete? Because this RFC is referring to RFC 2543.
>
> Best Regards
>
> Roland
>
>
> Deutsche Telekom AG
> T Com Zentrale
> Section T38; Signalling, Gateways and Switching Systems
> Roland Jesske, T38a12
> Am Kavalleriesand 3, 64295 Darmstadt, Germany
> Phone:  +49 6151 83-5940
> Fax:    +49 6151 83-4577
> mailto: r.jesske@telekom.de
>
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip

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



From mailnull@www1.ietf.org  Wed Oct  9 12:07:17 2002
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 MAA23497
	for <sip-archive@odin.ietf.org>; Wed, 9 Oct 2002 12:07:17 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g99G8tS00631
	for sip-archive@odin.ietf.org; Wed, 9 Oct 2002 12:08:55 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99G7Wv00496;
	Wed, 9 Oct 2002 12:07:32 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99G6xv32444
	for <sip@optimus.ietf.org>; Wed, 9 Oct 2002 12:06:59 -0400
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 MAA23416
	for <sip@ietf.org>; Wed, 9 Oct 2002 12:04:49 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.47.242])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g99G6nYH007713;
	Wed, 9 Oct 2002 12:06:50 -0400 (EDT)
Message-ID: <3DA45418.5030706@dynamicsoft.com>
Date: Wed, 09 Oct 2002 12:06:48 -0400
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: mark.beckmann@siemens.com, sip@ietf.org, Miguel.A.Garcia@ericsson.com,
        drage@lucent.com, georg.mayer@icn.siemens.de
Subject: Re: [Sip] Re: Question about caller preferences
References: <2038BCC78B1AD641891A0D1AE133DBB7C206DB@esebe019.ntc.nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Yes, that is true. Its based on the fact that the spec says that the 
methods param and the Allow header convey the same information. Allow 
indicates methods you can receive.

I should probably explicitly say it, though.

-Jonathan R.

hisham.khartabil@nokia.com wrote:
 > Its for receiving. When a UA registers with contact that has
 > methods-param, its indicating the methods it understands and capable
 > of handling when receiving.
 >
 > Regards, Hisham
 >
 >
 >> -----Original Message----- From: ext Beckmann Mark ICM MP P PS 4
 >> SAL 2 [mailto:mark.beckmann@siemens.com] Sent: Wednesday, October
 >> 09, 2002 3:00 PM To: sip@ietf.org Cc: 'Jonathan Rosenberg'; Miguel
 >> A. Garcia; Keith Drage; Mayer Georg ICM N PG SP ST N 1 Subject: RE:
 >> [Sip] Re: Question about caller preferences
 >>
 >>
 >> Hi,
 >>
 >> I have another question about the caller preferences, especially
 >> regarding the method tag of the contact parameter.
 >>
 >> Perhaps, this was discussed before on the list. In the draft,
 >> however, I couldn't find any hint whether it is possible to
 >> indicate the "direction", in which a UA supports a specific method.
 >>
 >>
 >> For example a UA that indicates support for the methods SUBSCRIBE
 >> and NOTIFY would add a contact parameter as follows:
 >>
 >> Contact: <sip:ua.example.com>;methods="SUBSCRIBE,NOTIFY"
 >>
 >> Now, does this mean the UA has to accept and be able to send both
 >> methods? I would guess that for some UAs it would make sense to
 >> support the ability to subscribe to an event and receive NOTIFYs,
 >> but not to accept SUBSCRIBEs and send NOTIFYs itself.
 >>
 >> Regards,
 >>
 >> Mark
 >>
 >> Mark Beckmann			Siemens AG
 >>
 >> ICM MP P PS 4S2 P.O.Box 100702			phone: +49 (5341) 906 1814 D-38228
 >> Salzgitter   		fax:   +49 (5341) 906 2010
 >>
 >> mailto: Mark.Beckmann@siemens.com
 >>
 >>
 >>
 >>
 >>> -----Original Message----- From: Jonathan Rosenberg
 >>> [mailto:jdrosen@dynamicsoft.com] Sent: Thursday, September 26,
 >>> 2002 7:21 PM To: Miguel A. Garcia Cc: sip@ietf.org; Keith Drage
 >>> Subject: [Sip] Re: Question about caller preferences
 >>>
 >>>
 >>> inline.
 >>>
 >>> Miguel A. Garcia wrote:
 >>>> Hi:
 >>>>
 >>>> I had a discussion with some folks about the caller preferences
 >>>>  draft, and we have some questions that we weren't able
 >>
 >> to answer by
 >>
 >>>> reading the document.
 >>>>
 >>>> We understand that by not publishing the support for a
 >>
 >> feature set,
 >>
 >>>> the UA is not providing any information. Therefore, the
 >>
 >> feature set
 >>
 >>>> may or may not be supported at the UA.
 >>>
 >>> Actually, RFC 2533 (which we are using) does say something
 >>> concrete about what it means to say nothing about a feature tag.
 >>> It
 >>
 >> means that
 >>
 >>> you are supporting all values. This means you need to be careful
 >>> about the semantics of the headers - the existing Reject-Contact
 >>>  semantic of "reject this contact if its feature set matches" is
 >>> bad, because it will cause a UA to be rejected even if it has
 >>> said nothing about a particular feature tag!
 >>>
 >>>>
 >>>> But the question is, if the UA decides to provide
 >>> information about a
 >>>> supported feature set, shall that information be complete?
 >>>
 >>> Yes.
 >>>
 >>>>
 >>>> We are thinking of the methods parameter in the Contact
 >>
 >> header for
 >>
 >>>> registration. In case the methods parameter is included,
 >>> shall it be
 >>>> complete and list all the methods supported by the UA?
 >>>
 >>> Yes.
 >>>
 >>> There was a thread on the list (likely followed by no one)
 >>> between myself, Juha, and Paul K. on this exact issue. Our
 >>> conclusion was that it was reasonable to mandate that a UA
 >>> include all values
 >>
 >> it supports
 >>
 >>> for a feature tag, when it includes that feature tag.
 >>>
 >>>>
 >>>> Example:
 >>>>
 >>>> Contact:
 >>>>
 >>>
 >>
 >> <sip:ua.example.com>;methods="INVITE,ACK,BYE,CANCEL,OPTIONS,REGISTER,-
 >>
 >>
 >>>> UPDATE,SUBSCRIBE,NOTIFY,PRACK,MESSAGE"
 >>>>
 >>>> Some folks think that the complete list is not essential. In my
 >>>>  opinion, if a feature is present, it should be complete. In
 >>>> this case, all the methods supported by the UA must be present.
 >>>>
 >>>
 >>> That is correct.
 >>>
 >>>>
 >>>> Other folks didn't see the need to publish the support
 >>
 >> for methods
 >>
 >>>> like ACK (implicitly supported if INVITE is supported), or
 >>>> NOTIFY (implicitly supported if SUBSCRIBE is supported).
 >>>>
 >>>> In my opinion, that assumption is always wrong, because
 >>
 >> the methods
 >>
 >>>> parameter indicates support for SIP methods, not for SIP
 >>>> capabilities.
 >>>
 >>> I would agree. Without listing all methods, you put the
 >>
 >> burden on the
 >>
 >>> server to lean what other methods a UA will support based on the
 >>> ones it listed. That won't always be a trivial exercise.
 >>>
 >>>>
 >>>> I would like to hear the opinion of the WG to give us some
 >>> guidance.
 >>>>
 >>>> Last, but not least, whatever is the correct thing to do, can
 >>>> you please add a very clear sentence to the caller preferences
 >>>>
 >>> draft, so
 >>>> that there is no doubt as with respect the interpretation?
 >>>
 >>> Yes. I have already done that in my working draft as a
 >>
 >> result of the
 >>
 >>> aforementioned thread with Paul K. and Juha.
 >>>
 >>> -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
 >>>
 >>> _______________________________________________ Sip mailing list
 >>> https://www1.ietf.org/mailman/listinfo/sip This list is for NEW
 >>> development of the core SIP Protocol Use
 >>> sip-implementors@cs.columbia.edu for questions on current sip Use
 >>> sipping@ietf.org for new developments on the application of sip
 >>>
 >>
 >> _______________________________________________ Sip mailing list
 >> https://www1.ietf.org/mailman/listinfo/sip This list is for NEW
 >> development of the core SIP Protocol Use
 >> sip-implementors@cs.columbia.edu for questions on current sip Use
 >> sipping@ietf.org for new developments on the application of 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

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



From mailnull@www1.ietf.org  Wed Oct  9 12:08:24 2002
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 MAA23577
	for <sip-archive@odin.ietf.org>; Wed, 9 Oct 2002 12:08:24 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g99GA2c00707
	for sip-archive@odin.ietf.org; Wed, 9 Oct 2002 12:10:02 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99G96v00660;
	Wed, 9 Oct 2002 12:09:06 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99G8Nv00610
	for <sip@optimus.ietf.org>; Wed, 9 Oct 2002 12:08:23 -0400
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 MAA23449
	for <sip@ietf.org>; Wed, 9 Oct 2002 12:06:14 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.47.242])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g99G87YH007716;
	Wed, 9 Oct 2002 12:08:08 -0400 (EDT)
Message-ID: <3DA45466.8020606@dynamicsoft.com>
Date: Wed, 09 Oct 2002 12:08:06 -0400
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: "Jesske, R" <R.Jesske@telekom.de>
CC: sip@ietf.org, "Poetzl, Joachim" <Joachim.Poetzl@telekom.de>,
        "Alexeitsev, D" <D.Alexeitsev@telekom.de>,
        "Tolksdorf, Christian" <Christian.Tolksdorf@telekom.de>,
        Robert.Benz@telekom.de, "Pinker, Gerold" <Gerold.Pinker@telekom.de>
Subject: Re: [Sip] RFC 2976 INFO Method
References: <C835D57E3730D6119F5000A0C9F019A90201DD11@U8P13.blf01.telekom.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

No, its not obsolete. Although I frequently wish it was....

-Jonathan R.

Jesske, R wrote:
 > Dear all, With publishing RFC 3261 SIP the "old" RFC 2543 is now
 > obsolete. My question is now what is the status of RFC 2976 INFO
 > Method, is it also obsolete? Because this RFC is referring to RFC
 > 2543.
 >
 > Best Regards
 >
 > Roland
 >
 >
 > Deutsche Telekom AG T Com Zentrale Section T38; Signalling, Gateways
 > and Switching Systems Roland Jesske, T38a12 Am Kavalleriesand 3,
 > 64295 Darmstadt, Germany Phone:  +49 6151 83-5940 Fax:    +49 6151
 > 83-4577 mailto: r.jesske@telekom.de
 >
 >
 >
 > _______________________________________________ Sip mailing list
 > https://www1.ietf.org/mailman/listinfo/sip This list is for NEW
 > development of the core SIP Protocol Use
 > sip-implementors@cs.columbia.edu for questions on current sip Use
 > sipping@ietf.org for new developments on the application of 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

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



From mailnull@www1.ietf.org  Wed Oct  9 12:17:04 2002
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 MAA23952
	for <sip-archive@odin.ietf.org>; Wed, 9 Oct 2002 12:17:04 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g99GIhM01113
	for sip-archive@odin.ietf.org; Wed, 9 Oct 2002 12:18:43 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99GIGv01092;
	Wed, 9 Oct 2002 12:18:16 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99GHKv01014
	for <sip@optimus.ietf.org>; Wed, 9 Oct 2002 12:17:20 -0400
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 MAA23882
	for <sip@ietf.org>; Wed, 9 Oct 2002 12:15:10 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.47.242])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g99GHEYH007719;
	Wed, 9 Oct 2002 12:17:15 -0400 (EDT)
Message-ID: <3DA4568A.7030407@dynamicsoft.com>
Date: Wed, 09 Oct 2002 12:17:14 -0400
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: sip@ietf.org
Subject: Re: [Sip] Bug in absolute-URI grammar
References: <2038BCC78B1AD641891A0D1AE133DBB7C206D6@esebe019.ntc.nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit



hisham.khartabil@nokia.com wrote:
 > I sent this a while ago and am resending.

Yes, there is a bug in the grammar, which will cause an absoluteURI to 
have two @ signs. Clearly, only one is intended. The production for srvr 
should not have the @ sign. This is logged in bugzilla:

http://www.sipwg.org/sipwg/show_bug.cgi?id=645

 > I also have a further
 > comment/question:
 >
 > net-path       =  "//" authority [ abs-path ]
 > authority      =  srvr / reg-name
 > srvr           =  [ [ userinfo "@" ] hostport ]
 > reg-name  =  1*( unreserved / escaped / "$" / "," / ";" / ":" / "@" / 
 >              "&" / "=" / "+" )
 >
 > How can a parser distinguish between srvr and reg-name? the @ sign is
 > allowed in both?

The @ sign does appear to be allowed in both. This is all copied from 
rfc2396, which doesn't give any guidance on how to distinguish the two. 
The only thing it says is that its scheme specific, so perhaps the 
intention is that whether you use srvr or reg-name depends on the scheme.

-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

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



From mailnull@www1.ietf.org  Wed Oct  9 13:38:30 2002
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 NAA26822
	for <sip-archive@odin.ietf.org>; Wed, 9 Oct 2002 13:38:30 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g99HeAV06034
	for sip-archive@odin.ietf.org; Wed, 9 Oct 2002 13:40:10 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99HdGv05979;
	Wed, 9 Oct 2002 13:39:16 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99HWiv05268
	for <sip@optimus.ietf.org>; Wed, 9 Oct 2002 13:32:44 -0400
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 NAA26602
	for <sip@ietf.org>; Wed, 9 Oct 2002 13:30:33 -0400 (EDT)
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 g99HWbe11732
	for <sip@ietf.org>; Wed, 9 Oct 2002 13:32:37 -0400 (EDT)
Received: by en0060D057.uk.lucent.com with Internet Mail Service (5.5.2653.19)
	id <TYBQ48DV>; Wed, 9 Oct 2002 18:32:36 +0100
Message-ID: <475FF955A05DD411980D00508B6D5FB00636B23F@en0033exch001u.uk.lucent.com>
From: "Drage, Keith (Keith)" <drage@lucent.com>
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "Jesske, R"
	 <R.Jesske@telekom.de>
Cc: sip@ietf.org, "Poetzl, Joachim" <Joachim.Poetzl@telekom.de>,
        "Alexeitsev, D" <D.Alexeitsev@telekom.de>,
        "Tolksdorf, Christian"
	 <Christian.Tolksdorf@telekom.de>,
        Robert.Benz@telekom.de, "Pinker, Gerold" <Gerold.Pinker@telekom.de>
Subject: RE: [Sip] RFC 2976 INFO Method
Date: Wed, 9 Oct 2002 18:32:35 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

Despite my detailed previous reply, I sympathise with Jonathan.

I suspect that the version that advances through the internet standards process, if any, will not look the same as RFC 2976. At least there will be some drastic rewriting of the scope/applicability.

Keith

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

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: 09 October 2002 17:08
> To: Jesske, R
> Cc: sip@ietf.org; Poetzl, Joachim; Alexeitsev, D; Tolksdorf, 
> Christian;
> Robert.Benz@telekom.de; Pinker, Gerold
> Subject: Re: [Sip] RFC 2976 INFO Method
> 
> 
> No, its not obsolete. Although I frequently wish it was....
> 
> -Jonathan R.
> 
> Jesske, R wrote:
>  > Dear all, With publishing RFC 3261 SIP the "old" RFC 2543 is now
>  > obsolete. My question is now what is the status of RFC 2976 INFO
>  > Method, is it also obsolete? Because this RFC is referring to RFC
>  > 2543.
>  >
>  > Best Regards
>  >
>  > Roland
>  >
>  >
>  > Deutsche Telekom AG T Com Zentrale Section T38; 
> Signalling, Gateways
>  > and Switching Systems Roland Jesske, T38a12 Am Kavalleriesand 3,
>  > 64295 Darmstadt, Germany Phone:  +49 6151 83-5940 Fax:    +49 6151
>  > 83-4577 mailto: r.jesske@telekom.de
>  >
>  >
>  >
>  > _______________________________________________ Sip mailing list
>  > https://www1.ietf.org/mailman/listinfo/sip This list is for NEW
>  > development of the core SIP Protocol Use
>  > sip-implementors@cs.columbia.edu for questions on current sip Use
>  > sipping@ietf.org for new developments on the application of 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
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Wed Oct  9 13:39:49 2002
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 NAA26847
	for <sip-archive@odin.ietf.org>; Wed, 9 Oct 2002 13:39:49 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g99HfTV06086
	for sip-archive@odin.ietf.org; Wed, 9 Oct 2002 13:41:29 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99HfAv06077;
	Wed, 9 Oct 2002 13:41:10 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99HWjv05274
	for <sip@optimus.ietf.org>; Wed, 9 Oct 2002 13:32:45 -0400
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 NAA26605
	for <sip@ietf.org>; Wed, 9 Oct 2002 13:30:34 -0400 (EDT)
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 g99HWce11749
	for <sip@ietf.org>; Wed, 9 Oct 2002 13:32:39 -0400 (EDT)
Received: by en0060D057.uk.lucent.com with Internet Mail Service (5.5.2653.19)
	id <TYBQ48DW>; Wed, 9 Oct 2002 18:32:36 +0100
Message-ID: <475FF955A05DD411980D00508B6D5FB00636B23E@en0033exch001u.uk.lucent.com>
From: "Drage, Keith (Keith)" <drage@lucent.com>
To: Rohan Mahy <rohan@cisco.com>, "Jesske, R" <R.Jesske@telekom.de>
Cc: sip@ietf.org, "Poetzl, Joachim" <Joachim.Poetzl@telekom.de>,
        "Alexeitsev, D" <D.Alexeitsev@telekom.de>,
        "Tolksdorf, Christian"
	 <Christian.Tolksdorf@telekom.de>,
        Robert.Benz@telekom.de, "Pinker, Gerold" <Gerold.Pinker@telekom.de>
Subject: RE: [Sip] RFC 2976 INFO Method
Date: Wed, 9 Oct 2002 18:32:35 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

I do not think it is as simple as that.

I did go looking for the rules in the various RFCs that define the IETF drafting, but failed to find anything.

First of all, I agree with Rohan that the obsoleting of RFC 2543 (or should it be status Historic) does not affect the status of RFC 2976.

I do not agree with the assertion of Rohan that a reader of RFC 2976 should simply replace all instances of RFC 2543 in RFC 2976 with RFC 3261. The correct interpretation of a normative reference is that when in the text one comes across a reference, one should do a substitution of the reference with the text of the reference. That substitution should still be done to RFC 2543. (Note that it is the references in the text that count, not the existence in the reference list at the end of the document - it is no good defining a macro without defining points where the macro should be inserted!) A conformant implementation to RFC 2976 without further condition must then still implement those requirements as specified.

What the sensible reader will then do is compare the text substituted in to that in the equivalent requirements in RFC 3261, and note the implications of any differences. As a result he may decide to implement the RFC 2543 sourced requirement or the RFC 3261 sourced requirement. For example, the key to the headers table in RFC 2976 is taken by reference to RFC 2543. That key changed in RFC 3261. It is probably better to use the original RFC 2543 key in interpreting the table rather than the RFC 3261 one. The reference to the syntax is again by reference to RFC 2543. Here it is probably better to interpret the RFC 2976 syntax in the light of the slightly amended lexical rules specified by RFC 3261. Any implementor performing this process will need to document their decision process as part of any statement of conformance, i.e. they conform to RFC 2976 with the following modifications (here provide list of changes) that take into account improvements and clarifications made in!
 RFC 3261.

Note that the above is really only a shortcut to save a specification being updated. If this interpretation process of the impact and applicability of RFC 3261 changes leads to incompatible implementations, then the onus is on the IETF to revise RFC 2976.

However this understanding is by my knowledge of commonly accepted rules in other standards bodies, rather than anything I could find in RFCs, so anybodies interpretation could be correct. Does anybody know of any IETF documentation that covers this?

Keith



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

> -----Original Message-----
> From: Rohan Mahy [mailto:rohan@cisco.com]
> Sent: 09 October 2002 16:55
> To: Jesske, R
> Cc: sip@ietf.org; Poetzl, Joachim; Alexeitsev, D; Tolksdorf, 
> Christian;
> Robert.Benz@telekom.de; Pinker, Gerold
> Subject: Re: [Sip] RFC 2976 INFO Method
> 
> 
> Hi,
> 
> INFO is not obsolete.  3261 Obsoletes 2543, so the effect of this is 
> that any RFC which contains 2543 as a normative reference is to 
> effectively update that reference.
> 
> thanks,
> -rohan
> 
> 
> On Wednesday, October 9, 2002, at 04:22 AM, Jesske, R wrote:
> 
> > Dear all,
> > With publishing RFC 3261 SIP the "old" RFC 2543 is now obsolete. My 
> > question is now what is the status of RFC 2976 INFO Method, 
> is it also 
> > obsolete? Because this RFC is referring to RFC 2543.
> >
> > Best Regards
> >
> > Roland
> >
> >
> > Deutsche Telekom AG
> > T Com Zentrale
> > Section T38; Signalling, Gateways and Switching Systems
> > Roland Jesske, T38a12
> > Am Kavalleriesand 3, 64295 Darmstadt, Germany
> > Phone:  +49 6151 83-5940
> > Fax:    +49 6151 83-4577
> > mailto: r.jesske@telekom.de
> >
> >
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Thu Oct 10 00:43:16 2002
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 AAA13253
	for <sip-archive@odin.ietf.org>; Thu, 10 Oct 2002 00:43:16 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9A4j1K07584
	for sip-archive@odin.ietf.org; Thu, 10 Oct 2002 00:45:01 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9A4hiv07554;
	Thu, 10 Oct 2002 00:43:44 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9A4fMv07505
	for <sip@optimus.ietf.org>; Thu, 10 Oct 2002 00:41:22 -0400
Received: from WS0005.indiatimes.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13224
	for <sip@ietf.org>; Thu, 10 Oct 2002 00:39:04 -0400 (EDT)
Received: from 192.168.57.15 (a2 [192.168.57.22])
	by WS0005.indiatimes.com (8.9.3/8.9.3) with SMTP id JAA15663
	for <sip@ietf.org>; Thu, 10 Oct 2002 09:48:29 +0530
From: "shilpa_ramesh" <shilpa_ramesh@indiatimes.com>
Message-Id: <200210100418.JAA15663@WS0005.indiatimes.com>
To: <sip@ietf.org>
Reply-To: "shilpa_ramesh"<shilpa_ramesh@indiatimes.com>
Date: Thu, 10 Oct 2002 10:03:06 +0530
X-URL: http://indiatimes.com
Content-Type: multipart/alternative;
	   boundary="=_MAILER_ATTACH_BOUNDARY1_20021010410361315634022"
MIME-Version: 1.0
Subject: [Sip] Proxy and redirect server
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

--=_MAILER_ATTACH_BOUNDARY1_20021010410361315634022
Content-Type: text/plain; charset=us-ascii

Hello all,


I came across a paper where in it is given that a user sometimes contacts the proxy server first to connect to another user..but sometimes he contacts the redirect server...


can anyone tell me when r proxy servers used and when r redirect servers used??why can't we use redirect and proxy server as one single server???


thanks,


shilpa
Get Your Private, Free E-mail from Indiatimes at  http://email.indiatimes.com
Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in

--=_MAILER_ATTACH_BOUNDARY1_20021010410361315634022
Content-Type: text/html; charset=us-ascii

<P>Hello all,</P>
<P>I came across a paper where in it is given that a user sometimes contacts the proxy server first to connect to another user..but sometimes he contacts the redirect server...</P>
<P>can anyone tell me when r proxy servers used and when r redirect servers used??why can't we use redirect and proxy server as one single server???</P>
<P>thanks,</P>
<P>shilpa</P>
<hr><font face="Arial" size="2"><b>Get Your Private, Free E-mail from Indiatimes at  </font><a href="http://email.indiatimes.com"><font face="Arial" size="2">http://email.indiatimes.com</font></a></b><br>Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from <A href="http://www.planetm.co.in">http://www.planetm.co.in</A>

--=_MAILER_ATTACH_BOUNDARY1_20021010410361315634022--

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



From mailnull@www1.ietf.org  Thu Oct 10 03:08:36 2002
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 DAA24208
	for <sip-archive@odin.ietf.org>; Thu, 10 Oct 2002 03:08:36 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9A7ANJ22831
	for sip-archive@odin.ietf.org; Thu, 10 Oct 2002 03:10:23 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9A79Dv22743;
	Thu, 10 Oct 2002 03:09:13 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9A75Xv22115
	for <sip@optimus.ietf.org>; Thu, 10 Oct 2002 03:05:33 -0400
Received: from hclnpd.hclt.co.in (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24128
	for <sip@ietf.org>; Thu, 10 Oct 2002 03:03:15 -0400 (EDT)
Received: from blaze.hcltech.com (blaze.hclt-ntl.co.in [192.168.19.30]) by hclnpd.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id SP905ZBR; Thu, 10 Oct 2002 12:35:38 +0530
Received: from sachinhome ([192.168.19.43])
	by blaze.hcltech.com (8.9.3/8.9.3) with SMTP id NAA18881
	for <sip@ietf.org>; Thu, 10 Oct 2002 13:04:04 +0530
Message-ID: <000001c2702d$0b698860$a5f1fea9@sachinhome>
From: "Sachin Shenoy" <sachins@netlab.hcltech.com>
To: <sip@ietf.org>
Date: Thu, 10 Oct 2002 12:26:17 +0530
Organization: HCL Technologies
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000F_01C27058.3B7D5E20"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Subject: [Sip] Accept header grammar problem
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_000F_01C27058.3B7D5E20
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

According to the RFC 3261 accept header grammar has...



accept-range =3D media-range *(SEMI accept-param)

media-range =3D ( "*/*"

   / ( m-type SLASH "*" )

   / ( m-type SLASH m-subtype )

   ) *( SEMI m-parameter )

accept-param =3D ("q" EQUAL qvalue) / generic-param

generic-param =3D token [ EQUAL gen-value ]

gen-value =3D token / host / quoted-string

m-parameter =3D m-attribute EQUAL m-value

m-attribute =3D token

m-value =3D token / quoted-string





I think there would be an ambiguity between the "accept-param" in =
"accept-range" &=20

"m-parameter" in "media-range". Cause both are separated by SEMI's.=20

How do we resolve this?



Thanks

Sachin




------=_NextPart_000_000F_01C27058.3B7D5E20
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 http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>
<P><FONT face=3DArial>Hi,</FONT></P>
<P><FONT face=3DArial>According to the RFC 3261 accept header grammar=20
has...</FONT></P>
<P><FONT face=3DArial></FONT>&nbsp;</P>
<P>accept-range =3D media-range *(SEMI accept-param)</P>
<P>media-range =3D ( "*/*"</P>
<P>&nbsp;&nbsp; / ( m-type SLASH "*" )</P>
<P>&nbsp;&nbsp; / ( m-type SLASH m-subtype )</P>
<P>&nbsp;&nbsp; ) *( SEMI m-parameter )</P><FONT face=3DArial><FONT =
size=3D2>
<P>accept-param =3D ("q" EQUAL qvalue) / generic-param</P><FONT =
size=3D2>
<P>generic-param =3D token [ EQUAL gen-value ]</P>
<P>gen-value =3D token / host / quoted-string</P></FONT><FONT size=3D2>
<P>m-parameter =3D m-attribute EQUAL m-value</P>
<P>m-attribute =3D token</P>
<P>m-value =3D token / quoted-string</P>
<P>&nbsp;</P>
<P>&nbsp;</P></FONT></FONT></FONT>
<P><FONT face=3DArial>I think there would be an ambiguity between the=20
"accept-param" in "accept-range" &amp; </FONT></P>
<P><FONT face=3DArial>"m-parameter" in "media-range". Cause both are =
separated by=20
SEMI's. </FONT></P>
<P><FONT face=3DArial>How do we resolve this?</FONT></P>
<P><FONT face=3DArial></FONT>&nbsp;</P>
<P><FONT face=3DArial>Thanks</FONT></P>
<P><FONT face=3DArial>Sachin</FONT></P>
<P><FONT face=3DArial></FONT>&nbsp;</P></FONT></DIV></BODY></HTML>

------=_NextPart_000_000F_01C27058.3B7D5E20--

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



From mailnull@www1.ietf.org  Thu Oct 10 15:15:05 2002
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 PAA20254
	for <sip-archive@odin.ietf.org>; Thu, 10 Oct 2002 15:15:04 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9AJGjJ30506
	for sip-archive@odin.ietf.org; Thu, 10 Oct 2002 15:16:45 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AJGBv30473;
	Thu, 10 Oct 2002 15:16:11 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AJDUv30386
	for <sip@optimus.ietf.org>; Thu, 10 Oct 2002 15:13:30 -0400
Received: from motgate4.mot.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20146
	for <sip@ietf.org>; Thu, 10 Oct 2002 15:11:17 -0400 (EDT)
Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (motgate4 2.1) with ESMTP id MAA17506 for <sip@ietf.org>; Thu, 10 Oct 2002 12:13:23 -0700 (MST)]
Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id MAA23726 for <sip@ietf.org>; Thu, 10 Oct 2002 12:13:23 -0700 (MST)]
Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52)
	id <M3V8JMTX>; Thu, 10 Oct 2002 14:13:22 -0500
Message-ID: <A5B4C9A2AD89D411AB3E009027B0DA1E05133AB1@IL27EXM09.cig.mot.com>
From: Idnani Ajaykumar-AIDNANI1 <Ajaykumar.Idnani@motorola.com>
To: sip@ietf.org, Upp Steve-CSU001 <Steve.Upp@motorola.com>,
        Hallin Tom-ATH033 <thallin@motorola.com>
Subject: RE: [Sip] Comments on draft-idnani-sip-comb-reg-subscr-00.txt
Date: Thu, 10 Oct 2002 14:13:10 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.52)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

All,

We have seen a lot of good comments on this draft.

So here are a few thoughts on the basic reason for writing this draft. We
will try and address issues as we go.

In a mobile environment you have a mobile node (MN) which is not SIP aware.
But it talks to the SIP core network through a SIP Gateway which sits on the
network. The Gateway serves more than one MNs so it will run multiple UA
engines one for each of the MN's it serves. This is called a SIP Proxy UA in
the draft.

Now, when a mobile (MN) registers using non-SIP means, the Proxy UA converts
the register to a SIP Register and sends it to the registrar.

The problem really is when the MN moves from one Proxy UA to another. It
registers with the new Proxy UA, but does not de-register with the old Proxy
UA. It depends on the core network to maintain the registrations correctly
across the proxy UAs.

The draft tries to solve the problem, by having the SIP Registrar send a
notification to the old Proxy UA that the MN has moved. This is not the
normal behavior of the Registrar as someone rightly pointed out because the
Registrar is not a SIP Event server. But the registrar has all the
information it needs to send the notification. What we are suggesting is
that we decouple the NOTIFY message from the SUBSCRIBE message and allow it
to be sent in response to other methods also. Of course this raises
compatibility issues with older versions of SIP and therefore we had
suggested in the draft that the "Event" header which is currently a
mandatory header in the SUBSCRIBE method, be made optional header in other
methods like REGISTER. So only when the Registrar sees a REGISTER method
with the "Event" header, would it send NOTIFYs when the contact information
for the MN changes. Another thing to note out here is, (and this seems to
have created some confusion) the proxy UA is not subscribing for some other
party's information. It is just expecting notification of events for a MN
that it is serving so that it can clean up its resources. It can be argued
that the resource can be cleared when the registration times out, but until
that is done there are chances that the INVITEs would be forked to a proxy
UA that is not really serving the MN, and the proxy UA would end up using
precious radio resources trying to page the MN.

There was also some talk about issues with other headers, but we think we
can take the approach of using the same value for headers, as would be used
in a normal REGISTER message.

One more clarification, the draft was shown using a "presence" event, but we
feel that we could just as well use some other event - maybe a new one -
just to solve the purpose of notifying the old proxy UA that the MN has
moved.

Thanks and Regards
- Ajay

-----Original Message-----
From: Dean Willis [mailto:dean.willis@softarmor.com] 
Sent: Monday, October 07, 2002 3:15 PM
To: duncan.mills@vf.vodafone.co.uk; adam@dynamicsoft.com; sip@ietf.org;
Ajaykumar Idnani; Steve Upp; Tom Hallin
Subject: RE: [Sip] Comments on draft-idnani-sip-comb-reg-subscr-00.txt


Duncan wrote:
> However, I would support a more general version of this 
> draft.  For instance, the real gain I can see (as Adam says, 
> this is only an optimisation, which SIPPING won't allow) is 
> that one REGISTER request does the same thing as a REGISTER + 
> X * SUBSCRIBE requests.  But- In the above draft, the SIP 
> nodes are all in the core network anyway, so this saving is 
> surely less valuable?
> 
> Now, in the 3GPP situation where we send SIP messages across 
> the radio interface, there is a strong requirement to save 
> radio bandwidth. Additionally, we also use the 
> SUBSCRIBE/NOTIFY procedures for events other than presence, 
> so any kind of implicit subscription is attractive...

Perhaps I'm confused about something, but as I recall, the things in IMS
being subscibed to via SUBSCRIBE are not served from the registrar that
services the REGISTER request. In other words, the SUBSCRIBEs don't go
to the same destinations as do the REGISTERs, so combining them doesn't
seem to make a lot of sense in any case. We should have called REGISTER
something like "SETCONTACT" -- it would have avoided a lot of this
discussion.

It would seem far more effective to use a server process that aggregates
notifications and subscriptions, as is done in the "presencelist" work.
In this model one subscribes to a list served by a server, then that
server subscribes to each element of the list, aggregates state, and
filters and returns appropriate notifications to the subscriber thereby
reducing over-the-air traffic tremendously. This effectively replaces
many SUBSCRIBEs with one SUBSCRIBs, and may replace many NOTIFYs with
fewer NOTIFYs, depending on how thoseare handled.
 
> But isn't the problem with implicit subscription the fact 
> that there is no call-id for the NOTIFY request to use?  Is 
> there no way around this?

That's one problem. There are also issues with knowing how to filter
notifications and how to negotiate whether implicit subscription is
supported and lots of other things. We had not finished enumerating the
issues before deciding implicit subscriptions were just dangerous.

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



From mailnull@www1.ietf.org  Thu Oct 10 23:35:04 2002
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 XAA00585
	for <sip-archive@odin.ietf.org>; Thu, 10 Oct 2002 23:35:04 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9B3aoF21983
	for sip-archive@odin.ietf.org; Thu, 10 Oct 2002 23:36:50 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9B3Ztv21951;
	Thu, 10 Oct 2002 23:35:55 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9B3V6v21875
	for <sip@optimus.ietf.org>; Thu, 10 Oct 2002 23:31:06 -0400
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 XAA00519;
	Thu, 10 Oct 2002 23:28:49 -0400 (EDT)
Received: from dwillis9 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.greycouncil.com (8.12.5/8.12.5) with SMTP id g9B3VVXi013827;
	Thu, 10 Oct 2002 22:31:32 -0500
Message-ID: <005a01c270d6$a929db00$1a02a8c0@dwillis9>
From: "Dean Willis" <dean.willis@softarmor.com>
To: <sip@ietf.org>, <sipping@ietf.org>, <simple@ietf.org>
References: <000301c26f06$5d88f9a0$958cfea9@TXDWILLIS2>
Date: Thu, 10 Oct 2002 22:31:17 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Content-Transfer-Encoding: 7bit
Subject: [Sip] Re: [Sipping] Supplementatry web site down for maintenance this afternoon
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

By the way, I think it's been back up for a day or so now. It looks stable
so far . . . as long as I don't run the CD-writer on it. That's still
making a hard kernel lockup.

--
Dean


----- Original Message -----
From: "Dean Willis" <dwillis@dynamicsoft.com>
To: <sip@ietf.org>; <sipping@ietf.org>; <simple@ietf.org>
Sent: Tuesday, October 08, 2002 3:07 PM
Subject: [Sipping] Supplementatry web site down for maintenance this
afternoon


> The www.softarmor.com/.... Web site is down this afternoon -- I'm having
> to replace a disk drive, and decided I might as well upgrade the OS
> concurrently.
>
> If you NEED stuff off of there, please look at
> http://kevlar.softarmor.com/.... instead.
>
> --
> 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
>
>

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



From mailnull@www1.ietf.org  Thu Oct 10 23:50:17 2002
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 XAA00842
	for <sip-archive@odin.ietf.org>; Thu, 10 Oct 2002 23:50:17 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9B3q3V22933
	for sip-archive@odin.ietf.org; Thu, 10 Oct 2002 23:52:03 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9B3pDv22907;
	Thu, 10 Oct 2002 23:51:13 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9B3o7v22871
	for <sip@optimus.ietf.org>; Thu, 10 Oct 2002 23:50:07 -0400
Received: from btlmail.bplmail.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00809
	for <sip@ietf.org>; Thu, 10 Oct 2002 23:47:43 -0400 (EDT)
Received: from [10.10.13.58] (helo=RKUMAR)
	by btlmail.bplmail.com with smtp (Exim 3.22 #1 (Red Hat Linux))
	id 17zqob-00069a-00; Fri, 11 Oct 2002 09:20:17 +0530
Reply-To: <ranjit.avasarala@bplmail.com>
From: "RANJIT" <ranjit.avasarala@bplmail.com>
To: "Idnani Ajaykumar-AIDNANI1" <Ajaykumar.Idnani@motorola.com>
Cc: "Sip-Ietf" <sip@ietf.org>
Subject: RE: [Sip] Comments on draft-idnani-sip-comb-reg-subscr-00.txt
Date: Fri, 11 Oct 2002 09:20:25 +0530
Message-ID: <GGEKLACDJCBAOANBIIIFEEPMCAAA.ranjit.avasarala@bplmail.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.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
In-Reply-To: <A5B4C9A2AD89D411AB3E009027B0DA1E05133AB1@IL27EXM09.cig.mot.com>
Importance: Normal
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi
   I think the 3GPP's document on Internet Multimedia SubSystem already
addresses this topic of SIP aware mobile nodes. There the Registrar is
S-CSCF.

so here each mobile node registers to theS-CSCF in its Home Network.

so how is this draft from the 3GPP specification?

Ranjit :-)

-----Original Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Idnani
Ajaykumar-AIDNANI1
Sent: Friday, October 11, 2002 12:43 AM
To: sip@ietf.org; Upp Steve-CSU001; Hallin Tom-ATH033
Subject: RE: [Sip] Comments on draft-idnani-sip-comb-reg-subscr-00.txt


All,

We have seen a lot of good comments on this draft.

So here are a few thoughts on the basic reason for writing this draft. We
will try and address issues as we go.

In a mobile environment you have a mobile node (MN) which is not SIP aware.
But it talks to the SIP core network through a SIP Gateway which sits on the
network. The Gateway serves more than one MNs so it will run multiple UA
engines one for each of the MN's it serves. This is called a SIP Proxy UA in
the draft.

Now, when a mobile (MN) registers using non-SIP means, the Proxy UA converts
the register to a SIP Register and sends it to the registrar.

The problem really is when the MN moves from one Proxy UA to another. It
registers with the new Proxy UA, but does not de-register with the old Proxy
UA. It depends on the core network to maintain the registrations correctly
across the proxy UAs.

The draft tries to solve the problem, by having the SIP Registrar send a
notification to the old Proxy UA that the MN has moved. This is not the
normal behavior of the Registrar as someone rightly pointed out because the
Registrar is not a SIP Event server. But the registrar has all the
information it needs to send the notification. What we are suggesting is
that we decouple the NOTIFY message from the SUBSCRIBE message and allow it
to be sent in response to other methods also. Of course this raises
compatibility issues with older versions of SIP and therefore we had
suggested in the draft that the "Event" header which is currently a
mandatory header in the SUBSCRIBE method, be made optional header in other
methods like REGISTER. So only when the Registrar sees a REGISTER method
with the "Event" header, would it send NOTIFYs when the contact information
for the MN changes. Another thing to note out here is, (and this seems to
have created some confusion) the proxy UA is not subscribing for some other
party's information. It is just expecting notification of events for a MN
that it is serving so that it can clean up its resources. It can be argued
that the resource can be cleared when the registration times out, but until
that is done there are chances that the INVITEs would be forked to a proxy
UA that is not really serving the MN, and the proxy UA would end up using
precious radio resources trying to page the MN.

There was also some talk about issues with other headers, but we think we
can take the approach of using the same value for headers, as would be used
in a normal REGISTER message.

One more clarification, the draft was shown using a "presence" event, but we
feel that we could just as well use some other event - maybe a new one -
just to solve the purpose of notifying the old proxy UA that the MN has
moved.

Thanks and Regards
- Ajay

-----Original Message-----
From: Dean Willis [mailto:dean.willis@softarmor.com]
Sent: Monday, October 07, 2002 3:15 PM
To: duncan.mills@vf.vodafone.co.uk; adam@dynamicsoft.com; sip@ietf.org;
Ajaykumar Idnani; Steve Upp; Tom Hallin
Subject: RE: [Sip] Comments on draft-idnani-sip-comb-reg-subscr-00.txt


Duncan wrote:
> However, I would support a more general version of this
> draft.  For instance, the real gain I can see (as Adam says,
> this is only an optimisation, which SIPPING won't allow) is
> that one REGISTER request does the same thing as a REGISTER +
> X * SUBSCRIBE requests.  But- In the above draft, the SIP
> nodes are all in the core network anyway, so this saving is
> surely less valuable?
>
> Now, in the 3GPP situation where we send SIP messages across
> the radio interface, there is a strong requirement to save
> radio bandwidth. Additionally, we also use the
> SUBSCRIBE/NOTIFY procedures for events other than presence,
> so any kind of implicit subscription is attractive...

Perhaps I'm confused about something, but as I recall, the things in IMS
being subscibed to via SUBSCRIBE are not served from the registrar that
services the REGISTER request. In other words, the SUBSCRIBEs don't go
to the same destinations as do the REGISTERs, so combining them doesn't
seem to make a lot of sense in any case. We should have called REGISTER
something like "SETCONTACT" -- it would have avoided a lot of this
discussion.

It would seem far more effective to use a server process that aggregates
notifications and subscriptions, as is done in the "presencelist" work.
In this model one subscribes to a list served by a server, then that
server subscribes to each element of the list, aggregates state, and
filters and returns appropriate notifications to the subscriber thereby
reducing over-the-air traffic tremendously. This effectively replaces
many SUBSCRIBEs with one SUBSCRIBs, and may replace many NOTIFYs with
fewer NOTIFYs, depending on how thoseare handled.

> But isn't the problem with implicit subscription the fact
> that there is no call-id for the NOTIFY request to use?  Is
> there no way around this?

That's one problem. There are also issues with knowing how to filter
notifications and how to negotiate whether implicit subscription is
supported and lots of other things. We had not finished enumerating the
issues before deciding implicit subscriptions were just dangerous.

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

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



From mailnull@www1.ietf.org  Fri Oct 11 03:22:38 2002
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 DAA13203
	for <sip-archive@odin.ietf.org>; Fri, 11 Oct 2002 03:22:38 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9B7OP507988
	for sip-archive@odin.ietf.org; Fri, 11 Oct 2002 03:24:25 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9B7N5v07963;
	Fri, 11 Oct 2002 03:23:05 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9B7JGv07839
	for <sip@optimus.ietf.org>; Fri, 11 Oct 2002 03:19:16 -0400
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 DAA13131
	for <sip@ietf.org>; Fri, 11 Oct 2002 03:16:58 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.67])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g9B7J5YH008677;
	Fri, 11 Oct 2002 03:19:05 -0400 (EDT)
Message-ID: <3DA67B68.1080609@dynamicsoft.com>
Date: Fri, 11 Oct 2002 03:19:04 -0400
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: Idnani Ajaykumar-AIDNANI1 <Ajaykumar.Idnani@motorola.com>
CC: sip@ietf.org, Upp Steve-CSU001 <Steve.Upp@motorola.com>,
        Hallin Tom-ATH033 <thallin@motorola.com>
Subject: Re: [Sip] Comments on draft-idnani-sip-comb-reg-subscr-00.txt
References: <A5B4C9A2AD89D411AB3E009027B0DA1E05133AB1@IL27EXM09.cig.mot.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

First off, the general tact we take here is to first generate 
requirements when you want the sip group to help solve a problem for 
you. The requirements work is done in sipping if it is deemed an 
interesting problem, and then sip develops a solution.

Clearly the requirements are not well spelled out so discussion of a 
solution is moot.

A note inline.

Idnani Ajaykumar-AIDNANI1 wrote:
> All,
> 
> We have seen a lot of good comments on this draft.
> 
> So here are a few thoughts on the basic reason for writing this draft. We
> will try and address issues as we go.
> 
> In a mobile environment you have a mobile node (MN) which is not SIP aware.
> But it talks to the SIP core network through a SIP Gateway which sits on the
> network. The Gateway serves more than one MNs so it will run multiple UA
> engines one for each of the MN's it serves. This is called a SIP Proxy UA in
> the draft.
> 
> Now, when a mobile (MN) registers using non-SIP means, the Proxy UA converts
> the register to a SIP Register and sends it to the registrar.
> 
> The problem really is when the MN moves from one Proxy UA to another. It
> registers with the new Proxy UA, but does not de-register with the old Proxy
> UA. It depends on the core network to maintain the registrations correctly
> across the proxy UAs.

Well, this is the basic requirement you seem to have. The old 
registration needs to be deleted.

There are many ways to do this with existing sip. I have already 
proposed one, where the new proxy UA de-registers, and it can do this 
because of defined conventions for constructing the URI.

Another way to do this is to have the old proxy-UA de-register. You have 
proposed a new mechanism for this, to allow the old proxy-UA to know 
about the new registration so it knows when it can de-register the old. 
I, and others, have pointed out the issues with the solution you have 
proposed.

However, we already have a protocol for this:
http://www.ietf.org/internet-drafts/draft-rosenberg-sip-reg-00.txt

although it is an individual draft at the moment, it will be a working 
group item. This will allow the old proxy UA to subscribe to the 
registrar and learn of the new registration, so it can unregister the 
old one. Therefore I believe it meets your requirements.

-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

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



From mailnull@www1.ietf.org  Fri Oct 11 23:27:48 2002
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 XAA10680
	for <sip-archive@odin.ietf.org>; Fri, 11 Oct 2002 23:27:48 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9C3TXU32706
	for sip-archive@odin.ietf.org; Fri, 11 Oct 2002 23:29:33 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9C3S6v32672;
	Fri, 11 Oct 2002 23:28:06 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9C3LGv32544
	for <sip@optimus.ietf.org>; Fri, 11 Oct 2002 23:21:16 -0400
Received: from em.njupt.edu.cn (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA10561
	for <sip@ietf.org>; Fri, 11 Oct 2002 23:18:50 -0400 (EDT)
Message-Id: <200210120318.XAA10561@ietf.org>
Received: (qmail 29363 invoked from network); 12 Oct 2002 03:43:24 -0000
Received: from unknown (HELO toto) (10.10.3.123)
  by em.njupt.edu.cn with SMTP; 12 Oct 2002 03:43:24 -0000
Date: Sat, 12 Oct 2002 11:24:51 +0800
From: feng zhang <y01317@njupt.edu.cn>
Reply-To: y01317@njupt.edu.cn
To: "sip@ietf.org" <sip@ietf.org>,
        "sip-implementors@cs.columbia.edu" <sip-implementors@cs.columbia.edu>
Organization: NUPT-CED202
X-mailer: FoxMail 4.0 beta 2 [cn]
Mime-Version: 1.0
Content-Type: text/plain;
      charset="GB2312"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id g9C3LGv32545
Subject: [Sip] INVITE client transaction
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit

Hello All,
	I have a doubt about the invite client transaction describe in SIP spec.
    In RFC3261 sec. 13.2.2.4 "2xx Responses", the last but one paragraph, it says:
" The UAC core considers the INVITE transaction completed 64*T1 seconds
   after the reception of the first 2xx response.  At this point all the
   early dialogs that have not transitioned to established dialogs are
   terminated.  Once the INVITE transaction is considered completed by
   the UAC core, no more new 2xx responses are expected to arrive.
"
   My question is:
   When recieving a 2xx response, the state of invite client transaction will transition to "Terminated" State, and the inv_client_transaction should be destroyed(17.1.1.2 RFC3261).But here in 13.2.2.4 , it says " The UAC core considers the INVITE transaction completed 64*T1 seconds after the reception of the first 2xx response.". Does the UAC core keeps the inv_client_transaction ALIVE for 64*T1 seconds? 
    And I want to know what "INVITE transaction completed" means? Does it mean the transaction is destroyed?  Why here uses 64*T1 seconds?
    I am doubted about it.Thank u very much to give me a clarification.

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



From mailnull@www1.ietf.org  Sat Oct 12 04:47:55 2002
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 EAA22688
	for <sip-archive@odin.ietf.org>; Sat, 12 Oct 2002 04:47:55 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9C8ni520681
	for sip-archive@odin.ietf.org; Sat, 12 Oct 2002 04:49:44 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9C8mtv20670;
	Sat, 12 Oct 2002 04:48:55 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9C8itv20616
	for <sip@optimus.ietf.org>; Sat, 12 Oct 2002 04:44:55 -0400
Received: from hsr.ch (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22646
	for <sip@ietf.org>; Sat, 12 Oct 2002 04:42:35 -0400 (EDT)
Received: from [217.162.98.81] (account <mkonrad@hsr.ch>)
  by hsr.ch (CommuniGate Pro WebUser 3.5.9)
  with HTTP id 5166655; Sat, 12 Oct 2002 10:44:42 +0200
From: "Matthias Konrad" <mkonrad@hsr.ch>
Subject: Re: [Sip] INVITE client transaction
To: y01317@njupt.edu.cn
Cc: sip@ietf.org
X-Mailer: CommuniGate Pro Web Mailer v.3.5.9
Date: Sat, 12 Oct 2002 10:44:42 +0200
Message-ID: <web-5166655@hsr.ch>
In-Reply-To: <200210120318.XAA10561@ietf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit

Hi
You have to distinguish if you are looking at the client side INVITE process as
whole or just at the client side invite transaction.
The client side invite transaction is just cabable of acknowledgeing one 2xx
response. Of course one invite request can result
in multiple dialogs. So the UAC core has to answer further 2xx responses. He
has to do this statelessly because the 
client side invite transaction is already in the terminated state which means,
that it can be destroyed. The 64*T1 seconds
say how long the UAC core has to do this work.
Personally I agree with you that the naming here could be a bid clearer.

Greets


On Sat, 12 Oct 2002 11:24:51 +0800
 feng zhang <y01317@njupt.edu.cn> wrote:
> Hello All,
> 	I have a doubt about the invite client transaction describe in SIP spec.
>     In RFC3261 sec. 13.2.2.4 "2xx Responses", the last but one paragraph, it
> says:
> " The UAC core considers the INVITE transaction completed 64*T1 seconds
>    after the reception of the first 2xx response.  At this point all the
>    early dialogs that have not transitioned to established dialogs are
>    terminated.  Once the INVITE transaction is considered completed by
>    the UAC core, no more new 2xx responses are expected to arrive.
> "
>    My question is:
>    When recieving a 2xx response, the state of invite client transaction will
> transition to "Terminated" State, and the inv_client_transaction should be
> destroyed(17.1.1.2 RFC3261).But here in 13.2.2.4 , it says " The UAC core
> considers the INVITE transaction completed 64*T1 seconds after the reception
> of the first 2xx response.". Does the UAC core keeps the
> inv_client_transaction ALIVE for 64*T1 seconds? 
>     And I want to know what "INVITE transaction completed" means? Does it
> mean the transaction is destroyed?  Why here uses 64*T1 seconds?
>     I am doubted about it.Thank u very much to give me a clarification.
> 
> Best Regards.
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip

 _  _ ___ ___  Matthias Konrad;
| || / __| _ \ HSR Hochschule Rapperswil; Oberseestrasse 10;
| __ \__ \   / CH-8640 Rapperswil; Tel: +41 55 222 41 11;
|_||_|___/_|_\ EMAIL: mkonrad@hsr.ch; WWW: www.hsr.ch
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Mon Oct 14 01:48:01 2002
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 BAA01081
	for <sip-archive@odin.ietf.org>; Mon, 14 Oct 2002 01:48:01 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9E5non00713
	for sip-archive@odin.ietf.org; Mon, 14 Oct 2002 01:49:50 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9E5mkv00701;
	Mon, 14 Oct 2002 01:48:46 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9E5fgv00572
	for <sip@optimus.ietf.org>; Mon, 14 Oct 2002 01:41:42 -0400
Received: from hclnpd.hclt.co.in (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00952
	for <sip@ietf.org>; Mon, 14 Oct 2002 01:39:20 -0400 (EDT)
Received: from blaze.hcltech.com (blaze.hclt-ntl.co.in [192.168.19.30]) by hclnpd.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id SP907P89; Mon, 14 Oct 2002 11:11:51 +0530
Received: from sachinhome ([192.168.19.43])
	by blaze.hcltech.com (8.9.3/8.9.3) with SMTP id LAA15454
	for <sip@ietf.org>; Mon, 14 Oct 2002 11:40:58 +0530
Message-ID: <00dc01c27346$021daf40$a5f1fea9@sachinhome>
From: "Sachin Shenoy" <sachins@netlab.hcltech.com>
To: <sip@ietf.org>
Date: Mon, 14 Oct 2002 11:11:41 +0530
Organization: HCL Technologies
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0072_01C27372.793E7EC0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Subject: [Sip] Backward incompatibity in Via header grammar.
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0072_01C27372.793E7EC0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

According to bis-02 & bis-05 the grammar of Via is following.

Via =3D ( "Via" | "v" ) HCOLON

1#( sent-protocol sent-by

*( SEMI via-params ) [ comment ] )

It allows for comment to be present in Via header.



But according to the new RFC, this is the grammar,

Via =3D ( "Via" / "v" ) HCOLON via-parm *(COMMA via-parm)

Which doesn't allow for comment.



Won't this cause backward incompatablity. (Any old proxy=20

which inserts comment in Via can cause serious problems for=20

new implementation).



Thanks

Sachin




------=_NextPart_000_0072_01C27372.793E7EC0
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 http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D3>
<P align=3Dleft><FONT size=3D2>Hi,</FONT></P>
<P align=3Dleft><FONT size=3D2>According to bis-02 &amp; bis-05 the =
grammar of Via=20
is following.</FONT></P>
<P align=3Dleft>Via =3D ( "Via"&nbsp;|</FONT><I><FONT face=3DCMSY10 =
size=3D3>=20
</I></FONT><FONT face=3DArial size=3D3>"v" ) HCOLON</P>
<P align=3Dleft>1#( sent-protocol sent-by</P>
<P align=3Dleft>*( SEMI via-params ) [ comment ] )</P><FONT size=3D2>
<P align=3Dleft><FONT size=3D2>It allows for comment to be present in =
Via=20
header.</FONT></P>
<P align=3Dleft>&nbsp;</P></FONT>
<P align=3Dleft><FONT size=3D2>But according to the new RFC, this is the =

grammar,</FONT></P>
<P align=3Dleft><FONT size=3D2>Via =3D ( "Via" / "v" ) HCOLON via-parm =
*(COMMA=20
via-parm)</P>
<P>Which doesn't allow for comment.</P>
<P>&nbsp;</P>
<P>Won't this cause backward incompatablity. (Any old proxy </P>
<P>which inserts comment in Via can cause serious problems for </P>
<P>new implementation).</P>
<P>&nbsp;</P>
<P>Thanks</P>
<P>Sachin</P>
<P>&nbsp;</P></FONT></FONT></DIV></BODY></HTML>

------=_NextPart_000_0072_01C27372.793E7EC0--

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



From mailnull@www1.ietf.org  Mon Oct 14 07:36:56 2002
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 HAA15012
	for <sip-archive@odin.ietf.org>; Mon, 14 Oct 2002 07:36:56 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9EBcaj26514
	for sip-archive@odin.ietf.org; Mon, 14 Oct 2002 07:38:36 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EBbjv26445;
	Mon, 14 Oct 2002 07:37:45 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EBagv25839
	for <sip@optimus.ietf.org>; Mon, 14 Oct 2002 07:36:42 -0400
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 HAA14968
	for <sip@ietf.org>; Mon, 14 Oct 2002 07:34:29 -0400 (EDT)
Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57])
	by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g9EBaci27004
	for <sip@ietf.org>; Mon, 14 Oct 2002 07:36:38 -0400 (EDT)
Received: by en0060D057.uk.lucent.com with Internet Mail Service (5.5.2653.19)
	id <TYBQWP4K>; Mon, 14 Oct 2002 12:36:37 +0100
Message-ID: <475FF955A05DD411980D00508B6D5FB00636B7F2@en0033exch001u.uk.lucent.com>
From: "Drage, Keith (Keith)" <drage@lucent.com>
To: Sachin Shenoy <sachins@netlab.hcltech.com>, sip@ietf.org
Subject: RE: [Sip] Backward incompatibity in Via header grammar.
Date: Mon, 14 Oct 2002 12:36:35 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C27375.F3849CFC"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-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_01C27375.F3849CFC
Content-Type: text/plain;
	charset="iso-8859-1"

Backward compatibility or incompatibility is assessed against previously published versions of the RFCs, i.e. RFC 2543 to RFC 3261.
 
Compatibility problems with anyone who implements an internet draft, i.e. work in progress, lie with whoever decided not to wait for the published RFC.
 
However the BNF you quote does appear in RFC 2543. I do not know the reason why it was removed, but I would note that there has been a general cleaning up of comment usage throughout RFC 3261 from RFC 2543, and not in this header alone.
 
Keith
 

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

-----Original Message-----
From: Sachin Shenoy [mailto:sachins@netlab.hcltech.com]
Sent: 14 October 2002 06:42
To: sip@ietf.org
Subject: [Sip] Backward incompatibity in Via header grammar.


Hi,

According to bis-02 & bis-05 the grammar of Via is following.

Via = ( "Via" | "v" ) HCOLON

1#( sent-protocol sent-by

*( SEMI via-params ) [ comment ] )

It allows for comment to be present in Via header.

 

But according to the new RFC, this is the grammar,

Via = ( "Via" / "v" ) HCOLON via-parm *(COMMA via-parm)

Which doesn't allow for comment.

 

Won't this cause backward incompatablity. (Any old proxy 

which inserts comment in Via can cause serious problems for 

new implementation).

 

Thanks

Sachin

 


------_=_NextPart_001_01C27375.F3849CFC
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.50.4919.2200" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><SPAN class=707013310-14102002><FONT face=Arial color=#0000ff 
size=2>Backward compatibility or incompatibility is assessed against previously 
published versions of the RFCs, i.e. RFC 2543 to RFC 3261.</FONT></SPAN></DIV>
<DIV><SPAN class=707013310-14102002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=707013310-14102002><FONT face=Arial color=#0000ff 
size=2>Compatibility problems with anyone who implements an internet draft, i.e. 
work in progress, lie with whoever decided not to wait for the published 
RFC.</FONT></SPAN></DIV>
<DIV><SPAN class=707013310-14102002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=707013310-14102002><FONT face=Arial color=#0000ff 
size=2>However the BNF you quote does appear in RFC 2543. I do not know the 
reason why it was removed, but I would note that there has been a general 
cleaning up of comment usage throughout RFC 3261 from RFC 2543, and not in this 
header alone.</FONT></SPAN></DIV>
<DIV><SPAN class=707013310-14102002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=707013310-14102002><FONT face=Arial color=#0000ff 
size=2>Keith</FONT></SPAN></DIV>
<DIV>&nbsp;</DIV>
<P><FONT size=2>Keith Drage<BR>Lucent Technologies<BR>Tel: +44 1793 
776249<BR>Email: drage@lucent.com </FONT></P>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Sachin Shenoy 
  [mailto:sachins@netlab.hcltech.com]<BR><B>Sent:</B> 14 October 2002 
  06:42<BR><B>To:</B> sip@ietf.org<BR><B>Subject:</B> [Sip] Backward 
  incompatibity in Via header grammar.<BR><BR></FONT></DIV>
  <DIV><FONT face=Arial size=3>
  <P align=left><FONT size=2>Hi,</FONT></P>
  <P align=left><FONT size=2>According to bis-02 &amp; bis-05 the grammar of Via 
  is following.</FONT></P>
  <P align=left>Via = ( "Via"&nbsp;|</FONT><I><FONT face=CMSY10 size=3> 
  </I></FONT><FONT face=Arial size=3>"v" ) HCOLON</P>
  <P align=left>1#( sent-protocol sent-by</P>
  <P align=left>*( SEMI via-params ) [ comment ] )</P><FONT size=2>
  <P align=left><FONT size=2>It allows for comment to be present in Via 
  header.</FONT></P>
  <P align=left>&nbsp;</P></FONT>
  <P align=left><FONT size=2>But according to the new RFC, this is the 
  grammar,</FONT></P>
  <P align=left><FONT size=2>Via = ( "Via" / "v" ) HCOLON via-parm *(COMMA 
  via-parm)</P>
  <P>Which doesn't allow for comment.</P>
  <P>&nbsp;</P>
  <P>Won't this cause backward incompatablity. (Any old proxy </P>
  <P>which inserts comment in Via can cause serious problems for </P>
  <P>new implementation).</P>
  <P>&nbsp;</P>
  <P>Thanks</P>
  <P>Sachin</P>
  <P>&nbsp;</P></FONT></FONT></DIV></BLOCKQUOTE></BODY></HTML>

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



From mailnull@www1.ietf.org  Mon Oct 14 07:37:15 2002
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 HAA15025
	for <sip-archive@odin.ietf.org>; Mon, 14 Oct 2002 07:37:15 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9EBctm26536
	for sip-archive@odin.ietf.org; Mon, 14 Oct 2002 07:38:55 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EBbuv26478;
	Mon, 14 Oct 2002 07:37:56 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EBagv25841
	for <sip@optimus.ietf.org>; Mon, 14 Oct 2002 07:36:42 -0400
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 HAA14969
	for <sip@ietf.org>; Mon, 14 Oct 2002 07:34:30 -0400 (EDT)
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 g9EBac120890
	for <sip@ietf.org>; Mon, 14 Oct 2002 07:36:38 -0400 (EDT)
Received: by en0060D057.uk.lucent.com with Internet Mail Service (5.5.2653.19)
	id <TYBQWP4N>; Mon, 14 Oct 2002 12:36:37 +0100
Message-ID: <475FF955A05DD411980D00508B6D5FB00636B7F4@en0033exch001u.uk.lucent.com>
From: "Drage, Keith (Keith)" <drage@lucent.com>
To: ranjit.avasarala@bplmail.com,
        Idnani Ajaykumar-AIDNANI1
	 <Ajaykumar.Idnani@motorola.com>
Cc: Sip-Ietf <sip@ietf.org>
Subject: RE: [Sip] Comments on draft-idnani-sip-comb-reg-subscr-00.txt
Date: Mon, 14 Oct 2002 12:36:35 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

3GPP currently addresses this by each entity that desires knowledge of the registration status sending a SUBSCRIBE request to the registrar for the reg event package. This does result in a large number of SUBSCRIBE messages being sent in parallel to REGISTER messages, but this is certainly what will occur in the current approved release.

I understand that the object of the proposal being discussed was to reduce the number of SUBSCRIBE requests in like scenarios like the 3GPP one by creating an implicit subscription, but that does not form part of any 3GPP drafts at the moment.



Keith

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

> -----Original Message-----
> From: RANJIT [mailto:ranjit.avasarala@bplmail.com]
> Sent: 11 October 2002 04:50
> To: Idnani Ajaykumar-AIDNANI1
> Cc: Sip-Ietf
> Subject: RE: [Sip] Comments on draft-idnani-sip-comb-reg-subscr-00.txt
> 
> 
> Hi
>    I think the 3GPP's document on Internet Multimedia 
> SubSystem already
> addresses this topic of SIP aware mobile nodes. There the Registrar is
> S-CSCF.
> 
> so here each mobile node registers to theS-CSCF in its Home Network.
> 
> so how is this draft from the 3GPP specification?
> 
> Ranjit :-)
> 
> -----Original Message-----
> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf 
> Of Idnani
> Ajaykumar-AIDNANI1
> Sent: Friday, October 11, 2002 12:43 AM
> To: sip@ietf.org; Upp Steve-CSU001; Hallin Tom-ATH033
> Subject: RE: [Sip] Comments on draft-idnani-sip-comb-reg-subscr-00.txt
> 
> 
> All,
> 
> We have seen a lot of good comments on this draft.
> 
> So here are a few thoughts on the basic reason for writing 
> this draft. We
> will try and address issues as we go.
> 
> In a mobile environment you have a mobile node (MN) which is 
> not SIP aware.
> But it talks to the SIP core network through a SIP Gateway 
> which sits on the
> network. The Gateway serves more than one MNs so it will run 
> multiple UA
> engines one for each of the MN's it serves. This is called a 
> SIP Proxy UA in
> the draft.
> 
> Now, when a mobile (MN) registers using non-SIP means, the 
> Proxy UA converts
> the register to a SIP Register and sends it to the registrar.
> 
> The problem really is when the MN moves from one Proxy UA to 
> another. It
> registers with the new Proxy UA, but does not de-register 
> with the old Proxy
> UA. It depends on the core network to maintain the 
> registrations correctly
> across the proxy UAs.
> 
> The draft tries to solve the problem, by having the SIP 
> Registrar send a
> notification to the old Proxy UA that the MN has moved. This 
> is not the
> normal behavior of the Registrar as someone rightly pointed 
> out because the
> Registrar is not a SIP Event server. But the registrar has all the
> information it needs to send the notification. What we are 
> suggesting is
> that we decouple the NOTIFY message from the SUBSCRIBE 
> message and allow it
> to be sent in response to other methods also. Of course this raises
> compatibility issues with older versions of SIP and therefore we had
> suggested in the draft that the "Event" header which is currently a
> mandatory header in the SUBSCRIBE method, be made optional 
> header in other
> methods like REGISTER. So only when the Registrar sees a 
> REGISTER method
> with the "Event" header, would it send NOTIFYs when the 
> contact information
> for the MN changes. Another thing to note out here is, (and 
> this seems to
> have created some confusion) the proxy UA is not subscribing 
> for some other
> party's information. It is just expecting notification of 
> events for a MN
> that it is serving so that it can clean up its resources. It 
> can be argued
> that the resource can be cleared when the registration times 
> out, but until
> that is done there are chances that the INVITEs would be 
> forked to a proxy
> UA that is not really serving the MN, and the proxy UA would 
> end up using
> precious radio resources trying to page the MN.
> 
> There was also some talk about issues with other headers, but 
> we think we
> can take the approach of using the same value for headers, as 
> would be used
> in a normal REGISTER message.
> 
> One more clarification, the draft was shown using a 
> "presence" event, but we
> feel that we could just as well use some other event - maybe 
> a new one -
> just to solve the purpose of notifying the old proxy UA that 
> the MN has
> moved.
> 
> Thanks and Regards
> - Ajay
> 
> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]
> Sent: Monday, October 07, 2002 3:15 PM
> To: duncan.mills@vf.vodafone.co.uk; adam@dynamicsoft.com; 
> sip@ietf.org;
> Ajaykumar Idnani; Steve Upp; Tom Hallin
> Subject: RE: [Sip] Comments on draft-idnani-sip-comb-reg-subscr-00.txt
> 
> 
> Duncan wrote:
> > However, I would support a more general version of this
> > draft.  For instance, the real gain I can see (as Adam says,
> > this is only an optimisation, which SIPPING won't allow) is
> > that one REGISTER request does the same thing as a REGISTER +
> > X * SUBSCRIBE requests.  But- In the above draft, the SIP
> > nodes are all in the core network anyway, so this saving is
> > surely less valuable?
> >
> > Now, in the 3GPP situation where we send SIP messages across
> > the radio interface, there is a strong requirement to save
> > radio bandwidth. Additionally, we also use the
> > SUBSCRIBE/NOTIFY procedures for events other than presence,
> > so any kind of implicit subscription is attractive...
> 
> Perhaps I'm confused about something, but as I recall, the 
> things in IMS
> being subscibed to via SUBSCRIBE are not served from the 
> registrar that
> services the REGISTER request. In other words, the SUBSCRIBEs don't go
> to the same destinations as do the REGISTERs, so combining 
> them doesn't
> seem to make a lot of sense in any case. We should have 
> called REGISTER
> something like "SETCONTACT" -- it would have avoided a lot of this
> discussion.
> 
> It would seem far more effective to use a server process that 
> aggregates
> notifications and subscriptions, as is done in the 
> "presencelist" work.
> In this model one subscribes to a list served by a server, then that
> server subscribes to each element of the list, aggregates state, and
> filters and returns appropriate notifications to the 
> subscriber thereby
> reducing over-the-air traffic tremendously. This effectively replaces
> many SUBSCRIBEs with one SUBSCRIBs, and may replace many NOTIFYs with
> fewer NOTIFYs, depending on how thoseare handled.
> 
> > But isn't the problem with implicit subscription the fact
> > that there is no call-id for the NOTIFY request to use?  Is
> > there no way around this?
> 
> That's one problem. There are also issues with knowing how to filter
> notifications and how to negotiate whether implicit subscription is
> supported and lots of other things. We had not finished 
> enumerating the
> issues before deciding implicit subscriptions were just dangerous.
> 
> --
> Dean
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Mon Oct 14 07:46:50 2002
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 HAA15445
	for <sip-archive@odin.ietf.org>; Mon, 14 Oct 2002 07:46:50 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9EBmU126918
	for sip-archive@odin.ietf.org; Mon, 14 Oct 2002 07:48:30 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EBlDv26869;
	Mon, 14 Oct 2002 07:47:13 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EBkfv26809
	for <sip@optimus.ietf.org>; Mon, 14 Oct 2002 07:46:41 -0400
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 HAA15227
	for <sip@ietf.org>; Mon, 14 Oct 2002 07:44:29 -0400 (EDT)
Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57])
	by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g9EBkci29884
	for <sip@ietf.org>; Mon, 14 Oct 2002 07:46:38 -0400 (EDT)
Received: by en0060D057.uk.lucent.com with Internet Mail Service (5.5.2653.19)
	id <TYBQWP5Y>; Mon, 14 Oct 2002 12:46:37 +0100
Message-ID: <475FF955A05DD411980D00508B6D5FB00636B7F9@en0033exch001u.uk.lucent.com>
From: "Drage, Keith (Keith)" <drage@lucent.com>
To: sip@ietf.org
Date: Mon, 14 Oct 2002 12:46:36 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sip] Status of sec-agree draft
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

I gather there are some problems being raised during the security review of the sec-agree draft, which may mean this draft will not go forward.

If there are such problems, can we have them brought to the list so we can all participate in the discussions, rather than have such discussions buried away in the corner.

After all this is a working group item which has completed last call.

Keith

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



From mailnull@www1.ietf.org  Mon Oct 14 09:41:59 2002
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 JAA19889
	for <sip-archive@odin.ietf.org>; Mon, 14 Oct 2002 09:41:59 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9EDhdU32701
	for sip-archive@odin.ietf.org; Mon, 14 Oct 2002 09:43:39 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EDgxv32676;
	Mon, 14 Oct 2002 09:42:59 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EAi3v24032
	for <sip@optimus.ietf.org>; Mon, 14 Oct 2002 06:44:03 -0400
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 GAA13991
	for <sip@ietf.org>; Mon, 14 Oct 2002 06:41:52 -0400 (EDT)
Received: from jku07.fokus.fraunhofer.de (port-212-202-171-89.reverse.qdsl-home.de [212.202.171.89])
	by fox.iptel.org (8.11.6/8.11.6) with ESMTP id g9EAhbn22280;
	Mon, 14 Oct 2002 12:43:40 +0200
Message-Id: <5.1.0.14.0.20021014124106.0354ece8@mailhost.fokus.gmd.de>
X-Sender: jku@mailhost.fokus.gmd.de
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 14 Oct 2002 12:43:35 +0200
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        Jiri Kuthan <jiri.kuthan@fokus.gmd.de>
From: Jiri Kuthan <jiri.kuthan@fokus.fraunhofer.de>
Subject: Re: [Sip] Retransmission of INVITEs
Cc: Igor Slepchin <ISlepchin@dynamicsoft.com>,
        "'Jiri Kuthan'" <jiri.kuthan@fokus.gmd.de>,
        "'Jiri Kuthan'" <jiri@iptel.org>, Medhavi Bhatia <mbhatia@nextone.com>,
        James Undery <jundery@ubiquity.net>, "SIP (E-mail)" <sip@ietf.org>
In-Reply-To: <3DA3C2DE.60404@dynamicsoft.com>
References: <5.1.0.14.0.20021004221532.03e50f20@mailhost.fokus.gmd.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

Hard to parse -- what are you exactly proposing to solve 
lost UDP/INVITE?

Thanks,

-Jiri

At 07:47 AM 10/9/2002, Jonathan Rosenberg wrote:


>Jiri Kuthan wrote:
>
>>>In any case, if the application is really concerned about this kind of
>>>failures, I think it can retransmit INVITEs even after a 100: 
>>
>>I agree as for implementations -- that breaks nothing and you can label your implementation as "added-value reliability UAC" ;-)
>>As for the specification, the INVITE UAC state machine simply
>>ignores this case. That's why it was raised on [sip] and not
>>[sip-implementers] and deserves IMHO an improvement.
>
>Well, it doesnt ignore it - it merely lumps it into another case (called party never answers) which requires the UAC at some point to give up and cancel. So, there is a call failure here when possibly there need not be. Thats not a bug in the spec, its a potential new feature if you want to add support for it.
>
>Anyway, nitpicks like that aside, there are some side effects to the proposed solution. Presumably, on retransmitting the INVITE and getting a failure, the client would try a backup server. Now, the problem is that the client cannot distinguish the case where the proxy failed before proxying the request, or after (but in both cases, before a final response or non-100 1xx). If it fails after proxying, trying a backup effectively results in a forked request. This can have unintended consequences. In a PSTN termination case, two PSTN gateways might get copies of the forked INVITE and then both make calls into the PSTN. If these happen to be for an 800 number or multiline call, you end up with potentially two calls created. Granted, one of them should be cancelled, but this is still undesirable behavior.
>
>My other concern is that the solution is UDP specific, and doesn't work for TCP. If we want to support this failure case for TCP, and we further assume failures without graceful closing of the connection, the client won't detect the failure as Henning pointed out. We could retransmit the INVITE on the TCP connection (yuck!), which is effectively like implementing application layer keepalives over TCP. I wonder what is the issue with TCP keepalives that make them infrequently used?
>
>Also, the retransmits over UDP exacerbate the bandwidth consumption of SIP for the common case where there is no failure. I guess this is not too bad if you stop retransmitting after non-100 1xx...
>
>-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

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



From mailnull@www1.ietf.org  Mon Oct 14 14:43:34 2002
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 OAA29325
	for <sip-archive@odin.ietf.org>; Mon, 14 Oct 2002 14:43:34 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9EIjI117067
	for sip-archive@odin.ietf.org; Mon, 14 Oct 2002 14:45:18 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EIiYv17028;
	Mon, 14 Oct 2002 14:44:34 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EIgxv16957
	for <sip@optimus.ietf.org>; Mon, 14 Oct 2002 14:42:59 -0400
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 OAA29270
	for <sip@ietf.org>; Mon, 14 Oct 2002 14:40:44 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id g9EIjEXi022153;
	Mon, 14 Oct 2002 13:45:15 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: "'Drage, Keith \(Keith\)'" <drage@lucent.com>, <sip@ietf.org>
Subject: RE: [Sip] Status of sec-agree draft
Date: Mon, 14 Oct 2002 13:42:45 -0500
Message-ID: <002301c273b1$7d0488d0$fe0c0c42@TXDWILLIS2>
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
X-Mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <475FF955A05DD411980D00508B6D5FB00636B7F9@en0033exch001u.uk.lucent.com>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit


That's a good suggestion, and I'd like to second it. The more we all
learn about the sorts of questions raised during security reviews, the
less likely we are to raise similar questions with further work.

--
Dean


> -----Original Message-----
> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On 
> Behalf Of Drage, Keith (Keith)
> Sent: Monday, October 14, 2002 6:47 AM
> To: sip@ietf.org
> Subject: [Sip] Status of sec-agree draft
> 
> 
> I gather there are some problems being raised during the 
> security review of the sec-agree draft, which may mean this 
> draft will not go forward.
> 
> If there are such problems, can we have them brought to the 
> list so we can all participate in the discussions, rather 
> than have such discussions buried away in the corner.
> 
> After all this is a working group item which has completed last call.
> 
> Keith
> 
> Keith Drage
> Lucent Technologies
> Tel: +44 1793 776249
> Email: drage@lucent.com 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current 
> sip Use sipping@ietf.org for new developments on the 
> application of sip
> 
> 

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



From mailnull@www1.ietf.org  Mon Oct 14 18:25:45 2002
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 SAA04537
	for <sip-archive@odin.ietf.org>; Mon, 14 Oct 2002 18:25:45 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9EMRV628581
	for sip-archive@odin.ietf.org; Mon, 14 Oct 2002 18:27:31 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EMQjv28527;
	Mon, 14 Oct 2002 18:26:45 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EMP7v28452
	for <sip@optimus.ietf.org>; Mon, 14 Oct 2002 18:25:07 -0400
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 SAA04290
	for <sip@ietf.org>; Mon, 14 Oct 2002 18:22:50 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id g9EMRPXi023333;
	Mon, 14 Oct 2002 17:27:25 -0500
From: "Dean Willis" <dwillis@dynamicsoft.com>
To: <sip@ietf.org>
Cc: <mankin@isi.edu>
Date: Mon, 14 Oct 2002 17:24:51 -0500
Message-ID: <005f01c273d0$837e00a0$fe0c0c42@TXDWILLIS2>
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
X-Mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Content-Transfer-Encoding: 7bit
Subject: [Sip] Record-Route, Path, Service Route, and Multi-Homed Proxies
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit


On the weird bits about SIP has always been "how to deal with
multi-homed proxies". This has begun to raise a mess of problems with
Path, Service-route, and a few other things I consider important (like
security).

Background
-----------

By multi-homed, I mean connected, like a router, to two or more
different networks, with an interface into each network, such that
traffic comes "in" one network and goes "out" a different one.

A simple model is shown here:


         /------- \         /------------\
        |   net1   |       |     net2    |
UA1-----| 10.1.1.0 |---P---| 192.168.1.0 |-----UA2
.2      | /25      | .1 .1 |  /24        |     .2
         \------- /         \------------/


UA1 has one interface with IP address 10.1.1.2

P has two interfaces and two addresses
	-- 10.1.1.1
	-- 192.168.2.1

And UA has one onterface and 1 address, 192.168.2.2


In other words, there IS no IP level route between UA1 and UA2. No ping.
No traceroute. They live in entirely different networks.

But they can still exchange SIP, because P is a  SIP Proxy.

This works in SIP because P can record-route. 

-- On a request from UA1 (say, INVITE), toward UA2 adds its interface
(the one facing UA2) to the Record-Route header field. 

-- UA2 stores the set of Record-Route header field values in case it
wants to send a request trhough P to UA1 later.

-- UA2 replies to the request, including the received Record-Route
header field.

-- P edits the record-route header field value corresponding to its
interface facing UA2 and changes it to have the addressing value
associated with its interface facing UA1. This little blurb is buried
way down in the SIP spec -- we really don't talk about multihomed
proxies very much.

-- UA1 stores the Record-Route header field values in case it ever wants
to talk to UA2 again.

The stored record-Route header field values are later used to construct
Route header fields, which are inserted in furture requests (such as
BYE).

So far, so good. It works.

But there has been an odd thing: the route, as seen by UA1, is entirely
different from the route as seen by UA2.

-- UA1 stored a route of 10.1.1.1
-- UA2 stored a route of 192.168.2.1

This odd thing has two serious implications:

1) UA2 cannot sign the route set, because it gets edited by P in the
response. Consequently, end-to-end protection of the route set can not
be supported by the protocol. We've just broken the openness principle
and the end-to-end principle. Oops.

2) P must implement special "multihomed" logic. On the request phase, it
goes through output interface calculation and writes the output
interface into the route. It must then inspect all responses, grep for
an input interface, and selectively edit them to reference the correct
output interface. This is a CPU drag. 


Implications for Path and Service-Route
---------------------------------------

As currently written, the Path header field accumulates in the same
manner as Record-Route. It gets written on the request. The Path draft
doesn't say what happens for a multi-homed host, so we assume it works
like Record-Route (it does say that), so it gets set to the interface
facing the registrar. This works just fine for the documented purpose of
path, finding the route from the registrar back to the UA.

But, people want to use the Path to calculate the route from the UA to a
service proxy associated with the registrar (Service-Route). Since only
the interfaces facing the registar are stored in Path, we have to use
configured information about the network to guess what the "other" side
might be. This is not all that useful -- it requires lots of tricky
configuration. Tricky configuration is BAD when we have an alternative.

One proposal is to let P edit Service-Route on the return stroke, just
like Record-Route. This would probably work, but conflicts with the
security requirements on Service-Route, requries special behavior in P,
and so forth. In other words, its bad for all the same reasons that the
Record-Route processing is bad, and then some.



Suggestion -- Symmetrize the Route with In-Out Record-Routing
-------------------------------------------------------------

What if proxies doing record-routing inserted a Record-Route header
field value for the receiving interface, and iff the sending interface
were different, inserted another Record-Route header field value for the
sending interface?

In the case of our example, P would add both 10.1.1.1 and 192.168.2.1

The result as I see it:

1) All routes would be fully symmetric -- that is, the route from UA1 to
UA2 would be the exact inverse of the route from UA2 to UA1

2) Service-Route could be derived directly from Path

3) End-to-end protection could be used for Record-Route and Path and
Service-Route 

4) P would, executing normal loose-routing logic, see each request twice
-- that is, it would pop the recieving interface, send the result to the
next hop (in this case the outgoing interface), then process again,
popping the outgoing interface and passing the request on. Of course,
the application logic in P COULD be enhanced to prevent double
processing. After all, we really haven't said a whole lot about how a
multi-homed proxy really works in the SIP specs so far.

5) Routes would be slightly larger, as they would carry information
about both sides of a multihomed proxy.

6) Path could continue to work as currently specfied, save for a
reference that multihomed proxies supporting Path should also do "In-Out
Record-Routing"

7) Service-Route could work as desired, provided it also require
supporting proxies to use In-Out Record-Routing

8) Response processing in a proxy becomes transparent. Everything tricky
is done in the request processing phase. Reponse processing just adds
another outer compare and pop.

I THINK the described behavior would be highly backward compatible,
requiring changes only in multihomed proxies supporting the new
behaviors.

Path Forward:

If nobody convinces me this is just a freaking bad idea, I propose to
document the record-route behavior in a new draft, and edit the
Service-Route draft to reference the behavior and describe how to
generate service-routes from record-routes. I believe all the
implications for Path (currently in rfc-ed queue) can be handled
entirely within the Service Route draft.



--
Dean







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



From mailnull@www1.ietf.org  Mon Oct 14 19:50:57 2002
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 TAA05873
	for <sip-archive@odin.ietf.org>; Mon, 14 Oct 2002 19:50:57 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9ENqhu32495
	for sip-archive@odin.ietf.org; Mon, 14 Oct 2002 19:52:43 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ENqLv32487;
	Mon, 14 Oct 2002 19:52:21 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ENoFv32440
	for <sip@optimus.ietf.org>; Mon, 14 Oct 2002 19:50:15 -0400
Received: from f1ee40-19.idc1.level3.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05855
	for <sip@ietf.org>; Mon, 14 Oct 2002 19:47:57 -0400 (EDT)
From: John.Hearty@Level3.com
Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1])
	by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id XAA25689;
	Mon, 14 Oct 2002 23:50:07 GMT
Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2656.59)
	id <RW752X5H>; Mon, 14 Oct 2002 17:50:07 -0600
Message-ID: <3DB099919328BA41905F651A6EF8397605C3C6@idc1exc0004.corp.global.level3.com>
To: dwillis@dynamicsoft.com, sip@ietf.org
Cc: mankin@isi.edu
Subject: RE: [Sip] Record-Route, Path, Service Route, and Multi-Homed Prox
	ies
Date: Mon, 14 Oct 2002 17:50:03 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

As I recall, I've already seen at least one vendor doing it the way you
proposed, and it seemed to work OK.

John Hearty
Level3

> -----Original Message-----
> From: Dean Willis [mailto:dwillis@dynamicsoft.com]
> Sent: Monday, October 14, 2002 4:25 PM
> To: sip@ietf.org
> Cc: mankin@isi.edu
> Subject: [Sip] Record-Route, Path, Service Route, and Multi-Homed
> Proxies
> 
> 
> 
> On the weird bits about SIP has always been "how to deal with
> multi-homed proxies". This has begun to raise a mess of problems with
> Path, Service-route, and a few other things I consider important (like
> security).
> 
> Background
> -----------
> 
> By multi-homed, I mean connected, like a router, to two or more
> different networks, with an interface into each network, such that
> traffic comes "in" one network and goes "out" a different one.
> 
> A simple model is shown here:
> 
> 
>          /------- \         /------------\
>         |   net1   |       |     net2    |
> UA1-----| 10.1.1.0 |---P---| 192.168.1.0 |-----UA2
> .2      | /25      | .1 .1 |  /24        |     .2
>          \------- /         \------------/
> 
> 
> UA1 has one interface with IP address 10.1.1.2
> 
> P has two interfaces and two addresses
> 	-- 10.1.1.1
> 	-- 192.168.2.1
> 
> And UA has one onterface and 1 address, 192.168.2.2
> 
> 
> In other words, there IS no IP level route between UA1 and 
> UA2. No ping.
> No traceroute. They live in entirely different networks.
> 
> But they can still exchange SIP, because P is a  SIP Proxy.
> 
> This works in SIP because P can record-route. 
> 
> -- On a request from UA1 (say, INVITE), toward UA2 adds its interface
> (the one facing UA2) to the Record-Route header field. 
> 
> -- UA2 stores the set of Record-Route header field values in case it
> wants to send a request trhough P to UA1 later.
> 
> -- UA2 replies to the request, including the received Record-Route
> header field.
> 
> -- P edits the record-route header field value corresponding to its
> interface facing UA2 and changes it to have the addressing value
> associated with its interface facing UA1. This little blurb is buried
> way down in the SIP spec -- we really don't talk about multihomed
> proxies very much.
> 
> -- UA1 stores the Record-Route header field values in case it 
> ever wants
> to talk to UA2 again.
> 
> The stored record-Route header field values are later used to 
> construct
> Route header fields, which are inserted in furture requests (such as
> BYE).
> 
> So far, so good. It works.
> 
> But there has been an odd thing: the route, as seen by UA1, 
> is entirely
> different from the route as seen by UA2.
> 
> -- UA1 stored a route of 10.1.1.1
> -- UA2 stored a route of 192.168.2.1
> 
> This odd thing has two serious implications:
> 
> 1) UA2 cannot sign the route set, because it gets edited by P in the
> response. Consequently, end-to-end protection of the route set can not
> be supported by the protocol. We've just broken the openness principle
> and the end-to-end principle. Oops.
> 
> 2) P must implement special "multihomed" logic. On the 
> request phase, it
> goes through output interface calculation and writes the output
> interface into the route. It must then inspect all responses, grep for
> an input interface, and selectively edit them to reference the correct
> output interface. This is a CPU drag. 
> 
> 
> Implications for Path and Service-Route
> ---------------------------------------
> 
> As currently written, the Path header field accumulates in the same
> manner as Record-Route. It gets written on the request. The Path draft
> doesn't say what happens for a multi-homed host, so we assume it works
> like Record-Route (it does say that), so it gets set to the interface
> facing the registrar. This works just fine for the documented 
> purpose of
> path, finding the route from the registrar back to the UA.
> 
> But, people want to use the Path to calculate the route from 
> the UA to a
> service proxy associated with the registrar (Service-Route). 
> Since only
> the interfaces facing the registar are stored in Path, we have to use
> configured information about the network to guess what the 
> "other" side
> might be. This is not all that useful -- it requires lots of tricky
> configuration. Tricky configuration is BAD when we have an 
> alternative.
> 
> One proposal is to let P edit Service-Route on the return stroke, just
> like Record-Route. This would probably work, but conflicts with the
> security requirements on Service-Route, requries special 
> behavior in P,
> and so forth. In other words, its bad for all the same 
> reasons that the
> Record-Route processing is bad, and then some.
> 
> 
> 
> Suggestion -- Symmetrize the Route with In-Out Record-Routing
> -------------------------------------------------------------
> 
> What if proxies doing record-routing inserted a Record-Route header
> field value for the receiving interface, and iff the sending interface
> were different, inserted another Record-Route header field 
> value for the
> sending interface?
> 
> In the case of our example, P would add both 10.1.1.1 and 192.168.2.1
> 
> The result as I see it:
> 
> 1) All routes would be fully symmetric -- that is, the route 
> from UA1 to
> UA2 would be the exact inverse of the route from UA2 to UA1
> 
> 2) Service-Route could be derived directly from Path
> 
> 3) End-to-end protection could be used for Record-Route and Path and
> Service-Route 
> 
> 4) P would, executing normal loose-routing logic, see each 
> request twice
> -- that is, it would pop the recieving interface, send the 
> result to the
> next hop (in this case the outgoing interface), then process again,
> popping the outgoing interface and passing the request on. Of course,
> the application logic in P COULD be enhanced to prevent double
> processing. After all, we really haven't said a whole lot about how a
> multi-homed proxy really works in the SIP specs so far.
> 
> 5) Routes would be slightly larger, as they would carry information
> about both sides of a multihomed proxy.
> 
> 6) Path could continue to work as currently specfied, save for a
> reference that multihomed proxies supporting Path should also 
> do "In-Out
> Record-Routing"
> 
> 7) Service-Route could work as desired, provided it also require
> supporting proxies to use In-Out Record-Routing
> 
> 8) Response processing in a proxy becomes transparent. 
> Everything tricky
> is done in the request processing phase. Reponse processing just adds
> another outer compare and pop.
> 
> I THINK the described behavior would be highly backward compatible,
> requiring changes only in multihomed proxies supporting the new
> behaviors.
> 
> Path Forward:
> 
> If nobody convinces me this is just a freaking bad idea, I propose to
> document the record-route behavior in a new draft, and edit the
> Service-Route draft to reference the behavior and describe how to
> generate service-routes from record-routes. I believe all the
> implications for Path (currently in rfc-ed queue) can be handled
> entirely within the Service Route draft.
> 
> 
> 
> --
> Dean
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Mon Oct 14 20:27:16 2002
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 UAA06276
	for <sip-archive@odin.ietf.org>; Mon, 14 Oct 2002 20:27:16 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9F0T3501337
	for sip-archive@odin.ietf.org; Mon, 14 Oct 2002 20:29:03 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9F0SZv01314;
	Mon, 14 Oct 2002 20:28:35 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9F0Rtv01284
	for <sip@optimus.ietf.org>; Mon, 14 Oct 2002 20:27:55 -0400
Received: from web20710.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA06247
	for <sip@ietf.org>; Mon, 14 Oct 2002 20:25:36 -0400 (EDT)
Message-ID: <20021015002746.31466.qmail@web20710.mail.yahoo.com>
Received: from [131.107.3.86] by web20710.mail.yahoo.com via HTTP; Mon, 14 Oct 2002 17:27:46 PDT
Date: Mon, 14 Oct 2002 17:27:46 -0700 (PDT)
From: Sean Olson <seancolson@yahoo.com>
Subject: RE: [Sip] Record-Route, Path, Service Route, and Multi-Homed Prox ies
To: John.Hearty@level3.com, dwillis@dynamicsoft.com, sip@ietf.org
Cc: mankin@isi.edu
In-Reply-To: <3DB099919328BA41905F651A6EF8397605C3C6@idc1exc0004.corp.global.level3.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

This should certainly work. It seems to be
more of an implementation detail than a 
SIP protocol change. Is it proposed that all
multi-homed implementations would have to insert
two Record-Route: headers?

Sean Olson
Microsoft

--- John.Hearty@level3.com wrote:
> As I recall, I've already seen at least one vendor
> doing it the way you
> proposed, and it seemed to work OK.
> 
> John Hearty
> Level3
> 
> > -----Original Message-----
> > From: Dean Willis [mailto:dwillis@dynamicsoft.com]
> > Sent: Monday, October 14, 2002 4:25 PM
> > To: sip@ietf.org
> > Cc: mankin@isi.edu
> > Subject: [Sip] Record-Route, Path, Service Route,
> and Multi-Homed
> > Proxies
> > 
> > 
> > 
> > On the weird bits about SIP has always been "how
> to deal with
> > multi-homed proxies". This has begun to raise a
> mess of problems with
> > Path, Service-route, and a few other things I
> consider important (like
> > security).
> > 
> > Background
> > -----------
> > 
> > By multi-homed, I mean connected, like a router,
> to two or more
> > different networks, with an interface into each
> network, such that
> > traffic comes "in" one network and goes "out" a
> different one.
> > 
> > A simple model is shown here:
> > 
> > 
> >          /------- \         /------------\
> >         |   net1   |       |     net2    |
> > UA1-----| 10.1.1.0 |---P---| 192.168.1.0 |-----UA2
> > .2      | /25      | .1 .1 |  /24        |     .2
> >          \------- /         \------------/
> > 
> > 
> > UA1 has one interface with IP address 10.1.1.2
> > 
> > P has two interfaces and two addresses
> > 	-- 10.1.1.1
> > 	-- 192.168.2.1
> > 
> > And UA has one onterface and 1 address,
> 192.168.2.2
> > 
> > 
> > In other words, there IS no IP level route between
> UA1 and 
> > UA2. No ping.
> > No traceroute. They live in entirely different
> networks.
> > 
> > But they can still exchange SIP, because P is a 
> SIP Proxy.
> > 
> > This works in SIP because P can record-route. 
> > 
> > -- On a request from UA1 (say, INVITE), toward UA2
> adds its interface
> > (the one facing UA2) to the Record-Route header
> field. 
> > 
> > -- UA2 stores the set of Record-Route header field
> values in case it
> > wants to send a request trhough P to UA1 later.
> > 
> > -- UA2 replies to the request, including the
> received Record-Route
> > header field.
> > 
> > -- P edits the record-route header field value
> corresponding to its
> > interface facing UA2 and changes it to have the
> addressing value
> > associated with its interface facing UA1. This
> little blurb is buried
> > way down in the SIP spec -- we really don't talk
> about multihomed
> > proxies very much.
> > 
> > -- UA1 stores the Record-Route header field values
> in case it 
> > ever wants
> > to talk to UA2 again.
> > 
> > The stored record-Route header field values are
> later used to 
> > construct
> > Route header fields, which are inserted in furture
> requests (such as
> > BYE).
> > 
> > So far, so good. It works.
> > 
> > But there has been an odd thing: the route, as
> seen by UA1, 
> > is entirely
> > different from the route as seen by UA2.
> > 
> > -- UA1 stored a route of 10.1.1.1
> > -- UA2 stored a route of 192.168.2.1
> > 
> > This odd thing has two serious implications:
> > 
> > 1) UA2 cannot sign the route set, because it gets
> edited by P in the
> > response. Consequently, end-to-end protection of
> the route set can not
> > be supported by the protocol. We've just broken
> the openness principle
> > and the end-to-end principle. Oops.
> > 
> > 2) P must implement special "multihomed" logic. On
> the 
> > request phase, it
> > goes through output interface calculation and
> writes the output
> > interface into the route. It must then inspect all
> responses, grep for
> > an input interface, and selectively edit them to
> reference the correct
> > output interface. This is a CPU drag. 
> > 
> > 
> > Implications for Path and Service-Route
> > ---------------------------------------
> > 
> > As currently written, the Path header field
> accumulates in the same
> > manner as Record-Route. It gets written on the
> request. The Path draft
> > doesn't say what happens for a multi-homed host,
> so we assume it works
> > like Record-Route (it does say that), so it gets
> set to the interface
> > facing the registrar. This works just fine for the
> documented 
> > purpose of
> > path, finding the route from the registrar back to
> the UA.
> > 
> > But, people want to use the Path to calculate the
> route from 
> > the UA to a
> > service proxy associated with the registrar
> (Service-Route). 
> > Since only
> > the interfaces facing the registar are stored in
> Path, we have to use
> > configured information about the network to guess
> what the 
> > "other" side
> > might be. This is not all that useful -- it
> requires lots of tricky
> > configuration. Tricky configuration is BAD when we
> have an 
> > alternative.
> > 
> > One proposal is to let P edit Service-Route on the
> return stroke, just
> > like Record-Route. This would probably work, but
> conflicts with the
> > security requirements on Service-Route, requries
> special 
> > behavior in P,
> > and so forth. In other words, its bad for all the
> same 
> > reasons that the
> > Record-Route processing is bad, and then some.
> > 
> > 
> > 
> > Suggestion -- Symmetrize the Route with In-Out
> Record-Routing
> >
>
-------------------------------------------------------------
> > 
> > What if proxies doing record-routing inserted a
> Record-Route header
> > field value for the receiving interface, and iff
> the sending interface
> > were different, inserted another Record-Route
> header field 
> > value for the
> > sending interface?
> > 
> > In the case of our example, P would add both
> 10.1.1.1 and 192.168.2.1
> > 
> > The result as I see it:
> > 
> 
=== message truncated ===


__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Mon Oct 14 21:08:16 2002
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 VAA06835
	for <sip-archive@odin.ietf.org>; Mon, 14 Oct 2002 21:08:15 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9F1A3h03671
	for sip-archive@odin.ietf.org; Mon, 14 Oct 2002 21:10:03 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9F19Kv03610;
	Mon, 14 Oct 2002 21:09:20 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9F16Dv02959
	for <sip@optimus.ietf.org>; Mon, 14 Oct 2002 21:06:13 -0400
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 VAA06780
	for <sip@ietf.org>; Mon, 14 Oct 2002 21:03:54 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id g9F18WXi024280;
	Mon, 14 Oct 2002 20:08:32 -0500
From: "Dean Willis" <dwillis@dynamicsoft.com>
To: "'Sean Olson'" <seancolson@yahoo.com>, <John.Hearty@level3.com>,
        <sip@ietf.org>
Cc: <mankin@isi.edu>
Subject: RE: [Sip] Record-Route, Path, Service Route, and Multi-Homed Prox ies
Date: Mon, 14 Oct 2002 20:05:56 -0500
Message-ID: <001401c273e7$047ee5a0$fe0c0c42@TXDWILLIS2>
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
Importance: Normal
In-Reply-To: <20021015002746.31466.qmail@web20710.mail.yahoo.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit


I believe that's the kernel of the proposal, yes.

I would propose that the Service-Route RFC mandates this two-header
behavior for any proxy supporting Service-Route and Path. There are
option-tags for Path, so . . .


--
Dean


> -----Original Message-----
> From: Sean Olson [mailto:seancolson@yahoo.com] 
> Sent: Monday, October 14, 2002 7:28 PM
> To: John.Hearty@level3.com; dwillis@dynamicsoft.com; sip@ietf.org
> Cc: mankin@isi.edu
> Subject: RE: [Sip] Record-Route, Path, Service Route, and 
> Multi-Homed Prox ies
> 
> 
> This should certainly work. It seems to be
> more of an implementation detail than a 
> SIP protocol change. Is it proposed that all
> multi-homed implementations would have to insert
> two Record-Route: headers?
> 
> Sean Olson
> Microsoft
> 
> --- John.Hearty@level3.com wrote:
> > As I recall, I've already seen at least one vendor
> > doing it the way you
> > proposed, and it seemed to work OK.
> > 
> > John Hearty
> > Level3
> > 
> > > -----Original Message-----
> > > From: Dean Willis [mailto:dwillis@dynamicsoft.com]
> > > Sent: Monday, October 14, 2002 4:25 PM
> > > To: sip@ietf.org
> > > Cc: mankin@isi.edu
> > > Subject: [Sip] Record-Route, Path, Service Route,
> > and Multi-Homed
> > > Proxies
> > > 
> > > 
> > > 
> > > On the weird bits about SIP has always been "how
> > to deal with
> > > multi-homed proxies". This has begun to raise a
> > mess of problems with
> > > Path, Service-route, and a few other things I
> > consider important (like
> > > security).
> > > 
> > > Background
> > > -----------
> > > 
> > > By multi-homed, I mean connected, like a router,
> > to two or more
> > > different networks, with an interface into each
> > network, such that
> > > traffic comes "in" one network and goes "out" a
> > different one.
> > > 
> > > A simple model is shown here:
> > > 
> > > 
> > >          /------- \         /------------\
> > >         |   net1   |       |     net2    |
> > > UA1-----| 10.1.1.0 |---P---| 192.168.1.0 |-----UA2
> > > .2      | /25      | .1 .1 |  /24        |     .2
> > >          \------- /         \------------/
> > > 
> > > 
> > > UA1 has one interface with IP address 10.1.1.2
> > > 
> > > P has two interfaces and two addresses
> > > 	-- 10.1.1.1
> > > 	-- 192.168.2.1
> > > 
> > > And UA has one onterface and 1 address,
> > 192.168.2.2
> > > 
> > > 
> > > In other words, there IS no IP level route between
> > UA1 and
> > > UA2. No ping.
> > > No traceroute. They live in entirely different
> > networks.
> > > 
> > > But they can still exchange SIP, because P is a
> > SIP Proxy.
> > > 
> > > This works in SIP because P can record-route.
> > > 
> > > -- On a request from UA1 (say, INVITE), toward UA2
> > adds its interface
> > > (the one facing UA2) to the Record-Route header
> > field.
> > > 
> > > -- UA2 stores the set of Record-Route header field
> > values in case it
> > > wants to send a request trhough P to UA1 later.
> > > 
> > > -- UA2 replies to the request, including the
> > received Record-Route
> > > header field.
> > > 
> > > -- P edits the record-route header field value
> > corresponding to its
> > > interface facing UA2 and changes it to have the
> > addressing value
> > > associated with its interface facing UA1. This
> > little blurb is buried
> > > way down in the SIP spec -- we really don't talk
> > about multihomed
> > > proxies very much.
> > > 
> > > -- UA1 stores the Record-Route header field values
> > in case it
> > > ever wants
> > > to talk to UA2 again.
> > > 
> > > The stored record-Route header field values are
> > later used to
> > > construct
> > > Route header fields, which are inserted in furture
> > requests (such as
> > > BYE).
> > > 
> > > So far, so good. It works.
> > > 
> > > But there has been an odd thing: the route, as
> > seen by UA1,
> > > is entirely
> > > different from the route as seen by UA2.
> > > 
> > > -- UA1 stored a route of 10.1.1.1
> > > -- UA2 stored a route of 192.168.2.1
> > > 
> > > This odd thing has two serious implications:
> > > 
> > > 1) UA2 cannot sign the route set, because it gets
> > edited by P in the
> > > response. Consequently, end-to-end protection of
> > the route set can not
> > > be supported by the protocol. We've just broken
> > the openness principle
> > > and the end-to-end principle. Oops.
> > > 
> > > 2) P must implement special "multihomed" logic. On
> > the
> > > request phase, it
> > > goes through output interface calculation and
> > writes the output
> > > interface into the route. It must then inspect all
> > responses, grep for
> > > an input interface, and selectively edit them to
> > reference the correct
> > > output interface. This is a CPU drag.
> > > 
> > > 
> > > Implications for Path and Service-Route
> > > ---------------------------------------
> > > 
> > > As currently written, the Path header field
> > accumulates in the same
> > > manner as Record-Route. It gets written on the
> > request. The Path draft
> > > doesn't say what happens for a multi-homed host,
> > so we assume it works
> > > like Record-Route (it does say that), so it gets
> > set to the interface
> > > facing the registrar. This works just fine for the
> > documented
> > > purpose of
> > > path, finding the route from the registrar back to
> > the UA.
> > > 
> > > But, people want to use the Path to calculate the
> > route from
> > > the UA to a
> > > service proxy associated with the registrar
> > (Service-Route).
> > > Since only
> > > the interfaces facing the registar are stored in
> > Path, we have to use
> > > configured information about the network to guess
> > what the
> > > "other" side
> > > might be. This is not all that useful -- it
> > requires lots of tricky
> > > configuration. Tricky configuration is BAD when we
> > have an
> > > alternative.
> > > 
> > > One proposal is to let P edit Service-Route on the
> > return stroke, just
> > > like Record-Route. This would probably work, but
> > conflicts with the
> > > security requirements on Service-Route, requries
> > special
> > > behavior in P,
> > > and so forth. In other words, its bad for all the
> > same
> > > reasons that the
> > > Record-Route processing is bad, and then some.
> > > 
> > > 
> > > 
> > > Suggestion -- Symmetrize the Route with In-Out
> > Record-Routing
> > >
> >
> -------------------------------------------------------------
> > > 
> > > What if proxies doing record-routing inserted a
> > Record-Route header
> > > field value for the receiving interface, and iff
> > the sending interface
> > > were different, inserted another Record-Route
> > header field
> > > value for the
> > > sending interface?
> > > 
> > > In the case of our example, P would add both
> > 10.1.1.1 and 192.168.2.1
> > > 
> > > The result as I see it:
> > > 
> > 
> === message truncated ===
> 
> 
> __________________________________________________
> Do you Yahoo!?
> Faith Hill - Exclusive Performances, Videos & More 
http://faith.yahoo.com


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



From mailnull@www1.ietf.org  Mon Oct 14 22:57:54 2002
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 WAA09185
	for <sip-archive@odin.ietf.org>; Mon, 14 Oct 2002 22:57:54 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9F2xfL08522
	for sip-archive@odin.ietf.org; Mon, 14 Oct 2002 22:59:41 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9F2xFv08508;
	Mon, 14 Oct 2002 22:59:15 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9F2vIv08460
	for <sip@optimus.ietf.org>; Mon, 14 Oct 2002 22:57:18 -0400
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 WAA09091
	for <sip@ietf.org>; Mon, 14 Oct 2002 22:55:00 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.49])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g9F2nTYH010506;
	Mon, 14 Oct 2002 22:49:29 -0400 (EDT)
Message-ID: <3DAB8239.4080606@dynamicsoft.com>
Date: Mon, 14 Oct 2002 22:49:29 -0400
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: "Drage, Keith (Keith)" <drage@lucent.com>
CC: Sachin Shenoy <sachins@netlab.hcltech.com>, sip@ietf.org
Subject: Re: [Sip] Backward incompatibity in Via header grammar.
References: <475FF955A05DD411980D00508B6D5FB00636B7F2@en0033exch001u.uk.lucent.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

There is no requirement for strict backwards compatibility. We have 
tried to achieve practical backwards compatibility, which means that the 
features we removed or changed weren't really implemented anyway. To our 
knowledge, no one was putting comments in, and since they were a pain, 
we removed them. Removing things that were never used is part of the 
IETF standards process.

-Jonathan R.

Drage, Keith (Keith) wrote:
> Backward compatibility or incompatibility is assessed against previously 
> published versions of the RFCs, i.e. RFC 2543 to RFC 3261.
>  
> Compatibility problems with anyone who implements an internet draft, 
> i.e. work in progress, lie with whoever decided not to wait for the 
> published RFC.
>  
> However the BNF you quote does appear in RFC 2543. I do not know the 
> reason why it was removed, but I would note that there has been a 
> general cleaning up of comment usage throughout RFC 3261 from RFC 2543, 
> and not in this header alone.
>  
> Keith
>  
> 
> Keith Drage
> Lucent Technologies
> Tel: +44 1793 776249
> Email: drage@lucent.com
> 
>     -----Original Message-----
>     *From:* Sachin Shenoy [mailto:sachins@netlab.hcltech.com]
>     *Sent:* 14 October 2002 06:42
>     *To:* sip@ietf.org
>     *Subject:* [Sip] Backward incompatibity in Via header grammar.
> 
>     Hi,
> 
>     According to bis-02 & bis-05 the grammar of Via is following.
> 
>     Via = ( "Via" |/ /"v" ) HCOLON
> 
>     1#( sent-protocol sent-by
> 
>     *( SEMI via-params ) [ comment ] )
> 
>     It allows for comment to be present in Via header.
> 
>      
> 
>     But according to the new RFC, this is the grammar,
> 
>     Via = ( "Via" / "v" ) HCOLON via-parm *(COMMA via-parm)
> 
>     Which doesn't allow for comment.
> 
>      
> 
>     Won't this cause backward incompatablity. (Any old proxy
> 
>     which inserts comment in Via can cause serious problems for
> 
>     new implementation).
> 
>      
> 
>     Thanks
> 
>     Sachin
> 
>      
> 

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

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



From mailnull@www1.ietf.org  Tue Oct 15 07:53:42 2002
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 HAA27445
	for <sip-archive@odin.ietf.org>; Tue, 15 Oct 2002 07:53:42 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9FBtNo09643
	for sip-archive@odin.ietf.org; Tue, 15 Oct 2002 07:55:23 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FBsEv09614;
	Tue, 15 Oct 2002 07:54:14 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FBqwv09584
	for <sip@optimus.ietf.org>; Tue, 15 Oct 2002 07:52:58 -0400
Received: from imr1.ericy.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27405
	for <sip@ietf.org>; Tue, 15 Oct 2002 07:50:46 -0400 (EDT)
Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122])
	by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g9FBqjj18060;
	Tue, 15 Oct 2002 06:52:46 -0500 (CDT)
Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1])
	by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g9FBqj920426;
	Tue, 15 Oct 2002 06:52:45 -0500 (CDT)
Received: from EAMMLEX034.lmc.ericsson.se (eammlex034.lmc.ericsson.se [142.133.1.134])
	by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id g9FBqih17219;
	Tue, 15 Oct 2002 07:52:44 -0400 (EDT)
Received: by EAMMLEX034.lmc.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <47YTWH2P>; Tue, 15 Oct 2002 07:52:44 -0400
Message-ID: <32CD630F6CBED411AE180008C7894CBC0C037AD4@lmc37.lmc.ericsson.se>
From: "George Foti (LMC)" <George.Foti@ericsson.ca>
To: "'Sean Olson'" <seancolson@yahoo.com>, John.Hearty@level3.com,
        dwillis@dynamicsoft.com, sip@ietf.org
Cc: mankin@isi.edu
Subject: RE: [Sip] Record-Route, Path, Service Route, and Multi-Homed Prox
	 ies
Date: Tue, 15 Oct 2002 07:52:42 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

I read the proposal as everytime that you would have to do a rewrite on a RR
in a response you would have to include 2 addresses.

George Foti
Ericsson Canada

> -----Original Message-----
> From: Sean Olson [mailto:seancolson@yahoo.com]
> Sent: Monday, October 14, 2002 8:28 PM
> To: John.Hearty@level3.com; dwillis@dynamicsoft.com; sip@ietf.org
> Cc: mankin@isi.edu
> Subject: RE: [Sip] Record-Route, Path, Service Route, and Multi-Homed
> Prox ies
> 
> 
> This should certainly work. It seems to be
> more of an implementation detail than a 
> SIP protocol change. Is it proposed that all
> multi-homed implementations would have to insert
> two Record-Route: headers?
> 
> Sean Olson
> Microsoft
> 
> --- John.Hearty@level3.com wrote:
> > As I recall, I've already seen at least one vendor
> > doing it the way you
> > proposed, and it seemed to work OK.
> > 
> > John Hearty
> > Level3
> > 
> > > -----Original Message-----
> > > From: Dean Willis [mailto:dwillis@dynamicsoft.com]
> > > Sent: Monday, October 14, 2002 4:25 PM
> > > To: sip@ietf.org
> > > Cc: mankin@isi.edu
> > > Subject: [Sip] Record-Route, Path, Service Route,
> > and Multi-Homed
> > > Proxies
> > > 
> > > 
> > > 
> > > On the weird bits about SIP has always been "how
> > to deal with
> > > multi-homed proxies". This has begun to raise a
> > mess of problems with
> > > Path, Service-route, and a few other things I
> > consider important (like
> > > security).
> > > 
> > > Background
> > > -----------
> > > 
> > > By multi-homed, I mean connected, like a router,
> > to two or more
> > > different networks, with an interface into each
> > network, such that
> > > traffic comes "in" one network and goes "out" a
> > different one.
> > > 
> > > A simple model is shown here:
> > > 
> > > 
> > >          /------- \         /------------\
> > >         |   net1   |       |     net2    |
> > > UA1-----| 10.1.1.0 |---P---| 192.168.1.0 |-----UA2
> > > .2      | /25      | .1 .1 |  /24        |     .2
> > >          \------- /         \------------/
> > > 
> > > 
> > > UA1 has one interface with IP address 10.1.1.2
> > > 
> > > P has two interfaces and two addresses
> > > 	-- 10.1.1.1
> > > 	-- 192.168.2.1
> > > 
> > > And UA has one onterface and 1 address,
> > 192.168.2.2
> > > 
> > > 
> > > In other words, there IS no IP level route between
> > UA1 and 
> > > UA2. No ping.
> > > No traceroute. They live in entirely different
> > networks.
> > > 
> > > But they can still exchange SIP, because P is a 
> > SIP Proxy.
> > > 
> > > This works in SIP because P can record-route. 
> > > 
> > > -- On a request from UA1 (say, INVITE), toward UA2
> > adds its interface
> > > (the one facing UA2) to the Record-Route header
> > field. 
> > > 
> > > -- UA2 stores the set of Record-Route header field
> > values in case it
> > > wants to send a request trhough P to UA1 later.
> > > 
> > > -- UA2 replies to the request, including the
> > received Record-Route
> > > header field.
> > > 
> > > -- P edits the record-route header field value
> > corresponding to its
> > > interface facing UA2 and changes it to have the
> > addressing value
> > > associated with its interface facing UA1. This
> > little blurb is buried
> > > way down in the SIP spec -- we really don't talk
> > about multihomed
> > > proxies very much.
> > > 
> > > -- UA1 stores the Record-Route header field values
> > in case it 
> > > ever wants
> > > to talk to UA2 again.
> > > 
> > > The stored record-Route header field values are
> > later used to 
> > > construct
> > > Route header fields, which are inserted in furture
> > requests (such as
> > > BYE).
> > > 
> > > So far, so good. It works.
> > > 
> > > But there has been an odd thing: the route, as
> > seen by UA1, 
> > > is entirely
> > > different from the route as seen by UA2.
> > > 
> > > -- UA1 stored a route of 10.1.1.1
> > > -- UA2 stored a route of 192.168.2.1
> > > 
> > > This odd thing has two serious implications:
> > > 
> > > 1) UA2 cannot sign the route set, because it gets
> > edited by P in the
> > > response. Consequently, end-to-end protection of
> > the route set can not
> > > be supported by the protocol. We've just broken
> > the openness principle
> > > and the end-to-end principle. Oops.
> > > 
> > > 2) P must implement special "multihomed" logic. On
> > the 
> > > request phase, it
> > > goes through output interface calculation and
> > writes the output
> > > interface into the route. It must then inspect all
> > responses, grep for
> > > an input interface, and selectively edit them to
> > reference the correct
> > > output interface. This is a CPU drag. 
> > > 
> > > 
> > > Implications for Path and Service-Route
> > > ---------------------------------------
> > > 
> > > As currently written, the Path header field
> > accumulates in the same
> > > manner as Record-Route. It gets written on the
> > request. The Path draft
> > > doesn't say what happens for a multi-homed host,
> > so we assume it works
> > > like Record-Route (it does say that), so it gets
> > set to the interface
> > > facing the registrar. This works just fine for the
> > documented 
> > > purpose of
> > > path, finding the route from the registrar back to
> > the UA.
> > > 
> > > But, people want to use the Path to calculate the
> > route from 
> > > the UA to a
> > > service proxy associated with the registrar
> > (Service-Route). 
> > > Since only
> > > the interfaces facing the registar are stored in
> > Path, we have to use
> > > configured information about the network to guess
> > what the 
> > > "other" side
> > > might be. This is not all that useful -- it
> > requires lots of tricky
> > > configuration. Tricky configuration is BAD when we
> > have an 
> > > alternative.
> > > 
> > > One proposal is to let P edit Service-Route on the
> > return stroke, just
> > > like Record-Route. This would probably work, but
> > conflicts with the
> > > security requirements on Service-Route, requries
> > special 
> > > behavior in P,
> > > and so forth. In other words, its bad for all the
> > same 
> > > reasons that the
> > > Record-Route processing is bad, and then some.
> > > 
> > > 
> > > 
> > > Suggestion -- Symmetrize the Route with In-Out
> > Record-Routing
> > >
> >
> -------------------------------------------------------------
> > > 
> > > What if proxies doing record-routing inserted a
> > Record-Route header
> > > field value for the receiving interface, and iff
> > the sending interface
> > > were different, inserted another Record-Route
> > header field 
> > > value for the
> > > sending interface?
> > > 
> > > In the case of our example, P would add both
> > 10.1.1.1 and 192.168.2.1
> > > 
> > > The result as I see it:
> > > 
> > 
> === message truncated ===
> 
> 
> __________________________________________________
> Do you Yahoo!?
> Faith Hill - Exclusive Performances, Videos & More
> http://faith.yahoo.com
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Tue Oct 15 11:58:20 2002
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 LAA05757
	for <sip-archive@odin.ietf.org>; Tue, 15 Oct 2002 11:58:19 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9FG02b23695
	for sip-archive@odin.ietf.org; Tue, 15 Oct 2002 12:00:02 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FFtmv23357;
	Tue, 15 Oct 2002 11:55:48 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FFqsv23221
	for <sip@optimus.ietf.org>; Tue, 15 Oct 2002 11:52:54 -0400
Received: from ihemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05514
	for <sip@ietf.org>; Tue, 15 Oct 2002 11:50:40 -0400 (EDT)
Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39])
	by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g9FFqlP16161;
	Tue, 15 Oct 2002 11:52:47 -0400 (EDT)
Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id KAA26872; Tue, 15 Oct 2002 10:52:46 -0500 (CDT)
Message-ID: <3DAC399C.90606@lucent.com>
Date: Tue, 15 Oct 2002 10:51:56 -0500
From: "Vijay K. Gurbani" <vkg@lucent.com>
Organization: Lucent Technologies, Inc./Bell Laboratories
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 <dwillis@dynamicsoft.com>
CC: sip@ietf.org, mankin@isi.edu
Subject: Re: [Sip] Record-Route, Path, Service Route, and Multi-Homed Proxies
References: <005f01c273d0$837e00a0$fe0c0c42@TXDWILLIS2>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hello Dean:

Dean Willis wrote:
> On the weird bits about SIP has always been "how to deal with
> multi-homed proxies". This has begun to raise a mess of problems with
> Path, Service-route, and a few other things I consider important (like
> security).

It also raises (solvable) problems with proxy/registrars being
authoritative entities for multiple domains, each represented by a
different interface.  We've run into some of these while running
on multi-homed machines.

In any case, regarding your specific proposal, it sounds eminently
reasonable.  For much the same reasons as you mention (not so much as
breaking e2e security model as for the intensive task of modifying
R-R responses going upstream; more so if the request has legitimately
spiralled and thus the need to find the appropriately inserted R-R), I
have not been a big fan of R-R response modifications (rfc3261 does
have an example, I believe, in Chapter 17).  Maitaining two Routes
in the Route set leads to simpler processing (optimizing proxies can
prevent double processing, as you point out).

> Path Forward:
> 
> If nobody convinces me this is just a freaking bad idea, I propose to
> document the record-route behavior in a new draft, and edit the
> Service-Route draft to reference the behavior and describe how to
> generate service-routes from record-routes. I believe all the
> implications for Path (currently in rfc-ed queue) can be handled
> entirely within the Service Route draft.

Must we come up with a new I-D for this?  It is not new SIP behavior
as much as heuristics/clarification/discussion on how a proxy/registrar
behaves under a multi-homed machine.  I mean, if rfc3261 does not
address multi-homing, can we add a section in Chapter 17?  There are a
list of open issues associated with rfc3261 anyway.  My personal
preference is to add it in rfc3261-bis since the 
heuristics/clarifications/discussions do really belong there.

Regards,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216

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



From mailnull@www1.ietf.org  Tue Oct 15 12:02:52 2002
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 MAA05946
	for <sip-archive@odin.ietf.org>; Tue, 15 Oct 2002 12:02:52 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9FG4Zt24315
	for sip-archive@odin.ietf.org; Tue, 15 Oct 2002 12:04:35 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FG4Hv24280;
	Tue, 15 Oct 2002 12:04:17 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FG3mv24235
	for <sip@optimus.ietf.org>; Tue, 15 Oct 2002 12:03:48 -0400
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 MAA05887
	for <sip@ietf.org>; Tue, 15 Oct 2002 12:01:35 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id g9FG6VXi029941;
	Tue, 15 Oct 2002 11:06:31 -0500
From: "Dean Willis" <dwillis@dynamicsoft.com>
To: "'Vijay K. Gurbani'" <vkg@lucent.com>
Cc: <sip@ietf.org>, <mankin@isi.edu>
Subject: RE: [Sip] Record-Route, Path, Service Route, and Multi-Homed Proxies
Date: Tue, 15 Oct 2002 11:03:34 -0500
Message-ID: <003401c27464$6a5a9c70$fe0c0c42@TXDWILLIS2>
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
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <3DAC399C.90606@lucent.com>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

> In any case, regarding your specific proposal, it sounds 
> eminently reasonable. 

Wow! Thanks! It's been  along time since I've done anything eminently
reasonable!

> Must we come up with a new I-D for this?  It is not new SIP 
> behavior as much as heuristics/clarification/discussion on 
> how a proxy/registrar behaves under a multi-homed machine.  I 
> mean, if rfc3261 does not address multi-homing, can we add a 
> section in Chapter 17?  There are a list of open issues 
> associated with rfc3261 anyway.  My personal preference is to 
> add it in rfc3261-bis since the 
> heuristics/clarifications/discussions do really belong there.

Well, the Service-Route specification is a "new" I-D. Actually, it's
completed WGLC and is awaiting final IESG review. Miguel and Gonzalo
raised some valid concerns that it is not as useful as they want. They
want to use it in conjunction with Path (currently in the rfc-ed queue).
Path refers to Record-Route behavior. So the proposed behavior would
probably need to be described in the Service-Route draft in order to
keep Service-Route from being blocked on 3261bis.

I think.

--
Dean

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



From mailnull@www1.ietf.org  Tue Oct 15 12:02:59 2002
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 MAA05960
	for <sip-archive@odin.ietf.org>; Tue, 15 Oct 2002 12:02:59 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9FG4gC24327
	for sip-archive@odin.ietf.org; Tue, 15 Oct 2002 12:04:42 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FG4Ov24302;
	Tue, 15 Oct 2002 12:04:24 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FG3rv24239
	for <sip@optimus.ietf.org>; Tue, 15 Oct 2002 12:03:53 -0400
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 MAA05890
	for <sip@ietf.org>; Tue, 15 Oct 2002 12:01:38 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id g9FG6VXj029941;
	Tue, 15 Oct 2002 11:06:31 -0500
From: "Dean Willis" <dwillis@dynamicsoft.com>
To: "'George Foti \(LMC\)'" <George.Foti@ericsson.ca>,
        "'Sean Olson'" <seancolson@yahoo.com>, <John.Hearty@level3.com>,
        <sip@ietf.org>
Cc: <mankin@isi.edu>
Subject: RE: [Sip] Record-Route, Path, Service Route, and Multi-Homed Prox ies
Date: Tue, 15 Oct 2002 11:03:34 -0500
Message-ID: <003501c27464$6bf42830$fe0c0c42@TXDWILLIS2>
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
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <32CD630F6CBED411AE180008C7894CBC0C037AD4@lmc37.lmc.ericsson.se>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit


Yep, INSTEAD of doing the rewrite in the reponse phase, you include 2
addresses (Record-Route header field values, to be technical) in the
request phase. 

--
Dean

> -----Original Message-----
> From: George Foti (LMC) [mailto:George.Foti@ericsson.ca] 
> Sent: Tuesday, October 15, 2002 6:53 AM
> To: 'Sean Olson'; John.Hearty@level3.com; 
> dwillis@dynamicsoft.com; sip@ietf.org
> Cc: mankin@isi.edu
> Subject: RE: [Sip] Record-Route, Path, Service Route, and 
> Multi-Homed Prox ies
> 
> 
> I read the proposal as everytime that you would have to do a 
> rewrite on a RR in a response you would have to include 2 addresses.
> 
> George Foti
> Ericsson Canada
> 
> > -----Original Message-----
> > From: Sean Olson [mailto:seancolson@yahoo.com]
> > Sent: Monday, October 14, 2002 8:28 PM
> > To: John.Hearty@level3.com; dwillis@dynamicsoft.com; sip@ietf.org
> > Cc: mankin@isi.edu
> > Subject: RE: [Sip] Record-Route, Path, Service Route, and 
> Multi-Homed 
> > Prox ies
> > 
> > 
> > This should certainly work. It seems to be
> > more of an implementation detail than a
> > SIP protocol change. Is it proposed that all
> > multi-homed implementations would have to insert
> > two Record-Route: headers?
> > 
> > Sean Olson
> > Microsoft
> > 
> > --- John.Hearty@level3.com wrote:
> > > As I recall, I've already seen at least one vendor
> > > doing it the way you
> > > proposed, and it seemed to work OK.
> > > 
> > > John Hearty
> > > Level3
> > > 
> > > > -----Original Message-----
> > > > From: Dean Willis [mailto:dwillis@dynamicsoft.com]
> > > > Sent: Monday, October 14, 2002 4:25 PM
> > > > To: sip@ietf.org
> > > > Cc: mankin@isi.edu
> > > > Subject: [Sip] Record-Route, Path, Service Route,
> > > and Multi-Homed
> > > > Proxies
> > > > 
> > > > 
> > > > 
> > > > On the weird bits about SIP has always been "how
> > > to deal with
> > > > multi-homed proxies". This has begun to raise a
> > > mess of problems with
> > > > Path, Service-route, and a few other things I
> > > consider important (like
> > > > security).
> > > > 
> > > > Background
> > > > -----------
> > > > 
> > > > By multi-homed, I mean connected, like a router,
> > > to two or more
> > > > different networks, with an interface into each
> > > network, such that
> > > > traffic comes "in" one network and goes "out" a
> > > different one.
> > > > 
> > > > A simple model is shown here:
> > > > 
> > > > 
> > > >          /------- \         /------------\
> > > >         |   net1   |       |     net2    |
> > > > UA1-----| 10.1.1.0 |---P---| 192.168.1.0 |-----UA2
> > > > .2      | /25      | .1 .1 |  /24        |     .2
> > > >          \------- /         \------------/
> > > > 
> > > > 
> > > > UA1 has one interface with IP address 10.1.1.2
> > > > 
> > > > P has two interfaces and two addresses
> > > > 	-- 10.1.1.1
> > > > 	-- 192.168.2.1
> > > > 
> > > > And UA has one onterface and 1 address,
> > > 192.168.2.2
> > > > 
> > > > 
> > > > In other words, there IS no IP level route between
> > > UA1 and
> > > > UA2. No ping.
> > > > No traceroute. They live in entirely different
> > > networks.
> > > > 
> > > > But they can still exchange SIP, because P is a
> > > SIP Proxy.
> > > > 
> > > > This works in SIP because P can record-route.
> > > > 
> > > > -- On a request from UA1 (say, INVITE), toward UA2
> > > adds its interface
> > > > (the one facing UA2) to the Record-Route header
> > > field.
> > > > 
> > > > -- UA2 stores the set of Record-Route header field
> > > values in case it
> > > > wants to send a request trhough P to UA1 later.
> > > > 
> > > > -- UA2 replies to the request, including the
> > > received Record-Route
> > > > header field.
> > > > 
> > > > -- P edits the record-route header field value
> > > corresponding to its
> > > > interface facing UA2 and changes it to have the
> > > addressing value
> > > > associated with its interface facing UA1. This
> > > little blurb is buried
> > > > way down in the SIP spec -- we really don't talk
> > > about multihomed
> > > > proxies very much.
> > > > 
> > > > -- UA1 stores the Record-Route header field values
> > > in case it
> > > > ever wants
> > > > to talk to UA2 again.
> > > > 
> > > > The stored record-Route header field values are
> > > later used to
> > > > construct
> > > > Route header fields, which are inserted in furture
> > > requests (such as
> > > > BYE).
> > > > 
> > > > So far, so good. It works.
> > > > 
> > > > But there has been an odd thing: the route, as
> > > seen by UA1,
> > > > is entirely
> > > > different from the route as seen by UA2.
> > > > 
> > > > -- UA1 stored a route of 10.1.1.1
> > > > -- UA2 stored a route of 192.168.2.1
> > > > 
> > > > This odd thing has two serious implications:
> > > > 
> > > > 1) UA2 cannot sign the route set, because it gets
> > > edited by P in the
> > > > response. Consequently, end-to-end protection of
> > > the route set can not
> > > > be supported by the protocol. We've just broken
> > > the openness principle
> > > > and the end-to-end principle. Oops.
> > > > 
> > > > 2) P must implement special "multihomed" logic. On
> > > the
> > > > request phase, it
> > > > goes through output interface calculation and
> > > writes the output
> > > > interface into the route. It must then inspect all
> > > responses, grep for
> > > > an input interface, and selectively edit them to
> > > reference the correct
> > > > output interface. This is a CPU drag.
> > > > 
> > > > 
> > > > Implications for Path and Service-Route
> > > > ---------------------------------------
> > > > 
> > > > As currently written, the Path header field
> > > accumulates in the same
> > > > manner as Record-Route. It gets written on the
> > > request. The Path draft
> > > > doesn't say what happens for a multi-homed host,
> > > so we assume it works
> > > > like Record-Route (it does say that), so it gets
> > > set to the interface
> > > > facing the registrar. This works just fine for the
> > > documented
> > > > purpose of
> > > > path, finding the route from the registrar back to
> > > the UA.
> > > > 
> > > > But, people want to use the Path to calculate the
> > > route from
> > > > the UA to a
> > > > service proxy associated with the registrar
> > > (Service-Route).
> > > > Since only
> > > > the interfaces facing the registar are stored in
> > > Path, we have to use
> > > > configured information about the network to guess
> > > what the
> > > > "other" side
> > > > might be. This is not all that useful -- it
> > > requires lots of tricky
> > > > configuration. Tricky configuration is BAD when we
> > > have an
> > > > alternative.
> > > > 
> > > > One proposal is to let P edit Service-Route on the
> > > return stroke, just
> > > > like Record-Route. This would probably work, but
> > > conflicts with the
> > > > security requirements on Service-Route, requries
> > > special
> > > > behavior in P,
> > > > and so forth. In other words, its bad for all the
> > > same
> > > > reasons that the
> > > > Record-Route processing is bad, and then some.
> > > > 
> > > > 
> > > > 
> > > > Suggestion -- Symmetrize the Route with In-Out
> > > Record-Routing
> > > >
> > >
> > -------------------------------------------------------------
> > > > 
> > > > What if proxies doing record-routing inserted a
> > > Record-Route header
> > > > field value for the receiving interface, and iff
> > > the sending interface
> > > > were different, inserted another Record-Route
> > > header field
> > > > value for the
> > > > sending interface?
> > > > 
> > > > In the case of our example, P would add both
> > > 10.1.1.1 and 192.168.2.1
> > > > 
> > > > The result as I see it:
> > > > 
> > > 
> > === message truncated ===
> > 
> > 
> > __________________________________________________
> > Do you Yahoo!?
> > Faith Hill - Exclusive Performances, Videos & More 
> > http://faith.yahoo.com 
> _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip
> > 
> 
> 

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



From mailnull@www1.ietf.org  Tue Oct 15 12:20:01 2002
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 MAA06393
	for <sip-archive@odin.ietf.org>; Tue, 15 Oct 2002 12:20:00 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9FGLhc25438
	for sip-archive@odin.ietf.org; Tue, 15 Oct 2002 12:21:43 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FGLNv25420;
	Tue, 15 Oct 2002 12:21:23 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FGKPv25377
	for <sip@optimus.ietf.org>; Tue, 15 Oct 2002 12:20:25 -0400
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 MAA06357
	for <sip@ietf.org>; Tue, 15 Oct 2002 12:18:11 -0400 (EDT)
Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39])
	by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g9FGKD221148;
	Tue, 15 Oct 2002 12:20:13 -0400 (EDT)
Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id LAA11495; Tue, 15 Oct 2002 11:20:12 -0500 (CDT)
Message-ID: <3DAC400A.1030207@lucent.com>
Date: Tue, 15 Oct 2002 11:19:22 -0500
From: "Vijay K. Gurbani" <vkg@lucent.com>
Organization: Lucent Technologies, Inc./Bell Laboratories
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 <dwillis@dynamicsoft.com>
CC: sip@ietf.org, mankin@isi.edu
Subject: Re: [Sip] Record-Route, Path, Service Route, and Multi-Homed Proxies
References: <003401c27464$6a5a9c70$fe0c0c42@TXDWILLIS2>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Dean Willis wrote:
> Wow! Thanks! It's been  along time since I've done anything eminently
> reasonable!

Law of averages, Dean; law of averages :-)
I am still waiting for me to do something eminently reasonable.

> Well, the Service-Route specification is a "new" I-D. Actually, it's
> completed WGLC and is awaiting final IESG review. Miguel and Gonzalo
> raised some valid concerns that it is not as useful as they want. They
> want to use it in conjunction with Path (currently in the rfc-ed queue).
> Path refers to Record-Route behavior. So the proposed behavior would
> probably need to be described in the Service-Route draft in order to
> keep Service-Route from being blocked on 3261bis.

I was afraid you would say so.  Although, for whatever it is worth, I
really wish we would do it in rfc3261bis, but if we cannot, so be it.
Maybe, when the time comes, we can replicate whatever is in the
Service-Route draft on multi-homed proxies in rfc3261bis -- just to
keep information in one place.

Regards,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216

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



From mailnull@www1.ietf.org  Tue Oct 15 12:23:19 2002
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 MAA06465
	for <sip-archive@odin.ietf.org>; Tue, 15 Oct 2002 12:23:19 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9FGP2O25612
	for sip-archive@odin.ietf.org; Tue, 15 Oct 2002 12:25:02 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FGO8v25540;
	Tue, 15 Oct 2002 12:24:08 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FGN0v25497
	for <sip@optimus.ietf.org>; Tue, 15 Oct 2002 12:23:00 -0400
Received: from imr1.ericy.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06407
	for <sip@ietf.org>; Tue, 15 Oct 2002 12:20:46 -0400 (EDT)
Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123])
	by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g9FGMbj22333;
	Tue, 15 Oct 2002 11:22:37 -0500 (CDT)
Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1])
	by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g9FGMaO07675;
	Tue, 15 Oct 2002 11:22:36 -0500 (CDT)
Received: from EAMMLEX034.lmc.ericsson.se (eammlex034.lmc.ericsson.se [142.133.1.134])
	by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id g9FGMah04363;
	Tue, 15 Oct 2002 12:22:36 -0400 (EDT)
Received: by EAMMLEX034.lmc.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <47YTWJQK>; Tue, 15 Oct 2002 12:22:35 -0400
Message-ID: <32CD630F6CBED411AE180008C7894CBC0C037ADB@lmc37.lmc.ericsson.se>
From: "George Foti (LMC)" <George.Foti@ericsson.ca>
To: "'Dean Willis'" <dwillis@dynamicsoft.com>,
        "George Foti (LMC)"
	 <George.Foti@lmc.ericsson.se>,
        "'Sean Olson'" <seancolson@yahoo.com>, John.Hearty@level3.com,
        sip@ietf.org
Cc: mankin@isi.edu
Subject: RE: [Sip] Record-Route, Path, Service Route, and Multi-Homed Prox
	 ies
Date: Tue, 15 Oct 2002 12:22:34 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

So what if we needed to do a re-write for SIGCOMP reasons, or SIP/SIPS
reasons.
It seems that regarding RR is unavoidable.
Rgds/gf


> -----Original Message-----
> From: Dean Willis [mailto:dwillis@dynamicsoft.com]
> Sent: Tuesday, October 15, 2002 12:04 PM
> To: 'George Foti (LMC)'; 'Sean Olson'; John.Hearty@level3.com;
> sip@ietf.org
> Cc: mankin@isi.edu
> Subject: RE: [Sip] Record-Route, Path, Service Route, and Multi-Homed
> Prox ies
> 
> 
> 
> Yep, INSTEAD of doing the rewrite in the reponse phase, you include 2
> addresses (Record-Route header field values, to be technical) in the
> request phase. 
> 
> --
> Dean
> 
> > -----Original Message-----
> > From: George Foti (LMC) [mailto:George.Foti@ericsson.ca] 
> > Sent: Tuesday, October 15, 2002 6:53 AM
> > To: 'Sean Olson'; John.Hearty@level3.com; 
> > dwillis@dynamicsoft.com; sip@ietf.org
> > Cc: mankin@isi.edu
> > Subject: RE: [Sip] Record-Route, Path, Service Route, and 
> > Multi-Homed Prox ies
> > 
> > 
> > I read the proposal as everytime that you would have to do a 
> > rewrite on a RR in a response you would have to include 2 addresses.
> > 
> > George Foti
> > Ericsson Canada
> > 
> > > -----Original Message-----
> > > From: Sean Olson [mailto:seancolson@yahoo.com]
> > > Sent: Monday, October 14, 2002 8:28 PM
> > > To: John.Hearty@level3.com; dwillis@dynamicsoft.com; sip@ietf.org
> > > Cc: mankin@isi.edu
> > > Subject: RE: [Sip] Record-Route, Path, Service Route, and 
> > Multi-Homed 
> > > Prox ies
> > > 
> > > 
> > > This should certainly work. It seems to be
> > > more of an implementation detail than a
> > > SIP protocol change. Is it proposed that all
> > > multi-homed implementations would have to insert
> > > two Record-Route: headers?
> > > 
> > > Sean Olson
> > > Microsoft
> > > 
> > > --- John.Hearty@level3.com wrote:
> > > > As I recall, I've already seen at least one vendor
> > > > doing it the way you
> > > > proposed, and it seemed to work OK.
> > > > 
> > > > John Hearty
> > > > Level3
> > > > 
> > > > > -----Original Message-----
> > > > > From: Dean Willis [mailto:dwillis@dynamicsoft.com]
> > > > > Sent: Monday, October 14, 2002 4:25 PM
> > > > > To: sip@ietf.org
> > > > > Cc: mankin@isi.edu
> > > > > Subject: [Sip] Record-Route, Path, Service Route,
> > > > and Multi-Homed
> > > > > Proxies
> > > > > 
> > > > > 
> > > > > 
> > > > > On the weird bits about SIP has always been "how
> > > > to deal with
> > > > > multi-homed proxies". This has begun to raise a
> > > > mess of problems with
> > > > > Path, Service-route, and a few other things I
> > > > consider important (like
> > > > > security).
> > > > > 
> > > > > Background
> > > > > -----------
> > > > > 
> > > > > By multi-homed, I mean connected, like a router,
> > > > to two or more
> > > > > different networks, with an interface into each
> > > > network, such that
> > > > > traffic comes "in" one network and goes "out" a
> > > > different one.
> > > > > 
> > > > > A simple model is shown here:
> > > > > 
> > > > > 
> > > > >          /------- \         /------------\
> > > > >         |   net1   |       |     net2    |
> > > > > UA1-----| 10.1.1.0 |---P---| 192.168.1.0 |-----UA2
> > > > > .2      | /25      | .1 .1 |  /24        |     .2
> > > > >          \------- /         \------------/
> > > > > 
> > > > > 
> > > > > UA1 has one interface with IP address 10.1.1.2
> > > > > 
> > > > > P has two interfaces and two addresses
> > > > > 	-- 10.1.1.1
> > > > > 	-- 192.168.2.1
> > > > > 
> > > > > And UA has one onterface and 1 address,
> > > > 192.168.2.2
> > > > > 
> > > > > 
> > > > > In other words, there IS no IP level route between
> > > > UA1 and
> > > > > UA2. No ping.
> > > > > No traceroute. They live in entirely different
> > > > networks.
> > > > > 
> > > > > But they can still exchange SIP, because P is a
> > > > SIP Proxy.
> > > > > 
> > > > > This works in SIP because P can record-route.
> > > > > 
> > > > > -- On a request from UA1 (say, INVITE), toward UA2
> > > > adds its interface
> > > > > (the one facing UA2) to the Record-Route header
> > > > field.
> > > > > 
> > > > > -- UA2 stores the set of Record-Route header field
> > > > values in case it
> > > > > wants to send a request trhough P to UA1 later.
> > > > > 
> > > > > -- UA2 replies to the request, including the
> > > > received Record-Route
> > > > > header field.
> > > > > 
> > > > > -- P edits the record-route header field value
> > > > corresponding to its
> > > > > interface facing UA2 and changes it to have the
> > > > addressing value
> > > > > associated with its interface facing UA1. This
> > > > little blurb is buried
> > > > > way down in the SIP spec -- we really don't talk
> > > > about multihomed
> > > > > proxies very much.
> > > > > 
> > > > > -- UA1 stores the Record-Route header field values
> > > > in case it
> > > > > ever wants
> > > > > to talk to UA2 again.
> > > > > 
> > > > > The stored record-Route header field values are
> > > > later used to
> > > > > construct
> > > > > Route header fields, which are inserted in furture
> > > > requests (such as
> > > > > BYE).
> > > > > 
> > > > > So far, so good. It works.
> > > > > 
> > > > > But there has been an odd thing: the route, as
> > > > seen by UA1,
> > > > > is entirely
> > > > > different from the route as seen by UA2.
> > > > > 
> > > > > -- UA1 stored a route of 10.1.1.1
> > > > > -- UA2 stored a route of 192.168.2.1
> > > > > 
> > > > > This odd thing has two serious implications:
> > > > > 
> > > > > 1) UA2 cannot sign the route set, because it gets
> > > > edited by P in the
> > > > > response. Consequently, end-to-end protection of
> > > > the route set can not
> > > > > be supported by the protocol. We've just broken
> > > > the openness principle
> > > > > and the end-to-end principle. Oops.
> > > > > 
> > > > > 2) P must implement special "multihomed" logic. On
> > > > the
> > > > > request phase, it
> > > > > goes through output interface calculation and
> > > > writes the output
> > > > > interface into the route. It must then inspect all
> > > > responses, grep for
> > > > > an input interface, and selectively edit them to
> > > > reference the correct
> > > > > output interface. This is a CPU drag.
> > > > > 
> > > > > 
> > > > > Implications for Path and Service-Route
> > > > > ---------------------------------------
> > > > > 
> > > > > As currently written, the Path header field
> > > > accumulates in the same
> > > > > manner as Record-Route. It gets written on the
> > > > request. The Path draft
> > > > > doesn't say what happens for a multi-homed host,
> > > > so we assume it works
> > > > > like Record-Route (it does say that), so it gets
> > > > set to the interface
> > > > > facing the registrar. This works just fine for the
> > > > documented
> > > > > purpose of
> > > > > path, finding the route from the registrar back to
> > > > the UA.
> > > > > 
> > > > > But, people want to use the Path to calculate the
> > > > route from
> > > > > the UA to a
> > > > > service proxy associated with the registrar
> > > > (Service-Route).
> > > > > Since only
> > > > > the interfaces facing the registar are stored in
> > > > Path, we have to use
> > > > > configured information about the network to guess
> > > > what the
> > > > > "other" side
> > > > > might be. This is not all that useful -- it
> > > > requires lots of tricky
> > > > > configuration. Tricky configuration is BAD when we
> > > > have an
> > > > > alternative.
> > > > > 
> > > > > One proposal is to let P edit Service-Route on the
> > > > return stroke, just
> > > > > like Record-Route. This would probably work, but
> > > > conflicts with the
> > > > > security requirements on Service-Route, requries
> > > > special
> > > > > behavior in P,
> > > > > and so forth. In other words, its bad for all the
> > > > same
> > > > > reasons that the
> > > > > Record-Route processing is bad, and then some.
> > > > > 
> > > > > 
> > > > > 
> > > > > Suggestion -- Symmetrize the Route with In-Out
> > > > Record-Routing
> > > > >
> > > >
> > > -------------------------------------------------------------
> > > > > 
> > > > > What if proxies doing record-routing inserted a
> > > > Record-Route header
> > > > > field value for the receiving interface, and iff
> > > > the sending interface
> > > > > were different, inserted another Record-Route
> > > > header field
> > > > > value for the
> > > > > sending interface?
> > > > > 
> > > > > In the case of our example, P would add both
> > > > 10.1.1.1 and 192.168.2.1
> > > > > 
> > > > > The result as I see it:
> > > > > 
> > > > 
> > > === message truncated ===
> > > 
> > > 
> > > __________________________________________________
> > > Do you Yahoo!?
> > > Faith Hill - Exclusive Performances, Videos & More 
> > > http://faith.yahoo.com 
> > _______________________________________________
> > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > This list is for NEW development of the core SIP Protocol
> > > Use sip-implementors@cs.columbia.edu for questions on current sip
> > > Use sipping@ietf.org for new developments on the 
> application of sip
> > > 
> > 
> > 
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Tue Oct 15 12:23:22 2002
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 MAA06478
	for <sip-archive@odin.ietf.org>; Tue, 15 Oct 2002 12:23:22 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9FGP5T25628
	for sip-archive@odin.ietf.org; Tue, 15 Oct 2002 12:25:05 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FGOEv25576;
	Tue, 15 Oct 2002 12:24:14 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FGNuv25520
	for <sip@optimus.ietf.org>; Tue, 15 Oct 2002 12:23:56 -0400
Received: from imr2.ericy.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06437
	for <sip@ietf.org>; Tue, 15 Oct 2002 12:21:42 -0400 (EDT)
Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157])
	by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g9FGNZg19119;
	Tue, 15 Oct 2002 11:23:35 -0500 (CDT)
Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1])
	by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g9FGNYO08033;
	Tue, 15 Oct 2002 11:23:34 -0500 (CDT)
Received: from eammlex033.lmc.ericsson.se (eammlex033.lmc.ericsson.se [142.133.1.133])
	by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id g9FGNYh04409;
	Tue, 15 Oct 2002 12:23:34 -0400 (EDT)
Received: by eammlex033.lmc.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <47YR7YKF>; Tue, 15 Oct 2002 12:22:56 -0400
Message-ID: <32CD630F6CBED411AE180008C7894CBC0C037ADC@lmc37.lmc.ericsson.se>
From: "George Foti (LMC)" <George.Foti@ericsson.ca>
To: "George Foti (LMC)" <George.Foti@lmc.ericsson.se>,
        "'Dean Willis'"
	 <dwillis@dynamicsoft.com>,
        "'Sean Olson'" <seancolson@yahoo.com>,
        "'John.Hearty@level3.com'" <John.Hearty@level3.com>,
        "'sip@ietf.org'"
	 <sip@ietf.org>
Cc: "'mankin@isi.edu'" <mankin@isi.edu>
Subject: RE: [Sip] Record-Route, Path, Service Route, and Multi-Homed Prox
	 ies
Date: Tue, 15 Oct 2002 12:23:32 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

Last line should read : that rewriting RR is unavoidable at all times.
Rgds/gf

> -----Original Message-----
> From: George Foti (LMC) 
> Sent: Tuesday, October 15, 2002 12:23 PM
> To: 'Dean Willis'; George Foti (LMC); 'Sean Olson';
> John.Hearty@level3.com; sip@ietf.org
> Cc: mankin@isi.edu
> Subject: RE: [Sip] Record-Route, Path, Service Route, and Multi-Homed
> Prox ies
> 
> 
> So what if we needed to do a re-write for SIGCOMP reasons, or 
> SIP/SIPS reasons.
> It seems that regarding RR is unavoidable.
> Rgds/gf
> 
> 
> > -----Original Message-----
> > From: Dean Willis [mailto:dwillis@dynamicsoft.com]
> > Sent: Tuesday, October 15, 2002 12:04 PM
> > To: 'George Foti (LMC)'; 'Sean Olson'; John.Hearty@level3.com;
> > sip@ietf.org
> > Cc: mankin@isi.edu
> > Subject: RE: [Sip] Record-Route, Path, Service Route, and 
> Multi-Homed
> > Prox ies
> > 
> > 
> > 
> > Yep, INSTEAD of doing the rewrite in the reponse phase, you 
> include 2
> > addresses (Record-Route header field values, to be technical) in the
> > request phase. 
> > 
> > --
> > Dean
> > 
> > > -----Original Message-----
> > > From: George Foti (LMC) [mailto:George.Foti@ericsson.ca] 
> > > Sent: Tuesday, October 15, 2002 6:53 AM
> > > To: 'Sean Olson'; John.Hearty@level3.com; 
> > > dwillis@dynamicsoft.com; sip@ietf.org
> > > Cc: mankin@isi.edu
> > > Subject: RE: [Sip] Record-Route, Path, Service Route, and 
> > > Multi-Homed Prox ies
> > > 
> > > 
> > > I read the proposal as everytime that you would have to do a 
> > > rewrite on a RR in a response you would have to include 2 
> addresses.
> > > 
> > > George Foti
> > > Ericsson Canada
> > > 
> > > > -----Original Message-----
> > > > From: Sean Olson [mailto:seancolson@yahoo.com]
> > > > Sent: Monday, October 14, 2002 8:28 PM
> > > > To: John.Hearty@level3.com; dwillis@dynamicsoft.com; 
> sip@ietf.org
> > > > Cc: mankin@isi.edu
> > > > Subject: RE: [Sip] Record-Route, Path, Service Route, and 
> > > Multi-Homed 
> > > > Prox ies
> > > > 
> > > > 
> > > > This should certainly work. It seems to be
> > > > more of an implementation detail than a
> > > > SIP protocol change. Is it proposed that all
> > > > multi-homed implementations would have to insert
> > > > two Record-Route: headers?
> > > > 
> > > > Sean Olson
> > > > Microsoft
> > > > 
> > > > --- John.Hearty@level3.com wrote:
> > > > > As I recall, I've already seen at least one vendor
> > > > > doing it the way you
> > > > > proposed, and it seemed to work OK.
> > > > > 
> > > > > John Hearty
> > > > > Level3
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Dean Willis [mailto:dwillis@dynamicsoft.com]
> > > > > > Sent: Monday, October 14, 2002 4:25 PM
> > > > > > To: sip@ietf.org
> > > > > > Cc: mankin@isi.edu
> > > > > > Subject: [Sip] Record-Route, Path, Service Route,
> > > > > and Multi-Homed
> > > > > > Proxies
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On the weird bits about SIP has always been "how
> > > > > to deal with
> > > > > > multi-homed proxies". This has begun to raise a
> > > > > mess of problems with
> > > > > > Path, Service-route, and a few other things I
> > > > > consider important (like
> > > > > > security).
> > > > > > 
> > > > > > Background
> > > > > > -----------
> > > > > > 
> > > > > > By multi-homed, I mean connected, like a router,
> > > > > to two or more
> > > > > > different networks, with an interface into each
> > > > > network, such that
> > > > > > traffic comes "in" one network and goes "out" a
> > > > > different one.
> > > > > > 
> > > > > > A simple model is shown here:
> > > > > > 
> > > > > > 
> > > > > >          /------- \         /------------\
> > > > > >         |   net1   |       |     net2    |
> > > > > > UA1-----| 10.1.1.0 |---P---| 192.168.1.0 |-----UA2
> > > > > > .2      | /25      | .1 .1 |  /24        |     .2
> > > > > >          \------- /         \------------/
> > > > > > 
> > > > > > 
> > > > > > UA1 has one interface with IP address 10.1.1.2
> > > > > > 
> > > > > > P has two interfaces and two addresses
> > > > > > 	-- 10.1.1.1
> > > > > > 	-- 192.168.2.1
> > > > > > 
> > > > > > And UA has one onterface and 1 address,
> > > > > 192.168.2.2
> > > > > > 
> > > > > > 
> > > > > > In other words, there IS no IP level route between
> > > > > UA1 and
> > > > > > UA2. No ping.
> > > > > > No traceroute. They live in entirely different
> > > > > networks.
> > > > > > 
> > > > > > But they can still exchange SIP, because P is a
> > > > > SIP Proxy.
> > > > > > 
> > > > > > This works in SIP because P can record-route.
> > > > > > 
> > > > > > -- On a request from UA1 (say, INVITE), toward UA2
> > > > > adds its interface
> > > > > > (the one facing UA2) to the Record-Route header
> > > > > field.
> > > > > > 
> > > > > > -- UA2 stores the set of Record-Route header field
> > > > > values in case it
> > > > > > wants to send a request trhough P to UA1 later.
> > > > > > 
> > > > > > -- UA2 replies to the request, including the
> > > > > received Record-Route
> > > > > > header field.
> > > > > > 
> > > > > > -- P edits the record-route header field value
> > > > > corresponding to its
> > > > > > interface facing UA2 and changes it to have the
> > > > > addressing value
> > > > > > associated with its interface facing UA1. This
> > > > > little blurb is buried
> > > > > > way down in the SIP spec -- we really don't talk
> > > > > about multihomed
> > > > > > proxies very much.
> > > > > > 
> > > > > > -- UA1 stores the Record-Route header field values
> > > > > in case it
> > > > > > ever wants
> > > > > > to talk to UA2 again.
> > > > > > 
> > > > > > The stored record-Route header field values are
> > > > > later used to
> > > > > > construct
> > > > > > Route header fields, which are inserted in furture
> > > > > requests (such as
> > > > > > BYE).
> > > > > > 
> > > > > > So far, so good. It works.
> > > > > > 
> > > > > > But there has been an odd thing: the route, as
> > > > > seen by UA1,
> > > > > > is entirely
> > > > > > different from the route as seen by UA2.
> > > > > > 
> > > > > > -- UA1 stored a route of 10.1.1.1
> > > > > > -- UA2 stored a route of 192.168.2.1
> > > > > > 
> > > > > > This odd thing has two serious implications:
> > > > > > 
> > > > > > 1) UA2 cannot sign the route set, because it gets
> > > > > edited by P in the
> > > > > > response. Consequently, end-to-end protection of
> > > > > the route set can not
> > > > > > be supported by the protocol. We've just broken
> > > > > the openness principle
> > > > > > and the end-to-end principle. Oops.
> > > > > > 
> > > > > > 2) P must implement special "multihomed" logic. On
> > > > > the
> > > > > > request phase, it
> > > > > > goes through output interface calculation and
> > > > > writes the output
> > > > > > interface into the route. It must then inspect all
> > > > > responses, grep for
> > > > > > an input interface, and selectively edit them to
> > > > > reference the correct
> > > > > > output interface. This is a CPU drag.
> > > > > > 
> > > > > > 
> > > > > > Implications for Path and Service-Route
> > > > > > ---------------------------------------
> > > > > > 
> > > > > > As currently written, the Path header field
> > > > > accumulates in the same
> > > > > > manner as Record-Route. It gets written on the
> > > > > request. The Path draft
> > > > > > doesn't say what happens for a multi-homed host,
> > > > > so we assume it works
> > > > > > like Record-Route (it does say that), so it gets
> > > > > set to the interface
> > > > > > facing the registrar. This works just fine for the
> > > > > documented
> > > > > > purpose of
> > > > > > path, finding the route from the registrar back to
> > > > > the UA.
> > > > > > 
> > > > > > But, people want to use the Path to calculate the
> > > > > route from
> > > > > > the UA to a
> > > > > > service proxy associated with the registrar
> > > > > (Service-Route).
> > > > > > Since only
> > > > > > the interfaces facing the registar are stored in
> > > > > Path, we have to use
> > > > > > configured information about the network to guess
> > > > > what the
> > > > > > "other" side
> > > > > > might be. This is not all that useful -- it
> > > > > requires lots of tricky
> > > > > > configuration. Tricky configuration is BAD when we
> > > > > have an
> > > > > > alternative.
> > > > > > 
> > > > > > One proposal is to let P edit Service-Route on the
> > > > > return stroke, just
> > > > > > like Record-Route. This would probably work, but
> > > > > conflicts with the
> > > > > > security requirements on Service-Route, requries
> > > > > special
> > > > > > behavior in P,
> > > > > > and so forth. In other words, its bad for all the
> > > > > same
> > > > > > reasons that the
> > > > > > Record-Route processing is bad, and then some.
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Suggestion -- Symmetrize the Route with In-Out
> > > > > Record-Routing
> > > > > >
> > > > >
> > > > -------------------------------------------------------------
> > > > > > 
> > > > > > What if proxies doing record-routing inserted a
> > > > > Record-Route header
> > > > > > field value for the receiving interface, and iff
> > > > > the sending interface
> > > > > > were different, inserted another Record-Route
> > > > > header field
> > > > > > value for the
> > > > > > sending interface?
> > > > > > 
> > > > > > In the case of our example, P would add both
> > > > > 10.1.1.1 and 192.168.2.1
> > > > > > 
> > > > > > The result as I see it:
> > > > > > 
> > > > > 
> > > > === message truncated ===
> > > > 
> > > > 
> > > > __________________________________________________
> > > > Do you Yahoo!?
> > > > Faith Hill - Exclusive Performances, Videos & More 
> > > > http://faith.yahoo.com 
> > > _______________________________________________
> > > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > > This list is for NEW development of the core SIP Protocol
> > > > Use sip-implementors@cs.columbia.edu for questions on 
> current sip
> > > > Use sipping@ietf.org for new developments on the 
> > application of sip
> > > > 
> > > 
> > > 
> > 
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Tue Oct 15 13:57:03 2002
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 NAA09714
	for <sip-archive@odin.ietf.org>; Tue, 15 Oct 2002 13:57:03 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9FHwln30395
	for sip-archive@odin.ietf.org; Tue, 15 Oct 2002 13:58:47 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FHw3v30367;
	Tue, 15 Oct 2002 13:58:03 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FHuXv30296
	for <sip@optimus.ietf.org>; Tue, 15 Oct 2002 13:56:33 -0400
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 NAA09581
	for <sip@ietf.org>; Tue, 15 Oct 2002 13:54:18 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id g9FHxEXi031230;
	Tue, 15 Oct 2002 12:59:15 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: "'George Foti \(LMC\)'" <George.Foti@ericsson.ca>, <sip@ietf.org>
Subject: RE: [Sip] Record-Route, Path, Service Route, and Multi-Homed Prox ies
Date: Tue, 15 Oct 2002 12:56:15 -0500
Message-ID: <004901c27474$286bffb0$fe0c0c42@TXDWILLIS2>
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
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <32CD630F6CBED411AE180008C7894CBC0C037ADB@lmc37.lmc.ericsson.se>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit


> 
> So what if we needed to do a re-write for SIGCOMP reasons, or 
> SIP/SIPS reasons. It seems that regarding RR is unavoidable. Rgds/gf
> 

Perhaps. Could you make the examples more obvious. I'm apparently
suffering from a clue deficiency this morning.

You need to change the record-route header field in response processing
to allow sigcomp? I would think one might compress the R-R like all
(other header fields) but I'm currently not cognizant of a situation
where it would need to be semantically analyzed and changed . . . Of
course I may just not be particularly cognizant at the moment, if ever.

--
Dean

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



From mailnull@www1.ietf.org  Tue Oct 15 14:20:37 2002
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 OAA10589
	for <sip-archive@odin.ietf.org>; Tue, 15 Oct 2002 14:20:37 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9FIMKK31762
	for sip-archive@odin.ietf.org; Tue, 15 Oct 2002 14:22:20 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FILwv31741;
	Tue, 15 Oct 2002 14:21:58 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FIKov31670
	for <sip@optimus.ietf.org>; Tue, 15 Oct 2002 14:20:50 -0400
Received: from imr1.ericy.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10518
	for <sip@ietf.org>; Tue, 15 Oct 2002 14:18:35 -0400 (EDT)
Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123])
	by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g9FIKfj19593;
	Tue, 15 Oct 2002 13:20:41 -0500 (CDT)
Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1])
	by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g9FIKeO17570;
	Tue, 15 Oct 2002 13:20:40 -0500 (CDT)
Received: from EAMMLEX034.lmc.ericsson.se (eammlex034.lmc.ericsson.se [142.133.1.134])
	by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id g9FIKeh11299;
	Tue, 15 Oct 2002 14:20:40 -0400 (EDT)
Received: by EAMMLEX034.lmc.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <47YTWK3N>; Tue, 15 Oct 2002 14:20:39 -0400
Message-ID: <32CD630F6CBED411AE180008C7894CBC0C037AE4@lmc37.lmc.ericsson.se>
From: "George Foti (LMC)" <George.Foti@ericsson.ca>
To: "'Dean Willis'" <dean.willis@softarmor.com>,
        "George Foti (LMC)"
	 <George.Foti@lmc.ericsson.se>, sip@ietf.org
Subject: RE: [Sip] Record-Route, Path, Service Route, and Multi-Homed Prox
	 ies
Date: Tue, 15 Oct 2002 14:20:35 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

Quoting RFC 3261, step 4 section 16.6 

         In a similar fashion, a proxy that receives a request
         over TLS, but generates a request without a SIPS URI in the
         Request-URI or topmost Route header field value (after the post
         processing of bullet 6), MUST insert a Record-Route header
         field that is not a SIPS URI.

         A proxy at a security perimeter must remain on the perimeter
         throughout the dialog.

         If the URI placed in the Record-Route header field needs to be
         rewritten when it passes back through in a response, the URI
         MUST be distinct enough to locate at that time.  (The request
         may spiral through this proxy, resulting in more than one
         Record-Route header field value being added).  Item 8 of
         Section 16.7 recommends a mechanism to make the URI
         sufficiently distinct.


Doesnt the above imply that if you come in a proxy over TLS and leave
without TLS and you RR that yyou need to rewrite RR coming back in
responses.





 Now quoting the SIGCOMP drafr from Gonzala revision 01

 5) Sending a Response to a Client

   A response is sent to the host in the sent-by parameter of the Via
   header field. If the topmost Via header field contains the parameter
   comp=sigcomp, the response SHOULD be compressed. Otherwise, the
   response MUST NOT be compressed.

   A proxy performing Record-Route inspects the Record-Route header
   field in the response and the Contact header field in the request
   that triggered this response (see example in Section 8). It looks for
   the URI of the next upstream (closer to the user agent client) hop in
   the route set. If this URI contains the parameter comp=sigcomp, the
   proxy SHOULD add comp=sigcomp to its entry in the Record-Route header
   field. If this URI does not contain the parameter comp=sigcomp, the
   proxy SHOULD remove comp=sigcomp (if it is present) from its entry in
   the Record-Route header field.

The above implies that we may to need to do rewrite of RR in the response.

So how do we deal with all the cases, will a proxy have to include both
addresses in the RR as well.
It was not clear to me from your initial e-mail on the topic.
Rgds/gf
 



> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]
> Sent: Tuesday, October 15, 2002 1:56 PM
> To: 'George Foti (LMC)'; sip@ietf.org
> Subject: RE: [Sip] Record-Route, Path, Service Route, and Multi-Homed
> Prox ies
> 
> 
> 
> > 
> > So what if we needed to do a re-write for SIGCOMP reasons, or 
> > SIP/SIPS reasons. It seems that regarding RR is unavoidable. Rgds/gf
> > 
> 
> Perhaps. Could you make the examples more obvious. I'm apparently
> suffering from a clue deficiency this morning.
> 
> You need to change the record-route header field in response 
> processing
> to allow sigcomp? I would think one might compress the R-R like all
> (other header fields) but I'm currently not cognizant of a situation
> where it would need to be semantically analyzed and changed . . . Of
> course I may just not be particularly cognizant at the 
> moment, if ever.
> 
> --
> Dean
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Tue Oct 15 14:32:11 2002
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 OAA11025
	for <sip-archive@odin.ietf.org>; Tue, 15 Oct 2002 14:32:11 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9FIXts32171
	for sip-archive@odin.ietf.org; Tue, 15 Oct 2002 14:33:55 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FIXLv32163;
	Tue, 15 Oct 2002 14:33:21 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9F5VRv14874
	for <sip@optimus.ietf.org>; Tue, 15 Oct 2002 01:31:27 -0400
Received: from mailman.packetdesign.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11746
	for <sip@ietf.org>; Tue, 15 Oct 2002 01:29:07 -0400 (EDT)
Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254])
	by mailman.packetdesign.com (8.12.3/8.11.6) with ESMTP id g9F5V4Eu084236;
	Mon, 14 Oct 2002 22:31:13 -0700 (PDT)
	(envelope-from casner@packetdesign.com)
Date: Mon, 14 Oct 2002 22:32:10 -0700 (PDT)
From: Stephen Casner <casner@packetdesign.com>
Reply-To: avt@ietf.org
To: sip@ietf.org
Message-ID: <20021014223127.R55120-100000@oak.packetdesign.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [Sip] Seeking input from G.726 ADPCM implementers
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

The IETF Audio/Video Transport working group is seeking input from
any implementers of systems using the G.726 ADPCM audio encoding, in
particular any that use the MIME audio subtypes G726-16, G726-24,
G726-32, and G726-40 or the RTP static paylod type 2 for G726-32.

This notice is being sent to multiple mailing lists to reach as many
interested parties as possible; please reply only to avt@ietf.org.

Background:

The AVT working group is seeking to advance the Real-time Transport
Protocol (RTP) and its associated Profile for A/V Conferences (RFCs
1889 and 1890, respectively) to Draft Standard status.  Two drafts
have been prepared to revise these RFCs for advancement:

    draft-ietf-avt-rtp-new-11.txt
    draft-ietf-avt-profile-new-12.txt

These drafts have been "tentatively approved" for publication by the
IESG.  In addition, a new companion draft has been approved for
publication as a Proposed Standard to specify MIME subtype
registrations for all the encoding names defined in the RTP Profile:

    draft-ietf-avt-rtp-mime-06.txt

Issue:

The packetization of G.726 audio specified in the RTP Profile packs
audio samples into octets beginning with the least-significant bit of
the octet.  This is at odds with the packetization of G.726 audio for
ATM AAL2 transport specified in ITU-T Recommendation I.366.2 Annex E,
which begins with the most-significant bit.  Implementers of systems
that operate with both transports or gateway between the two have
requested that the RTP packetization be changed to match the I.366.2
packetization to avoid requiring two different DSP implementations
and/or translation between packings.

Both specifications have existed for some time: I.366.2 has been an
approved standard since 1999, and the packing for the G726-32 rate has
been part of the RTP Profile drafts since 1997.  Therefore,
implementations of both packings are likely to exist.  Furthermore,
since the RTP Profile did not include packetizations for rates other
than 32K until 2001, some RTP implementations may have used the
I.366.2 packings for those rates.  As a consequence, there is no
course of action that will make everyone happy.

Proposal:

After consultation with the IETF Transport Area Directors, it is
proposed that the draft RTP Profile packetization be changed to be
consistent with I.366.2 Annex E before it is published as an RFC.  The
MIME subtype registrations for G726-16, G726-24, G726-32, and G726-40
in draft-ietf-avt-rtp-mime-06, which refer to the specification of the
packetizations in draft-ietf-avt-profile-new-12, would therefore
apply to the changed packetization.  In addition, RTP static payload
type 2, which is bound to the G726-32 encoding and packetization by
draft-ietf-avt-profile-new-12, would also change its meaning.

Consequences:

We have already heard from one vendor that has implemented the
packetizations according to the current RTP Profile draft and
therefore objects to the change.  Any such systems already in the
field would produce garbled audio when interoperated with
RFC-compliant implementations, and not detect the error.  This is a
significant consideration, although draft specifications are not
guaranteed to remain unchanged.

We have also been informed that the format for G.726 audio in the
Voice Profile for Internet Mail (RFC 2421/2) uses the same sample
packing as currently specified in the RTP Profile draft.  This is
consistent with ITU-T Recommendation X.420 for X.400 mail.  Since the
VPIM systems use MIME type audio/32KADPCM rather than audio/G726-32,
there would not be conflict in meaning if the latter were changed as
proposed.  However, voicemail systems that transmit messages over RTP
would be forced to reformat the data.

********************************************************************
*  We are seeking statements from interested parties both for and  *
*  against this proposal, particularly with motivations.           *
********************************************************************

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



From mailnull@www1.ietf.org  Tue Oct 15 14:55:20 2002
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 OAA11942
	for <sip-archive@odin.ietf.org>; Tue, 15 Oct 2002 14:55:20 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9FIv5r01231
	for sip-archive@odin.ietf.org; Tue, 15 Oct 2002 14:57:05 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FIuLv01219;
	Tue, 15 Oct 2002 14:56:21 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FIthv01162
	for <sip@optimus.ietf.org>; Tue, 15 Oct 2002 14:55:43 -0400
Received: from gamma.isi.edu (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11898;
	Tue, 15 Oct 2002 14:53:27 -0400 (EDT)
Received: from ISI.EDU (jet.isi.edu [128.9.160.87])
	by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id g9FItbD19589;
	Tue, 15 Oct 2002 11:55:37 -0700 (PDT)
Message-Id: <200210151855.g9FItbD19589@gamma.isi.edu>
To: IETF-Announce: ;
Cc: rfc-editor@rfc-editor.org, sip@ietf.org
From: rfc-editor@rfc-editor.org
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 15 Oct 2002 11:55:37 -0700
Subject: [Sip] RFC 3311 on The Session Initiation Protocol (SIP) UPDATE Method
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>


--NextPart


A new Request for Comments is now available in online RFC libraries.


        RFC 3311

        Title:      The Session Initiation Protocol (SIP)
                    UPDATE Method
        Author(s):  J. Rosenberg
        Status:     Standards Track
        Date:       October 2002
        Mailbox:    jdrosen@dynamicsoft.com
        Pages:      13
        Characters: 28125
        Updates/Obsoletes/SeeAlso:    None
                 
        I-D Tag:    draft-ietf-sip-update-02.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3311.txt


This specification defines the new UPDATE method for the Session
Initiation Protocol (SIP).  UPDATE allows a client to update
parameters of a session (such as the set of media streams and their
codecs) but has no impact on the state of a dialog.  In that sense,
it is like a re-INVITE, but unlike re-INVITE, it can be sent before
the initial INVITE has been completed.  This makes it very useful for
updating session parameters within early dialogs.

This document is a product of the Session Initiation Protocol Working
Group of the IETF.

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 
help: ways_to_get_rfcs.  For example:

        To: rfc-info@RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

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

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="RFC-INFO@RFC-EDITOR.ORG"

Content-Type: text/plain
Content-ID: <021015115326.RFC@RFC-EDITOR.ORG>

RETRIEVE: rfc
DOC-ID: rfc3311

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3311.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

Content-Type: text/plain
Content-ID: <021015115326.RFC@RFC-EDITOR.ORG>

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



From mailnull@www1.ietf.org  Tue Oct 15 15:16:39 2002
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 PAA12668
	for <sip-archive@odin.ietf.org>; Tue, 15 Oct 2002 15:16:39 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9FJIOr02548
	for sip-archive@odin.ietf.org; Tue, 15 Oct 2002 15:18:24 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FJHfv02528;
	Tue, 15 Oct 2002 15:17:41 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FJGKv02473
	for <sip@optimus.ietf.org>; Tue, 15 Oct 2002 15:16:20 -0400
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 PAA12527
	for <sip@ietf.org>; Tue, 15 Oct 2002 15:14:04 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id g9FJJ4Xi002367;
	Tue, 15 Oct 2002 14:19:05 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: "'George Foti \(LMC\)'" <George.Foti@ericsson.ca>, <sip@ietf.org>,
        "Gonzalo Camarillo" <Gonzalo.Camarillo@ericsson.com>
Subject: RE: [Sip] Record-Route, Path, Service Route, and Multi-Homed Prox ies
Date: Tue, 15 Oct 2002 14:16:03 -0500
Message-ID: <005301c2747f$4e457a80$fe0c0c42@TXDWILLIS2>
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
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <32CD630F6CBED411AE180008C7894CBC0C037AE4@lmc37.lmc.ericsson.se>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit


Excellent response. Thanks, George!


> -----Original Message-----
> From: George Foti (LMC) [mailto:George.Foti@ericsson.ca] 
> Sent: Tuesday, October 15, 2002 1:21 PM
> To: 'Dean Willis'; George Foti (LMC); sip@ietf.org
> Subject: RE: [Sip] Record-Route, Path, Service Route, and 
> Multi-Homed Prox ies
> 
> 
> Quoting RFC 3261, step 4 section 16.6 
> 
>          In a similar fashion, a proxy that receives a request
>          over TLS, but generates a request without a SIPS URI in the
>          Request-URI or topmost Route header field value 
> (after the post
>          processing of bullet 6), MUST insert a Record-Route header
>          field that is not a SIPS URI.
> 
>          A proxy at a security perimeter must remain on the perimeter
>          throughout the dialog.
> 
>          If the URI placed in the Record-Route header field 
> needs to be
>          rewritten when it passes back through in a response, the URI
>          MUST be distinct enough to locate at that time.  (The request
>          may spiral through this proxy, resulting in more than one
>          Record-Route header field value being added).  Item 8 of
>          Section 16.7 recommends a mechanism to make the URI
>          sufficiently distinct.
> 
> 
> Doesnt the above imply that if you come in a proxy over TLS 
> and leave without TLS and you RR that you need to rewrite RR 
> coming back in responses.
> 

Or that you have two RR entries -- one sips on the secure side, one sip
on the not-secure side. It's effectively like being dual-homed, even on
a single interface. Good catch, this will need to be made clear.

> 
> 
>  Now quoting the SIGCOMP drafr from Gonzalo revision 01
> 
>  5) Sending a Response to a Client
> 
>    A response is sent to the host in the sent-by parameter of the Via
>    header field. If the topmost Via header field contains the 
> parameter
>    comp=sigcomp, the response SHOULD be compressed. Otherwise, the
>    response MUST NOT be compressed.
> 
>    A proxy performing Record-Route inspects the Record-Route header
>    field in the response and the Contact header field in the request
>    that triggered this response (see example in Section 8). 
> It looks for
>    the URI of the next upstream (closer to the user agent 
> client) hop in
>    the route set. If this URI contains the parameter comp=sigcomp, the
>    proxy SHOULD add comp=sigcomp to its entry in the 
> Record-Route header
>    field. If this URI does not contain the parameter comp=sigcomp, the
>    proxy SHOULD remove comp=sigcomp (if it is present) from 
> its entry in
>    the Record-Route header field.
> 
> The above implies that we may to need to do rewrite of RR in 
> the response.

Hmm. Could this be accounted for by having "in" and "out" RR heaader
field values as proposed for sips and network adaptation? The one on the
compressed side would list sigcomp, the other one wouldn't. Gonzalo,
what do you think?
 
> So how do we deal with all the cases, will a proxy have to 
> include both addresses in the RR as well. It was not clear to 
> me from your initial e-mail on the topic. Rgds/gf

Good catch. On first thought, I THINK all of these cases can be dealt
with the same way -- by listing separate "in" and "out" Record-Route
header field values whenever they're not the same.

Proposed Rule: When a proxy Record-Routes and the route entering the
proxy differs (name, type, or parameters) from the route exiting the
proxy, the proxy should insert a record-route header field value for
each.

Other people probably know more. People?

--
Dean

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



From mailnull@www1.ietf.org  Tue Oct 15 15:23:47 2002
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 PAA12888
	for <sip-archive@odin.ietf.org>; Tue, 15 Oct 2002 15:23:47 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9FJPWg02855
	for sip-archive@odin.ietf.org; Tue, 15 Oct 2002 15:25:32 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FJPDv02844;
	Tue, 15 Oct 2002 15:25:13 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FJOJv02783
	for <sip@optimus.ietf.org>; Tue, 15 Oct 2002 15:24:19 -0400
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 PAA12857
	for <sip@ietf.org>; Tue, 15 Oct 2002 15:22:03 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id g9FJR4Xi002720;
	Tue, 15 Oct 2002 14:27:04 -0500
From: "Dean Willis" <dwillis@dynamicsoft.com>
To: "'Vijay K. Gurbani'" <vkg@lucent.com>
Cc: <sip@ietf.org>, <mankin@isi.edu>
Subject: RE: [Sip] Record-Route, Path, Service Route, and Multi-Homed Proxies
Date: Tue, 15 Oct 2002 14:24:03 -0500
Message-ID: <005901c27480$6c31e3c0$fe0c0c42@TXDWILLIS2>
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
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <3DAC400A.1030207@lucent.com>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

> > Well, the Service-Route specification is a "new" I-D.
> Actually, it's
> > completed WGLC and is awaiting final IESG review. Miguel
> and Gonzalo
> > raised some valid concerns that it is not as useful as they
> want. They
> > want to use it in conjunction with Path (currently in the rfc-ed 
> > queue). Path refers to Record-Route behavior. So the
> proposed behavior
> > would probably need to be described in the Service-Route draft in 
> > order to keep Service-Route from being blocked on 3261bis.
> 
> I was afraid you would say so.  Although, for whatever it is worth, I 
> really wish we would do it in rfc3261bis, but if we cannot, so be it. 
> Maybe, when the time comes, we can replicate whatever is in the 
> Service-Route draft on multi-homed proxies in rfc3261bis -- just to 
> keep information in one place.

Absolutely -- I would suggest we document this in 3261bis, but since we
need Service-Route before then, we also document it minimally in
Service-Route. If the writeup in Service-Route doesn't match with what
eventually happens in bis, then we'll need to update Service-Route at
that time.

--
Dean

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



From mailnull@www1.ietf.org  Wed Oct 16 04:01:41 2002
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 EAA21550
	for <sip-archive@odin.ietf.org>; Wed, 16 Oct 2002 04:01:41 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9G83WM17451
	for sip-archive@odin.ietf.org; Wed, 16 Oct 2002 04:03:32 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9G836v17421;
	Wed, 16 Oct 2002 04:03:06 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9G82Sv17380
	for <sip@optimus.ietf.org>; Wed, 16 Oct 2002 04:02:28 -0400
Received: from mta0 (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21531
	for <sip@ietf.org>; Wed, 16 Oct 2002 04:00:03 -0400 (EDT)
Received: from PRASANNA (mta0 [172.17.1.62])
 by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
 2002)) with ESMTPA id <0H42008A5E8QFN@mta0.huawei.com> for sip@ietf.org; Wed,
 16 Oct 2002 16:00:27 +0800 (CST)
Date: Wed, 16 Oct 2002 16:06:22 +0800
From: Prasanna <prasanna@huawei.com>
To: sip@ietf.org, schulzrinne@cs.columbia.edu
Cc: ranjit@huawei.com
Message-id: <KPEPLFDHIJPLNICJNCJJEEMOCCAA.prasanna@huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Content-Transfer-Encoding: 7BIT
Subject: [Sip] DHCP discovery for a REGISTRAR
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7BIT

Hi,
	Is there any way for a system to discover the REGISTRAR catering to that
domain using the DHCP procedures or is it expected that the domain registrar
will only be reachable by using sip.mcast.net?

Thanks and Regards,
Prasanna
Huawei Technologies.

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



From mailnull@www1.ietf.org  Wed Oct 16 04:57:41 2002
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 EAA21549
	for <sip-archive@odin.ietf.org>; Wed, 16 Oct 2002 04:01:41 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9G83Wf17439
	for sip-archive@odin.ietf.org; Wed, 16 Oct 2002 04:03:32 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9G82jv17390;
	Wed, 16 Oct 2002 04:02:45 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9G80cv17031
	for <sip@optimus.ietf.org>; Wed, 16 Oct 2002 04:00:39 -0400
Received: from mta0 (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21516
	for <sip@ietf.org>; Wed, 16 Oct 2002 03:58:13 -0400 (EDT)
Received: from PRASANNA (mta0 [172.17.1.62])
 by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
 2002)) with ESMTPA id <0H42008EZE4POL@mta0.huawei.com> for sip@ietf.org; Wed,
 16 Oct 2002 15:58:01 +0800 (CST)
Date: Wed, 16 Oct 2002 16:03:57 +0800
From: Prasanna <prasanna@huawei.com>
To: sip@ietf.org, schulzrinne@cs.columbia.edu, Gonzalo.Camarillo@ericsson.com,
        oran@cisco.com
Cc: ranjit@huawei.com
Message-id: <KPEPLFDHIJPLNICJNCJJOEMNCCAA.prasanna@huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Content-Transfer-Encoding: 7BIT
Subject: [Sip] definition of 155 (Update Requested) response code
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7BIT

Hi,
	Now that RFC-3311 (UPDATE) does not define the 155 response code, which
document defines the 155 response code.  As this is referred for HERFP in
the "reason" draft, is it proposed that the "reason" draft will define this
code.
Thanks and Regards,
Prasanna
Huawei Technologies.

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



From mailnull@www1.ietf.org  Wed Oct 16 10:22:18 2002
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 KAA00327
	for <sip-archive@odin.ietf.org>; Wed, 16 Oct 2002 10:22:18 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9GEO2x04715
	for sip-archive@odin.ietf.org; Wed, 16 Oct 2002 10:24:02 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GENHv04688;
	Wed, 16 Oct 2002 10:23:17 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GDb3v02179
	for <sip@optimus.ietf.org>; Wed, 16 Oct 2002 09:37:03 -0400
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 JAA28908
	for <sip@ietf.org>; Wed, 16 Oct 2002 09:34:45 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9GDaYQ1021355;
	Wed, 16 Oct 2002 15:36:34 +0200 (MEST)
Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.51])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g9GDaYG3015217;
	Wed, 16 Oct 2002 16:36:34 +0300 (EET DST)
Message-ID: <3DAD6B60.6C7403B5@lmf.ericsson.se>
Date: Wed, 16 Oct 2002 16:36:32 +0300
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: Dean Willis <dean.willis@softarmor.com>
CC: "'George Foti (LMC)'" <George.Foti@ericsson.ca>, sip@ietf.org
Subject: Re: [Sip] Record-Route, Path, Service Route, and Multi-Homed Prox ies
References: <005301c2747f$4e457a80$fe0c0c42@TXDWILLIS2>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Dean,

inline:

> >
> >  Now quoting the SIGCOMP drafr from Gonzalo revision 01
> >
> >  5) Sending a Response to a Client
> >
> >    A response is sent to the host in the sent-by parameter of the Via
> >    header field. If the topmost Via header field contains the
> > parameter
> >    comp=sigcomp, the response SHOULD be compressed. Otherwise, the
> >    response MUST NOT be compressed.
> >
> >    A proxy performing Record-Route inspects the Record-Route header
> >    field in the response and the Contact header field in the request
> >    that triggered this response (see example in Section 8).
> > It looks for
> >    the URI of the next upstream (closer to the user agent
> > client) hop in
> >    the route set. If this URI contains the parameter comp=sigcomp, the
> >    proxy SHOULD add comp=sigcomp to its entry in the
> > Record-Route header
> >    field. If this URI does not contain the parameter comp=sigcomp, the
> >    proxy SHOULD remove comp=sigcomp (if it is present) from
> > its entry in
> >    the Record-Route header field.
> >
> > The above implies that we may to need to do rewrite of RR in
> > the response.
> 
> Hmm. Could this be accounted for by having "in" and "out" RR heaader
> field values as proposed for sips and network adaptation? The one on the
> compressed side would list sigcomp, the other one wouldn't. Gonzalo,
> what do you think?

When SigComp is used, you need to re-write your RR header when the last
proxy that RRed added comp=SigComp and the next one will not use it.
 
Previous P           P                   Next P
   |                 |                     |
   |   compression   |  no compression     |

Your RR in the INVITE will be used for "Next P" to send you requests, so
it should not contain comp=sigcomp. Your RR in the 200 OK will be used
by "Previous P" to send you requests, so it should have comp=sigcomp.

If you use your double-RR trick, you could add comp=sigcomp to RR1
already in the INVITE and leave RR2 without comp=sigcomp. Everything
will work fine. However, you would be sending messages to yourself using
compression.

We could add a section about this in the SigComp-SIP draft so that
everything is clear. If a proxy is routing a message to itself, it would
be safe to ignore comp=sigcomp and "send" the request uncompressed.

Thanks,

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



From mailnull@www1.ietf.org  Wed Oct 16 10:30:27 2002
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 KAA00771
	for <sip-archive@odin.ietf.org>; Wed, 16 Oct 2002 10:30:27 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9GEWBv05463
	for sip-archive@odin.ietf.org; Wed, 16 Oct 2002 10:32:11 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GEVmv05331;
	Wed, 16 Oct 2002 10:31:48 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GEJIv04462
	for <sip@optimus.ietf.org>; Wed, 16 Oct 2002 10:19:18 -0400
Received: from tik2.ethz.ch (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00088
	for <sip@ietf.org>; Wed, 16 Oct 2002 10:17:03 -0400 (EDT)
Received: from ceid.upatras.gr (pc-3955.ethz.ch [129.132.66.94])
	by tik2.ethz.ch (8.8.8/8.8.8) with ESMTP id PAA10838
	for <sip@ietf.org>; Wed, 16 Oct 2002 15:35:41 +0200 (MET DST)
Message-ID: <3DAD6B14.1000608@ceid.upatras.gr>
Date: Wed, 16 Oct 2002 15:35:16 +0200
From: Kostas Katrinis <katrinis@ceid.upatras.gr>
Reply-To: katrinis@ceid.upatras.gr
Organization: TIK- ETH Zurich
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: sip@ietf.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Transport of conf control cmds using SIP msgs
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

	Hello to all,

actually I wanted to ask whether there is a specific guideline about 
using a specific type of SIP message to carry conference control 
commands (ex. SOAP payload), in case someone prefers to use an 
"all-SIPP" solution instead of using HTTP requests for carrying the 
mentioned commands.
(In a similar manner is the use of SUBSCRIBE/NOTIFY msgs for conference 
event propagation prescribed)

Thanks in advance,
Kostas Katrinis
ETH Zurich

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



From mailnull@www1.ietf.org  Wed Oct 16 11:44:34 2002
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 LAA03949
	for <sip-archive@odin.ietf.org>; Wed, 16 Oct 2002 11:44:34 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9GFkHJ11166
	for sip-archive@odin.ietf.org; Wed, 16 Oct 2002 11:46:17 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GFjLv11046;
	Wed, 16 Oct 2002 11:45:22 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GFhTv10962
	for <sip@optimus.ietf.org>; Wed, 16 Oct 2002 11:43:29 -0400
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 LAA03776
	for <sip@ietf.org>; Wed, 16 Oct 2002 11:41:15 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g9GFgXeS014334;
	Wed, 16 Oct 2002 11:42:33 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <S3Q8NYRA>; Wed, 16 Oct 2002 11:43:22 -0400
Message-ID: <1407568FD28578458C2F1FFFF30B82BB54952C@DYN-EXCH-001.dynamicsoft.com>
From: Igor Slepchin <ISlepchin@dynamicsoft.com>
To: "'Gonzalo Camarillo'" <Gonzalo.Camarillo@lmf.ericsson.se>,
        Dean Willis
	 <dean.willis@softarmor.com>
Cc: "'George Foti (LMC)'" <George.Foti@ericsson.ca>, sip@ietf.org
Subject: RE: [Sip] Record-Route, Path, Service Route, and Multi-Homed Prox
	 ies
Date: Wed, 16 Oct 2002 11:43:21 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

I think Dean's suggestion was that an optimizing proxy can detect itself in
the second Route and just do all the processing internally without sending
the request to the network ("processing" here would effectively mean just
popping that second Route header if I understand his proposal correctly).

As an aside, let me also say that I really like this proposal:) The only
potential problem I can see with it is that there might be situations when a
proxy would really send a request to itself doing somewhat different types
of processing the second time around and R-R both times. The optimizing
proxy may have problems determining if it can just pop the second Route
header or if it actually needs to do some additional processing. I guess if
the proxy is really optimizing, it could detect it's about to send the
request to itself and do all the processing internally the first time
around...

Thank you,
Igor Slepchin


> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
> <...>
> If you use your double-RR trick, you could add comp=sigcomp to RR1
> already in the INVITE and leave RR2 without comp=sigcomp. Everything
> will work fine. However, you would be sending messages to 
> yourself using
> compression.
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Thu Oct 17 01:00:50 2002
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 BAA21342
	for <sip-archive@odin.ietf.org>; Thu, 17 Oct 2002 01:00:50 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9H52eb20043
	for sip-archive@odin.ietf.org; Thu, 17 Oct 2002 01:02:40 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9H50Bv19981;
	Thu, 17 Oct 2002 01:00:11 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9H4rdv19817
	for <sip@optimus.ietf.org>; Thu, 17 Oct 2002 00:53:39 -0400
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 AAA21254
	for <sip@ietf.org>; Thu, 17 Oct 2002 00:51:19 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.14])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g9H4rOYH012206;
	Thu, 17 Oct 2002 00:53:25 -0400 (EDT)
Message-ID: <3DAE4242.4070903@dynamicsoft.com>
Date: Thu, 17 Oct 2002 00:53:22 -0400
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: Dean Willis <dean.willis@softarmor.com>
CC: "'George Foti (LMC)'" <George.Foti@ericsson.ca>, sip@ietf.org,
        Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Subject: Re: [Sip] Record-Route, Path, Service Route, and Multi-Homed Prox
 ies
References: <005301c2747f$4e457a80$fe0c0c42@TXDWILLIS2>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Dean,

Generally, I too like this proposal. As has been pointed out, folks have 
done it already as an implementation choice, as its backwards compatible.

My only real concern is the strength of this solution (MUST/MAY). I'd 
rather it be a MAY, and that would be consistent with 3261. However, the 
interesting bit is that Path specifies that you SHOULD NOT modify the 
Path in the response, and discusses protecting it with SMIME. Bis, on 
the other hand, explicitly says that since record-route can be changed 
by proxies, you shouldn't worry about modifications to it. So, from the 
path perspective, a MUST or SHOULD on your mechanism would make sense, 
in order to meet the security requirements that are already there.

So, its kind of odd that we have these divergent behaviors for path and 
record-route, even though they are supposed to be more or less the same. 
  If the goal is to unify them, then we need to have MAY for both. If 
the goal is to be consistent with whats there, your new I-D would have 
to specify SHOULD usage for path/service route, and MAY for 3261. Kind 
of ugly.

Oh - one other point. The only case in which your proposal WONT work is 
when the proxy needs to insert an RR into the response based on 
information in the response. I can't offhand think of a scenario for 
this, but certainly its possible. By still allowing the modification of 
the Path/RR, you could handle these cases.

We'll need to add some text about this in 3261bis when the time comes, 
and fix some of the MUSTS that have been poitned out by George. We'll 
log them into bugzilla.


-Jonathan R.

Dean Willis wrote:
> Excellent response. Thanks, George!
> 
> 
> 
>>-----Original Message-----
>>From: George Foti (LMC) [mailto:George.Foti@ericsson.ca] 
>>Sent: Tuesday, October 15, 2002 1:21 PM
>>To: 'Dean Willis'; George Foti (LMC); sip@ietf.org
>>Subject: RE: [Sip] Record-Route, Path, Service Route, and 
>>Multi-Homed Prox ies
>>
>>
>>Quoting RFC 3261, step 4 section 16.6 
>>
>>         In a similar fashion, a proxy that receives a request
>>         over TLS, but generates a request without a SIPS URI in the
>>         Request-URI or topmost Route header field value 
>>(after the post
>>         processing of bullet 6), MUST insert a Record-Route header
>>         field that is not a SIPS URI.
>>
>>         A proxy at a security perimeter must remain on the perimeter
>>         throughout the dialog.
>>
>>         If the URI placed in the Record-Route header field 
>>needs to be
>>         rewritten when it passes back through in a response, the URI
>>         MUST be distinct enough to locate at that time.  (The request
>>         may spiral through this proxy, resulting in more than one
>>         Record-Route header field value being added).  Item 8 of
>>         Section 16.7 recommends a mechanism to make the URI
>>         sufficiently distinct.
>>
>>
>>Doesnt the above imply that if you come in a proxy over TLS 
>>and leave without TLS and you RR that you need to rewrite RR 
>>coming back in responses.
>>
> 
> 
> Or that you have two RR entries -- one sips on the secure side, one sip
> on the not-secure side. It's effectively like being dual-homed, even on
> a single interface. Good catch, this will need to be made clear.
> 
> 
>>
>> Now quoting the SIGCOMP drafr from Gonzalo revision 01
>>
>> 5) Sending a Response to a Client
>>
>>   A response is sent to the host in the sent-by parameter of the Via
>>   header field. If the topmost Via header field contains the 
>>parameter
>>   comp=sigcomp, the response SHOULD be compressed. Otherwise, the
>>   response MUST NOT be compressed.
>>
>>   A proxy performing Record-Route inspects the Record-Route header
>>   field in the response and the Contact header field in the request
>>   that triggered this response (see example in Section 8). 
>>It looks for
>>   the URI of the next upstream (closer to the user agent 
>>client) hop in
>>   the route set. If this URI contains the parameter comp=sigcomp, the
>>   proxy SHOULD add comp=sigcomp to its entry in the 
>>Record-Route header
>>   field. If this URI does not contain the parameter comp=sigcomp, the
>>   proxy SHOULD remove comp=sigcomp (if it is present) from 
>>its entry in
>>   the Record-Route header field.
>>
>>The above implies that we may to need to do rewrite of RR in 
>>the response.
> 
> 
> Hmm. Could this be accounted for by having "in" and "out" RR heaader
> field values as proposed for sips and network adaptation? The one on the
> compressed side would list sigcomp, the other one wouldn't. Gonzalo,
> what do you think?
>  
> 
>>So how do we deal with all the cases, will a proxy have to 
>>include both addresses in the RR as well. It was not clear to 
>>me from your initial e-mail on the topic. Rgds/gf
> 
> 
> Good catch. On first thought, I THINK all of these cases can be dealt
> with the same way -- by listing separate "in" and "out" Record-Route
> header field values whenever they're not the same.
> 
> Proposed Rule: When a proxy Record-Routes and the route entering the
> proxy differs (name, type, or parameters) from the route exiting the
> proxy, the proxy should insert a record-route header field value for
> each.
> 
> Other people probably know more. People?
> 
> --
> Dean
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of 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

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



From mailnull@www1.ietf.org  Thu Oct 17 01:23:36 2002
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 BAA21757
	for <sip-archive@odin.ietf.org>; Thu, 17 Oct 2002 01:23:35 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9H5PPk21402
	for sip-archive@odin.ietf.org; Thu, 17 Oct 2002 01:25:25 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9H5Ogv21323;
	Thu, 17 Oct 2002 01:24:42 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9H5Gvv21011
	for <sip@optimus.ietf.org>; Thu, 17 Oct 2002 01:16:57 -0400
Received: from btlmail.bplmail.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21603
	for <sip@ietf.org>; Thu, 17 Oct 2002 01:14:27 -0400 (EDT)
Received: from [10.10.13.58] (helo=RKUMAR)
	by btlmail.bplmail.com with smtp (Exim 3.22 #1 (Red Hat Linux))
	id 18231C-0000mu-00; Thu, 17 Oct 2002 10:46:22 +0530
Reply-To: <ranjit.avasarala@bplmail.com>
From: "Ranjit Kumar Avasarala" <ranjit.avasarala@bplmail.com>
To: "Prasanna" <prasanna@huawei.com>, <sip@ietf.org>,
        <schulzrinne@cs.columbia.edu>
Cc: <ranjit@huawei.com>
Subject: RE: [Sip] DHCP discovery for a REGISTRAR
Date: Thu, 17 Oct 2002 10:47:13 +0530
Message-ID: <GGEKLACDJCBAOANBIIIFGEAECBAA.ranjit.avasarala@bplmail.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.2910.0)
Importance: Normal
In-Reply-To: <KPEPLFDHIJPLNICJNCJJEEMOCCAA.prasanna@huawei.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi
   Currently there is no mechanism in SIP for REGISTRAR discovery in SIP.

Ranjit

-----Original Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of
Prasanna
Sent: Wednesday, October 16, 2002 1:36 PM
To: sip@ietf.org; schulzrinne@cs.columbia.edu
Cc: ranjit@huawei.com
Subject: [Sip] DHCP discovery for a REGISTRAR


Hi,
	Is there any way for a system to discover the REGISTRAR catering to that
domain using the DHCP procedures or is it expected that the domain registrar
will only be reachable by using sip.mcast.net?

Thanks and Regards,
Prasanna
Huawei Technologies.

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

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



From mailnull@www1.ietf.org  Thu Oct 17 08:38:58 2002
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 IAA08156
	for <sip-archive@odin.ietf.org>; Thu, 17 Oct 2002 08:38:58 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9HCefg19594
	for sip-archive@odin.ietf.org; Thu, 17 Oct 2002 08:40:41 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HCdZv19477;
	Thu, 17 Oct 2002 08:39:35 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HCbNv19275
	for <sip@optimus.ietf.org>; Thu, 17 Oct 2002 08:37:23 -0400
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 IAA08008
	for <sip@ietf.org>; Thu, 17 Oct 2002 08:35:10 -0400 (EDT)
Received: from cs.columbia.edu ([12.84.131.236])
          by mtiwmhc12.worldnet.att.net
          (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP
          id <20021017123710.HFDF6348.mtiwmhc12.worldnet.att.net@cs.columbia.edu>;
          Thu, 17 Oct 2002 12:37:10 +0000
Message-ID: <3DAEAE95.4010404@cs.columbia.edu>
Date: Thu, 17 Oct 2002 08:35:33 -0400
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: ranjit.avasarala@bplmail.com
CC: Prasanna <prasanna@huawei.com>, sip@ietf.org, ranjit@huawei.com
Subject: Re: [Sip] DHCP discovery for a REGISTRAR
References: <GGEKLACDJCBAOANBIIIFGEAECBAA.ranjit.avasarala@bplmail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

And there is no real need for it. If you know your name, you know your 
registrar: alice@example.com has a registrar at example.com. Alice sends 
her REGISTER to that as if she was addressing a regular address, using 
whatever outbound proxies may be required.

Ranjit Kumar Avasarala wrote:
> Hi
>    Currently there is no mechanism in SIP for REGISTRAR discovery in SIP.
> 
> Ranjit
> 
> -----Original Message-----
> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of
> Prasanna
> Sent: Wednesday, October 16, 2002 1:36 PM
> To: sip@ietf.org; schulzrinne@cs.columbia.edu
> Cc: ranjit@huawei.com
> Subject: [Sip] DHCP discovery for a REGISTRAR
> 
> 
> Hi,
> 	Is there any way for a system to discover the REGISTRAR catering to that
> domain using the DHCP procedures or is it expected that the domain registrar
> will only be reachable by using sip.mcast.net?
> 
> Thanks and Regards,
> Prasanna
> Huawei Technologies.
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip

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



From mailnull@www1.ietf.org  Thu Oct 17 19:24:00 2002
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 TAA29218
	for <sip-archive@odin.ietf.org>; Thu, 17 Oct 2002 19:24:00 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9HNPnA27743
	for sip-archive@odin.ietf.org; Thu, 17 Oct 2002 19:25:49 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HNP2v27721;
	Thu, 17 Oct 2002 19:25:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HNMXv27659
	for <sip@optimus.ietf.org>; Thu, 17 Oct 2002 19:22:33 -0400
Received: from gamma.isi.edu (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29155;
	Thu, 17 Oct 2002 19:20:12 -0400 (EDT)
Received: from ISI.EDU (jet.isi.edu [128.9.160.87])
	by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id g9HNMOD11283;
	Thu, 17 Oct 2002 16:22:24 -0700 (PDT)
Message-Id: <200210172322.g9HNMOD11283@gamma.isi.edu>
To: IETF-Announce: ;
Cc: rfc-editor@rfc-editor.org, sip@ietf.org
From: rfc-editor@rfc-editor.org
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 17 Oct 2002 16:22:24 -0700
Subject: [Sip] RFC 3312 on Integration of Resource Management and Session Initiation Protocol (SIP)
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>


--NextPart


A new Request for Comments is now available in online RFC libraries.


        RFC 3312
                 
        Title:      Integration of Resource Management
                    and Session Initiation Protocol (SIP)
        Author(s):  G. Camarillo, Ed., W. Marshall, Ed., J. Rosenberg
        Status:     Standards Track
        Date:       October 2002
        Mailbox:    Gonzalo.Camarillo@ericsson.com,
                    wtm@research.att.com, jdrosen@dynamicsoft.com
        Pages:      30
        Characters: 65757
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-sip-manyfolks-resource-07.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3312.txt


This document defines a generic framework for preconditions, which are
extensible through IANA registration.  This document also discusses
how network quality of service can be made a precondition for
establishment of sessions initiated by the Session Initiation
Protocol (SIP).  These preconditions require that the participant
reserve network resources before continuing with the session.  We do
not define new quality of service reservation mechanisms; these
preconditions simply require a participant to use existing resource
reservation mechanisms before beginning the session.

This document is a product of the Session Initiation Protocol Working
Group of the IETF.

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 
help: ways_to_get_rfcs.  For example:

        To: rfc-info@RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

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

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="RFC-INFO@RFC-EDITOR.ORG"

Content-Type: text/plain
Content-ID: <021017162036.RFC@RFC-EDITOR.ORG>

RETRIEVE: rfc
DOC-ID: rfc3312

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3312.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

Content-Type: text/plain
Content-ID: <021017162036.RFC@RFC-EDITOR.ORG>

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



From mailnull@www1.ietf.org  Fri Oct 18 03:39:23 2002
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 DAA17779
	for <sip-archive@odin.ietf.org>; Fri, 18 Oct 2002 03:39:23 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9I7fFw28471
	for sip-archive@odin.ietf.org; Fri, 18 Oct 2002 03:41:15 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9I7e4v28426;
	Fri, 18 Oct 2002 03:40:04 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9I7aBv27741
	for <sip@optimus.ietf.org>; Fri, 18 Oct 2002 03:36:11 -0400
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 DAA17651
	for <sip@ietf.org>; Fri, 18 Oct 2002 03:33:44 -0400 (EDT)
From: mchauhan@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 g9I7KEi01728
	for <sip@ietf.org>; Fri, 18 Oct 2002 12:50:15 +0530
Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 65256C56.0029A3D3 ; Fri, 18 Oct 2002 13:04:49 +0530
X-Lotus-FromDomain: HSSBLR
To: "Sip" <sip@ietf.org>
Message-ID: <65256C56.0029A1E1.00@sampark.hss.hns.com>
Date: Fri, 18 Oct 2002 13:03:32 +0530
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: [Sip] BNF for Accept-Contact Header
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>



Hi,

According to the draft "draft-ietf-sip-callerprefs-06.txt" , the grammar of
the Accept-Contact and Reject-Contact header is as follows:

        Accept-Contact  =  ("Accept-Contact" / "a") HCOLON feature-set
*(COMMA feature-set)
        Reject-Contact  =  ("Reject-Contact" / "j") HCOLON feature-set
*(COMMA feature-set)
        feature-set     =  ( name-addr / addr-spec / "*")   *(SEMI tag-set)
 [q-param]
        tag-set         =  feature-tag EQUAL (tag-value-list |
string-value)
        tag-value-list  =  LDQUOT ["!"] tag-values RDQUOT
        feature-tag     =  ftag ; From RFC 2533
        tag-values      =  tag-value *("," tag-value)
        tag-value       =  boolean / number / token
        boolean         =  "TRUE" / "FALSE"
        number          =  integer / rational
        integer         =  [ "+" / "-" ] 1*DIGIT
        rational        =  [ "+" / "-" ] 1*DIGIT "/" 1*DIGIT
        string-value    =  quoted-string
        q-param         =  "q" EQUAL qvalue

In the feature-set field, there is no separator between tag-set and
q-param. Whereas the "draft-ietf-sip-callerprefs-05.txt" defines SEMICOLON
as
the separator. Is it a mistake in the grammar ? Please correct me if I am
wrong.

Thanks
Manoj Chauhan
Hughes Software Systems


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



From mailnull@www1.ietf.org  Fri Oct 18 08:48:15 2002
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 IAA23666
	for <sip-archive@odin.ietf.org>; Fri, 18 Oct 2002 08:48:15 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9ICnwA12654
	for sip-archive@odin.ietf.org; Fri, 18 Oct 2002 08:49:58 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ICnWv12644;
	Fri, 18 Oct 2002 08:49:33 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IClvv12563
	for <sip@optimus.ietf.org>; Fri, 18 Oct 2002 08:47:57 -0400
Received: from fsnt.future.futsoft.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23575
	for <sip@ietf.org>; Fri, 18 Oct 2002 08:45:40 -0400 (EDT)
Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com
 (Content Technologies SMTPRS 2.0.15) with ESMTP id <B0003473819@fsnt.future.futsoft.com> for <sip@ietf.org>;
 Fri, 18 Oct 2002 18:10:19 +0530
Received: from sheela (sheela.future.futsoft.com [10.6.2.37])
	by kailash.future.futsoft.com (8.12.2/8.12.2) with SMTP id g9ICaLJG028259
	for <sip@ietf.org>; Fri, 18 Oct 2002 18:06:21 +0530
Reply-To: <sheela@future.futsoft.com>
From: "Sheela K" <sheela@future.futsoft.com>
To: <sip@ietf.org>
Date: Fri, 18 Oct 2002 18:12:48 +0530
Message-Id: <001901c276a3$ddd58520$2502060a@future.futsoft.com>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Importance: Normal
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Location Service!!
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi All,

I have some clarifications on the features supported by SIP network
element,Location service.

1) Will Location service maintain only the address bindings for a single
domain where it is located (or) it will maintain for all of the possible
domains?
2) If a UAC/Proxy needs to reach a user who is in a different domain, how it
is handled by UAC/Proxy. What mechanism the UAC/Proxy possibly should use
for this kind of situation? How the SIP URI is resolved and used to reach
the destination?

Please clarify my doubts.

Thanks and Regards,
Sheela


***************************************************************************
This message is proprietary to Future Software Limited (FSL) 
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. 
FSL accepts no responsibility for loss or damage arising from 
the use of the information transmitted by this email including
damage from virus.
***************************************************************************
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Sat Oct 19 15:52:35 2002
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 PAA06880
	for <sip-archive@odin.ietf.org>; Sat, 19 Oct 2002 15:52:35 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9JJsN608545
	for sip-archive@odin.ietf.org; Sat, 19 Oct 2002 15:54:23 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9JJs3v08535;
	Sat, 19 Oct 2002 15:54:03 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9I8Vvv31259
	for <sip@optimus.ietf.org>; Fri, 18 Oct 2002 04:31:57 -0400
Received: from caduceus.fm.intel.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18763
	for <sip@ietf.org>; Fri, 18 Oct 2002 04:29:29 -0400 (EDT)
Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39])
	by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id g9I8RmL29714
	for <sip@ietf.org>; Fri, 18 Oct 2002 08:27:48 GMT
Received: from fmsmsxv040-1.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124])
	by talaria.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.27 2002/10/16 23:46:59 dmccart Exp $) with SMTP id g9I8YZ819108
	for <sip@ietf.org>; Fri, 18 Oct 2002 08:34:35 GMT
Received: from fmsmsx26.fm.intel.com ([132.233.42.26])
 by fmsmsxv040-1.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002101801321520762
 for <sip@ietf.org>; Fri, 18 Oct 2002 01:32:15 -0700
Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <VB7S6DWH>; Fri, 18 Oct 2002 01:31:40 -0700
Message-ID: <12B638FEE763F74696D8544752E7204801BACB58@bgsmsx101.iind.intel.com>
From: "Kaul, Amit" <amit.kaul@intel.com>
To: "'sip@ietf.org'" <sip@ietf.org>
Date: Fri, 18 Oct 2002 01:27:05 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sip] Subscribe/Notify and Refer/Notify
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

Hi,

I have following doubts in the Subscribe/Notify and Refer/Notify drafts :

i) As per the Subsc/Notify draft, Subscriber should be able to receive
   NOTIFY before receiving 2xx. Also, it shall create a new
subscription/dialog
   when it receives NOTIFY.

   Consider a scenario like this :

 |                 			SUBS
 | **Subsc. Trans. 
 | tmr. starts        	--------------------------->
 |                  			NOTIFY(ss: active)
 |         		 	<--------------------------
 |                   	
 |   *Subsc./Dialog
 |     created               		2xx(Notify)
 |			--------------------------->
 |
 \/  **Subsc. Trans. Tmr
        Times out : NO
        final response for SUBS
        is recvd.

In this case, subscription and dialog are created before getting 2xx for the
intial SUBSCRIBE.
However, if Subscriber doesn't get any final response and the transaction
timer for SUBSCRIBE
transaction times out, what should be the action on the part of subscriber :
a) Remove the subscription
b) Keep the subscription and remove the SUBSCRIBE transaction gracefully.

ii) As per the Refer/Notify draft, the subscription expiry time, before the
Subscriber gets NOTIFY
   depends on "Refer-To" header.

  E.g., in the draft, this line is mentioned :
    Subscription-State: active;expires=(depends on Refer-To URI)
   a) What exactly is meant by this ? 

   b) If no NOTIFY is received before the REFER (Refer/2xx) transaction
times  out, does that mean that subscription/dialog
   is automatically removed ? OR is subscriber supposed to wait for the
NOTIFY till some "Configured" time ?

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



From mailnull@www1.ietf.org  Sat Oct 19 15:52:36 2002
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 PAA06893
	for <sip-archive@odin.ietf.org>; Sat, 19 Oct 2002 15:52:36 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9JJsO608557
	for sip-archive@odin.ietf.org; Sat, 19 Oct 2002 15:54:24 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9JJrlv08512;
	Sat, 19 Oct 2002 15:53:47 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9H77uv02611
	for <sip@optimus.ietf.org>; Thu, 17 Oct 2002 03:07:56 -0400
Received: from globaledgesoft.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02608
	for <sip@ietf.org>; Thu, 17 Oct 2002 03:04:53 -0400 (EDT)
Received: from gesl [172.16.2.101]
	by globaledgesoft.com [172.16.2.3]
	with SMTP (MDaemon.PRO.v5.0.0.R)
	for <sip@ietf.org>; Thu, 17 Oct 2002 12:45:17 +0530
Message-ID: <000701c0399a$ca7e5e40$650210ac@ddsl>
From: "satya" <satyakumar@globaledgesoft.com>
To: <sip@ietf.org>
Cc: <sip-implementors@cs.columbia.edu>, <jo@ipdialog.com>,
        <brian.rosen@marconi.com>, <dean.willis@softarmor.com>
Date: Thu, 19 Oct 2000 12:34:13 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0004_01C039C8.E37DF8A0"
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
X-MDRemoteIP: 172.16.2.101
X-Return-Path: satyakumar@globaledgesoft.com
X-MDaemon-Deliver-To: sip@ietf.org
Subject: [Sip] a doubt in SIP header (call-id)
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0004_01C039C8.E37DF8A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,
=20
    SUB: a doubt in SIP header (call-id)=20

I had faced one problem when i'm testing my company's inhouse product, =
which is implementing SIP.

Here my role is : =20
        To test the parser modules ---- which are written for headers in =
SIP like ----  call-id, to, from, via, contact,=20
                contact-length, cseq......
        When i'm trying to test the call-id module... i gave a header =
like the following one
              Call-ID: 87602@141351@worcester.bell-telephone.com=20
               =20
                it is parsed with local-id as  87602  and
                                        host      as  =
141351@worcester.bell-telephone.com=20

                but what is I expect was=20
                                        local-id as  87602@141351  and=20
                                        host      as  =
worcester.bell-telephone.com=20


since as per the rfc 2543....... I can give the 'reserved' letter '@'  =
in local-id. =20
-------------------------------------------------------------------------=
-------------------------------------------------------------------------=
----------                                =20
Call-ID =3D ( "Call-ID" | "i" ) ":" local-id "@" host

local-id =3D 1*uric

uric =3D reserved | unreserved | escaped

reserved =3D ";" | "/" | "?" | ":" | "@" | "&" | "=3D" | "+" | "$" | ","

unreserved =3D alphanum | mark

mark =3D "-" | "_" | "." | "!" | "~" | "*" | "'" | "(" | ")"

escaped =3D "%" hex hex

alphanum =3D alpha | digit

digit =3D "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"

alpha =3D lowalpha | upalpha

upalpha =3D "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J" | =
"K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" | "T" | "U" | "V" | =
"W" | "X" | "Y" | "Z"

lowalpha =3D "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" |"j" | =
"k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" |"s" | "t" | "u" | "v" | =
"w" | "x" | "y" | "z"

hex =3D "A" | "B" | "C" | "D" | "E" | "F"| "a" | "b" | "c" | "d" | "e" | =
"f" | digit

-------------------------------------------------------------------------=
-------------------------------------------------------------------------=
---------------------------------


So my doubt was " whether the reserved letter @ can be used in the =
local-id  part of call-id header or not"   ......  could u please =
clarify.. this issue....

Please find some time to clear this....I'll be greatful to u...

Regards,
Senapathy T.
( please reply to  tsenapathy@rediffmail.com  or =
srinand@globaledgesoft.com )




------=_NextPart_000_0004_01C039C8.E37DF8A0
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><FONT face=3DArial size=3D2>Hi,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
<STRONG><U>SUB</U></STRONG>: a=20
doubt in SIP header (call-id) </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I had faced one problem when =
i'</FONT><FONT=20
face=3DArial size=3D2>m testing my company's inhouse product, which is =
implementing=20
<STRONG><U>SIP</U></STRONG>.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Here my role is :&nbsp; </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
To test=20
the&nbsp;parser modules ---- which are written for headers&nbsp;in SIP =
like=20
----&nbsp; call-id, to, from, via, contact, </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; contact-length, =
cseq......</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
When i'm=20
trying to test the call-id module... i gave a header like the following=20
one</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;<FONT=20
size=3D2><A=20
href=3D"mailto:Call-ID: =
87602@141351@worcester.bell-telephone.com">Call-ID:=20
87602@141351@worcester.bell-telephone.com</A></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; it is parsed with <STRONG>local-id =

</STRONG>as<STRONG>&nbsp; 87602&nbsp; </STRONG>and</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;=20
<STRONG>host&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </STRONG>as&nbsp; <STRONG><A=20
href=3D"mailto:141351@worcester.bell-telephone.com">141351@worcester.bell=
-telephone.com</A>&nbsp;</STRONG></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; but what is I expect was =
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;=20
<STRONG>local-id </STRONG>as<STRONG>&nbsp; =
87602@1<STRONG>41351</STRONG>&nbsp;=20
</STRONG>and=20
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;=20
<STRONG>host&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </STRONG>as&nbsp; <STRONG><A=20
href=3D"mailto:141351@worcester.bell-telephone.com">worcester.bell-teleph=
one.com</A>&nbsp;</STRONG></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>since as per the rfc 2543....... I can give the =
'<STRONG>reserved</STRONG>'=20
letter <STRONG>'@'</STRONG>&nbsp; in local-id.&nbsp;&nbsp;</DIV>
<DIV>--------------------------------------------------------------------=
-------------------------------------------------------------------------=
---------------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</DIV>
<DIV><FONT size=3D2>
<P><STRONG>Call-ID =3D ( "Call-ID" | "i" ) ":" local-id "@" =
host</STRONG></P>
<P>local-id =3D 1*uric</P><FONT size=3D2>
<P>uric =3D reserved | unreserved | escaped</P>
<P>reserved =3D ";" | "/" | "?" | ":" | "@" | "&amp;" | "=3D" | "+" | =
"$" |=20
","</P></FONT></FONT></DIV>
<DIV><FONT size=3D2>
<P>unreserved =3D alphanum | mark</P>
<P>mark =3D "-" | "_" | "." | "!" | "~" | "*" | "'" | "(" | ")"</P>
<P>escaped =3D "%" hex hex</P><FONT size=3D2>
<P>alphanum =3D alpha | digit</P><FONT size=3D2>
<P>digit =3D "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | =
"9"</P>
<P>alpha =3D lowalpha | =
upalpha</FONT></FONT></FONT></P></DIV></FONT></DIV>
<DIV><FONT size=3D2>
<P><FONT size=3D1><FONT size=3D3>upalpha </FONT>=3D "A" | "B" | "C" | =
"D" | "E" | "F"=20
| "G" | "H" | "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" =
| "S" |=20
"T" | "U" | "V" | "W" | "X" | "Y" | "Z"</FONT></P>
<P><FONT size=3D3>lowalpha </FONT>=3D "a" | "b" | "c" | "d" | "e" | "f" =
| "g" | "h"=20
| "i" |"j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" |"s" | "t" | =
"u" |=20
"v" | "w" | "x" | "y" | "z"</P><FONT size=3D2>
<P>hex =3D "A" | "B" | "C" | "D" | "E" | "F"| "a" | "b" | "c" | "d" | =
"e" | "f" |=20
digit</P>
<P><FONT=20
face=3DArial>------------------------------------------------------------=
-------------------------------------------------------------------------=
----------------------------------------------</FONT></P></FONT></FONT></=
DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>So my doubt was <STRONG>" whether the =
<U>reserved=20
letter @ </U>can be used in the <U>local-id</U>&nbsp;&nbsp;part of =
call-id=20
header or not"&nbsp;&nbsp; ......</STRONG>&nbsp; could u please =
clarify.. this=20
issue....</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Please find some time to clear =
this....I'll be=20
greatful to u...</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Senapathy T.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>( please reply to&nbsp; <A=20
href=3D"mailto:tsenapathy@rediffmail.com">tsenapathy@rediffmail.com</A>&n=
bsp; or=20
<A =
href=3D"mailto:srinand@globaledgesoft.com">srinand@globaledgesoft.com</A>=
=20
)</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0004_01C039C8.E37DF8A0--


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



From mailnull@www1.ietf.org  Sun Oct 20 02:08:42 2002
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 CAA22993
	for <sip-archive@odin.ietf.org>; Sun, 20 Oct 2002 02:08:42 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9K6Ab804208
	for sip-archive@odin.ietf.org; Sun, 20 Oct 2002 02:10:37 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9K69rv03974;
	Sun, 20 Oct 2002 02:09:53 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9K67kv31879
	for <sip@optimus.ietf.org>; Sun, 20 Oct 2002 02:07:46 -0400
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 CAA20984
	for <sip@ietf.org>; Sun, 20 Oct 2002 02:05:21 -0400 (EDT)
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 1839FN-0004CJ-00; Sun, 20 Oct 2002 09:07:33 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15794.18469.633317.451304@harjus.eng.song.fi>
Date: Sun, 20 Oct 2002 09:07:33 +0300
To: "Kaul, Amit" <amit.kaul@intel.com>
Cc: "'sip@ietf.org'" <sip@ietf.org>
Subject: [Sip] Subscribe/Notify and Refer/Notify
In-Reply-To: <12B638FEE763F74696D8544752E7204801BACB58@bgsmsx101.iind.intel.com>
References: <12B638FEE763F74696D8544752E7204801BACB58@bgsmsx101.iind.intel.com>
X-Mailer: VM 7.03 under Emacs 21.2.1
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Kaul, Amit writes:

 > i) As per the Subsc/Notify draft, Subscriber should be able to receive
 >    NOTIFY before receiving 2xx. Also, it shall create a new
 > subscription/dialog

i also complained about this a couple of weeks ago to the author of the
sub/not rfc 3265.  sub/not rfc is not following the dialog model of RFC
3261, which is very confusing.  at minimum, the sub/not rfc should have
had its own state diagrams in order to make the mess a bit clearer.  i
suggest that we announce the sub/not rfc obsolete and replace it with a
new, simpler one.

-- juha

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



From mailnull@www1.ietf.org  Mon Oct 21 02:00:32 2002
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 CAA10492
	for <sip-archive@odin.ietf.org>; Mon, 21 Oct 2002 02:00:32 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9L62Qi30712
	for sip-archive@odin.ietf.org; Mon, 21 Oct 2002 02:02:26 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9L60av30656;
	Mon, 21 Oct 2002 02:00:36 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9L5umv30540
	for <sip@optimus.ietf.org>; Mon, 21 Oct 2002 01:56:48 -0400
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 BAA09735
	for <sip@ietf.org>; Mon, 21 Oct 2002 01:54:23 -0400 (EDT)
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 183VYK-00057k-00; Mon, 21 Oct 2002 08:56:36 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15795.38676.416432.424559@harjus.eng.song.fi>
Date: Mon, 21 Oct 2002 08:56:36 +0300
To: "Kaul, Amit" <amit.kaul@intel.com>
Cc: "'sip@ietf.org'" <sip@ietf.org>
Subject: RE: [Sip] Subscribe/Notify and Refer/Notify
In-Reply-To: <12B638FEE763F74696D8544752E7204801BACB63@bgsmsx101.iind.intel.com>
References: <12B638FEE763F74696D8544752E7204801BACB63@bgsmsx101.iind.intel.com>
X-Mailer: VM 7.03 under Emacs 21.2.1
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Kaul, Amit writes:

 > I would prefer author of this RFC to document Subscription/dialog (RFC3265)
 > state machines 
 > in detail and explain the aberration (if any) with 3261 dialog state
 > machines in the
 > next update.

this is the minimum what the authors can do, but do we really need for
sub/not a dialog model that is not compatible with 3261?  my reply is no
and therefore i suggest that we redo 3265 in a way that is consistent
with 3261.

-- juha

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



From mailnull@www1.ietf.org  Mon Oct 21 09:03:43 2002
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 JAA26861
	for <sip-archive@odin.ietf.org>; Mon, 21 Oct 2002 09:03:43 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9LD5Td27719
	for sip-archive@odin.ietf.org; Mon, 21 Oct 2002 09:05:29 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LD4Bv27650;
	Mon, 21 Oct 2002 09:04:11 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9L5dkv30145
	for <sip@optimus.ietf.org>; Mon, 21 Oct 2002 01:39:46 -0400
Received: from hermes.jf.intel.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09463
	for <sip@ietf.org>; Mon, 21 Oct 2002 01:37:21 -0400 (EDT)
Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6])
	by hermes.jf.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id g9L5bhh19590
	for <sip@ietf.org>; Mon, 21 Oct 2002 05:37:43 GMT
Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206])
	by petasus.jf.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.27 2002/10/16 23:46:59 dmccart Exp $) with SMTP id g9L5aj525264
	for <sip@ietf.org>; Mon, 21 Oct 2002 05:36:45 GMT
Received: from orsmsx26.jf.intel.com ([192.168.65.26])
 by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2002102022430205601
 ; Sun, 20 Oct 2002 22:43:02 -0700
Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.2653.19)
	id <V1GHH2N6>; Sun, 20 Oct 2002 22:39:34 -0700
Message-ID: <12B638FEE763F74696D8544752E7204801BACB63@bgsmsx101.iind.intel.com>
From: "Kaul, Amit" <amit.kaul@intel.com>
To: "'jh@lohi.eng.song.fi'" <jh@lohi.eng.song.fi>
Cc: "'sip@ietf.org'" <sip@ietf.org>
Subject: RE: [Sip] Subscribe/Notify and Refer/Notify
Date: Sun, 20 Oct 2002 22:34:59 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

I do agree that there are quite a few "grey areas" in dialog/subscription 
state machines which the Event Package RFC3265 is not clear or is confusing
to the reader.

Juha - your suggestion of making sub/not rfc obsolete does sound kind of 
radical and we don't need to pull the trigger like this. There would be lot
of issues 
with this approach.

I would prefer author of this RFC to document Subscription/dialog (RFC3265)
state machines 
in detail and explain the aberration (if any) with 3261 dialog state
machines in the
next update. It would definitely be very helpful because right now, these
state machines 
do seem to be conflicting at times.

However, to start with, can we have the doubts (in my previous email)
cleared by the 
author in this list ?

thanks
__amit



> -----Original Message-----
> From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi]
> Sent: Sunday, October 20, 2002 11:38 AM
> To: Kaul, Amit
> Cc: 'sip@ietf.org'
> Subject: [Sip] Subscribe/Notify and Refer/Notify
> 
> 
> Kaul, Amit writes:
> 
>  > i) As per the Subsc/Notify draft, Subscriber should be 
> able to receive
>  >    NOTIFY before receiving 2xx. Also, it shall create a new
>  > subscription/dialog
> 
> i also complained about this a couple of weeks ago to the 
> author of the
> sub/not rfc 3265.  sub/not rfc is not following the dialog 
> model of RFC
> 3261, which is very confusing.  at minimum, the sub/not rfc 
> should have
> had its own state diagrams in order to make the mess a bit clearer.  i
> suggest that we announce the sub/not rfc obsolete and replace 
> it with a
> new, simpler one.
> 
> -- juha
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Mon Oct 21 12:11:51 2002
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 MAA04471
	for <sip-archive@odin.ietf.org>; Mon, 21 Oct 2002 12:11:51 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9LGDcB06706
	for sip-archive@odin.ietf.org; Mon, 21 Oct 2002 12:13:38 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LGCZv06650;
	Mon, 21 Oct 2002 12:12:35 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LGB8v06596
	for <sip@optimus.ietf.org>; Mon, 21 Oct 2002 12:11:08 -0400
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 MAA04370
	for <sip@ietf.org>; Mon, 21 Oct 2002 12:08:47 -0400 (EDT)
From: sunayak@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 g9LFspi20480;
	Mon, 21 Oct 2002 21:24:52 +0530
Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 65256C59.0058CA89 ; Mon, 21 Oct 2002 21:39:50 +0530
X-Lotus-FromDomain: HSSBLR
To: sip@ietf.org, fluffy@cisco.com, Jon.Peterson@NeuStar.biz,
        mwatson@nortelnetworks.com
Message-ID: <65256C59.0058C9B9.00@sampark.hss.hns.com>
Date: Mon, 21 Oct 2002 21:39:47 +0530
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: [Sip] Question on draft-ietf-sip-asserted-identity-02
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>



Hi,
     I had a question regarding the above draft. Say a
subscriber is not to be provided Privacy per the server
configured policy but still requests for privacy by
inserting a "Privacy: id" header in a call. Should the
server
(a) Reject the request with a final failure response
    (say 403) ORR
(b) Forward the request but ensure that privacy is
    not provided by any downstream proxy either.

     In order to do (b), (assuming that the request is
being forwarded to a host in the trust domain), the server
can strip off the "Privacy: id" header so that a downstream
element does not provide the desired privacy. But as per
the draft, only the proxy that applies the privacy function
can strip off the "Privacy: id" header. Or can an intermediate
that is aware of the policy proceed as per (b).

Regards,
Subhash Nayak
Hughes Software Systems
http://www.hssworld.com







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.


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



From mailnull@www1.ietf.org  Mon Oct 21 16:49:09 2002
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 QAA15030
	for <sip-archive@odin.ietf.org>; Mon, 21 Oct 2002 16:49:09 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9LKp0n22908
	for sip-archive@odin.ietf.org; Mon, 21 Oct 2002 16:51:00 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LKnUv22873;
	Mon, 21 Oct 2002 16:49:30 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LKlDv22788
	for <sip@optimus.ietf.org>; Mon, 21 Oct 2002 16:47:13 -0400
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 QAA14839
	for <sip@ietf.org>; Mon, 21 Oct 2002 16:44:51 -0400 (EDT)
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 g9LKkCFu004400;
	Mon, 21 Oct 2002 16:46:16 -0400 (EDT)
Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <S3PQXXL9>; Mon, 21 Oct 2002 15:47:03 -0500
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A6427F@DYN-TX-EXCH-001.dynamicsoft.com>
From: Adam Roach <adam@dynamicsoft.com>
To: "'jh@lohi.eng.song.fi'" <jh@lohi.eng.song.fi>,
        "'sip@ietf.org'"
	 <sip@ietf.org>
Subject: RE: [Sip] Subscribe/Notify and Refer/Notify
Date: Mon, 21 Oct 2002 15:46:58 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

> i
> suggest that we announce the sub/not rfc obsolete and replace 
> it with a
> new, simpler one.

Are you volunteering to take my albatross? That's too kind.
It'd be great if you could make the -00 deadline for Atlanta.
Thanks!

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



From mailnull@www1.ietf.org  Mon Oct 21 16:51:36 2002
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 QAA15133
	for <sip-archive@odin.ietf.org>; Mon, 21 Oct 2002 16:51:36 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9LKrRi23020
	for sip-archive@odin.ietf.org; Mon, 21 Oct 2002 16:53:27 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LKr8v23007;
	Mon, 21 Oct 2002 16:53:08 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LKqWv22983
	for <sip@optimus.ietf.org>; Mon, 21 Oct 2002 16:52:32 -0400
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 QAA15079
	for <sip@ietf.org>; Mon, 21 Oct 2002 16:50:11 -0400 (EDT)
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 g9LKpXFu004438;
	Mon, 21 Oct 2002 16:51:34 -0400 (EDT)
Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <S3PQXXMA>; Mon, 21 Oct 2002 15:52:24 -0500
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64280@DYN-TX-EXCH-001.dynamicsoft.com>
From: Adam Roach <adam@dynamicsoft.com>
To: "'Kaul, Amit'" <amit.kaul@intel.com>,
        "'jh@lohi.eng.song.fi'"
	 <jh@lohi.eng.song.fi>
Cc: "'sip@ietf.org'" <sip@ietf.org>
Subject: RE: [Sip] Subscribe/Notify and Refer/Notify
Date: Mon, 21 Oct 2002 15:52:17 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

> However, to start with, can we have the doubts (in my previous email)
> cleared by the 
> author in this list ?

Sorry; I thought that, since you sent the same note to me privately,
you wanted a private response (which I provided). Comments inline.

> In this case, subscription and dialog are created before 
> getting 2xx for the
> intial SUBSCRIBE.
> However, if Subscriber doesn't get any final response and the 
> transaction
> timer for SUBSCRIBE
> transaction times out, what should be the action on the part 
> of subscriber :
> a) Remove the subscription
> b) Keep the subscription and remove the SUBSCRIBE transaction 
> gracefully.

b. 

Ambiguity noted; this will be clarified in the next version of the
document.

> ii) As per the Refer/Notify draft, the subscription expiry 
> time, before the
> Subscriber gets NOTIFY
>    depends on "Refer-To" header.
> 
>   E.g., in the draft, this line is mentioned :
>     Subscription-State: active;expires=(depends on Refer-To URI)
>    a) What exactly is meant by this ? 

I'll let Robert address this one. (Is this an ambiguity in
the REFER draft, or did Amit miss something?)

>    b) If no NOTIFY is received before the REFER (Refer/2xx) 
> transaction
> times  out, does that mean that subscription/dialog
>    is automatically removed ? OR is subscriber supposed to 
> wait for the
> NOTIFY till some "Configured" time ?

If the REFER times out, assume the subscription did not succeed.
Note that the dialog may or may not disappear, depending on whether
the REFER was sent on an existing dialog; see the dialog handling
mentioned in RFC 3265.

In general, RFCs don't cover all possible failure cases; it's assumed
that implementors will think through the ramifications of the
decisions they make, and try to make things behave in a sensible
fashion. This seems to be one of those cases.

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



From mailnull@www1.ietf.org  Tue Oct 22 01:53:28 2002
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 BAA27295
	for <sip-archive@odin.ietf.org>; Tue, 22 Oct 2002 01:53:28 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9M5tNp13720
	for sip-archive@odin.ietf.org; Tue, 22 Oct 2002 01:55:23 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9M5pgv13622;
	Tue, 22 Oct 2002 01:51:43 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9M5n4v13560
	for <sip@optimus.ietf.org>; Tue, 22 Oct 2002 01:49:04 -0400
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 BAA27186
	for <sip@ietf.org>; Tue, 22 Oct 2002 01:46:39 -0400 (EDT)
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 183ruP-0006D4-00; Tue, 22 Oct 2002 08:48:53 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15796.59077.410357.665807@harjus.eng.song.fi>
Date: Tue, 22 Oct 2002 08:48:53 +0300
To: Adam Roach <adam@dynamicsoft.com>
Cc: "'sip@ietf.org'"
	 <sip@ietf.org>
Subject: RE: [Sip] Subscribe/Notify and Refer/Notify
In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A6427F@DYN-TX-EXCH-001.dynamicsoft.com>
References: <9BF66EBF6BEFD942915B4D4D45C051F3A6427F@DYN-TX-EXCH-001.dynamicsoft.com>
X-Mailer: VM 7.03 under Emacs 21.2.1
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Adam Roach writes:

 > Are you volunteering to take my albatross? That's too kind.
 > It'd be great if you could make the -00 deadline for Atlanta.

it won't be too much effort to make the next version of 3265 compliant
with 3261.  i can do that after the working group has made an
announcement that the current version will be changed and that there is
no requirement that the next version will be backwards compatible with
the current one.

i can't understand how 3265 got through the iesg review process.  i
would think that the first thing they require is compatibility with the
newly released sip rfc.

-- juha

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



From mailnull@www1.ietf.org  Tue Oct 22 10:41:25 2002
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 KAA19655
	for <sip-archive@odin.ietf.org>; Tue, 22 Oct 2002 10:41:25 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9MEhEJ18072
	for sip-archive@odin.ietf.org; Tue, 22 Oct 2002 10:43:14 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MEg3v18038;
	Tue, 22 Oct 2002 10:42:04 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MEdrv17967
	for <sip@optimus.ietf.org>; Tue, 22 Oct 2002 10:39:53 -0400
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 KAA19494
	for <sip@ietf.org>; Tue, 22 Oct 2002 10:37:33 -0400 (EDT)
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 g9MEcuFu007665;
	Tue, 22 Oct 2002 10:38:56 -0400 (EDT)
Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <S3PQXXP9>; Tue, 22 Oct 2002 09:39:47 -0500
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64284@DYN-TX-EXCH-001.dynamicsoft.com>
From: Adam Roach <adam@dynamicsoft.com>
To: "'jh@lohi.eng.song.fi'" <jh@lohi.eng.song.fi>,
        Adam Roach
	 <adam@dynamicsoft.com>
Cc: "'sip@ietf.org'" <sip@ietf.org>
Subject: RE: [Sip] Subscribe/Notify and Refer/Notify
Date: Tue, 22 Oct 2002 09:39:42 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

> it won't be too much effort to make the next version of 3265 compliant
> with 3261.  i can do that after the working group has made an
> announcement that the current version will be changed and 
> that there is
> no requirement that the next version will be backwards compatible with
> the current one.

Okay, you missed the sarcasm, apparently; I'll have to be more direct.
It's a lot easier to be critical than useful, as you've made a point
of demonstrating. I'd love to hear constructive comments on the
mechanism, and already have extensive notes on what needs to be
clarified in future versions of the draft (such as your earlier
suggestion that a clear dialog-establishing state machine be defined).

Most of your other comments, though, have not been suggestions as
much as sniping. Standing on the sidelines throwing rotten tomatoes
isn't going to yield much progress.

> i can't understand how 3265 got through the iesg review process.  i
> would think that the first thing they require is 
> compatibility with the
> newly released sip rfc.

Reading through the sniping in this paragraph (and taking it in the
context of your previous rants), I'll address what I think is the
underlying annoyance here: SUBSCRIBE/NOTIFY is complicated.

Contrary to your insinuations, the complications in the protocol
were not added merely because I'm a twisted and sadistic
person. Each mechanism in the protocol has a genesis, and each
additional complication has been carefully weighed against the
gains provided.

As happens a lot around here, I believe the main problem is that
there is a lack of historical perspective on the issue.

If you poke around a little bit, you can find early drafts of
SUB/NOT [1]. They did little more than define the SUBSCRIBE and
NOTIFY methods, plus the "Event" header. All other handling was
relegated to normal SIP dialog (call leg) establishment.

This specification was not considered complete enough, as it didn't
address the race condition that will typically occur between the
SUBSCRIBE response and the NOTIFY request, notifier-
initiated dialog termination, forking of SUBSCRIBE responses,
migration of subscriptions between nodes, and a wide variety of
other requirements that various parties felt were necessary for
a general purpose mechanism.

So, over two years and ten revisions of the document, each
problem and requirement was addressed in the most straightforward
way possible, and, for each issue, a consensus was reached
within the SIP working group(s).

As is the nature of such changes, each of these new features and
bugfixes to the protocol increased the complexity somewhat. And
that's where it is today. I'm sorry that it annoys you so much.

If you have suggestions for improvement that don't contravene
the requirements imposed on SUB/NOT by the underlying protocol
and by the users of the protocol (check the minutes from the
last seven or so SIP working group meetings), I'm very happy
to listen and incorporate them.

But leave the rotten tomatoes at home, please.

/a

[1]
http://www.softarmor.com/sipwg/drafts/morgue/draft-roach-sip-subscribe-notif
y-00.txt
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Tue Oct 22 11:59:13 2002
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 LAA23673
	for <sip-archive@odin.ietf.org>; Tue, 22 Oct 2002 11:59:13 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9MG13p22147
	for sip-archive@odin.ietf.org; Tue, 22 Oct 2002 12:01:03 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MFxuv22048;
	Tue, 22 Oct 2002 11:59:56 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MFw4v21995
	for <sip@optimus.ietf.org>; Tue, 22 Oct 2002 11:58:04 -0400
Received: from dyn-tx-app-007.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23542
	for <sip@ietf.org>; Tue, 22 Oct 2002 11:55:43 -0400 (EDT)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by dyn-tx-app-007.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g9MFwG132572;
	Tue, 22 Oct 2002 10:58:18 -0500
Subject: RE: [Sip] Subscribe/Notify and Refer/Notify
From: Robert Sparks <rsparks@dynamicsoft.com>
To: jh@lohi.eng.song.fi
Cc: Adam Roach <adam@dynamicsoft.com>, "'sip@ietf.org'" <sip@ietf.org>
In-Reply-To: <15796.59077.410357.665807@harjus.eng.song.fi>
References: 
	<9BF66EBF6BEFD942915B4D4D45C051F3A6427F@DYN-TX-EXCH-001.dynamicsoft.com> 
	<15796.59077.410357.665807@harjus.eng.song.fi>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) 
Date: 22 Oct 2002 10:52:17 -0500
Message-Id: <1035301940.1469.174.camel@RjS.localdomain>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Actually, there was a great deal of effort to _ensure_ that
3265 and 3261 were compatible - I remember several coordinated
rewrite sessions to make sure they said the same things. 

Having participated in the creation of both documents (having
long arguments with the other active participants over the 
intricacies of nested dialogs and when dialog life-cycles), and
having implemented systems that deal with all of them, I have to
say that I _strongly_ disagree with your statement that 3265 is wrong
and should be abandoned. 

I _will_ agree that the edge cases created by the consensus on how
to deal with the differences between and INVITE transaction and a
non-INVITE transaction can be more clearly documented. Everyone can help
with that - all that's required is understanding the problem and
providing text.

As far as I can tell, the behavior that's giving you the most
trouble right now is with establishing dialogs based on a NOTIFY
that arrives before a SUBSCRIBE transaction completes. The parallels
to look for in the INVITE mechanics are with early dialogs. Think
of SUB->200->NOT like INV->18x->200. If a 18x gets misordered and
is delivered after a 200, it's not going to affect any dialog state.

RjS

On Tue, 2002-10-22 at 00:48, jh@lohi.eng.song.fi wrote:
> Adam Roach writes:
> 
>  > Are you volunteering to take my albatross? That's too kind.
>  > It'd be great if you could make the -00 deadline for Atlanta.
> 
> it won't be too much effort to make the next version of 3265 compliant
> with 3261.  i can do that after the working group has made an
> announcement that the current version will be changed and that there is
> no requirement that the next version will be backwards compatible with
> the current one.
> 
> i can't understand how 3265 got through the iesg review process.  i
> would think that the first thing they require is compatibility with the
> newly released sip rfc.
> 
> -- juha
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip


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



From mailnull@www1.ietf.org  Tue Oct 22 23:02:29 2002
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 XAA13480
	for <sip-archive@odin.ietf.org>; Tue, 22 Oct 2002 23:02:29 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9N34OI23502
	for sip-archive@odin.ietf.org; Tue, 22 Oct 2002 23:04:24 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9N33nv23477;
	Tue, 22 Oct 2002 23:03:50 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9N31Pv23436
	for <sip@optimus.ietf.org>; Tue, 22 Oct 2002 23:01:25 -0400
Received: from oak.neustar.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13417
	for <sip@ietf.org>; Tue, 22 Oct 2002 22:58:59 -0400 (EDT)
Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11])
	by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g9N31Bb02525;
	Wed, 23 Oct 2002 03:01:11 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19)
	id <VLY12PMT>; Tue, 22 Oct 2002 23:01:34 -0400
Message-ID: <15A2739B7DAA624D8091C65981D7DA815EB2F1@stntexch2.va.neustar.com>
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: "'sunayak@hss.hns.com'" <sunayak@hss.hns.com>, sip@ietf.org,
        fluffy@cisco.com, mwatson@nortelnetworks.com
Date: Tue, 22 Oct 2002 23:01:33 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Subject: [Sip] RE: Question on draft-ietf-sip-asserted-identity-02
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>


I'm not sure I understand the case you describe below, but I'll take a stab
at a response. 

We make no provision in any of these privacy/identity drafts, as far as I
can recall for cases in which a privacy service has policies that preclude
user requests for privacy. This would be comparable to the telephone network
rejecting your attempt to dial *67. Personally, I am not interested in
standardizing any case in which a privacy service with the relevant
capabilities would purposefully refuse to fulfill a user's request for
privacy. I suppose that if you were to implement this as a non-standard
mechanism, your option (a) would be vastly preferable (and would follow the
spirit of Section 5 of the privacy draft).

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: sunayak@hss.hns.com [mailto:sunayak@hss.hns.com]
> Sent: Tuesday, October 22, 2002 1:10 AM
> To: sip@ietf.org; fluffy@cisco.com; Jon.Peterson@NeuStar.biz;
> mwatson@nortelnetworks.com
> Subject: Question on draft-ietf-sip-asserted-identity-02
> 
> 
> 
> 
> Hi,
>      I had a question regarding the above draft. Say a
> subscriber is not to be provided Privacy per the server
> configured policy but still requests for privacy by
> inserting a "Privacy: id" header in a call. Should the
> server
> (a) Reject the request with a final failure response
>     (say 403) ORR
> (b) Forward the request but ensure that privacy is
>     not provided by any downstream proxy either.
> 
>      In order to do (b), (assuming that the request is
> being forwarded to a host in the trust domain), the server
> can strip off the "Privacy: id" header so that a downstream
> element does not provide the desired privacy. But as per
> the draft, only the proxy that applies the privacy function
> can strip off the "Privacy: id" header. Or can an intermediate
> that is aware of the policy proceed as per (b).
> 
> Regards,
> Subhash Nayak
> Hughes Software Systems
> http://www.hssworld.com
> 
> 
> 
> 
> 
> 
> 
> 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.
> 
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Wed Oct 23 03:37:36 2002
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 DAA10695
	for <sip-archive@odin.ietf.org>; Wed, 23 Oct 2002 03:37:36 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9N7dXx12075
	for sip-archive@odin.ietf.org; Wed, 23 Oct 2002 03:39:33 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9N7d4v12058;
	Wed, 23 Oct 2002 03:39:04 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9N7aqv11431
	for <sip@optimus.ietf.org>; Wed, 23 Oct 2002 03:36:52 -0400
Received: from david.sae.siemens.com.sg (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10647
	for <sip@ietf.org>; Wed, 23 Oct 2002 03:34:18 -0400 (EDT)
X-Envelope-Sender-Is: kokjeng.loh@siemens.com (at relayer david.sae.siemens.com.sg)
Received: from mail.sae.siemens.com.sg (mail.sae.siemens.com.sg [194.138.237.14])
	by david.sae.siemens.com.sg (8.11.6/8.11.6) with ESMTP id g9N7Xll29348
	for <sip@ietf.org>; Wed, 23 Oct 2002 15:33:49 +0800 (SGT)
Received: from sgpk001a.sae.siemens.com.sg (sgpk001a.sae.siemens.com.sg [140.231.107.1])
	by mail.sae.siemens.com.sg (8.11.6/8.11.6) with ESMTP id g9N7Z1X20993
	for <sip@ietf.org>; Wed, 23 Oct 2002 15:35:01 +0800 (SGT)
Received: by sgpk001a.sae.siemens.com.sg with Internet Mail Service (5.5.2655.55)
	id <T8LWK2C5>; Wed, 23 Oct 2002 15:30:04 +0800
Message-ID: <7319EDDDE0CD7C458023FF64886CB177027C972C@sgpk001a.sae.siemens.com.sg>
From: Loh Kok Jeng <kokjeng.loh@siemens.com>
To: sip@ietf.org
Date: Wed, 23 Oct 2002 15:30:04 +0800
X-Mailer: Internet Mail Service (5.5.2655.55)
Subject: [Sip] Questions on Max-Forwards
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

Dear all,

If a valid SIP message with "Max-Forwards: 1" is received by a proxy, should

the proxy decrement Max-Forwards and forward it, or should it respond with
483?

Likewise, how should the proxy handle a message with with Max-Forwards: 0 
or a negative value?

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



From mailnull@www1.ietf.org  Wed Oct 23 06:04:00 2002
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 GAA12620
	for <sip-archive@odin.ietf.org>; Wed, 23 Oct 2002 06:04:00 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9NA5m619129
	for sip-archive@odin.ietf.org; Wed, 23 Oct 2002 06:05:48 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9NA5Nv19119;
	Wed, 23 Oct 2002 06:05:23 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9NA3uv19078
	for <sip@optimus.ietf.org>; Wed, 23 Oct 2002 06:03:56 -0400
Received: from caduceus.jf.intel.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12603
	for <sip@ietf.org>; Wed, 23 Oct 2002 06:01:37 -0400 (EDT)
Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7])
	by caduceus.jf.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id g9NA1I700644
	for <sip@ietf.org>; Wed, 23 Oct 2002 10:01:18 GMT
Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206])
	by talaria.jf.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.27 2002/10/16 23:46:59 dmccart Exp $) with SMTP id g9N9qus26970
	for <sip@ietf.org>; Wed, 23 Oct 2002 09:52:56 GMT
Received: from orsmsx26.jf.intel.com ([192.168.65.26])
 by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2002102303072532164
 ; Wed, 23 Oct 2002 03:07:26 -0700
Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.2653.19)
	id <V1GHQ549>; Wed, 23 Oct 2002 03:03:53 -0700
Message-ID: <12B638FEE763F74696D8544752E720481B2E63@bgsmsx101.iind.intel.com>
From: "Krishna, Samaga" <samaga.krishna@intel.com>
To: "'Loh Kok Jeng'" <kokjeng.loh@siemens.com>, sip@ietf.org
Subject: RE: [Sip] Questions on Max-Forwards
Date: Wed, 23 Oct 2002 02:53:19 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

Hi Loh,
 If proxy receives a request with Max-Forward : 1, the proxy will decrement
the count and forward the message.
If proxy receives the request with Max-Forward: 0, it should not forward the
request. It shall send 483 response. If the request is for OPTIONS, proxy
will act as final recipient and respond to it as in the RFC 3261 section 11.


have a nice day
Prasanna

 

-----Original Message-----
From: Loh Kok Jeng [mailto:kokjeng.loh@siemens.com]
Sent: Wednesday, October 23, 2002 1:00 PM
To: sip@ietf.org
Subject: [Sip] Questions on Max-Forwards


Dear all,

If a valid SIP message with "Max-Forwards: 1" is received by a proxy, should

the proxy decrement Max-Forwards and forward it, or should it respond with
483?

Likewise, how should the proxy handle a message with with Max-Forwards: 0 
or a negative value?

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



From mailnull@www1.ietf.org  Wed Oct 23 08:17:47 2002
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 IAA15182
	for <sip-archive@odin.ietf.org>; Wed, 23 Oct 2002 08:17:47 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9NCJZ625534
	for sip-archive@odin.ietf.org; Wed, 23 Oct 2002 08:19:35 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9NCImv25502;
	Wed, 23 Oct 2002 08:18:48 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9NCGPv25403
	for <sip@optimus.ietf.org>; Wed, 23 Oct 2002 08:16:25 -0400
Received: from david.sae.siemens.com.sg (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15124
	for <sip@ietf.org>; Wed, 23 Oct 2002 08:14:05 -0400 (EDT)
X-Envelope-Sender-Is: kokjeng.loh@siemens.com (at relayer david.sae.siemens.com.sg)
Received: from mail.sae.siemens.com.sg (mail.sae.siemens.com.sg [194.138.237.14])
	by david.sae.siemens.com.sg (8.11.6/8.11.6) with ESMTP id g9NCDcl15473;
	Wed, 23 Oct 2002 20:13:38 +0800 (SGT)
Received: from sgpk001a.sae.siemens.com.sg (sgpk001a.sae.siemens.com.sg [140.231.107.1])
	by mail.sae.siemens.com.sg (8.11.6/8.11.6) with ESMTP id g9NCEoX07345;
	Wed, 23 Oct 2002 20:14:52 +0800 (SGT)
Received: by sgpk001a.sae.siemens.com.sg with Internet Mail Service (5.5.2655.55)
	id <T8LWKMY2>; Wed, 23 Oct 2002 20:09:53 +0800
Message-ID: <7319EDDDE0CD7C458023FF64886CB177027CA17C@sgpk001a.sae.siemens.com.sg>
From: Loh Kok Jeng <kokjeng.loh@siemens.com>
To: "Krishna, Samaga" <samaga.krishna@intel.com>, sip@ietf.org
Subject: RE: [Sip] Questions on Max-Forwards
Date: Wed, 23 Oct 2002 20:09:52 +0800
X-Mailer: Internet Mail Service (5.5.2655.55)
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

Hi,

Thanks for your reply.  Section 11 says:

   Alternatively, a server receiving an OPTIONS request with a Max-
   Forwards header field value of 0 MAY respond to the request
   regardless of the Request-URI.

Does it mean that a proxy may send 483 instead of 200?

What if the value of Max-Forwards is outside the permitted range
0-255?  Should a 400 response be sent?

regards,
KJ Loh

> -----Original Message-----
> From: Krishna, Samaga [mailto:samaga.krishna@intel.com]
> Sent: Wednesday, October 23, 2002 5:53 PM
> To: 'Loh Kok Jeng'; sip@ietf.org
> Subject: RE: [Sip] Questions on Max-Forwards
> 
> 
> Hi Loh,
>  If proxy receives a request with Max-Forward : 1, the proxy 
> will decrement
> the count and forward the message.
> If proxy receives the request with Max-Forward: 0, it should 
> not forward the
> request. It shall send 483 response. If the request is for 
> OPTIONS, proxy
> will act as final recipient and respond to it as in the RFC 
> 3261 section 11.
> 
> 
> have a nice day
> Prasanna
> 
>  
> 
> -----Original Message-----
> From: Loh Kok Jeng [mailto:kokjeng.loh@siemens.com]
> Sent: Wednesday, October 23, 2002 1:00 PM
> To: sip@ietf.org
> Subject: [Sip] Questions on Max-Forwards
> 
> 
> Dear all,
> 
> If a valid SIP message with "Max-Forwards: 1" is received by 
> a proxy, should
> 
> the proxy decrement Max-Forwards and forward it, or should it 
> respond with
> 483?
> 
> Likewise, how should the proxy handle a message with with 
> Max-Forwards: 0 
> or a negative value?
> 
> regards,
> KJ Loh
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Wed Oct 23 08:56:10 2002
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 IAA16816
	for <sip-archive@odin.ietf.org>; Wed, 23 Oct 2002 08:56:10 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9NCvw027600
	for sip-archive@odin.ietf.org; Wed, 23 Oct 2002 08:57:58 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9NCvdv27568;
	Wed, 23 Oct 2002 08:57:39 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9NCuZv27518
	for <sip@optimus.ietf.org>; Wed, 23 Oct 2002 08:56:35 -0400
Received: from imo-m10.mx.aol.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16733
	for <sip@ietf.org>; Wed, 23 Oct 2002 08:54:16 -0400 (EDT)
From: Mpierce1@aol.com
Received: from Mpierce1@aol.com
	by imo-m10.mx.aol.com (mail_out_v34.13.) id g.21.262f6b8c (4328);
	Wed, 23 Oct 2002 08:56:12 -0400 (EDT)
Message-ID: <21.262f6b8c.2ae7f66c@aol.com>
Date: Wed, 23 Oct 2002 08:56:12 EDT
Subject: Re: [Sip] RE: Question on draft-ietf-sip-asserted-identity-02
To: jon.peterson@neustar.biz, sunayak@hss.hns.com, sip@ietf.org,
        fluffy@cisco.com, mwatson@nortelnetworks.com
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="part1_21.262f6b8c.2ae7f66c_boundary"
X-Mailer: AOL 6.0 for Windows XP US sub 10500
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>


--part1_21.262f6b8c.2ae7f66c_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

In a message dated 10/23/2002 5:41:00 AM W. Europe Daylight Time, 
jon.peterson@neustar.biz writes:


> We make no provision in any of these privacy/identity drafts, as far as I
> can recall for cases in which a privacy service has policies that preclude
> user requests for privacy. This would be comparable to the telephone network
> rejecting your attempt to dial *67. Personally, I am not interested in
> standardizing any case in which a privacy service with the relevant
> capabilities would purposefully refuse to fulfill a user's request for
> privacy. I suppose that if you were to implement this as a non-standard
> mechanism, your option (a) would be vastly preferable (and would follow the
> spirit of Section 5 of the privacy draft).
> 



[MAP] I'm not sure if it is an example of what you referred to as "the 
telephone network rejecting your attempt to dial *67", but today, dialing *67 
should have no effect on the delivery of the calling identity to the other 
end when you dial an "800" number or 911 in the US.

In addition, I remember some years ago that the PUC in Florida approved the 
assignment of a special office code that would override the originator's 
request for privacy when they dialed *67 followed by a number in that office 
code. It was just a regular looking telephone number (not something 
recognizable like 800) that would always get the calling line ID. And it was 
not intended specifically for police departments, etc. In this case, the 
calling user's request for "privacy" was ignored.

These are not cases in which the privacy service refuses to fulfil the user's 
request or rejects the *67, but rather, ones in which some other service 
takes precedence. Is the "asserted identity" draft taking these types of 
cases into account?

Mike Pierce
Artel



--part1_21.262f6b8c.2ae7f66c_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

<HTML><FONT FACE=arial,helvetica><FONT  SIZE=2>In a message dated 10/23/2002 5:41:00 AM W. Europe Daylight Time, jon.peterson@neustar.biz writes:
<BR>
<BR>
<BR><BLOCKQUOTE TYPE=CITE style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">We make no provision in any of these privacy/identity drafts, as far as I
<BR>can recall for cases in which a privacy service has policies that preclude
<BR>user requests for privacy. This would be comparable to the telephone network
<BR>rejecting your attempt to dial *67. Personally, I am not interested in
<BR>standardizing any case in which a privacy service with the relevant
<BR>capabilities would purposefully refuse to fulfill a user's request for
<BR>privacy. I suppose that if you were to implement this as a non-standard
<BR>mechanism, your option (a) would be vastly preferable (and would follow the
<BR>spirit of Section 5 of the privacy draft).
<BR></BLOCKQUOTE>
<BR>
<BR>
<BR>
<BR>[MAP] I'm not sure if it is an example of what you referred to as "the telephone network rejecting your attempt to dial *67", but today, dialing *67 should have no effect on the delivery of the calling identity to the other end when you dial an "800" number or 911 in the US.
<BR>
<BR>In addition, I remember some years ago that the PUC in Florida approved the assignment of a special office code that would override the originator's request for privacy when they dialed *67 followed by a number in that office code. It was just a regular looking telephone number (not something recognizable like 800) that would always get the calling line ID. And it was not intended specifically for police departments, etc. In this case, the calling user's request for "privacy" was ignored.
<BR>
<BR>These are not cases in which the privacy service refuses to fulfil the user's request or rejects the *67, but rather, ones in which some other service takes precedence. Is the "asserted identity" draft taking these types of cases into account?
<BR>
<BR>Mike Pierce
<BR>Artel
<BR>
<BR></FONT></HTML>

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



From mailnull@www1.ietf.org  Wed Oct 23 11:30:43 2002
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 LAA16167
	for <sip-archive@odin.ietf.org>; Wed, 23 Oct 2002 11:30:43 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9NFVdk04477
	for sip-archive@odin.ietf.org; Wed, 23 Oct 2002 11:31:39 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9NFUVv04355;
	Wed, 23 Oct 2002 11:30:31 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9NFRUv04264
	for <sip@optimus.ietf.org>; Wed, 23 Oct 2002 11:27:30 -0400
Received: from mail.ipnetfusion.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15058
	for <sip@ietf.org>; Wed, 23 Oct 2002 11:25:08 -0400 (EDT)
Received: from pc75 (pc75 [192.1.2.75])
	(authenticated)
	by mail.ipnetfusion.com (8.11.6/8.11.6) with ESMTP id g9NFRLP04150;
	Wed, 23 Oct 2002 10:27:21 -0500
From: "manoj mallik" <m.manoj@ipnetfusion.com>
To: "Loh Kok Jeng" <kokjeng.loh@siemens.com>,
        "Krishna, Samaga" <samaga.krishna@intel.com>, <sip@ietf.org>
Subject: RE: [Sip] Questions on Max-Forwards
Date: Wed, 23 Oct 2002 10:28:26 -0500
Message-ID: <NFBBLFEIJCBDFIDDNIGCMEMCCHAA.m.manoj@ipnetfusion.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)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
In-Reply-To: <7319EDDDE0CD7C458023FF64886CB177027CA17C@sgpk001a.sae.siemens.com.sg>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

inline

-----Original Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Loh Kok
Jeng
Sent: Wednesday, October 23, 2002 7:10 AM
To: Krishna, Samaga; sip@ietf.org
Subject: RE: [Sip] Questions on Max-Forwards


Hi,

Thanks for your reply.  Section 11 says:

   Alternatively, a server receiving an OPTIONS request with a Max-
   Forwards header field value of 0 MAY respond to the request
   regardless of the Request-URI.

Does it mean that a proxy may send 483 instead of 200?

>>>>Manoj: It indicates that if the Request is OPTIONS with Max-Forwards 0,
then it MAY act as final receiptant and respond to the Request irrespective
of the target in Request-URI. i.e even if the Request-URI is not meant for
him, it will respond to that OPTIONS request. It doesn't say about the kind
of Response. However RFC-3261, sec 11.2 Processing of OPTIONS Request, says
that

   "If the response to an OPTIONS is generated by a proxy server, the
   proxy returns a 200 (OK), listing the capabilities of the server.
   The response does not contain a message body."

What if the value of Max-Forwards is outside the permitted range
0-255?  Should a 400 response be sent?

Manoj>>>> This is a good question. I think nothing is mentioned in the RFC
if Max-Forwards is outside the permitted range 0-255. So it is really hard
to say what should be the response, may be it is implementation dependent.

regards,
KJ Loh

> -----Original Message-----
> From: Krishna, Samaga [mailto:samaga.krishna@intel.com]
> Sent: Wednesday, October 23, 2002 5:53 PM
> To: 'Loh Kok Jeng'; sip@ietf.org
> Subject: RE: [Sip] Questions on Max-Forwards
>
>
> Hi Loh,
>  If proxy receives a request with Max-Forward : 1, the proxy
> will decrement
> the count and forward the message.
> If proxy receives the request with Max-Forward: 0, it should
> not forward the
> request. It shall send 483 response. If the request is for
> OPTIONS, proxy
> will act as final recipient and respond to it as in the RFC
> 3261 section 11.
>
>
> have a nice day
> Prasanna
>
>
>
> -----Original Message-----
> From: Loh Kok Jeng [mailto:kokjeng.loh@siemens.com]
> Sent: Wednesday, October 23, 2002 1:00 PM
> To: sip@ietf.org
> Subject: [Sip] Questions on Max-Forwards
>
>
> Dear all,
>
> If a valid SIP message with "Max-Forwards: 1" is received by
> a proxy, should
>
> the proxy decrement Max-Forwards and forward it, or should it
> respond with
> 483?
>
> Likewise, how should the proxy handle a message with with
> Max-Forwards: 0
> or a negative value?
>
> regards,
> KJ Loh
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip

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



From mailnull@www1.ietf.org  Wed Oct 23 12:33:18 2002
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 MAA24683
	for <sip-archive@odin.ietf.org>; Wed, 23 Oct 2002 12:33:18 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9NGZ9W09471
	for sip-archive@odin.ietf.org; Wed, 23 Oct 2002 12:35:09 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9NGY9v09391;
	Wed, 23 Oct 2002 12:34:09 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9NGWjv09305
	for <sip@optimus.ietf.org>; Wed, 23 Oct 2002 12:32:45 -0400
Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24594
	for <sip@ietf.org>; Wed, 23 Oct 2002 12:30:22 -0400 (EDT)
Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32])
	by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9NGWVcl015896;
	Wed, 23 Oct 2002 09:32:31 -0700 (PDT)
Received: from fluffyw2k (dhcp-128-107-142-114.cisco.com [128.107.142.114])
	by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA)
	with SMTP id AAM34747;
	Wed, 23 Oct 2002 09:32:59 -0700 (PDT)
From: "Cullen Jennings" <fluffy@cisco.com>
To: <Mpierce1@aol.com>, <jon.peterson@neustar.biz>, <sunayak@hss.hns.com>,
        <sip@ietf.org>, <mwatson@nortelnetworks.com>
Subject: RE: [Sip] RE: Question on draft-ietf-sip-asserted-identity-02
Date: Wed, 23 Oct 2002 09:32:33 -0700
Message-ID: <IOELLHIFFNFPHNDEMKCPAEEKEKAA.fluffy@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 IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
In-Reply-To: <21.262f6b8c.2ae7f66c@aol.com>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit


The privacy provided by this system is only as good in as much as you can
trust the provider providing the privacy service. Let me explain this
confusing statement. Say I, fluffy, have a SIP phone. I have some sort of
subscriber contract with service.com. I set my outbound proxy to service.com
and send them a call and request privacy. Regardless of what number I
dialed, service.com can choose to do anything they want with this
information. The only thing I can do is take legal action if they do
something other than what my contract with them says they will do. I would
hope that my contract would say that they would always anonymize the call
and if that was not legally possible they would reject it and the only
exception to this would be a E911 call. I can easily imagine it will say
they make no guarantees about ever anonymizing anything and if it happened
to work you got lucky and all the liability of this was yours and if you
ever sued them they got to take your first born.

Cullen



-----Original Message-----
From: Mpierce1@aol.com [mailto:Mpierce1@aol.com]
Sent: Wednesday, October 23, 2002 5:56 AM
To: jon.peterson@neustar.biz; sunayak@hss.hns.com; sip@ietf.org;
fluffy@cisco.com; mwatson@nortelnetworks.com
Subject: Re: [Sip] RE: Question on draft-ietf-sip-asserted-identity-02


In a message dated 10/23/2002 5:41:00 AM W. Europe Daylight Time,
jon.peterson@neustar.biz writes:



We make no provision in any of these privacy/identity drafts, as far as I
can recall for cases in which a privacy service has policies that preclude
user requests for privacy. This would be comparable to the telephone network
rejecting your attempt to dial *67. Personally, I am not interested in
standardizing any case in which a privacy service with the relevant
capabilities would purposefully refuse to fulfill a user's request for
privacy. I suppose that if you were to implement this as a non-standard
mechanism, your option (a) would be vastly preferable (and would follow the
spirit of Section 5 of the privacy draft).





[MAP] I'm not sure if it is an example of what you referred to as "the
telephone network rejecting your attempt to dial *67", but today, dialing
*67 should have no effect on the delivery of the calling identity to the
other end when you dial an "800" number or 911 in the US.

In addition, I remember some years ago that the PUC in Florida approved the
assignment of a special office code that would override the originator's
request for privacy when they dialed *67 followed by a number in that office
code. It was just a regular looking telephone number (not something
recognizable like 800) that would always get the calling line ID. And it was
not intended specifically for police departments, etc. In this case, the
calling user's request for "privacy" was ignored.

These are not cases in which the privacy service refuses to fulfil the
user's request or rejects the *67, but rather, ones in which some other
service takes precedence. Is the "asserted identity" draft taking these
types of cases into account?

Mike Pierce
Artel

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



From mailnull@www1.ietf.org  Wed Oct 23 14:01:08 2002
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 OAA27557
	for <sip-archive@odin.ietf.org>; Wed, 23 Oct 2002 14:01:08 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9NI30I14297
	for sip-archive@odin.ietf.org; Wed, 23 Oct 2002 14:03:00 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9NI2cv14282;
	Wed, 23 Oct 2002 14:02:38 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9NI1uv14253
	for <sip@optimus.ietf.org>; Wed, 23 Oct 2002 14:01:56 -0400
Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27507
	for <sip@ietf.org>; Wed, 23 Oct 2002 13:59:28 -0400 (EDT)
Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44])
	by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9NI1hcl010217
	for <sip@ietf.org>; Wed, 23 Oct 2002 11:01:44 -0700 (PDT)
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 ABE66384;
	Wed, 23 Oct 2002 10:59:18 -0700 (PDT)
Date: Wed, 23 Oct 2002 11:02:12 -0700
Mime-Version: 1.0 (Apple Message framework v546)
Content-Type: text/plain; charset=US-ASCII; format=flowed
From: Rohan Mahy <rohan@cisco.com>
To: sip@ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: <8E416B94-E6B1-11D6-A132-0003938AF740@cisco.com>
X-Mailer: Apple Mail (2.546)
Content-Transfer-Encoding: 7bit
Subject: [Sip] moving UDP support out of the core SIP document
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hello Everyone,

I wanted to share some thoughts that I had about removing UDP from the 
core SIP document when we go to draft standard. We are probably at 
least one year away from going to Draft Standard. I hope that during 
this time most implementations will support RFC3261, and therefore 
support TCP.  In addition, it is quite likely that when moving to Draft 
Standard that the IESG will REQUIRE TLS support on SIP User Agents. 
This would ensure a ubiquitous hop-by-hop channel security mechanism, 
but which requires a reliable transport (TCP or SCTP).

Obviously UDP is still very attractive in wireless networks (due to RTT 
issues) and in other typically private networks with well-understood 
delay and loss characteristics. To make most implementations simpler 
however, I am proposing that we make unreliable transports (UDP and 
DCCP) of SIP optional in User Agents, and that we put the UDP-specific 
mechanism (ex: much of the complication of the transaction layer for 
handling retransmissions) in a separate Draft Standard document.  It is 
very likely that if we did this there would also be a baseline security 
mechanism for UDP as well (probably some profile of IPsec).  The net 
effect is that SIP User Agents could also talk to each other using TCP 
or TLS+TCP, and that User Agents with a strong preference for UDP would 
have a consistent security mechanism.  Proxies would still support both 
transports, so you could easily communicate between a TCP-only User 
Agent, and as User Agent which prefers UDP without requiring the User 
Agent to switch over to TCP.

I welcome your discussion and comments on this idea.

thanks,
-rohan

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



From mailnull@www1.ietf.org  Wed Oct 23 14:26:50 2002
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 OAA28613
	for <sip-archive@odin.ietf.org>; Wed, 23 Oct 2002 14:26:50 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9NISes15705
	for sip-archive@odin.ietf.org; Wed, 23 Oct 2002 14:28:40 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9NISFv15680;
	Wed, 23 Oct 2002 14:28:15 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9NIQFv15573
	for <sip@optimus.ietf.org>; Wed, 23 Oct 2002 14:26:15 -0400
Received: from host.serversanddomains.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28384
	for <sip@ietf.org>; Wed, 23 Oct 2002 14:23:53 -0400 (EDT)
Received: from victorpc ([206.184.140.168])
	by host.serversanddomains.com (8.10.2/8.10.2) with SMTP id g9NIQ5v25973;
	Wed, 23 Oct 2002 14:26:05 -0400
From: "Victor Paulsamy" <victor@zapex.com>
To: "Rohan Mahy" <rohan@cisco.com>, <sip@ietf.org>
Subject: RE: [Sip] moving UDP support out of the core SIP document
Date: Wed, 23 Oct 2002 11:23:19 -0700
Message-ID: <NEBBIPNANPGLCDPGFJGPEECLCGAA.victor@zapex.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 IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Importance: Normal
In-Reply-To: <8E416B94-E6B1-11D6-A132-0003938AF740@cisco.com>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

If SIP is "truly" independent of underlying transport protocols, wouldn't it
be appropriate to make all transports "optional"?

Regards,

--victor

> -----Original Message-----
> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Rohan
> Mahy
> Sent: Wednesday, October 23, 2002 11:02 AM
> To: sip@ietf.org
> Subject: [Sip] moving UDP support out of the core SIP document
>
>
> Hello Everyone,
>
> I wanted to share some thoughts that I had about removing UDP from the
> core SIP document when we go to draft standard. We are probably at
> least one year away from going to Draft Standard. I hope that during
> this time most implementations will support RFC3261, and therefore
> support TCP.  In addition, it is quite likely that when moving to Draft
> Standard that the IESG will REQUIRE TLS support on SIP User Agents.
> This would ensure a ubiquitous hop-by-hop channel security mechanism,
> but which requires a reliable transport (TCP or SCTP).
>
> Obviously UDP is still very attractive in wireless networks (due to RTT
> issues) and in other typically private networks with well-understood
> delay and loss characteristics. To make most implementations simpler
> however, I am proposing that we make unreliable transports (UDP and
> DCCP) of SIP optional in User Agents, and that we put the UDP-specific
> mechanism (ex: much of the complication of the transaction layer for
> handling retransmissions) in a separate Draft Standard document.  It is
> very likely that if we did this there would also be a baseline security
> mechanism for UDP as well (probably some profile of IPsec).  The net
> effect is that SIP User Agents could also talk to each other using TCP
> or TLS+TCP, and that User Agents with a strong preference for UDP would
> have a consistent security mechanism.  Proxies would still support both
> transports, so you could easily communicate between a TCP-only User
> Agent, and as User Agent which prefers UDP without requiring the User
> Agent to switch over to TCP.
>
> I welcome your discussion and comments on this idea.
>
> thanks,
> -rohan
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>

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



From mailnull@www1.ietf.org  Wed Oct 23 15:02:25 2002
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 PAA00196
	for <sip-archive@odin.ietf.org>; Wed, 23 Oct 2002 15:02:24 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9NJ4G617679
	for sip-archive@odin.ietf.org; Wed, 23 Oct 2002 15:04:16 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9NJ3uv17648;
	Wed, 23 Oct 2002 15:03:56 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9NJ2Qv17595
	for <sip@optimus.ietf.org>; Wed, 23 Oct 2002 15:02:26 -0400
Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29995
	for <sip@ietf.org>; Wed, 23 Oct 2002 15:00:04 -0400 (EDT)
Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44])
	by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9NJ2Icl014862;
	Wed, 23 Oct 2002 12:02:18 -0700 (PDT)
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 ABE67522;
	Wed, 23 Oct 2002 11:59:53 -0700 (PDT)
Date: Wed, 23 Oct 2002 12:02:47 -0700
Subject: Re: [Sip] moving UDP support out of the core SIP document
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v546)
Cc: <sip@ietf.org>
To: "Victor Paulsamy" <victor@zapex.com>
From: Rohan Mahy <rohan@cisco.com>
In-Reply-To: <NEBBIPNANPGLCDPGFJGPEECLCGAA.victor@zapex.com>
Message-Id: <04E5FF68-E6BA-11D6-A132-0003938AF740@cisco.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.546)
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi Victor,

Having no default transport does not encourage interoperability which 
is a major goal of Internet protocols.

thanks,
-rohan

On Wednesday, October 23, 2002, at 11:23 AM, Victor Paulsamy wrote:

> If SIP is "truly" independent of underlying transport protocols, 
> wouldn't it
> be appropriate to make all transports "optional"?
>
> Regards,
>
> --victor
>
>> -----Original Message-----
>> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Rohan
>> Mahy
>> Sent: Wednesday, October 23, 2002 11:02 AM
>> To: sip@ietf.org
>> Subject: [Sip] moving UDP support out of the core SIP document
>>
>>
>> Hello Everyone,
>>
>> I wanted to share some thoughts that I had about removing UDP from the
>> core SIP document when we go to draft standard. We are probably at
>> least one year away from going to Draft Standard. I hope that during
>> this time most implementations will support RFC3261, and therefore
>> support TCP.  In addition, it is quite likely that when moving to 
>> Draft
>> Standard that the IESG will REQUIRE TLS support on SIP User Agents.
>> This would ensure a ubiquitous hop-by-hop channel security mechanism,
>> but which requires a reliable transport (TCP or SCTP).
>>
>> Obviously UDP is still very attractive in wireless networks (due to 
>> RTT
>> issues) and in other typically private networks with well-understood
>> delay and loss characteristics. To make most implementations simpler
>> however, I am proposing that we make unreliable transports (UDP and
>> DCCP) of SIP optional in User Agents, and that we put the UDP-specific
>> mechanism (ex: much of the complication of the transaction layer for
>> handling retransmissions) in a separate Draft Standard document.  It 
>> is
>> very likely that if we did this there would also be a baseline 
>> security
>> mechanism for UDP as well (probably some profile of IPsec).  The net
>> effect is that SIP User Agents could also talk to each other using TCP
>> or TLS+TCP, and that User Agents with a strong preference for UDP 
>> would
>> have a consistent security mechanism.  Proxies would still support 
>> both
>> transports, so you could easily communicate between a TCP-only User
>> Agent, and as User Agent which prefers UDP without requiring the User
>> Agent to switch over to TCP.
>>
>> I welcome your discussion and comments on this idea.
>>
>> thanks,
>> -rohan
>>
>> _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol
>> Use sip-implementors@cs.columbia.edu for questions on current sip
>> Use sipping@ietf.org for new developments on the application of sip
>>
>

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



From mailnull@www1.ietf.org  Wed Oct 23 16:59:45 2002
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 QAA05303
	for <sip-archive@odin.ietf.org>; Wed, 23 Oct 2002 16:59:45 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9NL1bS24128
	for sip-archive@odin.ietf.org; Wed, 23 Oct 2002 17:01:37 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9NKxsv23539;
	Wed, 23 Oct 2002 16:59:54 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9NKvtv23449
	for <sip@optimus.ietf.org>; Wed, 23 Oct 2002 16:57:55 -0400
Received: from rainier.illuminet.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05032
	for <sip@ietf.org>; Wed, 23 Oct 2002 16:55:29 -0400 (EDT)
Received: from olwinexsmtp01.corp.illuminet.com (olwinexsmtp01.corp.illuminet.com [172.20.1.9]) by rainier.illuminet.com (8.8.8/8.8.8) with ESMTP id NAA12784; Wed, 23 Oct 2002 13:57:23 -0700 (PDT)
Received: by olwinexsmtp01.corp.illuminet.com with Internet Mail Service (5.5.2656.59)
	id <4D8HQWCZ>; Wed, 23 Oct 2002 13:57:23 -0700
Message-ID: <7016B23F645D5F4B9A652F7A559698FEB38EE4@opwinexrec01.corp.illuminet.com>
From: Kevin McCandless <KMcCandless@verisign.com>
To: "'Rohan Mahy'" <rohan@cisco.com>, Victor Paulsamy <victor@zapex.com>
Cc: sip@ietf.org
Subject: RE: [Sip] moving UDP support out of the core SIP document
Date: Wed, 23 Oct 2002 13:57:19 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

Rohan:

At first I would have to agree with Victor but you are right we need a base
for SIP transport.  I remember a white paper that looked at SCTP, TCP and
UDP as transport protocols for SIP.  If you were a carrier with large
amounts of SIP traffic SCTP would be the better transport protocol.  For
less traffic that would be seen between proxy and UA then TCP could be used.
Is it possible to the draft address the three transport protocols and the
necessary security mechanism to support them.  By recommending only one
protocol don't we several limit the deployment.

Just my thoughts....

Kevin... 

> -----Original Message-----
> From: Rohan Mahy [mailto:rohan@cisco.com]
> Sent: Wednesday, October 23, 2002 2:03 PM
> To: Victor Paulsamy
> Cc: sip@ietf.org
> Subject: Re: [Sip] moving UDP support out of the core SIP document
> 
> 
> Hi Victor,
> 
> Having no default transport does not encourage interoperability which 
> is a major goal of Internet protocols.
> 
> thanks,
> -rohan
> 
> On Wednesday, October 23, 2002, at 11:23 AM, Victor Paulsamy wrote:
> 
> > If SIP is "truly" independent of underlying transport protocols, 
> > wouldn't it
> > be appropriate to make all transports "optional"?
> >
> > Regards,
> >
> > --victor
> >
> >> -----Original Message-----
> >> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On 
> Behalf Of Rohan
> >> Mahy
> >> Sent: Wednesday, October 23, 2002 11:02 AM
> >> To: sip@ietf.org
> >> Subject: [Sip] moving UDP support out of the core SIP document
> >>
> >>
> >> Hello Everyone,
> >>
> >> I wanted to share some thoughts that I had about removing 
> UDP from the
> >> core SIP document when we go to draft standard. We are probably at
> >> least one year away from going to Draft Standard. I hope 
> that during
> >> this time most implementations will support RFC3261, and therefore
> >> support TCP.  In addition, it is quite likely that when moving to 
> >> Draft
> >> Standard that the IESG will REQUIRE TLS support on SIP User Agents.
> >> This would ensure a ubiquitous hop-by-hop channel security 
> mechanism,
> >> but which requires a reliable transport (TCP or SCTP).
> >>
> >> Obviously UDP is still very attractive in wireless 
> networks (due to 
> >> RTT
> >> issues) and in other typically private networks with 
> well-understood
> >> delay and loss characteristics. To make most 
> implementations simpler
> >> however, I am proposing that we make unreliable transports (UDP and
> >> DCCP) of SIP optional in User Agents, and that we put the 
> UDP-specific
> >> mechanism (ex: much of the complication of the transaction 
> layer for
> >> handling retransmissions) in a separate Draft Standard 
> document.  It 
> >> is
> >> very likely that if we did this there would also be a baseline 
> >> security
> >> mechanism for UDP as well (probably some profile of 
> IPsec).  The net
> >> effect is that SIP User Agents could also talk to each 
> other using TCP
> >> or TLS+TCP, and that User Agents with a strong preference for UDP 
> >> would
> >> have a consistent security mechanism.  Proxies would still support 
> >> both
> >> transports, so you could easily communicate between a TCP-only User
> >> Agent, and as User Agent which prefers UDP without 
> requiring the User
> >> Agent to switch over to TCP.
> >>
> >> I welcome your discussion and comments on this idea.
> >>
> >> thanks,
> >> -rohan
> >>
> >> _______________________________________________
> >> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >> This list is for NEW development of the core SIP Protocol
> >> Use sip-implementors@cs.columbia.edu for questions on current sip
> >> Use sipping@ietf.org for new developments on the application of sip
> >>
> >
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Wed Oct 23 17:24:31 2002
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 RAA05890
	for <sip-archive@odin.ietf.org>; Wed, 23 Oct 2002 17:24:31 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9NLQOZ25249
	for sip-archive@odin.ietf.org; Wed, 23 Oct 2002 17:26:24 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9NLPVv25221;
	Wed, 23 Oct 2002 17:25:31 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9NLOCv25170
	for <sip@optimus.ietf.org>; Wed, 23 Oct 2002 17:24:12 -0400
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 RAA05835
	for <sip@ietf.org>; Wed, 23 Oct 2002 17:21:48 -0400 (EDT)
Received: from pmismtp06.wcomnet.com ([166.38.62.54])
 by firewall.wcom.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May  7
 2002)) with ESMTP id <0H4G003K3DZDU9@firewall.wcom.com> for sip@ietf.org; Wed,
 23 Oct 2002 21:21:14 +0000 (GMT)
Received: from pmismtp06.wcomnet.com by pmismtp06.wcomnet.com
 (iPlanet Messaging Server 5.1 HotFix 0.7 (built May  7 2002))
 with SMTP id <0H4G00L01DZDCF@pmismtp06.wcomnet.com>; Wed,
 23 Oct 2002 21:21:13 +0000 (GMT)
Received: from hsinnreich2 ([166.42.40.85])
 by pmismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7
 2002)) with ESMTP id <0H4G00EV6DZAVG@pmismtp06.wcomnet.com>; Wed,
 23 Oct 2002 21:21:13 +0000 (GMT)
Date: Wed, 23 Oct 2002 16:21:10 -0500
From: Henry Sinnreich <Henry.Sinnreich@wcom.com>
Subject: RE: [Sip] moving UDP support out of the core SIP document
In-reply-to: 
 <7016B23F645D5F4B9A652F7A559698FEB38EE4@opwinexrec01.corp.illuminet.com>
To: "'Kevin McCandless'" <KMcCandless@verisign.com>,
        "'Rohan Mahy'" <rohan@cisco.com>,
        "'Victor Paulsamy'" <victor@zapex.com>
Cc: sip@ietf.org
Message-id: <000901c27ada$1d0f5b00$55282aa6@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
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

I agree with Rohan to have a default value.

Thanks, Henry

> -----Original Message-----
> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On 
> Behalf Of Kevin McCandless
> Sent: Wednesday, October 23, 2002 3:57 PM
> To: 'Rohan Mahy'; Victor Paulsamy
> Cc: sip@ietf.org
> Subject: RE: [Sip] moving UDP support out of the core SIP document
> 
> 
> Rohan:
> 
> At first I would have to agree with Victor but you are right 
> we need a base for SIP transport.  I remember a white paper 
> that looked at SCTP, TCP and UDP as transport protocols for 
> SIP.  If you were a carrier with large amounts of SIP traffic 
> SCTP would be the better transport protocol.  For less 
> traffic that would be seen between proxy and UA then TCP 
> could be used. Is it possible to the draft address the three 
> transport protocols and the necessary security mechanism to 
> support them.  By recommending only one protocol don't we 
> several limit the deployment.
> 
> Just my thoughts....
> 
> Kevin... 
> 
> > -----Original Message-----
> > From: Rohan Mahy [mailto:rohan@cisco.com]
> > Sent: Wednesday, October 23, 2002 2:03 PM
> > To: Victor Paulsamy
> > Cc: sip@ietf.org
> > Subject: Re: [Sip] moving UDP support out of the core SIP document
> > 
> > 
> > Hi Victor,
> > 
> > Having no default transport does not encourage 
> interoperability which
> > is a major goal of Internet protocols.
> > 
> > thanks,
> > -rohan
> > 
> > On Wednesday, October 23, 2002, at 11:23 AM, Victor Paulsamy wrote:
> > 
> > > If SIP is "truly" independent of underlying transport protocols,
> > > wouldn't it
> > > be appropriate to make all transports "optional"?
> > >
> > > Regards,
> > >
> > > --victor
> > >
> > >> -----Original Message-----
> > >> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On
> > Behalf Of Rohan
> > >> Mahy
> > >> Sent: Wednesday, October 23, 2002 11:02 AM
> > >> To: sip@ietf.org
> > >> Subject: [Sip] moving UDP support out of the core SIP document
> > >>
> > >>
> > >> Hello Everyone,
> > >>
> > >> I wanted to share some thoughts that I had about removing
> > UDP from the
> > >> core SIP document when we go to draft standard. We are 
> probably at 
> > >> least one year away from going to Draft Standard. I hope
> > that during
> > >> this time most implementations will support RFC3261, and 
> therefore 
> > >> support TCP.  In addition, it is quite likely that when 
> moving to 
> > >> Draft Standard that the IESG will REQUIRE TLS support on 
> SIP User 
> > >> Agents. This would ensure a ubiquitous hop-by-hop 
> channel security
> > mechanism,
> > >> but which requires a reliable transport (TCP or SCTP).
> > >>
> > >> Obviously UDP is still very attractive in wireless
> > networks (due to
> > >> RTT
> > >> issues) and in other typically private networks with
> > well-understood
> > >> delay and loss characteristics. To make most
> > implementations simpler
> > >> however, I am proposing that we make unreliable 
> transports (UDP and
> > >> DCCP) of SIP optional in User Agents, and that we put the
> > UDP-specific
> > >> mechanism (ex: much of the complication of the transaction
> > layer for
> > >> handling retransmissions) in a separate Draft Standard
> > document.  It
> > >> is
> > >> very likely that if we did this there would also be a baseline
> > >> security
> > >> mechanism for UDP as well (probably some profile of 
> > IPsec).  The net
> > >> effect is that SIP User Agents could also talk to each
> > other using TCP
> > >> or TLS+TCP, and that User Agents with a strong preference for UDP
> > >> would
> > >> have a consistent security mechanism.  Proxies would 
> still support 
> > >> both
> > >> transports, so you could easily communicate between a 
> TCP-only User
> > >> Agent, and as User Agent which prefers UDP without 
> > requiring the User
> > >> Agent to switch over to TCP.
> > >>
> > >> I welcome your discussion and comments on this idea.
> > >>
> > >> thanks,
> > >> -rohan
> > >>
> > >> _______________________________________________
> > >> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > >> This list is for NEW development of the core SIP Protocol Use 
> > >> sip-implementors@cs.columbia.edu for questions on 
> current sip Use 
> > >> sipping@ietf.org for new developments on the application of sip
> > >>
> > >
> > 
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on 
> current sip Use 
> > sipping@ietf.org for new developments on the application of sip
> > 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current 
> sip Use sipping@ietf.org for new developments on the 
> application of sip
> 

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



From mailnull@www1.ietf.org  Wed Oct 23 23:09:17 2002
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 XAA15036
	for <sip-archive@odin.ietf.org>; Wed, 23 Oct 2002 23:09:17 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9O3BDW08512
	for sip-archive@odin.ietf.org; Wed, 23 Oct 2002 23:11:13 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9O3Alv08495;
	Wed, 23 Oct 2002 23:10:48 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9O38pv08413
	for <sip@optimus.ietf.org>; Wed, 23 Oct 2002 23:08:51 -0400
Received: from david.sae.siemens.com.sg (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15010
	for <sip@ietf.org>; Wed, 23 Oct 2002 23:06:23 -0400 (EDT)
X-Envelope-Sender-Is: kokjeng.loh@siemens.com (at relayer david.sae.siemens.com.sg)
Received: from mail.sae.siemens.com.sg (mail.sae.siemens.com.sg [194.138.237.14])
	by david.sae.siemens.com.sg (8.11.6/8.11.6) with ESMTP id g9O35ul20280;
	Thu, 24 Oct 2002 11:05:56 +0800 (SGT)
Received: from sgpk001a.sae.siemens.com.sg (sgpk001a.sae.siemens.com.sg [140.231.107.1])
	by mail.sae.siemens.com.sg (8.11.6/8.11.6) with ESMTP id g9O377X12343;
	Thu, 24 Oct 2002 11:07:08 +0800 (SGT)
Received: by sgpk001a.sae.siemens.com.sg with Internet Mail Service (5.5.2655.55)
	id <T8LWKTX8>; Thu, 24 Oct 2002 11:02:08 +0800
Message-ID: <7319EDDDE0CD7C458023FF64886CB1776D2F2E@sgpk001a.sae.siemens.com.sg>
From: Loh Kok Jeng <kokjeng.loh@siemens.com>
To: manoj mallik <m.manoj@ipnetfusion.com>,
        "Krishna, Samaga"
	 <samaga.krishna@intel.com>, sip@ietf.org
Subject: RE: [Sip] Questions on Max-Forwards
Date: Thu, 24 Oct 2002 11:02:08 +0800
X-Mailer: Internet Mail Service (5.5.2655.55)
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

Hi,

If a UA wants to query a proxy with OPTIONS, what should be placed 
at "To:" header?  I think RFC3261 does not mention about this.

regards,
KJ Loh

> -----Original Message-----
> From: manoj mallik [mailto:m.manoj@ipnetfusion.com]
> Sent: Wednesday, October 23, 2002 11:28 PM
> To: Loh Kok Jeng; Krishna, Samaga; sip@ietf.org
> Subject: RE: [Sip] Questions on Max-Forwards
> 
> 
> inline
> 
> -----Original Message-----
> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf 
> Of Loh Kok
> Jeng
> Sent: Wednesday, October 23, 2002 7:10 AM
> To: Krishna, Samaga; sip@ietf.org
> Subject: RE: [Sip] Questions on Max-Forwards
> 
> 
> Hi,
> 
> Thanks for your reply.  Section 11 says:
> 
>    Alternatively, a server receiving an OPTIONS request with a Max-
>    Forwards header field value of 0 MAY respond to the request
>    regardless of the Request-URI.
> 
> Does it mean that a proxy may send 483 instead of 200?
> 
> >>>>Manoj: It indicates that if the Request is OPTIONS with 
> Max-Forwards 0,
> then it MAY act as final receiptant and respond to the 
> Request irrespective
> of the target in Request-URI. i.e even if the Request-URI is 
> not meant for
> him, it will respond to that OPTIONS request. It doesn't say 
> about the kind
> of Response. However RFC-3261, sec 11.2 Processing of OPTIONS 
> Request, says
> that
> 
>    "If the response to an OPTIONS is generated by a proxy server, the
>    proxy returns a 200 (OK), listing the capabilities of the server.
>    The response does not contain a message body."
> 
> What if the value of Max-Forwards is outside the permitted range
> 0-255?  Should a 400 response be sent?
> 
> Manoj>>>> This is a good question. I think nothing is 
> mentioned in the RFC
> if Max-Forwards is outside the permitted range 0-255. So it 
> is really hard
> to say what should be the response, may be it is 
> implementation dependent.
> 
> regards,
> KJ Loh
> 
> > -----Original Message-----
> > From: Krishna, Samaga [mailto:samaga.krishna@intel.com]
> > Sent: Wednesday, October 23, 2002 5:53 PM
> > To: 'Loh Kok Jeng'; sip@ietf.org
> > Subject: RE: [Sip] Questions on Max-Forwards
> >
> >
> > Hi Loh,
> >  If proxy receives a request with Max-Forward : 1, the proxy
> > will decrement
> > the count and forward the message.
> > If proxy receives the request with Max-Forward: 0, it should
> > not forward the
> > request. It shall send 483 response. If the request is for
> > OPTIONS, proxy
> > will act as final recipient and respond to it as in the RFC
> > 3261 section 11.
> >
> >
> > have a nice day
> > Prasanna
> >
> >
> >
> > -----Original Message-----
> > From: Loh Kok Jeng [mailto:kokjeng.loh@siemens.com]
> > Sent: Wednesday, October 23, 2002 1:00 PM
> > To: sip@ietf.org
> > Subject: [Sip] Questions on Max-Forwards
> >
> >
> > Dear all,
> >
> > If a valid SIP message with "Max-Forwards: 1" is received by
> > a proxy, should
> >
> > the proxy decrement Max-Forwards and forward it, or should it
> > respond with
> > 483?
> >
> > Likewise, how should the proxy handle a message with with
> > Max-Forwards: 0
> > or a negative value?
> >
> > regards,
> > KJ Loh
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip
> >
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Wed Oct 23 23:35:47 2002
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 XAA15557
	for <sip-archive@odin.ietf.org>; Wed, 23 Oct 2002 23:35:47 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9O3bhW09883
	for sip-archive@odin.ietf.org; Wed, 23 Oct 2002 23:37:43 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9O3bOv09808;
	Wed, 23 Oct 2002 23:37:24 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9O3aTv09282
	for <sip@optimus.ietf.org>; Wed, 23 Oct 2002 23:36:29 -0400
Received: from david.sae.siemens.com.sg (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15535
	for <sip@ietf.org>; Wed, 23 Oct 2002 23:34:00 -0400 (EDT)
X-Envelope-Sender-Is: kokjeng.loh@siemens.com (at relayer david.sae.siemens.com.sg)
Received: from mail.sae.siemens.com.sg (mail.sae.siemens.com.sg [194.138.237.14])
	by david.sae.siemens.com.sg (8.11.6/8.11.6) with ESMTP id g9O3XTl22036;
	Thu, 24 Oct 2002 11:33:31 +0800 (SGT)
Received: from sgpk001a.sae.siemens.com.sg (sgpk001a.sae.siemens.com.sg [140.231.107.1])
	by mail.sae.siemens.com.sg (8.11.6/8.11.6) with ESMTP id g9O3YgX14164;
	Thu, 24 Oct 2002 11:34:42 +0800 (SGT)
Received: by sgpk001a.sae.siemens.com.sg with Internet Mail Service (5.5.2655.55)
	id <T8LWK4HM>; Thu, 24 Oct 2002 11:29:43 +0800
Message-ID: <7319EDDDE0CD7C458023FF64886CB1776D2F30@sgpk001a.sae.siemens.com.sg>
From: Loh Kok Jeng <kokjeng.loh@siemens.com>
To: manoj mallik <m.manoj@ipnetfusion.com>,
        "Krishna, Samaga"
	 <samaga.krishna@intel.com>, sip@ietf.org
Subject: RE: [Sip] Questions on Max-Forwards
Date: Thu, 24 Oct 2002 11:29:42 +0800
X-Mailer: Internet Mail Service (5.5.2655.55)
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

Hi,

One more question on Max-Forwards.  How should an ACK with Max-Forwards 0 
be handled by a proxy or UAS?  One normally does not send a respond to ACK, 
so should ACK with Max-Forwards 0 be silently discarded?  Thanks.

regards,
KJ Loh


> -----Original Message-----
> From: manoj mallik [mailto:m.manoj@ipnetfusion.com]
> Sent: Wednesday, October 23, 2002 11:28 PM
> To: Loh Kok Jeng; Krishna, Samaga; sip@ietf.org
> Subject: RE: [Sip] Questions on Max-Forwards
> 
> 
> inline
> 
> -----Original Message-----
> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf 
> Of Loh Kok
> Jeng
> Sent: Wednesday, October 23, 2002 7:10 AM
> To: Krishna, Samaga; sip@ietf.org
> Subject: RE: [Sip] Questions on Max-Forwards
> 
> 
> Hi,
> 
> Thanks for your reply.  Section 11 says:
> 
>    Alternatively, a server receiving an OPTIONS request with a Max-
>    Forwards header field value of 0 MAY respond to the request
>    regardless of the Request-URI.
> 
> Does it mean that a proxy may send 483 instead of 200?
> 
> >>>>Manoj: It indicates that if the Request is OPTIONS with 
> Max-Forwards 0,
> then it MAY act as final receiptant and respond to the 
> Request irrespective
> of the target in Request-URI. i.e even if the Request-URI is 
> not meant for
> him, it will respond to that OPTIONS request. It doesn't say 
> about the kind
> of Response. However RFC-3261, sec 11.2 Processing of OPTIONS 
> Request, says
> that
> 
>    "If the response to an OPTIONS is generated by a proxy server, the
>    proxy returns a 200 (OK), listing the capabilities of the server.
>    The response does not contain a message body."
> 
> What if the value of Max-Forwards is outside the permitted range
> 0-255?  Should a 400 response be sent?
> 
> Manoj>>>> This is a good question. I think nothing is 
> mentioned in the RFC
> if Max-Forwards is outside the permitted range 0-255. So it 
> is really hard
> to say what should be the response, may be it is 
> implementation dependent.
> 
> regards,
> KJ Loh
> 
> > -----Original Message-----
> > From: Krishna, Samaga [mailto:samaga.krishna@intel.com]
> > Sent: Wednesday, October 23, 2002 5:53 PM
> > To: 'Loh Kok Jeng'; sip@ietf.org
> > Subject: RE: [Sip] Questions on Max-Forwards
> >
> >
> > Hi Loh,
> >  If proxy receives a request with Max-Forward : 1, the proxy
> > will decrement
> > the count and forward the message.
> > If proxy receives the request with Max-Forward: 0, it should
> > not forward the
> > request. It shall send 483 response. If the request is for
> > OPTIONS, proxy
> > will act as final recipient and respond to it as in the RFC
> > 3261 section 11.
> >
> >
> > have a nice day
> > Prasanna
> >
> >
> >
> > -----Original Message-----
> > From: Loh Kok Jeng [mailto:kokjeng.loh@siemens.com]
> > Sent: Wednesday, October 23, 2002 1:00 PM
> > To: sip@ietf.org
> > Subject: [Sip] Questions on Max-Forwards
> >
> >
> > Dear all,
> >
> > If a valid SIP message with "Max-Forwards: 1" is received by
> > a proxy, should
> >
> > the proxy decrement Max-Forwards and forward it, or should it
> > respond with
> > 483?
> >
> > Likewise, how should the proxy handle a message with with
> > Max-Forwards: 0
> > or a negative value?
> >
> > regards,
> > KJ Loh
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip
> >
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Wed Oct 23 23:47:46 2002
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 XAA15896
	for <sip-archive@odin.ietf.org>; Wed, 23 Oct 2002 23:47:46 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9O3ng410245
	for sip-archive@odin.ietf.org; Wed, 23 Oct 2002 23:49:42 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9O3nOv10223;
	Wed, 23 Oct 2002 23:49:24 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9O3m4v10121
	for <sip@optimus.ietf.org>; Wed, 23 Oct 2002 23:48:04 -0400
Received: from minotaur.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15823
	for <sip@ietf.org>; Wed, 23 Oct 2002 23:45:37 -0400 (EDT)
Received: from minotaur (mankin@localhost)
	by minotaur.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g9O3lpR12878;
	Wed, 23 Oct 2002 23:47:52 -0400
Message-Id: <200210240347.g9O3lpR12878@minotaur.nge.isi.edu>
To: sip@ietf.org
Cc: rohan@cisco.com, jon.peterson@neustar.biz, dean.willis@softarmor.com,
        jo@ipdialog.com, brian.rosen@marconi.com, sob@harvard.edu,
        mankin@psg.com
Reply-To: mankin@psg.com
Date: Wed, 23 Oct 2002 23:47:51 -0400
From: Allison Mankin <mankin@isi.edu>
Subject: [Sip] Some SIP WG Chair Changes
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

All,

This note is to let the SIP WG know of a shift in the
chairships.  Due to increased day job work, both Brian Rosen
and Joerg Ott are stepping down from their SIP co-chairships.

Our thanks are due to them for their efforts over a number
of years!

Dean Willis remains, and taking the other two co-chairships
here (SIP is very busy) will be Rohan Mahy and Jon Peterson.
So the SIP co-chair roster will be:

    Rohan Mahy, rohan@cisco.com
    Jon Peterson, jon.peterson@neustar.biz
    Dean Willis, dean.willis@softarmor.com

Expect them to coordinate very closely.  We're also making SIPPING
chair changes - to that list...

Allison
Transport Area Director for SIP and SIPPING

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



From mailnull@www1.ietf.org  Thu Oct 24 00:59:37 2002
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 AAA17408
	for <sip-archive@odin.ietf.org>; Thu, 24 Oct 2002 00:59:37 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9O51YF13436
	for sip-archive@odin.ietf.org; Thu, 24 Oct 2002 01:01:34 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9O51Dv13422;
	Thu, 24 Oct 2002 01:01:13 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9O4xhv13327
	for <sip@optimus.ietf.org>; Thu, 24 Oct 2002 00:59:43 -0400
Received: from shardagate.mahindrabt.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17267
	for <sip@ietf.org>; Thu, 24 Oct 2002 00:56:57 -0400 (EDT)
Received: from thisdomain (mailscan.sharda.mahindrabt.com [10.5.0.97])
	by shardagate.mahindrabt.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA31208
	for <sip@ietf.org>; Thu, 24 Oct 2002 10:29:00 +0530
Received: from intranet.sharda.mahindrabt.com by mahindrabt.com ; Thu, 24 Oct 2002 10:20:34 +0530
Date: Thu, 24 Oct 2002 10:20:34 +0530
X-Originating-IP: 10.5.0.15
X-Auth-User: kalele@mahindrabt.com
Received: from mahindrabt.com ([10.5.4.79])
	by intranet.sharda.mahindrabt.com (8.9.3/8.9.3) with ESMTP id KAA09257;
	Thu, 24 Oct 2002 10:29:46 +0530
Message-ID: <3DB77E7C.4631AA40@mahindrabt.com>
Date: Thu, 24 Oct 2002 10:30:44 +0530
From: Ajit Kalele <kalele@mahindrabt.com>
X-Mailer: Mozilla 4.73 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Loh Kok Jeng <kokjeng.loh@siemens.com>
CC: "Krishna, Samaga" <samaga.krishna@intel.com>, sip@ietf.org
Subject: Re: [Sip] Questions on Max-Forwards
References: <7319EDDDE0CD7C458023FF64886CB177027CA17C@sgpk001a.sae.siemens.com.sg>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

<Sorry, did a Reply instead of Reply All>

Hi,

>    Alternatively, a server receiving an OPTIONS request with a
Max-
>    Forwards header field value of 0 MAY respond to the request
>    regardless of the Request-URI.
>
> Does it mean that a proxy may send 483 instead of 200?

No, it means that Proxy should send 200 for OPTIONS, even though
the
R-URI doesn't belong to the Proxy.

> What if the value of Max-Forwards is outside the permitted
range
> 0-255?  Should a 400 response be sent?

As per section 16.3 Request Validation, sub-section 3
Max-Forwards check,

"If the request contains a Max-Forwards header field with a
field value
greater than zero, the check is passed."

So ..

For positive values :

I think the Proxy should set it to "69", as if it received it
with a
value "70", and forward the request.

For negative values :

It should send 400 Bad Request.

Best Regards
Ajit

Loh Kok Jeng wrote:

> Hi,
>
> Thanks for your reply.  Section 11 says:
>
>    Alternatively, a server receiving an OPTIONS request with a Max-
>    Forwards header field value of 0 MAY respond to the request
>    regardless of the Request-URI.
>
> Does it mean that a proxy may send 483 instead of 200?
>
> What if the value of Max-Forwards is outside the permitted range
> 0-255?  Should a 400 response be sent?
>
> regards,
> KJ Loh
>
> > -----Original Message-----
> > From: Krishna, Samaga [mailto:samaga.krishna@intel.com]
> > Sent: Wednesday, October 23, 2002 5:53 PM
> > To: 'Loh Kok Jeng'; sip@ietf.org
> > Subject: RE: [Sip] Questions on Max-Forwards
> >
> >
> > Hi Loh,
> >  If proxy receives a request with Max-Forward : 1, the proxy
> > will decrement
> > the count and forward the message.
> > If proxy receives the request with Max-Forward: 0, it should
> > not forward the
> > request. It shall send 483 response. If the request is for
> > OPTIONS, proxy
> > will act as final recipient and respond to it as in the RFC
> > 3261 section 11.
> >
> >
> > have a nice day
> > Prasanna
> >
> >
> >
> > -----Original Message-----
> > From: Loh Kok Jeng [mailto:kokjeng.loh@siemens.com]
> > Sent: Wednesday, October 23, 2002 1:00 PM
> > To: sip@ietf.org
> > Subject: [Sip] Questions on Max-Forwards
> >
> >
> > Dear all,
> >
> > If a valid SIP message with "Max-Forwards: 1" is received by
> > a proxy, should
> >
> > the proxy decrement Max-Forwards and forward it, or should it
> > respond with
> > 483?
> >
> > Likewise, how should the proxy handle a message with with
> > Max-Forwards: 0
> > or a negative value?
> >
> > regards,
> > KJ Loh
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip
> >
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip

*********************************************************
Disclaimer

This message (including any attachments) contains 
confidential information intended for a specific 
individual and purpose, and is protected by law. 
If you are not the intended recipient, you should 
delete this message and are hereby notified that 
any disclosure, copying, or distribution of this
message, or the taking of any action based on it, 
is strictly prohibited.

*********************************************************
Visit us at http://www.mahindrabt.com


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



From mailnull@www1.ietf.org  Thu Oct 24 01:13:39 2002
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 BAA17563
	for <sip-archive@odin.ietf.org>; Thu, 24 Oct 2002 01:13:38 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9O5Fav14266
	for sip-archive@odin.ietf.org; Thu, 24 Oct 2002 01:15:36 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9O5FFv14257;
	Thu, 24 Oct 2002 01:15:15 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9O5EOv14216
	for <sip@optimus.ietf.org>; Thu, 24 Oct 2002 01:14:24 -0400
Received: from shardagate.mahindrabt.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17548
	for <sip@ietf.org>; Thu, 24 Oct 2002 01:11:31 -0400 (EDT)
Received: from thisdomain (mailscan.sharda.mahindrabt.com [10.5.0.97])
	by shardagate.mahindrabt.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA00959
	for <sip@ietf.org>; Thu, 24 Oct 2002 10:43:39 +0530
Received: from intranet.sharda.mahindrabt.com by mahindrabt.com ; Thu, 24 Oct 2002 10:35:14 +0530
Date: Thu, 24 Oct 2002 10:35:14 +0530
X-Originating-IP: 10.5.0.15
X-Auth-User: kalele@mahindrabt.com
Received: from mahindrabt.com ([10.5.4.79])
	by intranet.sharda.mahindrabt.com (8.9.3/8.9.3) with ESMTP id KAA21461;
	Thu, 24 Oct 2002 10:44:26 +0530
Message-ID: <3DB781EB.7169477F@mahindrabt.com>
Date: Thu, 24 Oct 2002 10:45:23 +0530
From: Ajit Kalele <kalele@mahindrabt.com>
X-Mailer: Mozilla 4.73 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Loh Kok Jeng <kokjeng.loh@siemens.com>
CC: manoj mallik <m.manoj@ipnetfusion.com>,
        "Krishna, Samaga" <samaga.krishna@intel.com>, sip@ietf.org
Subject: Re: [Sip] Questions on Max-Forwards
References: <7319EDDDE0CD7C458023FF64886CB1776D2F30@sgpk001a.sae.siemens.com.sg>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi,

Again as per section 16.3 Request Validation, sub-section 3
Max-Forwards check,

    "If the request contains a Max-Forwards header field with a field
      value greater than zero, the check is passed.

      If the request contains a Max-Forwards header field with a field
      value of zero (0), the element MUST NOT forward the request."

So the ACK with Max-Forwards 0 should be silently discarded.

Best Regards
Ajit

Loh Kok Jeng wrote:

> Hi,
>
> One more question on Max-Forwards.  How should an ACK with Max-Forwards 0
> be handled by a proxy or UAS?  One normally does not send a respond to ACK,
> so should ACK with Max-Forwards 0 be silently discarded?  Thanks.
>
> regards,
> KJ Loh
>
> > -----Original Message-----
> > From: manoj mallik [mailto:m.manoj@ipnetfusion.com]
> > Sent: Wednesday, October 23, 2002 11:28 PM
> > To: Loh Kok Jeng; Krishna, Samaga; sip@ietf.org
> > Subject: RE: [Sip] Questions on Max-Forwards
> >
> >
> > inline
> >
> > -----Original Message-----
> > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf
> > Of Loh Kok
> > Jeng
> > Sent: Wednesday, October 23, 2002 7:10 AM
> > To: Krishna, Samaga; sip@ietf.org
> > Subject: RE: [Sip] Questions on Max-Forwards
> >
> >
> > Hi,
> >
> > Thanks for your reply.  Section 11 says:
> >
> >    Alternatively, a server receiving an OPTIONS request with a Max-
> >    Forwards header field value of 0 MAY respond to the request
> >    regardless of the Request-URI.
> >
> > Does it mean that a proxy may send 483 instead of 200?
> >
> > >>>>Manoj: It indicates that if the Request is OPTIONS with
> > Max-Forwards 0,
> > then it MAY act as final receiptant and respond to the
> > Request irrespective
> > of the target in Request-URI. i.e even if the Request-URI is
> > not meant for
> > him, it will respond to that OPTIONS request. It doesn't say
> > about the kind
> > of Response. However RFC-3261, sec 11.2 Processing of OPTIONS
> > Request, says
> > that
> >
> >    "If the response to an OPTIONS is generated by a proxy server, the
> >    proxy returns a 200 (OK), listing the capabilities of the server.
> >    The response does not contain a message body."
> >
> > What if the value of Max-Forwards is outside the permitted range
> > 0-255?  Should a 400 response be sent?
> >
> > Manoj>>>> This is a good question. I think nothing is
> > mentioned in the RFC
> > if Max-Forwards is outside the permitted range 0-255. So it
> > is really hard
> > to say what should be the response, may be it is
> > implementation dependent.
> >
> > regards,
> > KJ Loh
> >
> > > -----Original Message-----
> > > From: Krishna, Samaga [mailto:samaga.krishna@intel.com]
> > > Sent: Wednesday, October 23, 2002 5:53 PM
> > > To: 'Loh Kok Jeng'; sip@ietf.org
> > > Subject: RE: [Sip] Questions on Max-Forwards
> > >
> > >
> > > Hi Loh,
> > >  If proxy receives a request with Max-Forward : 1, the proxy
> > > will decrement
> > > the count and forward the message.
> > > If proxy receives the request with Max-Forward: 0, it should
> > > not forward the
> > > request. It shall send 483 response. If the request is for
> > > OPTIONS, proxy
> > > will act as final recipient and respond to it as in the RFC
> > > 3261 section 11.
> > >
> > >
> > > have a nice day
> > > Prasanna
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Loh Kok Jeng [mailto:kokjeng.loh@siemens.com]
> > > Sent: Wednesday, October 23, 2002 1:00 PM
> > > To: sip@ietf.org
> > > Subject: [Sip] Questions on Max-Forwards
> > >
> > >
> > > Dear all,
> > >
> > > If a valid SIP message with "Max-Forwards: 1" is received by
> > > a proxy, should
> > >
> > > the proxy decrement Max-Forwards and forward it, or should it
> > > respond with
> > > 483?
> > >
> > > Likewise, how should the proxy handle a message with with
> > > Max-Forwards: 0
> > > or a negative value?
> > >
> > > regards,
> > > KJ Loh
> > > _______________________________________________
> > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > This list is for NEW development of the core SIP Protocol
> > > Use sip-implementors@cs.columbia.edu for questions on current sip
> > > Use sipping@ietf.org for new developments on the application of sip
> > >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip
> >
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip

*********************************************************
Disclaimer

This message (including any attachments) contains 
confidential information intended for a specific 
individual and purpose, and is protected by law. 
If you are not the intended recipient, you should 
delete this message and are hereby notified that 
any disclosure, copying, or distribution of this
message, or the taking of any action based on it, 
is strictly prohibited.

*********************************************************
Visit us at http://www.mahindrabt.com


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



From mailnull@www1.ietf.org  Thu Oct 24 07:57:01 2002
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 HAA03040
	for <sip-archive@odin.ietf.org>; Thu, 24 Oct 2002 07:57:01 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9OBwo110586
	for sip-archive@odin.ietf.org; Thu, 24 Oct 2002 07:58:50 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OBwSv10525;
	Thu, 24 Oct 2002 07:58:28 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OBq3v10325
	for <sip@optimus.ietf.org>; Thu, 24 Oct 2002 07:52:03 -0400
Received: from fw1a.telekom.de (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02862
	for <sip@ietf.org>; Thu, 24 Oct 2002 07:49:42 -0400 (EDT)
Received: by fw1a.telekom.de; (8.8.8/1.3/10May95) id NAA18502; Thu, 24 Oct 2002 13:48:31 +0200 (MET DST)
Received: from g9jbr.mgb01.telekom.de by G8PXB.blf01.telekom.de with ESMTP for sip@ietf.org; Thu, 24 Oct 2002 13:42:49 +0200
Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <VKARVJ3S>; Thu, 24 Oct 2002 13:42:45 +0200
Message-Id: <A89A213731F7D51196A0000347055C83E393B2@G9JNT.mgb01.telekom.de>
From: "Alexeitsev, D" <D.Alexeitsev@telekom.de>
To: sip@ietf.org
Date: Thu, 24 Oct 2002 13:42:45 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sip] 406 Not Acceptable
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

Hello All,

Could someone clarify what this paragraph is trying to say and what are the "response entities"? Is this response only possible to the requests with Accept header?

21.4.7 406 Not Acceptable

   The resource identified by the request is only capable of generating
   response entities that have content characteristics not acceptable
   according to the Accept header field sent in the request.

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



From mailnull@www1.ietf.org  Thu Oct 24 08:04:48 2002
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 IAA03283
	for <sip-archive@odin.ietf.org>; Thu, 24 Oct 2002 08:04:48 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9OC6cv10947
	for sip-archive@odin.ietf.org; Thu, 24 Oct 2002 08:06:38 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OC6Cv10929;
	Thu, 24 Oct 2002 08:06:12 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OC5Bv10890
	for <sip@optimus.ietf.org>; Thu, 24 Oct 2002 08:05:11 -0400
Received: from fthsmtp01.cbsinc.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03257
	for <sip@ietf.org>; Thu, 24 Oct 2002 08:02:51 -0400 (EDT)
Received: by fthsmtp01 with Internet Mail Service (5.5.2653.19)
	id <VPQA8AX4>; Thu, 24 Oct 2002 08:03:20 -0400
Message-ID: <B51554B08F5AC243A26D66BD6E07614328E5F9@chn-ex01.cvns.corp.covansys.com>
From: KANUMURI Sreeram <SKanumur@covansys.com>
To: sip@ietf.org
Cc: "'Ranjit Kumar Avasarala'" <ranjit.avasarala@bplmail.com>
Date: Thu, 24 Oct 2002 08:05:01 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Subject: [Sip] Any  sipproxy avilable for testing
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

Hi all,
   

I am looking for a SIP-Proxyserver for testing my SIP-UA.

so can any one tell me where i can get a SIP proxy with CALLFORWARDNOANSWER
feature in the proxy for testing of my sipUA.

if it is a executable is also  sufficient for me.

TIA

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



From mailnull@www1.ietf.org  Thu Oct 24 08:22:05 2002
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 IAA03777
	for <sip-archive@odin.ietf.org>; Thu, 24 Oct 2002 08:22:04 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9OCNsL12206
	for sip-archive@odin.ietf.org; Thu, 24 Oct 2002 08:23:54 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OCNHv12185;
	Thu, 24 Oct 2002 08:23:17 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OCM2v12149
	for <sip@optimus.ietf.org>; Thu, 24 Oct 2002 08:22:02 -0400
Received: from fthsmtp01.cbsinc.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03718
	for <sip@ietf.org>; Thu, 24 Oct 2002 08:19:42 -0400 (EDT)
Received: by fthsmtp01 with Internet Mail Service (5.5.2653.19)
	id <VPQA8BPR>; Thu, 24 Oct 2002 08:20:12 -0400
Message-ID: <B51554B08F5AC243A26D66BD6E076143285CD3@chn-ex01.cvns.corp.covansys.com>
From: KANUMURI Sreeram <SKanumur@covansys.com>
To: "'Alexeitsev, D'" <D.Alexeitsev@telekom.de>, sip@ietf.org,
        "'ranjit.avasarala@bplmail.com'" <ranjit.avasarala@bplmail.com>
Subject: RE: [Sip] 406 Not Acceptable
Date: Thu, 24 Oct 2002 08:20:00 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

Hi all,
   

I am looking for a SIP-Proxyserver for testing my SIP-UA.

so can any one tell me where i can get a SIP proxy with CALLFORWARDNOANSWER
feature in the proxy for testing of my sipUA.

if it is a executable is also  sufficient for me.

TIA

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



From mailnull@www1.ietf.org  Thu Oct 24 08:26:08 2002
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 IAA03931
	for <sip-archive@odin.ietf.org>; Thu, 24 Oct 2002 08:26:08 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9OCRwQ12379
	for sip-archive@odin.ietf.org; Thu, 24 Oct 2002 08:27:58 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OCR7v12349;
	Thu, 24 Oct 2002 08:27:07 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OCPxv12300
	for <sip@optimus.ietf.org>; Thu, 24 Oct 2002 08:25:59 -0400
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 IAA03855
	for <sip@ietf.org>; Thu, 24 Oct 2002 08:23:38 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9OCPlQ1027466;
	Thu, 24 Oct 2002 14:25:47 +0200 (MEST)
Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.51])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g9OCPlG3011648;
	Thu, 24 Oct 2002 15:25:47 +0300 (EET DST)
Message-ID: <3DB7E6C9.173F1118@lmf.ericsson.se>
Date: Thu, 24 Oct 2002 15:25:45 +0300
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: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: Jiri Kuthan <jiri.kuthan@fokus.fraunhofer.de>,
        Igor Slepchin <ISlepchin@dynamicsoft.com>,
        "'Jiri Kuthan'" <jiri.kuthan@fokus.gmd.de>,
        "'Jiri Kuthan'" <jiri@iptel.org>, Medhavi Bhatia <mbhatia@nextone.com>,
        James Undery <jundery@ubiquity.net>, "SIP (E-mail)" <sip@ietf.org>,
        Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: Re: [Sip] Retransmission of INVITEs
References: <5.1.0.14.0.20021004221532.03e50f20@mailhost.fokus.gmd.de> <3DA3C2DE.60404@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Jonathan,

> I wonder what is the
> issue with TCP keepalives that make them infrequently used?

As Henning pointed out, they are seldom turned on. The problem is that
TCP keep-alives can terminate an alright TCP connection when there are
transient network failures.

For example, if we are playing a chess game over TCP, our TCP connection
may be open during days. If at the moment your TCP stack is sending me a
TCP keep alive my access router has crashed, we will lose the connection
because your TCP stack will time out and release it. However, 5 minutes
later my access router is OK again, and we could have gone on playing
for days...

Note, however, that TCP keep-alive time outs are in the order or hours
(two hours is a common value). SIP timeouts at establishment time are
much smaller.

Folks against TCP keepalives usually claim that this type of keepalive
mechanism belongs to the application layer rather than to the tranport
layer.

Regards,

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



From mailnull@www1.ietf.org  Thu Oct 24 08:47:30 2002
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 IAA04671
	for <sip-archive@odin.ietf.org>; Thu, 24 Oct 2002 08:47:30 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9OCnKI13706
	for sip-archive@odin.ietf.org; Thu, 24 Oct 2002 08:49:20 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OCmQv13653;
	Thu, 24 Oct 2002 08:48:26 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OCkuv13526
	for <sip@optimus.ietf.org>; Thu, 24 Oct 2002 08:46:56 -0400
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 IAA04514
	for <sip@ietf.org>; Thu, 24 Oct 2002 08:44:33 -0400 (EDT)
From: subbac@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 g9OCUNi04489
	for <sip@ietf.org>; Thu, 24 Oct 2002 18:00:23 +0530
Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 65256C5C.00461860 ; Thu, 24 Oct 2002 18:15:37 +0530
X-Lotus-FromDomain: HSSBLR
To: sip@ietf.org
cc: subbac@hss.hns.com
Message-ID: <65256C5C.004617B1.00@sampark.hss.hns.com>
Date: Thu, 24 Oct 2002 18:15:35 +0530
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: [Sip] Info regarding Preloaded Route Set
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>




Hi,

I have a doubt in using Pre-Loaded Route Set at UA end.

Let us say UA1 has a Pre-Loaded Route Set of  PR1, PR2, PR3.  (all routers
are strict routers)

UA1 initiates a call to UA2.

The INVITE looks like
          INVITE: PR1
          Route:    PR2, PR3, UA2

Now PR1 doesn't Record-Route.
          UA2 sends the RPR (182) response to UA1

          with Record-Route as   PR3, PR2


On receiving the Record-Route set,  UA1 updates its local Route-Set.
Now its Route Set contains  PR2, PR3 only.  Hence successive requests
directly reaches PR2.

Now if UA1 want to terminate the call by sending CANCEL,

     As per the latest Route Set present at UA1,  CANCEL should go to PR2
directly.
     It looks like
          CANCEL:  PR2
          Route:    PR3, UA2contact

This scenario leads to two questions:

     1   Is it valid to update the local Route Set at UA1 on receiving the
Record-Route header in RPR (not final response)
          and use it for subsequent Requests related to Dialog.

     2.  If YES: where should CANCEL go.   As per RFC 3261, CANCEL should
look like its original INVITE.
          But in this case, both Request URI and Route header got modified.
Is it valid??


         If No:  Before receiving the final response, if UA1 wants send
UPDATE to modify session parameters what Route-Set
          need to be used (i.e. Initial Route-Set or Route-Set received in
RPR).


provide your valuable inputs.


regards
CSR








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.


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



From mailnull@www1.ietf.org  Thu Oct 24 09:38:40 2002
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 JAA07255
	for <sip-archive@odin.ietf.org>; Thu, 24 Oct 2002 09:38:39 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9ODeSB17378
	for sip-archive@odin.ietf.org; Thu, 24 Oct 2002 09:40:28 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ODdJv17271;
	Thu, 24 Oct 2002 09:39:19 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ODZrv16580
	for <sip@optimus.ietf.org>; Thu, 24 Oct 2002 09:35:53 -0400
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 JAA06915
	for <sip@ietf.org>; Thu, 24 Oct 2002 09:33:33 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9ODZkKV003989;
	Thu, 24 Oct 2002 15:35:46 +0200 (MEST)
Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.112])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g9ODZkG3015696;
	Thu, 24 Oct 2002 16:35:46 +0300 (EET DST)
Message-ID: <3DB7F72E.97C512A7@lmf.ericsson.se>
Date: Thu, 24 Oct 2002 16:35:42 +0300
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: subbac@hss.hns.com
CC: sip@ietf.org
Subject: Re: [Sip] Info regarding Preloaded Route Set
References: <65256C5C.004617B1.00@sampark.hss.hns.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit


Hi,

> I have a doubt in using Pre-Loaded Route Set at UA end.
>
> Let us say UA1 has a Pre-Loaded Route Set of  PR1, PR2, PR3.  (all routers
> are strict routers)
>
> UA1 initiates a call to UA2.
>
> The INVITE looks like
>           INVITE: PR1
>           Route:    PR2, PR3, UA2
>
> Now PR1 doesn't Record-Route.
>           UA2 sends the RPR (182) response to UA1
>
>           with Record-Route as   PR3, PR2
>
> On receiving the Record-Route set,  UA1 updates its local Route-Set.
> Now its Route Set contains  PR2, PR3 only.  Hence successive requests
> directly reaches PR2.
>
> Now if UA1 want to terminate the call by sending CANCEL,
>
>      As per the latest Route Set present at UA1,  CANCEL should go to PR2
> directly.
>      It looks like
>           CANCEL:  PR2
>           Route:    PR3, UA2contact

[CHH] I don't think so. The CANCEL shall be routed like the INVITE.

> This scenario leads to two questions:
>
>      1   Is it valid to update the local Route Set at UA1 on receiving the
> Record-Route header in RPR (not final response)
>           and use it for subsequent Requests related to Dialog.

[CHH] Yes. You may need it for requests (PRACK, UPDATE, INFO...) before you
have received the final response for the INVITE.

>      2.  If YES: where should CANCEL go.   As per RFC 3261, CANCEL should
> look like its original INVITE.
>           But in this case, both Request URI and Route header got modified.
> Is it valid??

[CHH] The CANCEL goes wherever the INVITE went, using the same route.

Regards,

Christer Holmberg
Ericsson Finland


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



From mailnull@www1.ietf.org  Thu Oct 24 09:47:05 2002
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 JAA07881
	for <sip-archive@odin.ietf.org>; Thu, 24 Oct 2002 09:47:05 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9ODmsr17772
	for sip-archive@odin.ietf.org; Thu, 24 Oct 2002 09:48:54 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ODmYv17759;
	Thu, 24 Oct 2002 09:48:34 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ODlqv17677
	for <sip@optimus.ietf.org>; Thu, 24 Oct 2002 09:47:52 -0400
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 JAA07697
	for <sip@ietf.org>; Thu, 24 Oct 2002 09:45:32 -0400 (EDT)
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 g9ODlil29497;
	Thu, 24 Oct 2002 09:47:45 -0400 (EDT)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <TLKC2WVW>; Thu, 24 Oct 2002 09:47:45 -0400
Message-ID: <4D79C746863DD51197690002A52CDA000400DE1C@zcard0kc.ca.nortel.com>
From: "Tom-PT Taylor" <taylor@nortelnetworks.com>
To: "'Alexeitsev, D'" <D.Alexeitsev@telekom.de>, sip@ietf.org
Subject: RE: [Sip] 406 Not Acceptable
Date: Thu, 24 Oct 2002 09:47:44 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

An "entity" in this context is the body of the SIP message.

Note that in the absence of an Accept header field the assumption is that
"Accept: application/sdp" is present.

Given that this is a 4xx-series error, it is saying that the UAC has caused
a problem by saying that the only body types it can accept are types the UAS
cannot generate.  I have a hard time imagining an applicable case with SIP
-- likely the request would fail on some other ground anyway.  The header
field and the error both come from HTTP: see RFC 2616 section 14.1.

> -----Original Message-----
> From: Alexeitsev, D [mailto:D.Alexeitsev@telekom.de] 
> Sent: Thursday, October 24, 2002 7:43 AM
> To: sip@ietf.org
> Subject: [Sip] 406 Not Acceptable
> 
> 
> Hello All,
> 
> Could someone clarify what this paragraph is trying to say 
> and what are the "response entities"? Is this response only 
> possible to the requests with Accept header?
> 
> 21.4.7 406 Not Acceptable
> 
>    The resource identified by the request is only capable of 
> generating
>    response entities that have content characteristics not acceptable
>    according to the Accept header field sent in the request.
> 
> Greetings,
> Denis Alexeitsev _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current 
> sip Use sipping@ietf.org for new developments on the 
> application of sip
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Thu Oct 24 11:06:11 2002
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 LAA10894
	for <sip-archive@odin.ietf.org>; Thu, 24 Oct 2002 11:06:11 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9OF81822970
	for sip-archive@odin.ietf.org; Thu, 24 Oct 2002 11:08:01 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OF72v22417;
	Thu, 24 Oct 2002 11:07:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OF5bv22321
	for <sip@optimus.ietf.org>; Thu, 24 Oct 2002 11:05:37 -0400
Received: from gw-nl4.philips.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10801
	for <sip@ietf.org>; Thu, 24 Oct 2002 11:03:12 -0400 (EDT)
From: frank.derks@philips.com
Received: from smtpscan-nl1.philips.com (smtpscan-nl1.philips.com [130.139.36.21])
	by gw-nl4.philips.com (Postfix) with ESMTP id 53A20465F4
	for <sip@ietf.org>; Thu, 24 Oct 2002 17:05:27 +0200 (MET DST)
Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) 
	by smtpscan-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id RAA27724
	for <sip@ietf.org>; Thu, 24 Oct 2002 17:05:27 +0200 (MET DST)
Received: from ehv001soh.diamond.philips.com (e2soh01.diamond.philips.com [130.139.52.13]) 
	by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id RAA06554
	for <sip@ietf.org>; Thu, 24 Oct 2002 17:05:26 +0200 (MET DST)
To: sip@ietf.org
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF7EDB2718.2A3B592B-ONC1256C5C.004FA259@diamond.philips.com>
Date: Thu, 24 Oct 2002 17:03:44 +0200
X-MIMETrack: Serialize by Router on ehv001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at
 24/10/2002 17:03:50,
	Serialize complete at 24/10/2002 17:03:50
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [Sip] Questions on the draft on the Replaces header
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

The Replaces header draft 
(http://www.ietf.org/internet-drafts/draft-ietf-sip-replaces-02.txt),
states that this header is only defined for INVITE requests (section 6.1). 
The Overview
section (section 2), however, states that it is frequently used in 
combination with the 
REFER method as used in call transfer. Although the latter does not imply 
that a Replaces
header could be used in a REFER request, it does seem to hint in that 
direction.

Especially in the case of call transfer, it would be useful if it were 
allowed to use the
Replaces header in a REFER request. The reasoning behind this is the 
following. 

Receiving a REFER request, is a request to _also_ contact the destination 
contained in the
Refer-To header. It has no implications for the Dialog (or the Session) on 
which the REFER
was sent. This means that it is up to the recipient of the REFER request, 
to decide on the 
action(s) it is going to take after having contacted the indicated 
destination. I.e. it is
neither explicitely, nor implicitely conveyed that a transfer should take 
place. If this
does take place, this is up to the endpoint that received the REFER 
request. This is 
outside the control of the endpoint that sent the REFER request.

If it were allowed to use the Replaces header in a REFER request, it would 
become possible
to explicitely effect a transfer. Assuming that the endpoint sending the 
REFER request has
a Session with both parties that it wishes to transfer the call to, such a 
REFER would be
used as follows. The REFER request will contain a Refer-To header to 
indicate the endpoint
to which the Session should be transferred. I.e. the endpoint that should 
be contacted by
the recipient of the REFER request. The Replaces header contains details 
about the Session
that the sender of the REFER request has with the party to which that 
Session should be
transferred. The recipient of the REFER copies this header into the INVITE 
request that
it sends to establish the transfer call. The latter is, what I believe, 
described in the
current Replaces draft.

Any opinions on this?


Regards,

Frank

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



From mailnull@www1.ietf.org  Thu Oct 24 11:28:18 2002
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 LAA12289
	for <sip-archive@odin.ietf.org>; Thu, 24 Oct 2002 11:28:18 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9OFU8x24318
	for sip-archive@odin.ietf.org; Thu, 24 Oct 2002 11:30:08 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OFTkv24238;
	Thu, 24 Oct 2002 11:29:46 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OFSOv24105
	for <sip@optimus.ietf.org>; Thu, 24 Oct 2002 11:28:24 -0400
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 LAA12181
	for <sip@ietf.org>; Thu, 24 Oct 2002 11:26:02 -0400 (EDT)
Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39])
	by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g9OFSIv29052;
	Thu, 24 Oct 2002 11:28:18 -0400 (EDT)
Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id KAA26638; Thu, 24 Oct 2002 10:28:16 -0500 (CDT)
Message-ID: <3DB8114C.8050402@lucent.com>
Date: Thu, 24 Oct 2002 10:27:08 -0500
From: "Vijay K. Gurbani" <vkg@lucent.com>
Organization: Lucent Technologies, Inc./Bell Laboratories
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: Rohan Mahy <rohan@cisco.com>
CC: sip@ietf.org
Subject: Re: [Sip] moving UDP support out of the core SIP document
References: <8E416B94-E6B1-11D6-A132-0003938AF740@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Rohan Mahy wrote:
> Hello Everyone,
> 
> I wanted to share some thoughts that I had about removing UDP from the 
> core SIP document when we go to draft standard. 
[...]
> Obviously UDP is still very attractive in wireless networks (due to RTT 
> issues) and in other typically private networks with well-understood 
> delay and loss characteristics. To make most implementations simpler 
> however, I am proposing that we make unreliable transports (UDP and 
> DCCP) of SIP optional in User Agents, and that we put the UDP-specific 
> mechanism (ex: much of the complication of the transaction layer for 
> handling retransmissions) in a separate Draft Standard document.  

Making UDP optional is fine, but I think it should stay in the core
SIP specification.  Over the years, the SIP state machines for
INVITE and non-INVITE transactions have evolved keeping multiple
transports in mind.  The sourrounding text and the FSM figures
(Figure 5, 6, 7, and 8 in rfc3261) at this point in time are well
specified and, I beleive, well understood by the SIP community in
general.

Divorcing UDP transport from the core spec to another RFC raises other
questions:

   1/ Since proxies are optional in SIP and a UA can initiate
      a session directly with its peer, will a UDP-only UA
      insert a "Require: udp" in the request?

   2/ Issues such as reassembly, UDP response growing
      larger than the request, etc. still remain.

If it is a choice between deprecating UDP entirely or moving it to
another RFC, I would choose the latter.  But so long as we tacitly
support UDP, it would be nice to have it in the base document (maybe
degrade it to a MAY instead of a SHOULD).

Regards,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216

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



From mailnull@www1.ietf.org  Thu Oct 24 18:14:16 2002
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 SAA25553
	for <sip-archive@odin.ietf.org>; Thu, 24 Oct 2002 18:14:16 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9OMGAr15442
	for sip-archive@odin.ietf.org; Thu, 24 Oct 2002 18:16:10 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OMFfv15432;
	Thu, 24 Oct 2002 18:15:41 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OMDvv15385
	for <sip@optimus.ietf.org>; Thu, 24 Oct 2002 18:13:57 -0400
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 SAA25517
	for <sip@ietf.org>; Thu, 24 Oct 2002 18:11:32 -0400 (EDT)
Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44])
	by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9OMDkxF006385;
	Thu, 24 Oct 2002 15:13:46 -0700 (PDT)
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 ABE85979;
	Thu, 24 Oct 2002 15:11:23 -0700 (PDT)
Date: Thu, 24 Oct 2002 15:14:17 -0700
Subject: Re: [Sip] Questions on the draft on the Replaces header
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v546)
Cc: sip@ietf.org
To: frank.derks@philips.com
From: Rohan Mahy <rohan@cisco.com>
In-Reply-To: <OF7EDB2718.2A3B592B-ONC1256C5C.004FA259@diamond.philips.com>
Message-Id: <EFAF206A-E79D-11D6-A34B-0003938AF740@cisco.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.546)
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi,

If I understand your message correctly, I believe you are trying to add 
additional semantics to Replaces which are not necessary to accomplish 
what I believe you want to achieve.

If A has an existing session with C using a call-id of foo, I think you 
are asking for A to send a REFER that causes B to send an INVITE to C, 
such that the INVITE contains a Replaces header.  This would cause a 
new session from B to C to replace the old session from A to C.

To do this A sends a REFER with the following Refer-To header:

REFER sip:B SIP/2.0
Refer-To: <sip:C?Replaces=foo>

This causes B to generate an INVITE of the following form:

INVITE sip:C SIP/2.0
Replaces: foo

Headers in the REFER request are orthogonal to headers in the triggered 
request.  Headers  intended for inclusion in the triggered request are 
included in the Refer-To URI.

I hope this answers your question.

thanks,
-rohan


On Thursday, October 24, 2002, at 08:03 AM, frank.derks@philips.com 
wrote:

> The Replaces header draft
> (http://www.ietf.org/internet-drafts/draft-ietf-sip-replaces-02.txt),
> states that this header is only defined for INVITE requests (section 
> 6.1).
> The Overview
> section (section 2), however, states that it is frequently used in
> combination with the
> REFER method as used in call transfer. Although the latter does not 
> imply
> that a Replaces
> header could be used in a REFER request, it does seem to hint in that
> direction.
>
> Especially in the case of call transfer, it would be useful if it were
> allowed to use the
> Replaces header in a REFER request. The reasoning behind this is the
> following.
>
> Receiving a REFER request, is a request to _also_ contact the 
> destination
> contained in the
> Refer-To header. It has no implications for the Dialog (or the 
> Session) on
> which the REFER
> was sent. This means that it is up to the recipient of the REFER 
> request,
> to decide on the
> action(s) it is going to take after having contacted the indicated
> destination. I.e. it is
> neither explicitely, nor implicitely conveyed that a transfer should 
> take
> place. If this
> does take place, this is up to the endpoint that received the REFER
> request. This is
> outside the control of the endpoint that sent the REFER request.
>
> If it were allowed to use the Replaces header in a REFER request, it 
> would
> become possible
> to explicitely effect a transfer. Assuming that the endpoint sending 
> the
> REFER request has
> a Session with both parties that it wishes to transfer the call to, 
> such a
> REFER would be
> used as follows. The REFER request will contain a Refer-To header to
> indicate the endpoint
> to which the Session should be transferred. I.e. the endpoint that 
> should
> be contacted by
> the recipient of the REFER request. The Replaces header contains 
> details
> about the Session
> that the sender of the REFER request has with the party to which that
> Session should be
> transferred. The recipient of the REFER copies this header into the 
> INVITE
> request that
> it sends to establish the transfer call. The latter is, what I believe,
> described in the
> current Replaces draft.
>
> Any opinions on this?
>
>
> Regards,
>
> Frank
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip

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



From mailnull@www1.ietf.org  Fri Oct 25 00:24:24 2002
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 AAA02813
	for <sip-archive@odin.ietf.org>; Fri, 25 Oct 2002 00:24:24 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9P4QLc32191
	for sip-archive@odin.ietf.org; Fri, 25 Oct 2002 00:26:21 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9P4Prv32162;
	Fri, 25 Oct 2002 00:25:53 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9P4OGv32112
	for <sip@optimus.ietf.org>; Fri, 25 Oct 2002 00:24:16 -0400
Received: from em.njupt.edu.cn (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA02616
	for <sip@ietf.org>; Fri, 25 Oct 2002 00:21:43 -0400 (EDT)
Message-Id: <200210250421.AAA02616@ietf.org>
Received: (qmail 13421 invoked from network); 25 Oct 2002 04:48:05 -0000
Received: from unknown (HELO toto) (10.10.3.123)
  by em.njupt.edu.cn with SMTP; 25 Oct 2002 04:48:05 -0000
Date: Fri, 25 Oct 2002 12:29:39 +0800
From: feng zhang <y01317@njupt.edu.cn>
Reply-To: y01317@njupt.edu.cn
To: Dean Willis <dwillis@dynamicsoft.com>, "sip@ietf.org" <sip@ietf.org>
Subject: Re:[Sip] Record-Route, Path, Service Route, and Multi-Homed Proxies
Organization: NUPT-CED202
X-mailer: FoxMail 4.0 beta 2 [cn]
Mime-Version: 1.0
Content-Type: text/plain;
      charset="GB2312"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id g9P4OGv32113
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit

Hi Dean,

>This odd thing has two serious implications:
>
>1) UA2 cannot sign the route set, because it gets edited by P in the
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>response. Consequently, end-to-end protection of the route set can not
~~~~~~~~~~ I can not understand this point. If UA2 writes Route:192.168.2.1 in
           BYE to UA1, the P will not change the Route header, the P only
           strip this Route header in BYE, and passes it to UA1, NO route
           set is changed. I dont know why UA2 cannot sign the route set?
           u say P will edit the route set in response, and can u give me 
           an example? As I think , UA1 send 200 OK to UA2's BYE , the message
           200 OK has no Route header, what can P edit this response ?
           I am really confused. Thanks u very much!

>be supported by the protocol. We've just broken the openness principle
>and the end-to-end principle. Oops.
>
>2) P must implement special "multihomed" logic. On the request phase, it
>goes through output interface calculation and writes the output
>interface into the route. It must then inspect all responses, grep for
>an input interface, and selectively edit them to reference the correct
>output interface. This is a CPU drag. 
>

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



From mailnull@www1.ietf.org  Fri Oct 25 03:15:27 2002
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 DAA14653
	for <sip-archive@odin.ietf.org>; Fri, 25 Oct 2002 03:15:27 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9P7HQU15745
	for sip-archive@odin.ietf.org; Fri, 25 Oct 2002 03:17:26 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9P7GKv15627;
	Fri, 25 Oct 2002 03:16:20 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9P7E3v15543
	for <sip@optimus.ietf.org>; Fri, 25 Oct 2002 03:14:03 -0400
Received: from gw-nl6.philips.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14503;
	Fri, 25 Oct 2002 03:11:32 -0400 (EDT)
From: frank.derks@philips.com
Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23])
	by gw-nl6.philips.com (Postfix) with ESMTP
	id AA2D1A0A86; Fri, 25 Oct 2002 09:13:49 +0200 (MET DST)
Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) 
	by smtpscan-nl3.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id JAA12377; Fri, 25 Oct 2002 09:13:48 +0200 (MET DST)
Received: from ehv001soh.diamond.philips.com (e2soh01.diamond.philips.com [130.139.52.13]) 
	by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id JAA11225; Fri, 25 Oct 2002 09:13:47 +0200 (MET DST)
To: Rohan Mahy <rohan@cisco.com>
Cc: sip@ietf.org, sip-admin@ietf.org
Subject: Re: [Sip] Questions on the draft on the Replaces header
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF4B4C5ED9.AB28593E-ONC1256C5D.00251C8D@diamond.philips.com>
Date: Fri, 25 Oct 2002 09:12:09 +0200
X-MIMETrack: Serialize by Router on ehv001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at
 25/10/2002 09:12:11,
	Serialize complete at 25/10/2002 09:12:11
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

Rohan,

I understand that REFER, which includes the Refer-To header, is sufficient
to get B to establish a session with C. If I understand the REFER draft 
correctly, this has no impact on the session between A and B Therefore, at 

some point in time, B will have two sessions: on with A, and one with B.

I think that this leads to a situation in which it is not clear what B 
will 
do:

- will it mix the media from the two sessions?
- to which of the two sessions will it listen?
- to which of the two sessions will it talk?

The latter two can be influenced by A by modifying the session (e.g. put 
it
on hold). 

If it is A's intention to effect a transfer, it could do this implicitely 
by 
terminating its session with B. However, B then only has implicit 
knowledge 
(the fact that its session with A was terminated) that A probably intended 

to transfer its session with B to C.

The reason for adding the Replaces header to the REFER would be to make it
_explicit_ for B to replace its session with A by a session with C.

I realise that this somewhat changes the semantics of the Replaces header 
in 
the current proposal, but probably not by much. The current draft 
describes 
the use of the Replaces header in combination with an INVITE request only. 

Adding additional semantics for its use in combination with a REFER 
request 
would not seem to present a major impact. In particular, if the semantics
of the Replaces header are "replace the dialog/session on which this 
header
is received with the dialog/session specified in the Replaces header", 
both
situations would seem to be covered.

Regards,

Frank







Rohan Mahy <rohan@cisco.com>
Sent by: sip-admin@ietf.org
2002-10-25 00:14

 
        To:     Frank Derks/HVS/BE/PHILIPS@EMEA2
        cc:     sip@ietf.org
        Subject:        Re: [Sip] Questions on the draft on the Replaces header
        Classification: 



Hi,

If I understand your message correctly, I believe you are trying to add 
additional semantics to Replaces which are not necessary to accomplish 
what I believe you want to achieve.

If A has an existing session with C using a call-id of foo, I think you 
are asking for A to send a REFER that causes B to send an INVITE to C, 
such that the INVITE contains a Replaces header.  This would cause a 
new session from B to C to replace the old session from A to C.

To do this A sends a REFER with the following Refer-To header:

REFER sip:B SIP/2.0
Refer-To: <sip:C?Replaces=foo>

This causes B to generate an INVITE of the following form:

INVITE sip:C SIP/2.0
Replaces: foo

Headers in the REFER request are orthogonal to headers in the triggered 
request.  Headers  intended for inclusion in the triggered request are 
included in the Refer-To URI.

I hope this answers your question.

thanks,
-rohan


On Thursday, October 24, 2002, at 08:03 AM, frank.derks@philips.com 
wrote:

> The Replaces header draft
> (http://www.ietf.org/internet-drafts/draft-ietf-sip-replaces-02.txt),
> states that this header is only defined for INVITE requests (section 
> 6.1).
> The Overview
> section (section 2), however, states that it is frequently used in
> combination with the
> REFER method as used in call transfer. Although the latter does not 
> imply
> that a Replaces
> header could be used in a REFER request, it does seem to hint in that
> direction.
>
> Especially in the case of call transfer, it would be useful if it were
> allowed to use the
> Replaces header in a REFER request. The reasoning behind this is the
> following.
>
> Receiving a REFER request, is a request to _also_ contact the 
> destination
> contained in the
> Refer-To header. It has no implications for the Dialog (or the 
> Session) on
> which the REFER
> was sent. This means that it is up to the recipient of the REFER 
> request,
> to decide on the
> action(s) it is going to take after having contacted the indicated
> destination. I.e. it is
> neither explicitely, nor implicitely conveyed that a transfer should 
> take
> place. If this
> does take place, this is up to the endpoint that received the REFER
> request. This is
> outside the control of the endpoint that sent the REFER request.
>
> If it were allowed to use the Replaces header in a REFER request, it 
> would
> become possible
> to explicitely effect a transfer. Assuming that the endpoint sending 
> the
> REFER request has
> a Session with both parties that it wishes to transfer the call to, 
> such a
> REFER would be
> used as follows. The REFER request will contain a Refer-To header to
> indicate the endpoint
> to which the Session should be transferred. I.e. the endpoint that 
> should
> be contacted by
> the recipient of the REFER request. The Replaces header contains 
> details
> about the Session
> that the sender of the REFER request has with the party to which that
> Session should be
> transferred. The recipient of the REFER copies this header into the 
> INVITE
> request that
> it sends to establish the transfer call. The latter is, what I believe,
> described in the
> current Replaces draft.
>
> Any opinions on this?
>
>
> Regards,
>
> Frank
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip

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



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



From mailnull@www1.ietf.org  Fri Oct 25 03:36:21 2002
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 DAA14890
	for <sip-archive@odin.ietf.org>; Fri, 25 Oct 2002 03:36:21 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9P7cKx17044
	for sip-archive@odin.ietf.org; Fri, 25 Oct 2002 03:38:20 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9P7bev16950;
	Fri, 25 Oct 2002 03:37:40 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9P7aPv16439
	for <sip@optimus.ietf.org>; Fri, 25 Oct 2002 03:36:25 -0400
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 DAA14862
	for <sip@ietf.org>; Fri, 25 Oct 2002 03:33:54 -0400 (EDT)
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 g9P7Zpw09462
	for <sip@ietf.org>; Fri, 25 Oct 2002 10:35:51 +0300 (EET DST)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5e278857d5ac158f21084@esvir01nok.ntc.nokia.com>;
 Fri, 25 Oct 2002 10:36:12 +0300
Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Fri, 25 Oct 2002 10:36:12 +0300
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Fri, 25 Oct 2002 10:36:11 +0300
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: [Sip] moving UDP support out of the core SIP document
Date: Fri, 25 Oct 2002 10:36:11 +0300
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE6F2F@esebe019.ntc.nokia.com>
Thread-Topic: [Sip] moving UDP support out of the core SIP document
Thread-Index: AcJ7cr0fqHV8rU2gQLemg1DQy+PSSwAhatCA
To: <vkg@lucent.com>, <rohan@cisco.com>
Cc: <sip@ietf.org>
X-OriginalArrivalTime: 25 Oct 2002 07:36:11.0979 (UTC) FILETIME=[310CC9B0:01C27BF9]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9P7aQv16440
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit

Moving UDP to another document, downgrading it to a MAY in the SIP base document or whatever will not achieve anything, IMO. UA implementations will still have it (its easier to start with UDP when implementing SIP). Proxies MUST still support it.

We either deprecate it from the spec or leave it as is.

Regards,
Hisham

> -----Original Message-----
> From: ext Vijay K. Gurbani [mailto:vkg@lucent.com]
> Sent: Thursday, October 24, 2002 6:27 PM
> To: Rohan Mahy
> Cc: sip@ietf.org
> Subject: Re: [Sip] moving UDP support out of the core SIP document
> 
> 
> Rohan Mahy wrote:
> > Hello Everyone,
> > 
> > I wanted to share some thoughts that I had about removing 
> UDP from the 
> > core SIP document when we go to draft standard. 
> [...]
> > Obviously UDP is still very attractive in wireless networks 
> (due to RTT 
> > issues) and in other typically private networks with 
> well-understood 
> > delay and loss characteristics. To make most 
> implementations simpler 
> > however, I am proposing that we make unreliable transports (UDP and 
> > DCCP) of SIP optional in User Agents, and that we put the 
> UDP-specific 
> > mechanism (ex: much of the complication of the transaction 
> layer for 
> > handling retransmissions) in a separate Draft Standard document.  
> 
> Making UDP optional is fine, but I think it should stay in the core
> SIP specification.  Over the years, the SIP state machines for
> INVITE and non-INVITE transactions have evolved keeping multiple
> transports in mind.  The sourrounding text and the FSM figures
> (Figure 5, 6, 7, and 8 in rfc3261) at this point in time are well
> specified and, I beleive, well understood by the SIP community in
> general.
> 
> Divorcing UDP transport from the core spec to another RFC raises other
> questions:
> 
>    1/ Since proxies are optional in SIP and a UA can initiate
>       a session directly with its peer, will a UDP-only UA
>       insert a "Require: udp" in the request?
> 
>    2/ Issues such as reassembly, UDP response growing
>       larger than the request, etc. still remain.
> 
> If it is a choice between deprecating UDP entirely or moving it to
> another RFC, I would choose the latter.  But so long as we tacitly
> support UDP, it would be nice to have it in the base document (maybe
> degrade it to a MAY instead of a SHOULD).
> 
> Regards,
> 
> - vijay
> -- 
> Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
> Wireless Networks Group/Internet Software and Services
> Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
> Naperville, Illinois 60566     Voice: +1 630 224 0216
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Fri Oct 25 07:02:41 2002
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 HAA19070
	for <sip-archive@odin.ietf.org>; Fri, 25 Oct 2002 07:02:41 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9PB4U427841
	for sip-archive@odin.ietf.org; Fri, 25 Oct 2002 07:04:30 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PB40v27824;
	Fri, 25 Oct 2002 07:04:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PB2sv27792
	for <sip@optimus.ietf.org>; Fri, 25 Oct 2002 07:02:54 -0400
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 HAA19011
	for <sip@ietf.org>; Fri, 25 Oct 2002 07:00:29 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9PB2kKV009289;
	Fri, 25 Oct 2002 13:02:46 +0200 (MEST)
Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.51])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g9PB2kG3011763;
	Fri, 25 Oct 2002 14:02:46 +0300 (EET DST)
Message-ID: <3DB924D4.16CFCF57@lmf.ericsson.se>
Date: Fri, 25 Oct 2002 14:02:44 +0300
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: Robert Sparks <rsparks@dynamicsoft.com>, sip <sip@ietf.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] REFER and Reason
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hello,

It is probably too late for this comment, but just in case. Section
2.4.5 of the REFER spec says:

  "For
   example, if a client receives a REFER to a HTTP URL, and is
   successful in accessing the resource, its NOTIFY to the referrer can
   contain the message/sipfrag body of "SIP/2.0 200 OK".  If the
   notifier wishes to return additional non-SIP protocol specific
   information about the status of the request, it may place it in the
   body of the sipfrag message."

Additional non-SIP protocol information could be also returned in a
Reason header field. Something like:

Reason: HTTP ;cause=200 ;text="OK"

or

Reason: HTTP ;cause=404 ;text="Not Found"

This was one of the reasons why the protocol name space (HTTP is this
case) was introduced in the Reason header field. 


Regards,

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



From mailnull@www1.ietf.org  Fri Oct 25 07:36:08 2002
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 HAA20732
	for <sip-archive@odin.ietf.org>; Fri, 25 Oct 2002 07:36:08 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9PBbwM30330
	for sip-archive@odin.ietf.org; Fri, 25 Oct 2002 07:37:58 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PBbEv30014;
	Fri, 25 Oct 2002 07:37:14 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PBTuv29312
	for <sip@optimus.ietf.org>; Fri, 25 Oct 2002 07:29:57 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19827;
	Fri, 25 Oct 2002 07:27:36 -0400 (EDT)
Message-Id: <200210251127.HAA19827@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Fri, 25 Oct 2002 07:27:35 -0400
Subject: [Sip] I-D ACTION:draft-khartabil-sip-congestionsafe-ci-01.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

--NextPart

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


	Title		: Congestion safety and Content Indirection
	Author(s)	: H. Khartabil
	Filename	: draft-khartabil-sip-congestionsafe-ci-01.txt
	Pages		: 16
	Date		: 2002-10-24
	
The Session Initiation Protocol allows the use of UDP for transport 
of SIP messages. Baseline SIP does not allow congestion control for 
messages larger than MTU of a certain link nor does it allow end 
points to specify their maximum acceptable message size, regardless 
of the underlying transport protocol. 
This document combines two, namely congestion safely and Content-
Indirection Mechanism into the one document and presents scenarios 
where the 2 could be combined. It also introduces extensions to SIP 
that allows end points to specify their maximum acceptable message 
size.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-khartabil-sip-congestionsafe-ci-01.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-khartabil-sip-congestionsafe-ci-01.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-khartabil-sip-congestionsafe-ci-01.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:	<2002-10-24142052.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-khartabil-sip-congestionsafe-ci-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-khartabil-sip-congestionsafe-ci-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2002-10-24142052.I-D@ietf.org>

--OtherAccess--

--NextPart--


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



From mailnull@www1.ietf.org  Fri Oct 25 07:36:52 2002
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 HAA20785
	for <sip-archive@odin.ietf.org>; Fri, 25 Oct 2002 07:36:52 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9PBcgX30447
	for sip-archive@odin.ietf.org; Fri, 25 Oct 2002 07:38:42 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PBc7v30410;
	Fri, 25 Oct 2002 07:38:07 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PBUwv29435
	for <sip@optimus.ietf.org>; Fri, 25 Oct 2002 07:30:58 -0400
Received: from ipgen-india.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20118
	for <sip@ietf.org>; Fri, 25 Oct 2002 07:28:35 -0400 (EDT)
Received: from lakshmi [192.168.1.209]
	by ipgen-india.com [192.168.1.15]
	with SMTP (MDaemon.PRO.v5.0.7.T)
	for <sip@ietf.org>; Fri, 25 Oct 2002 17:00:09 +0530
Message-ID: <001601c27c7f$3d13e500$d101a8c0@lakshmi>
From: "lakshmi" <lakshmi@ipgen-india.com>
To: <sip@ietf.org>
Cc: "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>
Date: Sat, 26 Oct 2002 05:05:44 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0013_01C27CAD.569B4D00"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-MDRemoteIP: 192.168.1.209
X-Return-Path: lakshmi@ipgen-india.com
X-MDaemon-Deliver-To: sip@ietf.org
Subject: [Sip] Conflict in Accept header grammer
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0013_01C27CAD.569B4D00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

All,

Accept Header syntax is like this=20
accept-range =3D media-range *(SEMI accept-param)

media-range =3D ( "*/*"

   / ( m-type SLASH "*" )

   / ( m-type SLASH m-subtype )

   ) *( SEMI m-parameter )

accept-param =3D ("q" EQUAL qvalue) / generic-param

generic-param =3D token [ EQUAL gen-value ]

gen-value =3D token / host / quoted-string

m-parameter =3D m-attribute EQUAL m-value

m-attribute =3D token

m-value =3D token / quoted-string

Here how to distinguish b/w the m-parameter in media-range and =
generic-param in accept-param.



Thanks,

lakshmi




------=_NextPart_000_0013_01C27CAD.569B4D00
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.3103.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>All,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Accept Header syntax is like this =
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>
<P>accept-range =3D media-range *(SEMI accept-param)</P>
<P>media-range =3D ( "*/*"</P>
<P>&nbsp;&nbsp; / ( m-type SLASH "*" )</P>
<P>&nbsp;&nbsp; / ( m-type SLASH m-subtype )</P>
<P>&nbsp;&nbsp; ) *( SEMI m-parameter )</P><FONT face=3DArial><FONT =
size=3D2>
<P>accept-param =3D ("q" EQUAL qvalue) / generic-param</P><FONT =
size=3D2>
<P>generic-param =3D token [ EQUAL gen-value ]</P>
<P>gen-value =3D token / host / quoted-string</P></FONT><FONT size=3D2>
<P>m-parameter =3D m-attribute EQUAL m-value</P>
<P>m-attribute =3D token</P>
<P>m-value =3D token / quoted-string</P>
<P>Here how to&nbsp;distinguish b/w the m-parameter in media-range and=20
generic-param in accept-param.</P>
<P>&nbsp;</P>
<P>Thanks,</P>
<P>lakshmi</P>
<P>&nbsp;</P></FONT></FONT></FONT></FONT></DIV></BODY></HTML>

------=_NextPart_000_0013_01C27CAD.569B4D00--


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



From mailnull@www1.ietf.org  Fri Oct 25 07:52:14 2002
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 HAA21285
	for <sip-archive@odin.ietf.org>; Fri, 25 Oct 2002 07:52:13 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9PBs3P31015
	for sip-archive@odin.ietf.org; Fri, 25 Oct 2002 07:54:03 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PBrdv30993;
	Fri, 25 Oct 2002 07:53:39 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PBqLv30960
	for <sip@optimus.ietf.org>; Fri, 25 Oct 2002 07:52:21 -0400
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 HAA21236
	for <sip@ietf.org>; Fri, 25 Oct 2002 07:49:59 -0400 (EDT)
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 g9PBq0D16075;
	Fri, 25 Oct 2002 07:52:01 -0400 (EDT)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <TLKCJ276>; Fri, 25 Oct 2002 07:52:00 -0400
Message-ID: <4D79C746863DD51197690002A52CDA000400DE26@zcard0kc.ca.nortel.com>
From: "Tom-PT Taylor" <taylor@nortelnetworks.com>
To: "'lakshmi'" <lakshmi@ipgen-india.com>, sip@ietf.org
Cc: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Subject: RE: [Sip] Conflict in Accept header grammer
Date: Fri, 25 Oct 2002 07:51:57 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

Don't know if this helps, but m-parameters are attributes registered along
with the MIME type definitions, hence in theory can be known in advance once
the media types have been decoded.

-----Original Message-----
From: lakshmi [mailto:lakshmi@ipgen-india.com] 
Sent: Friday, October 25, 2002 7:36 PM
To: sip@ietf.org
Cc: Jonathan Rosenberg
Subject: [Sip] Conflict in Accept header grammer


All,

Accept Header syntax is like this 
accept-range = media-range *(SEMI accept-param)
media-range = ( "*/*"
   / ( m-type SLASH "*" )
   / ( m-type SLASH m-subtype )
   ) *( SEMI m-parameter )
accept-param = ("q" EQUAL qvalue) / generic-param
generic-param = token [ EQUAL gen-value ]
gen-value = token / host / quoted-string
m-parameter = m-attribute EQUAL m-value
m-attribute = token
m-value = token / quoted-string
Here how to distinguish b/w the m-parameter in media-range and generic-param
in accept-param.

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



From mailnull@www1.ietf.org  Fri Oct 25 08:05:07 2002
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 IAA21784
	for <sip-archive@odin.ietf.org>; Fri, 25 Oct 2002 08:05:06 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9PC6ug31634
	for sip-archive@odin.ietf.org; Fri, 25 Oct 2002 08:06:56 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PC5mv31594;
	Fri, 25 Oct 2002 08:05:48 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PC4Gv31543
	for <sip@optimus.ietf.org>; Fri, 25 Oct 2002 08:04:16 -0400
Received: from NREXCH.netrake.net (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21652
	for <sip@ietf.org>; Fri, 25 Oct 2002 08:01:55 -0400 (EDT)
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: [Sip] Conflict in Accept header grammer
Date: Fri, 25 Oct 2002 07:04:14 -0500
Message-ID: <7E06D3212981524CA10D2A114937C414093AE0@nrexch.netrake.net>
Thread-Topic: [Sip] Conflict in Accept header grammer
Thread-Index: AcJ8HaRfNOUB/LyfQ+KTJXIsadvt8AAADz/g
From: "Rob Phillips" <rob@netrake.com>
To: "Tom-PT Taylor" <taylor@nortelnetworks.com>,
        "lakshmi" <lakshmi@ipgen-india.com>, <sip@ietf.org>
Cc: "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9PC4Hv31546
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit

Correct - essentially, the parser *can't* generically tell the difference between a generic-param and m-parameter.  The handling of the generic-param or m-paramter is specific to the given media-range information.

- rob

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Friday, October 25, 2002 6:52 AM
To: 'lakshmi'; sip@ietf.org
Cc: Jonathan Rosenberg
Subject: RE: [Sip] Conflict in Accept header grammer


Don't know if this helps, but m-parameters are attributes registered along
with the MIME type definitions, hence in theory can be known in advance once
the media types have been decoded.

-----Original Message-----
From: lakshmi [mailto:lakshmi@ipgen-india.com] 
Sent: Friday, October 25, 2002 7:36 PM
To: sip@ietf.org
Cc: Jonathan Rosenberg
Subject: [Sip] Conflict in Accept header grammer


All,

Accept Header syntax is like this 
accept-range = media-range *(SEMI accept-param)
media-range = ( "*/*"
   / ( m-type SLASH "*" )
   / ( m-type SLASH m-subtype )
   ) *( SEMI m-parameter )
accept-param = ("q" EQUAL qvalue) / generic-param
generic-param = token [ EQUAL gen-value ]
gen-value = token / host / quoted-string
m-parameter = m-attribute EQUAL m-value
m-attribute = token
m-value = token / quoted-string
Here how to distinguish b/w the m-parameter in media-range and generic-param
in accept-param.

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



From mailnull@www1.ietf.org  Fri Oct 25 10:42:49 2002
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 KAA26739
	for <sip-archive@odin.ietf.org>; Fri, 25 Oct 2002 10:42:48 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9PEidf08588
	for sip-archive@odin.ietf.org; Fri, 25 Oct 2002 10:44:39 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PEhvv08560;
	Fri, 25 Oct 2002 10:43:57 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PEgWv08524
	for <sip@optimus.ietf.org>; Fri, 25 Oct 2002 10:42:32 -0400
Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26668
	for <sip@ietf.org>; Fri, 25 Oct 2002 10:40:11 -0400 (EDT)
Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP for sip@ietf.org; Fri, 25 Oct 2002 16:42:27 +0200
Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <VKARXHQ0>; Fri, 25 Oct 2002 16:42:27 +0200
Message-Id: <A89A213731F7D51196A0000347055C83E393BB@G9JNT.mgb01.telekom.de>
From: "Alexeitsev, D" <D.Alexeitsev@telekom.de>
To: sip@ietf.org
Subject: RE: [Sip] moving UDP support out of the core SIP document
Date: Fri, 25 Oct 2002 16:42:23 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

Hello All

Will then the unreliable responses became reliable?

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



From mailnull@www1.ietf.org  Fri Oct 25 10:52:30 2002
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 KAA27081
	for <sip-archive@odin.ietf.org>; Fri, 25 Oct 2002 10:52:30 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9PEsLc08997
	for sip-archive@odin.ietf.org; Fri, 25 Oct 2002 10:54:21 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PErOv08950;
	Fri, 25 Oct 2002 10:53:24 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PEpUv08827
	for <sip@optimus.ietf.org>; Fri, 25 Oct 2002 10:51:30 -0400
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 KAA26927
	for <sip@ietf.org>; Fri, 25 Oct 2002 10:49:09 -0400 (EDT)
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 g9PEpcqZ005957
	for <sip@ietf.org>; Fri, 25 Oct 2002 10:51:38 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAT53975;
	Fri, 25 Oct 2002 10:56:16 -0400 (EDT)
Message-ID: <3DB95A6C.8673D20F@cisco.com>
Date: Fri, 25 Oct 2002 10:51:24 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@ietf.org
References: <200210251127.HAA19827@ietf.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Re: draft-khartabil-sip-congestionsafe-ci-01.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

If you try to follow this proposal with a large INVITE, it rapidly breaks down when trying to use the CSS.

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



From mailnull@www1.ietf.org  Fri Oct 25 12:10:57 2002
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 MAA00237
	for <sip-archive@odin.ietf.org>; Fri, 25 Oct 2002 12:10:57 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9PGCma14252
	for sip-archive@odin.ietf.org; Fri, 25 Oct 2002 12:12:48 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PGBov14025;
	Fri, 25 Oct 2002 12:11:50 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PG3rv12593
	for <sip@optimus.ietf.org>; Fri, 25 Oct 2002 12:03:53 -0400
Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29725;
	Fri, 25 Oct 2002 12:01:26 -0400 (EDT)
Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44])
	by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9PG3agM004544;
	Fri, 25 Oct 2002 09:03:36 -0700 (PDT)
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 ABE94722;
	Fri, 25 Oct 2002 09:01:11 -0700 (PDT)
Date: Fri, 25 Oct 2002 09:04:06 -0700
Subject: Re: [Sip] Questions on the draft on the Replaces header
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v546)
Cc: sip@ietf.org, sip-admin@ietf.org
To: <frank.derks@philips.com>
From: Rohan Mahy <rohan@cisco.com>
In-Reply-To: <OF4B4C5ED9.AB28593E-ONC1256C5D.00251C8D@diamond.philips.com>
Message-Id: <6345349C-E833-11D6-A34B-0003938AF740@cisco.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.546)
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi,

This topic will be covered in the cc-transfer draft.  Basically, it is 
A's responsibility to terminate its session with B.  How B selects 
which session has "focus" is an implementation issue, but one that the 
transfer draft will discuss.

thanks,
-rohan


On Friday, October 25, 2002, at 12:12 AM, <frank.derks@philips.com> 
wrote:

> Rohan,
>
> I understand that REFER, which includes the Refer-To header, is 
> sufficient
> to get B to establish a session with C. If I understand the REFER draft
> correctly, this has no impact on the session between A and B 
> Therefore, at
>
> some point in time, B will have two sessions: on with A, and one with 
> B.
>
> I think that this leads to a situation in which it is not clear what B
> will
> do:
>
> - will it mix the media from the two sessions?
> - to which of the two sessions will it listen?
> - to which of the two sessions will it talk?
>
> The latter two can be influenced by A by modifying the session (e.g. 
> put
> it
> on hold).
>
> If it is A's intention to effect a transfer, it could do this 
> implicitely
> by
> terminating its session with B. However, B then only has implicit
> knowledge
> (the fact that its session with A was terminated) that A probably 
> intended
>
> to transfer its session with B to C.
>
> The reason for adding the Replaces header to the REFER would be to 
> make it
> _explicit_ for B to replace its session with A by a session with C.
>
> I realise that this somewhat changes the semantics of the Replaces 
> header
> in
> the current proposal, but probably not by much. The current draft
> describes
> the use of the Replaces header in combination with an INVITE request 
> only.
>
> Adding additional semantics for its use in combination with a REFER
> request
> would not seem to present a major impact. In particular, if the 
> semantics
> of the Replaces header are "replace the dialog/session on which this
> header
> is received with the dialog/session specified in the Replaces header",
> both
> situations would seem to be covered.
>
> Regards,
>
> Frank
>
>
>
>
>
>
>
> Rohan Mahy <rohan@cisco.com>
> Sent by: sip-admin@ietf.org
> 2002-10-25 00:14
>
>
>         To:     Frank Derks/HVS/BE/PHILIPS@EMEA2
>         cc:     sip@ietf.org
>         Subject:        Re: [Sip] Questions on the draft on the 
> Replaces header
>         Classification:
>
>
>
> Hi,
>
> If I understand your message correctly, I believe you are trying to add
> additional semantics to Replaces which are not necessary to accomplish
> what I believe you want to achieve.
>
> If A has an existing session with C using a call-id of foo, I think you
> are asking for A to send a REFER that causes B to send an INVITE to C,
> such that the INVITE contains a Replaces header.  This would cause a
> new session from B to C to replace the old session from A to C.
>
> To do this A sends a REFER with the following Refer-To header:
>
> REFER sip:B SIP/2.0
> Refer-To: <sip:C?Replaces=foo>
>
> This causes B to generate an INVITE of the following form:
>
> INVITE sip:C SIP/2.0
> Replaces: foo
>
> Headers in the REFER request are orthogonal to headers in the triggered
> request.  Headers  intended for inclusion in the triggered request are
> included in the Refer-To URI.
>
> I hope this answers your question.
>
> thanks,
> -rohan
>
>
> On Thursday, October 24, 2002, at 08:03 AM, frank.derks@philips.com
> wrote:
>
>> The Replaces header draft
>> (http://www.ietf.org/internet-drafts/draft-ietf-sip-replaces-02.txt),
>> states that this header is only defined for INVITE requests (section
>> 6.1).
>> The Overview
>> section (section 2), however, states that it is frequently used in
>> combination with the
>> REFER method as used in call transfer. Although the latter does not
>> imply
>> that a Replaces
>> header could be used in a REFER request, it does seem to hint in that
>> direction.
>>
>> Especially in the case of call transfer, it would be useful if it were
>> allowed to use the
>> Replaces header in a REFER request. The reasoning behind this is the
>> following.
>>
>> Receiving a REFER request, is a request to _also_ contact the
>> destination
>> contained in the
>> Refer-To header. It has no implications for the Dialog (or the
>> Session) on
>> which the REFER
>> was sent. This means that it is up to the recipient of the REFER
>> request,
>> to decide on the
>> action(s) it is going to take after having contacted the indicated
>> destination. I.e. it is
>> neither explicitely, nor implicitely conveyed that a transfer should
>> take
>> place. If this
>> does take place, this is up to the endpoint that received the REFER
>> request. This is
>> outside the control of the endpoint that sent the REFER request.
>>
>> If it were allowed to use the Replaces header in a REFER request, it
>> would
>> become possible
>> to explicitely effect a transfer. Assuming that the endpoint sending
>> the
>> REFER request has
>> a Session with both parties that it wishes to transfer the call to,
>> such a
>> REFER would be
>> used as follows. The REFER request will contain a Refer-To header to
>> indicate the endpoint
>> to which the Session should be transferred. I.e. the endpoint that
>> should
>> be contacted by
>> the recipient of the REFER request. The Replaces header contains
>> details
>> about the Session
>> that the sender of the REFER request has with the party to which that
>> Session should be
>> transferred. The recipient of the REFER copies this header into the
>> INVITE
>> request that
>> it sends to establish the transfer call. The latter is, what I 
>> believe,
>> described in the
>> current Replaces draft.
>>
>> Any opinions on this?
>>
>>
>> Regards,
>>
>> Frank
>>
>> _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol
>> Use sip-implementors@cs.columbia.edu for questions on current sip
>> Use sipping@ietf.org for new developments on the application of sip
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>
>
>

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



From mailnull@www1.ietf.org  Fri Oct 25 12:15:05 2002
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 MAA00338
	for <sip-archive@odin.ietf.org>; Fri, 25 Oct 2002 12:15:05 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9PGGvF14500
	for sip-archive@odin.ietf.org; Fri, 25 Oct 2002 12:16:57 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PGGJv14483;
	Fri, 25 Oct 2002 12:16:19 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PFaCv11014
	for <sip@optimus.ietf.org>; Fri, 25 Oct 2002 11:36:12 -0400
Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28582
	for <sip@ietf.org>; Fri, 25 Oct 2002 11:33:49 -0400 (EDT)
Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Fri, 25 Oct 2002 17:36:05 +0200
Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <VKASBVBA>; Fri, 25 Oct 2002 17:36:05 +0200
Message-Id: <D383E753268ED61183F60003473BCD9520E85A@G8PPX.blf01.telekom.de>
From: "Liess, Laura" <Laura.Liess@t-systems.com>
To: rohan@cisco.com
Cc: sip@ietf.org
Subject: AW: [Sip] moving UDP support out of the core SIP document
Date: Fri, 25 Oct 2002 17:36:05 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

Rohan, 

I don't think moving UDP support out of the core SIP document is a good idea. Doing so will probably solve many technical problems, but in my opinion doing such important changes all the time leads to interoperability problems and to additional delays in adoption of SIP as a basis for real customer solutions. SIP over UDP works fine within enterprise networks and IP-VPNs.
  
I also can remember UDP was one of our main arguments again H.323 about 3 years ago...

Thanks, Laura     



> -----Ursprungliche Nachricht-----
> Von: Rohan Mahy [mailto:rohan@cisco.com]
> Gesendet: Mittwoch, 23. Oktober 2002 21:03
> An: Victor Paulsamy
> Cc: sip@ietf.org
> Betreff: Re: [Sip] moving UDP support out of the core SIP document
> 
> 
> Hi Victor,
> 
> Having no default transport does not encourage interoperability which 
> is a major goal of Internet protocols.
> 
> thanks,
> -rohan
> 
> On Wednesday, October 23, 2002, at 11:23 AM, Victor Paulsamy wrote:
> 
> > If SIP is "truly" independent of underlying transport protocols, 
> > wouldn't it
> > be appropriate to make all transports "optional"?
> >
> > Regards,
> >
> > --victor
> >
> >> -----Original Message-----
> >> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On 
> Behalf Of Rohan
> >> Mahy
> >> Sent: Wednesday, October 23, 2002 11:02 AM
> >> To: sip@ietf.org
> >> Subject: [Sip] moving UDP support out of the core SIP document
> >>
> >>
> >> Hello Everyone,
> >>
> >> I wanted to share some thoughts that I had about removing 
> UDP from the
> >> core SIP document when we go to draft standard. We are probably at
> >> least one year away from going to Draft Standard. I hope 
> that during
> >> this time most implementations will support RFC3261, and therefore
> >> support TCP.  In addition, it is quite likely that when moving to 
> >> Draft
> >> Standard that the IESG will REQUIRE TLS support on SIP User Agents.
> >> This would ensure a ubiquitous hop-by-hop channel security 
> mechanism,
> >> but which requires a reliable transport (TCP or SCTP).
> >>
> >> Obviously UDP is still very attractive in wireless 
> networks (due to 
> >> RTT
> >> issues) and in other typically private networks with 
> well-understood
> >> delay and loss characteristics. To make most 
> implementations simpler
> >> however, I am proposing that we make unreliable transports (UDP and
> >> DCCP) of SIP optional in User Agents, and that we put the 
> UDP-specific
> >> mechanism (ex: much of the complication of the transaction 
> layer for
> >> handling retransmissions) in a separate Draft Standard 
> document.  It 
> >> is
> >> very likely that if we did this there would also be a baseline 
> >> security
> >> mechanism for UDP as well (probably some profile of 
> IPsec).  The net
> >> effect is that SIP User Agents could also talk to each 
> other using TCP
> >> or TLS+TCP, and that User Agents with a strong preference for UDP 
> >> would
> >> have a consistent security mechanism.  Proxies would still support 
> >> both
> >> transports, so you could easily communicate between a TCP-only User
> >> Agent, and as User Agent which prefers UDP without 
> requiring the User
> >> Agent to switch over to TCP.
> >>
> >> I welcome your discussion and comments on this idea.
> >>
> >> thanks,
> >> -rohan
> >>
> >> _______________________________________________
> >> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >> This list is for NEW development of the core SIP Protocol
> >> Use sip-implementors@cs.columbia.edu for questions on current sip
> >> Use sipping@ietf.org for new developments on the application of sip
> >>
> >
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Fri Oct 25 18:12:17 2002
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 SAA13668
	for <sip-archive@odin.ietf.org>; Fri, 25 Oct 2002 18:12:17 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9PMEC303369
	for sip-archive@odin.ietf.org; Fri, 25 Oct 2002 18:14:12 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PMDpv03349;
	Fri, 25 Oct 2002 18:13:51 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PMCMv03309
	for <sip@optimus.ietf.org>; Fri, 25 Oct 2002 18:12:22 -0400
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 SAA13613
	for <sip@ietf.org>; Fri, 25 Oct 2002 18:09:56 -0400 (EDT)
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 g9PMBLFu027825
	for <sip@ietf.org>; Fri, 25 Oct 2002 18:11:21 -0400 (EDT)
Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <S3PQXYKC>; Fri, 25 Oct 2002 17:12:12 -0500
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A642A7@DYN-TX-EXCH-001.dynamicsoft.com>
From: Adam Roach <adam@dynamicsoft.com>
To: "'sip@ietf.org'" <sip@ietf.org>
Date: Fri, 25 Oct 2002 17:12:07 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sip] "List" Event Template Package: new draft available
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

For those of you not following SIMPLE: a while back, we started work
on a mechanism for conveying presence of several entities with a single
subscription. At the Yokohama meeting (and in ensuing mailing list
discussions), we decided that the mechanism would probably be most useful
if it were generalized to a collection event template package that allows
for aggregation of any event package, not just presence.

The resulting i-d describing a template event package for collections
has now been submitted to the drafts editor. Until a copy appears in
the archives, you can download a copy from:

http://pages.sbcglobal.net/roaches/ietf/draft-roach-sip-list-template-00.txt

HTML version also available:
http://pages.sbcglobal.net/roaches/ietf/draft-roach-sip-list-template-00.htm
l

This work is still rather rough around the edges, but I think it gives a
good starting point for discussion.

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



From mailnull@www1.ietf.org  Sat Oct 26 07:35:55 2002
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 HAA04963
	for <sip-archive@odin.ietf.org>; Sat, 26 Oct 2002 07:35:54 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9QBbix12677
	for sip-archive@odin.ietf.org; Sat, 26 Oct 2002 07:37:44 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9QBakv12072;
	Sat, 26 Oct 2002 07:36:46 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9QBX9v11999
	for <sip@optimus.ietf.org>; Sat, 26 Oct 2002 07:33:10 -0400
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 HAA04865
	for <sip@ietf.org>; Sat, 26 Oct 2002 07:30:32 -0400 (EDT)
Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9QBWUKV026820;
	Sat, 26 Oct 2002 13:32:30 +0200 (MEST)
Received: from lmf.ericsson.se (136.225.183.41 [136.225.183.41]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55)
	id VQSTH3SN; Sat, 26 Oct 2002 13:32:30 +0200
Message-ID: <3DBA7D44.C6826669@lmf.ericsson.se>
Date: Sat, 26 Oct 2002 14:32:20 +0300
X-Sybari-Space: 00000000 00000000 00000000 00000000
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: sip <sip@ietf.org>, Dean Willis <dwillis@dynamicsoft.com>,
        Hisham.Khartabil@nokia.com, bcampbell@dynamicsoft.com
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Congestion safety
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Folks,

I have been reading the two drafts we have about congestion safety.

http://www.ietf.org/internet-drafts/draft-khartabil-sip-congestionsafe-ci-01.txt

and

http://www.ietf.org/internet-drafts/draft-ietf-sip-congestsafe-00.txt


I believe that trying to control the pace at which a proxy sends request
is a good idea. Dean and Ben's draft deals with that.

In addition to that, both drafts try to deal with SIP message size. I am
not sure that we want to go down this path. Both drafts propose
application-layer solutions to this problem. However, the SIP layer can
only make educated guesses about the size of a SIP message
"on-the-wire".

Both drafts decide the maximum application-layer message size based on
the maximum network-layer packet size (MTU). The problem is that between
the application layer and the network layer you will have things like
MIP and IPsec that may increase the size of the message and things like
SigComp that may reduce it.

IMO, trying to resolve a problem that only applies to legacy systems
(any future UA/proxy that handles large messages will implement TCP
and/or SCTP) by providing only approximate solutions is not a good idea.
And since any complete solution would be too complex, I would suggest
that we skip solving this issue. If a legacy system needs to be upgraded
to be congestion safe, it should implement a simple TCP stack (no TCP
features are needed) rather than implement UDP tricks.

I realize that the content indirection mechanism proposed by Hisham
could be used regardless of the MTU... but that's another story.

Comments?

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



From mailnull@www1.ietf.org  Sat Oct 26 17:22:41 2002
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 RAA12558
	for <sip-archive@odin.ietf.org>; Sat, 26 Oct 2002 17:22:41 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9QLObK02127
	for sip-archive@odin.ietf.org; Sat, 26 Oct 2002 17:24:37 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9QLNcv02092;
	Sat, 26 Oct 2002 17:23:38 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9QKukv00580
	for <sip@optimus.ietf.org>; Sat, 26 Oct 2002 16:56:46 -0400
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 QAA12090
	for <sip@ietf.org>; Sat, 26 Oct 2002 16:54:20 -0400 (EDT)
Received: from khanr ([12.89.77.9]) by mtiwmhc13.worldnet.att.net
          (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with SMTP
          id <20021026205639.YVUT12639.mtiwmhc13.worldnet.att.net@khanr>
          for <sip@ietf.org>; Sat, 26 Oct 2002 20:56:39 +0000
Message-ID: <000901c27d33$87922060$094d590c@khanr>
From: "Munira Sharmin" <msharmin@worldnet.att.net>
To: <sip@ietf.org>
Date: Sat, 26 Oct 2002 17:06:17 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-7"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Content-Transfer-Encoding: 7bit
Subject: [Sip] abnormal situation after connect
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Caller and callee SIP endpoints session starts (i.e. 200 Ok for the INVITE
and ACK exchange happens). If for some abnormal situation, say in one of the
proxy in between, session has to get torn down,  then it looks like
currently, only BYE is sent with no indication as to whether this is a
normal release or some abnormal release. So other proxies in the path or the
endpoints will have no idea why the call dropped.
How about inclusion of an optional reason header in the BYE message for such
a case, or can the SIP gurus gaurantee that such a situation will NEVER
occur (well, I have seen that happen once in a rare while) ?
Thanks.

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



From mailnull@www1.ietf.org  Sat Oct 26 19:23:47 2002
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 TAA14024
	for <sip-archive@odin.ietf.org>; Sat, 26 Oct 2002 19:23:47 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9QNPgB06692
	for sip-archive@odin.ietf.org; Sat, 26 Oct 2002 19:25:42 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9QNPJv06683;
	Sat, 26 Oct 2002 19:25:19 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9QNN4v06648
	for <sip@optimus.ietf.org>; Sat, 26 Oct 2002 19:23:04 -0400
Received: from i3exchange.i3domain.inin.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13850
	for <sip@ietf.org>; Sat, 26 Oct 2002 19:20:38 -0400 (EDT)
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: Sat, 26 Oct 2002 18:22:57 -0500
Message-ID: <58A40B582A73F54AB5D8739C0678F3A8020BB324@i3exchange.inin.com>
Thread-Topic: Standard mechanism to instruct the phone go off hook
Thread-Index: AcJ9RugdwlL/snawQ6qAbn/TE+DX/A==
From: "Snyder, Duke" <Duke.Snyder@inin.com>
To: <sip@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9QNN4v06649
Subject: [Sip] Standard mechanism to instruct the phone go off hook
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit

Has any work been done to have a standard mechanism for an application to request that the phone answer it's "alerting" call by going off hook (to speaker mode).   Currently, different hard IP phones have a different ways to "auto-answer", but it complicates SIP development working with proprietary, non-SIP techniques.   The PhoneControl draft (http://www.cs.columbia.edu/~hgs/sip/drafts/draft-dean-phonectl-03.txt) seems to do some phone control, but not the auto-answer request.

Common scenarios for this request:
*	A call center agent typically uses auto-answer for his call center calls.  His SIP app (based off his configuration) could send the call to his phone (with a headset), request that the phone answer the call, and the agent handles the call completely hands-free.
*	A call center supervisor selects a call to monitor.  His SIP app will direct the audio of the call to his phone, but first must call his phone to establish an audio path.  Again, typically the supervisor would like the phone to automatically go off hook rather than forcing him to answer the phone.

Authentication would need to be used since most people would not want their SIP phone in their bedroom to go off hook.


Duke Snyder
Interactive Intelligence, Inc.
www.inin.com




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



From mailnull@www1.ietf.org  Sun Oct 27 08:12:32 2002
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 IAA03351
	for <sip-archive@odin.ietf.org>; Sun, 27 Oct 2002 08:12:32 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9RDEN218413
	for sip-archive@odin.ietf.org; Sun, 27 Oct 2002 08:14:23 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9RDD5v18396;
	Sun, 27 Oct 2002 08:13: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 g9RDAtv18350
	for <sip@optimus.ietf.org>; Sun, 27 Oct 2002 08:10:55 -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 IAA03286
	for <sip@ietf.org>; Sun, 27 Oct 2002 08:08:31 -0500 (EST)
Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9RDAbKV025152;
	Sun, 27 Oct 2002 14:10:38 +0100 (MET)
Received: from lmf.ericsson.se (136.225.183.41 [136.225.183.41]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55)
	id VSSYX6KQ; Sun, 27 Oct 2002 14:10:36 +0100
Message-ID: <3DBBE5D2.8FC71D64@lmf.ericsson.se>
Date: Sun, 27 Oct 2002 15:10:42 +0200
X-Sybari-Space: 00000000 00000000 00000000 00000000
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: Munira Sharmin <msharmin@worldnet.att.net>
CC: sip@ietf.org
Subject: Re: [Sip] abnormal situation after connect
References: <000901c27d33$87922060$094d590c@khanr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Munira,

In draft-ietf-sip-reason-01.txt you can find examples of requests with
Reason headers. One of the examples consists of a BYE with a "Not
Acceptable" Reason header field. This way, all the SIP entities in the
path will know (as long as they can read the Reason header) that the BYE
was sent because the last offer received from the peer was unacceptable.

Regards,

Gonzalo

Munira Sharmin wrote:
> 
> Caller and callee SIP endpoints session starts (i.e. 200 Ok for the INVITE
> and ACK exchange happens). If for some abnormal situation, say in one of the
> proxy in between, session has to get torn down,  then it looks like
> currently, only BYE is sent with no indication as to whether this is a
> normal release or some abnormal release. So other proxies in the path or the
> endpoints will have no idea why the call dropped.
> How about inclusion of an optional reason header in the BYE message for such
> a case, or can the SIP gurus gaurantee that such a situation will NEVER
> occur (well, I have seen that happen once in a rare while) ?
> Thanks.
> 
> +AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXw-
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors+AEA-cs.columbia.edu for questions on current sip
> Use sipping+AEA-ietf.org for new developments on the application of 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
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Mon Oct 28 04:44:19 2002
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 EAA01688
	for <sip-archive@odin.ietf.org>; Mon, 28 Oct 2002 04:44:19 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9S9kMH12362
	for sip-archive@odin.ietf.org; Mon, 28 Oct 2002 04:46:22 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9S9jhv12339;
	Mon, 28 Oct 2002 04:45: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 g9S9fXv12227
	for <sip@optimus.ietf.org>; Mon, 28 Oct 2002 04:41:33 -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 EAA01555
	for <sip@ietf.org>; Mon, 28 Oct 2002 04:39:00 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.11])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g9S9fLYH019654;
	Mon, 28 Oct 2002 04:41:21 -0500 (EST)
Message-ID: <3DBD063F.6090503@dynamicsoft.com>
Date: Mon, 28 Oct 2002 04:41:20 -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: BECKMANN MARK <mark.beckmann@siemens.com>
CC: sip@ietf.org
Subject: Re: [Sip] Schedule for draft-rosenberg-sip-reg-00
References: <B3028CA9D0B8D511874E0002A53F24D566D1B9@mchh9mla.mchh.siemens.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

I've just submitted an update to the registration event package. Until 
it appears in the archives, you can pick it up from:

http://www.jdrosen.net/papers/draft-ietf-sipping-reg-event-00.txt

It incorporates the suggestions made by Mark on the list. Specifically, 
it has added a new event, called "shortened", which informs the 
subscriber that their registration interval has been shortened, and that 
they should re-register. It also adds an expires parameter that 
indicates the lifetime of the contact that is remaining.

I have kept the deactivated and expired events, as they were, which is 
the consensus on the list on this topic I believe.

Finally, I owe both Mark and the working group an apology on this draft. 
Mark's comments were made in July, and I provided no response or 
document update until now. I could make all the standard excuses, but I 
won't - its really just unacceptable.

I'd also like to acknowledge Rohan here, for providing some editing 
assistance in order to make sure this made it out the door in time for 
ietf 55.

I think this document is probably now ready for working group last call. 
There is not much controversial about it, and no open issues I am aware of.

-Jonathan R.


BECKMANN MARK wrote:
> Hi,
> 
> I'd like to know what the planned schedule for the I-D
> draft-rosenberg-sip-reg is? There haven't been a lot of dicussions on the
> list about this draft. I think a revision is needed based on the comments
> raised in the following messages:
> 
> http://www.ietf.org/mail-archive/working-groups/sip/current/msg06113.html
> http://www.ietf.org/mail-archive/working-groups/sip/current/msg06118.html
> http://www.ietf.org/mail-archive/working-groups/sip/current/msg06124.html
> 
> Are there any plans yet when this draft is supposed to move to WG LC? The
> main reason I'm asking is that 3GPP needs this draft to finalise their
> Release 5 specifications.
> 
> Regards,
> 
> Mark
> 
> Mark Beckmann			Siemens AG
> 
> ICM MP P PS 4S2
> P.O.Box 100702			phone: +49 (5341) 906 1814
> D-38228 Salzgitter   		fax:   +49 (5341) 906 2010
> 
> mailto: Mark.Beckmann@siemens.com
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of 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

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



From mailnull@www1.ietf.org  Mon Oct 28 06:39:09 2002
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 GAA04045
	for <sip-archive@odin.ietf.org>; Mon, 28 Oct 2002 06:39:09 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9SBf2v17873
	for sip-archive@odin.ietf.org; Mon, 28 Oct 2002 06:41:02 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SBecv17842;
	Mon, 28 Oct 2002 06:40: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 g9SBbTv17676
	for <sip@optimus.ietf.org>; Mon, 28 Oct 2002 06:37:29 -0500
Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03931
	for <sip@ietf.org>; Mon, 28 Oct 2002 06:35:06 -0500 (EST)
Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44])
	by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9SBbOgM015978;
	Mon, 28 Oct 2002 03:37:24 -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 ABF15836;
	Mon, 28 Oct 2002 03:35:01 -0800 (PST)
Date: Mon, 28 Oct 2002 03:37:59 -0800
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v546)
Cc: "'Dean Willis'" <dean.willis@softarmor.com>, jon.peterson@neustar.biz,
        rohan@cisco.com
To: sip@ietf.org
From: Rohan Mahy <rohan@cisco.com>
Content-Transfer-Encoding: 7bit
Message-Id: <B5C0B124-EA69-11D6-925C-0003938AF740@cisco.com>
X-Mailer: Apple Mail (2.546)
Content-Transfer-Encoding: 7bit
Subject: [Sip] agenda requests
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi,

I am now taking agenda requests for SIP. Please remember that agenda 
time will be to discuss open issues and should not be used as a 
tutorial on a specific draft. If you are the author of a chartered item 
which has no open issues, please ping the chairs so that we can give a 
brief status update on your behalf.  Also, please note that SIP has 
only a single agenda slot this time, so most individual submissions 
should be discussed in SIPPING, unless the chairs have directed 
otherwise.

thanks,
-rohan

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



From mailnull@www1.ietf.org  Mon Oct 28 09:28:55 2002
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 JAA10643
	for <sip-archive@odin.ietf.org>; Mon, 28 Oct 2002 09:28:55 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9SEUmb25972
	for sip-archive@odin.ietf.org; Mon, 28 Oct 2002 09:30:48 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SEUAv25947;
	Mon, 28 Oct 2002 09:30: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 g9SEPgv25798
	for <sip@optimus.ietf.org>; Mon, 28 Oct 2002 09:25:43 -0500
Received: from newdev.harvard.edu (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10353;
	Mon, 28 Oct 2002 09:23:19 -0500 (EST)
Received: (from sob@localhost)
	by newdev.harvard.edu (8.12.2/8.12.2) id g9SEOVSl010841;
	Mon, 28 Oct 2002 09:24:31 -0500 (EST)
Date: Mon, 28 Oct 2002 09:24:31 -0500 (EST)
From: Scott  Bradner <sob@harvard.edu>
Message-Id: <200210281424.g9SEOVSl010841@newdev.harvard.edu>
To: iptel@lists.bell-labs.com, sip@ietf.org, sipping@ietf.org
Cc: antti.vaha-sipila@nokia.com, james.yu@neustar.biz, mankin@psg.com,
        orit@radvision.com, schulzrinne@cs.columbia.edu
Subject: [Sip] request for iptell to review "url" IDs
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>



msg from the TSV ADs 

we would like the iptel WG to take on the following 3 IDs 

        draft-antti-rfc2806bis-05.txt
        draft-yu-tel-url-06.txt
        draft-levin-iptel-h323-url-scheme-04.txt       

we would like the WG to review the 3 IDs to be sure that they do not
conflict in the use of terminology or technology and to work with the ID
authors to resolve any conflicts

anyone with opinions about these IDs should join the iptel list and discuss
the issues there

we expect that this task will be a short term one and we can move to
getting these IDs published

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



From mailnull@www1.ietf.org  Mon Oct 28 09:33:38 2002
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 JAA11091
	for <sip-archive@odin.ietf.org>; Mon, 28 Oct 2002 09:33:38 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9SEZUa26271
	for sip-archive@odin.ietf.org; Mon, 28 Oct 2002 09:35:30 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SEZAv26251;
	Mon, 28 Oct 2002 09:35: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 g9SEYXv26209
	for <sip@optimus.ietf.org>; Mon, 28 Oct 2002 09:34: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 JAA10792
	for <sip@ietf.org>; Mon, 28 Oct 2002 09:32:07 -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 g9SEHOi26121
	for <sip@ietf.org>; Mon, 28 Oct 2002 19:47:24 +0530
Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 65256C60.004FD06D ; Mon, 28 Oct 2002 20:01:46 +0530
X-Lotus-FromDomain: HSSBLR
To: sip@ietf.org
cc: hbhondwe@hss.hns.com
Message-ID: <65256C60.004FCF65.00@sampark.hss.hns.com>
Date: Mon, 28 Oct 2002 20:01:20 +0530
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: [Sip] Status: draft-ietf-sip-asserted-identity-02
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>



Hi,

Can the authors of this draft please tell me the current status of this
draft?.
Is it already in RFC editors queue. Is a revision 3 of the draft in the
making?

Can you please also share changes/issues that have been accepted as changes
to be done over version 2 of the draft, which will therefore go into a
future revision of the draft.


thanks
Harsh Bhondwe
Hughes Software Systems







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.


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



From mailnull@www1.ietf.org  Mon Oct 28 09:35:43 2002
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 JAA11253
	for <sip-archive@odin.ietf.org>; Mon, 28 Oct 2002 09:35:43 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9SEbaa26980
	for sip-archive@odin.ietf.org; Mon, 28 Oct 2002 09:37:36 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SEbFv26760;
	Mon, 28 Oct 2002 09:37: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 g9SEaFv26306
	for <sip@optimus.ietf.org>; Mon, 28 Oct 2002 09:36:15 -0500
Received: from ihemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11122
	for <sip@ietf.org>; Mon, 28 Oct 2002 09:33:51 -0500 (EST)
Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57])
	by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g9SEaAq00116
	for <sip@ietf.org>; Mon, 28 Oct 2002 09:36:11 -0500 (EST)
Received: by en0060D057.uk.lucent.com with Internet Mail Service (5.5.2653.19)
	id <TYBQ6QTG>; Mon, 28 Oct 2002 14:36:10 -0000
Message-ID: <475FF955A05DD411980D00508B6D5FB0067B5714@en0033exch001u.uk.lucent.com>
From: "Drage, Keith (Keith)" <drage@lucent.com>
To: Rohan Mahy <rohan@cisco.com>, sip@ietf.org
Subject: RE: [Sip] moving UDP support out of the core SIP document
Date: Mon, 28 Oct 2002 14:35:49 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

Comments/questions as follows:

1)	Your proposal deals with the change of UDP from mandatory to optional at the UE. What changes, if any, would you expect to make to proxy support and handling?

2)	I did a quick look at the RFCs for TCP, and failed to work out whether all IETF compliant TCPs are now RFC 2914 compliant or not. This is because I am not sure whether the term "updates" used in the RFC index, automatically obsoletes the previuos version, and therefore is it possible to claim IETF compliance by implementing the core TCP RFC without implementing the congestion control extension. I assume that what we would require is mandatory support of a TCP that is RFC 2914 compliant.

3)	Given that you intend to retain support of UDP, although as an optional feature, I am not sure I would agree to moving it to a separate RFC. By all means move it and the supporting procedures to a normative annex, but moving it to a separate specification will lead to endless requests on the mailing list by people asking where the UDP support has gone.


Keith


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

> -----Original Message-----
> From: Rohan Mahy [mailto:rohan@cisco.com]
> Sent: 23 October 2002 19:02
> To: sip@ietf.org
> Subject: [Sip] moving UDP support out of the core SIP document
> 
> 
> Hello Everyone,
> 
> I wanted to share some thoughts that I had about removing UDP 
> from the 
> core SIP document when we go to draft standard. We are probably at 
> least one year away from going to Draft Standard. I hope that during 
> this time most implementations will support RFC3261, and therefore 
> support TCP.  In addition, it is quite likely that when 
> moving to Draft 
> Standard that the IESG will REQUIRE TLS support on SIP User Agents. 
> This would ensure a ubiquitous hop-by-hop channel security mechanism, 
> but which requires a reliable transport (TCP or SCTP).
> 
> Obviously UDP is still very attractive in wireless networks 
> (due to RTT 
> issues) and in other typically private networks with well-understood 
> delay and loss characteristics. To make most implementations simpler 
> however, I am proposing that we make unreliable transports (UDP and 
> DCCP) of SIP optional in User Agents, and that we put the 
> UDP-specific 
> mechanism (ex: much of the complication of the transaction layer for 
> handling retransmissions) in a separate Draft Standard 
> document.  It is 
> very likely that if we did this there would also be a 
> baseline security 
> mechanism for UDP as well (probably some profile of IPsec).  The net 
> effect is that SIP User Agents could also talk to each other 
> using TCP 
> or TLS+TCP, and that User Agents with a strong preference for 
> UDP would 
> have a consistent security mechanism.  Proxies would still 
> support both 
> transports, so you could easily communicate between a TCP-only User 
> Agent, and as User Agent which prefers UDP without requiring the User 
> Agent to switch over to TCP.
> 
> I welcome your discussion and comments on this idea.
> 
> thanks,
> -rohan
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Mon Oct 28 09:36:34 2002
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 JAA11313
	for <sip-archive@odin.ietf.org>; Mon, 28 Oct 2002 09:36:34 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9SEcQa27082
	for sip-archive@odin.ietf.org; Mon, 28 Oct 2002 09:38:26 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SEc9v27062;
	Mon, 28 Oct 2002 09:38: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 g9SEb3v26455
	for <sip@optimus.ietf.org>; Mon, 28 Oct 2002 09:37:03 -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 JAA11190
	for <sip@ietf.org>; Mon, 28 Oct 2002 09:34:39 -0500 (EST)
Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39])
	by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g9SEawA10796;
	Mon, 28 Oct 2002 09:36:59 -0500 (EST)
Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id IAA03656; Mon, 28 Oct 2002 08:36:52 -0600 (CST)
Message-ID: <3DBD4B2A.2090102@lucent.com>
Date: Mon, 28 Oct 2002 08:35:22 -0600
From: "Vijay K. Gurbani" <vkg@lucent.com>
Organization: Lucent Technologies, Inc./Bell Laboratories
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: Munira Sharmin <msharmin@worldnet.att.net>
CC: sip@ietf.org
Subject: Re: [Sip] abnormal situation after connect
References: <000901c27d33$87922060$094d590c@khanr>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Munira Sharmin wrote:
> Caller and callee SIP endpoints session starts (i.e. 200 Ok for the 
> INVITE and ACK exchange happens). If for some abnormal situation, say 
> in one of the proxy in between, session has to get torn down,  then it 
> looks like currently, only BYE is sent with no indication as to whether 
> this is a normal release or some abnormal release. So other proxies in 
> the path or the endpoints will have no idea why the call dropped.
> How about inclusion of an optional reason header in the BYE message for 
> such a case, or can the SIP gurus gaurantee that such a situation will 
> NEVER occur (well, I have seen that happen once in a rare while) ?

Take a look at the SIP Reason Header I-D
http://www.ietf.org/internet-drafts/draft-ietf-sip-reason-01.txt.

It does what you want.

Regards,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216

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



From mailnull@www1.ietf.org  Mon Oct 28 09:50:01 2002
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 JAA11824
	for <sip-archive@odin.ietf.org>; Mon, 28 Oct 2002 09:50:01 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9SEpsk27717
	for sip-archive@odin.ietf.org; Mon, 28 Oct 2002 09:51:54 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SEpVv27707;
	Mon, 28 Oct 2002 09:51: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 g9S90Qv09405
	for <sip@optimus.ietf.org>; Mon, 28 Oct 2002 04:00:26 -0500
Received: from rwcrmhc51.attbi.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00897
	for <sip@ietf.org>; Mon, 28 Oct 2002 03:57:53 -0500 (EST)
Received: from parameswjq8fwx ([12.237.230.168]) by rwcrmhc51.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP
          id <20021028090013.OSNA17494.rwcrmhc51.attbi.com@parameswjq8fwx>
          for <sip@ietf.org>; Mon, 28 Oct 2002 09:00:13 +0000
From: "Sriram Parameswar" <sriramkp@attbi.com>
To: <sip@ietf.org>
Date: Mon, 28 Oct 2002 03:00:12 -0600
Message-ID: <KEELKLOEMJCHGFFFAINJIECECAAA.sriramkp@attbi.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.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Subject: [Sip] FW: New Draft - Suppression of Refer Implicit Subscription
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi All,

I have submitted a draft (to SIPPING) that examines the requirements and one
_potential_ mechanism to suppress the implicit subscription created by the
REFER method.

Till it appears in the IETF site - please pick up a copy at the site below:

http://home.attbi.com/~sriramkp/draft-parameswar-sipping-norefersub-00.txt

<abstract>
   The recipient of the REFER method [1] creates an implicit
   subscription to the 'refer' event. This subscription causes the REFER
   recipient to send NOTIFY messages to the sender informing him of the
   progress of the REFER. This memo provides for the requirements and
   one potential mechanism to suppress the creation of this implicit
   subscription, via an option tag - 'norefersub'. This gives the agent
   sending the REFER control over the creation of the subscription,
   while being backwards compatible with [1].
</abstract>

Your comments are highly appreciated.

Regards,

Sriram Parameswar

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



From mailnull@www1.ietf.org  Mon Oct 28 13:33:21 2002
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 NAA23682
	for <sip-archive@odin.ietf.org>; Mon, 28 Oct 2002 13:33:20 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9SIZEx08302
	for sip-archive@odin.ietf.org; Mon, 28 Oct 2002 13:35:14 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SIYcv08288;
	Mon, 28 Oct 2002 13:34: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 g9SIWAv08243
	for <sip@optimus.ietf.org>; Mon, 28 Oct 2002 13:32:10 -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 NAA23485
	for <sip@ietf.org>; Mon, 28 Oct 2002 13:29:44 -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 g9SIVeb28704
	for <sip@ietf.org>; Mon, 28 Oct 2002 20:31:40 +0200 (EET)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5e391cf0ecac158f21082@esvir01nok.ntc.nokia.com>;
 Mon, 28 Oct 2002 20:32:03 +0200
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Mon, 28 Oct 2002 20:32:03 +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: [Sip] Congestion safety
Date: Mon, 28 Oct 2002 20:32:03 +0200
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE6F42@esebe019.ntc.nokia.com>
Thread-Topic: [Sip] Congestion safety
Thread-Index: AcJ8+MgyhTo22xPWTM+qzdnNnVnPKwBtHbow
To: <Gonzalo.Camarillo@lmf.ericsson.se>, <sip@ietf.org>,
        <dwillis@dynamicsoft.com>, <bcampbell@dynamicsoft.com>
X-OriginalArrivalTime: 28 Oct 2002 18:32:03.0776 (UTC) FILETIME=[4FC9BC00:01C27EB0]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9SIWAv08244
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit

Hi Gonzalo,

While I agree with you about the use of TCP, I still have few concerns:

- How does a terminal decide that a message is large enough to use TCP? How large is large? Would the terminal still use MTU to determine message size?
- RFC3261 recommends using connection oriented protocol if the request is within 200 bytes of MTU, therefore using MTU is nothing new in determining the transport to be used.
- The mechanism in the referenced drafts refers to the situation when the MTU en route is unknown by the UAC. It also doesn't require the UAC to perform an en route MTU discovery. First hop MTU is not enough as we all know.
- Its good that a UAC gets feedback why a message was rejected and how it can make it succeed.
- Message size increases at each hop and the UAC has no idea how large the message will grow as it traverses intermediaries and if it will exceed the MTU or not.
- The use of MTU, as you say, would only be used as an educated guess how large a message size should be. If MTU is 1500, the max size should be set to 1500 - 200 to allow for those extra headers, IP headers etc. (again nothing new here). I can clarify that in the draft is we reach some consensus.

Also, again as you pointed out, the UAC doesn't know the UAS's capabilities, this mechanism can be used regardless of underlying transport protocol so that UAS gets contents indirected. It can then fetch the contents whenever desired (eg: when more memory is available).

Regards,
Hisham

> -----Original Message-----
> From: ext Gonzalo Camarillo [mailtoa:Gonzalo.Camarillo@lmf.ericsson.se]
> Sent: Saturday, October 26, 2002 2:32 PM
> To: sip; Dean Willis; Khartabil Hisham (NMP/Helsinki);
> bcampbell@dynamicsoft.com
> Subject: [Sip] Congestion safety
> 
> 
> Folks,
> 
> I have been reading the two drafts we have about congestion safety.
> 
> http://www.ietf.org/internet-drafts/draft-khartabil-sip-conges
> tionsafe-ci-01.txt
> 
> and
> 
> http://www.ietf.org/internet-drafts/draft-ietf-sip-congestsafe-00.txt
> 
> 
> I believe that trying to control the pace at which a proxy 
> sends request
> is a good idea. Dean and Ben's draft deals with that.
> 
> In addition to that, both drafts try to deal with SIP message 
> size. I am
> not sure that we want to go down this path. Both drafts propose
> application-layer solutions to this problem. However, the SIP 
> layer can
> only make educated guesses about the size of a SIP message
> "on-the-wire".
> 
> Both drafts decide the maximum application-layer message size based on
> the maximum network-layer packet size (MTU). The problem is 
> that between
> the application layer and the network layer you will have things like
> MIP and IPsec that may increase the size of the message and 
> things like
> SigComp that may reduce it.
> 
> IMO, trying to resolve a problem that only applies to legacy systems
> (any future UA/proxy that handles large messages will implement TCP
> and/or SCTP) by providing only approximate solutions is not a 
> good idea.
> And since any complete solution would be too complex, I would suggest
> that we skip solving this issue. If a legacy system needs to 
> be upgraded
> to be congestion safe, it should implement a simple TCP stack (no TCP
> features are needed) rather than implement UDP tricks.
> 
> I realize that the content indirection mechanism proposed by Hisham
> could be used regardless of the MTU... but that's another story.
> 
> Comments?
> 
> Gonzalo
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Mon Oct 28 13:52:18 2002
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 NAA24367
	for <sip-archive@odin.ietf.org>; Mon, 28 Oct 2002 13:52:18 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9SIsCi09615
	for sip-archive@odin.ietf.org; Mon, 28 Oct 2002 13:54:12 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SIrIv09573;
	Mon, 28 Oct 2002 13:53: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 g9SIqEv09547
	for <sip@optimus.ietf.org>; Mon, 28 Oct 2002 13:52:14 -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 NAA24257
	for <sip@ietf.org>; Mon, 28 Oct 2002 13:49:48 -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 g9SIpjb07296
	for <sip@ietf.org>; Mon, 28 Oct 2002 20:51:45 +0200 (EET)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5e392f5208ac158f2512b@esvir05nok.ntc.nokia.com> for <sip@ietf.org>;
 Mon, 28 Oct 2002 20:52:08 +0200
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Mon, 28 Oct 2002 20:52:08 +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: Mon, 28 Oct 2002 20:52:07 +0200
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE6F43@esebe019.ntc.nokia.com>
Thread-Topic: Use of size param in Content-type: message/external-body
Thread-Index: AcJ+sx0Htu+n3y8CT1yQkyds3g2sjA==
To: <sip@ietf.org>
X-OriginalArrivalTime: 28 Oct 2002 18:52:08.0295 (UTC) FILETIME=[1DBCBF70:01C27EB3]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9SIqEv09548
Subject: [Sip] Use of size param in Content-type: message/external-body
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit

Hi,

Content-type: message/external-body has a parameter that indicates the size of the external body. Should this be mentioned somewhere in 

draft-ietf-sip-content-indirect-mech or draft-khartabil-sip-congestionsafe-ci ? It allows the UAS to make a better decision whether to download contents or not.

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



From mailnull@www1.ietf.org  Mon Oct 28 14:19:48 2002
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 OAA25551
	for <sip-archive@odin.ietf.org>; Mon, 28 Oct 2002 14:19:48 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9SJLgI11398
	for sip-archive@odin.ietf.org; Mon, 28 Oct 2002 14:21:42 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SJLIv11371;
	Mon, 28 Oct 2002 14:21: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 g9SJKjv11333
	for <sip@optimus.ietf.org>; Mon, 28 Oct 2002 14:20:45 -0500
Received: from web20705.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25466
	for <sip@ietf.org>; Mon, 28 Oct 2002 14:18:19 -0500 (EST)
Message-ID: <20021028192039.14380.qmail@web20705.mail.yahoo.com>
Received: from [207.46.137.205] by web20705.mail.yahoo.com via HTTP; Mon, 28 Oct 2002 11:20:39 PST
Date: Mon, 28 Oct 2002 11:20:39 -0800 (PST)
From: Sean Olson <seancolson@yahoo.com>
Subject: Re: [Sip] Use of size param in Content-type: message/external-body
To: hisham.khartabil@nokia.com, sip@ietf.org
In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7FE6F43@esebe019.ntc.nokia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

I will add this to an update of the ci mechanism
draft as an optional replacement for the 
"Content-Length" entity header within the
message/external-body MIME type.

thanks,
Sean

--- hisham.khartabil@nokia.com wrote:
> Hi,
> 
> Content-type: message/external-body has a parameter
> that indicates the size of the external body. Should
> this be mentioned somewhere in 
> 
> draft-ietf-sip-content-indirect-mech or
> draft-khartabil-sip-congestionsafe-ci ? It allows
> the UAS to make a better decision whether to
> download contents or not.
> 
> Regards,
> Hisham
> _______________________________________________
> Sip mailing list 
> https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP
> Protocol
> Use sip-implementors@cs.columbia.edu for questions
> on current sip
> Use sipping@ietf.org for new developments on the
> application of sip


__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Mon Oct 28 14:54:22 2002
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 OAA26913
	for <sip-archive@odin.ietf.org>; Mon, 28 Oct 2002 14:54:22 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9SJuHg13514
	for sip-archive@odin.ietf.org; Mon, 28 Oct 2002 14:56:17 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SJtbv13363;
	Mon, 28 Oct 2002 14:55: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 g9SJs2v13245
	for <sip@optimus.ietf.org>; Mon, 28 Oct 2002 14:54:02 -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 OAA26743
	for <sip@ietf.org>; Mon, 28 Oct 2002 14:51:36 -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 g9SJr2pR003594;
	Mon, 28 Oct 2002 14:53:02 -0500 (EST)
Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <S3PQXYQW>; Mon, 28 Oct 2002 13:53:54 -0600
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A642B3@DYN-TX-EXCH-001.dynamicsoft.com>
From: Adam Roach <adam@dynamicsoft.com>
To: "'Munira Sharmin'" <msharmin@worldnet.att.net>,
        "sip+AEA-ietf.org"
	 <sip@ietf.org>
Date: Mon, 28 Oct 2002 13:53:54 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="utf-7"
Subject: [Sip] RE: +AFs-Sip+AF0- abnormal situation after connect
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

+AD4- -----Original Message-----
+AD4- From: Munira Sharmin +AFs-mailto:msharmin+AEA-worldnet.att.net+AF0-
+AD4- 
+AD4- Caller and callee SIP endpoints session starts (i.e. 200 Ok 
+AD4- for the INVITE
+AD4- and ACK exchange happens). If for some abnormal situation, 
+AD4- say in one of the
+AD4- proxy in between, session has to get torn down,  then it looks like
+AD4- currently, only BYE is sent with no indication as to whether this is a
+AD4- normal release or some abnormal release.

I'm having a bit of difficulty completely parsing this, so I might
have misinterpreted what you meant to say. However, it sounds like
you are expecting that a +ACo-proxy+ACo- might have the ability to tear
down a SIP call by sending a BYE mid-session. This behavior is
expressly forbidden by the protocol, for a variety of reasons
(the most obvious two having to do with authentication and CSeq
spaces).

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



From mailnull@www1.ietf.org  Mon Oct 28 23:23:51 2002
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 XAA10165
	for <sip-archive@odin.ietf.org>; Mon, 28 Oct 2002 23:23:51 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9T4PpN06760
	for sip-archive@odin.ietf.org; Mon, 28 Oct 2002 23:25:51 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9T4P5v06730;
	Mon, 28 Oct 2002 23: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 g9T4KDv06636
	for <sip@optimus.ietf.org>; Mon, 28 Oct 2002 23:20:13 -0500
Received: from kevlar.softarmor.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10015
	for <sip@ietf.org>; Mon, 28 Oct 2002 23:17:41 -0500 (EST)
Received: from kevlar.softarmor.com (kevlar.softarmor.com [127.0.0.1])
	by kevlar.softarmor.com (8.12.5/8.12.5) with ESMTP id g9T4K2aq001882;
	Mon, 28 Oct 2002 22:20:03 -0600
Received: (from dwillis@localhost)
	by kevlar.softarmor.com (8.12.5/8.12.5/Submit) id g9T4K2Z8001880;
	Mon, 28 Oct 2002 22:20:02 -0600
X-Authentication-Warning: kevlar.softarmor.com: dwillis set sender to dean.willis@softarmor.com using -f
From: Dean Willis <dean.willis@softarmor.com>
To: sip@ietf.org
Cc: Bernhard Hoeneisen <bhoeneis@ee.ethz.ch>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) 
Date: 28 Oct 2002 22:20:01 -0600
Message-Id: <1035865201.1378.96.camel@kevlar.softarmor.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: [Sip] Service route discovery draft revised
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

We've revised the service route discovery draft and submitted it to the
archives, where it should appear in due course. In the near term, please
examine:

http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-scvrtdisco-02.txt
http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-scvrtdisco-02.html
or for the adventurous
http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-scvrtdisco-02.xml


Things that Changed:

1) Several small typos

2) Clarifications requested by Adam roach on the non-interaction with
record-routes in non-initial transactions

3) New contact info for Bernhard, who's back in .ch-land again.

4) Changed example to show two proxies on service-route

5) Changed examples to use FQDNs instead of name variables as per AD
guidance.

6) Adding paragraph to proxy section discussing multi-homed proxies and
reversible routes which should resolve concerns raised by 3GPP.

Please eyeball this as soon as possible -- we expect to be requesting
(or re-requesting, depending on how you look at it) IETF last call very
soon.

Thanks

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



From mailnull@www1.ietf.org  Tue Oct 29 00:02:54 2002
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 AAA10779
	for <sip-archive@odin.ietf.org>; Tue, 29 Oct 2002 00:02:54 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9T54sl07988
	for sip-archive@odin.ietf.org; Tue, 29 Oct 2002 00:04:54 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9T54Xv07980;
	Tue, 29 Oct 2002 00:04: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 g9T534v07956
	for <sip@optimus.ietf.org>; Tue, 29 Oct 2002 00:03:04 -0500
Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10740
	for <sip@ietf.org>; Tue, 29 Oct 2002 00:00:32 -0500 (EST)
Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44])
	by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9T52kgM018405;
	Mon, 28 Oct 2002 21:02:46 -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 ABF27773;
	Mon, 28 Oct 2002 21:00:23 -0800 (PST)
Date: Mon, 28 Oct 2002 21:03:24 -0800
Subject: Re: [Sip] Status: draft-ietf-sip-asserted-identity-02
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v546)
Cc: sip@ietf.org
To: hbhondwe@hss.hns.com
From: Rohan Mahy <rohan@cisco.com>
In-Reply-To: <65256C60.004FCF65.00@sampark.hss.hns.com>
Message-Id: <C0E152FC-EAFB-11D6-925C-0003938AF740@cisco.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.546)
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi,

Version -02 is in the RFC editor queue.  There will be no rev -03.  
Hope this helps.

thanks,
-rohan



On Monday, October 28, 2002, at 06:31 AM, hbhondwe@hss.hns.com wrote:

>
>
> Hi,
>
> Can the authors of this draft please tell me the current status of this
> draft?.
> Is it already in RFC editors queue. Is a revision 3 of the draft in the
> making?
>
> Can you please also share changes/issues that have been accepted as 
> changes
> to be done over version 2 of the draft, which will therefore go into a
> future revision of the draft.
>
>
> thanks
> Harsh Bhondwe
> Hughes Software Systems
>
>
>
>
>
>
>
> 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.
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip

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



From mailnull@www1.ietf.org  Tue Oct 29 00:27:22 2002
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 AAA11529
	for <sip-archive@odin.ietf.org>; Tue, 29 Oct 2002 00:27:22 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9T5TNx09677
	for sip-archive@odin.ietf.org; Tue, 29 Oct 2002 00:29:23 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9T5Suv09589;
	Tue, 29 Oct 2002 00: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 g9T5KXv09227
	for <sip@optimus.ietf.org>; Tue, 29 Oct 2002 00:20:33 -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 AAA11166
	for <sip@ietf.org>; Tue, 29 Oct 2002 00:18:01 -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 g9T5KLot011654;
	Mon, 28 Oct 2002 21:20:21 -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 ABF27849;
	Mon, 28 Oct 2002 21:17:54 -0800 (PST)
Date: Mon, 28 Oct 2002 21:20:55 -0800
Subject: Re: [Sip] FW: New Draft - Suppression of Refer Implicit Subscription
Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v546)
Cc: <sip@ietf.org>
To: "Sriram Parameswar" <sriramkp@attbi.com>
From: Rohan Mahy <rohan@cisco.com>
In-Reply-To: <KEELKLOEMJCHGFFFAINJIECECAAA.sriramkp@attbi.com>
Message-Id: <335C21B4-EAFE-11D6-925C-0003938AF740@cisco.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.546)
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi,

So you are just trading a pair of messages (NOTIFY/481) for an option  
tag in the REFER?  It doesn't seem that compelling to me personally.   
It certainly doesn't follow the generality over efficiency argument.   
Can you elaborate a bit more on your motivations?  The transfer draft  
recommends waiting for NOTIFY for attended transfer for robustness, so  
I'm not convinced there.  As for the "push content" model, I envisioned  
an immediate fetch, with a NOTIFY to deliver the status of that fetch.

thanks,
-rohan


On Monday, October 28, 2002, at 01:00 AM, Sriram Parameswar wrote:

> Hi All,
>
> I have submitted a draft (to SIPPING) that examines the requirements  
> and one
> _potential_ mechanism to suppress the implicit subscription created by  
> the
> REFER method.
>
> Till it appears in the IETF site - please pick up a copy at the site  
> below:
>
> http://home.attbi.com/~sriramkp/draft-parameswar-sipping-norefersub- 
> 00.txt
>
> <abstract>
>    The recipient of the REFER method [1] creates an implicit
>    subscription to the 'refer' event. This subscription causes the  
> REFER
>    recipient to send NOTIFY messages to the sender informing him of the
>    progress of the REFER. This memo provides for the requirements and
>    one potential mechanism to suppress the creation of this implicit
>    subscription, via an option tag - 'norefersub'. This gives the agent
>    sending the REFER control over the creation of the subscription,
>    while being backwards compatible with [1].
> </abstract>
>
> Your comments are highly appreciated.
>
> Regards,
>
> Sriram Parameswar
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip

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



From mailnull@www1.ietf.org  Tue Oct 29 00:32:26 2002
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 AAA11681
	for <sip-archive@odin.ietf.org>; Tue, 29 Oct 2002 00:32:26 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9T5YRk09850
	for sip-archive@odin.ietf.org; Tue, 29 Oct 2002 00:34:27 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9T5Y8v09831;
	Tue, 29 Oct 2002 00:34: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 g9T5X4v09802
	for <sip@optimus.ietf.org>; Tue, 29 Oct 2002 00:33:04 -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 AAA11653
	for <sip@ietf.org>; Tue, 29 Oct 2002 00:30:30 -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 g9T5Fmi28069
	for <sip@ietf.org>; Tue, 29 Oct 2002 10:45:48 +0530
Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 65256C61.001E3BF5 ; Tue, 29 Oct 2002 11:00:14 +0530
X-Lotus-FromDomain: HSSBLR
To: sip@ietf.org
cc: hbhondwe@hss.hns.com
Message-ID: <65256C61.001E3A1C.00@sampark.hss.hns.com>
Date: Tue, 29 Oct 2002 11:00:09 +0530
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: [Sip] draft-ietf-sip-asserted-identity-02.txt: ppi from trusted entity
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>



Hi,

Section 6 does not seem to explicitely specify proxy's behaviour when
p-preferred-identity header is received by a proxy from a trusted entity:

a)preferred identity corresponds to a valid identify known to the proxy for
that user.
-MUST the proxy use this identity or  MAY it ? I assume it MUST.
b)preferred identity does not correspond to a valid identity known to the
proxy for that user.
-Should the proxy behaviour be same as when the entity from which the
header was received is not trusted.


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.


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



From mailnull@www1.ietf.org  Tue Oct 29 02:43:01 2002
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 CAA23990
	for <sip-archive@odin.ietf.org>; Tue, 29 Oct 2002 02:43:01 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9T7j1D26003
	for sip-archive@odin.ietf.org; Tue, 29 Oct 2002 02:45:01 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9T7i3v25917;
	Tue, 29 Oct 2002 02:44: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 g9T7gXv25845
	for <sip@optimus.ietf.org>; Tue, 29 Oct 2002 02:42:33 -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 CAA23931
	for <sip@ietf.org>; Tue, 29 Oct 2002 02:40: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 g9T7gcB21369
	for <sip@ietf.org>; Tue, 29 Oct 2002 09:42:38 +0200 (EET)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5e3bf078b3ac158f23077@esvir03nok.nokia.com>;
 Tue, 29 Oct 2002 09:42:21 +0200
Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 29 Oct 2002 09:42:20 +0200
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 29 Oct 2002 09:42:20 +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: [Sip] "List" Event Template Package: new draft available
Date: Tue, 29 Oct 2002 09:41:54 +0200
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE6F45@esebe019.ntc.nokia.com>
Thread-Topic: [Sip] "List" Event Template Package: new draft available
Thread-Index: AcJ8dFdJVNbFirkWRqyeLzS/hZRTbACqg50Q
To: <adam@dynamicsoft.com>, <sip@ietf.org>
X-OriginalArrivalTime: 29 Oct 2002 07:42:20.0223 (UTC) FILETIME=[B6315CF0:01C27F1E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9T7gXv25846
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit

Is this replacing the presencelist package? And are we expecting a collection package (not template) any time soon?

Regards,
Hisham

> -----Original Message-----
> From: ext Adam Roach [mailto:adam@dynamicsoft.com]
> Sent: Saturday, October 26, 2002 1:12 AM
> To: 'sip@ietf.org'
> Subject: [Sip] "List" Event Template Package: new draft available
> 
> 
> For those of you not following SIMPLE: a while back, we started work
> on a mechanism for conveying presence of several entities 
> with a single
> subscription. At the Yokohama meeting (and in ensuing mailing list
> discussions), we decided that the mechanism would probably be 
> most useful
> if it were generalized to a collection event template package 
> that allows
> for aggregation of any event package, not just presence.
> 
> The resulting i-d describing a template event package for collections
> has now been submitted to the drafts editor. Until a copy appears in
> the archives, you can download a copy from:
> 
> http://pages.sbcglobal.net/roaches/ietf/draft-roach-sip-list-t
> emplate-00.txt
> 
> HTML version also available:
> http://pages.sbcglobal.net/roaches/ietf/draft-roach-sip-list-t
> emplate-00.htm
> l
> 
> This work is still rather rough around the edges, but I think 
> it gives a
> good starting point for discussion.
> 
> /a
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Tue Oct 29 05:50:38 2002
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 FAA27191
	for <sip-archive@odin.ietf.org>; Tue, 29 Oct 2002 05:50:38 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9TAqUE03676
	for sip-archive@odin.ietf.org; Tue, 29 Oct 2002 05:52:30 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9TApmv03650;
	Tue, 29 Oct 2002 05:51: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 g9TAnSv03597
	for <sip@optimus.ietf.org>; Tue, 29 Oct 2002 05:49:28 -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 FAA27161
	for <sip@ietf.org>; Tue, 29 Oct 2002 05:47:05 -0500 (EST)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9TAnQQ1028118;
	Tue, 29 Oct 2002 11:49:26 +0100 (MET)
Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.51])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g9TAnPG3009592;
	Tue, 29 Oct 2002 12:49:25 +0200 (EET)
Message-ID: <3DBE67B4.B89BCC65@lmf.ericsson.se>
Date: Tue, 29 Oct 2002 12:49:24 +0200
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: hisham.khartabil@nokia.com
CC: sip@ietf.org
Subject: Re: [Sip] Comments on draft-ietf-sip-compression-01.txt
References: <2038BCC78B1AD641891A0D1AE133DBB7C20671@esebe019.ntc.nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hisham,

> Well, why doesn't the draft say that? I was only guessing what those 2 paragraphs where trying to achieve. 

I will add some explanatory language to the draft. I will clarify that
those paragraphs deal with assymetric compression avoidance. Thanks for
the comment.

I will also add some text about the double-Record-routing mechanism that
Dean came up with.

Depending on the conclusion of the discussion about the SIP/SDP
dictionary, I will remove the reference to it. 

I will most likely release the new version of this draft before the I-D
cut-off.

Thanks,

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



From mailnull@www1.ietf.org  Tue Oct 29 06:29:00 2002
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 GAA28823
	for <sip-archive@odin.ietf.org>; Tue, 29 Oct 2002 06:29:00 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9TBUrA05722
	for sip-archive@odin.ietf.org; Tue, 29 Oct 2002 06:30:53 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9TBURv05700;
	Tue, 29 Oct 2002 06:30: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 g9TBM6v05153
	for <sip@optimus.ietf.org>; Tue, 29 Oct 2002 06: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 GAA28332;
	Tue, 29 Oct 2002 06:19:42 -0500 (EST)
Message-Id: <200210291119.GAA28332@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Tue, 29 Oct 2002 06:19:42 -0500
Subject: [Sip] I-D ACTION:draft-ietf-sip-join-00.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-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 Protocol Working Group of the IETF.

	Title		: The Session Inititation Protocol (SIP) 'Join' Header
	Author(s)	: R. Mahy, D. Petrie
	Filename	: draft-ietf-sip-join-00.txt
	Pages		: 15
	Date		: 2002-10-28
	
This document defines a new header for use with SIP multi-party
applications and call control.  The Join header is used to logically
join an existing SIP dialog with a new SIP dialog.  This primitive
can be used to enable a variety of features, for example: 'Barge-In',
answering-machine-style 'Message Screening' and 'Call Center
Monitoring'.  Note that definition of these example features is non-
normative.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-join-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-sip-join-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-sip-join-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:	<2002-10-28163654.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-join-00.txt

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

Content-Type: text/plain
Content-ID:	<2002-10-28163654.I-D@ietf.org>

--OtherAccess--

--NextPart--


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



From mailnull@www1.ietf.org  Tue Oct 29 06:40:50 2002
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 GAA29305
	for <sip-archive@odin.ietf.org>; Tue, 29 Oct 2002 06:40:50 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9TBghO06999
	for sip-archive@odin.ietf.org; Tue, 29 Oct 2002 06:42:43 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9TBgKv06970;
	Tue, 29 Oct 2002 06:42: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 g9TBfHv06926
	for <sip@optimus.ietf.org>; Tue, 29 Oct 2002 06:41:17 -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 GAA29277
	for <sip@ietf.org>; Tue, 29 Oct 2002 06:38:53 -0500 (EST)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9TBfEKV006208
	for <sip@ietf.org>; Tue, 29 Oct 2002 12:41:15 +0100 (MET)
Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.51])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g9TBfEG3013047
	for <sip@ietf.org>; Tue, 29 Oct 2002 13:41:14 +0200 (EET)
Message-ID: <3DBE73D9.21959858@lmf.ericsson.se>
Date: Tue, 29 Oct 2002 13:41:13 +0200
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: sip <sip@ietf.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] SIP-SigComp draft
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Folks,

I have just released a new version of the SIP-SigComp draft. Until it
appears in the archives, you can fetch it from:

http://www.cs.columbia.edu/~gonzalo/draft-ietf-sip-compression-02.txt

I have added some text about double Record-Routing (section 6) and some
explanatory text about asymmetric compression avoidance.

I have also removed the informative reference to the SIP/SDP dictionary.

Regards,

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



From mailnull@www1.ietf.org  Tue Oct 29 08:38:40 2002
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 IAA03485
	for <sip-archive@odin.ietf.org>; Tue, 29 Oct 2002 08:38:40 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9TDeXW13379
	for sip-archive@odin.ietf.org; Tue, 29 Oct 2002 08:40:33 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9TDchv13282;
	Tue, 29 Oct 2002 08:38: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 g9TDbBv12991
	for <sip@optimus.ietf.org>; Tue, 29 Oct 2002 08:37:11 -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 IAA03153
	for <sip@ietf.org>; Tue, 29 Oct 2002 08:34:47 -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 g9TDb8Q2015680
	for <sip@ietf.org>; Tue, 29 Oct 2002 14:37:08 +0100 (MET)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <VS6CM524>; Tue, 29 Oct 2002 14:37:08 +0100
Message-ID: <F8EFC4B4A8C016428BC1F589296D4FBF0BBA70@esealnt630.al.sw.ericsson.se>
From: "Vesa Torvinen (LMF)" <Vesa.Torvinen@lmf.ericsson.se>
To: "'sip@ietf.org'" <sip@ietf.org>
Date: Tue, 29 Oct 2002 14:36:59 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sip] SIP Security Agreement draft, version -05
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

Hi,

We have submitted a new version of 'SIP Security Agreement' 
draft. Until it appears in the archives, you can fetch it from:

http://standards.ericsson.net/sip/drafts/draft-ietf-sip-sec-agree-05.txt

Since the version -04, the major changes to the draft has been: 

- The motivational part is partly rewritten 
- The scope is limited to the first-hop negotiation 
- The relationship of the draft to SIPS & DNS processes has been clarified 
- S/MIME has been removed (because it is for end-to-end) 
- A new procedure and syntax for HTTP Digest has been introduced 
- A new IANA controlled namespace for security mechanisms has been added

We have also been asked to list 3gpp specific behaviour that goes beyond 
the standard sec-agree mechanism, see Appendix A. 

The draft is still in IESG security review. 

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



From mailnull@www1.ietf.org  Tue Oct 29 14:58:32 2002
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 OAA22065
	for <sip-archive@odin.ietf.org>; Tue, 29 Oct 2002 14:58:32 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9TK0SH02593
	for sip-archive@odin.ietf.org; Tue, 29 Oct 2002 15:00:28 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9TJwDv02425;
	Tue, 29 Oct 2002 14: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 g9TJuIv02368
	for <sip@optimus.ietf.org>; Tue, 29 Oct 2002 14:56:18 -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 OAA21784
	for <sip@ietf.org>; Tue, 29 Oct 2002 14:53:51 -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 g9TJxaWr020508;
	Tue, 29 Oct 2002 13:59:37 -0600
Received: (from dwillis@localhost)
	by bdsl.greycouncil.com (8.12.5/8.12.5/Submit) id g9TJxUaI020506;
	Tue, 29 Oct 2002 13:59:30 -0600
X-Authentication-Warning: bdsl.greycouncil.com: dwillis set sender to dwillis@dynamicsoft.com using -f
Subject: Re: Re:[Sip] Record-Route, Path, Service Route, and Multi-Homed
	Proxies
From: Dean Willis <dwillis@dynamicsoft.com>
To: y01317@njupt.edu.cn
Cc: "sip@ietf.org" <sip@ietf.org>
In-Reply-To: <200210250421.AAA02616@ietf.org>
References: <200210250421.AAA02616@ietf.org>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) 
Date: 29 Oct 2002 13:59:29 -0600
Message-Id: <1035921569.18814.287.camel@bdsl.greycouncil.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

On Thu, 2002-10-24 at 23:29, feng zhang wrote:
> Hi Dean,
> 
> >This odd thing has two serious implications:
> >
> >1) UA2 cannot sign the route set, because it gets edited by P in the
>     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >response. Consequently, end-to-end protection of the route set can not
> ~~~~~~~~~~ I can not understand this point. If UA2 writes Route:192.168.2.1 in
>            BYE to UA1, the P will not change the Route header, the P only
>            strip this Route header in BYE, and passes it to UA1, NO route
>            set is changed. I dont know why UA2 cannot sign the route set?
>            u say P will edit the route set in response, and can u give me 
>            an example? As I think , UA1 send 200 OK to UA2's BYE , the message
>            200 OK has no Route header, what can P edit this response ?
>            I am really confused. Thanks u very much!
> 
> >be supported by the protocol. We've just broken the openness principle
> >and the end-to-end principle. Oops.
> >
> >2) P must implement special "multihomed" logic. On the request phase, it
> >goes through output interface calculation and writes the output
> >interface into the route. It must then inspect all responses, grep for
> >an input interface, and selectively edit them to reference the correct
> >output interface. This is a CPU drag. 


Assume

UA1------P------UA2

where P is multi-homed. That is, it has an interface with one address
facing UA1, and a different interface with a different interface facing
UA2. There is NO IP level routability between UA1 and UA2.

Assume that the interface facing UA1 is 192.168.2.2 and the interface
facing UA2 is 63.64.250.82 (my house, oddly enough, has this setup)

So, UA1 sends an INVITE to P.
P adds a Record-Route <sip:63.64.250.82;lr> and sends the request on to
UA2. 

UA2 responds with a 200 OK reflecting the Record-Route back.

If P conforms to RFC3261, it must REWRITE the Record-Route header in the
200 Ok to have a value of <sip:192.168.2.2;lr> before passing the 200 OK
back to UA1.

Now, assume that UA2 had "signed" the Record-Route header, attaching it
in a body.

UA1 retrieves the signed body and compares the signed Record-Route with
the Record-Route in the 200 OK header. They don't match. What does this
mean?

--
Dean





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



From mailnull@www1.ietf.org  Tue Oct 29 15:23:37 2002
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 PAA23182
	for <sip-archive@odin.ietf.org>; Tue, 29 Oct 2002 15:23:37 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9TKPXL03991
	for sip-archive@odin.ietf.org; Tue, 29 Oct 2002 15:25:33 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9TK3Av02761;
	Tue, 29 Oct 2002 15: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 g9TK2Av02723
	for <sip@optimus.ietf.org>; Tue, 29 Oct 2002 15:02:10 -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 OAA22137
	for <sip@ietf.org>; Tue, 29 Oct 2002 14:59:43 -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 g9TK5NWr020559;
	Tue, 29 Oct 2002 14:05:24 -0600
Received: (from dwillis@localhost)
	by bdsl.greycouncil.com (8.12.5/8.12.5/Submit) id g9TK5Nla020557;
	Tue, 29 Oct 2002 14:05:23 -0600
X-Authentication-Warning: bdsl.greycouncil.com: dwillis set sender to dwillis@dynamicsoft.com using -f
Subject: Re: [Sip] Congestion safety
From: Dean Willis <dwillis@dynamicsoft.com>
To: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
Cc: sip <sip@ietf.org>, Hisham.Khartabil@nokia.com, bcampbell@dynamicsoft.com
In-Reply-To: <3DBA7D44.C6826669@lmf.ericsson.se>
References: <3DBA7D44.C6826669@lmf.ericsson.se>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) 
Date: 29 Oct 2002 14:05:22 -0600
Message-Id: <1035921922.20472.299.camel@bdsl.greycouncil.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Ok, I think you're saying that providing 

   1) a way to detect not-congestion-safe links 
   2) pacing transmissions over not-congestion-safe 
      links so as to avoid overlap 

are an adequate solution, making

   3) Avoiding fragmentation over not-congestion-safe links 

unnecessarily complex.

Inasmuch as solving message-size issues appears to be intractable, I
concur.

Do we have consensus on this in the WG?

--
Dean


On Sat, 2002-10-26 at 06:32, Gonzalo Camarillo wrote:
> Folks,
> 
> I have been reading the two drafts we have about congestion safety.
> 
> http://www.ietf.org/internet-drafts/draft-khartabil-sip-congestionsafe-ci-01.txt
> 
> and
> 
> http://www.ietf.org/internet-drafts/draft-ietf-sip-congestsafe-00.txt
> 
> 
> I believe that trying to control the pace at which a proxy sends request
> is a good idea. Dean and Ben's draft deals with that.
> 
> In addition to that, both drafts try to deal with SIP message size. I am
> not sure that we want to go down this path. Both drafts propose
> application-layer solutions to this problem. However, the SIP layer can
> only make educated guesses about the size of a SIP message
> "on-the-wire".
> 
> Both drafts decide the maximum application-layer message size based on
> the maximum network-layer packet size (MTU). The problem is that between
> the application layer and the network layer you will have things like
> MIP and IPsec that may increase the size of the message and things like
> SigComp that may reduce it.
> 
> IMO, trying to resolve a problem that only applies to legacy systems
> (any future UA/proxy that handles large messages will implement TCP
> and/or SCTP) by providing only approximate solutions is not a good idea.
> And since any complete solution would be too complex, I would suggest
> that we skip solving this issue. If a legacy system needs to be upgraded
> to be congestion safe, it should implement a simple TCP stack (no TCP
> features are needed) rather than implement UDP tricks.
> 
> I realize that the content indirection mechanism proposed by Hisham
> could be used regardless of the MTU... but that's another story.
> 
> Comments?
> 
> Gonzalo
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 

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



From mailnull@www1.ietf.org  Tue Oct 29 15:46:20 2002
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 PAA24204
	for <sip-archive@odin.ietf.org>; Tue, 29 Oct 2002 15:46:20 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9TKmHf05441
	for sip-archive@odin.ietf.org; Tue, 29 Oct 2002 15:48:17 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9TKMKv03929;
	Tue, 29 Oct 2002 15:22: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 g9TKLUv03900
	for <sip@optimus.ietf.org>; Tue, 29 Oct 2002 15:21:30 -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 PAA23039
	for <sip@ietf.org>; Tue, 29 Oct 2002 15:19:03 -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 g9TKKPpR009636;
	Tue, 29 Oct 2002 15:20:29 -0500 (EST)
Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <S3PQXYXH>; Tue, 29 Oct 2002 14:21:19 -0600
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A642BD@DYN-TX-EXCH-001.dynamicsoft.com>
From: Adam Roach <adam@dynamicsoft.com>
To: "'hisham.khartabil@nokia.com'" <hisham.khartabil@nokia.com>,
        Adam Roach <adam@dynamicsoft.com>, sip@ietf.org
Subject: RE: [Sip] "List" Event Template Package: new draft available
Date: Tue, 29 Oct 2002 14:21:10 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

The discussion we had on the topic (on the SIMPLE list)
ended with what I believe was consensus to go the 
"collection template package" route instead of the
"collection package" route. If you don't think the
topic received enough discussion, I guess you can
try to raise the issue again -- but revisiting items
that we have already acheived consensus on is one of
the surest ways to stall ongoing work.

/a

> -----Original Message-----
> From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]
> Sent: Tuesday, October 29, 2002 1:42
> To: adam@dynamicsoft.com; sip@ietf.org
> Subject: RE: [Sip] "List" Event Template Package: new draft available
> 
> 
> Is this replacing the presencelist package? And are we 
> expecting a collection package (not template) any time soon?
> 
> Regards,
> Hisham
> 
> > -----Original Message-----
> > From: ext Adam Roach [mailto:adam@dynamicsoft.com]
> > Sent: Saturday, October 26, 2002 1:12 AM
> > To: 'sip@ietf.org'
> > Subject: [Sip] "List" Event Template Package: new draft available
> > 
> > 
> > For those of you not following SIMPLE: a while back, we started work
> > on a mechanism for conveying presence of several entities 
> > with a single
> > subscription. At the Yokohama meeting (and in ensuing mailing list
> > discussions), we decided that the mechanism would probably be 
> > most useful
> > if it were generalized to a collection event template package 
> > that allows
> > for aggregation of any event package, not just presence.
> > 
> > The resulting i-d describing a template event package for 
> collections
> > has now been submitted to the drafts editor. Until a copy appears in
> > the archives, you can download a copy from:
> > 
> > http://pages.sbcglobal.net/roaches/ietf/draft-roach-sip-list-t
> > emplate-00.txt
> > 
> > HTML version also available:
> > http://pages.sbcglobal.net/roaches/ietf/draft-roach-sip-list-t
> > emplate-00.htm
> > l
> > 
> > This work is still rather rough around the edges, but I think 
> > it gives a
> > good starting point for discussion.
> > 
> > /a
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip
> > 
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Tue Oct 29 16:29:54 2002
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 QAA26307
	for <sip-archive@odin.ietf.org>; Tue, 29 Oct 2002 16:29:54 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9TLVph07389
	for sip-archive@odin.ietf.org; Tue, 29 Oct 2002 16:31:51 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9TLTwv07336;
	Tue, 29 Oct 2002 16:29: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 g9TLSVv07300
	for <sip@optimus.ietf.org>; Tue, 29 Oct 2002 16:28:31 -0500
Received: from dyn-tx-app-007.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26226
	for <sip@ietf.org>; Tue, 29 Oct 2002 16:26:03 -0500 (EST)
Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1])
	by dyn-tx-app-007.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g9TLSB107962;
	Tue, 29 Oct 2002 15:28:11 -0600
Message-ID: <3DBEFD62.5000908@dynamicsoft.com>
Date: Tue, 29 Oct 2002 15:28:02 -0600
From: Ben Campbell <bcampbell@dynamicsoft.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dean Willis <dwillis@dynamicsoft.com>
CC: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>, sip <sip@ietf.org>,
        Hisham.Khartabil@nokia.com
Subject: Re: [Sip] Congestion safety
References: <3DBA7D44.C6826669@lmf.ericsson.se> <1035921922.20472.299.camel@bdsl.greycouncil.com>
X-Enigmail-Version: 0.65.2.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

I concur.

Dean Willis wrote:
> Ok, I think you're saying that providing 
> 
>    1) a way to detect not-congestion-safe links 
>    2) pacing transmissions over not-congestion-safe 
>       links so as to avoid overlap 
> 
> are an adequate solution, making
> 
>    3) Avoiding fragmentation over not-congestion-safe links 
> 
> unnecessarily complex.
> 
> Inasmuch as solving message-size issues appears to be intractable, I
> concur.
> 
> Do we have consensus on this in the WG?
> 
> --
> Dean
> 
> 
> On Sat, 2002-10-26 at 06:32, Gonzalo Camarillo wrote:
> 
>>Folks,
>>
>>I have been reading the two drafts we have about congestion safety.
>>
>>http://www.ietf.org/internet-drafts/draft-khartabil-sip-congestionsafe-ci-01.txt
>>
>>and
>>
>>http://www.ietf.org/internet-drafts/draft-ietf-sip-congestsafe-00.txt
>>
>>
>>I believe that trying to control the pace at which a proxy sends request
>>is a good idea. Dean and Ben's draft deals with that.
>>
>>In addition to that, both drafts try to deal with SIP message size. I am
>>not sure that we want to go down this path. Both drafts propose
>>application-layer solutions to this problem. However, the SIP layer can
>>only make educated guesses about the size of a SIP message
>>"on-the-wire".
>>
>>Both drafts decide the maximum application-layer message size based on
>>the maximum network-layer packet size (MTU). The problem is that between
>>the application layer and the network layer you will have things like
>>MIP and IPsec that may increase the size of the message and things like
>>SigComp that may reduce it.
>>
>>IMO, trying to resolve a problem that only applies to legacy systems
>>(any future UA/proxy that handles large messages will implement TCP
>>and/or SCTP) by providing only approximate solutions is not a good idea.
>>And since any complete solution would be too complex, I would suggest
>>that we skip solving this issue. If a legacy system needs to be upgraded
>>to be congestion safe, it should implement a simple TCP stack (no TCP
>>features are needed) rather than implement UDP tricks.
>>
>>I realize that the content indirection mechanism proposed by Hisham
>>could be used regardless of the MTU... but that's another story.
>>
>>Comments?
>>
>>Gonzalo
>>_______________________________________________
>>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>This list is for NEW development of the core SIP Protocol
>>Use sip-implementors@cs.columbia.edu for questions on current sip
>>Use sipping@ietf.org for new developments on the application of sip
>>
> 
> 


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



From mailnull@www1.ietf.org  Tue Oct 29 19:13:43 2002
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 TAA02604
	for <sip-archive@odin.ietf.org>; Tue, 29 Oct 2002 19:13:43 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9U0FgV17188
	for sip-archive@odin.ietf.org; Tue, 29 Oct 2002 19:15:42 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9U0FAv17172;
	Tue, 29 Oct 2002 19:15: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 g9TG7Ov21949
	for <sip@optimus.ietf.org>; Tue, 29 Oct 2002 11:07:24 -0500
Received: from sccrmhc03.attbi.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10691
	for <sip@ietf.org>; Tue, 29 Oct 2002 11:04:58 -0500 (EST)
Received: from parameswjq8fwx ([12.237.230.168]) by sccrmhc03.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP
          id <20021029160719.DEUJ25411.sccrmhc03.attbi.com@parameswjq8fwx>;
          Tue, 29 Oct 2002 16:07:19 +0000
From: "Sriram Parameswar" <sriramkp@attbi.com>
To: "Rohan Mahy" <rohan@cisco.com>
Cc: <sip@ietf.org>
Subject: RE: [Sip] FW: New Draft - Suppression of Refer Implicit Subscription
Date: Tue, 29 Oct 2002 10:07:18 -0600
Message-ID: <KEELKLOEMJCHGFFFAINJCECKCAAA.sriramkp@attbi.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 IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <335C21B4-EAFE-11D6-925C-0003938AF740@cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Rohan,

Thank you for your comments. Its not only a question of trading pair of
messages for an option-tag. Implicit subscriptions themselves are
problematic, as has been discussed on this list several times - the memo
provides for a method to suppress them, while being backwardly compatible.
If the UA receiving the REFER does not have to create the state information
for the subscription - then I see that as a distinct advantage

As for content push, there is no guarantee that the fetch happens
instantaneously - there could be the need for human interaction before that
happens. As for the attended transfer case, admittedly its a weaker example,
but in an enterprise setting - say between an employee, boss and secretary -
I see no need for the creation of additional messaging.

HTH,

Sriram

-----Original Message-----
From: Rohan Mahy [mailto:rohan@cisco.com]
Sent: Monday, October 28, 2002 11:21 PM
To: Sriram Parameswar
Cc: sip@ietf.org
Subject: Re: [Sip] FW: New Draft - Suppression of Refer Implicit
Subscription


Hi,

So you are just trading a pair of messages (NOTIFY/481) for an option
tag in the REFER?  It doesn't seem that compelling to me personally.
It certainly doesn't follow the generality over efficiency argument.
Can you elaborate a bit more on your motivations?  The transfer draft
recommends waiting for NOTIFY for attended transfer for robustness, so
I'm not convinced there.  As for the "push content" model, I envisioned
an immediate fetch, with a NOTIFY to deliver the status of that fetch.

thanks,
-rohan


On Monday, October 28, 2002, at 01:00 AM, Sriram Parameswar wrote:

> Hi All,
>
> I have submitted a draft (to SIPPING) that examines the requirements
> and one
> _potential_ mechanism to suppress the implicit subscription created by
> the
> REFER method.
>
> Till it appears in the IETF site - please pick up a copy at the site
> below:
>
> http://home.attbi.com/~sriramkp/draft-parameswar-sipping-norefersub-
> 00.txt
>
> <abstract>
>    The recipient of the REFER method [1] creates an implicit
>    subscription to the 'refer' event. This subscription causes the
> REFER
>    recipient to send NOTIFY messages to the sender informing him of the
>    progress of the REFER. This memo provides for the requirements and
>    one potential mechanism to suppress the creation of this implicit
>    subscription, via an option tag - 'norefersub'. This gives the agent
>    sending the REFER control over the creation of the subscription,
>    while being backwards compatible with [1].
> </abstract>
>
> Your comments are highly appreciated.
>
> Regards,
>
> Sriram Parameswar
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip

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



From mailnull@www1.ietf.org  Wed Oct 30 02:45:06 2002
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 CAA04844
	for <sip-archive@odin.ietf.org>; Wed, 30 Oct 2002 02:45:06 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9U7l7o15136
	for sip-archive@odin.ietf.org; Wed, 30 Oct 2002 02:47:07 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9U7kSv15113;
	Wed, 30 Oct 2002 02:46: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 g9U7iHv15030
	for <sip@optimus.ietf.org>; Wed, 30 Oct 2002 02:44:17 -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 CAA04830
	for <sip@ietf.org>; Wed, 30 Oct 2002 02:41:42 -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 g9U7iOB04645
	for <sip@ietf.org>; Wed, 30 Oct 2002 09:44:24 +0200 (EET)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5e411868e2ac158f24077@esvir04nok.ntc.nokia.com>;
 Wed, 30 Oct 2002 09:44:04 +0200
Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 30 Oct 2002 09:44:04 +0200
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 30 Oct 2002 09:44:03 +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: [Sip] "List" Event Template Package: new draft available
Date: Wed, 30 Oct 2002 09:44:03 +0200
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE6F51@esebe019.ntc.nokia.com>
Thread-Topic: [Sip] "List" Event Template Package: new draft available
Thread-Index: AcJ/iRwcO0WWjUtrQo6l+9ED4wDWXAAXljVg
To: <adam@dynamicsoft.com>, <sip@ietf.org>
X-OriginalArrivalTime: 30 Oct 2002 07:44:03.0855 (UTC) FILETIME=[1E6019F0:01C27FE8]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9U7iHv15031
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit

I know and I agree. I was just asking if the draft you presented is it (since the event name "collection" was not used). I also wanted to know if it will replace the presencelist package. No stalling, just recap.

I guess the answer to both questions is yes.

Regards,
Hisham

> -----Original Message-----
> From: ext Adam Roach [mailto:adam@dynamicsoft.com]
> Sent: Tuesday, October 29, 2002 10:21 PM
> To: Khartabil Hisham (NMP/Helsinki); Adam Roach; sip@ietf.org
> Subject: RE: [Sip] "List" Event Template Package: new draft available
> 
> 
> The discussion we had on the topic (on the SIMPLE list)
> ended with what I believe was consensus to go the 
> "collection template package" route instead of the
> "collection package" route. If you don't think the
> topic received enough discussion, I guess you can
> try to raise the issue again -- but revisiting items
> that we have already acheived consensus on is one of
> the surest ways to stall ongoing work.
> 
> /a
> 
> > -----Original Message-----
> > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]
> > Sent: Tuesday, October 29, 2002 1:42
> > To: adam@dynamicsoft.com; sip@ietf.org
> > Subject: RE: [Sip] "List" Event Template Package: new draft 
> available
> > 
> > 
> > Is this replacing the presencelist package? And are we 
> > expecting a collection package (not template) any time soon?
> > 
> > Regards,
> > Hisham
> > 
> > > -----Original Message-----
> > > From: ext Adam Roach [mailto:adam@dynamicsoft.com]
> > > Sent: Saturday, October 26, 2002 1:12 AM
> > > To: 'sip@ietf.org'
> > > Subject: [Sip] "List" Event Template Package: new draft available
> > > 
> > > 
> > > For those of you not following SIMPLE: a while back, we 
> started work
> > > on a mechanism for conveying presence of several entities 
> > > with a single
> > > subscription. At the Yokohama meeting (and in ensuing mailing list
> > > discussions), we decided that the mechanism would probably be 
> > > most useful
> > > if it were generalized to a collection event template package 
> > > that allows
> > > for aggregation of any event package, not just presence.
> > > 
> > > The resulting i-d describing a template event package for 
> > collections
> > > has now been submitted to the drafts editor. Until a copy 
> appears in
> > > the archives, you can download a copy from:
> > > 
> > > http://pages.sbcglobal.net/roaches/ietf/draft-roach-sip-list-t
> > > emplate-00.txt
> > > 
> > > HTML version also available:
> > > http://pages.sbcglobal.net/roaches/ietf/draft-roach-sip-list-t
> > > emplate-00.htm
> > > l
> > > 
> > > This work is still rather rough around the edges, but I think 
> > > it gives a
> > > good starting point for discussion.
> > > 
> > > /a
> > > _______________________________________________
> > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > This list is for NEW development of the core SIP Protocol
> > > Use sip-implementors@cs.columbia.edu for questions on current sip
> > > Use sipping@ietf.org for new developments on the 
> application of sip
> > > 
> > 
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Wed Oct 30 02:59:57 2002
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 CAA05068
	for <sip-archive@odin.ietf.org>; Wed, 30 Oct 2002 02:59:57 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9U81xG15756
	for sip-archive@odin.ietf.org; Wed, 30 Oct 2002 03:01:59 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9U81Wv15709;
	Wed, 30 Oct 2002 03:01: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 g9U80ev15648
	for <sip@optimus.ietf.org>; Wed, 30 Oct 2002 03:00:40 -0500
Received: from web40006.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA05032
	for <sip@ietf.org>; Wed, 30 Oct 2002 02:58:08 -0500 (EST)
Message-ID: <20021030080029.41042.qmail@web40006.mail.yahoo.com>
Received: from [192.100.124.218] by web40006.mail.yahoo.com via HTTP; Wed, 30 Oct 2002 00:00:29 PST
Date: Wed, 30 Oct 2002 00:00:29 -0800 (PST)
From: Cristian Negresco <cristian_negresco@yahoo.com>
To: sip@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [Sip] NOTIFY bevahior
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

Hello,

SUBSCRIBE request is answered with 200 response and
the notifier immediately sends NOTIFY request to the
subscriber.

Problem is that NOTIFY could arrive at the subscriber
before 200 OK, case in which I assume the subscriber
will give a non-200 OK to the NOTIFY and the
subscription will be cancelled.

Should the proxy implement a mechanism to assure that
200-ok is the first to arrive to the subscriber? 

Thank you for your help.
Cristian


__________________________________________________
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Wed Oct 30 03:13:46 2002
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 DAA05301
	for <sip-archive@odin.ietf.org>; Wed, 30 Oct 2002 03:13:46 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9U8Fms17015
	for sip-archive@odin.ietf.org; Wed, 30 Oct 2002 03:15:48 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9U8FNv16971;
	Wed, 30 Oct 2002 03:15: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 g9U4XIv28872
	for <sip@optimus.ietf.org>; Tue, 29 Oct 2002 23:33:18 -0500
Received: from webmail32.rediffmail.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA07553
	for <sip@ietf.org>; Tue, 29 Oct 2002 23:30:46 -0500 (EST)
Received: (qmail 18161 invoked by uid 510); 30 Oct 2002 04:36:18 -0000
Date: 30 Oct 2002 04:36:18 -0000
Message-ID: <20021030043618.18160.qmail@webmail32.rediffmail.com>
Received: from unknown (61.11.48.130) by rediffmail.com via HTTP; 30 oct 2002 04:36:18 -0000
MIME-Version: 1.0
From: "chalapathi  rao" <damerla_cp@rediffmail.com>
Reply-To: "chalapathi  rao" <damerla_cp@rediffmail.com>
To: sip@ietf.org
Content-type: text/plain;
	format=flowed
Content-Disposition: inline
Subject: [Sip] sip faq
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

hi,
we are about to start sip stack implementation,
right now i don't have any idea of testing
the stack.please let me know any server is
providing sip testing facility at free of cost

thanks in advance
chalapthi



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



From mailnull@www1.ietf.org  Wed Oct 30 03:13:47 2002
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 DAA05309
	for <sip-archive@odin.ietf.org>; Wed, 30 Oct 2002 03:13:46 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9U8Fme17027
	for sip-archive@odin.ietf.org; Wed, 30 Oct 2002 03:15:48 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9U8FXv16992;
	Wed, 30 Oct 2002 03:15: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 g9U7pOv15295
	for <sip@optimus.ietf.org>; Wed, 30 Oct 2002 02:51:24 -0500
Received: from web40005.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA04919
	for <sip@ietf.org>; Wed, 30 Oct 2002 02:48:51 -0500 (EST)
Message-ID: <20021030075112.30590.qmail@web40005.mail.yahoo.com>
Received: from [192.100.124.218] by web40005.mail.yahoo.com via HTTP; Tue, 29 Oct 2002 23:51:12 PST
Date: Tue, 29 Oct 2002 23:51:12 -0800 (PST)
From: Cristian Popa <cristian_negresco@yahoo.com>
To: sip@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [Sip] NOTIFY
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

Hello,

SUBSCRIBE request is answered with 200 response and
the notifier immediately sends NOTIFY request to the
subscriber.

Problem is that NOTIFY could arrive at the subscriber
before 200 OK, case in which I assume the subscriber
will give a non-200 OK to the NOTIFY and the
subscription will be cancelled.

Should the proxy implement a mechanism to assure that
200-ok is the first to arrive to the subscriber? 

Thank you for your help.
Cristian

__________________________________________________
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Wed Oct 30 03:51:20 2002
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 DAA05975
	for <sip-archive@odin.ietf.org>; Wed, 30 Oct 2002 03:51:19 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9U8rM118758
	for sip-archive@odin.ietf.org; Wed, 30 Oct 2002 03:53:22 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9U8qrv18743;
	Wed, 30 Oct 2002 03:52: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 g9U8ppv18709
	for <sip@optimus.ietf.org>; Wed, 30 Oct 2002 03:51:51 -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 DAA05925
	for <sip@ietf.org>; Wed, 30 Oct 2002 03:49:18 -0500 (EST)
From: mikko.lonnfors@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 g9U8pFb00441
	for <sip@ietf.org>; Wed, 30 Oct 2002 10:51:16 +0200 (EET)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5e4156442aac158f21082@esvir01nok.ntc.nokia.com>;
 Wed, 30 Oct 2002 10:51:38 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 30 Oct 2002 10:51:38 +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: [Sip] NOTIFY
Date: Wed, 30 Oct 2002 10:51:37 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF10415F@esebe004.ntc.nokia.com>
Thread-Topic: [Sip] NOTIFY
Thread-Index: AcJ/7jV5QDCGZ+C6QOqRz8xTzf63XgAAU/MQ
To: <cristian_negresco@yahoo.com>, <sip@ietf.org>
X-OriginalArrivalTime: 30 Oct 2002 08:51:38.0371 (UTC) FILETIME=[8F0E2530:01C27FF1]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9U8ppv18710
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit

Hi,

Inline

> -----Original Message-----
> From: ext Cristian Popa [mailto:cristian_negresco@yahoo.com]
> Sent: 30 October, 2002 09:51
> To: sip@ietf.org
> Subject: [Sip] NOTIFY
> 
> 
> Hello,
> 
> SUBSCRIBE request is answered with 200 response and
> the notifier immediately sends NOTIFY request to the
> subscriber.

yes

> Problem is that NOTIFY could arrive at the subscriber
> before 200 OK, case in which I assume the subscriber
> will give a non-200 OK to the NOTIFY and the
> subscription will be cancelled.

UAs must be prepared to accept NOTIFY message before subscription transaction has completed. This behavior is described in RFC3265. See sections 3.1.4.4 and 3.2.4.

> Should the proxy implement a mechanism to assure that
> 200-ok is the first to arrive to the subscriber? 

No. This is not needed. 

Best Regards
- Mikko

> Thank you for your help.
> Cristian
> 
> __________________________________________________
> Do you Yahoo!?
> HotJobs - Search new jobs daily now
> http://hotjobs.yahoo.com/
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Wed Oct 30 06:27:21 2002
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 GAA09582
	for <sip-archive@odin.ietf.org>; Wed, 30 Oct 2002 06:27:21 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9UBTEY27229
	for sip-archive@odin.ietf.org; Wed, 30 Oct 2002 06:29:14 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UBPVv27015;
	Wed, 30 Oct 2002 06:25: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 g9UBLZv26713
	for <sip@optimus.ietf.org>; Wed, 30 Oct 2002 06:21:35 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09051;
	Wed, 30 Oct 2002 06:19:11 -0500 (EST)
Message-Id: <200210301119.GAA09051@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 30 Oct 2002 06:19:11 -0500
Subject: [Sip] I-D ACTION:draft-peterson-sip-smime-aes-00.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

--NextPart

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


	Title		: S/MIME AES Requirement for SIP
	Author(s)	: J. Peterson
	Filename	: draft-peterson-sip-smime-aes-00.txt
	Pages		: 11
	Date		: 2002-10-29
	
RFC3261 currently specifies 3DES as the required minimum ciphersuite
for implementations of S/MIME in SIP.  This document updates the
normative guidance of RFC3261 to require the Advanced Encryption
Standard (AES) for S/MIME.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-peterson-sip-smime-aes-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-peterson-sip-smime-aes-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-peterson-sip-smime-aes-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:	<2002-10-29130312.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-peterson-sip-smime-aes-00.txt

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

Content-Type: text/plain
Content-ID:	<2002-10-29130312.I-D@ietf.org>

--OtherAccess--

--NextPart--


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



From mailnull@www1.ietf.org  Wed Oct 30 07:44:53 2002
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 HAA12091
	for <sip-archive@odin.ietf.org>; Wed, 30 Oct 2002 07:44:52 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9UCkl632198
	for sip-archive@odin.ietf.org; Wed, 30 Oct 2002 07:46:47 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UCgwv32026;
	Wed, 30 Oct 2002 07:42: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 g9UCfWv31976
	for <sip@optimus.ietf.org>; Wed, 30 Oct 2002 07:41:32 -0500
Received: from cms3.etri.re.kr (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11843
	for <sip@ietf.org>; Wed, 30 Oct 2002 07:39:05 -0500 (EST)
From: hspark@etri.re.kr
Received: by cms3.etri.re.kr with Internet Mail Service (5.5.2653.19)
	id <VZPY2FW9>; Wed, 30 Oct 2002 21:38:51 +0900
Message-ID: <8470181DABD5D511B3E700D0B7A8AC4A455B1B@cms3.etri.re.kr>
To: sip@ietf.org
Date: Wed, 30 Oct 2002 21:38:48 +0900
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C28011.4B600AE0"
Subject: [Sip] Registration Event Package vs. DEREGISTER method
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-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_01C28011.4B600AE0
Content-Type: text/plain;
	charset="KS_C_5601-1987"

Hello,

How do you think about defining new method for deregistration, namely
"DEREGISTER" ?

IMHO, I think we need not subscription to Registration event package right
after registration.

Is it reasonable and possible ?

Thanks in advance for your comment.

Brad



------_=_NextPart_001_01C28011.4B600AE0
Content-Type: text/html;
	charset="KS_C_5601-1987"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=KS_C_5601-1987">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>Registration Event Package vs. DEREGISTER method</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2 FACE="Arial">Hello,</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">How do you think about defining new method for deregistration, namely &quot;DEREGISTER&quot; ?</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">IMHO, I think we need not subscription to Registration event package right after registration.</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">Is it reasonable and possible ?</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">Thanks in advance for your comment.</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">Brad</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C28011.4B600AE0--
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Wed Oct 30 08:21:23 2002
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 IAA13642
	for <sip-archive@odin.ietf.org>; Wed, 30 Oct 2002 08:21:23 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9UDNIU01835
	for sip-archive@odin.ietf.org; Wed, 30 Oct 2002 08:23:18 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UDMmv01779;
	Wed, 30 Oct 2002 08:22: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 g9UDLqv01725
	for <sip@optimus.ietf.org>; Wed, 30 Oct 2002 08:21:52 -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 IAA13584
	for <sip@ietf.org>; Wed, 30 Oct 2002 08:19:26 -0500 (EST)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9UDLmQ1020093
	for <sip@ietf.org>; Wed, 30 Oct 2002 14:21:48 +0100 (MET)
Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.112])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g9UDLmG3027428
	for <sip@ietf.org>; Wed, 30 Oct 2002 15:21:48 +0200 (EET)
Message-ID: <3DBFDCEC.4ED2443E@lmf.ericsson.se>
Date: Wed, 30 Oct 2002 15:21:49 +0200
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: sip@ietf.org
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] SIPS question
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit


Hi,

The RFC says that if the INVITE Contact header contained a SIPS-URI, the
200 Contact header must also contain a SIPS-URI.

However, I can't find anywhere said if it's allowed  to put a SIPS-URI
in the 200 Contact header if the INVITE Contact header contained a
SIP-URI. Don't know if it would make much sense, but still...

Regards,

Christer Holmberg
Ericsson Finland

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



From mailnull@www1.ietf.org  Wed Oct 30 09:50:49 2002
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 JAA17298
	for <sip-archive@odin.ietf.org>; Wed, 30 Oct 2002 09:50:49 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9UEqhR07705
	for sip-archive@odin.ietf.org; Wed, 30 Oct 2002 09:52:43 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UEpvv07625;
	Wed, 30 Oct 2002 09:51: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 g9UEoJv07545
	for <sip@optimus.ietf.org>; Wed, 30 Oct 2002 09:50:19 -0500
Received: from magus.nostrum.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17078
	for <sip@ietf.org>; Wed, 30 Oct 2002 09:47:53 -0500 (EST)
Received: from dynamicsoft.com (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g9UEoEpA047478;
	Wed, 30 Oct 2002 08:50:15 -0600 (CST)
Message-ID: <3DBFF19D.5010609@dynamicsoft.com>
Date: Wed, 30 Oct 2002 08:50:05 -0600
From: Ben Campbell <bcampbell@dynamicsoft.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Cristian Negresco <cristian_negresco@yahoo.com>
CC: sip@ietf.org
Subject: Re: [Sip] NOTIFY bevahior
References: <20021030080029.41042.qmail@web40006.mail.yahoo.com>
X-Enigmail-Version: 0.65.2.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Cristian Negresco wrote:
> Hello,
> 
> SUBSCRIBE request is answered with 200 response and
> the notifier immediately sends NOTIFY request to the
> subscriber.
> 
> Problem is that NOTIFY could arrive at the subscriber
> before 200 OK, case in which I assume the subscriber
> will give a non-200 OK to the NOTIFY and the
> subscription will be cancelled.

No, the subscriber accepts the NOTIFY and creates a dialog (if one did 
not already exist.) RFC3265 explitly deals with this scenario.

> 
> Should the proxy implement a mechanism to assure that
> 200-ok is the first to arrive to the subscriber? 
> 

No, it is not necessary.

Thanks!

Ben.

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



From mailnull@www1.ietf.org  Wed Oct 30 10:36:03 2002
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 KAA20382
	for <sip-archive@odin.ietf.org>; Wed, 30 Oct 2002 10:36:02 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9UFbvY11069
	for sip-archive@odin.ietf.org; Wed, 30 Oct 2002 10:37:57 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UFbVv11050;
	Wed, 30 Oct 2002 10:37: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 g9UFaRv10407
	for <sip@optimus.ietf.org>; Wed, 30 Oct 2002 10:36:27 -0500
Received: from uni02du.unity.ncsu.edu (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20120
	for <sip@ietf.org>; Wed, 30 Oct 2002 10:34:01 -0500 (EST)
Received: (from prsinha@localhost)
          by uni02du.unity.ncsu.edu (8.8.4/EC02Jan97)
	  id KAA09846; Wed, 30 Oct 2002 10:36:21 -0500 (EST)
Date: Wed, 30 Oct 2002 10:36:21 -0500 (EST)
From: Prabhas Ranjan Sinha <prsinha@unity.ncsu.edu>
To: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
cc: sip@ietf.org
Subject: Re: [Sip] SIPS question
In-Reply-To: <3DBFDCEC.4ED2443E@lmf.ericsson.se>
Message-ID: <Pine.GSO.4.44.0210301034070.9717-100000@uni02du.unity.ncsu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>


Chris,
If it is just a SIP-URI in INVITE, then why do we need to put SIPS-URI in
the 200 response ?
I would assume that the invitor doesnt need the transaction to be secured
so why a secured response ?

Prabhas

On Wed, 30 Oct 2002, Christer Holmberg wrote:

>
> Hi,
>
> The RFC says that if the INVITE Contact header contained a SIPS-URI, the
> 200 Contact header must also contain a SIPS-URI.
>
> However, I can't find anywhere said if it's allowed  to put a SIPS-URI
> in the 200 Contact header if the INVITE Contact header contained a
> SIP-URI. Don't know if it would make much sense, but still...
>
> Regards,
>
> Christer Holmberg
> Ericsson Finland
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>

Prabhas
+++++++++++++
CSEL Technology Enterprise Programme
London Business School
Baker Street, London NW1 6DD
*****************************************
There is no wisdom greater than kindness.
*****************************************

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



From mailnull@www1.ietf.org  Wed Oct 30 11:21:15 2002
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 LAA23023
	for <sip-archive@odin.ietf.org>; Wed, 30 Oct 2002 11:21:15 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9UGNB214230
	for sip-archive@odin.ietf.org; Wed, 30 Oct 2002 11:23:11 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UGMXv14144;
	Wed, 30 Oct 2002 11:22: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 g9UGLBv14050
	for <sip@optimus.ietf.org>; Wed, 30 Oct 2002 11:21:11 -0500
Received: from oak.neustar.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22836
	for <sip@ietf.org>; Wed, 30 Oct 2002 11:18:44 -0500 (EST)
Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11])
	by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g9UGL2b18856;
	Wed, 30 Oct 2002 16:21:02 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19)
	id <VLY1KDS3>; Wed, 30 Oct 2002 11:21:37 -0500
Message-ID: <15A2739B7DAA624D8091C65981D7DA815EB340@stntexch2.va.neustar.com>
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: "'Christer Holmberg'" <christer.holmberg@lmf.ericsson.se>, sip@ietf.org
Subject: RE: [Sip] SIPS question
Date: Wed, 30 Oct 2002 11:21:26 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>


I agree that I don't see any immediate use for this, but I also don't see
any danger that would mandate forbidding it. Was there anything you had in
mind?

Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se]
Sent: Wednesday, October 30, 2002 5:22 AM
To: sip@ietf.org
Subject: [Sip] SIPS question



Hi,

The RFC says that if the INVITE Contact header contained a SIPS-URI, the
200 Contact header must also contain a SIPS-URI.

However, I can't find anywhere said if it's allowed  to put a SIPS-URI
in the 200 Contact header if the INVITE Contact header contained a
SIP-URI. Don't know if it would make much sense, but still...

Regards,

Christer Holmberg
Ericsson Finland

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



From mailnull@www1.ietf.org  Wed Oct 30 11:35:56 2002
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 LAA23728
	for <sip-archive@odin.ietf.org>; Wed, 30 Oct 2002 11:35:56 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9UGbqb15480
	for sip-archive@odin.ietf.org; Wed, 30 Oct 2002 11:37:52 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UGbLv15303;
	Wed, 30 Oct 2002 11: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 g9UGY6v14734
	for <sip@optimus.ietf.org>; Wed, 30 Oct 2002 11:34:06 -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 LAA23504
	for <sip@ietf.org>; Wed, 30 Oct 2002 11:31:39 -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 g9UGX7pR014111;
	Wed, 30 Oct 2002 11:33:07 -0500 (EST)
Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <S3PQXY7K>; Wed, 30 Oct 2002 10:34:00 -0600
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A642C8@DYN-TX-EXCH-001.dynamicsoft.com>
From: Adam Roach <adam@dynamicsoft.com>
To: "'hisham.khartabil@nokia.com'" <hisham.khartabil@nokia.com>,
        Adam Roach <adam@dynamicsoft.com>, sip@ietf.org
Subject: RE: [Sip] "List" Event Template Package: new draft available
Date: Wed, 30 Oct 2002 10:33:59 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

> -----Original Message-----
> From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]
> 
> I know and I agree. I was just asking if the draft you 
> presented is it (since the event name "collection" was not 
> used). 

More or less, yes. There are still a lot of open issues about the
details (e.g. we will probably be moving the meta-information
from the preamble into a separate body part), but the intention
of this draft is to take us in the direction of the final solution.

I chose "list" over "collection" as a name simply because it's much
shorter.

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



From mailnull@www1.ietf.org  Wed Oct 30 13:09:36 2002
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 NAA00220
	for <sip-archive@odin.ietf.org>; Wed, 30 Oct 2002 13:09:36 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9UIBXh23035
	for sip-archive@odin.ietf.org; Wed, 30 Oct 2002 13:11:33 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UIB4v23000;
	Wed, 30 Oct 2002 13:11: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 g9UI9Fv22927
	for <sip@optimus.ietf.org>; Wed, 30 Oct 2002 13:09:15 -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 NAA00026
	for <sip@ietf.org>; Wed, 30 Oct 2002 13:06:46 -0500 (EST)
Received: from zwcwc012.europe.nortel.com ([47.160.46.124])
	by znsgs01r.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9UDhnX27922;
	Wed, 30 Oct 2002 13:43:49 GMT
Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19)
	id <V5JAT054>; Wed, 30 Oct 2002 13:43:50 -0000
Message-ID: <A3C2399B2FACD411A54200508BE39C74054F7887@zwcwd00r.europe.nortel.com>
From: "Mark Watson" <mwatson@nortelnetworks.com>
To: "'hbhondwe@hss.hns.com'" <hbhondwe@hss.hns.com>, sip@ietf.org
Subject: RE: [Sip] draft-ietf-sip-asserted-identity-02.txt: ppi from trust
	ed entity
Date: Wed, 30 Oct 2002 13:43:39 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2801A.5AB21340"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-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_01C2801A.5AB21340
Content-Type: text/plain;
	charset="iso-8859-1"

Harsh,

From memory, a proxy should not expect to receive P-Preferred-Identity from
another member of the Trust Domain for Asserted Identity.

You may be right that the behaviour if it is received is not specified. If a
P-Asserted-Identity is present, then I would expect the P-Preferred-Identity
to be discarded (they should not coexist). If there is no
P-Asserted-Identity, then I suppose the Proxy could behave as if the message
were received from outside the Trust Domain...

If P-Preferred-Identity is received from outside the Trust Domain, the proxy
attempts to authenticate the originator of the message.

You ask whether the proxy MAY or MUST use the P-Preferred-Identity, but I'm
not sure the question makes sense. If it were a MAY, then whether to use it
or not must be a matter of local policy for the proxy. If it were a MUST,
then as long as the P-Preferred-Identity is 'a valid identity for that user'
then it MUST use it. But the list of 'valid identities for that user' is a
matter of local policy too. So there is no difference.

For example, if the proxy NEVER uses P-Preferred-Identity, then this is
equivalent to saying that there is only one valid identity for the user.

Regards,

Mark Watson
 

> -----Original Message-----
> From: hbhondwe@hss.hns.com [mailto:hbhondwe@hss.hns.com]
> Sent: 29 October 2002 05:30
> To: sip@ietf.org
> Cc: hbhondwe@hss.hns.com
> Subject: [Sip] draft-ietf-sip-asserted-identity-02.txt: ppi 
> from trusted
> entity
> 
> 
> 
> 
> Hi,
> 
> Section 6 does not seem to explicitely specify proxy's behaviour when
> p-preferred-identity header is received by a proxy from a 
> trusted entity:
> 
> a)preferred identity corresponds to a valid identify known to 
> the proxy for
> that user.
> -MUST the proxy use this identity or  MAY it ? I assume it MUST.
> b)preferred identity does not correspond to a valid identity 
> known to the
> proxy for that user.
> -Should the proxy behaviour be same as when the entity from which the
> header was received is not trusted.
> 
> 
> 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.
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 

------_=_NextPart_001_01C2801A.5AB21340
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: [Sip] draft-ietf-sip-asserted-identity-02.txt: ppi from =
trusted entity</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Harsh,</FONT>
</P>

<P><FONT SIZE=3D2>From memory, a proxy should not expect to receive =
P-Preferred-Identity from another member of the Trust Domain for =
Asserted Identity.</FONT></P>

<P><FONT SIZE=3D2>You may be right that the behaviour if it is received =
is not specified. If a P-Asserted-Identity is present, then I would =
expect the P-Preferred-Identity to be discarded (they should not =
coexist). If there is no P-Asserted-Identity, then I suppose the Proxy =
could behave as if the message were received from outside the Trust =
Domain...</FONT></P>

<P><FONT SIZE=3D2>If P-Preferred-Identity is received from outside the =
Trust Domain, the proxy attempts to authenticate the originator of the =
message.</FONT></P>

<P><FONT SIZE=3D2>You ask whether the proxy MAY or MUST use the =
P-Preferred-Identity, but I'm not sure the question makes sense. If it =
were a MAY, then whether to use it or not must be a matter of local =
policy for the proxy. If it were a MUST, then as long as the =
P-Preferred-Identity is 'a valid identity for that user' then it MUST =
use it. But the list of 'valid identities for that user' is a matter of =
local policy too. So there is no difference.</FONT></P>

<P><FONT SIZE=3D2>For example, if the proxy NEVER uses =
P-Preferred-Identity, then this is equivalent to saying that there is =
only one valid identity for the user.</FONT></P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>Mark Watson</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: hbhondwe@hss.hns.com [<A =
HREF=3D"mailto:hbhondwe@hss.hns.com">mailto:hbhondwe@hss.hns.com</A>]</F=
ONT>
<BR><FONT SIZE=3D2>&gt; Sent: 29 October 2002 05:30</FONT>
<BR><FONT SIZE=3D2>&gt; To: sip@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: hbhondwe@hss.hns.com</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: [Sip] =
draft-ietf-sip-asserted-identity-02.txt: ppi </FONT>
<BR><FONT SIZE=3D2>&gt; from trusted</FONT>
<BR><FONT SIZE=3D2>&gt; entity</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hi,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Section 6 does not seem to explicitely specify =
proxy's behaviour when</FONT>
<BR><FONT SIZE=3D2>&gt; p-preferred-identity header is received by a =
proxy from a </FONT>
<BR><FONT SIZE=3D2>&gt; trusted entity:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; a)preferred identity corresponds to a valid =
identify known to </FONT>
<BR><FONT SIZE=3D2>&gt; the proxy for</FONT>
<BR><FONT SIZE=3D2>&gt; that user.</FONT>
<BR><FONT SIZE=3D2>&gt; -MUST the proxy use this identity or&nbsp; MAY =
it ? I assume it MUST.</FONT>
<BR><FONT SIZE=3D2>&gt; b)preferred identity does not correspond to a =
valid identity </FONT>
<BR><FONT SIZE=3D2>&gt; known to the</FONT>
<BR><FONT SIZE=3D2>&gt; proxy for that user.</FONT>
<BR><FONT SIZE=3D2>&gt; -Should the proxy behaviour be same as when the =
entity from which the</FONT>
<BR><FONT SIZE=3D2>&gt; header was received is not trusted.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; thanks</FONT>
<BR><FONT SIZE=3D2>&gt; harsh</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; This message is proprietary to Hughes Software =
Systems </FONT>
<BR><FONT SIZE=3D2>&gt; Limited (HSS) and is</FONT>
<BR><FONT SIZE=3D2>&gt; intended solely for the use of the individual =
to whom it is </FONT>
<BR><FONT SIZE=3D2>&gt; addressed.&nbsp; It</FONT>
<BR><FONT SIZE=3D2>&gt; may contain privileged or confidential =
information and should not be</FONT>
<BR><FONT SIZE=3D2>&gt; circulated or used for any purpose other than =
for what it is </FONT>
<BR><FONT SIZE=3D2>&gt; intended.&nbsp; If</FONT>
<BR><FONT SIZE=3D2>&gt; you have received this message in error, please =
notify the originator</FONT>
<BR><FONT SIZE=3D2>&gt; immediately.&nbsp; If you are not the intended =
recipient, you are </FONT>
<BR><FONT SIZE=3D2>&gt; notified that</FONT>
<BR><FONT SIZE=3D2>&gt; you are strictly prohibited from using, =
copying, altering, or </FONT>
<BR><FONT SIZE=3D2>&gt; disclosing</FONT>
<BR><FONT SIZE=3D2>&gt; the contents of this message.&nbsp; HSS accepts =
no responsibility </FONT>
<BR><FONT SIZE=3D2>&gt; for loss or</FONT>
<BR><FONT SIZE=3D2>&gt; damage arising from the use of the information =
transmitted by </FONT>
<BR><FONT SIZE=3D2>&gt; this email</FONT>
<BR><FONT SIZE=3D2>&gt; including damage from virus.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; Sip mailing list&nbsp; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/sip" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/sip</A></FONT>
<BR><FONT SIZE=3D2>&gt; This list is for NEW development of the core =
SIP Protocol</FONT>
<BR><FONT SIZE=3D2>&gt; Use sip-implementors@cs.columbia.edu for =
questions on current sip</FONT>
<BR><FONT SIZE=3D2>&gt; Use sipping@ietf.org for new developments on =
the application of sip</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2801A.5AB21340--
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Wed Oct 30 13:36:45 2002
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 NAA02756
	for <sip-archive@odin.ietf.org>; Wed, 30 Oct 2002 13:36:45 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9UIcgl24924
	for sip-archive@odin.ietf.org; Wed, 30 Oct 2002 13:38:42 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UIcFv24910;
	Wed, 30 Oct 2002 13:38: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 g9UIbxv24884
	for <sip@optimus.ietf.org>; Wed, 30 Oct 2002 13:37:59 -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 NAA02681
	for <sip@ietf.org>; Wed, 30 Oct 2002 13:35:30 -0500 (EST)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9UIbnQ1018398;
	Wed, 30 Oct 2002 19:37:53 +0100 (MET)
Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.106.10])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g9UIbmG3014087;
	Wed, 30 Oct 2002 20:37:49 +0200 (EET)
Message-ID: <3DC026FC.AE839F23@lmf.ericsson.se>
Date: Wed, 30 Oct 2002 20:37:48 +0200
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: "Peterson, Jon" <jon.peterson@neustar.biz>
CC: sip@ietf.org
Subject: Re: [Sip] SIPS question
References: <15A2739B7DAA624D8091C65981D7DA815EB340@stntexch2.va.neustar.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit


Hi,

> I agree that I don't see any immediate use for this, but I also don't see
> any danger that would mandate forbidding it. Was there anything you had in
> mind?

Assuming the UAS does insert a SIPS-URI in the Contact, let's have a look at
the following scenario:

UA1 ------------- P1 -------------- UA2

Now, UA1 sends an INVITE to UA2, via P1:

- UA1 inserts a SIP-URI in the Request-URI

- P1 inserts a Record-Route header with a SIP-URI

- UA2 sends 200 with a Contact header with a SIPS-URI


Q1:  Now, UA2 indicates that requests from P1 to UA2 shall be sent using TLS,
due to the SIPS-URI in the Contact. However, requests from UA2 to P1 would be
sent using let's say UDP, due to the SIP-URI in the Record-Route.


Q2: Now, if P1 supports loose routing, when UA1 sends another request within
the session, it will look like:

Request-URI: SIPS-URI: UA2
Route:SIP-URI: P1;lr

Now, according to chapter 26.2.2 in RFC3261, if the Request-URI contains a
SIPS-URI, TLS shall be used. However, the request is not sent to the
Request-URI, but to the top Route, which contains a SIP-URI. So, since P1
record routed with a SIP-URI, and that route is used to route the request, why
shall UA1 make the transport decission based on the SIPS-URI in the
Request-URI??? UA1 doesn't even know if P1 supports TLS or not, and UA1 may
not support TLS, so....


Regards,

Christer Holmberg
Ericsson Finland




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



From mailnull@www1.ietf.org  Wed Oct 30 14:09:21 2002
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 OAA04657
	for <sip-archive@odin.ietf.org>; Wed, 30 Oct 2002 14:09:21 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9UJBIZ27094
	for sip-archive@odin.ietf.org; Wed, 30 Oct 2002 14:11:18 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UJAXv27004;
	Wed, 30 Oct 2002 14:10: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 g9UJ92v26917
	for <sip@optimus.ietf.org>; Wed, 30 Oct 2002 14:09:02 -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 OAA04485
	for <sip@ietf.org>; Wed, 30 Oct 2002 14:06:33 -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 OAA07969;
	Wed, 30 Oct 2002 14:08:55 -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 OAA21234;
	Wed, 30 Oct 2002 14:08:56 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <V8TM39QK>; Wed, 30 Oct 2002 14:08:55 -0500
Message-ID: <313680C9A886D511A06000204840E1CF030B5AE3@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Snyder, Duke'" <Duke.Snyder@inin.com>, sip@ietf.org
Subject: RE: [Sip] Standard mechanism to instruct the phone go off hook
Date: Wed, 30 Oct 2002 14:08:55 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

I don't understand why this is needed given the scenarios you
provide.  In the examples you cite, you ALWAYS use autoanswer,
or, at least, you autoanswer for a particular AOR.  That's
a local decision.  The system shouldn't tell you to do that,
your sip UA should decide to do that, based on calling and
called URIs if necessary.  I'm not aware of scenarios where
it's the remote side, or an intermediary, that decides
whether you should or should not autoanswer.

So, local configuration seems very appropriate, and we don't
standardize that.

You could ask for a URI convention.  Consider the "intercom"
function.  Might be nice to have a URI convention for 
that, with a (local) decision on acceptance based on authentication
and who is calling. 

Brian

> -----Original Message-----
> From: Snyder, Duke [mailto:Duke.Snyder@inin.com]
> Sent: Saturday, October 26, 2002 7:23 PM
> To: sip@ietf.org
> Subject: [Sip] Standard mechanism to instruct the phone go off hook
> 
> 
> Has any work been done to have a standard mechanism for an 
> application to request that the phone answer it's "alerting" 
> call by going off hook (to speaker mode).   Currently, 
> different hard IP phones have a different ways to 
> "auto-answer", but it complicates SIP development working 
> with proprietary, non-SIP techniques.   The PhoneControl 
> draft 
> (http://www.cs.columbia.edu/~hgs/sip/drafts/draft-dean-phonect
> l-03.txt) seems to do some phone control, but not the 
> auto-answer request.
> 
> Common scenarios for this request:
> *	A call center agent typically uses auto-answer for his 
> call center calls.  His SIP app (based off his configuration) 
> could send the call to his phone (with a headset), request 
> that the phone answer the call, and the agent handles the 
> call completely hands-free.
> *	A call center supervisor selects a call to monitor.  
> His SIP app will direct the audio of the call to his phone, 
> but first must call his phone to establish an audio path.  
> Again, typically the supervisor would like the phone to 
> automatically go off hook rather than forcing him to answer the phone.
> 
> Authentication would need to be used since most people would 
> not want their SIP phone in their bedroom to go off hook.
> 
> 
> Duke Snyder
> Interactive Intelligence, Inc.
> www.inin.com
> 
> 
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Wed Oct 30 23:02:04 2002
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 XAA24964
	for <sip-archive@odin.ietf.org>; Wed, 30 Oct 2002 23:02:04 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9V445324934
	for sip-archive@odin.ietf.org; Wed, 30 Oct 2002 23:04:05 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9V43Rv24901;
	Wed, 30 Oct 2002 23:03: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 g9V40mv24811
	for <sip@optimus.ietf.org>; Wed, 30 Oct 2002 23:00:48 -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 WAA24879
	for <sip@ietf.org>; Wed, 30 Oct 2002 22:58:12 -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 g9V3h0i04082;
	Thu, 31 Oct 2002 09:13:01 +0530
Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 65256C63.0015C34E ; Thu, 31 Oct 2002 09:27:42 +0530
X-Lotus-FromDomain: HSSBLR
To: "Mark Watson" <mwatson@nortelnetworks.com>
cc: sip@ietf.org, hbhondwe@hss.hns.com
Message-ID: <65256C63.0015C2B8.00@sampark.hss.hns.com>
Date: Thu, 31 Oct 2002 09:27:40 +0530
Subject: RE: [Sip] draft-ietf-sip-asserted-identity-02.txt: ppi from trust
		ed entity
Mime-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=O179vXhhBjRqr1mUbSM8LYCJLnFFqsxaqQhJvVvRawfppotl0mbQvxJ3"
Content-Disposition: inline
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

--0__=O179vXhhBjRqr1mUbSM8LYCJLnFFqsxaqQhJvVvRawfppotl0mbQvxJ3
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline



Mark,

I understand the point that you've made and that  how a proxy uses the
P-Preferred-Identity headers
received from a user agent is a policy decision.

I got confused because of the first statement in Section 6 which reads:
'If a P-Preferred-Identity header field is present in the message that
   a proxy receives from an entity that it does not trust.....'.

Is this statement then equivalent to the following?
'If a P-Preferred-Identity header field is present in the message that
   a proxy receives from a user agent.....'.

I was also trying to understand why the P-Preferred-Identity MUST be
removed
by a proxy from any message that it forwards.Would it be correct to say
that the reason lies in
requirments themselves, as put forward in
draft-ietf-sipping-nai-reqs-02.txt , section 3 of which reads

'It shall be possible for a UA to provide a preferred identity to the
   network intermediary, which MAY be used to inform the generation of
   the Network Asserted Identity according to the policies of the Trust
   Domain.'.

And therefore the significance of P-Preferred-Identity exists only between
a UA and the proxy that performs its authentication.


thanks
harsh







"Mark Watson" <mwatson@nortelnetworks.com> on 10/30/2002 07:13:39 PM

To:   Harsh Bhondwe/HSSBLR, sip@ietf.org
cc:

Subject:  RE: [Sip] draft-ietf-sip-asserted-identity-02.txt: ppi from trust
      ed entity




Harsh,

From memory, a proxy should not expect to receive P-Preferred-Identity from
another member of the Trust Domain for Asserted Identity.

You may be right that the behaviour if it is received is not specified. If
a
P-Asserted-Identity is present, then I would expect the
P-Preferred-Identity
to be discarded (they should not coexist). If there is no
P-Asserted-Identity, then I suppose the Proxy could behave as if the
message
were received from outside the Trust Domain...

If P-Preferred-Identity is received from outside the Trust Domain, the
proxy
attempts to authenticate the originator of the message.

You ask whether the proxy MAY or MUST use the P-Preferred-Identity, but I'm
not sure the question makes sense. If it were a MAY, then whether to use it
or not must be a matter of local policy for the proxy. If it were a MUST,
then as long as the P-Preferred-Identity is 'a valid identity for that
user'
then it MUST use it. But the list of 'valid identities for that user' is a
matter of local policy too. So there is no difference.

For example, if the proxy NEVER uses P-Preferred-Identity, then this is
equivalent to saying that there is only one valid identity for the user.

Regards,

Mark Watson


> -----Original Message-----
> From: hbhondwe@hss.hns.com [mailto:hbhondwe@hss.hns.com]
> Sent: 29 October 2002 05:30
> To: sip@ietf.org
> Cc: hbhondwe@hss.hns.com
> Subject: [Sip] draft-ietf-sip-asserted-identity-02.txt: ppi
> from trusted
> entity
>
>
>
>
> Hi,
>
> Section 6 does not seem to explicitely specify proxy's behaviour when
> p-preferred-identity header is received by a proxy from a
> trusted entity:
>
> a)preferred identity corresponds to a valid identify known to
> the proxy for
> that user.
> -MUST the proxy use this identity or  MAY it ? I assume it MUST.
> b)preferred identity does not correspond to a valid identity
> known to the
> proxy for that user.
> -Should the proxy behaviour be same as when the entity from which the
> header was received is not trusted.
>
>
> 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.
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>


--0__=O179vXhhBjRqr1mUbSM8LYCJLnFFqsxaqQhJvVvRawfppotl0mbQvxJ3
Content-type: text/html; 
	name="att-1.htm"
Content-Disposition: attachment; filename="att-1.htm"
Content-Description: Internet HTML
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+
DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o
dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U
PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1NS4zNSI+DQo8VElUTEU+UkU6IFtT
aXBdIGRyYWZ0LWlldGYtc2lwLWFzc2VydGVkLWlkZW50aXR5LTAyLnR4dDogcHBpIGZyb20gdHJ1
c3RlZCBlbnRpdHk8L1RJVExFPg0KPC9IRUFEPg0KPEJPRFk+DQoNCjxQPjxGT05UIFNJWkU9Mj5I
YXJzaCw8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5Gcm9tIG1lbW9yeSwgYSBwcm94
eSBzaG91bGQgbm90IGV4cGVjdCB0byByZWNlaXZlIFAtUHJlZmVycmVkLUlkZW50aXR5IGZyb20g
YW5vdGhlciBtZW1iZXIgb2YgdGhlIFRydXN0IERvbWFpbiBmb3IgQXNzZXJ0ZWQgSWRlbnRpdHku
PC9GT05UPjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPllvdSBtYXkgYmUgcmlnaHQgdGhhdCB0aGUg
YmVoYXZpb3VyIGlmIGl0IGlzIHJlY2VpdmVkIGlzIG5vdCBzcGVjaWZpZWQuIElmIGEgUC1Bc3Nl
cnRlZC1JZGVudGl0eSBpcyBwcmVzZW50LCB0aGVuIEkgd291bGQgZXhwZWN0IHRoZSBQLVByZWZl
cnJlZC1JZGVudGl0eSB0byBiZSBkaXNjYXJkZWQgKHRoZXkgc2hvdWxkIG5vdCBjb2V4aXN0KS4g
SWYgdGhlcmUgaXMgbm8gUC1Bc3NlcnRlZC1JZGVudGl0eSwgdGhlbiBJIHN1cHBvc2UgdGhlIFBy
b3h5IGNvdWxkIGJlaGF2ZSBhcyBpZiB0aGUgbWVzc2FnZSB3ZXJlIHJlY2VpdmVkIGZyb20gb3V0
c2lkZSB0aGUgVHJ1c3QgRG9tYWluLi4uPC9GT05UPjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPklm
IFAtUHJlZmVycmVkLUlkZW50aXR5IGlzIHJlY2VpdmVkIGZyb20gb3V0c2lkZSB0aGUgVHJ1c3Qg
RG9tYWluLCB0aGUgcHJveHkgYXR0ZW1wdHMgdG8gYXV0aGVudGljYXRlIHRoZSBvcmlnaW5hdG9y
IG9mIHRoZSBtZXNzYWdlLjwvRk9OVD48L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5Zb3UgYXNrIHdo
ZXRoZXIgdGhlIHByb3h5IE1BWSBvciBNVVNUIHVzZSB0aGUgUC1QcmVmZXJyZWQtSWRlbnRpdHks
IGJ1dCBJJ20gbm90IHN1cmUgdGhlIHF1ZXN0aW9uIG1ha2VzIHNlbnNlLiBJZiBpdCB3ZXJlIGEg
TUFZLCB0aGVuIHdoZXRoZXIgdG8gdXNlIGl0IG9yIG5vdCBtdXN0IGJlIGEgbWF0dGVyIG9mIGxv
Y2FsIHBvbGljeSBmb3IgdGhlIHByb3h5LiBJZiBpdCB3ZXJlIGEgTVVTVCwgdGhlbiBhcyBsb25n
IGFzIHRoZSBQLVByZWZlcnJlZC1JZGVudGl0eSBpcyAnYSB2YWxpZCBpZGVudGl0eSBmb3IgdGhh
dCB1c2VyJyB0aGVuIGl0IE1VU1QgdXNlIGl0LiBCdXQgdGhlIGxpc3Qgb2YgJ3ZhbGlkIGlkZW50
aXRpZXMgZm9yIHRoYXQgdXNlcicgaXMgYSBtYXR0ZXIgb2YgbG9jYWwgcG9saWN5IHRvby4gU28g
dGhlcmUgaXMgbm8gZGlmZmVyZW5jZS48L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+Rm9y
IGV4YW1wbGUsIGlmIHRoZSBwcm94eSBORVZFUiB1c2VzIFAtUHJlZmVycmVkLUlkZW50aXR5LCB0
aGVuIHRoaXMgaXMgZXF1aXZhbGVudCB0byBzYXlpbmcgdGhhdCB0aGVyZSBpcyBvbmx5IG9uZSB2
YWxpZCBpZGVudGl0eSBmb3IgdGhlIHVzZXIuPC9GT05UPjwvUD4NCg0KPFA+PEZPTlQgU0laRT0y
PlJlZ2FyZHMsPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+TWFyayBXYXRzb248L0ZP
TlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZuYnNwOzwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0la
RT0yPiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08L0ZPTlQ+DQo8QlI+PEZPTlQgU0la
RT0yPiZndDsgRnJvbTogaGJob25kd2VAaHNzLmhucy5jb20gWzxBIEhSRUY9Im1haWx0bzpoYmhv
bmR3ZUBoc3MuaG5zLmNvbSI+bWFpbHRvOmhiaG9uZHdlQGhzcy5obnMuY29tPC9BPl08L0ZPTlQ+
DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgU2VudDogMjkgT2N0b2JlciAyMDAyIDA1OjMwPC9GT05U
Pg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IFRvOiBzaXBAaWV0Zi5vcmc8L0ZPTlQ+DQo8QlI+PEZP
TlQgU0laRT0yPiZndDsgQ2M6IGhiaG9uZHdlQGhzcy5obnMuY29tPC9GT05UPg0KPEJSPjxGT05U
IFNJWkU9Mj4mZ3Q7IFN1YmplY3Q6IFtTaXBdIGRyYWZ0LWlldGYtc2lwLWFzc2VydGVkLWlkZW50
aXR5LTAyLnR4dDogcHBpIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBmcm9tIHRydXN0
ZWQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgZW50aXR5PC9GT05UPg0KPEJSPjxGT05U
IFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+
PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4N
CjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBIaSw8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsg
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IFNlY3Rpb24gNiBkb2VzIG5vdCBzZWVtIHRv
IGV4cGxpY2l0ZWx5IHNwZWNpZnkgcHJveHkncyBiZWhhdmlvdXIgd2hlbjwvRk9OVD4NCjxCUj48
Rk9OVCBTSVpFPTI+Jmd0OyBwLXByZWZlcnJlZC1pZGVudGl0eSBoZWFkZXIgaXMgcmVjZWl2ZWQg
YnkgYSBwcm94eSBmcm9tIGEgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IHRydXN0ZWQg
ZW50aXR5OjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQg
U0laRT0yPiZndDsgYSlwcmVmZXJyZWQgaWRlbnRpdHkgY29ycmVzcG9uZHMgdG8gYSB2YWxpZCBp
ZGVudGlmeSBrbm93biB0byA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgdGhlIHByb3h5
IGZvcjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyB0aGF0IHVzZXIuPC9GT05UPg0KPEJS
PjxGT05UIFNJWkU9Mj4mZ3Q7IC1NVVNUIHRoZSBwcm94eSB1c2UgdGhpcyBpZGVudGl0eSBvciZu
YnNwOyBNQVkgaXQgPyBJIGFzc3VtZSBpdCBNVVNULjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+
Jmd0OyBiKXByZWZlcnJlZCBpZGVudGl0eSBkb2VzIG5vdCBjb3JyZXNwb25kIHRvIGEgdmFsaWQg
aWRlbnRpdHkgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGtub3duIHRvIHRoZTwvRk9O
VD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBwcm94eSBmb3IgdGhhdCB1c2VyLjwvRk9OVD4NCjxC
Uj48Rk9OVCBTSVpFPTI+Jmd0OyAtU2hvdWxkIHRoZSBwcm94eSBiZWhhdmlvdXIgYmUgc2FtZSBh
cyB3aGVuIHRoZSBlbnRpdHkgZnJvbSB3aGljaCB0aGU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y
PiZndDsgaGVhZGVyIHdhcyByZWNlaXZlZCBpcyBub3QgdHJ1c3RlZC48L0ZPTlQ+DQo8QlI+PEZP
TlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxC
Uj48Rk9OVCBTSVpFPTI+Jmd0OyB0aGFua3M8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsg
aGFyc2g8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJ
WkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZP
TlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxC
Uj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05U
Pg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBU
aGlzIG1lc3NhZ2UgaXMgcHJvcHJpZXRhcnkgdG8gSHVnaGVzIFNvZnR3YXJlIFN5c3RlbXMgPC9G
T05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IExpbWl0ZWQgKEhTUykgYW5kIGlzPC9GT05UPg0K
PEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUg
aW5kaXZpZHVhbCB0byB3aG9tIGl0IGlzIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBh
ZGRyZXNzZWQuJm5ic3A7IEl0PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IG1heSBjb250
YWluIHByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGFuZCBzaG91bGQgbm90
IGJlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGNpcmN1bGF0ZWQgb3IgdXNlZCBmb3Ig
YW55IHB1cnBvc2Ugb3RoZXIgdGhhbiBmb3Igd2hhdCBpdCBpcyA8L0ZPTlQ+DQo8QlI+PEZPTlQg
U0laRT0yPiZndDsgaW50ZW5kZWQuJm5ic3A7IElmPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4m
Z3Q7IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgcGxlYXNlIG5vdGlm
eSB0aGUgb3JpZ2luYXRvcjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBpbW1lZGlhdGVs
eS4mbmJzcDsgSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSA8
L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgbm90aWZpZWQgdGhhdDwvRk9OVD4NCjxCUj48
Rk9OVCBTSVpFPTI+Jmd0OyB5b3UgYXJlIHN0cmljdGx5IHByb2hpYml0ZWQgZnJvbSB1c2luZywg
Y29weWluZywgYWx0ZXJpbmcsIG9yIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBkaXNj
bG9zaW5nPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IHRoZSBjb250ZW50cyBvZiB0aGlz
IG1lc3NhZ2UuJm5ic3A7IEhTUyBhY2NlcHRzIG5vIHJlc3BvbnNpYmlsaXR5IDwvRk9OVD4NCjxC
Uj48Rk9OVCBTSVpFPTI+Jmd0OyBmb3IgbG9zcyBvcjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+
Jmd0OyBkYW1hZ2UgYXJpc2luZyBmcm9tIHRoZSB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIHRyYW5z
bWl0dGVkIGJ5IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyB0aGlzIGVtYWlsPC9GT05U
Pg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGluY2x1ZGluZyBkYW1hZ2UgZnJvbSB2aXJ1cy48L0ZP
TlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7
IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBTaXAg
bWFpbGluZyBsaXN0Jm5ic3A7IDxBIEhSRUY9Imh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL3NpcCIgVEFSR0VUPSJfYmxhbmsiPmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL3NpcDwvQT48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgVGhpcyBs
aXN0IGlzIGZvciBORVcgZGV2ZWxvcG1lbnQgb2YgdGhlIGNvcmUgU0lQIFByb3RvY29sPC9GT05U
Pg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IFVzZSBzaXAtaW1wbGVtZW50b3JzQGNzLmNvbHVtYmlh
LmVkdSBmb3IgcXVlc3Rpb25zIG9uIGN1cnJlbnQgc2lwPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9
Mj4mZ3Q7IFVzZSBzaXBwaW5nQGlldGYub3JnIGZvciBuZXcgZGV2ZWxvcG1lbnRzIG9uIHRoZSBh
cHBsaWNhdGlvbiBvZiBzaXA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0K
PC9QPg0KDQo8L0JPRFk+DQo8L0hUTUw+DQo=

--0__=O179vXhhBjRqr1mUbSM8LYCJLnFFqsxaqQhJvVvRawfppotl0mbQvxJ3--

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



From mailnull@www1.ietf.org  Wed Oct 30 23:43:59 2002
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 XAA25971
	for <sip-archive@odin.ietf.org>; Wed, 30 Oct 2002 23:43:59 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9V4k0G27251
	for sip-archive@odin.ietf.org; Wed, 30 Oct 2002 23:46:00 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9V4jcv27235;
	Wed, 30 Oct 2002 23:45: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 g9V4hBv27160
	for <sip@optimus.ietf.org>; Wed, 30 Oct 2002 23:43:11 -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 XAA25865
	for <sip@ietf.org>; Wed, 30 Oct 2002 23:40:38 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.41])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g9V4grYH021824;
	Wed, 30 Oct 2002 23:42:53 -0500 (EST)
Message-ID: <3DC0B4CC.1040109@dynamicsoft.com>
Date: Wed, 30 Oct 2002 23:42: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: hspark@etri.re.kr
CC: sip@ietf.org
Subject: Re: [Sip] Registration Event Package vs. DEREGISTER method
References: <8470181DABD5D511B3E700D0B7A8AC4A455B1B@cms3.etri.re.kr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit



hspark@etri.re.kr wrote:
> Hello,
>
> How do you think about defining new method for deregistration, namely
>  "DEREGISTER" ?

Deregistration is already supported using REGISTER with Expires:0.

>
> IMHO, I think we need not subscription to Registration event package
>  right after registration.

Subscriptions to registrations are needed for the reasons desribed in
the document.

-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

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



From mailnull@www1.ietf.org  Thu Oct 31 00:09:25 2002
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 AAA26441
	for <sip-archive@odin.ietf.org>; Thu, 31 Oct 2002 00:09:24 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9V5BRE28429
	for sip-archive@odin.ietf.org; Thu, 31 Oct 2002 00:11:27 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9V5Aqv28408;
	Thu, 31 Oct 2002 00:10: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 g9V59ev28372
	for <sip@optimus.ietf.org>; Thu, 31 Oct 2002 00:09:40 -0500
Received: from cms3.etri.re.kr (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26397
	for <sip@ietf.org>; Thu, 31 Oct 2002 00:07:06 -0500 (EST)
From: hspark@etri.re.kr
Received: by cms3.etri.re.kr with Internet Mail Service (5.5.2653.19)
	id <VZPY2KG5>; Thu, 31 Oct 2002 14:06:51 +0900
Message-ID: <8470181DABD5D511B3E700D0B7A8AC4A455B1D@cms3.etri.re.kr>
To: jdrosen@dynamicsoft.com
Cc: sip@ietf.org
Subject: RE: [Sip] Registration Event Package vs. DEREGISTER method
Date: Thu, 31 Oct 2002 14:06:51 +0900
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2809B.52632270"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-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_01C2809B.52632270
Content-Type: text/plain;
	charset="iso-2022-kr"

Thanks, Jonathan. 
Inline

> hspark@etri.re.kr wrote:
> > Hello,
> >
> > How do you think about defining new method for 
> deregistration, namely
> >  "DEREGISTER" ?
> 
> Deregistration is already supported using REGISTER with Expires:0.

I am sorry for ambiguity. 
I mean Deregistration is Network Initiated Deregistration e.g. Registration
Expiration at Registrar.

In detail, Registration event package document says, 
UA subscribes to Registration event package in order to get notification of
changes of its registration state, 
for example registration expiration.

But how about Registrar sends DEREGISTER to UA when UA's registration
expires or is unregistered.
Is it reasonable ? Thanks in advance. 

 
> >
> > IMHO, I think we need not subscription to Registration event package
> >  right after registration.
> 
> Subscriptions to registrations are needed for the reasons desribed in
> the document.
> 
> -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
> 

------_=_NextPart_001_01C2809B.52632270
Content-Type: text/html;
	charset="iso-2022-kr"
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-2022-kr">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [Sip] Registration Event Package vs. DEREGISTER =
method</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Thanks, Jonathan. </FONT>
<BR><FONT SIZE=3D2>Inline</FONT>
</P>

<P><FONT SIZE=3D2>&gt; hspark@etri.re.kr wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Hello,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; How do you think about defining new method =
for </FONT>
<BR><FONT SIZE=3D2>&gt; deregistration, namely</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &quot;DEREGISTER&quot; ?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Deregistration is already supported using =
REGISTER with Expires:0.</FONT>
</P>

<P><FONT SIZE=3D2>I am sorry for ambiguity. </FONT>
<BR><FONT SIZE=3D2>I mean Deregistration is Network Initiated =
Deregistration e.g. Registration Expiration at Registrar.</FONT>
</P>

<P><FONT SIZE=3D2>In detail, Registration event package document says, =
</FONT>
<BR><FONT SIZE=3D2>UA subscribes to Registration event package in order =
to get notification of changes of its registration state, </FONT>
<BR><FONT SIZE=3D2>for example registration expiration.</FONT>
</P>

<P><FONT SIZE=3D2>But how about Registrar sends DEREGISTER to UA when =
UA's registration expires or is unregistered.</FONT>
<BR><FONT SIZE=3D2>Is it reasonable ? Thanks in advance. </FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; IMHO, I think we need not subscription to =
Registration event package</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; right after registration.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Subscriptions to registrations are needed for =
the reasons desribed in</FONT>
<BR><FONT SIZE=3D2>&gt; the document.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -Jonathan R.</FONT>
<BR><FONT SIZE=3D2>&gt; -- </FONT>
<BR><FONT SIZE=3D2>&gt; Jonathan D. Rosenberg, =
Ph.D.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp; 72 Eagle Rock Ave.</FONT>
<BR><FONT SIZE=3D2>&gt; Chief =
Scientist&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; First Floor</FONT>
<BR><FONT SIZE=3D2>&gt; =
dynamicsoft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; East =
Hanover, NJ 07936</FONT>
<BR><FONT SIZE=3D2>&gt; =
jdrosen@dynamicsoft.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
FAX:&nbsp;&nbsp; (973) 952-5050</FONT>
<BR><FONT SIZE=3D2>&gt; <A HREF=3D"http://www.jdrosen.net" =
TARGET=3D"_blank">http://www.jdrosen.net</A>&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; PHONE: (973) 952-5000</FONT>
<BR><FONT SIZE=3D2>&gt; <A HREF=3D"http://www.dynamicsoft.com" =
TARGET=3D"_blank">http://www.dynamicsoft.com</A></FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>

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



From mailnull@www1.ietf.org  Thu Oct 31 05:24:06 2002
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 FAA11908
	for <sip-archive@odin.ietf.org>; Thu, 31 Oct 2002 05:24:06 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9VAPxh21152
	for sip-archive@odin.ietf.org; Thu, 31 Oct 2002 05:25:59 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VAPLv21130;
	Thu, 31 Oct 2002 05: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 g9VAM2v20893
	for <sip@optimus.ietf.org>; Thu, 31 Oct 2002 05:22:02 -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 FAA11775
	for <sip@ietf.org>; Thu, 31 Oct 2002 05:19:38 -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 g9VAMLB25162
	for <sip@ietf.org>; Thu, 31 Oct 2002 12:22:21 +0200 (EET)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5e46cf4a31ac158f23077@esvir03nok.nokia.com>;
 Thu, 31 Oct 2002 12:21:55 +0200
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Thu, 31 Oct 2002 12:21:55 +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: [Sip] SIPS question
Date: Thu, 31 Oct 2002 12:21:54 +0200
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE6F5E@esebe019.ntc.nokia.com>
Thread-Topic: [Sip] SIPS question
Thread-Index: AcKARN0It6p80d4xT+SMCja9fbovWQAgSXyQ
To: <christer.holmberg@lmf.ericsson.se>, <jon.peterson@neustar.biz>
Cc: <sip@ietf.org>
X-OriginalArrivalTime: 31 Oct 2002 10:21:55.0670 (UTC) FILETIME=[566E1F60:01C280C7]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9VAM2v20894
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit

I guess UA2 should have registered with P1 using a sips-uri in the contact-header. P1 doesn't care about the contact-header sent in the 200 OK. UA2 contact-header is telling UA1 (not P1) to contact it using TLS.

My suggestion would be that UA2 rejects the call and then re-registers with P1 using a sips-uri in the contact-header. Otherwise we have a complicated scenario where P1 has to examine contact-header in response and change the route-header to sips. UA1 has to do the same and change its own contact header to sips in a re-INVITE. Too much.

Regards,
Hisham

> -----Original Message-----
> From: ext Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se]
> Sent: Wednesday, October 30, 2002 8:38 PM
> To: Peterson, Jon
> Cc: sip@ietf.org
> Subject: Re: [Sip] SIPS question
> 
> 
> 
> Hi,
> 
> > I agree that I don't see any immediate use for this, but I 
> also don't see
> > any danger that would mandate forbidding it. Was there 
> anything you had in
> > mind?
> 
> Assuming the UAS does insert a SIPS-URI in the Contact, let's 
> have a look at
> the following scenario:
> 
> UA1 ------------- P1 -------------- UA2
> 
> Now, UA1 sends an INVITE to UA2, via P1:
> 
> - UA1 inserts a SIP-URI in the Request-URI
> 
> - P1 inserts a Record-Route header with a SIP-URI
> 
> - UA2 sends 200 with a Contact header with a SIPS-URI
> 
> 
> Q1:  Now, UA2 indicates that requests from P1 to UA2 shall be 
> sent using TLS,
> due to the SIPS-URI in the Contact. However, requests from 
> UA2 to P1 would be
> sent using let's say UDP, due to the SIP-URI in the Record-Route.
> 
> 
> Q2: Now, if P1 supports loose routing, when UA1 sends another 
> request within
> the session, it will look like:
> 
> Request-URI: SIPS-URI: UA2
> Route:SIP-URI: P1;lr
> 
> Now, according to chapter 26.2.2 in RFC3261, if the 
> Request-URI contains a
> SIPS-URI, TLS shall be used. However, the request is not sent to the
> Request-URI, but to the top Route, which contains a SIP-URI. 
> So, since P1
> record routed with a SIP-URI, and that route is used to route 
> the request, why
> shall UA1 make the transport decission based on the SIPS-URI in the
> Request-URI??? UA1 doesn't even know if P1 supports TLS or 
> not, and UA1 may
> not support TLS, so....
> 
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> 
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Thu Oct 31 05:29:39 2002
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 FAA11981
	for <sip-archive@odin.ietf.org>; Thu, 31 Oct 2002 05:29:39 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9VAVWQ21509
	for sip-archive@odin.ietf.org; Thu, 31 Oct 2002 05:31:32 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VAVAv21491;
	Thu, 31 Oct 2002 05:31: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 g9VAUov21450
	for <sip@optimus.ietf.org>; Thu, 31 Oct 2002 05:30:50 -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 FAA11949
	for <sip@ietf.org>; Thu, 31 Oct 2002 05:28:25 -0500 (EST)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9VAUlKV000200;
	Thu, 31 Oct 2002 11:30:47 +0100 (MET)
Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.112])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g9VAUlG3025481;
	Thu, 31 Oct 2002 12:30:47 +0200 (EET)
Message-ID: <3DC10658.10EB633D@lmf.ericsson.se>
Date: Thu, 31 Oct 2002 12:30:48 +0200
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: hisham.khartabil@nokia.com
CC: jon.peterson@neustar.biz, sip@ietf.org
Subject: Re: [Sip] SIPS question
References: <2038BCC78B1AD641891A0D1AE133DBB7FE6F5E@esebe019.ntc.nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit


Hi,

> I guess UA2 should have registered with P1 using a sips-uri in the contact-header. P1 doesn't care about the contact-header sent in the 200 OK. UA2 contact-header is telling UA1 (not P1) to contact it using TLS.

No, but the Contact header value will be used in requests during the session, as part of the route set or Request-URI (depending on if loose routing is used etc)

> My suggestion would be that UA2 rejects the call and then re-registers with P1 using a sips-uri in the contact-header. Otherwise we have a complicated scenario where P1 has to examine contact-header in response and change the route-header to sips. UA1 has to do the same and change its own contact header to sips in a re-INVITE. Too much.

This is the reason I first aksed if UA2 is allowed to return a SIPS-URI in the Contact header in the first place :)

Also, I guess you can get similar scenarios if a proxy inserts a Record-Route header with SIPS-URI, even if it receives something sent with a SIP-URI.

Regards,

Christer Holmberg
Ericsson Finland



>
>
> Regards,
> Hisham
>
> > -----Original Message-----
> > From: ext Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se]
> > Sent: Wednesday, October 30, 2002 8:38 PM
> > To: Peterson, Jon
> > Cc: sip@ietf.org
> > Subject: Re: [Sip] SIPS question
> >
> >
> >
> > Hi,
> >
> > > I agree that I don't see any immediate use for this, but I
> > also don't see
> > > any danger that would mandate forbidding it. Was there
> > anything you had in
> > > mind?
> >
> > Assuming the UAS does insert a SIPS-URI in the Contact, let's
> > have a look at
> > the following scenario:
> >
> > UA1 ------------- P1 -------------- UA2
> >
> > Now, UA1 sends an INVITE to UA2, via P1:
> >
> > - UA1 inserts a SIP-URI in the Request-URI
> >
> > - P1 inserts a Record-Route header with a SIP-URI
> >
> > - UA2 sends 200 with a Contact header with a SIPS-URI
> >
> >
> > Q1:  Now, UA2 indicates that requests from P1 to UA2 shall be
> > sent using TLS,
> > due to the SIPS-URI in the Contact. However, requests from
> > UA2 to P1 would be
> > sent using let's say UDP, due to the SIP-URI in the Record-Route.
> >
> >
> > Q2: Now, if P1 supports loose routing, when UA1 sends another
> > request within
> > the session, it will look like:
> >
> > Request-URI: SIPS-URI: UA2
> > Route:SIP-URI: P1;lr
> >
> > Now, according to chapter 26.2.2 in RFC3261, if the
> > Request-URI contains a
> > SIPS-URI, TLS shall be used. However, the request is not sent to the
> > Request-URI, but to the top Route, which contains a SIP-URI.
> > So, since P1
> > record routed with a SIP-URI, and that route is used to route
> > the request, why
> > shall UA1 make the transport decission based on the SIPS-URI in the
> > Request-URI??? UA1 doesn't even know if P1 supports TLS or
> > not, and UA1 may
> > not support TLS, so....
> >
> >
> > Regards,
> >
> > Christer Holmberg
> > Ericsson Finland
> >
> >
> >
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip
> >

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



From mailnull@www1.ietf.org  Thu Oct 31 06:13:22 2002
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 GAA12856
	for <sip-archive@odin.ietf.org>; Thu, 31 Oct 2002 06:13:22 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9VBFGQ23924
	for sip-archive@odin.ietf.org; Thu, 31 Oct 2002 06:15:16 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VBEev23898;
	Thu, 31 Oct 2002 06:14: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 g9VBDuv23865
	for <sip@optimus.ietf.org>; Thu, 31 Oct 2002 06:13:56 -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 GAA12623
	for <sip@ietf.org>; Thu, 31 Oct 2002 06:11:31 -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 g9VBDUO24734
	for <sip@ietf.org>; Thu, 31 Oct 2002 13:13:30 +0200 (EET)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5e46fedd78ac158f21082@esvir01nok.ntc.nokia.com>;
 Thu, 31 Oct 2002 13:13:53 +0200
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Thu, 31 Oct 2002 13:13:53 +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: [Sip] SIPS question
Date: Thu, 31 Oct 2002 13:13:51 +0200
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE6F5F@esebe019.ntc.nokia.com>
Thread-Topic: [Sip] SIPS question
Thread-Index: AcKAyJ7XIQbO+jGVTbmjQc8253XnoAABTGeA
To: <christer.holmberg@lmf.ericsson.se>
Cc: <jon.peterson@neustar.biz>, <sip@ietf.org>
X-OriginalArrivalTime: 31 Oct 2002 11:13:53.0151 (UTC) FILETIME=[9897F8F0:01C280CE]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9VBDuv23866
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit



> -----Original Message-----
> From: ext Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se]
> Sent: Thursday, October 31, 2002 12:31 PM
> To: Khartabil Hisham (NMP/Helsinki)
> Cc: jon.peterson@neustar.biz; sip@ietf.org
> Subject: Re: [Sip] SIPS question
> 
> 
> 
> Hi,
> 
> > I guess UA2 should have registered with P1 using a sips-uri 
> in the contact-header. P1 doesn't care about the 
> contact-header sent in the 200 OK. UA2 contact-header is 
> telling UA1 (not P1) to contact it using TLS.
> 
> No, but the Contact header value will be used in requests 
> during the session, as part of the route set or Request-URI 
> (depending on if loose routing is used etc)

What I meant to say is that if UA2 had registered with P1 using a sips-uri in the contact-header, then when P1 is routing the INVITE, it will put sips-uri in the record-route header since the request uri (retrieved from the registrar) is a sips-uri.

Since P1 contacted UA2 using sips, the 200 ok must contain a contact-header with sips-uri.

> 
> > My suggestion would be that UA2 rejects the call and then 
> re-registers with P1 using a sips-uri in the contact-header. 
> Otherwise we have a complicated scenario where P1 has to 
> examine contact-header in response and change the 
> route-header to sips. UA1 has to do the same and change its 
> own contact header to sips in a re-INVITE. Too much.
> 
> This is the reason I first aksed if UA2 is allowed to return 
> a SIPS-URI in the Contact header in the first place :)

This is applicable in the scenario when UA2 decides, after registering, that it wants to use sips now.

> 
> Also, I guess you can get similar scenarios if a proxy 
> inserts a Record-Route header with SIPS-URI, even if it 
> receives something sent with a SIP-URI.

That scenario is covered in RFC3261 (where the proxy has to exit the record-route header in the response, or do it Dean's way :).

Regards,
Hisham

> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> 
> 
> >
> >
> > Regards,
> > Hisham
> >
> > > -----Original Message-----
> > > From: ext Christer Holmberg 
> [mailto:christer.holmberg@lmf.ericsson.se]
> > > Sent: Wednesday, October 30, 2002 8:38 PM
> > > To: Peterson, Jon
> > > Cc: sip@ietf.org
> > > Subject: Re: [Sip] SIPS question
> > >
> > >
> > >
> > > Hi,
> > >
> > > > I agree that I don't see any immediate use for this, but I
> > > also don't see
> > > > any danger that would mandate forbidding it. Was there
> > > anything you had in
> > > > mind?
> > >
> > > Assuming the UAS does insert a SIPS-URI in the Contact, let's
> > > have a look at
> > > the following scenario:
> > >
> > > UA1 ------------- P1 -------------- UA2
> > >
> > > Now, UA1 sends an INVITE to UA2, via P1:
> > >
> > > - UA1 inserts a SIP-URI in the Request-URI
> > >
> > > - P1 inserts a Record-Route header with a SIP-URI
> > >
> > > - UA2 sends 200 with a Contact header with a SIPS-URI
> > >
> > >
> > > Q1:  Now, UA2 indicates that requests from P1 to UA2 shall be
> > > sent using TLS,
> > > due to the SIPS-URI in the Contact. However, requests from
> > > UA2 to P1 would be
> > > sent using let's say UDP, due to the SIP-URI in the Record-Route.
> > >
> > >
> > > Q2: Now, if P1 supports loose routing, when UA1 sends another
> > > request within
> > > the session, it will look like:
> > >
> > > Request-URI: SIPS-URI: UA2
> > > Route:SIP-URI: P1;lr
> > >
> > > Now, according to chapter 26.2.2 in RFC3261, if the
> > > Request-URI contains a
> > > SIPS-URI, TLS shall be used. However, the request is not 
> sent to the
> > > Request-URI, but to the top Route, which contains a SIP-URI.
> > > So, since P1
> > > record routed with a SIP-URI, and that route is used to route
> > > the request, why
> > > shall UA1 make the transport decission based on the 
> SIPS-URI in the
> > > Request-URI??? UA1 doesn't even know if P1 supports TLS or
> > > not, and UA1 may
> > > not support TLS, so....
> > >
> > >
> > > Regards,
> > >
> > > Christer Holmberg
> > > Ericsson Finland
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > This list is for NEW development of the core SIP Protocol
> > > Use sip-implementors@cs.columbia.edu for questions on current sip
> > > Use sipping@ietf.org for new developments on the 
> application of sip
> > >
> 
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Thu Oct 31 06:38:58 2002
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 GAA13960
	for <sip-archive@odin.ietf.org>; Thu, 31 Oct 2002 06:38:58 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9VBeqt25575
	for sip-archive@odin.ietf.org; Thu, 31 Oct 2002 06:40:52 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VBeQv25552;
	Thu, 31 Oct 2002 06:40: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 g9VBbHv25104
	for <sip@optimus.ietf.org>; Thu, 31 Oct 2002 06:37:17 -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 GAA13813
	for <sip@ietf.org>; Thu, 31 Oct 2002 06:34:51 -0500 (EST)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9VBbDKV020927;
	Thu, 31 Oct 2002 12:37:13 +0100 (MET)
Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.112])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g9VBbDG3029253;
	Thu, 31 Oct 2002 13:37:13 +0200 (EET)
Message-ID: <3DC115EA.68CA3412@lmf.ericsson.se>
Date: Thu, 31 Oct 2002 13:37:14 +0200
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: hisham.khartabil@nokia.com
CC: jon.peterson@neustar.biz, sip@ietf.org
Subject: Re: [Sip] SIPS question
References: <2038BCC78B1AD641891A0D1AE133DBB7FE6F5F@esebe019.ntc.nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit



hisham.khartabil@nokia.com wrote:

> > -----Original Message-----
> > From: ext Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se]
> > Sent: Thursday, October 31, 2002 12:31 PM
> > To: Khartabil Hisham (NMP/Helsinki)
> > Cc: jon.peterson@neustar.biz; sip@ietf.org
> > Subject: Re: [Sip] SIPS question
> >
> >
> >
> > Hi,
> >
> > > I guess UA2 should have registered with P1 using a sips-uri
> > in the contact-header. P1 doesn't care about the
> > contact-header sent in the 200 OK. UA2 contact-header is
> > telling UA1 (not P1) to contact it using TLS.
> >
> > No, but the Contact header value will be used in requests
> > during the session, as part of the route set or Request-URI
> > (depending on if loose routing is used etc)
>
> What I meant to say is that if UA2 had registered with P1 using a sips-uri in the contact-header, then when P1 is routing the INVITE, it will put sips-uri in the record-route header since the request uri (retrieved from the registrar) is a sips-uri.

> Since P1 contacted UA2 using sips, the 200 ok must contain a contact-header with sips-uri.

Ok. So, in this case UA1 will receive a Record-Route with SIPS-URI. So, the next time UA1 sends a request the SIPS-URI indicates it shall use TLS - which UA1 may not even support.

And, since UA1 used SIP-URI in its own Contact header, P1 shall use UDP (or TCP) to forward requests received from UA2, so now we would have the separate-transport-in-each-direction problem between UA1 and P1, wouldn't we?

Regards,

Christer Holmberg
Ericsson Finland



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



From mailnull@www1.ietf.org  Thu Oct 31 07:14:43 2002
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 HAA15403
	for <sip-archive@odin.ietf.org>; Thu, 31 Oct 2002 07:14:43 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9VCGbG27158
	for sip-archive@odin.ietf.org; Thu, 31 Oct 2002 07:16:37 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VCG4v27141;
	Thu, 31 Oct 2002 07:16: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 g9VCEMv27093
	for <sip@optimus.ietf.org>; Thu, 31 Oct 2002 07:14:22 -0500
Received: from i3exchange.i3domain.inin.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15266
	for <sip@ietf.org>; Thu, 31 Oct 2002 07:11:56 -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: [Sip] Standard mechanism to instruct the phone go off hook
Date: Thu, 31 Oct 2002 07:14:19 -0500
Message-ID: <58A40B582A73F54AB5D8739C0678F3A801A60298@i3exchange.inin.com>
Thread-Topic: [Sip] Standard mechanism to instruct the phone go off hook
Thread-Index: AcKAR84PaG+HtPTHSGOi6hzC9pCOkQAjb5zw
From: "Snyder, Duke" <Duke.Snyder@inin.com>
To: "Rosen, Brian" <Brian.Rosen@marconi.com>, <sip@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9VCEMv27094
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit

Correct, for the scenarios below, we always want the phone to be in "auto answer" mode.  The problem is that there will be other calls, such as calls from the spouse, that are sent to the same phone.   In this case, the application knows that the call center supervisor or call center agent does NOT want the auto answer on his phone to kick in (maybe the agent stepped away from his desk or just doesn't want to talk to that specific caller at the moment) and the application could (or could not) send a hopefully-upcoming-SIP notify to inform the phone to answer the alerting call.  This is a comment complaint at every one of our sites.

-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Wednesday, October 30, 2002 2:09 PM
To: Snyder, Duke; sip@ietf.org
Subject: RE: [Sip] Standard mechanism to instruct the phone go off hook


I don't understand why this is needed given the scenarios you
provide.  In the examples you cite, you ALWAYS use autoanswer,
or, at least, you autoanswer for a particular AOR.  That's
a local decision.  The system shouldn't tell you to do that,
your sip UA should decide to do that, based on calling and
called URIs if necessary.  I'm not aware of scenarios where
it's the remote side, or an intermediary, that decides
whether you should or should not autoanswer.

So, local configuration seems very appropriate, and we don't
standardize that.

You could ask for a URI convention.  Consider the "intercom"
function.  Might be nice to have a URI convention for 
that, with a (local) decision on acceptance based on authentication
and who is calling. 

Brian

> -----Original Message-----
> From: Snyder, Duke [mailto:Duke.Snyder@inin.com]
> Sent: Saturday, October 26, 2002 7:23 PM
> To: sip@ietf.org
> Subject: [Sip] Standard mechanism to instruct the phone go off hook
> 
> 
> Has any work been done to have a standard mechanism for an 
> application to request that the phone answer it's "alerting" 
> call by going off hook (to speaker mode).   Currently, 
> different hard IP phones have a different ways to 
> "auto-answer", but it complicates SIP development working 
> with proprietary, non-SIP techniques.   The PhoneControl 
> draft 
> (http://www.cs.columbia.edu/~hgs/sip/drafts/draft-dean-phonect
> l-03.txt) seems to do some phone control, but not the 
> auto-answer request.
> 
> Common scenarios for this request:
> *	A call center agent typically uses auto-answer for his 
> call center calls.  His SIP app (based off his configuration) 
> could send the call to his phone (with a headset), request 
> that the phone answer the call, and the agent handles the 
> call completely hands-free.
> *	A call center supervisor selects a call to monitor.  
> His SIP app will direct the audio of the call to his phone, 
> but first must call his phone to establish an audio path.  
> Again, typically the supervisor would like the phone to 
> automatically go off hook rather than forcing him to answer the phone.
> 
> Authentication would need to be used since most people would 
> not want their SIP phone in their bedroom to go off hook.
> 
> 
> Duke Snyder
> Interactive Intelligence, Inc.
> www.inin.com
> 
> 
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Thu Oct 31 07:20:44 2002
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 HAA15705
	for <sip-archive@odin.ietf.org>; Thu, 31 Oct 2002 07:20:44 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9VCMdg27500
	for sip-archive@odin.ietf.org; Thu, 31 Oct 2002 07:22:39 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VCMAv27438;
	Thu, 31 Oct 2002 07:22: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 g9VCLDv27383
	for <sip@optimus.ietf.org>; Thu, 31 Oct 2002 07:21:13 -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 HAA15612
	for <sip@ietf.org>; Thu, 31 Oct 2002 07:18:47 -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 g9VCKkO25002
	for <sip@ietf.org>; Thu, 31 Oct 2002 14:20:46 +0200 (EET)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5e473c72abac158f21082@esvir01nok.ntc.nokia.com>;
 Thu, 31 Oct 2002 14:21:09 +0200
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Thu, 31 Oct 2002 14:21:09 +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: [Sip] SIPS question
Date: Thu, 31 Oct 2002 14:21:08 +0200
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE6F61@esebe019.ntc.nokia.com>
Thread-Topic: [Sip] SIPS question
Thread-Index: AcKA0d519MrYPCgKTqWSVIWSf8yWUwABO+iA
To: <christer.holmberg@lmf.ericsson.se>
Cc: <jon.peterson@neustar.biz>, <sip@ietf.org>
X-OriginalArrivalTime: 31 Oct 2002 12:21:09.0610 (UTC) FILETIME=[FE82BCA0:01C280D7]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9VCLDv27384
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit



> -----Original Message-----
> From: ext Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se]
> Sent: Thursday, October 31, 2002 1:37 PM
> To: Khartabil Hisham (NMP/Helsinki)
> Cc: jon.peterson@neustar.biz; sip@ietf.org
> Subject: Re: [Sip] SIPS question
> 
> 
> 
> 
> hisham.khartabil@nokia.com wrote:
> 
> > > -----Original Message-----
> > > From: ext Christer Holmberg 
> [mailto:christer.holmberg@lmf.ericsson.se]
> > > Sent: Thursday, October 31, 2002 12:31 PM
> > > To: Khartabil Hisham (NMP/Helsinki)
> > > Cc: jon.peterson@neustar.biz; sip@ietf.org
> > > Subject: Re: [Sip] SIPS question
> > >
> > >
> > >
> > > Hi,
> > >
> > > > I guess UA2 should have registered with P1 using a sips-uri
> > > in the contact-header. P1 doesn't care about the
> > > contact-header sent in the 200 OK. UA2 contact-header is
> > > telling UA1 (not P1) to contact it using TLS.
> > >
> > > No, but the Contact header value will be used in requests
> > > during the session, as part of the route set or Request-URI
> > > (depending on if loose routing is used etc)
> >
> > What I meant to say is that if UA2 had registered with P1 
> using a sips-uri in the contact-header, then when P1 is 
> routing the INVITE, it will put sips-uri in the record-route 
> header since the request uri (retrieved from the registrar) 
> is a sips-uri.
> 
> > Since P1 contacted UA2 using sips, the 200 ok must contain 
> a contact-header with sips-uri.
> 
> Ok. So, in this case UA1 will receive a Record-Route with 
> SIPS-URI. So, the next time UA1 sends a request the SIPS-URI 
> indicates it shall use TLS - which UA1 may not even support.

No, P1 will modify the record-route header in the response and will make it a sip-uri.

> 
> And, since UA1 used SIP-URI in its own Contact header, P1 
> shall use UDP (or TCP) to forward requests received from UA2, 
> so now we would have the separate-transport-in-each-direction 
> problem between UA1 and P1, wouldn't we?

UA1 will have a different route-set that UA2.

/Hisham


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



From mailnull@www1.ietf.org  Thu Oct 31 07:43:12 2002
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 HAA16824
	for <sip-archive@odin.ietf.org>; Thu, 31 Oct 2002 07:43:12 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9VCj7w29181
	for sip-archive@odin.ietf.org; Thu, 31 Oct 2002 07:45:07 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VCiev29156;
	Thu, 31 Oct 2002 07:44: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 g9VCh3v29121
	for <sip@optimus.ietf.org>; Thu, 31 Oct 2002 07:43:03 -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 HAA16789
	for <sip@ietf.org>; Thu, 31 Oct 2002 07:40:37 -0500 (EST)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9VCgxQ1016706;
	Thu, 31 Oct 2002 13:42:59 +0100 (MET)
Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.112])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g9VCgxG3002779;
	Thu, 31 Oct 2002 14:42:59 +0200 (EET)
Message-ID: <3DC12554.E964A4A5@lmf.ericsson.se>
Date: Thu, 31 Oct 2002 14:43:00 +0200
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: hisham.khartabil@nokia.com
CC: jon.peterson@neustar.biz, sip@ietf.org
Subject: Re: [Sip] SIPS question
References: <2038BCC78B1AD641891A0D1AE133DBB7FE6F61@esebe019.ntc.nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit


Hi,

> > > > Hi,
> > > >
> > > > > I guess UA2 should have registered with P1 using a sips-uri
> > > > in the contact-header. P1 doesn't care about the
> > > > contact-header sent in the 200 OK. UA2 contact-header is
> > > > telling UA1 (not P1) to contact it using TLS.
> > > >
> > > > No, but the Contact header value will be used in requests
> > > > during the session, as part of the route set or Request-URI
> > > > (depending on if loose routing is used etc)
> > >
> > > What I meant to say is that if UA2 had registered with P1
> > using a sips-uri in the contact-header, then when P1 is
> > routing the INVITE, it will put sips-uri in the record-route
> > header since the request uri (retrieved from the registrar)
> > is a sips-uri.
> >
> > > Since P1 contacted UA2 using sips, the 200 ok must contain
> > a contact-header with sips-uri.
> >
> > Ok. So, in this case UA1 will receive a Record-Route with
> > SIPS-URI. So, the next time UA1 sends a request the SIPS-URI
> > indicates it shall use TLS - which UA1 may not even support.
>
> No, P1 will modify the record-route header in the response and will make it a sip-uri.

> >And, since UA1 used SIP-URI in its own Contact header, P1
> >shall use UDP (or TCP) to forward requests received from UA2,
> >so now we would have the separate-transport-in-each-direction
> >problem between UA1 and P1, wouldn't we?
>
> UA1 will have a different route-set that UA2.

True.

However, EVEN if UA2 has registered itself with P1 using SIPS-URI, and P1 uses TLS to
contact it, UA1 will still receive a Contact header with SIPS-URI, and according to the
RFC ("if the Request-URI is SIPS-URI, TLS MUST be used") it would have to use TLS for the
other requests, even if it doesn't support TLS, and even if the requests aren't even sent
to UA2 (UA1 send them to P1, which record-routed).

Regards,

Christer Holmberg
Ericsson Finland


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



From mailnull@www1.ietf.org  Thu Oct 31 08:06:05 2002
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 IAA17522
	for <sip-archive@odin.ietf.org>; Thu, 31 Oct 2002 08:06:05 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9VD80b30543
	for sip-archive@odin.ietf.org; Thu, 31 Oct 2002 08:08:00 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VD7Sv30478;
	Thu, 31 Oct 2002 08:07: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 g9VD6gv29866
	for <sip@optimus.ietf.org>; Thu, 31 Oct 2002 08:06:42 -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 IAA17436
	for <sip@ietf.org>; Thu, 31 Oct 2002 08:04:15 -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 g9VD6S920856;
	Thu, 31 Oct 2002 13:06:28 GMT
Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19)
	id <V5JAVBCP>; Thu, 31 Oct 2002 13:06:28 -0000
Message-ID: <A3C2399B2FACD411A54200508BE39C74054F7898@zwcwd00r.europe.nortel.com>
From: "Mark Watson" <mwatson@nortelnetworks.com>
To: "'hbhondwe@hss.hns.com'" <hbhondwe@hss.hns.com>
Cc: sip@ietf.org
Subject: RE: [Sip] draft-ietf-sip-asserted-identity-02.txt: ppi from trust
	 ed entity
Date: Thu, 31 Oct 2002 13:06:24 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C280DE.50948662"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-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_01C280DE.50948662
Content-Type: text/plain;
	charset="iso-8859-1"

Harsh,

See comments inline...

> -----Original Message-----
> From: hbhondwe@hss.hns.com [mailto:hbhondwe@hss.hns.com]
> Sent: 31 October 2002 03:58
> To: Watson, Mark [MOP:EP10:EXCH]
> Cc: sip@ietf.org; hbhondwe@hss.hns.com
> Subject: RE: [Sip] draft-ietf-sip-asserted-identity-02.txt: ppi from
> trust ed entity
> 
> 
> 
> 
> Mark,
> 
> I understand the point that you've made and that  how a proxy uses the
> P-Preferred-Identity headers
> received from a user agent is a policy decision.
> 
> I got confused because of the first statement in Section 6 
> which reads:
> 'If a P-Preferred-Identity header field is present in the message that
>    a proxy receives from an entity that it does not trust.....'.
> 
> Is this statement then equivalent to the following?
> 'If a P-Preferred-Identity header field is present in the message that
>    a proxy receives from a user agent.....'.
> 

No, in this draft 'an entity that [the proxy] does not trust' formally means
'an entity outside the Trust Domain for Asserted Identity of which the proxy
is a member'.

Normal User Agents will usually be outside the Trust Domain. But a User
Agent such as a PSTN gateway may be inside the Trust Domain.

Another proxy could be either inside or outside the Trust Domain. The
requirements that have to be met for another proxy to be considered inside
the Trust Domain are defined in the definition of a particular Trust Domain
(called Spec(T)). The minimum things that Spec(T) has to include to make the
mechanism work are described in the drafts.

> I was also trying to understand why the P-Preferred-Identity MUST be
> removed
> by a proxy from any message that it forwards.Would it be 
> correct to say
> that the reason lies in
> requirments themselves, as put forward in
> draft-ietf-sipping-nai-reqs-02.txt , section 3 of which reads
> 
> 'It shall be possible for a UA to provide a preferred identity to the
>    network intermediary, which MAY be used to inform the generation of
>    the Network Asserted Identity according to the policies of 
> the Trust
>    Domain.'.
> 
> And therefore the significance of P-Preferred-Identity exists 
> only between
> a UA and the proxy that performs its authentication.
> 

Yes.

> 
> thanks
> harsh
> 
> 
> 
> 
> 
> 
> 
> "Mark Watson" <mwatson@nortelnetworks.com> on 10/30/2002 07:13:39 PM
> 
> To:   Harsh Bhondwe/HSSBLR, sip@ietf.org
> cc:
> 
> Subject:  RE: [Sip] draft-ietf-sip-asserted-identity-02.txt: 
> ppi from trust
>       ed entity
> 
> 
> 
> 
> Harsh,
> 
> From memory, a proxy should not expect to receive 
> P-Preferred-Identity from
> another member of the Trust Domain for Asserted Identity.
> 
> You may be right that the behaviour if it is received is not 
> specified. If
> a
> P-Asserted-Identity is present, then I would expect the
> P-Preferred-Identity
> to be discarded (they should not coexist). If there is no
> P-Asserted-Identity, then I suppose the Proxy could behave as if the
> message
> were received from outside the Trust Domain...
> 
> If P-Preferred-Identity is received from outside the Trust Domain, the
> proxy
> attempts to authenticate the originator of the message.
> 
> You ask whether the proxy MAY or MUST use the 
> P-Preferred-Identity, but I'm
> not sure the question makes sense. If it were a MAY, then 
> whether to use it
> or not must be a matter of local policy for the proxy. If it 
> were a MUST,
> then as long as the P-Preferred-Identity is 'a valid identity for that
> user'
> then it MUST use it. But the list of 'valid identities for 
> that user' is a
> matter of local policy too. So there is no difference.
> 
> For example, if the proxy NEVER uses P-Preferred-Identity, 
> then this is
> equivalent to saying that there is only one valid identity 
> for the user.
> 
> Regards,
> 
> Mark Watson
> 
> 
> > -----Original Message-----
> > From: hbhondwe@hss.hns.com [mailto:hbhondwe@hss.hns.com]
> > Sent: 29 October 2002 05:30
> > To: sip@ietf.org
> > Cc: hbhondwe@hss.hns.com
> > Subject: [Sip] draft-ietf-sip-asserted-identity-02.txt: ppi
> > from trusted
> > entity
> >
> >
> >
> >
> > Hi,
> >
> > Section 6 does not seem to explicitely specify proxy's 
> behaviour when
> > p-preferred-identity header is received by a proxy from a
> > trusted entity:
> >
> > a)preferred identity corresponds to a valid identify known to
> > the proxy for
> > that user.
> > -MUST the proxy use this identity or  MAY it ? I assume it MUST.
> > b)preferred identity does not correspond to a valid identity
> > known to the
> > proxy for that user.
> > -Should the proxy behaviour be same as when the entity from 
> which the
> > header was received is not trusted.
> >
> >
> > 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.
> >
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip
> >
> 
> 

------_=_NextPart_001_01C280DE.50948662
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: [Sip] draft-ietf-sip-asserted-identity-02.txt: ppi from =
trust ed entity</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Harsh,</FONT>
</P>

<P><FONT SIZE=3D2>See comments inline...</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: hbhondwe@hss.hns.com [<A =
HREF=3D"mailto:hbhondwe@hss.hns.com">mailto:hbhondwe@hss.hns.com</A>]</F=
ONT>
<BR><FONT SIZE=3D2>&gt; Sent: 31 October 2002 03:58</FONT>
<BR><FONT SIZE=3D2>&gt; To: Watson, Mark [MOP:EP10:EXCH]</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: sip@ietf.org; hbhondwe@hss.hns.com</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: [Sip] =
draft-ietf-sip-asserted-identity-02.txt: ppi from</FONT>
<BR><FONT SIZE=3D2>&gt; trust ed entity</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </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; </FONT>
<BR><FONT SIZE=3D2>&gt; I understand the point that you've made and =
that&nbsp; how a proxy uses the</FONT>
<BR><FONT SIZE=3D2>&gt; P-Preferred-Identity headers</FONT>
<BR><FONT SIZE=3D2>&gt; received from a user agent is a policy =
decision.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I got confused because of the first statement =
in Section 6 </FONT>
<BR><FONT SIZE=3D2>&gt; which reads:</FONT>
<BR><FONT SIZE=3D2>&gt; 'If a P-Preferred-Identity header field is =
present in the message that</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; a proxy receives from an =
entity that it does not trust.....'.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Is this statement then equivalent to the =
following?</FONT>
<BR><FONT SIZE=3D2>&gt; 'If a P-Preferred-Identity header field is =
present in the message that</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; a proxy receives from a user =
agent.....'.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>No, in this draft 'an entity that [the proxy] does =
not trust' formally means 'an entity outside the Trust Domain for =
Asserted Identity of which the proxy is a member'.</FONT></P>

<P><FONT SIZE=3D2>Normal User Agents will usually be outside the Trust =
Domain. But a User Agent such as a PSTN gateway may be inside the Trust =
Domain.</FONT></P>

<P><FONT SIZE=3D2>Another proxy could be either inside or outside the =
Trust Domain. The requirements that have to be met for another proxy to =
be considered inside the Trust Domain are defined in the definition of =
a particular Trust Domain (called Spec(T)). The minimum things that =
Spec(T) has to include to make the mechanism work are described in the =
drafts.</FONT></P>

<P><FONT SIZE=3D2>&gt; I was also trying to understand why the =
P-Preferred-Identity MUST be</FONT>
<BR><FONT SIZE=3D2>&gt; removed</FONT>
<BR><FONT SIZE=3D2>&gt; by a proxy from any message that it =
forwards.Would it be </FONT>
<BR><FONT SIZE=3D2>&gt; correct to say</FONT>
<BR><FONT SIZE=3D2>&gt; that the reason lies in</FONT>
<BR><FONT SIZE=3D2>&gt; requirments themselves, as put forward =
in</FONT>
<BR><FONT SIZE=3D2>&gt; draft-ietf-sipping-nai-reqs-02.txt , section 3 =
of which reads</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 'It shall be possible for a UA to provide a =
preferred identity to the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; network intermediary, which =
MAY be used to inform the generation of</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; the Network Asserted Identity =
according to the policies of </FONT>
<BR><FONT SIZE=3D2>&gt; the Trust</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; Domain.'.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; And therefore the significance of =
P-Preferred-Identity exists </FONT>
<BR><FONT SIZE=3D2>&gt; only between</FONT>
<BR><FONT SIZE=3D2>&gt; a UA and the proxy that performs its =
authentication.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>Yes.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; thanks</FONT>
<BR><FONT SIZE=3D2>&gt; harsh</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;Mark Watson&quot; =
&lt;mwatson@nortelnetworks.com&gt; on 10/30/2002 07:13:39 PM</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; To:&nbsp;&nbsp; Harsh Bhondwe/HSSBLR, =
sip@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; cc:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Subject:&nbsp; RE: [Sip] =
draft-ietf-sip-asserted-identity-02.txt: </FONT>
<BR><FONT SIZE=3D2>&gt; ppi from trust</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ed =
entity</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Harsh,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; From memory, a proxy should not expect to =
receive </FONT>
<BR><FONT SIZE=3D2>&gt; P-Preferred-Identity from</FONT>
<BR><FONT SIZE=3D2>&gt; another member of the Trust Domain for Asserted =
Identity.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; You may be right that the behaviour if it is =
received is not </FONT>
<BR><FONT SIZE=3D2>&gt; specified. If</FONT>
<BR><FONT SIZE=3D2>&gt; a</FONT>
<BR><FONT SIZE=3D2>&gt; P-Asserted-Identity is present, then I would =
expect the</FONT>
<BR><FONT SIZE=3D2>&gt; P-Preferred-Identity</FONT>
<BR><FONT SIZE=3D2>&gt; to be discarded (they should not coexist). If =
there is no</FONT>
<BR><FONT SIZE=3D2>&gt; P-Asserted-Identity, then I suppose the Proxy =
could behave as if the</FONT>
<BR><FONT SIZE=3D2>&gt; message</FONT>
<BR><FONT SIZE=3D2>&gt; were received from outside the Trust =
Domain...</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; If P-Preferred-Identity is received from =
outside the Trust Domain, the</FONT>
<BR><FONT SIZE=3D2>&gt; proxy</FONT>
<BR><FONT SIZE=3D2>&gt; attempts to authenticate the originator of the =
message.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; You ask whether the proxy MAY or MUST use the =
</FONT>
<BR><FONT SIZE=3D2>&gt; P-Preferred-Identity, but I'm</FONT>
<BR><FONT SIZE=3D2>&gt; not sure the question makes sense. If it were a =
MAY, then </FONT>
<BR><FONT SIZE=3D2>&gt; whether to use it</FONT>
<BR><FONT SIZE=3D2>&gt; or not must be a matter of local policy for the =
proxy. If it </FONT>
<BR><FONT SIZE=3D2>&gt; were a MUST,</FONT>
<BR><FONT SIZE=3D2>&gt; then as long as the P-Preferred-Identity is 'a =
valid identity for that</FONT>
<BR><FONT SIZE=3D2>&gt; user'</FONT>
<BR><FONT SIZE=3D2>&gt; then it MUST use it. But the list of 'valid =
identities for </FONT>
<BR><FONT SIZE=3D2>&gt; that user' is a</FONT>
<BR><FONT SIZE=3D2>&gt; matter of local policy too. So there is no =
difference.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; For example, if the proxy NEVER uses =
P-Preferred-Identity, </FONT>
<BR><FONT SIZE=3D2>&gt; then this is</FONT>
<BR><FONT SIZE=3D2>&gt; equivalent to saying that there is only one =
valid identity </FONT>
<BR><FONT SIZE=3D2>&gt; for the user.</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; Mark Watson</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: hbhondwe@hss.hns.com [<A =
HREF=3D"mailto:hbhondwe@hss.hns.com">mailto:hbhondwe@hss.hns.com</A>]</F=
ONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: 29 October 2002 05:30</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: sip@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Cc: hbhondwe@hss.hns.com</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: [Sip] =
draft-ietf-sip-asserted-identity-02.txt: ppi</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; from trusted</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; entity</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Hi,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Section 6 does not seem to explicitely =
specify proxy's </FONT>
<BR><FONT SIZE=3D2>&gt; behaviour when</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; p-preferred-identity header is received by =
a proxy from a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; trusted entity:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; a)preferred identity corresponds to a =
valid identify known to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the proxy for</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; that user.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -MUST the proxy use this identity or&nbsp; =
MAY it ? I assume it MUST.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; b)preferred identity does not correspond =
to a valid identity</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; known to the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; proxy for that user.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -Should the proxy behaviour be same as =
when the entity from </FONT>
<BR><FONT SIZE=3D2>&gt; which the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; header was received is not trusted.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; thanks</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; harsh</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; This message is proprietary to Hughes =
Software Systems</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Limited (HSS) and is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; intended solely for the use of the =
individual to whom it is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; addressed.&nbsp; It</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; may contain privileged or confidential =
information and should not be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; circulated or used for any purpose other =
than for what it is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; intended.&nbsp; If</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; you have received this message in error, =
please notify the </FONT>
<BR><FONT SIZE=3D2>&gt; originator</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; immediately.&nbsp; If you are not the =
intended recipient, you are</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; notified that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; you are strictly prohibited from using, =
copying, altering, or</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; disclosing</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the contents of this message.&nbsp; HSS =
accepts no responsibility</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; for loss or</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; damage arising from the use of the =
information transmitted by</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; this email</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; including damage from virus.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sip mailing list&nbsp; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/sip" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/sip</A></FONT>
<BR><FONT SIZE=3D2>&gt; &gt; This list is for NEW development of the =
core SIP Protocol</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Use sip-implementors@cs.columbia.edu for =
questions on current sip</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Use sipping@ietf.org for new developments =
on the application of sip</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_01C280DE.50948662--
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Thu Oct 31 08:23:27 2002
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 IAA18045
	for <sip-archive@odin.ietf.org>; Thu, 31 Oct 2002 08:23:27 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9VDPM331056
	for sip-archive@odin.ietf.org; Thu, 31 Oct 2002 08:25:22 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VDOVv31024;
	Thu, 31 Oct 2002 08: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 g9VDN3v30984
	for <sip@optimus.ietf.org>; Thu, 31 Oct 2002 08:23:03 -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 IAA17941
	for <sip@ietf.org>; Thu, 31 Oct 2002 08:20:36 -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 g9VDNKB03490
	for <sip@ietf.org>; Thu, 31 Oct 2002 15:23:20 +0200 (EET)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5e47750bebac158f23077@esvir03nok.nokia.com>;
 Thu, 31 Oct 2002 15:22:58 +0200
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Thu, 31 Oct 2002 15:22:57 +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: [Sip] SIPS question
Date: Thu, 31 Oct 2002 15:22:56 +0200
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE6F62@esebe019.ntc.nokia.com>
Thread-Topic: [Sip] SIPS question
Thread-Index: AcKA2w3Nk3a7Q1VJQyKmtniKgS2WvwABRcgA
To: <christer.holmberg@lmf.ericsson.se>
Cc: <jon.peterson@neustar.biz>, <sip@ietf.org>
X-OriginalArrivalTime: 31 Oct 2002 13:22:57.0757 (UTC) FILETIME=[A0BD10D0:01C280E0]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9VDN3v30985
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit

I guess the problem is in this sentence in section 12.1.1 UAS Behaviour

"If the request that initiated the dialog contained a
   SIPS URI in the Request-URI or in the top Record-Route header field
   value, if there was any, or the Contact header field if there was no
   Record-Route header field, the Contact header field in the response
   MUST be a SIPS URI"

Even though UAC sent an INVITE with contact containing sip-uri, UAS can send a 200 with contact containing sips-uri (proxy added a record-route with sips-uri or request-uri is sips-uri). What does UAC do in this situation when its sending a reinvite and it doesn't support TLS?

Regards,
Hisham

> -----Original Message-----
> From: ext Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se]
> Sent: Thursday, October 31, 2002 2:43 PM
> To: Khartabil Hisham (NMP/Helsinki)
> Cc: jon.peterson@neustar.biz; sip@ietf.org
> Subject: Re: [Sip] SIPS question
> 
> 
> 
> Hi,
> 
> > > > > Hi,
> > > > >
> > > > > > I guess UA2 should have registered with P1 using a sips-uri
> > > > > in the contact-header. P1 doesn't care about the
> > > > > contact-header sent in the 200 OK. UA2 contact-header is
> > > > > telling UA1 (not P1) to contact it using TLS.
> > > > >
> > > > > No, but the Contact header value will be used in requests
> > > > > during the session, as part of the route set or Request-URI
> > > > > (depending on if loose routing is used etc)
> > > >
> > > > What I meant to say is that if UA2 had registered with P1
> > > using a sips-uri in the contact-header, then when P1 is
> > > routing the INVITE, it will put sips-uri in the record-route
> > > header since the request uri (retrieved from the registrar)
> > > is a sips-uri.
> > >
> > > > Since P1 contacted UA2 using sips, the 200 ok must contain
> > > a contact-header with sips-uri.
> > >
> > > Ok. So, in this case UA1 will receive a Record-Route with
> > > SIPS-URI. So, the next time UA1 sends a request the SIPS-URI
> > > indicates it shall use TLS - which UA1 may not even support.
> >
> > No, P1 will modify the record-route header in the response 
> and will make it a sip-uri.
> 
> > >And, since UA1 used SIP-URI in its own Contact header, P1
> > >shall use UDP (or TCP) to forward requests received from UA2,
> > >so now we would have the separate-transport-in-each-direction
> > >problem between UA1 and P1, wouldn't we?
> >
> > UA1 will have a different route-set that UA2.
> 
> True.
> 
> However, EVEN if UA2 has registered itself with P1 using 
> SIPS-URI, and P1 uses TLS to
> contact it, UA1 will still receive a Contact header with 
> SIPS-URI, and according to the
> RFC ("if the Request-URI is SIPS-URI, TLS MUST be used") it 
> would have to use TLS for the
> other requests, even if it doesn't support TLS, and even if 
> the requests aren't even sent
> to UA2 (UA1 send them to P1, which record-routed).
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> 
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Thu Oct 31 08:47:23 2002
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 IAA18966
	for <sip-archive@odin.ietf.org>; Thu, 31 Oct 2002 08:47:23 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9VDnJ932440
	for sip-archive@odin.ietf.org; Thu, 31 Oct 2002 08:49:19 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VDmlv32415;
	Thu, 31 Oct 2002 08:48: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 g9VDiKv32253
	for <sip@optimus.ietf.org>; Thu, 31 Oct 2002 08:44:20 -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 IAA18661
	for <sip@ietf.org>; Thu, 31 Oct 2002 08:41:53 -0500 (EST)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9VDiGQ1008331;
	Thu, 31 Oct 2002 14:44:16 +0100 (MET)
Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.112])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g9VDiFG3006951;
	Thu, 31 Oct 2002 15:44:15 +0200 (EET)
Message-ID: <3DC133B1.E3BA3F27@lmf.ericsson.se>
Date: Thu, 31 Oct 2002 15:44:17 +0200
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: hisham.khartabil@nokia.com
CC: jon.peterson@neustar.biz, sip@ietf.org
Subject: Re: [Sip] SIPS question
References: <2038BCC78B1AD641891A0D1AE133DBB7FE6F62@esebe019.ntc.nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit


Hi,

> I guess the problem is in this sentence in section 12.1.1 UAS Behaviour
>
> "If the request that initiated the dialog contained a
>    SIPS URI in the Request-URI or in the top Record-Route header field
>    value, if there was any, or the Contact header field if there was no
>    Record-Route header field, the Contact header field in the response
>    MUST be a SIPS URI"

Yes, and from a UAC point of view, I think the text in chapter 26.2.2 is the problem:

"When used as the Request-URI of a request, the SIPS scheme signifies that each hop over which the
request is forwarded, until the request reaches the SIP entity responsible for the domain portion of the Request-URI, must be
secured with TLS;"

Again, to my understanding this indicate that TLS shall be used, even if the message isn't even sent to the Request-URI, but to the top route.

> Even though UAC sent an INVITE with contact containing sip-uri, UAS can send a 200 with contact containing sips-uri (proxy added a record-route with sips-uri or request-uri is sips-uri). What does UAC do in this situation when its sending a reinvite and it doesn't support TLS?

Exactly :)

Regards,

Christer


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



From mailnull@www1.ietf.org  Thu Oct 31 16:26:05 2002
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 QAA15839
	for <sip-archive@odin.ietf.org>; Thu, 31 Oct 2002 16:26:05 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id g9VLS2h30822
	for sip-archive@odin.ietf.org; Thu, 31 Oct 2002 16:28:02 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VLRHv30725;
	Thu, 31 Oct 2002 16:27: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 g9VLPGv30582
	for <sip@optimus.ietf.org>; Thu, 31 Oct 2002 16:25:16 -0500
Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15701
	for <sip@ietf.org>; Thu, 31 Oct 2002 16:22:47 -0500 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 31 Oct 2002 13:25:09 -0800
Received: from 213.243.142.147 by lw9fd.law9.hotmail.msn.com with HTTP;
	Thu, 31 Oct 2002 21:25:09 GMT
X-Originating-IP: [213.243.142.147]
From: "Janne Kario" <jkario78@hotmail.com>
To: sip@ietf.org
Date: Thu, 31 Oct 2002 23:25:09 +0200
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F125T8Pzlh3xtimqRMM0001f71e@hotmail.com>
X-OriginalArrivalTime: 31 Oct 2002 21:25:09.0492 (UTC) FILETIME=[FD657B40:01C28123]
Subject: [Sip] (no subject)
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

A quick question. What is the relation between

draft-ietf-sip-asserted-identity-02

and

draft-peterson-sip-identity-01

It seems to me that they have some overlapping functions.

_________________________________________________________________
Surf the Web without missing calls! Get MSN Broadband.  
http://resourcecenter.msn.com/access/plans/freeactivation.asp

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



From mailnull@www1.ietf.org  Thu Oct 31 20:35:55 2002
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 UAA22980
	for <sip-archive@odin.ietf.org>; Thu, 31 Oct 2002 20:35:55 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA11bu813048
	for sip-archive@odin.ietf.org; Thu, 31 Oct 2002 20:37:56 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA11bLv13031;
	Thu, 31 Oct 2002 20: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 gA11Zpv12373
	for <sip@optimus.ietf.org>; Thu, 31 Oct 2002 20:35:51 -0500
Received: from dnsmx1pya.telcordia.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22930
	for <sip@ietf.org>; Thu, 31 Oct 2002 20:33:14 -0500 (EST)
From: ysong@telcordia.com
Received: from notes900.cc.telcordia.com (notes900.cc.telcordia.com [128.96.79.7])
	by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with ESMTP id UAA00392;
	Thu, 31 Oct 2002 20:33:49 -0500 (EST)
To: sip@ietf.org, "Mark Watson" <mwatson@nortelnetworks.com>
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF2CBA0911.7457D136-ON85256C64.00070CFE@cc.telcordia.com>
Date: Thu, 31 Oct 2002 20:33:56 -0500
X-MIMETrack: Serialize by Router on notes900/Telcordia(Release 5.0.6a |January 17, 2001) at
 10/31/2002 08:33:59 PM
MIME-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=85256C6400070CFE8f9e8a93df938690918c85256C6400070CFE"
Content-Disposition: inline
Subject: [Sip] question on draft-ietf-sip-asserted-identity-02.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

--0__=85256C6400070CFE8f9e8a93df938690918c85256C6400070CFE
Content-type: text/plain; charset=us-ascii


Hi,

On page 8, in Table 2 for the P-Asserted-Identity header, the header is not
allowed in SIP INFO method. Is there any special reason?

The scenario i have is the case where a UAC (gateway) sends an initial
INVITE to a UAS without a calling name as the name information is not yet
available and then sends a calling name in a subsequent INFO method before
the UAS answers, assuming an early call leg is established. In this case,
couldn't the P-Asserted-Identity header be sent in the INFO carrying the
calling name? The UAC can wait until the calling name is available before
sending the initial INVITE, but this scenario may be considered to minimize
call setup delay.

Thanks,
YoungSun



                                                                                                
                    "Mark Watson"                                                               
                    <mwatson@nortelnet        To:     "'hbhondwe@hss.hns.com'"                  
                    works.com>                <hbhondwe@hss.hns.com>                            
                                              cc:     sip@ietf.org, (bcc: Youngsun              
                    10/31/2002 08:06          Song/Telcordia)                                   
                    AM                        Subject:     RE: [Sip]                            
                                              draft-ietf-sip-asserted-identity-02.txt: ppi from 
                                              trust    ed entity                                
                                                                                                





Harsh,

See comments inline...

> -----Original Message-----
> From: hbhondwe@hss.hns.com [mailto:hbhondwe@hss.hns.com]
> Sent: 31 October 2002 03:58
> To: Watson, Mark [MOP:EP10:EXCH]
> Cc: sip@ietf.org; hbhondwe@hss.hns.com
> Subject: RE: [Sip] draft-ietf-sip-asserted-identity-02.txt: ppi from
> trust ed entity
>
>
>
>
> Mark,
>
> I understand the point that you've made and that  how a proxy uses the
> P-Preferred-Identity headers
> received from a user agent is a policy decision.
>
> I got confused because of the first statement in Section 6
> which reads:
> 'If a P-Preferred-Identity header field is present in the message that
>    a proxy receives from an entity that it does not trust.....'.
>
> Is this statement then equivalent to the following?
> 'If a P-Preferred-Identity header field is present in the message that
>    a proxy receives from a user agent.....'.
>

No, in this draft 'an entity that [the proxy] does not trust' formally
means
'an entity outside the Trust Domain for Asserted Identity of which the
proxy
is a member'.

Normal User Agents will usually be outside the Trust Domain. But a User
Agent such as a PSTN gateway may be inside the Trust Domain.

Another proxy could be either inside or outside the Trust Domain. The
requirements that have to be met for another proxy to be considered inside
the Trust Domain are defined in the definition of a particular Trust Domain
(called Spec(T)). The minimum things that Spec(T) has to include to make
the
mechanism work are described in the drafts.

> I was also trying to understand why the P-Preferred-Identity MUST be
> removed
> by a proxy from any message that it forwards.Would it be
> correct to say
> that the reason lies in
> requirments themselves, as put forward in
> draft-ietf-sipping-nai-reqs-02.txt , section 3 of which reads
>
> 'It shall be possible for a UA to provide a preferred identity to the
>    network intermediary, which MAY be used to inform the generation of
>    the Network Asserted Identity according to the policies of
> the Trust
>    Domain.'.
>
> And therefore the significance of P-Preferred-Identity exists
> only between
> a UA and the proxy that performs its authentication.
>

Yes.

>
> thanks
> harsh
>
>
>
>
>
>
>
> "Mark Watson" <mwatson@nortelnetworks.com> on 10/30/2002 07:13:39 PM
>
> To:   Harsh Bhondwe/HSSBLR, sip@ietf.org
> cc:
>
> Subject:  RE: [Sip] draft-ietf-sip-asserted-identity-02.txt:
> ppi from trust
>       ed entity
>
>
>
>
> Harsh,
>
> From memory, a proxy should not expect to receive
> P-Preferred-Identity from
> another member of the Trust Domain for Asserted Identity.
>
> You may be right that the behaviour if it is received is not
> specified. If
> a
> P-Asserted-Identity is present, then I would expect the
> P-Preferred-Identity
> to be discarded (they should not coexist). If there is no
> P-Asserted-Identity, then I suppose the Proxy could behave as if the
> message
> were received from outside the Trust Domain...
>
> If P-Preferred-Identity is received from outside the Trust Domain, the
> proxy
> attempts to authenticate the originator of the message.
>
> You ask whether the proxy MAY or MUST use the
> P-Preferred-Identity, but I'm
> not sure the question makes sense. If it were a MAY, then
> whether to use it
> or not must be a matter of local policy for the proxy. If it
> were a MUST,
> then as long as the P-Preferred-Identity is 'a valid identity for that
> user'
> then it MUST use it. But the list of 'valid identities for
> that user' is a
> matter of local policy too. So there is no difference.
>
> For example, if the proxy NEVER uses P-Preferred-Identity,
> then this is
> equivalent to saying that there is only one valid identity
> for the user.
>
> Regards,
>
> Mark Watson
>
>
> > -----Original Message-----
> > From: hbhondwe@hss.hns.com [mailto:hbhondwe@hss.hns.com]
> > Sent: 29 October 2002 05:30
> > To: sip@ietf.org
> > Cc: hbhondwe@hss.hns.com
> > Subject: [Sip] draft-ietf-sip-asserted-identity-02.txt: ppi
> > from trusted
> > entity
> >
> >
> >
> >
> > Hi,
> >
> > Section 6 does not seem to explicitely specify proxy's
> behaviour when
> > p-preferred-identity header is received by a proxy from a
> > trusted entity:
> >
> > a)preferred identity corresponds to a valid identify known to
> > the proxy for
> > that user.
> > -MUST the proxy use this identity or  MAY it ? I assume it MUST.
> > b)preferred identity does not correspond to a valid identity
> > known to the
> > proxy for that user.
> > -Should the proxy behaviour be same as when the entity from
> which the
> > header was received is not trusted.
> >
> >
> > 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.
> >
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip
> >
>
>

--0__=85256C6400070CFE8f9e8a93df938690918c85256C6400070CFE
Content-type: text/html; 
	name="att1.htm"
Content-Disposition: attachment; filename="att1.htm"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+
DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o
dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U
PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1NS4zNSI+DQo8VElUTEU+UkU6IFtT
aXBdIGRyYWZ0LWlldGYtc2lwLWFzc2VydGVkLWlkZW50aXR5LTAyLnR4dDogcHBpIGZyb20gdHJ1
c3QgZWQgZW50aXR5PC9USVRMRT4NCjwvSEVBRD4NCjxCT0RZPg0KDQo8UD48Rk9OVCBTSVpFPTI+
SGFyc2gsPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+U2VlIGNvbW1lbnRzIGlubGlu
ZS4uLjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPiZndDsgLS0tLS1PcmlnaW5hbCBN
ZXNzYWdlLS0tLS08L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgRnJvbTogaGJob25kd2VA
aHNzLmhucy5jb20gWzxBIEhSRUY9Im1haWx0bzpoYmhvbmR3ZUBoc3MuaG5zLmNvbSI+bWFpbHRv
OmhiaG9uZHdlQGhzcy5obnMuY29tPC9BPl08L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsg
U2VudDogMzEgT2N0b2JlciAyMDAyIDAzOjU4PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7
IFRvOiBXYXRzb24sIE1hcmsgW01PUDpFUDEwOkVYQ0hdPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9
Mj4mZ3Q7IENjOiBzaXBAaWV0Zi5vcmc7IGhiaG9uZHdlQGhzcy5obnMuY29tPC9GT05UPg0KPEJS
PjxGT05UIFNJWkU9Mj4mZ3Q7IFN1YmplY3Q6IFJFOiBbU2lwXSBkcmFmdC1pZXRmLXNpcC1hc3Nl
cnRlZC1pZGVudGl0eS0wMi50eHQ6IHBwaSBmcm9tPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4m
Z3Q7IHRydXN0IGVkIGVudGl0eTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+
DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZn
dDsgTWFyayw8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05U
IFNJWkU9Mj4mZ3Q7IEkgdW5kZXJzdGFuZCB0aGUgcG9pbnQgdGhhdCB5b3UndmUgbWFkZSBhbmQg
dGhhdCZuYnNwOyBob3cgYSBwcm94eSB1c2VzIHRoZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+
Jmd0OyBQLVByZWZlcnJlZC1JZGVudGl0eSBoZWFkZXJzPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9
Mj4mZ3Q7IHJlY2VpdmVkIGZyb20gYSB1c2VyIGFnZW50IGlzIGEgcG9saWN5IGRlY2lzaW9uLjwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZn
dDsgSSBnb3QgY29uZnVzZWQgYmVjYXVzZSBvZiB0aGUgZmlyc3Qgc3RhdGVtZW50IGluIFNlY3Rp
b24gNiA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgd2hpY2ggcmVhZHM6PC9GT05UPg0K
PEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICdJZiBhIFAtUHJlZmVycmVkLUlkZW50aXR5IGhlYWRlciBm
aWVsZCBpcyBwcmVzZW50IGluIHRoZSBtZXNzYWdlIHRoYXQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la
RT0yPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgYSBwcm94eSByZWNlaXZlcyBmcm9tIGFuIGVudGl0
eSB0aGF0IGl0IGRvZXMgbm90IHRydXN0Li4uLi4nLjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+
Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgSXMgdGhpcyBzdGF0ZW1lbnQgdGhl
biBlcXVpdmFsZW50IHRvIHRoZSBmb2xsb3dpbmc/PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4m
Z3Q7ICdJZiBhIFAtUHJlZmVycmVkLUlkZW50aXR5IGhlYWRlciBmaWVsZCBpcyBwcmVzZW50IGlu
IHRoZSBtZXNzYWdlIHRoYXQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsmbmJzcDsmbmJz
cDsmbmJzcDsgYSBwcm94eSByZWNlaXZlcyBmcm9tIGEgdXNlciBhZ2VudC4uLi4uJy48L0ZPTlQ+
DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+
Tm8sIGluIHRoaXMgZHJhZnQgJ2FuIGVudGl0eSB0aGF0IFt0aGUgcHJveHldIGRvZXMgbm90IHRy
dXN0JyBmb3JtYWxseSBtZWFucyAnYW4gZW50aXR5IG91dHNpZGUgdGhlIFRydXN0IERvbWFpbiBm
b3IgQXNzZXJ0ZWQgSWRlbnRpdHkgb2Ygd2hpY2ggdGhlIHByb3h5IGlzIGEgbWVtYmVyJy48L0ZP
TlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+Tm9ybWFsIFVzZXIgQWdlbnRzIHdpbGwgdXN1YWxs
eSBiZSBvdXRzaWRlIHRoZSBUcnVzdCBEb21haW4uIEJ1dCBhIFVzZXIgQWdlbnQgc3VjaCBhcyBh
IFBTVE4gZ2F0ZXdheSBtYXkgYmUgaW5zaWRlIHRoZSBUcnVzdCBEb21haW4uPC9GT05UPjwvUD4N
Cg0KPFA+PEZPTlQgU0laRT0yPkFub3RoZXIgcHJveHkgY291bGQgYmUgZWl0aGVyIGluc2lkZSBv
ciBvdXRzaWRlIHRoZSBUcnVzdCBEb21haW4uIFRoZSByZXF1aXJlbWVudHMgdGhhdCBoYXZlIHRv
IGJlIG1ldCBmb3IgYW5vdGhlciBwcm94eSB0byBiZSBjb25zaWRlcmVkIGluc2lkZSB0aGUgVHJ1
c3QgRG9tYWluIGFyZSBkZWZpbmVkIGluIHRoZSBkZWZpbml0aW9uIG9mIGEgcGFydGljdWxhciBU
cnVzdCBEb21haW4gKGNhbGxlZCBTcGVjKFQpKS4gVGhlIG1pbmltdW0gdGhpbmdzIHRoYXQgU3Bl
YyhUKSBoYXMgdG8gaW5jbHVkZSB0byBtYWtlIHRoZSBtZWNoYW5pc20gd29yayBhcmUgZGVzY3Jp
YmVkIGluIHRoZSBkcmFmdHMuPC9GT05UPjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPiZndDsgSSB3
YXMgYWxzbyB0cnlpbmcgdG8gdW5kZXJzdGFuZCB3aHkgdGhlIFAtUHJlZmVycmVkLUlkZW50aXR5
IE1VU1QgYmU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgcmVtb3ZlZDwvRk9OVD4NCjxC
Uj48Rk9OVCBTSVpFPTI+Jmd0OyBieSBhIHByb3h5IGZyb20gYW55IG1lc3NhZ2UgdGhhdCBpdCBm
b3J3YXJkcy5Xb3VsZCBpdCBiZSA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgY29ycmVj
dCB0byBzYXk8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgdGhhdCB0aGUgcmVhc29uIGxp
ZXMgaW48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgcmVxdWlybWVudHMgdGhlbXNlbHZl
cywgYXMgcHV0IGZvcndhcmQgaW48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgZHJhZnQt
aWV0Zi1zaXBwaW5nLW5haS1yZXFzLTAyLnR4dCAsIHNlY3Rpb24gMyBvZiB3aGljaCByZWFkczwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZn
dDsgJ0l0IHNoYWxsIGJlIHBvc3NpYmxlIGZvciBhIFVBIHRvIHByb3ZpZGUgYSBwcmVmZXJyZWQg
aWRlbnRpdHkgdG8gdGhlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IG5ldHdvcmsgaW50ZXJtZWRpYXJ5LCB3aGljaCBNQVkgYmUgdXNlZCB0byBpbmZvcm0g
dGhlIGdlbmVyYXRpb24gb2Y8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsmbmJzcDsmbmJz
cDsmbmJzcDsgdGhlIE5ldHdvcmsgQXNzZXJ0ZWQgSWRlbnRpdHkgYWNjb3JkaW5nIHRvIHRoZSBw
b2xpY2llcyBvZiA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgdGhlIFRydXN0PC9GT05U
Pg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IERvbWFpbi4nLjwvRk9O
VD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsg
QW5kIHRoZXJlZm9yZSB0aGUgc2lnbmlmaWNhbmNlIG9mIFAtUHJlZmVycmVkLUlkZW50aXR5IGV4
aXN0cyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgb25seSBiZXR3ZWVuPC9GT05UPg0K
PEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGEgVUEgYW5kIHRoZSBwcm94eSB0aGF0IHBlcmZvcm1zIGl0
cyBhdXRoZW50aWNhdGlvbi48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0K
PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+WWVzLjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0la
RT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IHRoYW5rczwvRk9OVD4NCjxC
Uj48Rk9OVCBTSVpFPTI+Jmd0OyBoYXJzaDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8
L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4m
Z3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la
RT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9O
VCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJnF1b3Q7TWFyayBX
YXRzb24mcXVvdDsgJmx0O213YXRzb25Abm9ydGVsbmV0d29ya3MuY29tJmd0OyBvbiAxMC8zMC8y
MDAyIDA3OjEzOjM5IFBNPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxC
Uj48Rk9OVCBTSVpFPTI+Jmd0OyBUbzombmJzcDsmbmJzcDsgSGFyc2ggQmhvbmR3ZS9IU1NCTFIs
IHNpcEBpZXRmLm9yZzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBjYzo8L0ZPTlQ+DQo8
QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IFN1Ympl
Y3Q6Jm5ic3A7IFJFOiBbU2lwXSBkcmFmdC1pZXRmLXNpcC1hc3NlcnRlZC1pZGVudGl0eS0wMi50
eHQ6IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBwcGkgZnJvbSB0cnVzdDwvRk9OVD4N
CjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyBlZCBlbnRpdHk8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxG
T05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8
QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IEhhcnNo
LDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y
PiZndDsgRnJvbSBtZW1vcnksIGEgcHJveHkgc2hvdWxkIG5vdCBleHBlY3QgdG8gcmVjZWl2ZSA8
L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgUC1QcmVmZXJyZWQtSWRlbnRpdHkgZnJvbTwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBhbm90aGVyIG1lbWJlciBvZiB0aGUgVHJ1c3Qg
RG9tYWluIGZvciBBc3NlcnRlZCBJZGVudGl0eS48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZn
dDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IFlvdSBtYXkgYmUgcmlnaHQgdGhhdCB0
aGUgYmVoYXZpb3VyIGlmIGl0IGlzIHJlY2VpdmVkIGlzIG5vdCA8L0ZPTlQ+DQo8QlI+PEZPTlQg
U0laRT0yPiZndDsgc3BlY2lmaWVkLiBJZjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBh
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IFAtQXNzZXJ0ZWQtSWRlbnRpdHkgaXMgcHJl
c2VudCwgdGhlbiBJIHdvdWxkIGV4cGVjdCB0aGU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZn
dDsgUC1QcmVmZXJyZWQtSWRlbnRpdHk8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgdG8g
YmUgZGlzY2FyZGVkICh0aGV5IHNob3VsZCBub3QgY29leGlzdCkuIElmIHRoZXJlIGlzIG5vPC9G
T05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IFAtQXNzZXJ0ZWQtSWRlbnRpdHksIHRoZW4gSSBz
dXBwb3NlIHRoZSBQcm94eSBjb3VsZCBiZWhhdmUgYXMgaWYgdGhlPC9GT05UPg0KPEJSPjxGT05U
IFNJWkU9Mj4mZ3Q7IG1lc3NhZ2U8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgd2VyZSBy
ZWNlaXZlZCBmcm9tIG91dHNpZGUgdGhlIFRydXN0IERvbWFpbi4uLjwvRk9OVD4NCjxCUj48Rk9O
VCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgSWYgUC1QcmVmZXJy
ZWQtSWRlbnRpdHkgaXMgcmVjZWl2ZWQgZnJvbSBvdXRzaWRlIHRoZSBUcnVzdCBEb21haW4sIHRo
ZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBwcm94eTwvRk9OVD4NCjxCUj48Rk9OVCBT
SVpFPTI+Jmd0OyBhdHRlbXB0cyB0byBhdXRoZW50aWNhdGUgdGhlIG9yaWdpbmF0b3Igb2YgdGhl
IG1lc3NhZ2UuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9O
VCBTSVpFPTI+Jmd0OyBZb3UgYXNrIHdoZXRoZXIgdGhlIHByb3h5IE1BWSBvciBNVVNUIHVzZSB0
aGUgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IFAtUHJlZmVycmVkLUlkZW50aXR5LCBi
dXQgSSdtPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IG5vdCBzdXJlIHRoZSBxdWVzdGlv
biBtYWtlcyBzZW5zZS4gSWYgaXQgd2VyZSBhIE1BWSwgdGhlbiA8L0ZPTlQ+DQo8QlI+PEZPTlQg
U0laRT0yPiZndDsgd2hldGhlciB0byB1c2UgaXQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZn
dDsgb3Igbm90IG11c3QgYmUgYSBtYXR0ZXIgb2YgbG9jYWwgcG9saWN5IGZvciB0aGUgcHJveHku
IElmIGl0IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyB3ZXJlIGEgTVVTVCw8L0ZPTlQ+
DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgdGhlbiBhcyBsb25nIGFzIHRoZSBQLVByZWZlcnJlZC1J
ZGVudGl0eSBpcyAnYSB2YWxpZCBpZGVudGl0eSBmb3IgdGhhdDwvRk9OVD4NCjxCUj48Rk9OVCBT
SVpFPTI+Jmd0OyB1c2VyJzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyB0aGVuIGl0IE1V
U1QgdXNlIGl0LiBCdXQgdGhlIGxpc3Qgb2YgJ3ZhbGlkIGlkZW50aXRpZXMgZm9yIDwvRk9OVD4N
CjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyB0aGF0IHVzZXInIGlzIGE8L0ZPTlQ+DQo8QlI+PEZPTlQg
U0laRT0yPiZndDsgbWF0dGVyIG9mIGxvY2FsIHBvbGljeSB0b28uIFNvIHRoZXJlIGlzIG5vIGRp
ZmZlcmVuY2UuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9O
VCBTSVpFPTI+Jmd0OyBGb3IgZXhhbXBsZSwgaWYgdGhlIHByb3h5IE5FVkVSIHVzZXMgUC1QcmVm
ZXJyZWQtSWRlbnRpdHksIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyB0aGVuIHRoaXMg
aXM8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgZXF1aXZhbGVudCB0byBzYXlpbmcgdGhh
dCB0aGVyZSBpcyBvbmx5IG9uZSB2YWxpZCBpZGVudGl0eSA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la
RT0yPiZndDsgZm9yIHRoZSB1c2VyLjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZP
TlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgUmVnYXJkcyw8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la
RT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IE1hcmsgV2F0c29uPC9GT05U
Pg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8
L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut
LS0tLTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IEZyb206IGhiaG9uZHdlQGhz
cy5obnMuY29tIFs8QSBIUkVGPSJtYWlsdG86aGJob25kd2VAaHNzLmhucy5jb20iPm1haWx0bzpo
YmhvbmR3ZUBoc3MuaG5zLmNvbTwvQT5dPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZn
dDsgU2VudDogMjkgT2N0b2JlciAyMDAyIDA1OjMwPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4m
Z3Q7ICZndDsgVG86IHNpcEBpZXRmLm9yZzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAm
Z3Q7IENjOiBoYmhvbmR3ZUBoc3MuaG5zLmNvbTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0
OyAmZ3Q7IFN1YmplY3Q6IFtTaXBdIGRyYWZ0LWlldGYtc2lwLWFzc2VydGVkLWlkZW50aXR5LTAy
LnR4dDogcHBpPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgZnJvbSB0cnVzdGVk
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgZW50aXR5PC9GT05UPg0KPEJSPjxG
T05UIFNJWkU9Mj4mZ3Q7ICZndDs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0Ozwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9
Mj4mZ3Q7ICZndDs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyBIaSw8L0ZPTlQ+
DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0
OyAmZ3Q7IFNlY3Rpb24gNiBkb2VzIG5vdCBzZWVtIHRvIGV4cGxpY2l0ZWx5IHNwZWNpZnkgcHJv
eHkncyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgYmVoYXZpb3VyIHdoZW48L0ZPTlQ+
DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyBwLXByZWZlcnJlZC1pZGVudGl0eSBoZWFkZXIg
aXMgcmVjZWl2ZWQgYnkgYSBwcm94eSBmcm9tIGE8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZn
dDsgJmd0OyB0cnVzdGVkIGVudGl0eTo8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0
OzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IGEpcHJlZmVycmVkIGlkZW50aXR5
IGNvcnJlc3BvbmRzIHRvIGEgdmFsaWQgaWRlbnRpZnkga25vd24gdG88L0ZPTlQ+DQo8QlI+PEZP
TlQgU0laRT0yPiZndDsgJmd0OyB0aGUgcHJveHkgZm9yPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9
Mj4mZ3Q7ICZndDsgdGhhdCB1c2VyLjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7
IC1NVVNUIHRoZSBwcm94eSB1c2UgdGhpcyBpZGVudGl0eSBvciZuYnNwOyBNQVkgaXQgPyBJIGFz
c3VtZSBpdCBNVVNULjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IGIpcHJlZmVy
cmVkIGlkZW50aXR5IGRvZXMgbm90IGNvcnJlc3BvbmQgdG8gYSB2YWxpZCBpZGVudGl0eTwvRk9O
VD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IGtub3duIHRvIHRoZTwvRk9OVD4NCjxCUj48
Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IHByb3h5IGZvciB0aGF0IHVzZXIuPC9GT05UPg0KPEJSPjxG
T05UIFNJWkU9Mj4mZ3Q7ICZndDsgLVNob3VsZCB0aGUgcHJveHkgYmVoYXZpb3VyIGJlIHNhbWUg
YXMgd2hlbiB0aGUgZW50aXR5IGZyb20gPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IHdo
aWNoIHRoZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IGhlYWRlciB3YXMgcmVj
ZWl2ZWQgaXMgbm90IHRydXN0ZWQuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDs8
L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF
PTI+Jmd0OyAmZ3Q7IHRoYW5rczwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IGhh
cnNoPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDs8L0ZPTlQ+DQo8QlI+PEZPTlQg
U0laRT0yPiZndDsgJmd0OzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7PC9GT05U
Pg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZn
dDsgJmd0OzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7PC9GT05UPg0KPEJSPjxG
T05UIFNJWkU9Mj4mZ3Q7ICZndDs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0Ozwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IFRoaXMgbWVzc2FnZSBpcyBwcm9wcmll
dGFyeSB0byBIdWdoZXMgU29mdHdhcmUgU3lzdGVtczwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+
Jmd0OyAmZ3Q7IExpbWl0ZWQgKEhTUykgYW5kIGlzPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4m
Z3Q7ICZndDsgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIHRv
IHdob20gaXQgaXM8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyBhZGRyZXNzZWQu
Jm5ic3A7IEl0PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgbWF5IGNvbnRhaW4g
cHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gYW5kIHNob3VsZCBub3QgYmU8
L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyBjaXJjdWxhdGVkIG9yIHVzZWQgZm9y
IGFueSBwdXJwb3NlIG90aGVyIHRoYW4gZm9yIHdoYXQgaXQgaXM8L0ZPTlQ+DQo8QlI+PEZPTlQg
U0laRT0yPiZndDsgJmd0OyBpbnRlbmRlZC4mbmJzcDsgSWY8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la
RT0yPiZndDsgJmd0OyB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIHBs
ZWFzZSBub3RpZnkgdGhlIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBvcmlnaW5hdG9y
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgaW1tZWRpYXRlbHkuJm5ic3A7IElm
IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmU8L0ZPTlQ+DQo8QlI+
PEZPTlQgU0laRT0yPiZndDsgJmd0OyBub3RpZmllZCB0aGF0PC9GT05UPg0KPEJSPjxGT05UIFNJ
WkU9Mj4mZ3Q7ICZndDsgeW91IGFyZSBzdHJpY3RseSBwcm9oaWJpdGVkIGZyb20gdXNpbmcsIGNv
cHlpbmcsIGFsdGVyaW5nLCBvcjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IGRp
c2Nsb3Npbmc8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyB0aGUgY29udGVudHMg
b2YgdGhpcyBtZXNzYWdlLiZuYnNwOyBIU1MgYWNjZXB0cyBubyByZXNwb25zaWJpbGl0eTwvRk9O
VD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IGZvciBsb3NzIG9yPC9GT05UPg0KPEJSPjxG
T05UIFNJWkU9Mj4mZ3Q7ICZndDsgZGFtYWdlIGFyaXNpbmcgZnJvbSB0aGUgdXNlIG9mIHRoZSBp
bmZvcm1hdGlvbiB0cmFuc21pdHRlZCBieTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAm
Z3Q7IHRoaXMgZW1haWw8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyBpbmNsdWRp
bmcgZGFtYWdlIGZyb20gdmlydXMuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDs8
L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF
PTI+Jmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgU2lwIG1haWxpbmcgbGlzdCZu
YnNwOyA8QSBIUkVGPSJodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXAi
IFRBUkdFVD0iX2JsYW5rIj5odHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z
aXA8L0E+PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgVGhpcyBsaXN0IGlzIGZv
ciBORVcgZGV2ZWxvcG1lbnQgb2YgdGhlIGNvcmUgU0lQIFByb3RvY29sPC9GT05UPg0KPEJSPjxG
T05UIFNJWkU9Mj4mZ3Q7ICZndDsgVXNlIHNpcC1pbXBsZW1lbnRvcnNAY3MuY29sdW1iaWEuZWR1
IGZvciBxdWVzdGlvbnMgb24gY3VycmVudCBzaXA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZn
dDsgJmd0OyBVc2Ugc2lwcGluZ0BpZXRmLm9yZyBmb3IgbmV3IGRldmVsb3BtZW50cyBvbiB0aGUg
YXBwbGljYXRpb24gb2Ygc2lwPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDs8L0ZP
TlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7
IDwvRk9OVD4NCjwvUD4NCg0KPC9CT0RZPg0KPC9IVE1MPg==

--0__=85256C6400070CFE8f9e8a93df938690918c85256C6400070CFE--

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



From mailnull@www1.ietf.org  Thu Oct 31 22:19:58 2002
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 WAA25444
	for <sip-archive@odin.ietf.org>; Thu, 31 Oct 2002 22:19:58 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA13M1L17625
	for sip-archive@odin.ietf.org; Thu, 31 Oct 2002 22:22:01 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA13LPv17590;
	Thu, 31 Oct 2002 22:21: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 gA13JCv17512
	for <sip@optimus.ietf.org>; Thu, 31 Oct 2002 22:19:12 -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 WAA25387
	for <sip@ietf.org>; Thu, 31 Oct 2002 22:16:38 -0500 (EST)
Received: from sponge.cisco.com (IDENT:mirapoint@sponge.cisco.com [64.101.128.87])
	by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gA13IuxF015750
	for <sip@ietf.org>; Thu, 31 Oct 2002 19:18:57 -0800 (PST)
Received: from ARUNVENKW2K1 (rtp-vpn1-803.cisco.com [10.82.227.35])
	by sponge.cisco.com (Mirapoint)
	with SMTP id ABO00559;
	Thu, 31 Oct 2002 21:19:01 -0600 (CST)
From: "Arunachalam Venkatraman" <arunvenk@cisco.com>
To: <sip@ietf.org>
Subject: RE: [Sip] SIPS question
Date: Thu, 31 Oct 2002 21:25:46 -0600
Message-ID: <NEBBIAKLLFKJFPOIPFDAOEJHCLAA.arunvenk@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 IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <3DC12554.E964A4A5@lmf.ericsson.se>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Christer
Interesting issue.

How about this for a solution ---
The UAS sends a SIPS URI in its Contact only if one of the following is
true-
1. The top Route in its Route Set is a SIPS URI
2. If no Route set has been established, the Contact in the request is a
SIPS-URI.

In all other cases, it sends a SIP-URI in its Contact.

Will this work?

Venkat


-----Original Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of
Christer Holmberg
Sent: Thursday, October 31, 2002 6:43 AM
To: hisham.khartabil@nokia.com
Cc: jon.peterson@neustar.biz; sip@ietf.org
Subject: Re: [Sip] SIPS question



Hi,

> > > > Hi,
> > > >
> > > > > I guess UA2 should have registered with P1 using a sips-uri
> > > > in the contact-header. P1 doesn't care about the
> > > > contact-header sent in the 200 OK. UA2 contact-header is
> > > > telling UA1 (not P1) to contact it using TLS.
> > > >
> > > > No, but the Contact header value will be used in requests
> > > > during the session, as part of the route set or Request-URI
> > > > (depending on if loose routing is used etc)
> > >
> > > What I meant to say is that if UA2 had registered with P1
> > using a sips-uri in the contact-header, then when P1 is
> > routing the INVITE, it will put sips-uri in the record-route
> > header since the request uri (retrieved from the registrar)
> > is a sips-uri.
> >
> > > Since P1 contacted UA2 using sips, the 200 ok must contain
> > a contact-header with sips-uri.
> >
> > Ok. So, in this case UA1 will receive a Record-Route with
> > SIPS-URI. So, the next time UA1 sends a request the SIPS-URI
> > indicates it shall use TLS - which UA1 may not even support.
>
> No, P1 will modify the record-route header in the response and will make
it a sip-uri.

> >And, since UA1 used SIP-URI in its own Contact header, P1
> >shall use UDP (or TCP) to forward requests received from UA2,
> >so now we would have the separate-transport-in-each-direction
> >problem between UA1 and P1, wouldn't we?
>
> UA1 will have a different route-set that UA2.

True.

However, EVEN if UA2 has registered itself with P1 using SIPS-URI, and P1
uses TLS to
contact it, UA1 will still receive a Contact header with SIPS-URI, and
according to the
RFC ("if the Request-URI is SIPS-URI, TLS MUST be used") it would have to
use TLS for the
other requests, even if it doesn't support TLS, and even if the requests
aren't even sent
to UA2 (UA1 send them to P1, which record-routed).

Regards,

Christer Holmberg
Ericsson Finland


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

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