From exim@www1.ietf.org  Wed Oct  1 03:03:43 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01124
	for <sip-archive@odin.ietf.org>; Wed, 1 Oct 2003 03:03:43 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4b16-0004f2-D3
	for sip-archive@odin.ietf.org; Wed, 01 Oct 2003 03:03:20 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9173KZu017858
	for sip-archive@odin.ietf.org; Wed, 1 Oct 2003 03:03:20 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4b0o-0004ck-42; Wed, 01 Oct 2003 03:03:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4b01-0004bf-DN
	for sip@optimus.ietf.org; Wed, 01 Oct 2003 03:02:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01051
	for <sip@ietf.org>; Wed, 1 Oct 2003 03:02:05 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4azx-0003B1-00
	for sip@ietf.org; Wed, 01 Oct 2003 03:02:09 -0400
Received: from web41604.mail.yahoo.com ([66.218.93.104])
	by ietf-mx with smtp (Exim 4.12)
	id 1A4azw-00039s-00
	for sip@ietf.org; Wed, 01 Oct 2003 03:02:08 -0400
Message-ID: <20031001070139.66092.qmail@web41604.mail.yahoo.com>
Received: from [80.74.106.2] by web41604.mail.yahoo.com via HTTP; Wed, 01 Oct 2003 00:01:39 PDT
Date: Wed, 1 Oct 2003 00:01:39 -0700 (PDT)
From: Jay Morris <jay_m_morris@yahoo.com>
To: rsparks@dynamicsoft.com
Cc: sip@ietf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-2139583697-1064991699=:64667"
Subject: [Sip] what is the correct response code for CANCEL on REFER or SUBSCRIBE
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-2139583697-1064991699=:64667
Content-Type: text/plain; charset=us-ascii

Hi
Since CANCEL is illegal for REFER and SUBSCRIBE requests, what is the correct response code when receiving such CANCEL?
I thought about "403 Forbidden" or "405 Method Not Allowed"
what do you say?
 
Jay


---------------------------------
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
--0-2139583697-1064991699=:64667
Content-Type: text/html; charset=us-ascii

<DIV>Hi</DIV>
<DIV>Since CANCEL is illegal for REFER and SUBSCRIBE requests, what is the correct response code when receiving such CANCEL?</DIV>
<DIV>I thought about "403 Forbidden" or <FONT color=#000000>"405 Method Not Allowed"</FONT></DIV>
<DIV>what do you say?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Jay</DIV><p><hr SIZE=1>
Do you Yahoo!?<br>
<a href="http://shopping.yahoo.com/?__yltc=s%3A150000443%2Cd%3A22708228%2Cslk%3Atext%2Csec%3Amail">The New Yahoo! Shopping</a> - with improved product search
--0-2139583697-1064991699=:64667--

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Wed Oct  1 03:42:43 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01638
	for <sip-archive@odin.ietf.org>; Wed, 1 Oct 2003 03:42:42 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4bcn-0006qx-FU
	for sip-archive@odin.ietf.org; Wed, 01 Oct 2003 03:42:18 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h917gHoX026286
	for sip-archive@odin.ietf.org; Wed, 1 Oct 2003 03:42:17 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4bca-0006lP-1i; Wed, 01 Oct 2003 03:42:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4bc4-0006k3-ID
	for sip@optimus.ietf.org; Wed, 01 Oct 2003 03:41:32 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01548
	for <sip@ietf.org>; Wed, 1 Oct 2003 03:41:26 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4bc2-0003Un-00
	for sip@ietf.org; Wed, 01 Oct 2003 03:41:30 -0400
Received: from web41605.mail.yahoo.com ([66.218.93.105])
	by ietf-mx with smtp (Exim 4.12)
	id 1A4bc1-0003U7-00
	for sip@ietf.org; Wed, 01 Oct 2003 03:41:29 -0400
Message-ID: <20031001074059.62411.qmail@web41605.mail.yahoo.com>
Received: from [80.74.106.2] by web41605.mail.yahoo.com via HTTP; Wed, 01 Oct 2003 00:40:59 PDT
Date: Wed, 1 Oct 2003 00:40:59 -0700 (PDT)
From: Jay Morris <jay_m_morris@yahoo.com>
To: sip@ietf.org
Cc: rsparks@dynamicsoft.com
In-Reply-To: <99FF181D4C99564F8D623069E1DDB25E22A8AF@nt-mail.tlv.radvision.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-747345610-1064994059=:61882"
Subject: [Sip] Re: REFER request with method parameter != INVITE in refer-to  he   ader
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-747345610-1064994059=:61882
Content-Type: text/plain; charset=us-ascii

Hello all
I did not understand the answer.
can I send a REFER request with method=OPTIONS in the Refer-To URI ???
(lets say I just want to know whether the remote target is 'alive', and I don't need any new dialog for it...)
Jay






On Mon, 2003-09-29 at 05:58, Ofra Wachsman wrote:
> another thing - is it possible to set in the method parameter of the
> Refer-To URI, a method that does not create a dialog? (method different
than
> INVITE, SUBSCRIBE or REFER)?

Yes.
You can also set it to a non sip: URI (such as http).

RjS

---------------------------------
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
--0-747345610-1064994059=:61882
Content-Type: text/html; charset=us-ascii

<DIV>Hello all</DIV>
<DIV>I did not understand the answer.</DIV>
<DIV>can I send a REFER request with method=OPTIONS in the Refer-To URI ???</DIV>
<DIV>(lets say I just want to know whether the remote target is 'alive', and I don't need any new dialog for it...)</DIV>
<DIV>Jay<BR></DIV><BR>
<BLOCKQUOTE class=replbq style="BORDER-LEFT: #1010ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px"><BR><BR><BR><BR>On Mon, 2003-09-29 at 05:58, Ofra Wachsman wrote:<BR>&gt; another thing - is it possible to set in the method parameter of the<BR>&gt; Refer-To URI, a method that does not create a dialog? (method different<BR>than<BR>&gt; INVITE, SUBSCRIBE or REFER)?<BR><BR>Yes.<BR>You can also set it to a non sip: URI (such as http).<BR><BR>RjS</BLOCKQUOTE><p><hr SIZE=1>
Do you Yahoo!?<br>
<a href="http://shopping.yahoo.com/?__yltc=s%3A150000443%2Cd%3A22708228%2Cslk%3Atext%2Csec%3Amail">The New Yahoo! Shopping</a> - with improved product search
--0-747345610-1064994059=:61882--

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Wed Oct  1 05:16:36 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04885
	for <sip-archive@odin.ietf.org>; Wed, 1 Oct 2003 05:16:36 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4d5i-0002xW-33
	for sip-archive@odin.ietf.org; Wed, 01 Oct 2003 05:16:14 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h919GDkn011317
	for sip-archive@odin.ietf.org; Wed, 1 Oct 2003 05:16:13 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4d5W-0002w3-Ne; Wed, 01 Oct 2003 05:16:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4d57-0002vV-S2
	for sip@optimus.ietf.org; Wed, 01 Oct 2003 05:15:37 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04842
	for <sip@ietf.org>; Wed, 1 Oct 2003 05:15:30 -0400 (EDT)
From: aki.niemi@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4d54-0004bi-00
	for sip@ietf.org; Wed, 01 Oct 2003 05:15:34 -0400
Received: from mgw-x4.nokia.com ([131.228.20.27])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4d53-0004bf-00
	for sip@ietf.org; Wed, 01 Oct 2003 05:15:34 -0400
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h919FYt25980
	for <sip@ietf.org>; Wed, 1 Oct 2003 12:15:34 +0300 (EET DST)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T6503fbdc87ac158f24077@esvir04nok.ntc.nokia.com> for <sip@ietf.org>;
 Wed, 1 Oct 2003 12:15:34 +0300
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Wed, 1 Oct 2003 12:15:34 +0300
x-mimeole: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Using Request-URI to identify the PUBLISHed resource (was: RE: [Sip] Re:draft-ietf-sip-publish-00.txt)
Date: Wed, 1 Oct 2003 12:15:34 +0300
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945395@esebe013.ntc.nokia.com>
Thread-Topic: [Sip] Re:draft-ietf-sip-publish-00.txt
Thread-Index: AcOHj1nsX1plnAEgRqeMiQBSRDowagAZm3Dg
To: <sip@ietf.org>
X-OriginalArrivalTime: 01 Oct 2003 09:15:34.0457 (UTC) FILETIME=[91D37A90:01C387FC]
Content-Transfer-Encoding: quoted-printable
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: quoted-printable

Hi All,

I think the conclusion in this thread is that the alignment with =
REGISTER is useful only with respect to the concept of third-party =
publication (use of From), and that the Request-URI needs to be used to =
identify the resource - identical to as it is done in SUBSCRIBE.

I will change the wording in the draft to this effect.

Cheers,
Aki

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Wed Oct  1 10:24:47 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14988
	for <sip-archive@odin.ietf.org>; Wed, 1 Oct 2003 10:24:47 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4htw-0002uf-Qv
	for sip-archive@odin.ietf.org; Wed, 01 Oct 2003 10:24:25 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h91EOO54011139
	for sip-archive@odin.ietf.org; Wed, 1 Oct 2003 10:24:24 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4htc-0002pk-Oc; Wed, 01 Oct 2003 10:24:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4htV-0002p1-Pb
	for sip@optimus.ietf.org; Wed, 01 Oct 2003 10:23:57 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14936
	for <sip@ietf.org>; Wed, 1 Oct 2003 10:23:49 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4htT-0007YK-00
	for sip@ietf.org; Wed, 01 Oct 2003 10:23:55 -0400
Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4htS-0007Xm-00
	for sip@ietf.org; Wed, 01 Oct 2003 10:23:54 -0400
Received: from localhost (localhost.localdomain [127.0.0.1])
	by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h91ENJd13068;
	Wed, 1 Oct 2003 09:23:19 -0500
From: Robert Sparks <rsparks@dynamicsoft.com>
To: Jay Morris <jay_m_morris@yahoo.com>
Cc: sip@ietf.org
In-Reply-To: <20031001074059.62411.qmail@web41605.mail.yahoo.com>
References: <20031001074059.62411.qmail@web41605.mail.yahoo.com>
Content-Type: text/plain
Message-Id: <1065018198.916.15.camel@RjS.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.4 
Date: Wed, 01 Oct 2003 09:23:19 -0500
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Re: REFER request with method parameter != INVITE in refer-to  he
 ader
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 Wed, 2003-10-01 at 02:40, Jay Morris wrote:
> Hello all
> I did not understand the answer.
> can I send a REFER request with method=OPTIONS in the Refer-To URI ???
> (lets say I just want to know whether the remote target is 'alive',
> and I don't need any new dialog for it...)
> Jay
> 

Yes you can send a REFER with a Refer-To URI that looks like
<sip:remote-target@example;method=OPTIONS>.
I assume you are testing network visibility of the target from
the transferee, not just liveliness (otherwise you'ld just send
the OPTIONS directly to the target, yes?).

>         
>         
>         
>         On Mon, 2003-09-29 at 05:58, Ofra Wachsman wrote:
>         > another thing - is it possible to set in the method
>         parameter of the
>         > Refer-To URI, a method that does not create a dialog?
>         (method different
>         than
>         > INVITE, SUBSCRIBE or REFER)?
>         
>         Yes.
>         You can also set it to a non sip: URI (such as http).
>         
>         RjS
> 
> ______________________________________________________________________
> Do you Yahoo!?
> The New Yahoo! Shopping - with improved product search


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Wed Oct  1 10:50:34 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16078
	for <sip-archive@odin.ietf.org>; Wed, 1 Oct 2003 10:50:33 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4iIt-0004o9-Sk
	for sip-archive@odin.ietf.org; Wed, 01 Oct 2003 10:50:11 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h91EoBid018424
	for sip-archive@odin.ietf.org; Wed, 1 Oct 2003 10:50:11 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4iIk-0004mc-Rc; Wed, 01 Oct 2003 10:50:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4iIT-0004mB-NX
	for sip@optimus.ietf.org; Wed, 01 Oct 2003 10:49:45 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16021
	for <sip@ietf.org>; Wed, 1 Oct 2003 10:49:37 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4iIR-00005C-00
	for sip@ietf.org; Wed, 01 Oct 2003 10:49:43 -0400
Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4iIQ-00004Q-00
	for sip@ietf.org; Wed, 01 Oct 2003 10:49:42 -0400
Received: from localhost (localhost.localdomain [127.0.0.1])
	by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h91En9d13378;
	Wed, 1 Oct 2003 09:49:09 -0500
Subject: Re: [Sip] what is the correct response code for CANCEL on REFER or
	SUBSCRIBE
From: Robert Sparks <rsparks@dynamicsoft.com>
To: Jay Morris <jay_m_morris@yahoo.com>
Cc: sip@ietf.org
In-Reply-To: <20031001070139.66092.qmail@web41604.mail.yahoo.com>
References: <20031001070139.66092.qmail@web41604.mail.yahoo.com>
Content-Type: text/plain
Message-Id: <1065019748.951.29.camel@RjS.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.4 
Date: Wed, 01 Oct 2003 09:49:09 -0500
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

It really doesn't matter much. 

You don't want to use 405, because that would claim you didn't support
CANCEL at any time for this RURI, even for INVITE.

403 or 603 are safe responses.

Using a 200 OK won't break anything. Remember, accepting a CANCEL
doesn't mean the request it's trying to cancel will _be_ cancelled.

RjS

On Wed, 2003-10-01 at 02:01, Jay Morris wrote:
> Hi
> Since CANCEL is illegal for REFER and SUBSCRIBE requests, what is the
> correct response code when receiving such CANCEL?
> I thought about "403 Forbidden" or "405 Method Not Allowed"
> what do you say?
>  
> Jay
> 
> 
> ______________________________________________________________________
> Do you Yahoo!?
> The New Yahoo! Shopping - with improved product search


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Wed Oct  1 11:04:29 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16996
	for <sip-archive@odin.ietf.org>; Wed, 1 Oct 2003 11:04:28 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4iWM-0005qj-Qs
	for sip-archive@odin.ietf.org; Wed, 01 Oct 2003 11:04:07 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h91F46HS022453
	for sip-archive@odin.ietf.org; Wed, 1 Oct 2003 11:04:06 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4iWI-0005pY-FF; Wed, 01 Oct 2003 11:04:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4iVf-0005k7-Od
	for sip@optimus.ietf.org; Wed, 01 Oct 2003 11:03:23 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16952
	for <sip@ietf.org>; Wed, 1 Oct 2003 11:03:15 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4iVd-0000J6-00
	for sip@ietf.org; Wed, 01 Oct 2003 11:03:21 -0400
Received: from mail01.corp.tellme.com ([209.157.157.98])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4iVc-0000Ib-00
	for sip@ietf.org; Wed, 01 Oct 2003 11:03:20 -0400
Received: from mail01.corp.tellme.com (localhost [127.0.0.1])
	by localhost.tellme.com (Postfix) with ESMTP id C001535E53
	for <sip@ietf.org>; Wed,  1 Oct 2003 08:02:49 -0700 (PDT)
Received: from spider (shell02.corp.tellme.com [209.157.157.55])
	by mail01.corp.tellme.com (Postfix) with SMTP id 7415435FD3
	for <sip@ietf.org>; Wed,  1 Oct 2003 07:59:07 -0700 (PDT)
From: "Greg Scallan" <spider@tellme.com>
To: <sip@ietf.org>
Date: Wed, 1 Oct 2003 07:58:49 -0700
Message-ID: <OGEDJFNFIMDPCJDMFNFIMEDKHIAA.spider@tellme.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <1065018198.916.15.camel@RjS.localdomain>
Content-Transfer-Encoding: quoted-printable
Subject: [Sip] Question regarding Proxy forwarding 2XX responses
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: quoted-printable

Hi All,

	Was hoping someone could help clarify the following question. Assuming =
RFC 3261 compliance, Does a SIP Proxy server acting in a transaction =
stateful manner *have to* forward *all* 2XX responses received as a =
result of an INVITE that had been forwarded to multiple UAS's? Or, can =
the Proxy decide to only forward the first one received?

Thanks,
greg


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Wed Oct  1 11:10:32 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17249
	for <sip-archive@odin.ietf.org>; Wed, 1 Oct 2003 11:10:32 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4icC-0006Xl-US
	for sip-archive@odin.ietf.org; Wed, 01 Oct 2003 11:10:09 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h91FA8fU025128
	for sip-archive@odin.ietf.org; Wed, 1 Oct 2003 11:10:08 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4ic7-0006WR-Jf; Wed, 01 Oct 2003 11:10:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4ibw-0006Va-E2
	for sip@optimus.ietf.org; Wed, 01 Oct 2003 11:09:52 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17210
	for <sip@ietf.org>; Wed, 1 Oct 2003 11:09:43 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4ibt-0000OS-00
	for sip@ietf.org; Wed, 01 Oct 2003 11:09:49 -0400
Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net)
	by ietf-mx with smtp (Exim 4.12)
	id 1A4ibt-0000OP-00
	for sip@ietf.org; Wed, 01 Oct 2003 11:09:49 -0400
Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net
          via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Wed, 1 Oct 2003 16:12:29 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Question regarding Proxy forwarding 2XX responses
Date: Wed, 1 Oct 2003 16:09:10 +0100
Message-ID: <45730E094814E44488F789C1CDED27AE01E22DC1@gbnewp0758m.eu.ubiquity.net>
Thread-Topic: [Sip] Question regarding Proxy forwarding 2XX responses
Thread-Index: AcOILSw7/W1rVLKfRpOfBDk7+VEYeAAAMaDw
From: "Chris Boulton" <cboulton@ubiquity.net>
To: "Greg Scallan" <spider@tellme.com>, <sip@ietf.org>
Content-Transfer-Encoding: quoted-printable
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: quoted-printable

All.

>-----Original Message-----
>From: Greg Scallan [mailto:spider@tellme.com]
>Sent: 01 October 2003 15:59
>To: sip@ietf.org
>Subject: [Sip] Question regarding Proxy forwarding 2XX responses
>
>Hi All,
>
>	Was hoping someone could help clarify the following question.
>Assuming RFC 3261 compliance, Does a SIP Proxy server acting in a
>transaction stateful manner *have to* forward *all* 2XX responses
received
>as a result of an INVITE that had been forwarded to multiple UAS's? Or,
can
>the Proxy decide to only forward the first one received?
>
>Thanks,
>greg
>
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Wed Oct  1 11:22:38 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18379
	for <sip-archive@odin.ietf.org>; Wed, 1 Oct 2003 11:22:37 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4inu-00079d-I0
	for sip-archive@odin.ietf.org; Wed, 01 Oct 2003 11:22:14 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h91FMEXH027444
	for sip-archive@odin.ietf.org; Wed, 1 Oct 2003 11:22:14 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4ini-00075F-Ky; Wed, 01 Oct 2003 11:22:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4imj-00072z-6O
	for sip@optimus.ietf.org; Wed, 01 Oct 2003 11:21:01 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18223
	for <sip@ietf.org>; Wed, 1 Oct 2003 11:20:54 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4imi-0000fF-00
	for sip@ietf.org; Wed, 01 Oct 2003 11:21:00 -0400
Received: from mail01.corp.tellme.com ([209.157.157.98])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4imh-0000eA-00
	for sip@ietf.org; Wed, 01 Oct 2003 11:20:59 -0400
Received: from mail01.corp.tellme.com (localhost [127.0.0.1])
	by localhost.tellme.com (Postfix) with ESMTP
	id F1C7B35E53; Wed,  1 Oct 2003 08:20:28 -0700 (PDT)
Received: from spider (shell02.corp.tellme.com [209.157.157.55])
	by mail01.corp.tellme.com (Postfix) with SMTP
	id B54A835D52; Wed,  1 Oct 2003 08:20:28 -0700 (PDT)
From: "Greg Scallan" <spider@tellme.com>
To: "Chris Boulton" <cboulton@ubiquity.net>, <sip@ietf.org>
Subject: RE: [Sip] Question regarding Proxy forwarding 2XX responses
Date: Wed, 1 Oct 2003 08:20:14 -0700
Message-ID: <OGEDJFNFIMDPCJDMFNFIKEDLHIAA.spider@tellme.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <45730E094814E44488F789C1CDED27AE01E22DC1@gbnewp0758m.eu.ubiquity.net>
Content-Transfer-Encoding: quoted-printable
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: quoted-printable

Thank you, another question then:

If the same proxy decided instead forwarded the INVITE to UAS1, then =
received a 4XX response, can the SIP Proxy subsequently decide to =
forward the INVITE to UAS2 and upon receiving a 2XX response, only =
forward the 2XX response and not the 4XX response?

It was unclear to me from reading the spec if this is allowed because =
RFC 3261 seemed to indicate that when the Proxy server received the =
final response for all outstanding client transactions that it MUST =
forward the "best response".  In this case, we don't like the best =
response and want to retry additional UAS's.

thanks,
greg

-----Original Message-----
From: Chris Boulton [mailto:cboulton@ubiquity.net]
Sent: Wednesday, October 01, 2003 8:09 AM
To: Greg Scallan; sip@ietf.org
Subject: RE: [Sip] Question regarding Proxy forwarding 2XX responses


All.

>-----Original Message-----
>From: Greg Scallan [mailto:spider@tellme.com]
>Sent: 01 October 2003 15:59
>To: sip@ietf.org
>Subject: [Sip] Question regarding Proxy forwarding 2XX responses
>
>Hi All,
>
>	Was hoping someone could help clarify the following question.
>Assuming RFC 3261 compliance, Does a SIP Proxy server acting in a
>transaction stateful manner *have to* forward *all* 2XX responses
received
>as a result of an INVITE that had been forwarded to multiple UAS's? Or,
can
>the Proxy decide to only forward the first one received?
>
>Thanks,
>greg
>
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Wed Oct  1 11:30:49 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19174
	for <sip-archive@odin.ietf.org>; Wed, 1 Oct 2003 11:30:48 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4ivp-00085e-JK
	for sip-archive@odin.ietf.org; Wed, 01 Oct 2003 11:30:25 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h91FUPIl031041
	for sip-archive@odin.ietf.org; Wed, 1 Oct 2003 11:30:25 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4ivT-00080d-Fj; Wed, 01 Oct 2003 11:30:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4iv5-0007zm-0M
	for sip@optimus.ietf.org; Wed, 01 Oct 2003 11:29:39 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19120
	for <sip@ietf.org>; Wed, 1 Oct 2003 11:29:31 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4iv3-0000vL-00
	for sip@ietf.org; Wed, 01 Oct 2003 11:29:37 -0400
Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net)
	by ietf-mx with smtp (Exim 4.12)
	id 1A4iv3-0000vA-00
	for sip@ietf.org; Wed, 01 Oct 2003 11:29:37 -0400
Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net
          via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Wed, 1 Oct 2003 16:32:17 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Question regarding Proxy forwarding 2XX responses
Date: Wed, 1 Oct 2003 16:28:57 +0100
Message-ID: <45730E094814E44488F789C1CDED27AE01E22DC2@gbnewp0758m.eu.ubiquity.net>
Thread-Topic: [Sip] Question regarding Proxy forwarding 2XX responses
Thread-Index: AcOIL3bV+tmEl80WRySksQiwQRNaZAAAOvQQ
From: "Chris Boulton" <cboulton@ubiquity.net>
To: "Greg Scallan" <spider@tellme.com>, <sip@ietf.org>
Content-Transfer-Encoding: quoted-printable
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: quoted-printable

Greg,
	You should really be putting these type of questions to the
sip-implemetors list ;-)

<<See comment>>

Chris.


>-----Original Message-----
>From: Greg Scallan [mailto:spider@tellme.com]
>Sent: 01 October 2003 16:20
>To: Chris Boulton; sip@ietf.org
>Subject: RE: [Sip] Question regarding Proxy forwarding 2XX responses
>
>Thank you, another question then:
>
>If the same proxy decided instead forwarded the INVITE to UAS1, then
>received a 4XX response, can the SIP Proxy subsequently decide to
forward
>the INVITE to UAS2 and upon receiving a 2XX response, only forward the
2XX
>response and not the 4XX response?

[Chris Boulton] If you have two potential locations (e.g. as part of a
location lookup) you can fork sequentially, and then pick the best
response (200 OK in your example) and only forward this to the
originator(UAC).

>
>It was unclear to me from reading the spec if this is allowed because
RFC
>3261 seemed to indicate that when the Proxy server received the final
>response for all outstanding client transactions that it MUST forward
the
>"best response".  In this case, we don't like the best response and
want to
>retry additional UAS's.
>
>thanks,
>greg
>
>-----Original Message-----
>From: Chris Boulton [mailto:cboulton@ubiquity.net]
>Sent: Wednesday, October 01, 2003 8:09 AM
>To: Greg Scallan; sip@ietf.org
>Subject: RE: [Sip] Question regarding Proxy forwarding 2XX responses
>
>
>All.
>
>>-----Original Message-----
>>From: Greg Scallan [mailto:spider@tellme.com]
>>Sent: 01 October 2003 15:59
>>To: sip@ietf.org
>>Subject: [Sip] Question regarding Proxy forwarding 2XX responses
>>
>>Hi All,
>>
>>	Was hoping someone could help clarify the following question.
>>Assuming RFC 3261 compliance, Does a SIP Proxy server acting in a
>>transaction stateful manner *have to* forward *all* 2XX responses
>received
>>as a result of an INVITE that had been forwarded to multiple UAS's?
Or,
>can
>>the Proxy decide to only forward the first one received?
>>
>>Thanks,
>>greg
>>
>>
>>_______________________________________________
>>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Wed Oct  1 11:39:34 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19887
	for <sip-archive@odin.ietf.org>; Wed, 1 Oct 2003 11:39:34 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4j4I-0000PL-Ih
	for sip-archive@odin.ietf.org; Wed, 01 Oct 2003 11:39:11 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h91FdALo001561
	for sip-archive@odin.ietf.org; Wed, 1 Oct 2003 11:39:10 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4j49-0000OT-QA; Wed, 01 Oct 2003 11:39:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4j3b-0000O6-Kq
	for sip@optimus.ietf.org; Wed, 01 Oct 2003 11:38:27 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19781
	for <sip@ietf.org>; Wed, 1 Oct 2003 11:38:20 -0400 (EDT)
From: hisham.khartabil@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4j3a-000160-00
	for sip@ietf.org; Wed, 01 Oct 2003 11:38:26 -0400
Received: from mgw-x1.nokia.com ([131.228.20.21])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4j3Z-00015x-00
	for sip@ietf.org; Wed, 01 Oct 2003 11:38:25 -0400
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h91FcO614541
	for <sip@ietf.org>; Wed, 1 Oct 2003 18:38:24 +0300 (EET DST)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T65055a5860ac158f25621@esvir05nok.ntc.nokia.com>;
 Wed, 1 Oct 2003 18:38:23 +0300
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Wed, 1 Oct 2003 18:38:22 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C38832.0BA61F82"
Subject: RE: [Sip] what is the correct response code for CANCEL on REFER or SUBSCRIBE
Date: Wed, 1 Oct 2003 18:38:22 +0300
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797162@esebe019.ntc.nokia.com>
Thread-Topic: [Sip] what is the correct response code for CANCEL on REFER or SUBSCRIBE
Thread-Index: AcOH6j78Dk5tlcQzRU6xK9+wnZ0Y0AAR8UcQ
To: <jay_m_morris@yahoo.com>, <rsparks@dynamicsoft.com>
Cc: <sip@ietf.org>
X-OriginalArrivalTime: 01 Oct 2003 15:38:22.0612 (UTC) FILETIME=[0BE9CD40:01C38832]
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_001_01C38832.0BA61F82
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

200 OK for CANCEL would do.
=20
/Hisham

-----Original Message-----
From: ext Jay Morris [mailto:jay_m_morris@yahoo.com]
Sent: Wednesday, October 01, 2003 10:02 AM
To: rsparks@dynamicsoft.com
Cc: sip@ietf.org
Subject: [Sip] what is the correct response code for CANCEL on REFER or =
SUBSCRIBE


Hi
Since CANCEL is illegal for REFER and SUBSCRIBE requests, what is the =
correct response code when receiving such CANCEL?
I thought about "403 Forbidden" or "405 Method Not Allowed"
what do you say?
=20
Jay



  _____ =20

Do you Yahoo!?
The  =
<http://shopping.yahoo.com/?__yltc=3Ds%3A150000443%2Cd%3A22708228%2Cslk%3=
Atext%2Csec%3Amail> New Yahoo! Shopping - with improved product search


------_=_NextPart_001_01C38832.0BA61F82
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=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<META content=3D"MSHTML 5.50.4611.1300" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D555093815-01102003><FONT face=3DArial color=3D#0000ff =
size=3D2>200 OK=20
for CANCEL would do.</FONT></SPAN></DIV>
<DIV><SPAN class=3D555093815-01102003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D555093815-01102003><FONT face=3DArial color=3D#0000ff =

size=3D2>/Hisham</FONT></SPAN></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> ext Jay Morris=20
  [mailto:jay_m_morris@yahoo.com]<BR><B>Sent:</B> Wednesday, October 01, =
2003=20
  10:02 AM<BR><B>To:</B> rsparks@dynamicsoft.com<BR><B>Cc:</B>=20
  sip@ietf.org<BR><B>Subject:</B> [Sip] what is the correct response =
code for=20
  CANCEL on REFER or SUBSCRIBE<BR><BR></FONT></DIV>
  <DIV>Hi</DIV>
  <DIV>Since CANCEL is illegal for REFER and SUBSCRIBE requests, what is =
the=20
  correct response code when receiving such CANCEL?</DIV>
  <DIV>I thought about "403 Forbidden" or <FONT color=3D#000000>"405 =
Method Not=20
  Allowed"</FONT></DIV>
  <DIV>what do you say?</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Jay</DIV>
  <P>
  <HR SIZE=3D1>
  Do you Yahoo!?<BR><A=20
  =
href=3D"http://shopping.yahoo.com/?__yltc=3Ds%3A150000443%2Cd%3A22708228%=
2Cslk%3Atext%2Csec%3Amail">The=20
  New Yahoo! Shopping</A> - with improved product=20
search</BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C38832.0BA61F82--

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Wed Oct  1 14:14:43 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26225
	for <sip-archive@odin.ietf.org>; Wed, 1 Oct 2003 14:14:43 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4lUR-0001lL-E8
	for sip-archive@odin.ietf.org; Wed, 01 Oct 2003 14:14:22 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h91IEJT2006771
	for sip-archive@odin.ietf.org; Wed, 1 Oct 2003 14:14:19 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4lUA-0001gr-Ma; Wed, 01 Oct 2003 14:14:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4lTl-0001fw-IZ
	for sip@optimus.ietf.org; Wed, 01 Oct 2003 14:13:37 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26140
	for <sip@ietf.org>; Wed, 1 Oct 2003 14:13:28 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4lTj-0002ys-00
	for sip@ietf.org; Wed, 01 Oct 2003 14:13:35 -0400
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4lTi-0002y9-00
	for sip@ietf.org; Wed, 01 Oct 2003 14:13:34 -0400
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 OAA15012;
	Wed, 1 Oct 2003 14:12:58 -0400 (EDT)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA02916;
	Wed, 1 Oct 2003 14:12:59 -0400 (EDT)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19)
	id <S6M3X1M1>; Wed, 1 Oct 2003 14:12:59 -0400
Message-ID: <313680C9A886D511A06000204840E1CF070B5F2A@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Dean Willis'" <dean.willis@softarmor.com>
Cc: "'Stastny Richard'" <Richard.Stastny@oefeg.at>,
        Rohan Mahy
	 <rohan@cisco.com>,
        Francois Audet <audet@nortelnetworks.com>,
        Paul Kyzivat <pkyzivat@cisco.com>,
        Bob Penfield
	 <bpenfield@acmepacket.com>, sip@ietf.org
Subject: RE: [Sip] SIPIT Interop problem with ;user=phone
Date: Wed, 1 Oct 2003 14:12:58 -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>

Getting back to this.  I was working on other things.

One overriding criticism I have for this post is that it assumes
that a gateway is the ultimate destination for a call with user=phone.
It isn't.  A sipphone is just as likely a destination as a gateway.
If I assign an E.164, or an internal number, to a phone so that 
callers with TDM equipment can call them (or simplistic user interfaces
that encourage meaningless strings of digits as the user part of
a nice sip AOR), then when I call it, many, many existing systems
will append user=phone to the request URI.  

Much more in line

> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]
> Sent: Monday, September 22, 2003 12:06 PM
> To: Rosen, Brian
> Cc: 'Stastny Richard'; Rohan Mahy; Francois Audet; Paul Kyzivat; Bob
> Penfield; sip@ietf.org
> Subject: RE: [Sip] SIPIT Interop problem with ;user=phone
> 
> 
> 
> Ah! I think we have something here!
> 
> Brian said:
> > A user at a dumb phone always enters a dial string.
> > No argument.
> > 
> > However, at some point, either a UA translates a dial string
> > to a phone number, or a downstream proxy does it.  At that point
> > it isn't a dial string, it's a phone number, and it might be
> > in a context (it could be global).  What I've mentioned is
> > a case, which I think is pretty common, where the number is
> > not represented the same way as a dial string and a phone number,
> > and yet is in the same domain.
> 
> Actually, this isn't quite right. Proxies transform URIs. They can do
> all sorts of transformations -- changing the domain, the user part,
> parameters, etc. for any number of reasons and using any number of
> mechanisms to specify that transformation. It's never a 
> dial-string when
> it's being processed by a proxy. It might CONTAIN information that is
> meant to represent a dial-string, but it's a request URI as long as
> we're thinking about the problem from the proxy's perspective.
> 
> Eventually, that request (and its associated, potentially transformed
> URI) may be delivered to a telephony gateway. The gateway's job is to
> construct appropriate PSTN signaling based on the request-URI. By
> today's convention, simple gateways take the user part of the request
> URI and use it as the signaling input to the PSTN -- i.e., a "dial
> string". More sophisticated gateways verify that the host-part of the
> request (if any) targets the gateway. Even more sophisticated gateways
> perform their own transformations on the user part, perhaps applying
> regular expressions or similar programatic mechanisms. Oddly 
> enough, no
> gateway that I'm aware of treats a request any differently if it has a
> user=phone parameter than it does if there is no user=phone parameter,
> and there's not even any way to test for this in the 
> expression language
> of such gateways, as far as I know.
Woah.  I think gateways are the least interesting part of the problem.

I agree that a gateway doesn't need or care about user=phone.

I agree that gateways sometimes have the ability to transform dial strings
to phone numbers.  I think that only adds to the confusion we now have.
Gateways that I know about can't differentiate between a dial string
and a phone number; they treat all input as dial strings.  If the
environment
those gateways were a part of had phone numbers that were not dial strings,
they would be incapable of dialing the phone numbers.  Some element would
have to make sure the user part was a dial string.  It would be useful,
I think, for there to be a way to tell the difference.  Then such gateways
could selectively apply the transformation logic.

> 
> So who does pay attention to a parameter of user=phone? 
> Potentially, it
> is considered by intermediate proxies, who are trying to 
> decide 1) What
> transformation to make to the request URI, if any, and 2) 
> Where to send
> the request next.
> 
> I believe there have been suggestions that proxies use user=phone in
> several distinct ways:
> 
> 1) As a way to indicate that this request URI is intended for eventaul
> delivery (unless otherwise transformed) to a PSTN gateway.
I don't know of any device that does this.  Specifically, no device
that I know of has any way to know what the characteristics of the
destination is - gateway, sipphone, H.323 phone,...

If you said "as a way to indicate that this is a phone number,
maybe we could get somewhere.
> 
> 2) As a way to indicate that the request URI MUST be 
> delivered to a PSTN
> gateway, and that the user-part of the request-URI is expected to be
> meaningly translatable to PSTN signaling by a gateway in the domain or
> context of the request.
Again, I know of no device that does this.  No device that I know of
has any way to know whether a numeric user part has anything to
do with PSTN signalling or not, whether there is a gateway of any
kind involved. or whether the numeric string is translatable to
PSTN signalling

> 
> 3) As a way to inidcate that the SIP or SIPS request-URI was 
> constructed
> from a tel URI, which transformation may or may not be reversable.
Ahh, at last.  Yes, this is ONE possible use of user=phone.

> 
> 4) As a way to indicate that some prior device in the processing chain
> has transformed the user-part of the request URI FROM a dial-string to
> some sort of unique user-part so that it can be used in routing. This
> might be better addressed by a "history" sort of operation.
Agree this could be a use of user=phone, and I agree it may not be the
best use.  I think we need a way to know if this is a phone number or
a dial string.  It's not clear to me that we need to know if there
was dial string to phone number conversion somewhere along the line.
I can't think of why you need that.  A uri originating
as a phone number is interchangeable, I think, with a dial string
transformed to a phone number.  The requirement is to differentiate
dial strings from phone numbers, not the history of how we came to
have one or the other.

> 
> 5) As a way to indicate that some prior device in the processing chain
> has transformed the user part INTO a dial-string which can be 
> correctly
> interpreted by a specific PSTN gateway. This might be better addressed
> by a "history" sort of operation.
Yeah, I first was confused by this, but I now understand that if you
have, for example, a real E.164, but your gateway faces a PBX, you usually
can't give the PBX the E.164.  You have to transform it into a dial
string (prepend with 9 for example).

This again argues for a way to know if a uri is a dial string or a 
phone number.

> 
> 6) As a way to indicate that the originating UA doesn't know 
> what to do
> with user-input and that further transformation is required by a proxy
> for the request-URI to resolve to the intended target.
Agree again that this is one use user=phone has been put to.
Generally, we treat user input as a dial string, but we don't really
have to, that's just a convention.

> 
> Brian further expounds:
> 
> > Let's take a practical example.  Suppose I have a domain with
> > a reasonably smart proxy server and a mix of phones.  Some phones
> > have dialstring translation, some don't.  The proxy server
> > can translate dial strings to phone numbers, and it also can
> > route phone numbers.  Obviously it can do both (ie translate then
> > route).
> > 
> > Now, how does the proxy know if it needs to translate?  That is,
> > how does it know that a uri passed to it is a dial string vs
> > a phone number?  If I pass it a phone number and it decides to
> > apply it's dialstring processing, that will fail.  If I pass a 
> > dial string and it just routes, that will fail.  It has to know
> > what it is given.  In my example it was 7246826@pit.sip.marconi.com
> > That's a phone number, and a dial string, but it's two different
> > destinations.  In my numbering plan, it's my phone.  In my dialing
> > plan it's an extension in another office.
> > 
> 
> In this case, you appear to be using mode 6 as described above.
No, my point was that if I have one phone that sends a dial string,
and another phone that sends a phone number, at some point, someone
has to know that they are interpreted differently.

> 
> Discussion: 
> 
> Some phones know how to transform a sequence of user-entered 
> digits into
> a routable request. These phones, when presented a user input loooking
> like a string of digits, use this capability to generate a request URI
> targeting the (effectively) globally-routable destination. Such a
> request has no user=phone parameter.
Well, agree except for the "globally routable" part.  It's routable.
but it may not be globally routable.

Today, some phones with this capability do add user=phone.  Some don't.
> 
> Other phones do NOT know how to do this translation and just paste the
> collected digits into the user-part of a request and add user=phone.
Right.  Most of the phones I know that send dial strings add user=phone.
Can't claim that they all do.

> 
> A routing proxy, receiving a request, applies different routing and
> transformation logic to a request having user=phone than it does to a
> request not having that parameter. This may result in 
> identical outputs
> for requests with/without user=phone, or it may result in divergent
> outputs.
Well, this is the problem the thread started with.  Agree that this is
where we are, and it's not good.

> 
> Conclusion:
>  
> I believe that in this usage, the presence of user=phone in a request
> indicates something about the ORIGINATOR of the request (this request
> came from a stupid phone) and not something about the TARGET of the
> request (this request is meant to go to the PSTN).
Quibble with wording, but agree that the originator adds user=phone under
some circumstances, and targets generally don't care.

> 
> I think this distinction (Exactly WHO is a "phone" when the 
> request says
> user=phone) is at the heart of the discussion we're having. 
> And I don't
> believe your usage is at all consistent with what I've heard from many
> other people on this list, who believe that "user=phone" is a property
> of the request's TARGET, not a property of the request's ORIGINATOR.
I don't see that everyone else has that point of view, but I think you
have done a good job of explaining why the destination is not
interested in user=phone.  An intermediate proxy might be, but today,
it's problematic.

> 
> Admittedly, when viewed this way, it makes more sense than some
> suggestions. Note that modes 1 and 2 above break things, and mode 3
> isn't particularly useful.
> 
> I'm still not sure where this leaves us, but am beginning to hope that
> we understand the underlying confusion.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Wed Oct  1 15:28:44 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00696
	for <sip-archive@odin.ietf.org>; Wed, 1 Oct 2003 15:28:44 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4me3-00055N-EX
	for sip-archive@odin.ietf.org; Wed, 01 Oct 2003 15:28:20 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h91JSJTv019550
	for sip-archive@odin.ietf.org; Wed, 1 Oct 2003 15:28:19 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4mdm-00054R-7l; Wed, 01 Oct 2003 15:28:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4mdR-00053i-HW
	for sip@optimus.ietf.org; Wed, 01 Oct 2003 15:27:42 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00605
	for <sip@ietf.org>; Wed, 1 Oct 2003 15:27:35 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4mdQ-000448-00
	for sip@ietf.org; Wed, 01 Oct 2003 15:27:40 -0400
Received: from freebsd.tuan.com ([64.124.66.20])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4mdP-000445-00
	for sip@ietf.org; Wed, 01 Oct 2003 15:27:39 -0400
Received: from vaio (64.124.66.210.aaph.com [64.124.66.210])
	by freebsd.tuan.com (8.11.3/8.11.3) with ESMTP id h91JRb303601;
	Wed, 1 Oct 2003 12:27:37 -0700 (PDT)
	(envelope-from mkaleem@purplecomm.com)
Reply-To: <mkaleem@purplecomm.com>
From: "MKaleem" <mkaleem@purplecomm.com>
To: <sip@ietf.org>
Cc: "'Steve Pellegrino'" <Steve.Pellegrino@ulticom.com>,
        <zaifeng.chen@BISC.SIEMENS.COM.CN>
Subject: RE: Sip digest, Vol 1 #1141 - 13 msgs  Subject: Re: [Sip] Any one can confirm that "fork" only means 
Date: Wed, 1 Oct 2003 12:27:33 -0700
Message-ID: <000a01c38852$1443cf70$4f02a8c0@vaio>
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.2627
In-Reply-To: <20030930160001.27623.8063.Mailman@www1.ietf.org>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
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

Steve:

Fork could be either  parallel and/or sequential.
Mark

> -----Original Message-----
> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On 
> Behalf Of sip-request@ietf.org
> Sent: Tuesday, September 30, 2003 9:00 AM
> To: sip@ietf.org
> Subject: Sip digest, Vol 1 #1141 - 13 msgs
> 
> 
> Send Sip mailing list submissions to
> 	sip@ietf.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www1.ietf.org/mailman/listinfo/sip
> or, via email, send a message with subject or body 'help' to
> 	sip-request@ietf.org
> 
> You can reach the person managing the list at
> 	sip-admin@ietf.org
> 
> When replying, please edit your Subject line so it is more 
> specific than "Re: Contents of Sip digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: Re:draft-ietf-sip-publish-00.txt (Paul Kyzivat)
>    2. Unsuscribe (Alejandro Islas)
>    3. sip-publish-00.txt (Samir Srivastava)
>    4. RE: sip-publish-00.txt (Samir Srivastava)
>    5. Any one can confirm that "fork" only means parellel 
> search and no
>        t covers sequential search? (Chen Zaifeng,BISC R&D SA(BJ))
>    6. Re: Re:draft-ietf-sip-publish-00.txt (Aki Niemi)
>    7. Re: sip-publish-00.txt (Aki Niemi)
>    8. Re: Any one can confirm that "fork" only means parellel search
>        and no t covers sequential search? (Steve Pellegrino)
>    9. Re: Re:draft-ietf-sip-publish-00.txt (Paul Kyzivat)
>   10. RE: Re:draft-ietf-sip-publish-00.txt 
> (hisham.khartabil@nokia.com)
>   11. Re: Re:draft-ietf-sip-publish-00.txt (Dean Willis)
> 
> --__--__--
> 
> Message: 1
> Date: Mon, 29 Sep 2003 17:02:11 -0400
> From: Paul Kyzivat <pkyzivat@cisco.com>
> To: Robert Sparks <rsparks@dynamicsoft.com>
> CC: Aki Niemi <aki.niemi@nokia.com>, sip@ietf.org
> Subject: Re: [Sip] Re:draft-ietf-sip-publish-00.txt
> 
> 
> 
> Robert Sparks wrote:
> > On Mon, 2003-09-29 at 14:05, Paul Kyzivat wrote:
> > 
> >>Aki,
> >>
> >>I think the one major issue here is whether the presence 
> document to 
> >>be
> >>affected should be chosen by the To-uri or the Request-uri. 
> Has this 
> >>been explicitly discussed before? I think it is a big 
> decision, and I 
> >>don't think it is a clear cut one. The following things 
> come to my mind 
> >>that are factors affecting, or affected by the decision:
> > 
> > 
> > This was discussed in SIMPLE (several times iirc) and the 
> outcome of 
> > the discussion was that the resource being modified was 
> identified by 
> > the Request-URI.
> 
> I didn't remember. If it has been decided that way, then there are a 
> number of tweaks to the language that need to be made. Most 
> of them were 
> pointed out in my original reply on this subject.
> 
> 	Paul
> 
> 
> 
> --__--__--
> 
> Message: 2
> Reply-To: "Alejandro Islas" <aislas@kbtel.com>
> From: "Alejandro Islas" <aislas@kbtel.com>
> To: <sip@ietf.org>
> Date: Mon, 29 Sep 2003 18:10:45 -0500
> Organization: Kb/TEL
> Subject: [Sip] Unsuscribe
> 
> This is a multi-part message in MIME format.
> 
> ------=_NextPart_000_0011_01C386B5.0087ACC0
> Content-Type: text/plain;
> 	charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
> 
> I would like to unsuscribe my account aislas@kbtel.com from 
> the = sip@ietf.org  Alejandro Islas  Kb/TEL=20
> 
> ------=_NextPart_000_0011_01C386B5.0087ACC0
> 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 
> 6.00.2713.1100" name=3DGENERATOR> <STYLE></STYLE> </HEAD> 
> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial size=3D2>I 
> would like to unsuscribe my account = <A=20 
> href=3D"mailto:aislas@kbtel.com">aislas@kbtel.com</A> from 
> the=20 sip@ietf.org</FONT></DIV> <DIV><FONT face=3DArial 
> size=3D2>&nbsp;Alejandro Islas<BR>&nbsp;Kb/TEL=20 
> </FONT></DIV></BODY></HTML>
> 
> ------=_NextPart_000_0011_01C386B5.0087ACC0--
> 
> 
> 
> --__--__--
> 
> Message: 3
> Date: Mon, 29 Sep 2003 18:10:18 -0700
> From: "Samir Srivastava" <ssrivastava@telverse.com>
> To: "Aki Niemi" <aki.niemi@nokia.com>
> Cc: <sip@ietf.org>
> Subject: [Sip] sip-publish-00.txt
> 
> Hi,
> 
> A) In Section 5, it states
> 
> "EPAs MUST NOT send a new PUBLISH request (not a 
> re-transmission)  until they have received a final response 
> from the ESC for the  previous one or the previous PUBLISH 
> request has timed out. "
> 
>  What's the reason for adding this exception? There may be 
> the cases  when PUBLISH request may be going through proxy 
> which may retransmit.  If it goes thru proxy callId, and Cseq 
> comparission is needed at ESC  as needed in the case of REGISTER.=20
> 
> B) Table 1 and 2 is incomplete.
> 
>   1. In 200 OK, Expires header is MUST. which is not shown.=20
>      Separte entry needed for 2xx.
> =20
>   2. Also Min-Expires header is missing in the table. which 
> is MUST for 423.
> 
> C) In the example Messages, mandatory "Max-Forward" Header is 
> missing from all=20
>    messages.
> 
> Thx
> Samir
> 
> 
> 
> 
> --__--__--
> 
> Message: 4
> Subject: RE: [Sip] sip-publish-00.txt
> Date: Mon, 29 Sep 2003 19:26:40 -0700
> From: "Samir Srivastava" <ssrivastava@telverse.com>
> To: "Samir Srivastava" <ssrivastava@telverse.com>,
>         "Aki Niemi" <aki.niemi@nokia.com>
> Cc: <sip@ietf.org>
> 
> 
> 
> -----Original Message-----
> From: Samir Srivastava=20
> Sent: Monday, September 29, 2003 6:10 PM
> To: Aki Niemi
> Cc: sip@ietf.org
> Subject: [Sip] sip-publish-00.txt
> 
> 
> Hi,
> 
> A) In Section 5, it states
> 
> "EPAs MUST NOT send a new PUBLISH request (not a 
> re-transmission)  until they have received a final response 
> from the ESC for the  previous one or the previous PUBLISH 
> request has timed out. "
> 
>  What's the reason for adding this exception? There may be 
> the cases  when PUBLISH request may be going through proxy 
> which may retransmit.  If it goes thru proxy callId, and Cseq 
> comparission is needed at ESC  as needed in the case of REGISTER.=20
> 
> >> I take back the proxy retransmission. Is there any case 
> due to reboot
>    etc when out of order requests are received at the ESC ?=20
> 
> B) Table 1 and 2 is incomplete.
> 
>   1. In 200 OK, Expires header is MUST. which is not shown.=20
>      Separte entry needed for 2xx.
> =20
>   2. Also Min-Expires header is missing in the table. which 
> is MUST for 423.
> 
> C) In the example Messages, mandatory "Max-Forward" Header is 
> missing from all=20
>    messages.
> 
> Thx
> Samir
> 
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current 
> sip Use sipping@ietf.org for new developments on the 
> application of sip
> 
> 
> --__--__--
> 
> Message: 5
> From: "Chen Zaifeng,BISC R&D SA(BJ)" 
> <zaifeng.chen@BISC.SIEMENS.COM.CN>
> To: SIP@ietf.org
> Date: Tue, 30 Sep 2003 11:13:24 +0800
> Subject: [Sip] Any one can confirm that "fork" only means 
> parellel search and no  t covers sequential search?
> 
> Dear All:
> 
> In RFC3261 page 15 there is such a description "A proxy 
> server can also send an INVITE to a number of locations at 
> the same time.  This type of parallel search is known as 
> forking." I think this is enough to say that fork only means 
> parellel search.
> 
> But some other people think that the description doesn't deny 
> the case of sequential seach, so any one can confirm that 
> "fork" only means parellel search and not covers sequential search?
> 
> Thanks!
> 
> Sincerely yours, 
> Chen Zaifeng
> --------------------------------------------------------------
> ------------
> Beijing International Switching System Corporation Ltd.
> R&D SA
> No. 14 Jiu Xian Qiao Road
> Beijing 100016, P. R. China
> Tel:  +86-10-8457 1921
> Fax: +86-10-6436 7732
> E-mail: <mailto:zaifeng.chen@bisc.siemens.com.cn>
> 
> 
> 
> 
> 
> --__--__--
> 
> Message: 6
> Date: Tue, 30 Sep 2003 11:43:43 +0300
> From: Aki Niemi <aki.niemi@nokia.com>
> To: ext Paul Kyzivat <pkyzivat@cisco.com>
> CC: Robert Sparks <rsparks@dynamicsoft.com>, sip@ietf.org
> Subject: Re: [Sip] Re:draft-ietf-sip-publish-00.txt
> 
> Hi,
> 
> As long as I can remember, PUBLISH's use of To and From have been 
> consistent with REGISTER all the way down to explicitly allowing for 
> third-party publications. The use of Request-URI as identifying the 
> target resource has admittedly been ambiguously defined. The way the 
> draft currently reads is that they are both kind of used - 
> which works 
> fine if they are the same.
> 
> But I think Paul brings up an important issue about 
> forwarding PUBLISH 
> requests. What is the use case, and the semantics we are looking for?
> 
> 1) Alice's PUBLISH gets forwarded to Bob, whose ESC rejects 
> the request.
> 
>    -> Consequently a forwarded subscription will deliver only
>       Bob's presence
> 
> 2) Alice's PUBLISH gets forwarded to Bob, whose ESC composes 
> the event 
> state into Bob's presence document.
> 
>    -> Consequently a forwarded subscription will deliver the union or
>       some combination of Bob's and Alice's presence
> 
> 3) Alice's PUBLISH gets forwarded to Bob, whose ESC establishes event 
> state for Alice
> 
>    -> Consequently a forwarded subscription will deliver 
> Alice's presence
>       which is now "parked" in Bob's Presence Server
> 
> Out of these three, I especially like the properties of 3). It would 
> allow one to have a static SIP address, e.g., "sip:aki.niemi@iki.fi", 
> which would be forwarded to whatever service provider one was 
> using at 
> the time, e.g., "sip:aki.niemi@nokia.com", 
> "sip:hillomunkki@foo.someisp.org". In practice, I could "park" the 
> presence of "sip:aki.niemi@iki.fi" into nokia.com, or 
> foo.someisp.org's 
> presence system.
> 
> The problem is that by default, a presence server does *not* 
> look at the 
> To-field. It only looks at the Request-URI to determine the requested 
> resource. So a subscription to "sip:aki.niemi@iki.fi" would 
> deliver the 
> presence of a completely different presentity.
> 
> I don't much like 2), but that's probably because I don't quite 
> understand the use-case. What would the resulting presence 
> document look 
> like? Would it still have entity="pres:bob@biloxi.com", and just have 
> alice's tuples? IMO, this sort of thing could be more easily 
> achieved by 
> configuring Alice's EPAs to publish presence directly to 
> sip:bob@biloxi.com.
> 
> So in my opinion, the key issue really is whether we see 3) 
> as useful, 
> and/or feasible. That is the only use-case I can think of 
> right now that 
> would strictly require using the To-field as the resource 
> pointer. This 
> would also require some clarification to RFC 3265 on resource 
> identification, so it's not an entirely uncontroversial road 
> to take either.
> 
> Thoughts?
> 
> Cheers,
> Aki
> 
> 
> On 30.09.2003 00:02, ext Paul Kyzivat:
> > 
> > 
> > Robert Sparks wrote:
> > 
> >> On Mon, 2003-09-29 at 14:05, Paul Kyzivat wrote:
> >>
> >>> Aki,
> >>>
> >>> I think the one major issue here is whether the presence 
> document to
> >>> be affected should be chosen by the To-uri or the 
> Request-uri. Has 
> >>> this been explicitly discussed before? I think it is a 
> big decision, 
> >>> and I don't think it is a clear cut one. The following 
> things come to 
> >>> my mind that are factors affecting, or affected by the decision:
> >>
> >>
> >>
> >> This was discussed in SIMPLE (several times iirc) and the 
> outcome of 
> >> the discussion was that the resource being modified was 
> identified by 
> >> the Request-URI.
> > 
> > 
> > I didn't remember. If it has been decided that way, then there are a
> > number of tweaks to the language that need to be made. Most 
> of them were 
> > pointed out in my original reply on this subject.
> > 
> >     Paul
> > 
> 
> 
> 
> 
> --__--__--
> 
> Message: 7
> Date: Tue, 30 Sep 2003 11:57:08 +0300
> From: Aki Niemi <aki.niemi@nokia.com>
> To: ext Samir Srivastava <ssrivastava@telverse.com>
> CC: sip@ietf.org
> Subject: Re: [Sip] sip-publish-00.txt
> 
> Hi Samir,
> 
> Comments inline,
> 
> On 30.09.2003 05:26, ext Samir Srivastava:
> > 
> > Hi,
> > 
> > A) In Section 5, it states
> > 
> > "EPAs MUST NOT send a new PUBLISH request (not a re-transmission)  
> > until they have received a final response from the ESC for the  
> > previous one or the previous PUBLISH request has timed out. "
> > 
> >  What's the reason for adding this exception?
> 
> This restriction is mainly due to congestion concerns. The same 
> restriction applies to MESSAGE requests.
> 
> >  There may be the cases
> >  when PUBLISH request may be going through proxy which may 
> retransmit.  
> > If it goes thru proxy callId, and Cseq comparission is 
> needed at ESC  
> > as needed in the case of REGISTER.
> > 
> >>> I take back the proxy retransmission. Is there any case due to 
> >>> reboot
> >    etc when out of order requests are received at the ESC ?
> 
> PUBLISH requests are process in the order that they arrive at 
> the ESC. 
> The If-Match header field is used to identify the specific state that 
> the request is targetting.
> 
> I don't quite understand the problem. Can you elaborate a bit?
> 
> > 
> > B) Table 1 and 2 is incomplete.
> > 
> >   1. In 200 OK, Expires header is MUST. which is not shown. 
> >      Separte entry needed for 2xx.
> >  
> >   2. Also Min-Expires header is missing in the table. which is MUST 
> > for 423.
> 
> Good catch. I will add both to the table.
> 
> > 
> > C) In the example Messages, mandatory "Max-Forward" Header 
> is missing 
> > from all
> >    messages.
> 
> Will add that in the next revision.
> 
> Cheers,
> Aki
> 
> > 
> > Thx
> > Samir
> > 
> > 
> > 
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on 
> current sip Use 
> > sipping@ietf.org for new developments on the application of sip
> 
> 
> 
> 
> --__--__--
> 
> Message: 8
> Date: Tue, 30 Sep 2003 07:58:34 -0400
> From: Steve Pellegrino <Steve.Pellegrino@ulticom.com>
> To: "Chen Zaifeng,BISC R&D SA(BJ)" <zaifeng.chen@BISC.SIEMENS.COM.CN>
> CC: sip <sip@ietf.org>
> Subject: Re: [Sip] Any one can confirm that "fork" only means 
> parellel search  and no t covers sequential search?
> 
> Refer to section 16.6 that goes on to describe that the proxy 
> MAY choose 
> to forward the request to targets in the set (i.e. fork the request) 
> serially, in parallel, or using a combination of both.
> 
> Regards,
> Steve
> 
> 
> Chen Zaifeng,BISC R&D SA(BJ) wrote:
> 
> >Dear All:
> >
> >In RFC3261 page 15 there is such a description "A proxy 
> server can also 
> >send an INVITE to a number of locations at the same time.  
> This type of 
> >parallel search is known as forking." I think this is enough to say 
> >that fork only means parellel search.
> >
> >But some other people think that the description doesn't 
> deny the case 
> >of sequential seach, so any one can confirm that "fork" only means 
> >parellel search and not covers sequential search?
> >
> >Thanks!
> >
> >Sincerely yours,
> >Chen Zaifeng
> >-------------------------------------------------------------
> -------------
> >Beijing International Switching System Corporation Ltd.
> >R&D SA
> >No. 14 Jiu Xian Qiao Road
> >Beijing 100016, P. R. China
> >Tel:  +86-10-8457 1921
> >Fax: +86-10-6436 7732
> >E-mail: <mailto:zaifeng.chen@bisc.siemens.com.cn>
> >
> >
> >
> >
> >_______________________________________________
> >Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >This list is for NEW development of the core SIP Protocol
> >Use sip-implementors@cs.columbia.edu for questions on 
> current sip Use 
> >sipping@ietf.org for new developments on the application of sip
> >
> >  
> >
> 
> 
> 
> --__--__--
> 
> Message: 9
> Date: Tue, 30 Sep 2003 09:39:55 -0400
> From: Paul Kyzivat <pkyzivat@cisco.com>
> To: Aki Niemi <aki.niemi@nokia.com>
> CC: Robert Sparks <rsparks@dynamicsoft.com>, sip@ietf.org
> Subject: Re: [Sip] Re:draft-ietf-sip-publish-00.txt
> 
> 
> 
> Aki Niemi wrote:
> > Hi,
> > 
> > As long as I can remember, PUBLISH's use of To and From have been
> > consistent with REGISTER all the way down to explicitly 
> allowing for 
> > third-party publications.
> 
> The use of From, and 3rd party publications isn't in question 
> here. It 
> is the unaffected by how the target is selected.
> 
> I admit I haven't been following the development of PUBLISH closely 
> enough to remember whether there has agreement on how the target is 
> selected. That is why I asked. Apparently Robert thinks there was 
> agreement that the request uri would be used, while you seem to think 
> that To will be used.
> 
> I think consistency argues for using the request uri, unless some 
> compelling argument wins the day. But that is just my opinion.
> 
>  > The use of Request-URI as identifying the
> > target resource has admittedly been ambiguously defined. The way the
> > draft currently reads is that they are both kind of used - 
> which works 
> > fine if they are the same.
> 
> :-)
> 
> > But I think Paul brings up an important issue about 
> forwarding PUBLISH
> > requests. What is the use case, and the semantics we are 
> looking for?
> > 
> > 1) Alice's PUBLISH gets forwarded to Bob, whose ESC rejects the 
> > request.
> > 
> >   -> Consequently a forwarded subscription will deliver only
> >      Bob's presence
> > 
> > 2) Alice's PUBLISH gets forwarded to Bob, whose ESC 
> composes the event
> > state into Bob's presence document.
> > 
> >   -> Consequently a forwarded subscription will deliver the union or
> >      some combination of Bob's and Alice's presence
> > 
> > 3) Alice's PUBLISH gets forwarded to Bob, whose ESC 
> establishes event
> > state for Alice
> > 
> >   -> Consequently a forwarded subscription will deliver 
> Alice's presence
> >      which is now "parked" in Bob's Presence Server
> > 
> > Out of these three, I especially like the properties of 3). It would
> > allow one to have a static SIP address, e.g., 
> "sip:aki.niemi@iki.fi", 
> > which would be forwarded to whatever service provider one 
> was using at 
> > the time, e.g., "sip:aki.niemi@nokia.com", 
> > "sip:hillomunkki@foo.someisp.org". In practice, I could "park" the 
> > presence of "sip:aki.niemi@iki.fi" into nokia.com, or 
> foo.someisp.org's 
> > presence system.
> > 
> > The problem is that by default, a presence server does 
> *not* look at 
> > the
> > To-field. It only looks at the Request-URI to determine the 
> requested 
> > resource. So a subscription to "sip:aki.niemi@iki.fi" would 
> deliver the 
> > presence of a completely different presentity.
> 
> Yes. While (3) may be interesting in some ways, to be useful 
> it requires 
> a change in the way subscribe works. And I think that would have many 
> unintended consequences. While the scenario might be useful for 
> presence, it wouldn't be very appealing for other packages, such as 
> "dialog".
> 
> > I don't much like 2), but that's probably because I don't quite
> > understand the use-case. What would the resulting presence 
> document look 
> > like? Would it still have entity="pres:bob@biloxi.com", and 
> just have 
> > alice's tuples?
> 
> I also can't think of a use case where this is valid. But 
> neither can I 
> think of a use case where (3) is valid - I can't think of a business 
> model where the operator of the presence server for Bob would 
> want to do 
> this.
> 
> I think (1) is the interesting use case, and it works regardless of 
> whether the target is chosen using the request uri or the To uri.
> 
>  > IMO, this sort of thing could be more easily achieved by
> > configuring Alice's EPAs to publish presence directly to
> > sip:bob@biloxi.com.
> 
> I think if Alice is going away and wants to forward calls to 
> Bob, that 
> she should do something different with her presence. Probably 
> configure 
> some static state indicating she is away, and listing Bob as an 
> alternative contact. Her forwarding should not include 
> subscriptions for 
> presence.
> 
> If she neglects to do this then all the alternatives seem to provide 
> comparably useless results.
> 
> > So in my opinion, the key issue really is whether we see 3) 
> as useful,
> > and/or feasible. That is the only use-case I can think of 
> right now that 
> > would strictly require using the To-field as the resource 
> pointer. This 
> > would also require some clarification to RFC 3265 on resource 
> > identification, so it's not an entirely uncontroversial 
> road to take 
> > either.
> 
> Covered above.
> 
> 	Paul
> 
> 
> 
> --__--__--
> 
> Message: 10
> From: hisham.khartabil@nokia.com
> Subject: RE: [Sip] Re:draft-ietf-sip-publish-00.txt
> Date: Tue, 30 Sep 2003 18:44:02 +0300
> To: <pkyzivat@cisco.com>, <aki.niemi@nokia.com>
> Cc: <rsparks@dynamicsoft.com>, <sip@ietf.org>
> 
> The way Alice gets her PUBLISH to be delivered to Bob is by 
> registering = her AOR (using REGISTER) with a contact header 
> that has Bob's URI with = parameter method=3DPUBLISH. Now, 
> what is the use case for Alice to do = that? I don't know.
> 
> About To-header vs. Request-URI: I favour request-URI for consistency.
> 
> Regards,
> Hisham
> 
> > -----Original Message-----
> > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com]
> > Sent: Tuesday, September 30, 2003 4:40 PM
> > To: Niemi Aki (NMP/Helsinki)
> > Cc: Robert Sparks; sip@ietf.org
> > Subject: Re: [Sip] Re:draft-ietf-sip-publish-00.txt
> >=20
> >=20
> >=20
> >=20
> > Aki Niemi wrote:
> > > Hi,
> > >=20
> > > As long as I can remember, PUBLISH's use of To and From 
> have been=20  
> > >consistent with REGISTER all the way down to explicitly=20
> > allowing for=20
> > > third-party publications.
> >=20
> > The use of From, and 3rd party publications isn't in question=20  
> >here. It=20  is the unaffected by how the target is selected.
> >=20
> > I admit I haven't been following the development of PUBLISH 
> closely=20
> > enough to remember whether there has agreement on how the 
> target is=20
> > selected. That is why I asked. Apparently Robert thinks there was=20
> > agreement that the request uri would be used, while you 
> seem to think=20
> > that To will be used.
> >=20
> > I think consistency argues for using the request uri, unless some=20
> > compelling argument wins the day. But that is just my opinion.
> >=20
> >  > The use of Request-URI as identifying the
> > > target resource has admittedly been ambiguously defined.=20
> > The way the=20
> > > draft currently reads is that they are both kind of used -=20
> > which works=20
> > > fine if they are the same.
> >=20
> > :-)
> >=20
> > > But I think Paul brings up an important issue about=20
> > forwarding PUBLISH=20
> > > requests. What is the use case, and the semantics we are=20
> > looking for?
> > >=20
> > > 1) Alice's PUBLISH gets forwarded to Bob, whose ESC rejects=20
> > the request.
> > >=20
> > >   -> Consequently a forwarded subscription will deliver only
> > >      Bob's presence
> > >=20
> > > 2) Alice's PUBLISH gets forwarded to Bob, whose ESC=20
> > composes the event=20
> > > state into Bob's presence document.
> > >=20
> > >   -> Consequently a forwarded subscription will deliver 
> the union or
> > >      some combination of Bob's and Alice's presence
> > >=20
> > > 3) Alice's PUBLISH gets forwarded to Bob, whose ESC=20
> > establishes event=20
> > > state for Alice
> > >=20
> > >   -> Consequently a forwarded subscription will deliver=20
> > Alice's presence
> > >      which is now "parked" in Bob's Presence Server
> > >=20
> > > Out of these three, I especially like the properties of 3).=20
> > It would=20
> > > allow one to have a static SIP address, e.g.,=20
> > "sip:aki.niemi@iki.fi",=20
> > > which would be forwarded to whatever service provider one=20
> > was using at=20
> > > the time, e.g., "sip:aki.niemi@nokia.com",=20 
> > > "sip:hillomunkki@foo.someisp.org". In practice, I could "park" 
> > > the=20 presence of "sip:aki.niemi@iki.fi" into nokia.com, or=20
> > foo.someisp.org's=20
> > > presence system.
> > >=20
> > > The problem is that by default, a presence server does=20
> > *not* look at the=20
> > > To-field. It only looks at the Request-URI to determine the=20
> > requested=20
> > > resource. So a subscription to "sip:aki.niemi@iki.fi" would=20
> > deliver the=20
> > > presence of a completely different presentity.
> >=20
> > Yes. While (3) may be interesting in some ways, to be useful=20  it 
> >requires=20  a change in the way subscribe works. And I think that 
> >would have many=20  unintended consequences. While the 
> scenario might 
> >be useful for=20  presence, it wouldn't be very appealing for other 
> >packages, such as=20  "dialog".
> >=20
> > > I don't much like 2), but that's probably because I don't 
> quite=20 
> > > understand the use-case. What would the resulting presence=20
> > document look=20
> > > like? Would it still have entity=3D"pres:bob@biloxi.com", and=20
> > just have=20
> > > alice's tuples?
> >=20
> > I also can't think of a use case where this is valid. 
> But=20  neither 
> >can I=20  think of a use case where (3) is valid - I can't 
> think of a 
> >business=20  model where the operator of the presence server for Bob 
> >would=20  want to do=20
> > this.
> >=20
> > I think (1) is the interesting use case, and it works 
> regardless of=20
> > whether the target is chosen using the request uri or the To uri.
> >=20
> >  > IMO, this sort of thing could be more easily achieved by
> > > configuring Alice's EPAs to publish presence directly to=20 
> > > sip:bob@biloxi.com.
> >=20
> > I think if Alice is going away and wants to forward calls 
> to=20  Bob, 
> >that=20  she should do something different with her presence. 
> >Probably=20  configure=20
> > some static state indicating she is away, and listing Bob as an=20
> > alternative contact. Her forwarding should not include=20
> > subscriptions for=20
> > presence.
> >=20
> > If she neglects to do this then all the alternatives seem 
> to provide=20
> > comparably useless results.
> >=20
> > > So in my opinion, the key issue really is whether we see 3)=20
> > as useful,=20
> > > and/or feasible. That is the only use-case I can think of=20
> > right now that=20
> > > would strictly require using the To-field as the resource=20
> > pointer. This=20
> > > would also require some clarification to RFC 3265 on resource=20 
> > > identification, so it's not an entirely uncontroversial=20
> > road to take=20
> > > either.
> >=20
> > Covered above.
> >=20
> > 	Paul
> >=20
> >=20
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on 
> current sip  Use 
> >sipping@ietf.org for new developments on the application of sip =20
> 
> 
> --__--__--
> 
> Message: 11
> Subject: Re: [Sip] Re:draft-ietf-sip-publish-00.txt
> From: Dean Willis <dean.willis@softarmor.com>
> To: Aki Niemi <aki.niemi@nokia.com>
> Cc: ext Paul Kyzivat <pkyzivat@cisco.com>,
>         Robert Sparks <rsparks@dynamicsoft.com>, sip@ietf.org
> Date: Tue, 30 Sep 2003 10:50:14 -0500
> 
> On Tue, 2003-09-30 at 03:43, Aki Niemi wrote:
> > Hi,
> > 
> > As long as I can remember, PUBLISH's use of To and From have been
> > consistent with REGISTER all the way down to explicitly 
> allowing for 
> > third-party publications. The use of Request-URI as identifying the 
> > target resource has admittedly been ambiguously defined. 
> The way the 
> > draft currently reads is that they are both kind of used - 
> which works 
> > fine if they are the same.
> 
> As I recall, the original design team was unanimous in its 
> decision to indicate the target of PUBLISH using the request URI.
> 
> REGISTER is unfortunately somewhat broken. This is an 
> artifact of the originally-slightly-broken source-routing 
> model of SIP ala 2543, which is "much beter now". We wouldn't 
> design REGISTER that way now, and I see no need to replicate 
> REGISTER's annoying quirks going forward. I actually have 
> some hope that PUBLISH can eventually be used to replace 
> REGISTER -- after all, REGISTER is just the action of 
> publishing a contact (and, with caller-pref, some capabilities).
> 
> --
> 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
> 
> End of Sip Digest
> 


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Wed Oct  1 15:37:35 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01082
	for <sip-archive@odin.ietf.org>; Wed, 1 Oct 2003 15:37:35 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4mmb-0005WT-KB
	for sip-archive@odin.ietf.org; Wed, 01 Oct 2003 15:37:11 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h91Jb9YN021192
	for sip-archive@odin.ietf.org; Wed, 1 Oct 2003 15:37:09 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4mmU-0005Tv-NC; Wed, 01 Oct 2003 15:37:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4mlv-0005T8-2q
	for sip@optimus.ietf.org; Wed, 01 Oct 2003 15:36:28 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01023
	for <sip@ietf.org>; Wed, 1 Oct 2003 15:36:20 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4mlt-0004Ca-00
	for sip@ietf.org; Wed, 01 Oct 2003 15:36:25 -0400
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4mlt-0004Bc-00
	for sip@ietf.org; Wed, 01 Oct 2003 15:36:25 -0400
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h91JZlJu011967;
	Wed, 1 Oct 2003 12:35:50 -0700 (PDT)
Received: from cisco.com ([161.44.79.51])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ACV09625;
	Wed, 1 Oct 2003 15:35:46 -0400 (EDT)
Message-ID: <3F7B2C92.3010408@cisco.com>
Date: Wed, 01 Oct 2003 15:35:46 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
CC: "'Dean Willis'" <dean.willis@softarmor.com>,
        "'Stastny Richard'" <Richard.Stastny@oefeg.at>,
        Rohan Mahy <rohan@cisco.com>,
        Francois Audet <audet@nortelnetworks.com>,
        Bob Penfield <bpenfield@acmepacket.com>, sip@ietf.org
Subject: Re: [Sip] SIPIT Interop problem with ;user=phone
References: <313680C9A886D511A06000204840E1CF070B5F2A@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: 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

Rosen, Brian wrote:
> 
> No, my point was that if I have one phone that sends a dial string,
> and another phone that sends a phone number, at some point, someone
> has to know that they are interpreted differently.

Brian,

You keep bringing up the same issues, but you haven't responded to 
earlier proposals that address your concerns. Specifically, how does the 
following not meet your needs?

- one phone-context to represent a dial string
- a different phone-context to represent a (local) phone number.

As best I can tell, this should meet your needs, even if it isn't in the 
form you would prefer.

Proxies that translate a dial string into a phone number also make the 
appropriate change to the the phone-context. Anybody that receives such 
a thing and doesn't understand the context can either pass it on to 
somebody else that might, or can simply fail.

BTW, I agree that the presence or absence of gateways doesn't change 
this problem at all.

	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 exim@www1.ietf.org  Wed Oct  1 16:02:40 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02013
	for <sip-archive@odin.ietf.org>; Wed, 1 Oct 2003 16:02:40 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4nAu-0006qU-Kh
	for sip-archive@odin.ietf.org; Wed, 01 Oct 2003 16:02:17 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h91K2GJE026257
	for sip-archive@odin.ietf.org; Wed, 1 Oct 2003 16:02:16 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4nAf-0006oz-K4; Wed, 01 Oct 2003 16:02:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4n9j-0006no-LK
	for sip@optimus.ietf.org; Wed, 01 Oct 2003 16:01:03 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01969
	for <sip@ietf.org>; Wed, 1 Oct 2003 16:00:56 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4n9h-0004TS-00
	for sip@ietf.org; Wed, 01 Oct 2003 16:01:02 -0400
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4n9h-0004TE-00
	for sip@ietf.org; Wed, 01 Oct 2003 16:01:01 -0400
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 QAA19211;
	Wed, 1 Oct 2003 16:00:28 -0400 (EDT)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA19331;
	Wed, 1 Oct 2003 16:00:30 -0400 (EDT)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19)
	id <S6M3XH8A>; Wed, 1 Oct 2003 16:00:29 -0400
Message-ID: <313680C9A886D511A06000204840E1CF070B5F30@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Paul Kyzivat'" <pkyzivat@cisco.com>
Cc: "'Dean Willis'" <dean.willis@softarmor.com>,
        "'Stastny Richard'"
	 <Richard.Stastny@oefeg.at>,
        Rohan Mahy <rohan@cisco.com>,
        Francois Audet
	 <audet@nortelnetworks.com>,
        Bob Penfield <bpenfield@acmepacket.com>, sip@ietf.org
Subject: RE: [Sip] SIPIT Interop problem with ;user=phone
Date: Wed, 1 Oct 2003 16:00:29 -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 was responding to this post, which doesn't discuss that aspect.

I think I have responded to the "differentiate by context" idea.
It requires that there be a way to differentiate configuration;
you have to know which devices translate, and which don't and get
them the correct context.  I think that is hard, and it's
unnecessary that it be that hard.  Usually, all the devices in 
a domain are in the same context.  

It means that every proxy in a path that routes has to know
both contexts so that it can figure out what it has.

I would much rather explicitly label the uri with what it
contains.

Having said that, if we write a BCP that explains how this works,
I can live with it.  I'm volunteered to do some writing, so this
could be a part of it.

Brian

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Wednesday, October 01, 2003 3:36 PM
> To: Rosen, Brian
> Cc: 'Dean Willis'; 'Stastny Richard'; Rohan Mahy; Francois Audet; Bob
> Penfield; sip@ietf.org
> Subject: Re: [Sip] SIPIT Interop problem with ;user=phone
> 
> 
> Rosen, Brian wrote:
> > 
> > No, my point was that if I have one phone that sends a dial string,
> > and another phone that sends a phone number, at some point, someone
> > has to know that they are interpreted differently.
> 
> Brian,
> 
> You keep bringing up the same issues, but you haven't responded to 
> earlier proposals that address your concerns. Specifically, 
> how does the 
> following not meet your needs?
> 
> - one phone-context to represent a dial string
> - a different phone-context to represent a (local) phone number.
> 
> As best I can tell, this should meet your needs, even if it 
> isn't in the 
> form you would prefer.
> 
> Proxies that translate a dial string into a phone number also 
> make the 
> appropriate change to the the phone-context. Anybody that 
> receives such 
> a thing and doesn't understand the context can either pass it on to 
> somebody else that might, or can simply fail.
> 
> BTW, I agree that the presence or absence of gateways doesn't change 
> this problem at all.
> 
> 	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 exim@www1.ietf.org  Wed Oct  1 16:14:30 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02506
	for <sip-archive@odin.ietf.org>; Wed, 1 Oct 2003 16:14:30 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4nMM-00082C-DZ
	for sip-archive@odin.ietf.org; Wed, 01 Oct 2003 16:14:06 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h91KE6T2030878
	for sip-archive@odin.ietf.org; Wed, 1 Oct 2003 16:14:06 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4nMI-00081A-BM; Wed, 01 Oct 2003 16:14:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4nM1-0007xa-Re
	for sip@optimus.ietf.org; Wed, 01 Oct 2003 16:13:46 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02487
	for <sip@ietf.org>; Wed, 1 Oct 2003 16:13:38 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4nM0-0004dq-00
	for sip@ietf.org; Wed, 01 Oct 2003 16:13:44 -0400
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4nLy-0004db-00
	for sip@ietf.org; Wed, 01 Oct 2003 16:13:43 -0400
Received: from cisco.com (171.71.177.237)
  by sj-iport-3.cisco.com with ESMTP; 01 Oct 2003 13:18:31 -0700
Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h91KDAwn009982;
	Wed, 1 Oct 2003 13:13:10 -0700 (PDT)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AMC56259;
	Wed, 1 Oct 2003 13:10:05 -0700 (PDT)
Date: Wed, 1 Oct 2003 13:17:07 -0700
Subject: Re: [Sip] SIPIT Interop problem with ;user=phone
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: "'Dean Willis'" <dean.willis@softarmor.com>,
        "'Stastny Richard'" <Richard.Stastny@oefeg.at>,
        Francois Audet <audet@nortelnetworks.com>,
        Paul Kyzivat <pkyzivat@cisco.com>,
        Bob Penfield <bpenfield@acmepacket.com>, sip@ietf.org
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
From: Rohan Mahy <rohan@cisco.com>
In-Reply-To: <313680C9A886D511A06000204840E1CF070B5F2A@whq-msgusr-02.pit.comms.marconi.com>
Message-Id: <3AF63C0D-F44C-11D7-8F68-0003938AF740@cisco.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
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 Wednesday, October 1, 2003, at 11:12 AM, Rosen, Brian wrote:

> Getting back to this.  I was working on other things.
>
> One overriding criticism I have for this post is that it assumes
> that a gateway is the ultimate destination for a call with user=phone.
> It isn't.  A sipphone is just as likely a destination as a gateway.
> If I assign an E.164, or an internal number, to a phone so that
> callers with TDM equipment can call them (or simplistic user interfaces
> that encourage meaningless strings of digits as the user part of
> a nice sip AOR), then when I call it, many, many existing systems
> will append user=phone to the request URI.
>
> Much more in line
>
>> -----Original Message-----
>> From: Dean Willis [mailto:dean.willis@softarmor.com]
>> Sent: Monday, September 22, 2003 12:06 PM
>> To: Rosen, Brian
>> Cc: 'Stastny Richard'; Rohan Mahy; Francois Audet; Paul Kyzivat; Bob
>> Penfield; sip@ietf.org
>> Subject: RE: [Sip] SIPIT Interop problem with ;user=phone
>>
>>
>>
>> Ah! I think we have something here!
>>
>> Brian said:
>>> A user at a dumb phone always enters a dial string.
>>> No argument.
>>>
>>> However, at some point, either a UA translates a dial string
>>> to a phone number, or a downstream proxy does it.  At that point
>>> it isn't a dial string, it's a phone number, and it might be
>>> in a context (it could be global).  What I've mentioned is
>>> a case, which I think is pretty common, where the number is
>>> not represented the same way as a dial string and a phone number,
>>> and yet is in the same domain.
>>
>> Actually, this isn't quite right. Proxies transform URIs. They can do
>> all sorts of transformations -- changing the domain, the user part,
>> parameters, etc. for any number of reasons and using any number of
>> mechanisms to specify that transformation. It's never a
>> dial-string when
>> it's being processed by a proxy. It might CONTAIN information that is
>> meant to represent a dial-string, but it's a request URI as long as
>> we're thinking about the problem from the proxy's perspective.
>>
>> Eventually, that request (and its associated, potentially transformed
>> URI) may be delivered to a telephony gateway. The gateway's job is to
>> construct appropriate PSTN signaling based on the request-URI. By
>> today's convention, simple gateways take the user part of the request
>> URI and use it as the signaling input to the PSTN -- i.e., a "dial
>> string". More sophisticated gateways verify that the host-part of the
>> request (if any) targets the gateway. Even more sophisticated gateways
>> perform their own transformations on the user part, perhaps applying
>> regular expressions or similar programatic mechanisms. Oddly
>> enough, no
>> gateway that I'm aware of treats a request any differently if it has a
>> user=phone parameter than it does if there is no user=phone parameter,
>> and there's not even any way to test for this in the
>> expression language
>> of such gateways, as far as I know.
> Woah.  I think gateways are the least interesting part of the problem.
>
> I agree that a gateway doesn't need or care about user=phone.
>
> I agree that gateways sometimes have the ability to transform dial 
> strings
> to phone numbers.  I think that only adds to the confusion we now have.
> Gateways that I know about can't differentiate between a dial string
> and a phone number; they treat all input as dial strings.  If the
> environment
> those gateways were a part of had phone numbers that were not dial 
> strings,
> they would be incapable of dialing the phone numbers.  Some element 
> would
> have to make sure the user part was a dial string.  It would be useful,
> I think, for there to be a way to tell the difference.  Then such 
> gateways
> could selectively apply the transformation logic.
>
>>
>> So who does pay attention to a parameter of user=phone?
>> Potentially, it
>> is considered by intermediate proxies, who are trying to
>> decide 1) What
>> transformation to make to the request URI, if any, and 2)
>> Where to send
>> the request next.
>>
>> I believe there have been suggestions that proxies use user=phone in
>> several distinct ways:
>>
>> 1) As a way to indicate that this request URI is intended for eventaul
>> delivery (unless otherwise transformed) to a PSTN gateway.
> I don't know of any device that does this.  Specifically, no device
> that I know of has any way to know what the characteristics of the
> destination is - gateway, sipphone, H.323 phone,...
>
> If you said "as a way to indicate that this is a phone number,
> maybe we could get somewhere.
>>
>> 2) As a way to indicate that the request URI MUST be
>> delivered to a PSTN
>> gateway, and that the user-part of the request-URI is expected to be
>> meaningly translatable to PSTN signaling by a gateway in the domain or
>> context of the request.
> Again, I know of no device that does this.  No device that I know of
> has any way to know whether a numeric user part has anything to
> do with PSTN signalling or not, whether there is a gateway of any
> kind involved. or whether the numeric string is translatable to
> PSTN signalling
>
>>
>> 3) As a way to inidcate that the SIP or SIPS request-URI was
>> constructed
>> from a tel URI, which transformation may or may not be reversable.
> Ahh, at last.  Yes, this is ONE possible use of user=phone.
>
>>
>> 4) As a way to indicate that some prior device in the processing chain
>> has transformed the user-part of the request URI FROM a dial-string to
>> some sort of unique user-part so that it can be used in routing. This
>> might be better addressed by a "history" sort of operation.
> Agree this could be a use of user=phone, and I agree it may not be the
> best use.  I think we need a way to know if this is a phone number or
> a dial string.

I still don't get what you are on about here.  How does a HUMAN know if 
something is a phone number or a dial string?  they don't.  likewise, 
as long as we are leaving out wait and pause, you can represent all 
dial strings as a local-number in the ABNF of a tel URL. If you want to 
make a distinction here, why not just make one using phone-context?

> It's not clear to me that we need to know if there
> was dial string to phone number conversion somewhere along the line.
> I can't think of why you need that.  A uri originating
> as a phone number is interchangeable, I think, with a dial string
> transformed to a phone number.  The requirement is to differentiate
> dial strings from phone numbers, not the history of how we came to
> have one or the other.
>
>>
>> 5) As a way to indicate that some prior device in the processing chain
>> has transformed the user part INTO a dial-string which can be
>> correctly
>> interpreted by a specific PSTN gateway. This might be better addressed
>> by a "history" sort of operation.
> Yeah, I first was confused by this, but I now understand that if you
> have, for example, a real E.164, but your gateway faces a PBX, you 
> usually
> can't give the PBX the E.164.  You have to transform it into a dial
> string (prepend with 9 for example).
>
> This again argues for a way to know if a uri is a dial string or a
> phone number.

again, you can use phone-context to disambiguate this if you'd like.

>> 6) As a way to indicate that the originating UA doesn't know
>> what to do
>> with user-input and that further transformation is required by a proxy
>> for the request-URI to resolve to the intended target.
> Agree again that this is one use user=phone has been put to.
> Generally, we treat user input as a dial string, but we don't really
> have to, that's just a convention.

You can trivially scope this by adding an appropriate phone-context 
parameter here.

>> Brian further expounds:
>>
>>> Let's take a practical example.  Suppose I have a domain with
>>> a reasonably smart proxy server and a mix of phones.  Some phones
>>> have dialstring translation, some don't.  The proxy server
>>> can translate dial strings to phone numbers, and it also can
>>> route phone numbers.  Obviously it can do both (ie translate then
>>> route).
>>>
>>> Now, how does the proxy know if it needs to translate?  That is,
>>> how does it know that a uri passed to it is a dial string vs
>>> a phone number?  If I pass it a phone number and it decides to
>>> apply it's dialstring processing, that will fail.  If I pass a
>>> dial string and it just routes, that will fail.  It has to know
>>> what it is given.  In my example it was 7246826@pit.sip.marconi.com
>>> That's a phone number, and a dial string, but it's two different
>>> destinations.  In my numbering plan, it's my phone.  In my dialing
>>> plan it's an extension in another office.
>>>
>>
>> In this case, you appear to be using mode 6 as described above.
> No, my point was that if I have one phone that sends a dial string,
> and another phone that sends a phone number, at some point, someone
> has to know that they are interpreted differently.

I believe I already gave several examples using phone-context that 
allow you to disambiguate these.

>>
>> Discussion:
>>
>> Some phones know how to transform a sequence of user-entered
>> digits into
>> a routable request. These phones, when presented a user input loooking
>> like a string of digits, use this capability to generate a request URI
>> targeting the (effectively) globally-routable destination. Such a
>> request has no user=phone parameter.
> Well, agree except for the "globally routable" part.  It's routable.
> but it may not be globally routable.
>
> Today, some phones with this capability do add user=phone.  Some don't.
>>
>> Other phones do NOT know how to do this translation and just paste the
>> collected digits into the user-part of a request and add user=phone.
> Right.  Most of the phones I know that send dial strings add 
> user=phone.
> Can't claim that they all do.
>
>>
>> A routing proxy, receiving a request, applies different routing and
>> transformation logic to a request having user=phone than it does to a
>> request not having that parameter. This may result in
>> identical outputs
>> for requests with/without user=phone, or it may result in divergent
>> outputs.
> Well, this is the problem the thread started with.  Agree that this is
> where we are, and it's not good.
>
>>
>> Conclusion:
>>
>> I believe that in this usage, the presence of user=phone in a request
>> indicates something about the ORIGINATOR of the request (this request
>> came from a stupid phone) and not something about the TARGET of the
>> request (this request is meant to go to the PSTN).
> Quibble with wording, but agree that the originator adds user=phone 
> under
> some circumstances, and targets generally don't care.
>
>>
>> I think this distinction (Exactly WHO is a "phone" when the
>> request says
>> user=phone) is at the heart of the discussion we're having.

yes.  I believe that user=phone  should mean that the USERpart = a 
PHONEnumber

>> And I don't
>> believe your usage is at all consistent with what I've heard from many
>> other people on this list, who believe that "user=phone" is a property
>> of the request's TARGET, not a property of the request's ORIGINATOR.
> I don't see that everyone else has that point of view, but I think you
> have done a good job of explaining why the destination is not
> interested in user=phone.  An intermediate proxy might be, but today,
> it's problematic.

If I sent to a gateway:  INVITE sip:+14085551212@east.gw.net;user=phone

and the gateway knew how to transform a global-number into whatever 
form was expected on its PSTN interface, then the user=phone is a 
property used by the TARGET.  the target could be a proxy, if the host 
part of the request URI corresponds to a domain for which that server 
is authoritative.

>> Admittedly, when viewed this way, it makes more sense than some
>> suggestions. Note that modes 1 and 2 above break things, and mode 3
>> isn't particularly useful.

I think mode 3 is actually very useful as a convention.

thanks,
-rohan

>> I'm still not sure where this leaves us, but am beginning to hope that
>> we understand the underlying confusion.


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Wed Oct  1 16:29:35 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02940
	for <sip-archive@odin.ietf.org>; Wed, 1 Oct 2003 16:29:35 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4nax-0000NI-Od
	for sip-archive@odin.ietf.org; Wed, 01 Oct 2003 16:29:12 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h91KTBBE001383
	for sip-archive@odin.ietf.org; Wed, 1 Oct 2003 16:29:11 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4nao-0000Lk-61; Wed, 01 Oct 2003 16:29:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4naF-0000LO-JC
	for sip@optimus.ietf.org; Wed, 01 Oct 2003 16:28:27 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02915
	for <sip@ietf.org>; Wed, 1 Oct 2003 16:28:20 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4naD-0004nK-00
	for sip@ietf.org; Wed, 01 Oct 2003 16:28:25 -0400
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4naD-0004mO-00
	for sip@ietf.org; Wed, 01 Oct 2003 16:28:25 -0400
Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h91KRrJs000807;
	Wed, 1 Oct 2003 13:27:53 -0700 (PDT)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AMC57991;
	Wed, 1 Oct 2003 13:24:51 -0700 (PDT)
Date: Wed, 1 Oct 2003 13:31:58 -0700
Subject: Re: [Sip] SIPIT Interop problem with ;user=phone
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: "'Paul Kyzivat'" <pkyzivat@cisco.com>,
        "'Dean Willis'" <dean.willis@softarmor.com>,
        "'Stastny Richard'" <Richard.Stastny@oefeg.at>,
        Francois Audet <audet@nortelnetworks.com>,
        Bob Penfield <bpenfield@acmepacket.com>, sip@ietf.org
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
From: Rohan Mahy <rohan@cisco.com>
In-Reply-To: <313680C9A886D511A06000204840E1CF070B5F30@whq-msgusr-02.pit.comms.marconi.com>
Message-Id: <4E519763-F44E-11D7-8F68-0003938AF740@cisco.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
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 Wednesday, October 1, 2003, at 01:00 PM, Rosen, Brian wrote:

> I was responding to this post, which doesn't discuss that aspect.
>
> I think I have responded to the "differentiate by context" idea.
> It requires that there be a way to differentiate configuration;
> you have to know which devices translate, and which don't and get
> them the correct context.  I think that is hard,

Brian,

Your earlier proposal is equivalently "difficult".  You have to 
configure devices which translate to insert one string, and devices 
which do not translate to insert another.  The only difference is the 
strings.

thanks,
-rohan

> and it's
> unnecessary that it be that hard.  Usually, all the devices in
> a domain are in the same context.
>
> It means that every proxy in a path that routes has to know
> both contexts so that it can figure out what it has.
>
> I would much rather explicitly label the uri with what it
> contains.
>
> Having said that, if we write a BCP that explains how this works,
> I can live with it.  I'm volunteered to do some writing, so this
> could be a part of it.
>
> Brian
>
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
>> Sent: Wednesday, October 01, 2003 3:36 PM
>> To: Rosen, Brian
>> Cc: 'Dean Willis'; 'Stastny Richard'; Rohan Mahy; Francois Audet; Bob
>> Penfield; sip@ietf.org
>> Subject: Re: [Sip] SIPIT Interop problem with ;user=phone
>>
>>
>> Rosen, Brian wrote:
>>>
>>> No, my point was that if I have one phone that sends a dial string,
>>> and another phone that sends a phone number, at some point, someone
>>> has to know that they are interpreted differently.
>>
>> Brian,
>>
>> You keep bringing up the same issues, but you haven't responded to
>> earlier proposals that address your concerns. Specifically,
>> how does the
>> following not meet your needs?
>>
>> - one phone-context to represent a dial string
>> - a different phone-context to represent a (local) phone number.
>>
>> As best I can tell, this should meet your needs, even if it
>> isn't in the
>> form you would prefer.
>>
>> Proxies that translate a dial string into a phone number also
>> make the
>> appropriate change to the the phone-context. Anybody that
>> receives such
>> a thing and doesn't understand the context can either pass it on to
>> somebody else that might, or can simply fail.
>>
>> BTW, I agree that the presence or absence of gateways doesn't change
>> this problem at all.
>>
>> 	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 exim@www1.ietf.org  Wed Oct  1 16:41:30 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03742
	for <sip-archive@odin.ietf.org>; Wed, 1 Oct 2003 16:41:30 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4nmU-0001PK-JC
	for sip-archive@odin.ietf.org; Wed, 01 Oct 2003 16:41:07 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h91Kf62x005407
	for sip-archive@odin.ietf.org; Wed, 1 Oct 2003 16:41:06 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4nmQ-0001Oe-FQ; Wed, 01 Oct 2003 16:41:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4nlU-0001MO-5R
	for sip@optimus.ietf.org; Wed, 01 Oct 2003 16:40:04 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03685
	for <sip@ietf.org>; Wed, 1 Oct 2003 16:39:56 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4nlS-00054k-00
	for sip@ietf.org; Wed, 01 Oct 2003 16:40:02 -0400
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4nlR-00054H-00
	for sip@ietf.org; Wed, 01 Oct 2003 16:40:01 -0400
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 QAA20293;
	Wed, 1 Oct 2003 16:39:29 -0400 (EDT)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA25018;
	Wed, 1 Oct 2003 16:39:31 -0400 (EDT)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19)
	id <S6M3X209>; Wed, 1 Oct 2003 16:39:30 -0400
Message-ID: <313680C9A886D511A06000204840E1CF070B5F34@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Rohan Mahy'" <rohan@cisco.com>
Cc: "'Paul Kyzivat'" <pkyzivat@cisco.com>,
        "'Dean Willis'"
	 <dean.willis@softarmor.com>,
        "'Stastny Richard'"
	 <Richard.Stastny@oefeg.at>,
        Francois Audet <audet@nortelnetworks.com>,
        Bob Penfield <bpenfield@acmepacket.com>, sip@ietf.org
Subject: RE: [Sip] SIPIT Interop problem with ;user=phone
Date: Wed, 1 Oct 2003 16:39:30 -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>

Suppose we defined a new parameter value, user=phonenumber
and user=dialstring.

A phone that knew how to translate would specify user=phonenumber.
A phone that did not know how to translate would specify user=dialstring.

A proxy that translated might turn 
sip:1212@example.com;user=dialstring;phone=context=pbx.example.com
into
sip:+17005551212@example.com;user=phonenumber

No configuration required.

I'd prefer that we not overload user=phone instead of phonenumber, primarily
because nearly every device that actually sets user=phone really is sending
dialstrings.

Brian

> -----Original Message-----
> From: Rohan Mahy [mailto:rohan@cisco.com]
> Sent: Wednesday, October 01, 2003 4:32 PM
> To: Rosen, Brian
> Cc: 'Paul Kyzivat'; 'Dean Willis'; 'Stastny Richard'; Francois Audet;
> Bob Penfield; sip@ietf.org
> Subject: Re: [Sip] SIPIT Interop problem with ;user=phone
> 
> 
> 
> On Wednesday, October 1, 2003, at 01:00 PM, Rosen, Brian wrote:
> 
> > I was responding to this post, which doesn't discuss that aspect.
> >
> > I think I have responded to the "differentiate by context" idea.
> > It requires that there be a way to differentiate configuration;
> > you have to know which devices translate, and which don't and get
> > them the correct context.  I think that is hard,
> 
> Brian,
> 
> Your earlier proposal is equivalently "difficult".  You have to 
> configure devices which translate to insert one string, and devices 
> which do not translate to insert another.  The only difference is the 
> strings.
> 
> thanks,
> -rohan
> 
> > and it's
> > unnecessary that it be that hard.  Usually, all the devices in
> > a domain are in the same context.
> >
> > It means that every proxy in a path that routes has to know
> > both contexts so that it can figure out what it has.
> >
> > I would much rather explicitly label the uri with what it
> > contains.
> >
> > Having said that, if we write a BCP that explains how this works,
> > I can live with it.  I'm volunteered to do some writing, so this
> > could be a part of it.
> >
> > Brian
> >
> >> -----Original Message-----
> >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> >> Sent: Wednesday, October 01, 2003 3:36 PM
> >> To: Rosen, Brian
> >> Cc: 'Dean Willis'; 'Stastny Richard'; Rohan Mahy; Francois 
> Audet; Bob
> >> Penfield; sip@ietf.org
> >> Subject: Re: [Sip] SIPIT Interop problem with ;user=phone
> >>
> >>
> >> Rosen, Brian wrote:
> >>>
> >>> No, my point was that if I have one phone that sends a 
> dial string,
> >>> and another phone that sends a phone number, at some 
> point, someone
> >>> has to know that they are interpreted differently.
> >>
> >> Brian,
> >>
> >> You keep bringing up the same issues, but you haven't responded to
> >> earlier proposals that address your concerns. Specifically,
> >> how does the
> >> following not meet your needs?
> >>
> >> - one phone-context to represent a dial string
> >> - a different phone-context to represent a (local) phone number.
> >>
> >> As best I can tell, this should meet your needs, even if it
> >> isn't in the
> >> form you would prefer.
> >>
> >> Proxies that translate a dial string into a phone number also
> >> make the
> >> appropriate change to the the phone-context. Anybody that
> >> receives such
> >> a thing and doesn't understand the context can either pass it on to
> >> somebody else that might, or can simply fail.
> >>
> >> BTW, I agree that the presence or absence of gateways 
> doesn't change
> >> this problem at all.
> >>
> >> 	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 exim@www1.ietf.org  Wed Oct  1 16:45:28 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03886
	for <sip-archive@odin.ietf.org>; Wed, 1 Oct 2003 16:45:28 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4nqL-0001jl-3x
	for sip-archive@odin.ietf.org; Wed, 01 Oct 2003 16:45:05 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h91Kj5or006651
	for sip-archive@odin.ietf.org; Wed, 1 Oct 2003 16:45:05 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4nqI-0001io-AL; Wed, 01 Oct 2003 16:45:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4npt-0001iE-22
	for sip@optimus.ietf.org; Wed, 01 Oct 2003 16:44:37 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03847
	for <sip@ietf.org>; Wed, 1 Oct 2003 16:44:29 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4npr-00059Y-00
	for sip@ietf.org; Wed, 01 Oct 2003 16:44:35 -0400
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4npq-00058u-00
	for sip@ietf.org; Wed, 01 Oct 2003 16:44:34 -0400
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 QAA20442;
	Wed, 1 Oct 2003 16:44:02 -0400 (EDT)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA25660;
	Wed, 1 Oct 2003 16:44:02 -0400 (EDT)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19)
	id <S6M3XJ1K>; Wed, 1 Oct 2003 16:44:01 -0400
Message-ID: <313680C9A886D511A06000204840E1CF070B5F35@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Rohan Mahy'" <rohan@cisco.com>
Cc: "'Dean Willis'" <dean.willis@softarmor.com>,
        "'Stastny Richard'"
	 <Richard.Stastny@oefeg.at>,
        Francois Audet <audet@nortelnetworks.com>,
        Paul Kyzivat <pkyzivat@cisco.com>,
        Bob Penfield
	 <bpenfield@acmepacket.com>, sip@ietf.org
Subject: RE: [Sip] SIPIT Interop problem with ;user=phone
Date: Wed, 1 Oct 2003 16:44: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>

edited for brevity

> >> 4) As a way to indicate that some prior device in the 
> processing chain
> >> has transformed the user-part of the request URI FROM a 
> dial-string to
> >> some sort of unique user-part so that it can be used in 
> routing. This
> >> might be better addressed by a "history" sort of operation.
> > Agree this could be a use of user=phone, and I agree it may 
> not be the
> > best use.  I think we need a way to know if this is a phone 
> number or
> > a dial string.
> 
> I still don't get what you are on about here.  How does a 
> HUMAN know if 
> something is a phone number or a dial string?  they don't.  likewise, 
> as long as we are leaving out wait and pause, you can represent all 
> dial strings as a local-number in the ABNF of a tel URL. If 
> you want to 
> make a distinction here, why not just make one using phone-context?
Well, actually, humans often do know the difference, but that doesn't
matter.  It's the phone, and succeeding proxies that care, not the user.
Generally, a user enters a dialstring.

I've responded to the different context as the way to differentiate
in another message.

...snip...

> >> I think this distinction (Exactly WHO is a "phone" when the
> >> request says
> >> user=phone) is at the heart of the discussion we're having.
> 
> yes.  I believe that user=phone  should mean that the USERpart = a 
> PHONEnumber

Carefull.  That means it isn't a dial string :)

Brian


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Wed Oct  1 17:10:38 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04896
	for <sip-archive@odin.ietf.org>; Wed, 1 Oct 2003 17:10:38 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4oEh-0003es-P1
	for sip-archive@odin.ietf.org; Wed, 01 Oct 2003 17:10:16 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h91LAF0e014051
	for sip-archive@odin.ietf.org; Wed, 1 Oct 2003 17:10:15 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4oEV-0003cD-7E; Wed, 01 Oct 2003 17:10:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4oDY-0003Vl-UA
	for sip@optimus.ietf.org; Wed, 01 Oct 2003 17:09:05 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04806
	for <sip@ietf.org>; Wed, 1 Oct 2003 17:08:57 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4oDW-0005Rj-00
	for sip@ietf.org; Wed, 01 Oct 2003 17:09:02 -0400
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4oDW-0005RQ-00
	for sip@ietf.org; Wed, 01 Oct 2003 17:09:02 -0400
Received: from cisco.com (171.71.177.238)
  by sj-iport-3.cisco.com with ESMTP; 01 Oct 2003 14:13:50 -0700
Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h91L8TXg002440;
	Wed, 1 Oct 2003 14:08:30 -0700 (PDT)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AMC62988;
	Wed, 1 Oct 2003 14:05:25 -0700 (PDT)
Date: Wed, 1 Oct 2003 14:12:32 -0700
Subject: Re: [Sip] SIPIT Interop problem with ;user=phone
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: "'Paul Kyzivat'" <pkyzivat@cisco.com>,
        "'Dean Willis'" <dean.willis@softarmor.com>,
        "'Stastny Richard'" <Richard.Stastny@oefeg.at>,
        Francois Audet <audet@nortelnetworks.com>,
        Bob Penfield <bpenfield@acmepacket.com>, sip@ietf.org
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
From: Rohan Mahy <rohan@cisco.com>
In-Reply-To: <313680C9A886D511A06000204840E1CF070B5F34@whq-msgusr-02.pit.comms.marconi.com>
Message-Id: <F8C02736-F453-11D7-8F68-0003938AF740@cisco.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
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 Wednesday, October 1, 2003, at 01:39 PM, Rosen, Brian wrote:

> Suppose we defined a new parameter value, user=phonenumber
> and user=dialstring.
>
> A phone that knew how to translate would specify user=phonenumber.
> A phone that did not know how to translate would specify 
> user=dialstring.

a phone that knew how to translate would specify 
;phone-context=phonenumber.mydomain.com, or just send a SIP URI
a phone that did not would specify ;phone-context=noclue.mydomain.com

same amount of configuration.


> A proxy that translated might turn
> sip:1212@example.com;user=dialstring;phone=context=pbx.example.com
> into
> sip:+17005551212@example.com;user=phonenumber
>
> No configuration required.

likewise with my proposal.  also note that if a proxy handles phones 
with different dial plans, it can disambiguate the same phone number or 
dial string with my approach, but cannot with yours.  I think this is a 
very compelling motivation for my proposal.

> I'd prefer that we not overload user=phone instead of phonenumber, 
> primarily
> because nearly every device that actually sets user=phone really is 
> sending
> dialstrings.

if user=phone means "tel URI embedded in userpart" then there is no 
semantic or syntactic ambiguity.  everything just works.

thanks,
-rohan

> Brian
>
>> -----Original Message-----
>> From: Rohan Mahy [mailto:rohan@cisco.com]
>> Sent: Wednesday, October 01, 2003 4:32 PM
>> To: Rosen, Brian
>> Cc: 'Paul Kyzivat'; 'Dean Willis'; 'Stastny Richard'; Francois Audet;
>> Bob Penfield; sip@ietf.org
>> Subject: Re: [Sip] SIPIT Interop problem with ;user=phone
>>
>>
>>
>> On Wednesday, October 1, 2003, at 01:00 PM, Rosen, Brian wrote:
>>
>>> I was responding to this post, which doesn't discuss that aspect.
>>>
>>> I think I have responded to the "differentiate by context" idea.
>>> It requires that there be a way to differentiate configuration;
>>> you have to know which devices translate, and which don't and get
>>> them the correct context.  I think that is hard,
>>
>> Brian,
>>
>> Your earlier proposal is equivalently "difficult".  You have to
>> configure devices which translate to insert one string, and devices
>> which do not translate to insert another.  The only difference is the
>> strings.
>>
>> thanks,
>> -rohan
>>
>>> and it's
>>> unnecessary that it be that hard.  Usually, all the devices in
>>> a domain are in the same context.
>>>
>>> It means that every proxy in a path that routes has to know
>>> both contexts so that it can figure out what it has.
>>>
>>> I would much rather explicitly label the uri with what it
>>> contains.
>>>
>>> Having said that, if we write a BCP that explains how this works,
>>> I can live with it.  I'm volunteered to do some writing, so this
>>> could be a part of it.
>>>
>>> Brian
>>>
>>>> -----Original Message-----
>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
>>>> Sent: Wednesday, October 01, 2003 3:36 PM
>>>> To: Rosen, Brian
>>>> Cc: 'Dean Willis'; 'Stastny Richard'; Rohan Mahy; Francois
>> Audet; Bob
>>>> Penfield; sip@ietf.org
>>>> Subject: Re: [Sip] SIPIT Interop problem with ;user=phone
>>>>
>>>>
>>>> Rosen, Brian wrote:
>>>>>
>>>>> No, my point was that if I have one phone that sends a
>> dial string,
>>>>> and another phone that sends a phone number, at some
>> point, someone
>>>>> has to know that they are interpreted differently.
>>>>
>>>> Brian,
>>>>
>>>> You keep bringing up the same issues, but you haven't responded to
>>>> earlier proposals that address your concerns. Specifically,
>>>> how does the
>>>> following not meet your needs?
>>>>
>>>> - one phone-context to represent a dial string
>>>> - a different phone-context to represent a (local) phone number.
>>>>
>>>> As best I can tell, this should meet your needs, even if it
>>>> isn't in the
>>>> form you would prefer.
>>>>
>>>> Proxies that translate a dial string into a phone number also
>>>> make the
>>>> appropriate change to the the phone-context. Anybody that
>>>> receives such
>>>> a thing and doesn't understand the context can either pass it on to
>>>> somebody else that might, or can simply fail.
>>>>
>>>> BTW, I agree that the presence or absence of gateways
>> doesn't change
>>>> this problem at all.
>>>>
>>>> 	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 exim@www1.ietf.org  Wed Oct  1 17:13:27 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05013
	for <sip-archive@odin.ietf.org>; Wed, 1 Oct 2003 17:13:27 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4oHQ-00042T-Sq
	for sip-archive@odin.ietf.org; Wed, 01 Oct 2003 17:13:04 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h91LD4QJ015494
	for sip-archive@odin.ietf.org; Wed, 1 Oct 2003 17:13:04 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4oHO-00041N-2M; Wed, 01 Oct 2003 17:13:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4oGs-0003xj-RX
	for sip@optimus.ietf.org; Wed, 01 Oct 2003 17:12:30 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04981
	for <sip@ietf.org>; Wed, 1 Oct 2003 17:12:22 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4oGq-0005VZ-00
	for sip@ietf.org; Wed, 01 Oct 2003 17:12:28 -0400
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4oGq-0005VB-00
	for sip@ietf.org; Wed, 01 Oct 2003 17:12:28 -0400
Received: from cisco.com (171.71.177.237)
  by sj-iport-3.cisco.com with ESMTP; 01 Oct 2003 14:17:16 -0700
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h91LBswn007783;
	Wed, 1 Oct 2003 14:11:55 -0700 (PDT)
Received: from cisco.com ([161.44.79.51])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ACV19715;
	Wed, 1 Oct 2003 17:11:53 -0400 (EDT)
Message-ID: <3F7B4319.7010002@cisco.com>
Date: Wed, 01 Oct 2003 17:11:53 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
CC: "'Rohan Mahy'" <rohan@cisco.com>,
        "'Dean Willis'" <dean.willis@softarmor.com>,
        "'Stastny Richard'" <Richard.Stastny@oefeg.at>,
        Francois Audet <audet@nortelnetworks.com>,
        Bob Penfield <bpenfield@acmepacket.com>, sip@ietf.org
Subject: Re: [Sip] SIPIT Interop problem with ;user=phone
References: <313680C9A886D511A06000204840E1CF070B5F34@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: 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



Rosen, Brian wrote:
> Suppose we defined a new parameter value, user=phonenumber
> and user=dialstring.
> 
> A phone that knew how to translate would specify user=phonenumber.
> A phone that did not know how to translate would specify user=dialstring.
> 
> A proxy that translated might turn 
> sip:1212@example.com;user=dialstring;phone=context=pbx.example.com
> into
> sip:+17005551212@example.com;user=phonenumber
> 
> No configuration required.

First, a small error in above:
   sip:1212@example.com;user=dialstring;phone=context=pbx.example.com 
should be
   sip:1212;phone=context=pbx.example.com@example.com;user=dialstring

But that is irrelevant to the discussion.

The above still requires the phone to be provisioned with two strings: a 
domain ("example.com") and a context ("pbx.example.com"). The only thing 
you are saving is that you can configure phones without regard to 
whether they translate or not.

We can get the same effect by always privisioning phones with three 
strings: domain, untranslated context, translated context. Then the 
phone can decide which context to use depending on its functionality.

	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 exim@www1.ietf.org  Wed Oct  1 17:19:33 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05276
	for <sip-archive@odin.ietf.org>; Wed, 1 Oct 2003 17:19:33 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4oNK-0004Xk-8A
	for sip-archive@odin.ietf.org; Wed, 01 Oct 2003 17:19:11 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h91LJAPt017461
	for sip-archive@odin.ietf.org; Wed, 1 Oct 2003 17:19:10 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4oNB-0004Ww-KM; Wed, 01 Oct 2003 17:19:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4oN5-0004Wg-2U
	for sip@optimus.ietf.org; Wed, 01 Oct 2003 17:18:55 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05246
	for <sip@ietf.org>; Wed, 1 Oct 2003 17:18:47 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4oN2-0005cO-00
	for sip@ietf.org; Wed, 01 Oct 2003 17:18:52 -0400
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4oN1-0005c3-00
	for sip@ietf.org; Wed, 01 Oct 2003 17:18:52 -0400
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 RAA21381;
	Wed, 1 Oct 2003 17:18:19 -0400 (EDT)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA00577;
	Wed, 1 Oct 2003 17:18:21 -0400 (EDT)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19)
	id <S6M3XKF2>; Wed, 1 Oct 2003 17:18:20 -0400
Message-ID: <313680C9A886D511A06000204840E1CF070B5F3A@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Rohan Mahy'" <rohan@cisco.com>
Cc: "'Paul Kyzivat'" <pkyzivat@cisco.com>,
        "'Dean Willis'"
	 <dean.willis@softarmor.com>,
        "'Stastny Richard'"
	 <Richard.Stastny@oefeg.at>,
        Francois Audet <audet@nortelnetworks.com>,
        Bob Penfield <bpenfield@acmepacket.com>, sip@ietf.org
Subject: RE: [Sip] SIPIT Interop problem with ;user=phone
Date: Wed, 1 Oct 2003 17:18:19 -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>

We're not communicating.

If it's a defined parameter, there is no configuration other than
the single local context.  The user=phonenumber or user=dialstring
is fixed, not configured (well, it could be configured for a phone
that could translate, but could be set to not translate I suppose,
but the point is that all phones would be configured the same way).

If it's differentiated by context, then the configuration is dependent
on whether a phone translates or not.  There are two local contexts,
and the phone has to be configured differently depending on what kind
of device it is.  This is possible, but unecessarily difficult.

Are you proposing a BCP convention on the use of "phonenumber" and
"noclue"?  

Brian


> -----Original Message-----
> From: Rohan Mahy [mailto:rohan@cisco.com]
> Sent: Wednesday, October 01, 2003 5:13 PM
> To: Rosen, Brian
> Cc: 'Paul Kyzivat'; 'Dean Willis'; 'Stastny Richard'; Francois Audet;
> Bob Penfield; sip@ietf.org
> Subject: Re: [Sip] SIPIT Interop problem with ;user=phone
> 
> 
> 
> On Wednesday, October 1, 2003, at 01:39 PM, Rosen, Brian wrote:
> 
> > Suppose we defined a new parameter value, user=phonenumber
> > and user=dialstring.
> >
> > A phone that knew how to translate would specify user=phonenumber.
> > A phone that did not know how to translate would specify 
> > user=dialstring.
> 
> a phone that knew how to translate would specify 
> ;phone-context=phonenumber.mydomain.com, or just send a SIP URI
> a phone that did not would specify ;phone-context=noclue.mydomain.com
> 
> same amount of configuration.
> 
> 
> > A proxy that translated might turn
> > sip:1212@example.com;user=dialstring;phone=context=pbx.example.com
> > into
> > sip:+17005551212@example.com;user=phonenumber
> >
> > No configuration required.
> 
> likewise with my proposal.  also note that if a proxy handles phones 
> with different dial plans, it can disambiguate the same phone 
> number or 
> dial string with my approach, but cannot with yours.  I think 
> this is a 
> very compelling motivation for my proposal.
> 
> > I'd prefer that we not overload user=phone instead of phonenumber, 
> > primarily
> > because nearly every device that actually sets user=phone really is 
> > sending
> > dialstrings.
> 
> if user=phone means "tel URI embedded in userpart" then there is no 
> semantic or syntactic ambiguity.  everything just works.
> 
> thanks,
> -rohan
> 
> > Brian
> >
> >> -----Original Message-----
> >> From: Rohan Mahy [mailto:rohan@cisco.com]
> >> Sent: Wednesday, October 01, 2003 4:32 PM
> >> To: Rosen, Brian
> >> Cc: 'Paul Kyzivat'; 'Dean Willis'; 'Stastny Richard'; 
> Francois Audet;
> >> Bob Penfield; sip@ietf.org
> >> Subject: Re: [Sip] SIPIT Interop problem with ;user=phone
> >>
> >>
> >>
> >> On Wednesday, October 1, 2003, at 01:00 PM, Rosen, Brian wrote:
> >>
> >>> I was responding to this post, which doesn't discuss that aspect.
> >>>
> >>> I think I have responded to the "differentiate by context" idea.
> >>> It requires that there be a way to differentiate configuration;
> >>> you have to know which devices translate, and which don't and get
> >>> them the correct context.  I think that is hard,
> >>
> >> Brian,
> >>
> >> Your earlier proposal is equivalently "difficult".  You have to
> >> configure devices which translate to insert one string, and devices
> >> which do not translate to insert another.  The only 
> difference is the
> >> strings.
> >>
> >> thanks,
> >> -rohan
> >>
> >>> and it's
> >>> unnecessary that it be that hard.  Usually, all the devices in
> >>> a domain are in the same context.
> >>>
> >>> It means that every proxy in a path that routes has to know
> >>> both contexts so that it can figure out what it has.
> >>>
> >>> I would much rather explicitly label the uri with what it
> >>> contains.
> >>>
> >>> Having said that, if we write a BCP that explains how this works,
> >>> I can live with it.  I'm volunteered to do some writing, so this
> >>> could be a part of it.
> >>>
> >>> Brian
> >>>
> >>>> -----Original Message-----
> >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> >>>> Sent: Wednesday, October 01, 2003 3:36 PM
> >>>> To: Rosen, Brian
> >>>> Cc: 'Dean Willis'; 'Stastny Richard'; Rohan Mahy; Francois
> >> Audet; Bob
> >>>> Penfield; sip@ietf.org
> >>>> Subject: Re: [Sip] SIPIT Interop problem with ;user=phone
> >>>>
> >>>>
> >>>> Rosen, Brian wrote:
> >>>>>
> >>>>> No, my point was that if I have one phone that sends a
> >> dial string,
> >>>>> and another phone that sends a phone number, at some
> >> point, someone
> >>>>> has to know that they are interpreted differently.
> >>>>
> >>>> Brian,
> >>>>
> >>>> You keep bringing up the same issues, but you haven't 
> responded to
> >>>> earlier proposals that address your concerns. Specifically,
> >>>> how does the
> >>>> following not meet your needs?
> >>>>
> >>>> - one phone-context to represent a dial string
> >>>> - a different phone-context to represent a (local) phone number.
> >>>>
> >>>> As best I can tell, this should meet your needs, even if it
> >>>> isn't in the
> >>>> form you would prefer.
> >>>>
> >>>> Proxies that translate a dial string into a phone number also
> >>>> make the
> >>>> appropriate change to the the phone-context. Anybody that
> >>>> receives such
> >>>> a thing and doesn't understand the context can either 
> pass it on to
> >>>> somebody else that might, or can simply fail.
> >>>>
> >>>> BTW, I agree that the presence or absence of gateways
> >> doesn't change
> >>>> this problem at all.
> >>>>
> >>>> 	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 exim@www1.ietf.org  Wed Oct  1 17:25:43 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05514
	for <sip-archive@odin.ietf.org>; Wed, 1 Oct 2003 17:25:43 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4oTH-0005BA-Kh
	for sip-archive@odin.ietf.org; Wed, 01 Oct 2003 17:25:21 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h91LPJvI019850
	for sip-archive@odin.ietf.org; Wed, 1 Oct 2003 17:25:19 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4oT1-000561-BG; Wed, 01 Oct 2003 17:25:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4oSP-00055S-7V
	for sip@optimus.ietf.org; Wed, 01 Oct 2003 17:24:25 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05464
	for <sip@ietf.org>; Wed, 1 Oct 2003 17:24:17 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4oSM-0005gp-00
	for sip@ietf.org; Wed, 01 Oct 2003 17:24:22 -0400
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4oSM-0005gb-00
	for sip@ietf.org; Wed, 01 Oct 2003 17:24:22 -0400
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 RAA21484;
	Wed, 1 Oct 2003 17:23:50 -0400 (EDT)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA01474;
	Wed, 1 Oct 2003 17:23:52 -0400 (EDT)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19)
	id <S6M3XKL4>; Wed, 1 Oct 2003 17:23:51 -0400
Message-ID: <313680C9A886D511A06000204840E1CF070B5F3B@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Paul Kyzivat'" <pkyzivat@cisco.com>
Cc: "'Rohan Mahy'" <rohan@cisco.com>,
        "'Dean Willis'"
	 <dean.willis@softarmor.com>,
        "'Stastny Richard'"
	 <Richard.Stastny@oefeg.at>,
        Francois Audet <audet@nortelnetworks.com>,
        Bob Penfield <bpenfield@acmepacket.com>, sip@ietf.org
Subject: RE: [Sip] SIPIT Interop problem with ;user=phone
Date: Wed, 1 Oct 2003 17:23:50 -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 can deal with having three string provisioning, although
I think my solution is a whole lot cleaner. 

I think you have to have the phone context different from the
local domain.  You can't collapse to one, although you could
default under some circumstances with some BCP work, to one.
That might be worth doing, but it doesn't change too much.
There are lots of cases of both multiple sip domains with the same
phone context and one sip domain with multiple phone contexts.

Brian

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Wednesday, October 01, 2003 5:12 PM
> To: Rosen, Brian
> Cc: 'Rohan Mahy'; 'Dean Willis'; 'Stastny Richard'; Francois 
> Audet; Bob
> Penfield; sip@ietf.org
> Subject: Re: [Sip] SIPIT Interop problem with ;user=phone
> 
> 
> 
> 
> Rosen, Brian wrote:
> > Suppose we defined a new parameter value, user=phonenumber
> > and user=dialstring.
> > 
> > A phone that knew how to translate would specify user=phonenumber.
> > A phone that did not know how to translate would specify 
> user=dialstring.
> > 
> > A proxy that translated might turn 
> > sip:1212@example.com;user=dialstring;phone=context=pbx.example.com
> > into
> > sip:+17005551212@example.com;user=phonenumber
> > 
> > No configuration required.
> 
> First, a small error in above:
>    sip:1212@example.com;user=dialstring;phone=context=pbx.example.com 
> should be
>    sip:1212;phone=context=pbx.example.com@example.com;user=dialstring
> 
> But that is irrelevant to the discussion.
> 
> The above still requires the phone to be provisioned with two 
> strings: a 
> domain ("example.com") and a context ("pbx.example.com"). The 
> only thing 
> you are saving is that you can configure phones without regard to 
> whether they translate or not.
> 
> We can get the same effect by always privisioning phones with three 
> strings: domain, untranslated context, translated context. Then the 
> phone can decide which context to use depending on its functionality.
> 
> 	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 exim@www1.ietf.org  Wed Oct  1 17:43:36 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05960
	for <sip-archive@odin.ietf.org>; Wed, 1 Oct 2003 17:43:36 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4oka-00064r-DI
	for sip-archive@odin.ietf.org; Wed, 01 Oct 2003 17:43:14 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h91LhC6W023304
	for sip-archive@odin.ietf.org; Wed, 1 Oct 2003 17:43:12 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4okP-00062v-FN; Wed, 01 Oct 2003 17:43:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4ojr-00060v-Mv
	for sip@optimus.ietf.org; Wed, 01 Oct 2003 17:42:28 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05917
	for <sip@ietf.org>; Wed, 1 Oct 2003 17:42:19 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4ojl-0005s9-00
	for sip@ietf.org; Wed, 01 Oct 2003 17:42:21 -0400
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4ojj-0005s2-00
	for sip@ietf.org; Wed, 01 Oct 2003 17:42:19 -0400
Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h91Lflwn004828;
	Wed, 1 Oct 2003 14:41:48 -0700 (PDT)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AMC67318;
	Wed, 1 Oct 2003 14:38:45 -0700 (PDT)
Date: Wed, 1 Oct 2003 14:45:53 -0700
Subject: Re: [Sip] SIPIT Interop problem with ;user=phone
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: "'Paul Kyzivat'" <pkyzivat@cisco.com>,
        "'Dean Willis'" <dean.willis@softarmor.com>,
        "'Stastny Richard'" <Richard.Stastny@oefeg.at>,
        Francois Audet <audet@nortelnetworks.com>,
        Bob Penfield <bpenfield@acmepacket.com>, sip@ietf.org
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
From: Rohan Mahy <rohan@cisco.com>
In-Reply-To: <313680C9A886D511A06000204840E1CF070B5F3A@whq-msgusr-02.pit.comms.marconi.com>
Message-Id: <A153B602-F458-11D7-8F68-0003938AF740@cisco.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
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 Wednesday, October 1, 2003, at 02:18 PM, Rosen, Brian wrote:

> We're not communicating.
> If it's a defined parameter, there is no configuration other than
> the single local context.  The user=phonenumber or user=dialstring
> is fixed, not configured (well, it could be configured for a phone
> that could translate, but could be set to not translate I suppose,
> but the point is that all phones would be configured the same way).

sure those are two fixed strings.  but you can accomplish the same 
thing by using a phone-context convention that reuses the domain name 
information that the phone already needs anyway and can get via DHCP.  
you don't need any new configuration for the string, but you have the 
option to add it.

> If it's differentiated by context, then the configuration is dependent
> on whether a phone translates or not.  There are two local contexts,
> and the phone has to be configured differently depending on what kind
> of device it is.

as Paul said, the phone can use the strings available to it (either by 
convention or configuration) and make up their own mind.

> This is possible, but unecessarily difficult.

I disagree.  Even if you have to configure the strings explicitly it is 
not a big deal and is something the phones should really know anyway.

> Are you proposing a BCP convention on the use of "phonenumber" and
> "noclue"?

no, but I would absolutely prefer it to adding a "user=dialstring" 
parameter.

thanks,
-rohan

> Brian
>
>
>> -----Original Message-----
>> From: Rohan Mahy [mailto:rohan@cisco.com]
>> Sent: Wednesday, October 01, 2003 5:13 PM
>> To: Rosen, Brian
>> Cc: 'Paul Kyzivat'; 'Dean Willis'; 'Stastny Richard'; Francois Audet;
>> Bob Penfield; sip@ietf.org
>> Subject: Re: [Sip] SIPIT Interop problem with ;user=phone
>>
>>
>>
>> On Wednesday, October 1, 2003, at 01:39 PM, Rosen, Brian wrote:
>>
>>> Suppose we defined a new parameter value, user=phonenumber
>>> and user=dialstring.
>>>
>>> A phone that knew how to translate would specify user=phonenumber.
>>> A phone that did not know how to translate would specify
>>> user=dialstring.
>>
>> a phone that knew how to translate would specify
>> ;phone-context=phonenumber.mydomain.com, or just send a SIP URI
>> a phone that did not would specify ;phone-context=noclue.mydomain.com
>>
>> same amount of configuration.
>>
>>
>>> A proxy that translated might turn
>>> sip:1212@example.com;user=dialstring;phone=context=pbx.example.com
>>> into
>>> sip:+17005551212@example.com;user=phonenumber
>>>
>>> No configuration required.
>>
>> likewise with my proposal.  also note that if a proxy handles phones
>> with different dial plans, it can disambiguate the same phone
>> number or
>> dial string with my approach, but cannot with yours.  I think
>> this is a
>> very compelling motivation for my proposal.
>>
>>> I'd prefer that we not overload user=phone instead of phonenumber,
>>> primarily
>>> because nearly every device that actually sets user=phone really is
>>> sending
>>> dialstrings.
>>
>> if user=phone means "tel URI embedded in userpart" then there is no
>> semantic or syntactic ambiguity.  everything just works.
>>
>> thanks,
>> -rohan
>>
>>> Brian
>>>
>>>> -----Original Message-----
>>>> From: Rohan Mahy [mailto:rohan@cisco.com]
>>>> Sent: Wednesday, October 01, 2003 4:32 PM
>>>> To: Rosen, Brian
>>>> Cc: 'Paul Kyzivat'; 'Dean Willis'; 'Stastny Richard';
>> Francois Audet;
>>>> Bob Penfield; sip@ietf.org
>>>> Subject: Re: [Sip] SIPIT Interop problem with ;user=phone
>>>>
>>>>
>>>>
>>>> On Wednesday, October 1, 2003, at 01:00 PM, Rosen, Brian wrote:
>>>>
>>>>> I was responding to this post, which doesn't discuss that aspect.
>>>>>
>>>>> I think I have responded to the "differentiate by context" idea.
>>>>> It requires that there be a way to differentiate configuration;
>>>>> you have to know which devices translate, and which don't and get
>>>>> them the correct context.  I think that is hard,
>>>>
>>>> Brian,
>>>>
>>>> Your earlier proposal is equivalently "difficult".  You have to
>>>> configure devices which translate to insert one string, and devices
>>>> which do not translate to insert another.  The only
>> difference is the
>>>> strings.
>>>>
>>>> thanks,
>>>> -rohan
>>>>
>>>>> and it's
>>>>> unnecessary that it be that hard.  Usually, all the devices in
>>>>> a domain are in the same context.
>>>>>
>>>>> It means that every proxy in a path that routes has to know
>>>>> both contexts so that it can figure out what it has.
>>>>>
>>>>> I would much rather explicitly label the uri with what it
>>>>> contains.
>>>>>
>>>>> Having said that, if we write a BCP that explains how this works,
>>>>> I can live with it.  I'm volunteered to do some writing, so this
>>>>> could be a part of it.
>>>>>
>>>>> Brian
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
>>>>>> Sent: Wednesday, October 01, 2003 3:36 PM
>>>>>> To: Rosen, Brian
>>>>>> Cc: 'Dean Willis'; 'Stastny Richard'; Rohan Mahy; Francois
>>>> Audet; Bob
>>>>>> Penfield; sip@ietf.org
>>>>>> Subject: Re: [Sip] SIPIT Interop problem with ;user=phone
>>>>>>
>>>>>>
>>>>>> Rosen, Brian wrote:
>>>>>>>
>>>>>>> No, my point was that if I have one phone that sends a
>>>> dial string,
>>>>>>> and another phone that sends a phone number, at some
>>>> point, someone
>>>>>>> has to know that they are interpreted differently.
>>>>>>
>>>>>> Brian,
>>>>>>
>>>>>> You keep bringing up the same issues, but you haven't
>> responded to
>>>>>> earlier proposals that address your concerns. Specifically,
>>>>>> how does the
>>>>>> following not meet your needs?
>>>>>>
>>>>>> - one phone-context to represent a dial string
>>>>>> - a different phone-context to represent a (local) phone number.
>>>>>>
>>>>>> As best I can tell, this should meet your needs, even if it
>>>>>> isn't in the
>>>>>> form you would prefer.
>>>>>>
>>>>>> Proxies that translate a dial string into a phone number also
>>>>>> make the
>>>>>> appropriate change to the the phone-context. Anybody that
>>>>>> receives such
>>>>>> a thing and doesn't understand the context can either
>> pass it on to
>>>>>> somebody else that might, or can simply fail.
>>>>>>
>>>>>> BTW, I agree that the presence or absence of gateways
>>>> doesn't change
>>>>>> this problem at all.
>>>>>>
>>>>>> 	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


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Wed Oct  1 18:19:42 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08111
	for <sip-archive@odin.ietf.org>; Wed, 1 Oct 2003 18:19:42 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4pJY-00088N-27
	for sip-archive@odin.ietf.org; Wed, 01 Oct 2003 18:19:20 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h91MJK4m031210
	for sip-archive@odin.ietf.org; Wed, 1 Oct 2003 18:19:20 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4pJH-00086a-M8; Wed, 01 Oct 2003 18:19:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4pIz-00086I-Aa
	for sip@optimus.ietf.org; Wed, 01 Oct 2003 18:18:45 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08082
	for <sip@ietf.org>; Wed, 1 Oct 2003 18:18:36 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4pIu-0006Hy-00
	for sip@ietf.org; Wed, 01 Oct 2003 18:18:41 -0400
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4pIu-0006Hn-00
	for sip@ietf.org; Wed, 01 Oct 2003 18:18:40 -0400
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 SAA23092;
	Wed, 1 Oct 2003 18:18:07 -0400 (EDT)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA08740;
	Wed, 1 Oct 2003 18:18:08 -0400 (EDT)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19)
	id <S6M3XLTT>; Wed, 1 Oct 2003 18:18:07 -0400
Message-ID: <313680C9A886D511A06000204840E1CF070B5F3D@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Rohan Mahy'" <rohan@cisco.com>
Cc: "'Paul Kyzivat'" <pkyzivat@cisco.com>,
        "'Dean Willis'"
	 <dean.willis@softarmor.com>,
        "'Stastny Richard'"
	 <Richard.Stastny@oefeg.at>,
        Francois Audet <audet@nortelnetworks.com>,
        Bob Penfield <bpenfield@acmepacket.com>, sip@ietf.org
Subject: RE: [Sip] SIPIT Interop problem with ;user=phone
Date: Wed, 1 Oct 2003 18:18:07 -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>

> > Are you proposing a BCP convention on the use of "phonenumber" and
> > "noclue"?
> 
> no, but I would absolutely prefer it to adding a "user=dialstring" 
> parameter.
> 
Why?  This whole thing is just weird to me.  Either I've convinced you,
or you already understood that differentiating is useful.

Why is it that you don't see the value to explicitly label what the
userpart is?  Why is a hack better?  There really is only one context,
there really are two representations.  Faking it with two contexts
works, in the sense that you can differentiate, but it just doesn't
seem to be as good a solution.  Both need some work; we have at least
one RFC, maybe two in this.  Why is two contexts a better answer?

Let me be clear that I'll still accept two contexts as a compromise.

Brian

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Wed Oct  1 18:52:37 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09309
	for <sip-archive@odin.ietf.org>; Wed, 1 Oct 2003 18:52:37 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4ppO-0001jB-DH
	for sip-archive@odin.ietf.org; Wed, 01 Oct 2003 18:52:15 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h91MqE40006579
	for sip-archive@odin.ietf.org; Wed, 1 Oct 2003 18:52:14 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4ppC-0001hZ-4z; Wed, 01 Oct 2003 18:52:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4poZ-0001gr-At
	for sip@optimus.ietf.org; Wed, 01 Oct 2003 18:51:23 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09259
	for <sip@ietf.org>; Wed, 1 Oct 2003 18:51:14 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4poW-0006h5-00
	for sip@ietf.org; Wed, 01 Oct 2003 18:51:20 -0400
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4poV-0006gl-00
	for sip@ietf.org; Wed, 01 Oct 2003 18:51:19 -0400
Received: from cisco.com (64.102.124.12)
  by sj-iport-2.cisco.com with ESMTP; 01 Oct 2003 15:50:38 -0700
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h91Moj01023902;
	Wed, 1 Oct 2003 18:50:46 -0400 (EDT)
Received: from cisco.com ([161.44.79.51])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ACV26973;
	Wed, 1 Oct 2003 18:50:40 -0400 (EDT)
Message-ID: <3F7B5A40.6070403@cisco.com>
Date: Wed, 01 Oct 2003 18:50:40 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
CC: "'Rohan Mahy'" <rohan@cisco.com>,
        "'Dean Willis'" <dean.willis@softarmor.com>,
        "'Stastny Richard'" <Richard.Stastny@oefeg.at>,
        Francois Audet <audet@nortelnetworks.com>,
        Bob Penfield <bpenfield@acmepacket.com>, sip@ietf.org
Subject: Re: [Sip] SIPIT Interop problem with ;user=phone
References: <313680C9A886D511A06000204840E1CF070B5F3B@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: 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



Rosen, Brian wrote:

> I can deal with having three string provisioning,

Progress!!! :-)

 > although I think my solution is a whole lot cleaner.

Personally I think a solution that doesn't require any changes to the 
definition of the sip: url is cleaner than one that does.

I also find it cleaner because it works in both sip and tel urls.

> I think you have to have the phone context different from the
> local domain.   You can't collapse to one, although you could
> default under some circumstances with some BCP work, to one.

No argument here.

	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 exim@www1.ietf.org  Wed Oct  1 19:12:29 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10151
	for <sip-archive@odin.ietf.org>; Wed, 1 Oct 2003 19:12:29 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4q8c-0002rV-16
	for sip-archive@odin.ietf.org; Wed, 01 Oct 2003 19:12:06 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h91NC5fU010889
	for sip-archive@odin.ietf.org; Wed, 1 Oct 2003 19:12:05 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4q8W-0002mZ-D2; Wed, 01 Oct 2003 19:12:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4q89-0002lW-L1
	for sip@optimus.ietf.org; Wed, 01 Oct 2003 19:11:37 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10021
	for <sip@ietf.org>; Wed, 1 Oct 2003 19:11:28 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4q86-0006wN-00
	for sip@ietf.org; Wed, 01 Oct 2003 19:11:34 -0400
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4q84-0006w9-00
	for sip@ietf.org; Wed, 01 Oct 2003 19:11:32 -0400
Received: from cisco.com (171.71.177.238)
  by sj-iport-3.cisco.com with ESMTP; 01 Oct 2003 16:16:23 -0700
Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h91NB0Xg014062;
	Wed, 1 Oct 2003 16:11:00 -0700 (PDT)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AMC77582;
	Wed, 1 Oct 2003 16:08:01 -0700 (PDT)
Date: Wed, 1 Oct 2003 16:15:08 -0700
Subject: Re: [Sip] SIPIT Interop problem with ;user=phone
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: "'Paul Kyzivat'" <pkyzivat@cisco.com>,
        "'Dean Willis'" <dean.willis@softarmor.com>,
        "'Stastny Richard'" <Richard.Stastny@oefeg.at>,
        Francois Audet <audet@nortelnetworks.com>,
        Bob Penfield <bpenfield@acmepacket.com>, sip@ietf.org
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
From: Rohan Mahy <rohan@cisco.com>
In-Reply-To: <313680C9A886D511A06000204840E1CF070B5F3D@whq-msgusr-02.pit.comms.marconi.com>
Message-Id: <19A672C4-F465-11D7-8F68-0003938AF740@cisco.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
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 Wednesday, October 1, 2003, at 03:18 PM, Rosen, Brian wrote:
>>> Are you proposing a BCP convention on the use of "phonenumber" and
>>> "noclue"?
>>
>> no, but I would absolutely prefer it to adding a "user=dialstring"
>> parameter.
>>
> Why?  This whole thing is just weird to me.  Either I've convinced you,
> or you already understood that differentiating is useful.
>
> Why is it that you don't see the value to explicitly label what the
> userpart is?  Why is a hack better?  There really is only one context,
> there really are two representations.

First off, I consider your overall approach a monstrous hack.  I think 
it is ridiculous that folks allow untranslated digits strings in their 
network at all, but at least the phone-context solution quarantines 
them so they can be handled more safely.  I find this sheer laziness 
and very dangerous.  Even many telephone operators can't get this 
right. For example, I am currently on the phone with AT&T Wireless who 
has just changed something last week in their network so that there is 
no way that I can dial a US number with a 1 in front of it at home, but 
no way I can dial a US number without a 1 in front of it at work  (same 
company, same "network", not roaming in either place).  This would 
never happen if there was a standard way to convey full global numbers. 
  All of my devices in my network exchange full global phone numbers, or 
fully qualified SIP URIs.

In other words, if I were in charge of your dialing plan, all your 
"phone numbers" would be translated into either a global e164, or a SIP 
URI with user=ip in an appropriate domain (an AOR).  If you have a 
device that cannot be configured to process the digit map itself, you 
could have this device send its digits (you call them dial strings, I 
think they are just phone numbers in a particular context*) in a tel 
URI with an appropriate phone-context which is unique to that digit map.

You could have more than one digit map/dial plan for some of these dumb 
phones, in which case you would use multiple phone-contexts to sort 
this out.  Likewise, I don't need a phone-context for any of your 
"phone numbers" if these are real AORs, but if these were not unique in 
the domain of the SIP URI you placed them in (not AORs), then you could 
further disambiguate with phone-context.

Several times in this thread, I have given motivations for 
functionality you can get if you follow my proposal, such as one proxy 
handling multiple digit maps (for example in a multi-tenant situation). 
  You have not addressed these cases.  Nobody has provided any technical 
reason why my proposal doesn't work, and I have given many reasons why 
it works.  I will have an ID out in a few days which describes the 
motivations and detailed scenarios for my approach.  Until then, let's 
please pause this thread.

thanks,
-rohan

*To be clear, I think the definition of "dial string" intended by 
RFC2806 was a string of digits that included post-dial information such 
as pauses, waits, and access codes.  Such a dial string always 
*contains* a "phone number" which is the pre-dial portion.


> Faking it with two contexts
> works, in the sense that you can differentiate, but it just doesn't
> seem to be as good a solution.  Both need some work; we have at least
> one RFC, maybe two in this.  Why is two contexts a better answer?
>
> Let me be clear that I'll still accept two contexts as a compromise.
>
> Brian


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Thu Oct  2 05:38:48 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09208
	for <sip-archive@odin.ietf.org>; Thu, 2 Oct 2003 05:38:48 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4zuk-0002hj-NA
	for sip-archive@odin.ietf.org; Thu, 02 Oct 2003 05:38:27 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h929cP1F010304
	for sip-archive@odin.ietf.org; Thu, 2 Oct 2003 05:38:25 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4zuO-0002Vv-Dl; Thu, 02 Oct 2003 05:38:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4zu3-0002Sl-R0
	for sip@optimus.ietf.org; Thu, 02 Oct 2003 05:37:43 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09175
	for <sip@ietf.org>; Thu, 2 Oct 2003 05:37:33 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4zu0-0005IV-00
	for sip@ietf.org; Thu, 02 Oct 2003 05:37:40 -0400
Received: from zdemail04.zdem.compaq.com ([161.114.112.28])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4ztz-0005IH-00
	for sip@ietf.org; Thu, 02 Oct 2003 05:37:39 -0400
Received: from demexg11.emea.cpqcorp.net (demexg11.emea.cpqcorp.net [16.41.86.63])
	by zdemail04.zdem.compaq.com (Postfix) with ESMTP id 5B7E5355
	for <sip@ietf.org>; Thu,  2 Oct 2003 11:37:10 +0200 (CEST)
Received: from demexc02.emea.cpqcorp.net ([16.41.86.72]) by demexg11.emea.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673);
	 Thu, 2 Oct 2003 11:37:10 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C388C8.C05A1CEE"
Date: Thu, 2 Oct 2003 11:37:09 +0200
Message-ID: <D058F9E891C36C468711FCA4357F742E07031C@demexc02.emea.cpqcorp.net>
Thread-Topic: Reserving hardware resources in SIP to ISUP mapping
Thread-Index: AcOIyL9+jCtvRzYcTlug4wrHb8FycQ==
From: "El Moussawi, Ali" <ali.el-moussawi@hp.com>
To: <sip@ietf.org>
X-OriginalArrivalTime: 02 Oct 2003 09:37:10.0211 (UTC) FILETIME=[C0919930:01C388C8]
Subject: [Sip] Reserving hardware resources in SIP to ISUP mapping
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_001_01C388C8.C05A1CEE
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,
My question is about the meaning of the term "reserve hardware
resources" in SIP to ISUP mapping RFC 3398.
There is several steps needed to establish media path :
1 - Asking the MG (Media Gateway) to reserve a PSTN trunk and slot in
receive only mode.
2 - Asking the MG to reserve a RTP path in receive only.
3 - Modifying the PSTN circuit of 1 to send and receive.
4 - Modifying the RTP path of 2 to send and receive.

The RFC 3398 text doesn't give details on when to perform these actions,
but the call flows diagrams give suggestion on how to do it, and there
is sometimes a divergence. For example, in 7.1.1, IAM is sent before
reserving CIC, while 7.2.1 said the opposite (and in deed IAM can't be
sent without a CIC).

I see two ways of solving this. In SIP to ISUP case for instance
* First way :
On INVITE received, steps 1 and 2 are taken, then IAM is sent to PSTN
network.
Later on, when ANM is received, steps 3 and 4 are taken, then 200 OK is
sent to SIP network.

* Second way :
On INVITE received, setp 1 is taken. Then IAM is sent to PSTN network,
then step 2 is taken.
Later on, when ANM is received, steps 3 is taken, then 200 OK is sent to
SIP network. Finally step 4 is taken (no need to wait for ACK from the
SIP network ? ).

Which one is better acording to you ?
Thanks a lot,

Ali

------_=_NextPart_001_01C388C8.C05A1CEE
Content-Type: text/html;
	charset="us-ascii"
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=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.6396.0">
<TITLE>Reserving hardware resources in SIP to ISUP mapping</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi all,</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">My question is about the meaning of =
the term &quot;reserve hardware resources&quot; in SIP to ISUP mapping =
RFC 3398.</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">There is several steps needed to =
establish media path :</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">1 - Asking the MG (Media Gateway) to =
reserve a PSTN trunk and slot in receive only mode.</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">2 - Asking the MG to reserve a RTP =
path in receive only.</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">3 - Modifying the PSTN circuit of 1 to =
send and receive.</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">4 - Modifying the RTP path of 2 to =
send and receive.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The RFC 3398 text doesn't give details =
on when to perform these actions, but the call flows diagrams give =
suggestion on how to do it, and there is sometimes a divergence. For =
example, in 7.1.1, IAM is sent before reserving CIC, while 7.2.1 said =
the opposite (and in deed IAM can't be sent without a CIC).</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I see two ways of solving this. In SIP =
to ISUP case for instance</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">* First way :</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">On INVITE received, steps 1 and 2 are =
taken, then IAM is sent to PSTN network.</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Later on, when ANM is received, steps =
3 and 4 are taken, then 200 OK is sent to SIP network.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">* Second way :</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">On INVITE received, setp 1 is taken. =
Then IAM is sent to PSTN network, then step 2 is taken.</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Later on, when ANM is received, steps =
3 is taken, then 200 OK is sent to SIP network. Finally step 4 is taken =
(no need to wait for ACK from the SIP network ? ).</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Which one is better acording to you =
?</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Thanks a lot,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Ali</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C388C8.C05A1CEE--

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Thu Oct  2 18:06:33 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27745
	for <sip-archive@odin.ietf.org>; Thu, 2 Oct 2003 18:06:33 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A5BaO-0005a8-4Z
	for sip-archive@odin.ietf.org; Thu, 02 Oct 2003 18:06:13 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h92M6Ch0021457
	for sip-archive@odin.ietf.org; Thu, 2 Oct 2003 18:06:12 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A5BaE-0005ZT-Rf; Thu, 02 Oct 2003 18:06:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A5Ba6-0005Z4-HG
	for sip@optimus.ietf.org; Thu, 02 Oct 2003 18:05:55 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27639
	for <sip@ietf.org>; Thu, 2 Oct 2003 18:05:43 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A5Ba3-0007Jh-00
	for sip@ietf.org; Thu, 02 Oct 2003 18:05:51 -0400
Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A5Ba2-0007JY-00
	for sip@ietf.org; Thu, 02 Oct 2003 18:05:50 -0400
Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h92M4t002975;
	Thu, 2 Oct 2003 17:04:55 -0500 (CDT)
Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <S5BDR5GQ>; Thu, 2 Oct 2003 15:04:56 -0700
Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D20B4E6EEC@zsc3c030.us.nortel.com>
From: "Francois Audet" <audet@nortelnetworks.com>
To: "'Rohan Mahy'" <rohan@cisco.com>,
        "'Rosen, Brian'"
	 <Brian.Rosen@marconi.com>
Cc: "'Paul Kyzivat'" <pkyzivat@cisco.com>,
        "'Dean Willis'"
	 <dean.willis@softarmor.com>,
        "'Stastny Richard'"
	 <Richard.Stastny@oefeg.at>,
        "'Bob Penfield'" <bpenfield@acmepacket.com>,
        "'sip@ietf.org'" <sip@ietf.org>
Subject: RE: [Sip] SIPIT Interop problem with ;user=phone
Date: Thu, 2 Oct 2003 15:04:53 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C38931.34541C9A"
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_01C38931.34541C9A
Content-Type: text/plain

> Several times in this thread, I have given motivations for 
> functionality you can get if you follow my proposal, such as 
> one proxy 
> handling multiple digit maps (for example in a multi-tenant 
> situation). 
>   You have not addressed these cases.  Nobody has provided 
> any technical 
> reason why my proposal doesn't work, and I have given many 
> reasons why 
> it works.  I will have an ID out in a few days which describes the 
> motivations and detailed scenarios for my approach.  Until 
> then, let's 
> please pause this thread.

Finally! Agreed 100%.




------_=_NextPart_001_01C38931.34541C9A
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2656.31">
<TITLE>RE: [Sip] SIPIT Interop problem with ;user=phone</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>&gt; Several times in this thread, I have given motivations for </FONT>
<BR><FONT SIZE=2>&gt; functionality you can get if you follow my proposal, such as </FONT>
<BR><FONT SIZE=2>&gt; one proxy </FONT>
<BR><FONT SIZE=2>&gt; handling multiple digit maps (for example in a multi-tenant </FONT>
<BR><FONT SIZE=2>&gt; situation). </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; You have not addressed these cases.&nbsp; Nobody has provided </FONT>
<BR><FONT SIZE=2>&gt; any technical </FONT>
<BR><FONT SIZE=2>&gt; reason why my proposal doesn't work, and I have given many </FONT>
<BR><FONT SIZE=2>&gt; reasons why </FONT>
<BR><FONT SIZE=2>&gt; it works.&nbsp; I will have an ID out in a few days which describes the </FONT>
<BR><FONT SIZE=2>&gt; motivations and detailed scenarios for my approach.&nbsp; Until </FONT>
<BR><FONT SIZE=2>&gt; then, let's </FONT>
<BR><FONT SIZE=2>&gt; please pause this thread.</FONT>
</P>

<P><FONT SIZE=2>Finally! Agreed 100%.</FONT>
</P>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C38931.34541C9A--

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Thu Oct  2 22:17:35 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05179
	for <sip-archive@odin.ietf.org>; Thu, 2 Oct 2003 22:17:35 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A5FVK-00017P-3E
	for sip-archive@odin.ietf.org; Thu, 02 Oct 2003 22:17:15 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h932HEnV004295
	for sip-archive@odin.ietf.org; Thu, 2 Oct 2003 22:17:14 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A5FV6-00016l-Cs; Thu, 02 Oct 2003 22:17:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A5FUS-00016I-Vb
	for sip@optimus.ietf.org; Thu, 02 Oct 2003 22:16:21 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05152
	for <sip@ietf.org>; Thu, 2 Oct 2003 22:16:10 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A5FUP-0001sp-00
	for sip@ietf.org; Thu, 02 Oct 2003 22:16:17 -0400
Received: from willow.neustar.com ([209.173.53.84])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A5FUP-0001sN-00
	for sip@ietf.org; Thu, 02 Oct 2003 22:16:17 -0400
Received: from chiimc01.npac.com ([10.32.90.4])
	by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h932FZ023532;
	Fri, 3 Oct 2003 02:15:35 GMT
Received: by CHIIMC01 with Internet Mail Service (5.5.2653.19)
	id <TH2N09W0>; Thu, 2 Oct 2003 21:16:16 -0500
Message-ID: <A9DECB0B8A01A54DBECC03B25D29513C0A7C0A@stntexch03.va.neustar.com>
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: "'El Moussawi, Ali'" <ali.el-moussawi@hp.com>, sip@ietf.org
Subject: RE: [Sip] Reserving hardware resources in SIP to ISUP mapping
Date: Thu, 2 Oct 2003 21:16:17 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C38954.53F18060"
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_01C38954.53F18060
Content-Type: text/plain;
	charset="iso-8859-1"

Some notes below.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: El Moussawi, Ali [mailto:ali.el-moussawi@hp.com]
Sent: Thursday, October 02, 2003 2:37 AM
To: sip@ietf.org
Subject: [Sip] Reserving hardware resources in SIP to ISUP mapping



Hi all, 
My question is about the meaning of the term "reserve hardware resources" in
SIP to ISUP mapping RFC 3398. 
There is several steps needed to establish media path : 
1 - Asking the MG (Media Gateway) to reserve a PSTN trunk and slot in
receive only mode. 
2 - Asking the MG to reserve a RTP path in receive only. 
3 - Modifying the PSTN circuit of 1 to send and receive. 
4 - Modifying the RTP path of 2 to send and receive.  

<JFP> I think that by the term "reserve hardware resources" we meant more
the acquisition of those DSP resources inside a gateway that are integral to
the process described in 3 and 4. Or we might have, if the term "reserve
hardware resources" actually appeared in RFC3398, which it doesn't.
"reserve" appears in 7.2.1 and 8.2.1 - as far as I know, those are the only
instances. 8.2.1 mentions DSP resource acquisition. 7.2.1 does mention TCIC
selection as a necessary prerequisite to IAM transmission. </JFP> 

The RFC 3398 text doesn't give details on when to perform these actions, but
the call flows diagrams give suggestion on how to do it, and there is
sometimes a divergence. For example, in 7.1.1, IAM is sent before reserving
CIC, while 7.2.1 said the opposite (and in deed IAM can't be sent without a
CIC). 

<JFP> In 7.1.1, an IAM is sent before reserving the CIC? Where does it say
that, exactly? 7.1.1 doesn't even talk  about any sort of reservation. In
fact, it passes over in silence when any necessary 'resources' are acquired.
</JFP> 

I see two ways of solving this. In SIP to ISUP case for instance 
* First way : 
On INVITE received, steps 1 and 2 are taken, then IAM is sent to PSTN
network. 
Later on, when ANM is received, steps 3 and 4 are taken, then 200 OK is sent
to SIP network. 

* Second way : 
On INVITE received, setp 1 is taken. Then IAM is sent to PSTN network, then
step 2 is taken. 
Later on, when ANM is received, steps 3 is taken, then 200 OK is sent to SIP
network. Finally step 4 is taken (no need to wait for ACK from the SIP
network ? ).

Which one is better acording to you ?  

<JFP> Unfortunately, what you're really asking about here is "early media".
You want to know when the gateway should begin transmission of media in the
backwards direction in SIP-ISUP cases, and when it should transition to
bidirectional media. I might point you to section 5.5 of RFC3398, and
moreover to:

http://www.ietf.org/internet-drafts/draft-camarillo-sipping-early-media-02.t
xt
<http://www.ietf.org/internet-drafts/draft-camarillo-sipping-early-media-02.
txt>  

</JFP> 

 Thanks a lot, 

Ali 


------_=_NextPart_001_01C38954.53F18060
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">
<TITLE>Reserving hardware resources in SIP to ISUP mapping</TITLE>

<META content="MSHTML 6.00.2800.1226" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=468181601-03102003>Some 
notes below.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=468181601-03102003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=468181601-03102003>Jon 
Peterson</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=468181601-03102003>NeuStar, Inc.</SPAN></FONT></DIV>
<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> El Moussawi, Ali 
  [mailto:ali.el-moussawi@hp.com]<BR><B>Sent:</B> Thursday, October 02, 2003 
  2:37 AM<BR><B>To:</B> sip@ietf.org<BR><B>Subject:</B> [Sip] Reserving hardware 
  resources in SIP to ISUP mapping<BR><BR></FONT></DIV><!-- Converted from text/rtf format -->
  <P><FONT face=Arial size=2>Hi all,</FONT> <BR><FONT face=Arial size=2>My 
  question is about the meaning of the term "reserve hardware resources" in SIP 
  to ISUP mapping RFC 3398.</FONT> <BR><FONT face=Arial size=2>There is several 
  steps needed to establish media path :</FONT> <BR><FONT face=Arial size=2>1 - 
  Asking the MG (Media Gateway) to reserve a PSTN trunk and slot in receive only 
  mode.</FONT> <BR><FONT face=Arial size=2>2 - Asking the MG to reserve a RTP 
  path in receive only.</FONT> <BR><FONT face=Arial size=2>3 - Modifying the 
  PSTN circuit of 1 to send and receive.</FONT> <BR><FONT face=Arial size=2>4 - 
  Modifying the RTP path of 2 to send and receive.</FONT>&nbsp;<SPAN 
  class=468181601-03102003><FONT face=Arial color=#0000ff 
  size=2>&nbsp;</FONT></SPAN></P>
  <P><SPAN class=468181601-03102003><FONT face=Arial color=#0000ff 
  size=2>&lt;JFP&gt; I think that by the term "reserve hardware 
  resources"&nbsp;we meant more the acquisition of those DSP resources inside a 
  gateway that are integral to the process described in 3 and 4. Or we might 
  have, if the term "reserve hardware resources" actually appeared in RFC3398, 
  which it doesn't. "reserve" appears&nbsp;in 7.2.1 and 8.2.1 - as far as I 
  know, those&nbsp;are the only instances.&nbsp;8.2.1 mentions DSP resource 
  acquisition.&nbsp;7.2.1 does mention TCIC selection as a necessary 
  prerequisite to IAM transmission. &lt;/JFP&gt;</FONT>&nbsp;</SPAN></P>
  <P><FONT face=Arial><FONT size=2>The RFC 3398 text doesn't give details on 
  when to perform these actions, but the call flows diagrams give suggestion on 
  how to do it, and there is sometimes a divergence. For example, in 7.1.1, IAM 
  is sent before reserving CIC, while 7.2.1 said the opposite (and in deed IAM 
  can't be sent without a CIC).<SPAN class=468181601-03102003><FONT 
  color=#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></P>
  <P><FONT face=Arial><FONT size=2><SPAN class=468181601-03102003><FONT 
  color=#0000ff>&lt;JFP&gt;&nbsp;In 7.1.1, an IAM is sent before reserving the 
  CIC? Where does it say that, exactly?&nbsp;7.1.1 doesn't even talk&nbsp; about 
  any sort of reservation. In fact, it passes over in silence when any necessary 
  'resources' are acquired. 
  &nbsp;&lt;/JFP&gt;</FONT>&nbsp;</SPAN></FONT></FONT></P>
  <P><FONT face=Arial size=2>I see two ways of solving this. In SIP to ISUP case 
  for instance</FONT> <BR><FONT face=Arial size=2>* First way :</FONT> <BR><FONT 
  face=Arial size=2>On INVITE received, steps 1 and 2 are taken, then IAM is 
  sent to PSTN network.</FONT> <BR><FONT face=Arial size=2>Later on, when ANM is 
  received, steps 3 and 4 are taken, then 200 OK is sent to SIP network.</FONT> 
  </P>
  <P><FONT face=Arial size=2>* Second way :</FONT> <BR><FONT face=Arial 
  size=2>On INVITE received, setp 1 is taken. Then IAM is sent to PSTN network, 
  then step 2 is taken.</FONT> <BR><FONT face=Arial size=2>Later on, when ANM is 
  received, steps 3 is taken, then 200 OK is sent to SIP network. Finally step 4 
  is taken (no need to wait for ACK from the SIP network ? ).</FONT></P>
  <P><FONT face=Arial size=2>Which one is better acording to you 
  ?</FONT>&nbsp;<SPAN class=468181601-03102003><FONT face=Arial color=#0000ff 
  size=2>&nbsp;</FONT></SPAN></P>
  <P><SPAN class=468181601-03102003><FONT face=Arial color=#0000ff 
  size=2>&lt;JFP&gt; Unfortunately, what you're really asking&nbsp;about here is 
  "early media". You want to know when the gateway should 
  begin&nbsp;transmission of media in the&nbsp;backwards direction in 
  SIP-ISUP&nbsp;cases, and when it should transition to bidirectional media. I 
  might point you to section 5.5 of RFC3398, and moreover 
  to:</FONT></SPAN></P><FONT face=Arial color=#0000ff size=2><A 
  href="http://www.ietf.org/internet-drafts/draft-camarillo-sipping-early-media-02.txt">http://www.ietf.org/internet-drafts/draft-camarillo-sipping-early-media-02.txt</A></FONT>
  <P><SPAN class=468181601-03102003><FONT face=Arial color=#0000ff 
  size=2>&lt;/JFP&gt;</FONT>&nbsp;</SPAN></P>
  <P><FONT face=Arial><FONT size=2><SPAN 
  class=468181601-03102003>&nbsp;</SPAN>Thanks a lot,</FONT></FONT> </P>
  <P><FONT face=Arial size=2>Ali</FONT> </P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C38954.53F18060--

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Fri Oct  3 02:21:44 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23676
	for <sip-archive@odin.ietf.org>; Fri, 3 Oct 2003 02:21:43 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A5JJZ-0004NT-52
	for sip-archive@odin.ietf.org; Fri, 03 Oct 2003 02:21:21 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h936LKjB016594
	for sip-archive@odin.ietf.org; Fri, 3 Oct 2003 02:21:20 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A5JJL-0004Gy-3a; Fri, 03 Oct 2003 02:21:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4a9n-00012O-8e
	for sip@optimus.ietf.org; Wed, 01 Oct 2003 02:08:15 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09210
	for <sip@ietf.org>; Wed, 1 Oct 2003 02:08:07 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4a9j-0002cT-00
	for sip@ietf.org; Wed, 01 Oct 2003 02:08:11 -0400
Received: from bay2-f74.bay2.hotmail.com ([65.54.247.74] helo=hotmail.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4a9j-0002bc-00
	for sip@ietf.org; Wed, 01 Oct 2003 02:08:11 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Tue, 30 Sep 2003 23:07:41 -0700
Received: from 80.74.106.2 by by2fd.bay2.hotmail.msn.com with HTTP;
	Wed, 01 Oct 2003 06:07:41 GMT
X-Originating-IP: [80.74.106.2]
X-Originating-Email: [relkem_los@hotmail.com]
From: "Relkem Los" <relkem_los@hotmail.com>
To: sip@ietf.org
Date: Wed, 01 Oct 2003 06:07:41 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY2-F74ilIMb3XLVmA00001866@hotmail.com>
X-OriginalArrivalTime: 01 Oct 2003 06:07:41.0850 (UTC) FILETIME=[52D427A0:01C387E2]
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id CAA09213
Subject: [Sip] ACK retransmission for 2xx
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: quoted-printable

Hi,
According to RFC3261
=93The UAC core MUST generate an ACK request for each 2xx received from t=
he=20
transaction layer=94
and
=93Once the ACK has been constructed, the procedures of [4] are used to=20
determine the destination address, port and transport.=94

Does this mean that we need to do the DNS procedure for every retransmiss=
ion=20
of this ACK?
Can=92t this cause the ACK to be sent to a different IP and even use a=20
different transport for each retransmission?

Thanks.

_________________________________________________________________
Get McAfee virus scanning and cleaning of incoming attachments.  Get Hotm=
ail=20
Extra Storage!   http://join.msn.com/?PAGE=3Dfeatures/es


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Fri Oct  3 03:09:46 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23675
	for <sip-archive@odin.ietf.org>; Fri, 3 Oct 2003 02:21:43 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A5JJZ-0004NS-51
	for sip-archive@odin.ietf.org; Fri, 03 Oct 2003 02:21:21 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h936LKib016597
	for sip-archive@odin.ietf.org; Fri, 3 Oct 2003 02:21:20 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A5JJQ-0004IR-RB; Fri, 03 Oct 2003 02:21:12 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4xQS-0002Ui-Gl
	for sip@optimus.ietf.org; Thu, 02 Oct 2003 02:59:00 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05220
	for <sip@ietf.org>; Thu, 2 Oct 2003 02:58:50 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4xQO-0003nF-00
	for sip@ietf.org; Thu, 02 Oct 2003 02:58:56 -0400
Received: from bay2-f118.bay2.hotmail.com ([65.54.247.118] helo=hotmail.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4xQO-0003ms-00
	for sip@ietf.org; Thu, 02 Oct 2003 02:58:56 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 1 Oct 2003 23:58:26 -0700
Received: from 80.74.106.2 by by2fd.bay2.hotmail.msn.com with HTTP;
	Thu, 02 Oct 2003 06:58:26 GMT
X-Originating-IP: [80.74.106.2]
X-Originating-Email: [relkem_los@hotmail.com]
From: "Relkem Los" <relkem_los@hotmail.com>
To: sip@ietf.org
Date: Thu, 02 Oct 2003 06:58:26 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY2-F118EXQHuvDr940000699a@hotmail.com>
X-OriginalArrivalTime: 02 Oct 2003 06:58:26.0822 (UTC) FILETIME=[942FC260:01C388B2]
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id CAA05221
Subject: [Sip] ACK retransmission for 2xx
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: quoted-printable

Hi,
According to RFC3261 =93The UAC core MUST generate an ACK request for eac=
h 2xx=20
received from the transaction layer=94 and =93 Once the ACK has been=20
constructed, the procedures of [4] are used to determine the destination=20
address, port and transport.=94
Does this mean that we need to do the DNS procedure for every retransmiss=
ion=20
of this ACK?
Can=92t this cause the ACK to be sent to a different IP and even use a=20
different transport for each retransmission?

Thanks.

_________________________________________________________________
Add MSN 8 Internet Software to your existing Internet access and enjoy=20
patented spam protection and more.  Sign up now!  =20
http://join.msn.com/?page=3Ddept/byoa


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Fri Oct  3 03:09:47 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23680
	for <sip-archive@odin.ietf.org>; Fri, 3 Oct 2003 02:21:43 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A5JJZ-0004NV-5H
	for sip-archive@odin.ietf.org; Fri, 03 Oct 2003 02:21:22 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h936LKlL016599
	for sip-archive@odin.ietf.org; Fri, 3 Oct 2003 02:21:20 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A5JJT-0004J0-TW; Fri, 03 Oct 2003 02:21:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4ywt-0007eh-Lc
	for sip@optimus.ietf.org; Thu, 02 Oct 2003 04:36:35 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07861
	for <sip@ietf.org>; Thu, 2 Oct 2003 04:36:26 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4ywq-0004o7-00
	for sip@ietf.org; Thu, 02 Oct 2003 04:36:32 -0400
Received: from mail1.telekom.de ([62.225.183.202])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4ywp-0004nv-00
	for sip@ietf.org; Thu, 02 Oct 2003 04:36:32 -0400
Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP for sip@ietf.org; Thu, 2 Oct 2003 10:34:51 +0200
Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <T543S3T0>; Thu, 2 Oct 2003 10:34:50 +0200
Message-Id: <32BCBA960C20EB408F4BE7658522620D034398@G9JJX.mgb01.telekom.de>
From: "Alexeitsev, D" <D.Alexeitsev@t-com.net>
To: sip@ietf.org
Subject: AW: [Sip] SIPIT Interop problem with ;user=phone
Date: Thu, 2 Oct 2003 10:34:40 +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>

Hello All,

Sorry if I'm getting too late, still I want add my two cents on this discussion

There are several possibilities how a User Equipment (UE) can send address information which is particularly true for the mobile phones. People dial network codes (for example "911") national number with prefix (for example "01234567899"), international number with prefix (for example "00123456789123" or "+123456789123") and so on.

I can not imagine that a UE can translate this dial strings in to E.164 numbers, just because this strings differs around the world.

So the UE just puts the string that a human dialled in to the Request-URI and now the interesting starts. I don't see the need of tel URI contexts as applied to the SIP protocol as there are already several ways in SIP how you can address the dial string analyser (thus define the context):

- address dialstring analyser in the host portion of SIP-URI, and put the dial string in to userpart
- address dialstring analyser in the Route: header field and put dial string in to tel URI
- address dialstring analyser in the IP header and put dial string in to tel URI (not recommended behaviour)

Note: Don't know why would someone use the last two items as they are just the separation of the information that can be put in one place: SIP-URI.

By addressing dialstring analyser, one has already defined the context, so there is no need to put one. No user=phone as the UE can not do the dialstring-to-E.164 conversion.

After dialstring analyser did his job there will be FQe164, that shall be used in the global Internet. My understanding was that the dialstring analyser then puts user=phone as the address information in SIP-URI userpart is FQe164 and it is formatted according to the RFC 2806.

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 exim@www1.ietf.org  Fri Oct  3 03:09:47 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23677
	for <sip-archive@odin.ietf.org>; Fri, 3 Oct 2003 02:21:43 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A5JJZ-0004NU-4x
	for sip-archive@odin.ietf.org; Fri, 03 Oct 2003 02:21:21 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h936LKiA016596
	for sip-archive@odin.ietf.org; Fri, 3 Oct 2003 02:21:20 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A5JJO-0004HI-74; Fri, 03 Oct 2003 02:21:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4dgZ-0004mk-I7
	for sip@optimus.ietf.org; Wed, 01 Oct 2003 05:54:19 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05854
	for <SIP@ietf.org>; Wed, 1 Oct 2003 05:54:11 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4dgV-0004xY-00
	for SIP@ietf.org; Wed, 01 Oct 2003 05:54:15 -0400
Received: from gc-na5.alcatel.fr ([64.208.49.5] helo=smail2.alcatel.fr)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4dgR-0004wz-00
	for SIP@ietf.org; Wed, 01 Oct 2003 05:54:11 -0400
Received: from bsf.alcatel.fr (mail205.dit.sxb.bsf.alcatel.fr [155.132.205.115])
	by smail2.alcatel.fr (ALCANET/NETFR) with ESMTP id h919reYY031283
	for <SIP@ietf.org>; Wed, 1 Oct 2003 11:53:40 +0200
Received: from mail (mail-bsf-alcatel-fr.dit.sxb.bsf.alcatel.fr [155.132.205.91])
	by bsf.alcatel.fr (8.8.8+Sun/8.9.3) with ESMTP id LAA03557
	for <SIP@ietf.org>; Wed, 1 Oct 2003 11:53:40 +0200 (MET DST)
Received: from bst.bsf.alcatel.fr ([155.132.76.46]) 
	by mail (8.8.8+Sun/) with ESMTP id LAA03553;
	Wed, 1 Oct 2003 11:53:40 +0200 (MET DST)
Message-ID: <3F7AA3FC.2070400@bst.bsf.alcatel.fr>
Date: Wed, 01 Oct 2003 11:53:00 +0200
From: Jean-Francois Rey <jean-francois.rey@bst.bsf.alcatel.fr>
Organization: Alcatel
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
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
X-Virus-Scanned: by amavisd-new
Content-Transfer-Encoding: 7bit
Subject: [Sip] Change of display name
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 implementing some attended transfer use cases between a telephone 
gateway and SIP phones. I need to update the display name when the 
transfer takes place. Unfortunately, if more than one gateway is 
involved in the transfer, I cannot use the REFER + replaces mechanism. I 
know that this topic has already been discussed in this list : Update of 
display name during a call 
(http://www1.ietf.org/mail-archive/working-groups/sip/current/msg08521.html), 
Update and P-Asserted-ID 
(http://www1.ietf.org/mail-archive/working-groups/sip/current/msg08142.html). 
Unfortunately, I'm still a bit unsure of what is the outcome of these 
threads. Using an identity mechanism (a short term one like 
P-Asserted-ID or a long term one like AIB) in a UPDATE or re-INVITE 
seems a bit underspecified to say the least. Could anyone provide 
guidance on these topics : do we have a consensus ? Would this consensus 
go beyond telephone gateways experts and include SIP phone and 
application vendors ? Are there any existing documents or planned 
actions (new versions of drafts or rfcs, BCP) that would clarify this 
topic ?

I played a little bit with SIP phones and I found out that a solution 
works with many SIP phones : using the usual INVITE + replaces mechanisms.

So instead of the UPDATE + identity solution

          Gateway	 Dialog D1	    SIP phone
	  |=========================|
	  |    (D1)UPDATE	    |
	  |------------------------>|

I tried this :

          Gateway	 Dialog D1	    SIP phone
	  |=========================|
	  |    (D2)INVITE	    |
	  |	(replaces D1)	    |
	  |------------------------>|

It works fine except if D1 is not confirmed.
I understand that
- there might be GRUU/routing problems (but nothing new compared to 
usual REFER + replaces mechanism),
- there are more messages being exchanged than in the UPDATE solution 
(but the INVITE + replaces seems the BCP for attended transfer in SIP).

So there are issues. OTOH this solution works with many implementations, 
it can rely on all identity solutions and IMHO it uses nicely the 
semantic of replaces (which is needed for attended transfer between SIP 
phones anyway).

I'd like to have the community's feeling on that topic.

Thanks,
Jean-Francois


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Fri Oct  3 07:12:38 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00607
	for <sip-archive@odin.ietf.org>; Fri, 3 Oct 2003 07:12:38 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A5Nr4-0008EM-ND
	for sip-archive@odin.ietf.org; Fri, 03 Oct 2003 07:12:15 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h93BCEmQ031633
	for sip-archive@odin.ietf.org; Fri, 3 Oct 2003 07:12:14 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A5Nqq-0008Dd-Ac; Fri, 03 Oct 2003 07:12:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A5Nqn-0008DG-4w
	for sip@optimus.ietf.org; Fri, 03 Oct 2003 07:11:57 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00587
	for <sip@ietf.org>; Fri, 3 Oct 2003 07:11:45 -0400 (EDT)
From: x.chen@fle.fujitsu.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A5Nqi-0006mf-00
	for sip@ietf.org; Fri, 03 Oct 2003 07:11:52 -0400
Received: from [193.122.18.249] (helo=emily.fle.fujitsu.com)
	by ietf-mx with smtp (Exim 4.12)
	id 1A5Nqh-0006mY-00
	for sip@ietf.org; Fri, 03 Oct 2003 07:11:52 -0400
Received: by fle2.fle.fujitsu.com with Internet Mail Service (5.5.2656.59)
	id <TNBHDKZP>; Fri, 3 Oct 2003 12:01:08 +0100
Message-ID: <E9978DD405A2D611913500047583E37A4D18AA@fle2.fle.fujitsu.com>
To: sip@ietf.org
Date: Fri, 3 Oct 2003 12:01:07 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/mixed;
	boundary="----=_NextPartTM-000-635e0086-db94-4a82-8586-3fd33b47c22c"
Subject: [Sip] Question on draft Indicating User Agent Capabilities in the Sessi
 on Initiation Protocol
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.

------=_NextPartTM-000-635e0086-db94-4a82-8586-3fd33b47c22c
Content-Type: text/plain

Hi all,

I am just thinking this draft can be expanded to include to indicate the
callee preference information too.

The use case could be that when user has multiple terminals with different
capabilities registered as the contact addresses, the user could tell the
network (in REGISTER) that for which type of services (content), which of
his terminals (contact addresses) to be used. For example, for Instant
Messaging with video content, to my laptop (with better display).

Or maybe this use case has been addressed by another draft? Please let me
know.

Regards
 
Xin Chen
Mobile Network Division
Fujitsu Laboratories Europe
Tel: +44(0)2086064453
Mobile: +44(0)7775741020


------=_NextPartTM-000-635e0086-db94-4a82-8586-3fd33b47c22c
Content-Type: text/plain;
	name="InterScan_Disclaimer.txt"
Content-Disposition: attachment;
	filename="InterScan_Disclaimer.txt"
Content-Transfer-Encoding: 7bit

This e-mail has been scanned by Trend InterScan Software.

This e-mail (and its attachment(s) if any) is intended for the named 
addressee(s) only. It may
contain information which is privileged and confidential within the 
meaning of the applicable law.
Unauthorised use, copying or disclosure is strictly prohibited and may 
be unlawful.

If you are not the intended recipient please delete this email and 
contact the sender via email return.

Fujitsu Laboratories of Europe Ltd (FLE) does not accept responsibility 
for changes made to this email after
it was sent. The views expressed in this email may not necessarily be 
the views held by FLE.

Unless expressly stated otherwise, this email does not form part of a 
legally binding contract
or agreement between the recipient and Fujitsu Laboratories of Europe Ltd (FLE).

------=_NextPartTM-000-635e0086-db94-4a82-8586-3fd33b47c22c--

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Fri Oct  3 08:40:43 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04490
	for <sip-archive@odin.ietf.org>; Fri, 3 Oct 2003 08:40:43 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A5PEL-0003ej-8f
	for sip-archive@odin.ietf.org; Fri, 03 Oct 2003 08:40:21 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h93CeL7r014052
	for sip-archive@odin.ietf.org; Fri, 3 Oct 2003 08:40:21 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A5PE4-0003dr-CG; Fri, 03 Oct 2003 08:40:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A5PDx-0003dG-Ei
	for sip@optimus.ietf.org; Fri, 03 Oct 2003 08:39:57 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04477
	for <sip@ietf.org>; Fri, 3 Oct 2003 08:39:48 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A5PDw-0000EC-00
	for sip@ietf.org; Fri, 03 Oct 2003 08:39:56 -0400
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A5PDv-0000E4-00
	for sip@ietf.org; Fri, 03 Oct 2003 08:39:55 -0400
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 IAA03008;
	Fri, 3 Oct 2003 08:39:23 -0400 (EDT)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA10075;
	Fri, 3 Oct 2003 08:39:24 -0400 (EDT)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19)
	id <S6M3YQ0R>; Fri, 3 Oct 2003 08:39:24 -0400
Message-ID: <313680C9A886D511A06000204840E1CF070B5F4B@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Alexeitsev, D'" <D.Alexeitsev@t-com.net>, sip@ietf.org
Subject: RE: [Sip] SIPIT Interop problem with ;user=phone
Date: Fri, 3 Oct 2003 08:39:20 -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>

Denis

Most phones today put a dial string in the user part, put their outbound 
proxy in the host part, and set user=phone.  Right now, if you use such 
phones with a proxy server that is a dialstring analyzer, it will work.  
If the first hop proxy is not the dialstring analyzer, it would fail.  
It would work to change such phones to put a configurable route to  
dialstring analyzer in the INVITE, but the context makes that unnecessary,
as long as you can differentiate dialstrings from phone numbers.  This
thread has had several proposals on how to do that.  Please note that there
are phones that do dialstring analysis, and thus it is important for any
proxy in the path to know if dialstring analysis has already been
done.

Context is a useful concept, for both dialstrings and phone numbers, 
because one element may serve as the dialstring analyzer for a variety 
of environments.  It is common, for example, to have one proxy serve 
several sites.  Each site may have a somewhat different dial plan.  
In such a case, you want the dialstring analyzer to know which dial 
plan is needed.  That is what context does for you.

Finally, the result of dialstring analysis is a phone number, but it may
not be an E.164.  It could be a local number -- a 2,3 or 4 digit 
extension number, for example.

Brian

> -----Original Message-----
> From: Alexeitsev, D [mailto:D.Alexeitsev@t-com.net]
> Sent: Thursday, October 02, 2003 4:35 AM
> To: sip@ietf.org
> Subject: AW: [Sip] SIPIT Interop problem with ;user=phone
> 
> 
> Hello All,
> 
> Sorry if I'm getting too late, still I want add my two cents 
> on this discussion
> 
> There are several possibilities how a User Equipment (UE) can 
> send address information which is particularly true for the 
> mobile phones. People dial network codes (for example "911") 
> national number with prefix (for example "01234567899"), 
> international number with prefix (for example 
> "00123456789123" or "+123456789123") and so on.
> 
> I can not imagine that a UE can translate this dial strings 
> in to E.164 numbers, just because this strings differs around 
> the world.
> 
> So the UE just puts the string that a human dialled in to the 
> Request-URI and now the interesting starts. I don't see the 
> need of tel URI contexts as applied to the SIP protocol as 
> there are already several ways in SIP how you can address the 
> dial string analyser (thus define the context):
> 
> - address dialstring analyser in the host portion of SIP-URI, 
> and put the dial string in to userpart
> - address dialstring analyser in the Route: header field and 
> put dial string in to tel URI
> - address dialstring analyser in the IP header and put dial 
> string in to tel URI (not recommended behaviour)
> 
> Note: Don't know why would someone use the last two items as 
> they are just the separation of the information that can be 
> put in one place: SIP-URI.
> 
> By addressing dialstring analyser, one has already defined 
> the context, so there is no need to put one. No user=phone as 
> the UE can not do the dialstring-to-E.164 conversion.
> 
> After dialstring analyser did his job there will be FQe164, 
> that shall be used in the global Internet. My understanding 
> was that the dialstring analyser then puts user=phone as the 
> address information in SIP-URI userpart is FQe164 and it is 
> formatted according to the RFC 2806.
> 
> 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 exim@www1.ietf.org  Fri Oct  3 09:20:32 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05683
	for <sip-archive@odin.ietf.org>; Fri, 3 Oct 2003 09:20:32 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A5Pqs-00058q-Cb
	for sip-archive@odin.ietf.org; Fri, 03 Oct 2003 09:20:11 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h93DKA3N019741
	for sip-archive@odin.ietf.org; Fri, 3 Oct 2003 09:20:10 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A5Pql-00057k-M0; Fri, 03 Oct 2003 09:20:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A5PqZ-000577-Td
	for sip@optimus.ietf.org; Fri, 03 Oct 2003 09:19:52 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05673
	for <sip@ietf.org>; Fri, 3 Oct 2003 09:19:42 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A5PqY-0000a9-00
	for sip@ietf.org; Fri, 03 Oct 2003 09:19:50 -0400
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A5PqX-0000a4-00
	for sip@ietf.org; Fri, 03 Oct 2003 09:19:49 -0400
Received: from cisco.com (171.71.177.237)
  by sj-iport-3.cisco.com with ESMTP; 03 Oct 2003 06:25:21 -0700
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h93DJHwn019219;
	Fri, 3 Oct 2003 06:19:17 -0700 (PDT)
Received: from [128.107.171.228] ([128.107.171.228])
	by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AIR73950;
	Fri, 3 Oct 2003 06:19:15 -0700 (PDT)
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Thu, 02 Oct 2003 14:44:03 -0700
Subject: Re: [Sip] sip-mib: removal of sipStatusCodeClassesTable
From: Cullen Jennings <fluffy@cisco.com>
To: Kevin Lingle <klingle@cisco.com>, Mary Barnes <mbarnes@nortelnetworks.com>,
        <orit1@microsoft.com>, AC Mahendran <mahendra@qualcomm.com>
CC: Jean-Francois Mule <jf.mule@cablelabs.com>, <sip@ietf.org>
Message-ID: <BBA1EA33.1ECBC%fluffy@cisco.com>
In-Reply-To: <3F744155.2010101@cisco.com>
Mime-version: 1.0
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


One tiny comment on this ....

A 407 may not be an indication that anything bad is happening. I'm not sure
there is much use in grouping all the 4xx together.

Cullen


On 9/26/03 6:38 AM, "Kevin Lingle" <klingle@cisco.com> wrote:

> additionally...
> 
> recently i was cc'd on an email where one developer
> asked another for a list of statistics that could be
> used as a measure of the health/well-being of a sip
> proxy.    the developer responded in terms of the sip
> stats we have in the sip-common-mib and said the following
> about some objects from the sipStatusCodeClassesTable:
> 
> -----
> Successful responses - When calls are successful, these counters
> should be going up.
> 
>    sipStatsSuccessClassIns       Counter32, /* 200 OK response */
>    sipStatsSuccessClassOuts      Counter32,
> 
> Failure responses - A very high value for these counters indicates
> calls failing in the network. Typically, if calls are not failing,
> these counters should have low values and increment slowly.
> 
>    sipStatsReqFailClassIns       Counter32, /* 4XX class errors */
>    sipStatsReqFailClassOuts      Counter32,
>    sipStatsServerFailClassIns    Counter32, /* 5xx class errors */
>    sipStatsServerFailClassOuts   Counter32,
>    sipStatsGlobalFailClassIns    Counter32, /* 6xx class errors */
>    sipStatsGlobalFailClassOuts   Counter32,
> --------
> 
> so i chimed in saying that there was a proposal to
> remove this table from the mib.  if that were to
> occur, was there a small subset of individual rsp code
> counters that could be polled in order to draw
> the same conclusion on failures.
> 
> the answer i got back was that all of the individial
> 4xx,5xx,6xx counters.  a subset of "important" counters
> really wasn't feasible.
> 
> if that is the case, then aren't these per class stats
> potentially of use in quickly gauging whether a sip system
> may be experiencing problems that warrent further investigation?
> 
> kevin
> 
> 
> Kevin Lingle wrote:
>> hi all,
>> 
>> a proposal in on the table to remove this table from
>> the SIP-COMMON-MIB.  cullen was the only one of the reviewers
>> who raised this issue explicitly.  i wanted to give others a
>> chance to comment on it.
>> 
>> orit, did allude to there being too many counters and suggested
>> removal of some summary counters.  he didn't mention this table
>> by name though (i don't think).
>> 
>> these are "summary counters", but were defined this way to give
>> a high level (gross) indicator of problems so a manager could
>> to and probe a system further for the details.  working at a
>> more granular level of rsp code counters would require more polling
>> on the part of snmp managers.  that was the thought behind providing
>> these aggregate counters.
>> 
>> http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-07.txt
>> 
>> comments?
>> 
>> kevin
> 


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Fri Oct  3 10:57:36 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10999
	for <sip-archive@odin.ietf.org>; Fri, 3 Oct 2003 10:57:35 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A5RMo-0001Gg-8y
	for sip-archive@odin.ietf.org; Fri, 03 Oct 2003 10:57:15 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h93EvE15004870
	for sip-archive@odin.ietf.org; Fri, 3 Oct 2003 10:57:14 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A5RMb-0001Fv-OE; Fri, 03 Oct 2003 10:57:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A5RLf-0001FO-NR
	for sip@optimus.ietf.org; Fri, 03 Oct 2003 10:56:04 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10896
	for <sip@ietf.org>; Fri, 3 Oct 2003 10:55:53 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A5RLc-0001nl-00
	for sip@ietf.org; Fri, 03 Oct 2003 10:56:00 -0400
Received: from auds953.usa.alcatel.com ([143.209.238.6])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A5RLc-0001nI-00
	for sip@ietf.org; Fri, 03 Oct 2003 10:56:00 -0400
Received: from alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id h93EtF6E005657;
	Fri, 3 Oct 2003 09:55:15 -0500 (CDT)
Message-ID: <3F7D8DD2.25972BE6@alcatel.com>
Date: Fri, 03 Oct 2003 09:55:14 -0500
From: Alex Audu <alex.audu@alcatel.com>
Reply-To: alex.audu@alcatel.com
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Francois Audet <audet@nortelnetworks.com>
CC: "'Rohan Mahy'" <rohan@cisco.com>,
        "'Rosen, Brian'" <Brian.Rosen@marconi.com>,
        "'Paul Kyzivat'" <pkyzivat@cisco.com>,
        "'Dean Willis'" <dean.willis@softarmor.com>,
        "'Stastny Richard'" <Richard.Stastny@oefeg.at>,
        "'Bob Penfield'" <bpenfield@acmepacket.com>,
        "'sip@ietf.org'" <sip@ietf.org>
Subject: Re: [Sip] SIPIT Interop problem with ;user=phone
References: <2F1FC1DEA077D5119FAD00508BCFD6D20B4E6EEC@zsc3c030.us.nortel.com>
Content-Type: multipart/alternative;
 boundary="------------865E6BBA76CB876500BB8939"
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>


--------------865E6BBA76CB876500BB8939
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello Francois,

How will your proposal scale?  I am not too sure.

Regards,
Alex.

Francois Audet wrote:

>
>
> > Several times in this thread, I have given motivations for
> > functionality you can get if you follow my proposal, such as
> > one proxy
> > handling multiple digit maps (for example in a multi-tenant
> > situation).
> >   You have not addressed these cases.  Nobody has provided
> > any technical
> > reason why my proposal doesn't work, and I have given many
> > reasons why
> > it works.  I will have an ID out in a few days which describes the
> > motivations and detailed scenarios for my approach.  Until
> > then, let's
> > please pause this thread.
>
> Finally! Agreed 100%.
>

--------------865E6BBA76CB876500BB8939
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hello Francois,
<p>How will your proposal scale?&nbsp; I am not too sure.
<p>Regards,
<br>Alex.
<p>Francois Audet wrote:
<blockquote TYPE=CITE>&nbsp;
<p><font size=-1>> Several times in this thread, I have given motivations
for</font>
<br><font size=-1>> functionality you can get if you follow my proposal,
such as</font>
<br><font size=-1>> one proxy</font>
<br><font size=-1>> handling multiple digit maps (for example in a multi-tenant</font>
<br><font size=-1>> situation).</font>
<br><font size=-1>>&nbsp;&nbsp; You have not addressed these cases.&nbsp;
Nobody has provided</font>
<br><font size=-1>> any technical</font>
<br><font size=-1>> reason why my proposal doesn't work, and I have given
many</font>
<br><font size=-1>> reasons why</font>
<br><font size=-1>> it works.&nbsp; I will have an ID out in a few days
which describes the</font>
<br><font size=-1>> motivations and detailed scenarios for my approach.&nbsp;
Until</font>
<br><font size=-1>> then, let's</font>
<br><font size=-1>> please pause this thread.</font>
<p><font size=-1>Finally! Agreed 100%.</font>
<br>&nbsp;</blockquote>
</html>

--------------865E6BBA76CB876500BB8939--


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Fri Oct  3 12:09:46 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13900
	for <sip-archive@odin.ietf.org>; Fri, 3 Oct 2003 12:09:46 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A5SUd-0005ld-Mv
	for sip-archive@odin.ietf.org; Fri, 03 Oct 2003 12:09:25 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h93G9NuV022163
	for sip-archive@odin.ietf.org; Fri, 3 Oct 2003 12:09:23 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A5SUI-0005f3-S3; Fri, 03 Oct 2003 12:09:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A5SU6-0005dw-H7
	for sip@optimus.ietf.org; Fri, 03 Oct 2003 12:08:51 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13856
	for <sip@ietf.org>; Fri, 3 Oct 2003 12:08:41 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A5SU5-0002iB-00
	for sip@ietf.org; Fri, 03 Oct 2003 12:08:49 -0400
Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A5SU4-0002hF-00
	for sip@ietf.org; Fri, 03 Oct 2003 12:08:48 -0400
Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h93G66l17099;
	Fri, 3 Oct 2003 11:06:06 -0500 (CDT)
Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <S5BDS78V>; Fri, 3 Oct 2003 09:06:06 -0700
Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D20B4E7695@zsc3c030.us.nortel.com>
From: "Francois Audet" <audet@nortelnetworks.com>
To: "'alex.audu@alcatel.com'" <alex.audu@alcatel.com>
Cc: "'Rohan Mahy'" <rohan@cisco.com>,
        "'Rosen, Brian'"
	 <Brian.Rosen@marconi.com>,
        "'Paul Kyzivat'" <pkyzivat@cisco.com>,
        "'Dean Willis'" <dean.willis@softarmor.com>,
        "'Stastny Richard'"
	 <Richard.Stastny@oefeg.at>,
        "'Bob Penfield'" <bpenfield@acmepacket.com>,
        "'sip@ietf.org'" <sip@ietf.org>
Subject: RE: [Sip] SIPIT Interop problem with ;user=phone
Date: Fri, 3 Oct 2003 09:06:05 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C389C8.3F2E6318"
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_01C389C8.3F2E6318
Content-Type: text/plain

That's the whole point. It's the only proposal that scales. The other
proposals have the problem that they don't scale because they assume a
single dialing plan per proxy.

This proposals allows as many dialling plans as you want. This is useful for
multi-tennant, geographically disperse enterprises, virtual private
telephony services, etc.


-----Original Message-----
From: Alex Audu [mailto:alex.audu@alcatel.com] 
Sent: Friday, October 03, 2003 07:55
To: Audet, Francois [SC100:4K02:EXCH]
Cc: 'Rohan Mahy'; 'Rosen, Brian'; 'Paul Kyzivat'; 'Dean Willis'; 'Stastny
Richard'; 'Bob Penfield'; 'sip@ietf.org'
Subject: Re: [Sip] SIPIT Interop problem with ;user=phone


Hello Francois, 
How will your proposal scale?  I am not too sure. 
Regards, 
Alex. 
Francois Audet wrote: 
  
> Several times in this thread, I have given motivations for 
> functionality you can get if you follow my proposal, such as 
> one proxy 
> handling multiple digit maps (for example in a multi-tenant 
> situation). 
>   You have not addressed these cases.  Nobody has provided 
> any technical 
> reason why my proposal doesn't work, and I have given many 
> reasons why 
> it works.  I will have an ID out in a few days which describes the 
> motivations and detailed scenarios for my approach.  Until 
> then, let's 
> please pause this thread. 
Finally! Agreed 100%. 
 

------_=_NextPart_001_01C389C8.3F2E6318
Content-Type: text/html
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=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>RE: [Sip] SIPIT Interop problem with ;user=3Dphone</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>That's the whole point. It's the only proposal that =
scales. The other proposals have the problem that they don't scale =
because they assume a single dialing plan per proxy.</FONT></P>

<P><FONT SIZE=3D2>This proposals allows as many dialling plans as you =
want. This is useful for multi-tennant, geographically disperse =
enterprises, virtual private telephony services, etc.</FONT></P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Alex Audu [<A =
HREF=3D"mailto:alex.audu@alcatel.com">mailto:alex.audu@alcatel.com</A>] =
</FONT>
<BR><FONT SIZE=3D2>Sent: Friday, October 03, 2003 07:55</FONT>
<BR><FONT SIZE=3D2>To: Audet, Francois [SC100:4K02:EXCH]</FONT>
<BR><FONT SIZE=3D2>Cc: 'Rohan Mahy'; 'Rosen, Brian'; 'Paul Kyzivat'; =
'Dean Willis'; 'Stastny Richard'; 'Bob Penfield'; 'sip@ietf.org'</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [Sip] SIPIT Interop problem with =
;user=3Dphone</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hello Francois, </FONT>
<BR><FONT SIZE=3D2>How will your proposal scale?&nbsp; I am not too =
sure. </FONT>
<BR><FONT SIZE=3D2>Regards, </FONT>
<BR><FONT SIZE=3D2>Alex. </FONT>
<BR><FONT SIZE=3D2>Francois Audet wrote: </FONT>
<BR><FONT SIZE=3D2>&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; Several times in this thread, I have given =
motivations for </FONT>
<BR><FONT SIZE=3D2>&gt; functionality you can get if you follow my =
proposal, such as </FONT>
<BR><FONT SIZE=3D2>&gt; one proxy </FONT>
<BR><FONT SIZE=3D2>&gt; handling multiple digit maps (for example in a =
multi-tenant </FONT>
<BR><FONT SIZE=3D2>&gt; situation). </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; You have not addressed these =
cases.&nbsp; Nobody has provided </FONT>
<BR><FONT SIZE=3D2>&gt; any technical </FONT>
<BR><FONT SIZE=3D2>&gt; reason why my proposal doesn't work, and I have =
given many </FONT>
<BR><FONT SIZE=3D2>&gt; reasons why </FONT>
<BR><FONT SIZE=3D2>&gt; it works.&nbsp; I will have an ID out in a few =
days which describes the </FONT>
<BR><FONT SIZE=3D2>&gt; motivations and detailed scenarios for my =
approach.&nbsp; Until </FONT>
<BR><FONT SIZE=3D2>&gt; then, let's </FONT>
<BR><FONT SIZE=3D2>&gt; please pause this thread. </FONT>
<BR><FONT SIZE=3D2>Finally! Agreed 100%. </FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C389C8.3F2E6318--

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Fri Oct  3 13:05:31 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16684
	for <sip-archive@odin.ietf.org>; Fri, 3 Oct 2003 13:05:31 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A5TMd-0000EO-0W
	for sip-archive@odin.ietf.org; Fri, 03 Oct 2003 13:05:11 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h93H5APb000881
	for sip-archive@odin.ietf.org; Fri, 3 Oct 2003 13:05:10 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A5TMU-0000Di-Qs; Fri, 03 Oct 2003 13:05:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A5TLt-0000D3-U4
	for sip@optimus.ietf.org; Fri, 03 Oct 2003 13:04:26 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16659
	for <sip@ietf.org>; Fri, 3 Oct 2003 13:04:15 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A5TLs-0003il-00
	for sip@ietf.org; Fri, 03 Oct 2003 13:04:24 -0400
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A5TLr-0003ie-00
	for sip@ietf.org; Fri, 03 Oct 2003 13:04:23 -0400
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 NAA13391;
	Fri, 3 Oct 2003 13:03:49 -0400 (EDT)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA23581;
	Fri, 3 Oct 2003 13:03:50 -0400 (EDT)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19)
	id <S6M3YZNP>; Fri, 3 Oct 2003 13:03:50 -0400
Message-ID: <313680C9A886D511A06000204840E1CF070B5F5B@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Francois Audet'" <audet@nortelnetworks.com>,
        "'alex.audu@alcatel.com'"
	 <alex.audu@alcatel.com>
Cc: "'Rohan Mahy'" <rohan@cisco.com>, "'Paul Kyzivat'" <pkyzivat@cisco.com>,
        "'Dean Willis'" <dean.willis@softarmor.com>,
        "'Stastny Richard'"
	 <Richard.Stastny@oefeg.at>,
        "'Bob Penfield'" <bpenfield@acmepacket.com>,
        "'sip@ietf.org'" <sip@ietf.org>
Subject: RE: [Sip] SIPIT Interop problem with ;user=phone
Date: Fri, 3 Oct 2003 13:03:44 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C389D0.3DB085CC"
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_01C389D0.3DB085CC
Content-Type: text/plain;
	charset="iso-8859-1"

I'm pausing, as requested, but several of the proposal's scale.
 
Brian

-----Original Message-----
From: Francois Audet [mailto:audet@nortelnetworks.com]
Sent: Friday, October 03, 2003 12:06 PM
To: 'alex.audu@alcatel.com'
Cc: 'Rohan Mahy'; 'Rosen, Brian'; 'Paul Kyzivat'; 'Dean Willis'; 'Stastny
Richard'; 'Bob Penfield'; 'sip@ietf.org'
Subject: RE: [Sip] SIPIT Interop problem with ;user=phone



That's the whole point. It's the only proposal that scales. The other
proposals have the problem that they don't scale because they assume a
single dialing plan per proxy.

This proposals allows as many dialling plans as you want. This is useful for
multi-tennant, geographically disperse enterprises, virtual private
telephony services, etc.


-----Original Message----- 
From: Alex Audu [ mailto:alex.audu@alcatel.com
<mailto:alex.audu@alcatel.com> ] 
Sent: Friday, October 03, 2003 07:55 
To: Audet, Francois [SC100:4K02:EXCH] 
Cc: 'Rohan Mahy'; 'Rosen, Brian'; 'Paul Kyzivat'; 'Dean Willis'; 'Stastny
Richard'; 'Bob Penfield'; 'sip@ietf.org' 
Subject: Re: [Sip] SIPIT Interop problem with ;user=phone 


Hello Francois, 
How will your proposal scale?  I am not too sure. 
Regards, 
Alex. 
Francois Audet wrote: 
  
> Several times in this thread, I have given motivations for 
> functionality you can get if you follow my proposal, such as 
> one proxy 
> handling multiple digit maps (for example in a multi-tenant 
> situation). 
>   You have not addressed these cases.  Nobody has provided 
> any technical 
> reason why my proposal doesn't work, and I have given many 
> reasons why 
> it works.  I will have an ID out in a few days which describes the 
> motivations and detailed scenarios for my approach.  Until 
> then, let's 
> please pause this thread. 
Finally! Agreed 100%. 
  


------_=_NextPart_001_01C389D0.3DB085CC
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">
<TITLE>RE: [Sip] SIPIT Interop problem with ;user=phone</TITLE>

<META content="MSHTML 6.00.2800.1106" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=295080317-03102003><FONT face=Arial color=#0000ff>I'm pausing, 
as requested, but several of the proposal's scale.</FONT></SPAN></DIV>
<DIV><SPAN class=295080317-03102003><FONT face=Arial 
color=#0000ff></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=295080317-03102003><FONT face=Arial 
color=#0000ff>Brian</FONT></SPAN></DIV>
<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> Francois Audet 
  [mailto:audet@nortelnetworks.com]<BR><B>Sent:</B> Friday, October 03, 2003 
  12:06 PM<BR><B>To:</B> 'alex.audu@alcatel.com'<BR><B>Cc:</B> 'Rohan Mahy'; 
  'Rosen, Brian'; 'Paul Kyzivat'; 'Dean Willis'; 'Stastny Richard'; 'Bob 
  Penfield'; 'sip@ietf.org'<BR><B>Subject:</B> RE: [Sip] SIPIT Interop problem 
  with ;user=phone<BR><BR></FONT></DIV>
  <P><FONT size=2>That's the whole point. It's the only proposal that scales. 
  The other proposals have the problem that they don't scale because they assume 
  a single dialing plan per proxy.</FONT></P>
  <P><FONT size=2>This proposals allows as many dialling plans as you want. This 
  is useful for multi-tennant, geographically disperse enterprises, virtual 
  private telephony services, etc.</FONT></P><BR>
  <P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: Alex 
  Audu [<A href="mailto:alex.audu@alcatel.com">mailto:alex.audu@alcatel.com</A>] 
  </FONT><BR><FONT size=2>Sent: Friday, October 03, 2003 07:55</FONT> <BR><FONT 
  size=2>To: Audet, Francois [SC100:4K02:EXCH]</FONT> <BR><FONT size=2>Cc: 
  'Rohan Mahy'; 'Rosen, Brian'; 'Paul Kyzivat'; 'Dean Willis'; 'Stastny 
  Richard'; 'Bob Penfield'; 'sip@ietf.org'</FONT> <BR><FONT size=2>Subject: Re: 
  [Sip] SIPIT Interop problem with ;user=phone</FONT> </P><BR>
  <P><FONT size=2>Hello Francois, </FONT><BR><FONT size=2>How will your proposal 
  scale?&nbsp; I am not too sure. </FONT><BR><FONT size=2>Regards, 
  </FONT><BR><FONT size=2>Alex. </FONT><BR><FONT size=2>Francois Audet wrote: 
  </FONT><BR><FONT size=2>&nbsp; </FONT><BR><FONT size=2>&gt; Several times in 
  this thread, I have given motivations for </FONT><BR><FONT size=2>&gt; 
  functionality you can get if you follow my proposal, such as </FONT><BR><FONT 
  size=2>&gt; one proxy </FONT><BR><FONT size=2>&gt; handling multiple digit 
  maps (for example in a multi-tenant </FONT><BR><FONT size=2>&gt; situation). 
  </FONT><BR><FONT size=2>&gt;&nbsp;&nbsp; You have not addressed these 
  cases.&nbsp; Nobody has provided </FONT><BR><FONT size=2>&gt; any technical 
  </FONT><BR><FONT size=2>&gt; reason why my proposal doesn't work, and I have 
  given many </FONT><BR><FONT size=2>&gt; reasons why </FONT><BR><FONT 
  size=2>&gt; it works.&nbsp; I will have an ID out in a few days which 
  describes the </FONT><BR><FONT size=2>&gt; motivations and detailed scenarios 
  for my approach.&nbsp; Until </FONT><BR><FONT size=2>&gt; then, let's 
  </FONT><BR><FONT size=2>&gt; please pause this thread. </FONT><BR><FONT 
  size=2>Finally! Agreed 100%. </FONT><BR><FONT size=2>&nbsp;</FONT> 
</P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C389D0.3DB085CC--

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Fri Oct  3 13:14:26 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17005
	for <sip-archive@odin.ietf.org>; Fri, 3 Oct 2003 13:14:26 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A5TVG-0000yA-AY
	for sip-archive@odin.ietf.org; Fri, 03 Oct 2003 13:14:06 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h93HE6do003702
	for sip-archive@odin.ietf.org; Fri, 3 Oct 2003 13:14:06 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A5TVB-0000xB-Cd; Fri, 03 Oct 2003 13:14:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A5TV1-0000wk-BB
	for sip@optimus.ietf.org; Fri, 03 Oct 2003 13:13:51 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16948
	for <sip@ietf.org>; Fri, 3 Oct 2003 13:13:40 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A5TUz-0003o2-00
	for sip@ietf.org; Fri, 03 Oct 2003 13:13:49 -0400
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A5TUy-0003nm-00
	for sip@ietf.org; Fri, 03 Oct 2003 13:13:49 -0400
Received: from cisco.com (64.102.124.12)
  by sj-iport-3.cisco.com with ESMTP; 03 Oct 2003 10:19:24 -0700
Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27])
	by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h93HDE01010269;
	Fri, 3 Oct 2003 13:13:15 -0400 (EDT)
Received: from cisco.com (klingle-linux.cisco.com [64.102.93.48])
	by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id APH27536;
	Fri, 3 Oct 2003 10:13:13 -0700 (PDT)
Message-ID: <3F7DAE29.7090806@cisco.com>
Date: Fri, 03 Oct 2003 13:13:13 -0400
From: Kevin Lingle <klingle@cisco.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Cullen Jennings <fluffy@cisco.com>
CC: Mary Barnes <mbarnes@nortelnetworks.com>, orit1@microsoft.com,
        AC Mahendran
 <mahendra@qualcomm.com>,
        Jean-Francois Mule <jf.mule@cablelabs.com>, sip@ietf.org
Subject: Re: [Sip] sip-mib: removal of sipStatusCodeClassesTable
References: <BBA1EA33.1ECBC%fluffy@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



Cullen Jennings wrote:
> One tiny comment on this ....
> 
> A 407 may not be an indication that anything bad is happening. I'm not sure
> there is much use in grouping all the 4xx together.

cullen,

do i detect, in this comment, that perhap you could see usefulness in
any of the other classes ;) (eg, 6xx);  or do you still essentially want
the entire table removed?

it would be good to hear the views of others (assigned reviewers especially).

i don't have any great attachement to the table.  i was ready to remove it
based on cullens original comments and then i got feed back (below)
with a point of view supporting the concept behind this table.

if i don't here any other support for the table, then i'll remove it from the mib.

kevin

> 
> Cullen
> 
> 
> On 9/26/03 6:38 AM, "Kevin Lingle" <klingle@cisco.com> wrote:
> 
> 
>>additionally...
>>
>>recently i was cc'd on an email where one developer
>>asked another for a list of statistics that could be
>>used as a measure of the health/well-being of a sip
>>proxy.    the developer responded in terms of the sip
>>stats we have in the sip-common-mib and said the following
>>about some objects from the sipStatusCodeClassesTable:
>>
>>-----
>>Successful responses - When calls are successful, these counters
>>should be going up.
>>
>>   sipStatsSuccessClassIns       Counter32, /* 200 OK response */
>>   sipStatsSuccessClassOuts      Counter32,
>>
>>Failure responses - A very high value for these counters indicates
>>calls failing in the network. Typically, if calls are not failing,
>>these counters should have low values and increment slowly.
>>
>>   sipStatsReqFailClassIns       Counter32, /* 4XX class errors */
>>   sipStatsReqFailClassOuts      Counter32,
>>   sipStatsServerFailClassIns    Counter32, /* 5xx class errors */
>>   sipStatsServerFailClassOuts   Counter32,
>>   sipStatsGlobalFailClassIns    Counter32, /* 6xx class errors */
>>   sipStatsGlobalFailClassOuts   Counter32,
>>--------
>>
>>so i chimed in saying that there was a proposal to
>>remove this table from the mib.  if that were to
>>occur, was there a small subset of individual rsp code
>>counters that could be polled in order to draw
>>the same conclusion on failures.
>>
>>the answer i got back was that all of the individial
>>4xx,5xx,6xx counters.  a subset of "important" counters
>>really wasn't feasible.
>>
>>if that is the case, then aren't these per class stats
>>potentially of use in quickly gauging whether a sip system
>>may be experiencing problems that warrent further investigation?
>>
>>kevin
>>
>>
>>Kevin Lingle wrote:
>>
>>>hi all,
>>>
>>>a proposal in on the table to remove this table from
>>>the SIP-COMMON-MIB.  cullen was the only one of the reviewers
>>>who raised this issue explicitly.  i wanted to give others a
>>>chance to comment on it.
>>>
>>>orit, did allude to there being too many counters and suggested
>>>removal of some summary counters.  he didn't mention this table
>>>by name though (i don't think).
>>>
>>>these are "summary counters", but were defined this way to give
>>>a high level (gross) indicator of problems so a manager could
>>>to and probe a system further for the details.  working at a
>>>more granular level of rsp code counters would require more polling
>>>on the part of snmp managers.  that was the thought behind providing
>>>these aggregate counters.
>>>
>>>http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-07.txt
>>>
>>>comments?
>>>
>>>kevin
>>
> 
> 


-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Kevin R. Lingle       919.392.2029
  http://www.klove.com                               http://www.air1.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 exim@www1.ietf.org  Fri Oct  3 14:58:34 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20551
	for <sip-archive@odin.ietf.org>; Fri, 3 Oct 2003 14:58:34 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A5V81-0005SY-NY
	for sip-archive@odin.ietf.org; Fri, 03 Oct 2003 14:58:13 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h93IwD2M020979
	for sip-archive@odin.ietf.org; Fri, 3 Oct 2003 14:58:13 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A5V7q-0005Ro-5F; Fri, 03 Oct 2003 14:58:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A5V7U-0005RG-DW
	for sip@optimus.ietf.org; Fri, 03 Oct 2003 14:57:40 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20510
	for <sip@ietf.org>; Fri, 3 Oct 2003 14:57:30 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A5V7R-0004u0-00
	for sip@ietf.org; Fri, 03 Oct 2003 14:57:37 -0400
Received: from motgate.mot.com ([129.188.136.100])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A5V7Q-0004tv-00
	for sip@ietf.org; Fri, 03 Oct 2003 14:57:36 -0400
Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234])
	by motgate.mot.com (Motorola/Motgate) with ESMTP id h93Ivaw1004507
	for <sip@ietf.org>; Fri, 3 Oct 2003 11:57:36 -0700 (MST)
Received: from il27exm02.cig.mot.com (il27exm02.cig.mot.com [10.17.193.3])
	by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h93IvYgi014146
	for <sip@ietf.org>; Fri, 3 Oct 2003 13:57:34 -0500
Received: by il27exm02.cig.mot.com with Internet Mail Service (5.5.2657.2)
	id <T7RMGY2H>; Fri, 3 Oct 2003 13:57:29 -0500
Message-ID: <8F37768D4D9CD71192CF00065BF2598B931FB5@il27exm02.cig.mot.com>
From: Idnani Ajaykumar-AIDNANI1 <Ajaykumar.Idnani@motorola.com>
To: sip@ietf.org,
        "'sip-implementors@cs.columbia.edu'"
	 <sip-implementors@cs.columbia.edu>
Date: Fri, 3 Oct 2003 13:57:19 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.2)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C389E0.2BBE8D36"
Subject: [Sip] A question about section 12 in RFC 3261.
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_01C389E0.2BBE8D36
Content-Type: text/plain

All,
 
I had a question about a possible error scenario, that I feel RFC 3261 does not describe. Let me describe the scenario first, and then raise the question. Imagine a scenario where you have two UAa, that are using two different outbound Proxies, that are in a peering relationship i.e. UA1 -> Proxy1 -> Proxy2 -> UA2. Now assume a reliable transport all through. Also assume that a dialog is setup between the two UAs with the following dialog particulars
 
UA1
===
 
local-tag = tag_ua1
remote-tag = tag_ua2
remote-target = sip:UA2@somehost.somedomain.com:6123
Route-set = <sip:proxy1:5123>, <sip:proxy2:5060>
 
UA2
===
 
local-tag = tag_ua2
remote-tag = tag_ua1
remote-target = sip:UA1@someotherhost.somedomain.com:6234
Rooute-set = <sip:proxy2:5060>, <sip:proxy1:5123>
 
In this case the TCP connection between the UA1 and the Proxy1 was initiated by UA1, and has a TCP tuple of 
 
(IP address of someotherhost.somedomain.com, 6234, IP address of Proxy 1, 5060),
 
where port 6234 is the ephemeral port on UA1, and port 5060 is the port that Proxy 1 is listening on.
 
Similarly the TCP connection between the UA2 and Proxy2 was initiated by UA2 and has a TCP tuple of
 
(IP address of somehost.somedomain.com, 6123, IP address of Proxy 2, 5060),
 
where port 6123 is the ephemeral port on UA2, and port 5060 is the port that Proxy 2 is listening on..
 
Now also assume that the connection between the two proxies is initiated by Proxy 1 and has the following tuple
 
(IP address of Proxy 1, 5123, IP address of Proxy 2, 5060),
 
where port 5123 is the ephemeral port on Proxy1, and port 5060 is  the port that Proxy 2 is listening on.
 
NOW THE QUESTION
---------------------------------
 
What should the Proxy 2 do, if it detects that the connection between Proxy 1, and Proxy 2 is broken? The Route set is telling Proxy 2 to send the request to port 5123 of Proxy1, but the connection to that port does not exist. I did not find any discussion of this in the SIP RFC. I did find something in Section 18 that applied to responses in the same transactions, but I am not sure if the same can be applied to subsequent requests within the same dialog.
 
Your help in this regard will be highly appreciated.
 
Sincerely
- Ajay
 
 

------_=_NextPart_001_01C389E0.2BBE8D36
Content-Type: text/html
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxucz0iaHR0
cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KPE1FVEEgSFRUUC1FUVVJ
Vj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0K
DQoNCjxtZXRhIG5hbWU9UHJvZ0lkIGNvbnRlbnQ9V29yZC5Eb2N1bWVudD4NCjxtZXRhIG5hbWU9
R2VuZXJhdG9yIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEwIj4NCjxtZXRhIG5hbWU9T3JpZ2lu
YXRvciBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMCI+DQo8bGluayByZWw9RmlsZS1MaXN0IGhy
ZWY9ImNpZDpmaWxlbGlzdC54bWxAMDFDMzg5QjYuNDU4ODI3QjAiPg0KPCEtLVtpZiBndGUgbXNv
IDldPjx4bWw+DQogPG86T2ZmaWNlRG9jdW1lbnRTZXR0aW5ncz4NCiAgPG86RG9Ob3RSZWx5T25D
U1MvPg0KIDwvbzpPZmZpY2VEb2N1bWVudFNldHRpbmdzPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt
LVtpZiBndGUgbXNvIDldPjx4bWw+DQogPHc6V29yZERvY3VtZW50Pg0KICA8dzpTcGVsbGluZ1N0
YXRlPkNsZWFuPC93OlNwZWxsaW5nU3RhdGU+DQogIDx3OkdyYW1tYXJTdGF0ZT5DbGVhbjwvdzpH
cmFtbWFyU3RhdGU+DQogIDx3OkRvY3VtZW50S2luZD5Eb2N1bWVudEVtYWlsPC93OkRvY3VtZW50
S2luZD4NCiAgPHc6RW52ZWxvcGVWaXMvPg0KICA8dzpEaXNwbGF5SG9yaXpvbnRhbERyYXdpbmdH
cmlkRXZlcnk+MDwvdzpEaXNwbGF5SG9yaXpvbnRhbERyYXdpbmdHcmlkRXZlcnk+DQogIDx3OkRp
c3BsYXlWZXJ0aWNhbERyYXdpbmdHcmlkRXZlcnk+MDwvdzpEaXNwbGF5VmVydGljYWxEcmF3aW5n
R3JpZEV2ZXJ5Pg0KICA8dzpVc2VNYXJnaW5zRm9yRHJhd2luZ0dyaWRPcmlnaW4vPg0KICA8dzpD
b21wYXRpYmlsaXR5Pg0KICAgPHc6Rm9vdG5vdGVMYXlvdXRMaWtlV1c4Lz4NCiAgIDx3OlNoYXBl
TGF5b3V0TGlrZVdXOC8+DQogICA8dzpBbGlnblRhYmxlc1Jvd0J5Um93Lz4NCiAgIDx3OkZvcmdl
dExhc3RUYWJBbGlnbm1lbnQvPg0KICAgPHc6RG9Ob3RVc2VIVE1MUGFyYWdyYXBoQXV0b1NwYWNp
bmcvPg0KICAgPHc6TGF5b3V0UmF3VGFibGVXaWR0aC8+DQogICA8dzpMYXlvdXRUYWJsZVJvd3NB
cGFydC8+DQogICA8dzpVc2VXb3JkOTdMaW5lQnJlYWtpbmdSdWxlcy8+DQogIDwvdzpDb21wYXRp
YmlsaXR5Pg0KICA8dzpCcm93c2VyTGV2ZWw+TWljcm9zb2Z0SW50ZXJuZXRFeHBsb3JlcjQ8L3c6
QnJvd3NlckxldmVsPg0KIDwvdzpXb3JkRG9jdW1lbnQ+DQo8L3htbD48IVtlbmRpZl0tLT4NCjxz
dHlsZT4NCjwhLS0NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5N
c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bXNvLXN0eWxlLXBhcmVudDoiIjsNCgltYXJnaW46
MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBo
YW47DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsN
Cgltc28tZmFyZWFzdC1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNw
YW4uTXNvSHlwZXJsaW5rDQoJe2NvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu
ZTsNCgl0ZXh0LXVuZGVybGluZTpzaW5nbGU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu
a0ZvbGxvd2VkDQoJe2NvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0K
CXRleHQtdW5kZXJsaW5lOnNpbmdsZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUt
dHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCW1zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1hbnNp
LWZvbnQtc2l6ZToxMC4wcHQ7DQoJbXNvLWJpZGktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh
bWlseTpBcmlhbDsNCgltc28tYXNjaWktZm9udC1mYW1pbHk6QXJpYWw7DQoJbXNvLWhhbnNpLWZv
bnQtZmFtaWx5OkFyaWFsOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OkFyaWFsOw0KCWNvbG9yOndp
bmRvd3RleHQ7fQ0Kc3Bhbi5TcGVsbEUNCgl7bXNvLXN0eWxlLW5hbWU6IiI7DQoJbXNvLXNwbC1l
Onllczt9DQpzcGFuLkdyYW1FDQoJe21zby1zdHlsZS1uYW1lOiIiOw0KCW1zby1ncmFtLWU6eWVz
O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx
LjI1aW4gMS4waW4gMS4yNWluOw0KCW1zby1oZWFkZXItbWFyZ2luOi41aW47DQoJbXNvLWZvb3Rl
ci1tYXJnaW46LjVpbjsNCgltc28tcGFwZXItc291cmNlOjA7fQ0KZGl2LlNlY3Rpb24xDQoJe3Bh
Z2U6U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPg0KPCEtLVtpZiBndGUgbXNvIDEwXT4NCjxzdHls
ZT4NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLyANCiB0YWJsZS5Nc29Ob3JtYWxUYWJsZQ0KCXtt
c28tc3R5bGUtbmFtZToiVGFibGUgTm9ybWFsIjsNCgltc28tdHN0eWxlLXJvd2JhbmQtc2l6ZTow
Ow0KCW1zby10c3R5bGUtY29sYmFuZC1zaXplOjA7DQoJbXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJ
bXNvLXN0eWxlLXBhcmVudDoiIjsNCgltc28tcGFkZGluZy1hbHQ6MGluIDUuNHB0IDBpbiA1LjRw
dDsNCgltc28tcGFyYS1tYXJnaW46MGluOw0KCW1zby1wYXJhLW1hcmdpbi1ib3R0b206LjAwMDFw
dDsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXplOjEwLjBwdDsNCglm
b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQo8L3N0eWxlPg0KPCFbZW5kaWZdLS0+DQo8
L2hlYWQ+DQoNCjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZSBzdHlsZT0n
dGFiLWludGVydmFsOi41aW4nPg0KDQo8ZGl2IGNsYXNzPVNlY3Rpb24xPg0KDQo8cCBjbGFzcz1N
c29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox
MC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbCc+QWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48
L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBz
dHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0y
IGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpB
cmlhbCc+SSBoYWQgYSBxdWVzdGlvbiBhYm91dCBhIHBvc3NpYmxlIGVycm9yIDxzcGFuIGNsYXNz
PUdyYW1FPnNjZW5hcmlvLA0KdGhhdDwvc3Bhbj4gSSBmZWVsIFJGQyAzMjYxIGRvZXMgbm90IGRl
c2NyaWJlLiBMZXQgbWUgZGVzY3JpYmUgdGhlIHNjZW5hcmlvDQpmaXJzdCwgYW5kIHRoZW4gcmFp
c2UgdGhlIHF1ZXN0aW9uLiBJbWFnaW5lIGEgc2NlbmFyaW8gd2hlcmUgeW91IGhhdmUgdHdvIDxz
cGFuDQpjbGFzcz1TcGVsbEU+VUFhPC9zcGFuPiwgdGhhdCBhcmUgdXNpbmcgdHdvIGRpZmZlcmVu
dCBvdXRib3VuZCBQcm94aWVzLCB0aGF0DQphcmUgaW4gYSBwZWVyaW5nIHJlbGF0aW9uc2hpcCBp
LmUuIFVBMSAtJmd0OyBQcm94eTEgLSZndDsgUHJveHkyIC0mZ3Q7IFVBMi4gTm93DQphc3N1bWUg
YSByZWxpYWJsZSB0cmFuc3BvcnQgYWxsIHRocm91Z2guIEFsc28gYXNzdW1lIHRoYXQgYSBkaWFs
b2cgaXMgc2V0dXANCmJldHdlZW4gdGhlIHR3byA8c3BhbiBjbGFzcz1TcGVsbEU+VUFzPC9zcGFu
PiB3aXRoIHRoZSBmb2xsb3dpbmcgZGlhbG9nDQpwYXJ0aWN1bGFyczxvOnA+PC9vOnA+PC9zcGFu
PjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1Bcmlh
bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZv
bnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250
LWZhbWlseTpBcmlhbCc+VUExPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xh
c3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNp
emU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPj09PTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9u
dD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3Bh
biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gY2xh
c3M9R3JhbUU+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsJz5sb2NhbC10YWc8L3NwYW4+PC9mb250Pjwvc3Bhbj48
Zm9udA0KZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6QXJpYWwnPiA9IHRhZ191
YTE8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNw
YW4gY2xhc3M9R3JhbUU+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4NCnN0eWxlPSdmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsJz5yZW1vdGUtdGFnPC9zcGFuPjwvZm9udD48
L3NwYW4+PGZvbnQNCmZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OkFyaWFsJz4g
PSB0YWdfdWEyPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y
bWFsPjxzcGFuIGNsYXNzPUdyYW1FPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuDQpzdHls
ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbCc+cmVtb3RlLXRhcmdldDwvc3Bh
bj48L2ZvbnQ+PC9zcGFuPjxmb250DQpmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWls
eTpBcmlhbCc+ID0gc2lwOlVBMkBzb21laG9zdC5zb21lZG9tYWluLmNvbTo2MTIzPG86cD48L286
cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBm
YWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJp
YWwnPlJvdXRlLXNldCA9ICZsdDtzaXA8c3BhbiBjbGFzcz1HcmFtRT46cHJveHkxOjUxMjM8L3Nw
YW4+Jmd0OywNCiZsdDtzaXA6cHJveHkyOjUwNjAmZ3Q7PG86cD48L286cD48L3NwYW4+PC9mb250
PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFu
IHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXpl
PTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5
OkFyaWFsJz5VQTI8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29O
b3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w
cHQ7DQpmb250LWZhbWlseTpBcmlhbCc+PT09PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4N
Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxl
PSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBjbGFzcz1HcmFt
RT48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6QXJpYWwnPmxvY2FsLXRhZzwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjxmb250DQpm
YWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseTpBcmlhbCc+ID0gdGFnX3VhMjxvOnA+
PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBjbGFz
cz1HcmFtRT48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwnPnJlbW90ZS10YWc8L3NwYW4+PC9mb250Pjwvc3Bhbj48
Zm9udA0KZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6QXJpYWwnPiA9IHRhZ191
YTE8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNw
YW4gY2xhc3M9R3JhbUU+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4NCnN0eWxlPSdmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsJz5yZW1vdGUtdGFyZ2V0PC9zcGFuPjwvZm9u
dD48L3NwYW4+PGZvbnQNCmZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OkFyaWFs
Jz4gPQ0Kc2lwOlVBMUBzb21lb3RoZXJob3N0LnNvbWVkb21haW4uY29tOjYyMzQ8bzpwPjwvbzpw
Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gY2xhc3M9U3Bl
bGxFPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTpBcmlhbCc+Um9vdXRlPC9zcGFuPjwvZm9udD48L3NwYW4+PGZvbnQNCmZh
Y2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OkFyaWFsJz4tc2V0ID0gJmx0O3NpcDxz
cGFuIGNsYXNzPUdyYW1FPjpwcm94eTI6NTA2MDwvc3Bhbj4mZ3Q7LA0KJmx0O3NpcDpwcm94eTE6
NTEyMyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt
YWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7
DQpmb250LWZhbWlseTpBcmlhbCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4N
Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxl
PSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPkluIHRoaXMgY2FzZSB0aGUg
VENQIGNvbm5lY3Rpb24gYmV0d2VlbiB0aGUgVUExIGFuZCB0aGUNClByb3h5MSB3YXMgaW5pdGlh
dGVkIGJ5IFVBMSwgYW5kIGhhcyBhIFRDUCA8c3BhbiBjbGFzcz1TcGVsbEU+dHVwbGU8L3NwYW4+
IG9mIDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48
Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZv
bnQtZmFtaWx5OkFyaWFsJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8
cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2Zv
bnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbCc+KElQIGFkZHJlc3Mgb2Ygc29tZW90
aGVyaG9zdC5zb21lZG9tYWluLmNvbSwgNjIzNCwgSVANCmFkZHJlc3Mgb2YgUHJveHkgMSwgNTA2
MCksPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxm
b250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9u
dC1mYW1pbHk6QXJpYWwnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxw
IGNsYXNzPU1zb05vcm1hbD48c3BhbiBjbGFzcz1HcmFtRT48Zm9udCBzaXplPTIgZmFjZT1Bcmlh
bD48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwnPndoZXJl
PC9zcGFuPjwvZm9udD48L3NwYW4+PGZvbnQNCmZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQt
ZmFtaWx5OkFyaWFsJz4gcG9ydCA2MjM0IGlzIHRoZSBlcGhlbWVyYWwgcG9ydCBvbg0KVUExLCBh
bmQgcG9ydCA1MDYwIGlzIHRoZSBwb3J0IHRoYXQgUHJveHkgMSBpcyBsaXN0ZW5pbmcgb24uPG86
cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNp
emU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1p
bHk6QXJpYWwnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNz
PU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl
OjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz5TaW1pbGFybHkgdGhlIFRDUCBjb25uZWN0aW9u
IGJldHdlZW4gdGhlIFVBMiBhbmQgUHJveHkyIHdhcw0KaW5pdGlhdGVkIGJ5IFVBMiBhbmQgaGFz
IGEgVENQIDxzcGFuIGNsYXNzPVNwZWxsRT50dXBsZTwvc3Bhbj4gb2Y8bzpwPjwvbzpwPjwvc3Bh
bj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJp
YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbCc+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxm
b250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9u
dC1mYW1pbHk6QXJpYWwnPihJUCBhZGRyZXNzIG9mIHNvbWVob3N0LnNvbWVkb21haW4uY29tLCA2
MTIzLCBJUCBhZGRyZXNzIG9mDQpQcm94eSAyLCA1MDYwKSw8bzpwPjwvbzpwPjwvc3Bhbj48L2Zv
bnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNw
YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbCc+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGNs
YXNzPUdyYW1FPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuDQpzdHlsZT0nZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTpBcmlhbCc+d2hlcmU8L3NwYW4+PC9mb250Pjwvc3Bhbj48Zm9u
dA0KZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6QXJpYWwnPiBwb3J0IDYxMjMg
aXMgdGhlIGVwaGVtZXJhbCBwb3J0IG9uDQpVQTIsIGFuZCBwb3J0IDUwNjAgaXMgdGhlIHBvcnQg
dGhhdCBQcm94eSAyIGlzIGxpc3RlbmluZyBvbi4uPG86cD48L286cD48L3NwYW4+PC9mb250Pjwv
cD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0
eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIg
ZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFy
aWFsJz5Ob3cgYWxzbyBhc3N1bWUgdGhhdCB0aGUgY29ubmVjdGlvbiBiZXR3ZWVuIHRoZSB0d28g
cHJveGllcw0KaXMgaW5pdGlhdGVkIGJ5IFByb3h5IDEgYW5kIGhhcyB0aGUgZm9sbG93aW5nIDxz
cGFuIGNsYXNzPVNwZWxsRT50dXBsZTwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w
Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5
bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbCc+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBm
YWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJp
YWwnPihJUCBhZGRyZXNzIG9mIFByb3h5IDEsIDUxMjMsIElQIGFkZHJlc3Mgb2YgUHJveHkgMiwg
NTA2MCksPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs
Pjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0K
Zm9udC1mYW1pbHk6QXJpYWwnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoN
CjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBjbGFzcz1HcmFtRT48Zm9udCBzaXplPTIgZmFjZT1B
cmlhbD48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwnPndo
ZXJlPC9zcGFuPjwvZm9udD48L3NwYW4+PGZvbnQNCmZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2Zv
bnQtZmFtaWx5OkFyaWFsJz4gcG9ydCA1MTIzIGlzIHRoZSBlcGhlbWVyYWwgcG9ydCBvbg0KUHJv
eHkxLCBhbmQgcG9ydCA1MDYwIGlzPHNwYW4gc3R5bGU9J21zby1zcGFjZXJ1bjp5ZXMnPiZuYnNw
OyA8L3NwYW4+dGhlIHBvcnQNCnRoYXQgUHJveHkgMiBpcyBsaXN0ZW5pbmcgb24uPG86cD48L286
cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBm
YWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJp
YWwnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05v
cm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw
dDsNCmZvbnQtZmFtaWx5OkFyaWFsJz5OT1cgVEhFIFFVRVNUSU9OPG86cD48L286cD48L3NwYW4+
PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFs
PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPi0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+
DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHls
ZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZh
Y2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlh
bCc+V2hhdCBzaG91bGQgdGhlIFByb3h5IDIgZG8sIGlmIGl0IGRldGVjdHMgdGhhdCB0aGUNCmNv
bm5lY3Rpb24gYmV0d2VlbiBQcm94eSA8c3BhbiBjbGFzcz1HcmFtRT4xLDwvc3Bhbj4gYW5kIFBy
b3h5IDIgaXMgYnJva2VuPyBUaGUNClJvdXRlIHNldCBpcyB0ZWxsaW5nIFByb3h5IDIgdG8gc2Vu
ZCB0aGUgcmVxdWVzdCB0byBwb3J0IDUxMjMgb2YgUHJveHkxLCBidXQgdGhlDQpjb25uZWN0aW9u
IHRvIHRoYXQgcG9ydCBkb2VzIG5vdCBleGlzdC4gSSBkaWQgbm90IGZpbmQgYW55IGRpc2N1c3Np
b24gb2YgdGhpcw0KaW4gdGhlIFNJUCBSRkMuIEkgZGlkIGZpbmQgc29tZXRoaW5nIGluIFNlY3Rp
b24gMTggdGhhdCBhcHBsaWVkIHRvIHJlc3BvbnNlcyBpbg0KdGhlIHNhbWUgdHJhbnNhY3Rpb25z
LCBidXQgSSBhbSBub3Qgc3VyZSBpZiB0aGUgc2FtZSBjYW4gYmUgYXBwbGllZCB0bw0Kc3Vic2Vx
dWVudCByZXF1ZXN0cyB3aXRoaW4gdGhlIHNhbWUgZGlhbG9nLjxvOnA+PC9vOnA+PC9zcGFuPjwv
Zm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48
c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQg
c2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZh
bWlseTpBcmlhbCc+WW91ciBoZWxwIGluIHRoaXMgcmVnYXJkIHdpbGwgYmUgaGlnaGx5IGFwcHJl
Y2lhdGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1h
bD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsN
CmZvbnQtZmFtaWx5OkFyaWFsJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K
DQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9
J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbCc+U2luY2VyZWx5PG86cD48L286
cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBm
YWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJp
YWwnPi0gQWpheTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05v
cm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw
dDsNCmZvbnQtZmFtaWx5OkFyaWFsJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w
Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5
bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbCc+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjwvYm9keT4NCg0KPC9odG1sPg0K

------_=_NextPart_001_01C389E0.2BBE8D36--

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Sun Oct  5 21:49:41 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02333
	for <sip-archive@odin.ietf.org>; Sun, 5 Oct 2003 21:49:41 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A6KUx-0006HJ-2n
	for sip-archive@odin.ietf.org; Sun, 05 Oct 2003 21:49:19 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h961nJWG024075
	for sip-archive@odin.ietf.org; Sun, 5 Oct 2003 21:49:19 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A6KUf-0006Fk-Pq; Sun, 05 Oct 2003 21:49:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A6KUE-0006F8-3x
	for sip@optimus.ietf.org; Sun, 05 Oct 2003 21:48:34 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02322
	for <sip@ietf.org>; Sun, 5 Oct 2003 21:48:25 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A6KUB-0007Oz-00
	for sip@ietf.org; Sun, 05 Oct 2003 21:48:31 -0400
Received: from [211.214.215.200] (helo=elesign-top.elesign.co.kr)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A6KUA-0007OB-00
	for sip@ietf.org; Sun, 05 Oct 2003 21:48:30 -0400
content-class: urn:content-classes:message
Date: Mon, 6 Oct 2003 10:37:07 +0900
Message-ID: <5049A0AA77BCD345951B6AD40FF5C0931F647D@elesign-top.elesign.co.kr>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Thread-Topic: A question about matching request to server transaction.
Thread-Index: AcOLq9MHmg/SfXj2RuWVibDhV5Ndkg==
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
From: "Wook Park" <qpid1011@elesign.com>
To: <sip@ietf.org>
Content-Transfer-Encoding: quoted-printable
Subject: [Sip] A question about matching request to server 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: quoted-printable

Hi all.

I have some questions about matching transaction.
Please let me know the answer.

The following is an paragragh in rfc3261.
->
  The ACK request matches a transaction if the Request-
   URI, From tag, Call-ID, CSeq number (not the method), and top Via
   header field match those of the INVITE request which created the
   transaction, and the To tag of the ACK matches the To tag of the
   response sent by the server transaction.  Matching is done based on
   the matching rules defined for each of those header fields.

I wonder what the meaning "top Via header field match those of the
INVITE" is.
Does it mean that top Via header field should be equal those of the
INVITE?

There is the meaning "equal" in case of via header in rfc3261.
->
 Two Via header fields are equal if their sent-protocol and sent-by
   fields are equal, both have the same set of parameters, and the
   values of all parameters are equal.

However ACK could be sent without passing through proxy. In that case
UAS could receive
different Top Via Header of ACK from those of INVITE.

How does UAS match the ACK to server Transaction in this case?



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Mon Oct  6 07:45:01 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25924
	for <sip-archive@odin.ietf.org>; Mon, 6 Oct 2003 07:45:01 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A6Tn4-0001SL-G9
	for sip-archive@odin.ietf.org; Mon, 06 Oct 2003 07:44:39 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h96Bicr0005593
	for sip-archive@odin.ietf.org; Mon, 6 Oct 2003 07:44:38 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A6TlW-0001Jg-5w; Mon, 06 Oct 2003 07:43:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A6Tl0-0001J7-2Y
	for sip@optimus.ietf.org; Mon, 06 Oct 2003 07:42:30 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25818
	for <sip@ietf.org>; Mon, 6 Oct 2003 07:42:21 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A6Tkz-000415-00
	for sip@ietf.org; Mon, 06 Oct 2003 07:42:29 -0400
Received: from [62.119.82.43] (helo=hotsip.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A6Tky-00040e-00
	for sip@ietf.org; Mon, 06 Oct 2003 07:42:28 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] A question about matching request to server transaction.
Date: Mon, 6 Oct 2003 13:41:51 +0200
Message-ID: <FE03AFC4B33E7447979123987BD65F45141E71@exchange.hotsip.com>
Thread-Topic: [Sip] A question about matching request to server transaction.
Thread-Index: AcOLq9MHmg/SfXj2RuWVibDhV5NdkgAUedlw
From: "Christian Jansson" <christian.jansson@hotsip.com>
To: "Wook Park" <qpid1011@elesign.com>, <sip@ietf.org>
Content-Transfer-Encoding: quoted-printable
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: quoted-printable



> Hi all.
>=20
> I have some questions about matching transaction.
> Please let me know the answer.
>=20
> The following is an paragragh in rfc3261.
> ->
>   The ACK request matches a transaction if the Request-
>    URI, From tag, Call-ID, CSeq number (not the method), and top Via
>    header field match those of the INVITE request which created the
>    transaction, and the To tag of the ACK matches the To tag of the
>    response sent by the server transaction.  Matching is done based on
>    the matching rules defined for each of those header fields.
>=20
> I wonder what the meaning "top Via header field match those=20
> of the INVITE" is. Does it mean that top Via header field=20
> should be equal those of the INVITE?
>=20
> There is the meaning "equal" in case of via header in rfc3261.
> ->
>  Two Via header fields are equal if their sent-protocol and sent-by
>    fields are equal, both have the same set of parameters, and the
>    values of all parameters are equal.
>=20
> However ACK could be sent without passing through proxy. In=20
> that case UAS could receive different Top Via Header of ACK=20
> from those of INVITE.
>=20
> How does UAS match the ACK to server Transaction in this case?

ACK for 2xx is not part of the transaction and should therefore not
match the INVITE.
ACK for 3xx-6xx is part of the INVITE transaction and must have the same
via, and follow
the same path as the INVITE, which will lead to a match.


/ Christian Jansson, Hotsip

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

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Mon Oct  6 09:21:48 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29077
	for <sip-archive@odin.ietf.org>; Mon, 6 Oct 2003 09:21:48 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A6VIf-0005PS-DB
	for sip-archive@odin.ietf.org; Mon, 06 Oct 2003 09:21:27 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h96DLLUQ020793
	for sip-archive@odin.ietf.org; Mon, 6 Oct 2003 09:21:21 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A6VIL-0005Oo-Pf; Mon, 06 Oct 2003 09:21:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A6VHi-0005OH-Ts
	for sip@optimus.ietf.org; Mon, 06 Oct 2003 09:20:22 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28971
	for <sip@ietf.org>; Mon, 6 Oct 2003 09:20:13 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A6VHh-00053X-00
	for sip@ietf.org; Mon, 06 Oct 2003 09:20:21 -0400
Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A6VHg-00053Q-00
	for sip@ietf.org; Mon, 06 Oct 2003 09:20:20 -0400
Received: from Natarajucl1127 (huawei.com [172.17.1.62])
 by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
 2002)) with ESMTPA id <0HMC003KX7MMB7@mta0.huawei.com> for sip@ietf.org; Mon,
 06 Oct 2003 21:18:24 +0800 (CST)
Date: Mon, 06 Oct 2003 18:51:51 +0530
From: "Nataraju A.B." <natarajuab@huawei.com>
Subject: Re: [Sip] ACK retransmission for 2xx
To: Relkem Los <relkem_los@hotmail.com>, sip@ietf.org
Message-id: <019901c38c0c$cee95440$3d02120a@in.huawei.com>
Organization: HTIPL
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
Content-type: multipart/alternative;
 boundary="Boundary_(ID_swn5VA4mQWKvSgO8rS4nWA)"
X-Priority: 3
X-MSMail-priority: Normal
References: <BAY2-F118EXQHuvDr940000699a@hotmail.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>

This is a multi-part message in MIME format.

--Boundary_(ID_swn5VA4mQWKvSgO8rS4nWA)
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7BIT

Regards,
Nataraju A.B.
  ----- Original Message ----- 
  From: Relkem Los 
  To: sip@ietf.org 
  Sent: Thursday, October 02, 2003 12:28 PM
  Subject: [Sip] ACK retransmission for 2xx


  Hi,
  According to RFC3261 "The UAC core MUST generate an ACK request for each 2xx 
  received from the transaction layer" and " Once the ACK has been 
  constructed, the procedures of [4] are used to determine the destination 
  address, port and transport."
  Does this mean that we need to do the DNS procedure for every retransmission 
  of this ACK?
  Can't this cause the ACK to be sent to a different IP and even use a 
  different transport for each retransmission?

  [ABN]

  When UAC receives a 2xx of INVITE it has to generate the ACK response and has to cache that response and retransmitt for all the responses received on that dialog. till the expiration of timer 64*T1. 

  Its better to cache the DNS results and use the same results for each ACK retransmission on that dialog. At this point of time DNS queried on contact address in 2xx. This contact URI is more specific to that UAS than one specified in Req-URI in the initial INVITE. hence it less possible that the ACK reaching different end points. 

  for each 2xx with different tags the above set operations must be repeated ( I assume ). but the what is mentioned in rfc mean that it must be repeated for all the 2xx received (whether retransmitted (same to-tag) OR with a different to-tag ).

  but rfc does not say about DNS results must be cached or not ( It might be an implementation issue ).

  [ABN]

  Thanks.

  _________________________________________________________________
  Add MSN 8 Internet Software to your existing Internet access and enjoy 
  patented spam protection and more.  Sign up now!   
  http://join.msn.com/?page=dept/byoa


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


--Boundary_(ID_swn5VA4mQWKvSgO8rS4nWA)
Content-type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 7BIT

<!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.4134.600" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY style="COLOR: #0000ff; FONT-FAMILY: Verdana" bgColor=#ffffff>
<DIV><STRONG><FONT size=2>Regards,</FONT></STRONG></DIV>
<DIV><STRONG><FONT size=2>Nataraju A.B.</FONT></STRONG></DIV>
<BLOCKQUOTE 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV 
  style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B> 
  <A title=relkem_los@hotmail.com href="mailto:relkem_los@hotmail.com">Relkem 
  Los</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>To:</B> <A title=sip@ietf.org 
  href="mailto:sip@ietf.org">sip@ietf.org</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Sent:</B> Thursday, October 02, 2003 12:28 
  PM</DIV>
  <DIV style="FONT: 10pt arial"><B>Subject:</B> [Sip] ACK retransmission for 
  2xx</DIV>
  <DIV><STRONG><FONT size=2></FONT></STRONG><STRONG><FONT 
  size=2></FONT></STRONG><BR></DIV>
  <DIV>Hi,<BR>According to RFC3261 "The UAC core MUST generate an ACK request 
  for each 2xx <BR>received from the transaction layer" and " Once the ACK has 
  been <BR>constructed, the procedures of [4] are used to determine the 
  destination <BR>address, port and transport."<BR>Does this mean that we need 
  to do the DNS procedure for every retransmission <BR>of this ACK?<BR>Can't 
  this cause the ACK to be sent to a different IP and even use a <BR>different 
  transport for each retransmission?<BR></DIV>
  <DIV><FONT size=2><STRONG><EM>[ABN]</EM></STRONG></FONT></DIV>
  <DIV><STRONG><EM><FONT size=2></FONT></EM></STRONG>&nbsp;</DIV>
  <DIV>When UAC receives a 2xx of INVITE it has to generate the ACK response and 
  has to cache that response and retransmitt for all the responses received on 
  that dialog. till the expiration of timer 64*T1. </DIV>
  <DIV><STRONG><FONT size=2></FONT></STRONG>&nbsp;</DIV>
  <DIV>Its better to cache the DNS results and use the same results for each ACK 
  retransmission on that dialog. At this point of time DNS queried on contact 
  address in 2xx. This contact URI is more specific to that UAS than one 
  specified in Req-URI in the initial INVITE. hence it less possible that the 
  ACK reaching different end points. </DIV>
  <DIV>
  <DIV><STRONG></STRONG>&nbsp;</DIV>
  <DIV>for each 2xx with different tags the above set operations must be 
  repeated ( I assume ). but the what is mentioned in rfc mean that it must be 
  repeated for all the 2xx received (whether retransmitted (same to-tag)&nbsp;OR 
  with a different to-tag ).</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>but rfc does not say about DNS results must be cached or not ( It might 
  be an implementation issue ).</DIV>
  <DIV><STRONG></STRONG>&nbsp;</DIV>
  <DIV><STRONG><FONT size=2><EM>[ABN]</EM></FONT></STRONG></DIV><FONT 
  size=2></FONT><FONT 
  size=2></FONT><BR>Thanks.<BR><BR>_________________________________________________________________<BR>Add 
  MSN 8 Internet Software to your existing Internet access and enjoy 
  <BR>patented spam protection and more.&nbsp; Sign up now!&nbsp;&nbsp; <BR><A 
  href="http://join.msn.com/?page=dept/byoa">http://join.msn.com/?page=dept/byoa</A><BR><BR><BR>_______________________________________________<BR>Sip 
  mailing list&nbsp; <A 
  href="https://www1.ietf.org/mailman/listinfo/sip">https://www1.ietf.org/mailman/listinfo/sip</A><BR>This 
  list is for NEW development of the core SIP Protocol<BR>Use <A 
  href="mailto:sip-implementors@cs.columbia.edu">sip-implementors@cs.columbia.edu</A> 
  for questions on current sip<BR>Use <A 
  href="mailto:sipping@ietf.org">sipping@ietf.org</A> for new developments on 
  the application of sip</DIV></BLOCKQUOTE>
<P></P></BODY></HTML>

--Boundary_(ID_swn5VA4mQWKvSgO8rS4nWA)--

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Mon Oct  6 10:14:37 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02626
	for <sip-archive@odin.ietf.org>; Mon, 6 Oct 2003 10:14:37 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A6W7s-0007sJ-VG
	for sip-archive@odin.ietf.org; Mon, 06 Oct 2003 10:14:17 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h96EEGJs030152
	for sip-archive@odin.ietf.org; Mon, 6 Oct 2003 10:14:16 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A6W7g-0007oa-0d; Mon, 06 Oct 2003 10:14:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A6VW5-0005zR-2i
	for sip@optimus.ietf.org; Mon, 06 Oct 2003 09:35:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29650
	for <sip@ietf.org>; Mon, 6 Oct 2003 09:35:03 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A6VW3-0005FZ-00
	for sip@ietf.org; Mon, 06 Oct 2003 09:35:11 -0400
Received: from mail1.telekom.de ([62.225.183.202])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A6VW2-0005Ep-00
	for sip@ietf.org; Mon, 06 Oct 2003 09:35:10 -0400
Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 6 Oct 2003 15:33:01 +0200
Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <4LDZNDWY>; Mon, 6 Oct 2003 15:33:01 +0200
Message-Id: <32BCBA960C20EB408F4BE7658522620D03439A@G9JJX.mgb01.telekom.de>
From: "Alexeitsev, D" <D.Alexeitsev@t-com.net>
To: Brian.Rosen@marconi.com
Cc: sip@ietf.org
Subject: AW: [Sip] SIPIT Interop problem with ;user=phone
Date: Mon, 6 Oct 2003 15:32:52 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
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: quoted-printable

Hello Brian, All

Thanks a lot for this summary,

Few points/questions that I still have

What is the advantage of having context that is a given URI or set of =
URIs specific if there are already mechanisms in SIP to =
URI-independently address the dialstring analyser using "configurable =
route" procedures?

In my opinion the whole dialstring issue can be solved by the currently =
available mechanisms:

SIP URI has the context definition as it has the mandatory hostportion. =
The problem with the digit analyser not being the outbound proxy is =
solved by the "configurable route" procedures.

What people are seeking is probably the description on how to resolve =
the tel URI in the SIP environment. And this can simply done by putting =
the context in to the hostportion of SIP-URI and the address of =
dialstring analyser in to the Route header (if needed).

Anyway I don't see any need for the tel URIs in the SIP Request-URI due =
to the given conversion simplicity.

The only thing that requires consideration is how and if it is needed =
at all to show that the resolution of dial string to a telephone number =
was done.

Greetings,
Denis Alexeitsev



-----Urspr=FCngliche Nachricht-----
Von: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Gesendet: Freitag, 3. Oktober 2003 14:39
An: Alexeitsev, Denis; sip@ietf.org
Betreff: RE: [Sip] SIPIT Interop problem with ;user=3Dphone


Denis

Most phones today put a dial string in the user part, put their =
outbound=20
proxy in the host part, and set user=3Dphone.  Right now, if you use =
such=20
phones with a proxy server that is a dialstring analyzer, it will work. =
=20
If the first hop proxy is not the dialstring analyzer, it would fail. =20
It would work to change such phones to put a configurable route to =20
dialstring analyzer in the INVITE, but the context makes that =
unnecessary,
as long as you can differentiate dialstrings from phone numbers.  This
thread has had several proposals on how to do that.  Please note that =
there
are phones that do dialstring analysis, and thus it is important for =
any
proxy in the path to know if dialstring analysis has already been
done.

Context is a useful concept, for both dialstrings and phone numbers,=20
because one element may serve as the dialstring analyzer for a variety=20
of environments.  It is common, for example, to have one proxy serve=20
several sites.  Each site may have a somewhat different dial plan. =20
In such a case, you want the dialstring analyzer to know which dial=20
plan is needed.  That is what context does for you.

Finally, the result of dialstring analysis is a phone number, but it =
may
not be an E.164.  It could be a local number -- a 2,3 or 4 digit=20
extension number, for example.

Brian

> -----Original Message-----
> From: Alexeitsev, D [mailto:D.Alexeitsev@t-com.net]
> Sent: Thursday, October 02, 2003 4:35 AM
> To: sip@ietf.org
> Subject: AW: [Sip] SIPIT Interop problem with ;user=3Dphone
>=20
>=20
> Hello All,
>=20
> Sorry if I'm getting too late, still I want add my two cents=20
> on this discussion
>=20
> There are several possibilities how a User Equipment (UE) can=20
> send address information which is particularly true for the=20
> mobile phones. People dial network codes (for example "911")=20
> national number with prefix (for example "01234567899"),=20
> international number with prefix (for example=20
> "00123456789123" or "+123456789123") and so on.
>=20
> I can not imagine that a UE can translate this dial strings=20
> in to E.164 numbers, just because this strings differs around=20
> the world.
>=20
> So the UE just puts the string that a human dialled in to the=20
> Request-URI and now the interesting starts. I don't see the=20
> need of tel URI contexts as applied to the SIP protocol as=20
> there are already several ways in SIP how you can address the=20
> dial string analyser (thus define the context):
>=20
> - address dialstring analyser in the host portion of SIP-URI,=20
> and put the dial string in to userpart
> - address dialstring analyser in the Route: header field and=20
> put dial string in to tel URI
> - address dialstring analyser in the IP header and put dial=20
> string in to tel URI (not recommended behaviour)
>=20
> Note: Don't know why would someone use the last two items as=20
> they are just the separation of the information that can be=20
> put in one place: SIP-URI.
>=20
> By addressing dialstring analyser, one has already defined=20
> the context, so there is no need to put one. No user=3Dphone as=20
> the UE can not do the dialstring-to-E.164 conversion.
>=20
> After dialstring analyser did his job there will be FQe164,=20
> that shall be used in the global Internet. My understanding=20
> was that the dialstring analyser then puts user=3Dphone as the=20
> address information in SIP-URI userpart is FQe164 and it is=20
> formatted according to the RFC 2806.
>=20
> Greetings,
> Denis Alexeitsev
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Mon Oct  6 10:14:37 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02624
	for <sip-archive@odin.ietf.org>; Mon, 6 Oct 2003 10:14:37 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A6W7s-0007sK-VX
	for sip-archive@odin.ietf.org; Mon, 06 Oct 2003 10:14:17 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h96EEGmX030154
	for sip-archive@odin.ietf.org; Mon, 6 Oct 2003 10:14:16 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A6W7e-0007oJ-MK; Mon, 06 Oct 2003 10:14:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A6CgK-0000Ik-G7
	for sip@optimus.ietf.org; Sun, 05 Oct 2003 13:28:32 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20790
	for <sip@ietf.org>; Sun, 5 Oct 2003 13:28:25 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A6CgI-0003jT-00
	for sip@ietf.org; Sun, 05 Oct 2003 13:28:30 -0400
Received: from motgate5.mot.com ([144.189.100.105])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A6CgH-0003jQ-00
	for sip@ietf.org; Sun, 05 Oct 2003 13:28:29 -0400
Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136])
	by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h95HSS5e015661
	for <sip@ietf.org>; Sun, 5 Oct 2003 10:28:28 -0700 (MST)
Received: from il27exm02.cig.mot.com (il27exm02.cig.mot.com [10.17.193.3])
	by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id h95HSQCi024894
	for <sip@ietf.org>; Sun, 5 Oct 2003 12:28:27 -0500
Received: by il27exm02.cig.mot.com with Internet Mail Service (5.5.2657.2)
	id <T7RMH6J5>; Sun, 5 Oct 2003 12:28:21 -0500
Message-ID: <EBF631554F9CD7118D0B00065BF34DCB0E78BF@il27exm03.cig.mot.com>
From: Baniel Uri-CUB001 <Uri.Baniel@motorola.com>
To: Idnani Ajaykumar-AIDNANI1 <Ajaykumar.Idnani@motorola.com>, sip@ietf.org,
        sip-implementors@cs.columbia.edu
Date: Sun, 5 Oct 2003 12:28:46 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.2)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C38B66.2014AABA"
Subject: [Sip] RE: [Sip-implementors] A question about section 12 in RFC 3261.
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_01C38B66.2014AABA
Content-Type: text/plain

Proxy 2 should establish a new TCP connection from an ephemeral port (say 7129) to the listening port of P1 (5060). Section 18 of 3261 does cover that...
 
3261 section 18:
"Note that, because the source port is often ephemeral, but it cannot be known whether it is ephemeral or selected through procedures in [4], connections accepted by the transport layer will frequently not be reused.  The result is that two proxies in a "peering" relationship using a connection-oriented transport frequently will have two connections in use, one for transactions initiated in each direction."
Therefore the rule above was NOT originally intent to responses in the same transactions, but was intent to subsequent requests within the same dialog.
P1 should be able to correlate the incoming messages (either responses or new requests) from P2 on the same dialog based on the SIP fields that are used to identify the dialog (call ID and local/remote tags).
Typically when you establish a TCP connection you are in the mercy of the Operating System wrt to the ephemeral port you would get, and the normal API would not let you re-establish the connection on your listening port. That's the background to section 18 (at least in my understanding)...
 
Uri
================================================================== 
Uri Baniel - Distinguished Member of Technical Staff - Motorola  
Tel: (847) 632 4616; Fax: (847) 632 3963; 
"Learning that does not daily increase will daily decrease. - EWC 
================================================================== 
-----Original Message-----
From: Idnani Ajaykumar-AIDNANI1 [mailto:Ajaykumar.Idnani@motorola.com]
Sent: Friday, October 03, 2003 1:57 PM
To: sip@ietf.org; sip-implementors@cs.columbia.edu
Subject: [Sip-implementors] A question about section 12 in RFC 3261.


All,
 
I had a question about a possible error scenario, that I feel RFC 3261 does not describe. Let me describe the scenario first, and then raise the question. Imagine a scenario where you have two UAa, that are using two different outbound Proxies, that are in a peering relationship i.e. UA1 -> Proxy1 -> Proxy2 -> UA2. Now assume a reliable transport all through. Also assume that a dialog is setup between the two UAs with the following dialog particulars
 
UA1
===
 
local-tag = tag_ua1
remote-tag = tag_ua2
remote-target = sip:UA2@somehost.somedomain.com:6123
Route-set = <sip:proxy1:5123>, <sip:proxy2:5060>
 
UA2
===
 
local-tag = tag_ua2
remote-tag = tag_ua1
remote-target = sip:UA1@someotherhost.somedomain.com:6234
Rooute-set = <sip:proxy2:5060>, <sip:proxy1:5123>
 
In this case the TCP connection between the UA1 and the Proxy1 was initiated by UA1, and has a TCP tuple of 
 
(IP address of someotherhost.somedomain.com, 6234, IP address of Proxy 1, 5060),
 
where port 6234 is the ephemeral port on UA1, and port 5060 is the port that Proxy 1 is listening on.
 
Similarly the TCP connection between the UA2 and Proxy2 was initiated by UA2 and has a TCP tuple of
 
(IP address of somehost.somedomain.com, 6123, IP address of Proxy 2, 5060),
 
where port 6123 is the ephemeral port on UA2, and port 5060 is the port that Proxy 2 is listening on..
 
Now also assume that the connection between the two proxies is initiated by Proxy 1 and has the following tuple
 
(IP address of Proxy 1, 5123, IP address of Proxy 2, 5060),
 
where port 5123 is the ephemeral port on Proxy1, and port 5060 is  the port that Proxy 2 is listening on.
 
NOW THE QUESTION
---------------------------------
 
What should the Proxy 2 do, if it detects that the connection between Proxy 1, and Proxy 2 is broken? The Route set is telling Proxy 2 to send the request to port 5123 of Proxy1, but the connection to that port does not exist. I did not find any discussion of this in the SIP RFC. I did find something in Section 18 that applied to responses in the same transactions, but I am not sure if the same can be applied to subsequent requests within the same dialog.
 
Your help in this regard will be highly appreciated.
 
Sincerely
- Ajay
 
 

------_=_NextPart_001_01C38B66.2014AABA
Content-Type: text/html
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4bWxu
czpvID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4bWxuczp3
ID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCI+PEhFQUQ+DQo8TUVU
QSBIVFRQLUVRVUlWPSJDb250ZW50LVR5cGUiIENPTlRFTlQ9InRleHQvaHRtbDsgY2hhcnNldD1V
Uy1BU0NJSSI+DQoNCg0KPE1FVEEgY29udGVudD1Xb3JkLkRvY3VtZW50IG5hbWU9UHJvZ0lkPg0K
PE1FVEEgY29udGVudD0iTVNIVE1MIDUuNTAuNDcyNS4yMTAwIiBuYW1lPUdFTkVSQVRPUj4NCjxN
RVRBIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEwIiBuYW1lPU9yaWdpbmF0b3I+PExJTksgDQpo
cmVmPSJjaWQ6ZmlsZWxpc3QueG1sQDAxQzM4OUI2LjQ1ODgyN0IwIiByZWw9RmlsZS1MaXN0Pjwh
LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOk9mZmljZURvY3VtZW50U2V0dGluZ3M+DQogIDxv
OkRvTm90UmVseU9uQ1NTLz4NCiA8L286T2ZmaWNlRG9jdW1lbnRTZXR0aW5ncz4NCjwveG1sPjwh
W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDx3OldvcmREb2N1bWVudD4NCiAg
PHc6U3BlbGxpbmdTdGF0ZT5DbGVhbjwvdzpTcGVsbGluZ1N0YXRlPg0KICA8dzpHcmFtbWFyU3Rh
dGU+Q2xlYW48L3c6R3JhbW1hclN0YXRlPg0KICA8dzpEb2N1bWVudEtpbmQ+RG9jdW1lbnRFbWFp
bDwvdzpEb2N1bWVudEtpbmQ+DQogIDx3OkVudmVsb3BlVmlzLz4NCiAgPHc6RGlzcGxheUhvcml6
b250YWxEcmF3aW5nR3JpZEV2ZXJ5PjA8L3c6RGlzcGxheUhvcml6b250YWxEcmF3aW5nR3JpZEV2
ZXJ5Pg0KICA8dzpEaXNwbGF5VmVydGljYWxEcmF3aW5nR3JpZEV2ZXJ5PjA8L3c6RGlzcGxheVZl
cnRpY2FsRHJhd2luZ0dyaWRFdmVyeT4NCiAgPHc6VXNlTWFyZ2luc0ZvckRyYXdpbmdHcmlkT3Jp
Z2luLz4NCiAgPHc6Q29tcGF0aWJpbGl0eT4NCiAgIDx3OkZvb3Rub3RlTGF5b3V0TGlrZVdXOC8+
DQogICA8dzpTaGFwZUxheW91dExpa2VXVzgvPg0KICAgPHc6QWxpZ25UYWJsZXNSb3dCeVJvdy8+
DQogICA8dzpGb3JnZXRMYXN0VGFiQWxpZ25tZW50Lz4NCiAgIDx3OkRvTm90VXNlSFRNTFBhcmFn
cmFwaEF1dG9TcGFjaW5nLz4NCiAgIDx3OkxheW91dFJhd1RhYmxlV2lkdGgvPg0KICAgPHc6TGF5
b3V0VGFibGVSb3dzQXBhcnQvPg0KICAgPHc6VXNlV29yZDk3TGluZUJyZWFraW5nUnVsZXMvPg0K
ICA8L3c6Q29tcGF0aWJpbGl0eT4NCiAgPHc6QnJvd3NlckxldmVsPk1pY3Jvc29mdEludGVybmV0
RXhwbG9yZXI0PC93OkJyb3dzZXJMZXZlbD4NCiA8L3c6V29yZERvY3VtZW50Pg0KPC94bWw+PCFb
ZW5kaWZdLS0+DQo8U1RZTEU+QHBhZ2UgU2VjdGlvbjEge3NpemU6IDguNWluIDExLjBpbjsgbWFy
Z2luOiAxLjBpbiAxLjI1aW4gMS4waW4gMS4yNWluOyBtc28taGVhZGVyLW1hcmdpbjogLjVpbjsg
bXNvLWZvb3Rlci1tYXJnaW46IC41aW47IG1zby1wYXBlci1zb3VyY2U6IDA7IH0NClAuTXNvTm9y
bWFsIHsNCglGT05ULVNJWkU6IDEwcHQ7IE1BUkdJTjogMGluIDBpbiAwcHQ7IEZPTlQtRkFNSUxZ
OiAiVGltZXMgTmV3IFJvbWFuIjsgbXNvLXN0eWxlLXBhcmVudDogIiI7IG1zby1wYWdpbmF0aW9u
OiB3aWRvdy1vcnBoYW47IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAiVGltZXMgTmV3IFJvbWFu
Ig0KfQ0KTEkuTXNvTm9ybWFsIHsNCglGT05ULVNJWkU6IDEwcHQ7IE1BUkdJTjogMGluIDBpbiAw
cHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgbXNvLXN0eWxlLXBhcmVudDogIiI7
IG1zby1wYWdpbmF0aW9uOiB3aWRvdy1vcnBoYW47IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAi
VGltZXMgTmV3IFJvbWFuIg0KfQ0KRElWLk1zb05vcm1hbCB7DQoJRk9OVC1TSVpFOiAxMHB0OyBN
QVJHSU46IDBpbiAwaW4gMHB0OyBGT05ULUZBTUlMWTogIlRpbWVzIE5ldyBSb21hbiI7IG1zby1z
dHlsZS1wYXJlbnQ6ICIiOyBtc28tcGFnaW5hdGlvbjogd2lkb3ctb3JwaGFuOyBtc28tZmFyZWFz
dC1mb250LWZhbWlseTogIlRpbWVzIE5ldyBSb21hbiINCn0NCkE6bGluayB7DQoJQ09MT1I6IGJs
dWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lOyB0ZXh0LXVuZGVybGluZTogc2luZ2xlDQp9
DQpTUEFOLk1zb0h5cGVybGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5k
ZXJsaW5lOyB0ZXh0LXVuZGVybGluZTogc2luZ2xlDQp9DQpBOnZpc2l0ZWQgew0KCUNPTE9SOiBw
dXJwbGU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lOyB0ZXh0LXVuZGVybGluZTogc2luZ2xl
DQp9DQpTUEFOLk1zb0h5cGVybGlua0ZvbGxvd2VkIHsNCglDT0xPUjogcHVycGxlOyBURVhULURF
Q09SQVRJT046IHVuZGVybGluZTsgdGV4dC11bmRlcmxpbmU6IHNpbmdsZQ0KfQ0KU1BBTi5FbWFp
bFN0eWxlMTcgew0KCUNPTE9SOiB3aW5kb3d0ZXh0OyBGT05ULUZBTUlMWTogQXJpYWw7IG1zby1z
dHlsZS10eXBlOiBwZXJzb25hbC1jb21wb3NlOyBtc28tc3R5bGUtbm9zaG93OiB5ZXM7IG1zby1h
bnNpLWZvbnQtc2l6ZTogMTAuMHB0OyBtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdDsgbXNvLWFz
Y2lpLWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNv
LWJpZGktZm9udC1mYW1pbHk6IEFyaWFsDQp9DQpTUEFOLlNwZWxsRSB7DQoJbXNvLXN0eWxlLW5h
bWU6ICIiOyBtc28tc3BsLWU6IHllcw0KfQ0KU1BBTi5HcmFtRSB7DQoJbXNvLXN0eWxlLW5hbWU6
ICIiOyBtc28tZ3JhbS1lOiB5ZXMNCn0NCkRJVi5TZWN0aW9uMSB7DQoJcGFnZTogU2VjdGlvbjEN
Cn0NCjwvU1RZTEU+DQo8IS0tW2lmIGd0ZSBtc28gMTBdPg0KPHN0eWxlPg0KIC8qIFN0eWxlIERl
ZmluaXRpb25zICovIA0KIHRhYmxlLk1zb05vcm1hbFRhYmxlDQoJe21zby1zdHlsZS1uYW1lOiJU
YWJsZSBOb3JtYWwiOw0KCW1zby10c3R5bGUtcm93YmFuZC1zaXplOjA7DQoJbXNvLXRzdHlsZS1j
b2xiYW5kLXNpemU6MDsNCgltc28tc3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtcGFyZW50
OiIiOw0KCW1zby1wYWRkaW5nLWFsdDowaW4gNS40cHQgMGluIDUuNHB0Ow0KCW1zby1wYXJhLW1h
cmdpbjowaW47DQoJbXNvLXBhcmEtbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCW1zby1wYWdpbmF0
aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l
cyBOZXcgUm9tYW4iO30NCjwvc3R5bGU+DQo8IVtlbmRpZl0tLT48L0hFQUQ+DQo8Qk9EWSBsYW5n
PUVOLVVTIHN0eWxlPSJ0YWItaW50ZXJ2YWw6IC41aW4iIHZMaW5rPXB1cnBsZSBsaW5rPWJsdWU+
DQo8RElWPjxTUEFOIGNsYXNzPTg4MjU4MDYxNy0wNTEwMjAwMz48Rk9OVCBmYWNlPUFyaWFsIGNv
bG9yPSMwMDAwZmYgc2l6ZT0yPlByb3h5IA0KMiBzaG91bGQgZXN0YWJsaXNoIGEgbmV3IFRDUCBj
b25uZWN0aW9uIGZyb20gYW4gZXBoZW1lcmFsIHBvcnQgKHNheSA3MTI5KSB0byB0aGUgDQpsaXN0
ZW5pbmcgcG9ydCBvZiBQMSAoNTA2MCkuIFNlY3Rpb24gMTggb2YgMzI2MSBkb2VzIGNvdmVyIA0K
dGhhdC4uLjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48U1BB
TiBjbGFzcz04ODI1ODA2MTctMDUxMDIwMDM+MzI2MSBzZWN0aW9uIDE4OjwvU1BBTj48L0RJVj4N
CjxQIGNsYXNzPU1zb1BsYWluVGV4dD48U1BBTiBzdHlsZT0ibXNvLWZhcmVhc3QtZm9udC1mYW1p
bHk6ICdNUyBNaW5jaG8nIj48U1BBTiANCmNsYXNzPTg4MjU4MDYxNy0wNTEwMjAwMz4iPC9TUEFO
Pk5vdGUgdGhhdCwgYmVjYXVzZSB0aGUgc291cmNlPFNQQU4gDQpjbGFzcz04ODI1ODA2MTctMDUx
MDIwMDM+IDwvU1BBTj48L1NQQU4+PFNQQU4gDQpzdHlsZT0ibXNvLWZhcmVhc3QtZm9udC1mYW1p
bHk6ICdNUyBNaW5jaG8nIj5wb3J0IGlzIG9mdGVuIGVwaGVtZXJhbCwgYnV0IGl0IA0KY2Fubm90
IGJlIGtub3duIHdoZXRoZXIgaXQgaXM8U1BBTiBjbGFzcz04ODI1ODA2MTctMDUxMDIwMDM+IDwv
U1BBTj48L1NQQU4+PFNQQU4gDQpzdHlsZT0ibXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICdNUyBN
aW5jaG8nIj5lcGhlbWVyYWwgb3Igc2VsZWN0ZWQgdGhyb3VnaCANCnByb2NlZHVyZXMgaW4gWzRd
LCBjb25uZWN0aW9ucyBhY2NlcHRlZDxTUEFOIGNsYXNzPTg4MjU4MDYxNy0wNTEwMjAwMz4gDQo8
L1NQQU4+PC9TUEFOPjxTUEFOIHN0eWxlPSJtc28tZmFyZWFzdC1mb250LWZhbWlseTogJ01TIE1p
bmNobyciPmJ5IHRoZSANCnRyYW5zcG9ydCBsYXllciB3aWxsIGZyZXF1ZW50bHkgPFNUUk9ORz5u
b3Q8L1NUUk9ORz4gYmUgcmV1c2VkLjxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4m
bmJzcDsgPC9TUEFOPlRoZSByZXN1bHQgaXM8U1BBTiANCmNsYXNzPTg4MjU4MDYxNy0wNTEwMjAw
Mz4gPC9TUEFOPjwvU1BBTj48U1BBTiANCnN0eWxlPSJtc28tZmFyZWFzdC1mb250LWZhbWlseTog
J01TIE1pbmNobyciPnRoYXQgdHdvIHByb3hpZXMgaW4gYSAicGVlcmluZyIgDQpyZWxhdGlvbnNo
aXAgdXNpbmcgYSBjb25uZWN0aW9uLTwvU1BBTj48U1BBTiANCnN0eWxlPSJtc28tZmFyZWFzdC1m
b250LWZhbWlseTogJ01TIE1pbmNobyciPm9yaWVudGVkJm5ic3A7PFNQQU4gDQpjbGFzcz04ODI1
ODA2MTctMDUxMDIwMDM+dDwvU1BBTj5yYW5zcG9ydCBmcmVxdWVudGx5IHdpbGwgaGF2ZSB0d28g
Y29ubmVjdGlvbnMgDQppbiB1c2UsIG9uZTxTUEFOIGNsYXNzPTg4MjU4MDYxNy0wNTEwMjAwMz4g
PC9TUEFOPjwvU1BBTj48U1BBTiANCnN0eWxlPSJtc28tZmFyZWFzdC1mb250LWZhbWlseTogJ01T
IE1pbmNobyciPmZvciA8U1RST05HPnRyYW5zYWN0aW9ucyANCmluaXRpYXRlZDwvU1RST05HPiBp
biBlYWNoIGRpcmVjdGlvbi48U1BBTiANCmNsYXNzPTg4MjU4MDYxNy0wNTEwMjAwMz4iPC9TUEFO
PjwvU1BBTj48L1A+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgc2l6ZT0yPjxTUEFOIGNs
YXNzPTg4MjU4MDYxNy0wNTEwMjAwMz5UaGVyZWZvcmUgdGhlIA0KcnVsZSBhYm92ZSZuYnNwO3dh
cyBOT1QmbmJzcDtvcmlnaW5hbGx5IGludGVudDwvU1BBTj4gdG8gcmVzcG9uc2VzIGluIHRoZSBz
YW1lIA0KdHJhbnNhY3Rpb25zLCBidXQmbmJzcDs8U1BBTiBjbGFzcz04ODI1ODA2MTctMDUxMDIw
MDM+d2FzIGludGVudDwvU1BBTj4mbmJzcDt0byANCnN1YnNlcXVlbnQgcmVxdWVzdHMgd2l0aGlu
IHRoZSBzYW1lIGRpYWxvZy48L0ZPTlQ+PC9GT05UPjwvRElWPg0KPERJVj48U1BBTiBjbGFzcz04
ODI1ODA2MTctMDUxMDIwMDM+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+UDEgc2hvdWxkIGJlIGFi
bGUgdG8gDQpjb3JyZWxhdGUgdGhlIGluY29taW5nIG1lc3NhZ2VzIChlaXRoZXIgcmVzcG9uc2Vz
IG9yIG5ldyByZXF1ZXN0cykmbmJzcDtmcm9tIFAyIA0Kb24gdGhlIHNhbWUgZGlhbG9nIGJhc2Vk
IG9uIHRoZSBTSVAgZmllbGRzIHRoYXQgYXJlIHVzZWQgdG8gaWRlbnRpZnkgdGhlIGRpYWxvZyAN
CihjYWxsIElEIGFuZCBsb2NhbC9yZW1vdGUgdGFncykuPC9GT05UPjwvU1BBTj48L0RJVj4NCjxE
SVY+PFNQQU4gY2xhc3M9ODgyNTgwNjE3LTA1MTAyMDAzPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0y
PlR5cGljYWxseSB3aGVuIHlvdSANCmVzdGFibGlzaCBhIFRDUCBjb25uZWN0aW9uIHlvdSBhcmUg
aW4gdGhlIG1lcmN5IG9mIHRoZSBPcGVyYXRpbmcgU3lzdGVtIHdydCB0byANCnRoZSBlcGhlbWVy
YWwgcG9ydCB5b3Ugd291bGQgZ2V0LCBhbmQgdGhlIG5vcm1hbCBBUEkgd291bGQgbm90IGxldCB5
b3UgDQpyZS1lc3RhYmxpc2ggdGhlIGNvbm5lY3Rpb24gb24geW91ciBsaXN0ZW5pbmcgcG9ydC4g
VGhhdCdzIHRoZSBiYWNrZ3JvdW5kIHRvIA0Kc2VjdGlvbiAxOCAoYXQgbGVhc3QgaW4gbXkgdW5k
ZXJzdGFuZGluZykuLi48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBjbGFzcz04ODI1
ODA2MTctMDUxMDIwMDM+PEZPTlQgZmFjZT1BcmlhbCANCnNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZu
YnNwOzwvRElWPg0KPERJVj48U1BBTiBjbGFzcz04ODI1ODA2MTctMDUxMDIwMDM+PEZPTlQgZmFj
ZT1BcmlhbCANCnNpemU9Mj5Vcmk8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPFA+PEZPTlQgZmFjZT0i
Q291cmllciBOZXciIA0Kc2l6ZT0yPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvRk9OVD4gDQo8QlI+PEZPTlQgZmFjZT0i
Q291cmllciBOZXciIHNpemU9Mj5VcmkgQmFuaWVsIC0gRGlzdGluZ3Vpc2hlZCBNZW1iZXIgb2Yg
DQpUZWNobmljYWwgU3RhZmYgLSBNb3Rvcm9sYSZuYnNwOyA8L0ZPTlQ+PEJSPjxGT05UIGZhY2U9
IkNvdXJpZXIgTmV3IiBzaXplPTI+VGVsOiANCig4NDcpIDYzMiA0NjE2OyBGYXg6ICg4NDcpIDYz
MiAzOTYzOyA8L0ZPTlQ+PEJSPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiANCnNpemU9Mj4iTGVh
cm5pbmcgdGhhdCBkb2VzIG5vdCBkYWlseSBpbmNyZWFzZSB3aWxsIGRhaWx5IGRlY3JlYXNlLiAt
IEVXQzwvRk9OVD4gDQo8QlI+PEZPTlQgZmFjZT0iQ291cmllciBOZXciIA0Kc2l6ZT0yPj09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PTwvRk9OVD4gDQo8L1A+DQo8QkxPQ0tRVU9URSBkaXI9bHRyIHN0eWxlPSJNQVJHSU4tUklH
SFQ6IDBweCI+DQogIDxESVYgY2xhc3M9T3V0bG9va01lc3NhZ2VIZWFkZXIgZGlyPWx0ciBhbGln
bj1sZWZ0PjxGT05UIGZhY2U9VGFob21hIA0KICBzaXplPTI+LS0tLS1PcmlnaW5hbCBNZXNzYWdl
LS0tLS08QlI+PEI+RnJvbTo8L0I+IElkbmFuaSBBamF5a3VtYXItQUlETkFOSTEgDQogIFttYWls
dG86QWpheWt1bWFyLklkbmFuaUBtb3Rvcm9sYS5jb21dPEJSPjxCPlNlbnQ6PC9CPiBGcmlkYXks
IE9jdG9iZXIgMDMsIA0KICAyMDAzIDE6NTcgUE08QlI+PEI+VG86PC9CPiBzaXBAaWV0Zi5vcmc7
IA0KICBzaXAtaW1wbGVtZW50b3JzQGNzLmNvbHVtYmlhLmVkdTxCUj48Qj5TdWJqZWN0OjwvQj4g
W1NpcC1pbXBsZW1lbnRvcnNdIEEgDQogIHF1ZXN0aW9uIGFib3V0IHNlY3Rpb24gMTIgaW4gUkZD
IDMyNjEuPEJSPjxCUj48L0ZPTlQ+PC9ESVY+DQogIDxESVYgY2xhc3M9U2VjdGlvbjE+DQogIDxQ
IGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCiAgc3R5bGU9
IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsIj5BbGwsPG86cD48L286cD48L1NQ
QU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgc2l6
ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogQXJpYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1h
bD48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBw
dDsgRk9OVC1GQU1JTFk6IEFyaWFsIj5JIGhhZCBhIHF1ZXN0aW9uIGFib3V0IGEgcG9zc2libGUg
DQogIGVycm9yIDxTUEFOIGNsYXNzPUdyYW1FPnNjZW5hcmlvLCB0aGF0PC9TUEFOPiBJIGZlZWwg
UkZDIDMyNjEgZG9lcyBub3QgDQogIGRlc2NyaWJlLiBMZXQgbWUgZGVzY3JpYmUgdGhlIHNjZW5h
cmlvIGZpcnN0LCBhbmQgdGhlbiByYWlzZSB0aGUgcXVlc3Rpb24uIA0KICBJbWFnaW5lIGEgc2Nl
bmFyaW8gd2hlcmUgeW91IGhhdmUgdHdvIDxTUEFOIGNsYXNzPVNwZWxsRT5VQWE8L1NQQU4+LCB0
aGF0IGFyZSANCiAgdXNpbmcgdHdvIGRpZmZlcmVudCBvdXRib3VuZCBQcm94aWVzLCB0aGF0IGFy
ZSBpbiBhIHBlZXJpbmcgcmVsYXRpb25zaGlwIGkuZS4gDQogIFVBMSAtJmd0OyBQcm94eTEgLSZn
dDsgUHJveHkyIC0mZ3Q7IFVBMi4gTm93IGFzc3VtZSBhIHJlbGlhYmxlIHRyYW5zcG9ydCBhbGwg
DQogIHRocm91Z2guIEFsc28gYXNzdW1lIHRoYXQgYSBkaWFsb2cgaXMgc2V0dXAgYmV0d2VlbiB0
aGUgdHdvIDxTUEFOIA0KICBjbGFzcz1TcGVsbEU+VUFzPC9TUEFOPiB3aXRoIHRoZSBmb2xsb3dp
bmcgZGlhbG9nIA0KICBwYXJ0aWN1bGFyczxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQog
IDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCiAgc3R5
bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1Bcmlh
bCBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBB
cmlhbCI+VUExPG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9y
bWFsPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAx
MHB0OyBGT05ULUZBTUlMWTogQXJpYWwiPj09PTxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+
DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCiAg
c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gY2xhc3M9
R3JhbUU+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6
IDEwcHQ7IEZPTlQtRkFNSUxZOiBBcmlhbCI+bG9jYWwtdGFnPC9TUEFOPjwvRk9OVD48L1NQQU4+
PEZPTlQgDQogIGZhY2U9QXJpYWw+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCI+ID0g
DQogIHRhZ191YTE8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29O
b3JtYWw+PFNQQU4gY2xhc3M9R3JhbUU+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQog
IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBBcmlhbCI+cmVtb3RlLXRhZzwv
U1BBTj48L0ZPTlQ+PC9TUEFOPjxGT05UIA0KICBmYWNlPUFyaWFsPjxTUEFOIHN0eWxlPSJGT05U
LUZBTUlMWTogQXJpYWwiPiA9IA0KICB0YWdfdWEyPG86cD48L286cD48L1NQQU4+PC9GT05UPjwv
UD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGNsYXNzPUdyYW1FPjxGT05UIGZhY2U9QXJp
YWwgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTog
QXJpYWwiPnJlbW90ZS10YXJnZXQ8L1NQQU4+PC9GT05UPjwvU1BBTj48Rk9OVCANCiAgZmFjZT1B
cmlhbD48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6IEFyaWFsIj4gPSANCiAgc2lwOlVBMkBzb21l
aG9zdC5zb21lZG9tYWluLmNvbTo2MTIzPG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAg
PFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KICBzdHls
ZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogQXJpYWwiPlJvdXRlLXNldCA9ICZsdDtz
aXA8U1BBTiANCiAgY2xhc3M9R3JhbUU+OnByb3h5MTo1MTIzPC9TUEFOPiZndDssIA0KICAmbHQ7
c2lwOnByb3h5Mjo1MDYwJmd0OzxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNs
YXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZP
TlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvU1BB
Tj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBzaXpl
PTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBBcmlhbCI+
VUEyPG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxG
T05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBG
T05ULUZBTUlMWTogQXJpYWwiPj09PTxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQ
IGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCiAgc3R5bGU9
IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
U1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gY2xhc3M9R3JhbUU+
PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7
IEZPTlQtRkFNSUxZOiBBcmlhbCI+bG9jYWwtdGFnPC9TUEFOPjwvRk9OVD48L1NQQU4+PEZPTlQg
DQogIGZhY2U9QXJpYWw+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCI+ID0gDQogIHRh
Z191YTI8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+
PFNQQU4gY2xhc3M9R3JhbUU+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQogIHN0eWxl
PSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBBcmlhbCI+cmVtb3RlLXRhZzwvU1BBTj48
L0ZPTlQ+PC9TUEFOPjxGT05UIA0KICBmYWNlPUFyaWFsPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlM
WTogQXJpYWwiPiA9IA0KICB0YWdfdWExPG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAg
PFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGNsYXNzPUdyYW1FPjxGT05UIGZhY2U9QXJpYWwgc2l6
ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogQXJpYWwi
PnJlbW90ZS10YXJnZXQ8L1NQQU4+PC9GT05UPjwvU1BBTj48Rk9OVCANCiAgZmFjZT1BcmlhbD48
U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6IEFyaWFsIj4gPSANCiAgc2lwOlVBMUBzb21lb3RoZXJo
b3N0LnNvbWVkb21haW4uY29tOjYyMzQ8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8
UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gY2xhc3M9U3BlbGxFPjxGT05UIGZhY2U9QXJpYWwgc2l6
ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogQXJpYWwi
PlJvb3V0ZTwvU1BBTj48L0ZPTlQ+PC9TUEFOPjxGT05UIA0KICBmYWNlPUFyaWFsPjxTUEFOIHN0
eWxlPSJGT05ULUZBTUlMWTogQXJpYWwiPi1zZXQgPSAmbHQ7c2lwPFNQQU4gDQogIGNsYXNzPUdy
YW1FPjpwcm94eTI6NTA2MDwvU1BBTj4mZ3Q7LCANCiAgJmx0O3NpcDpwcm94eTE6NTEyMyZndDs8
bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQg
ZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQt
RkFNSUxZOiBBcmlhbCI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAg
Y2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0i
Rk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogQXJpYWwiPkluIHRoaXMgY2FzZSB0aGUgVENQ
IGNvbm5lY3Rpb24gDQogIGJldHdlZW4gdGhlIFVBMSBhbmQgdGhlIFByb3h5MSB3YXMgaW5pdGlh
dGVkIGJ5IFVBMSwgYW5kIGhhcyBhIFRDUCA8U1BBTiANCiAgY2xhc3M9U3BlbGxFPnR1cGxlPC9T
UEFOPiBvZiA8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3Jt
YWw+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEw
cHQ7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9GT05UPjwv
UD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0K
ICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogQXJpYWwiPihJUCBhZGRyZXNz
IG9mIA0KICBzb21lb3RoZXJob3N0LnNvbWVkb21haW4uY29tLCA2MjM0LCBJUCBhZGRyZXNzIG9m
IFByb3h5IDEsIA0KICA1MDYwKSw8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBj
bGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJG
T05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PG86cD4mbmJzcDs8L286cD48L1NQ
QU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGNsYXNzPUdyYW1FPjxG
T05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBG
T05ULUZBTUlMWTogQXJpYWwiPndoZXJlPC9TUEFOPjwvRk9OVD48L1NQQU4+PEZPTlQgDQogIGZh
Y2U9QXJpYWw+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCI+IHBvcnQgNjIzNCBpcyB0
aGUgZXBoZW1lcmFsIHBvcnQgDQogIG9uIFVBMSwgYW5kIHBvcnQgNTA2MCBpcyB0aGUgcG9ydCB0
aGF0IFByb3h5IDEgaXMgbGlzdGVuaW5nIA0KICBvbi48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+
PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4g
DQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PG86cD4mbmJz
cDs8L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZh
Y2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZB
TUlMWTogQXJpYWwiPlNpbWlsYXJseSB0aGUgVENQIGNvbm5lY3Rpb24gDQogIGJldHdlZW4gdGhl
IFVBMiBhbmQgUHJveHkyIHdhcyBpbml0aWF0ZWQgYnkgVUEyIGFuZCBoYXMgYSBUQ1AgPFNQQU4g
DQogIGNsYXNzPVNwZWxsRT50dXBsZTwvU1BBTj4gb2Y8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+
PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4g
DQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PG86cD4mbmJz
cDs8L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZh
Y2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZB
TUlMWTogQXJpYWwiPihJUCBhZGRyZXNzIG9mIA0KICBzb21laG9zdC5zb21lZG9tYWluLmNvbSwg
NjEyMywgSVAgYWRkcmVzcyBvZiBQcm94eSAyLCANCiAgNTA2MCksPG86cD48L286cD48L1NQQU4+
PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0y
PjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogQXJpYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48
U1BBTiBjbGFzcz1HcmFtRT48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCiAgc3R5bGU9
IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsIj53aGVyZTwvU1BBTj48L0ZPTlQ+
PC9TUEFOPjxGT05UIA0KICBmYWNlPUFyaWFsPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogQXJp
YWwiPiBwb3J0IDYxMjMgaXMgdGhlIGVwaGVtZXJhbCBwb3J0IA0KICBvbiBVQTIsIGFuZCBwb3J0
IDUwNjAgaXMgdGhlIHBvcnQgdGhhdCBQcm94eSAyIGlzIGxpc3RlbmluZyANCiAgb24uLjxvOnA+
PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNl
PUFyaWFsIHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1J
TFk6IEFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFz
cz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05U
LVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBBcmlhbCI+Tm93IGFsc28gYXNzdW1lIHRoYXQgdGhl
IA0KICBjb25uZWN0aW9uIGJldHdlZW4gdGhlIHR3byBwcm94aWVzIGlzIGluaXRpYXRlZCBieSBQ
cm94eSAxIGFuZCBoYXMgdGhlIA0KICBmb2xsb3dpbmcgPFNQQU4gY2xhc3M9U3BlbGxFPnR1cGxl
PC9TUEFOPjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1h
bD48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBw
dDsgRk9OVC1GQU1JTFk6IEFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9Q
Pg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQog
IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBBcmlhbCI+KElQIGFkZHJlc3Mg
b2YgUHJveHkgMSwgNTEyMywgSVAgDQogIGFkZHJlc3Mgb2YgUHJveHkgMiwgNTA2MCksPG86cD48
L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9
QXJpYWwgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlM
WTogQXJpYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNz
PU1zb05vcm1hbD48U1BBTiBjbGFzcz1HcmFtRT48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BB
TiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsIj53aGVyZTwv
U1BBTj48L0ZPTlQ+PC9TUEFOPjxGT05UIA0KICBmYWNlPUFyaWFsPjxTUEFOIHN0eWxlPSJGT05U
LUZBTUlMWTogQXJpYWwiPiBwb3J0IDUxMjMgaXMgdGhlIGVwaGVtZXJhbCBwb3J0IA0KICBvbiBQ
cm94eTEsIGFuZCBwb3J0IDUwNjAgaXM8U1BBTiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZu
YnNwOyA8L1NQQU4+dGhlIA0KICBwb3J0IHRoYXQgUHJveHkgMiBpcyBsaXN0ZW5pbmcgb24uPG86
cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZh
Y2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZB
TUlMWTogQXJpYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNs
YXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZP
TlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsIj5OT1cgVEhFIA0KICBRVUVTVElPTjxv
OnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBm
YWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1G
QU1JTFk6IEFyaWFsIj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpw
PjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1Bcmlh
bCBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBB
cmlhbCI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNv
Tm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpF
OiAxMHB0OyBGT05ULUZBTUlMWTogQXJpYWwiPldoYXQgc2hvdWxkIHRoZSBQcm94eSAyIGRvLCBp
ZiBpdCANCiAgZGV0ZWN0cyB0aGF0IHRoZSBjb25uZWN0aW9uIGJldHdlZW4gUHJveHkgPFNQQU4g
Y2xhc3M9R3JhbUU+MSw8L1NQQU4+IGFuZCANCiAgUHJveHkgMiBpcyBicm9rZW4/IFRoZSBSb3V0
ZSBzZXQgaXMgdGVsbGluZyBQcm94eSAyIHRvIHNlbmQgdGhlIHJlcXVlc3QgdG8gDQogIHBvcnQg
NTEyMyBvZiBQcm94eTEsIGJ1dCB0aGUgY29ubmVjdGlvbiB0byB0aGF0IHBvcnQgZG9lcyBub3Qg
ZXhpc3QuIEkgZGlkIG5vdCANCiAgZmluZCBhbnkgZGlzY3Vzc2lvbiBvZiB0aGlzIGluIHRoZSBT
SVAgUkZDLiBJIGRpZCBmaW5kIHNvbWV0aGluZyBpbiBTZWN0aW9uIDE4IA0KICB0aGF0IGFwcGxp
ZWQgdG8gcmVzcG9uc2VzIGluIHRoZSBzYW1lIHRyYW5zYWN0aW9ucywgYnV0IEkgYW0gbm90IHN1
cmUgaWYgdGhlIA0KICBzYW1lIGNhbiBiZSBhcHBsaWVkIHRvIHN1YnNlcXVlbnQgcmVxdWVzdHMg
d2l0aGluIHRoZSBzYW1lIA0KICBkaWFsb2cuPG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4N
CiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KICBz
dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogQXJpYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFy
aWFsIHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6
IEFyaWFsIj5Zb3VyIGhlbHAgaW4gdGhpcyByZWdhcmQgd2lsbCBiZSANCiAgaGlnaGx5IGFwcHJl
Y2lhdGVkLjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1h
bD48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBw
dDsgRk9OVC1GQU1JTFk6IEFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9Q
Pg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQog
IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBBcmlhbCI+U2luY2VyZWx5PG86
cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZh
Y2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZB
TUlMWTogQXJpYWwiPi0gDQpBamF5PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAg
Y2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0i
Rk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogQXJpYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9T
UEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIHNp
emU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPjwvQkxPQ0tRVU9URT48
L0JPRFk+PC9IVE1MPg0K

------_=_NextPart_001_01C38B66.2014AABA--

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Tue Oct  7 20:14:35 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28858
	for <sip-archive@odin.ietf.org>; Tue, 7 Oct 2003 20:14:34 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A71y1-0007wz-3Q
	for sip-archive@odin.ietf.org; Tue, 07 Oct 2003 20:14:13 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h980EDVo030504
	for sip-archive@odin.ietf.org; Tue, 7 Oct 2003 20:14:13 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A71xq-0007vK-0u; Tue, 07 Oct 2003 20:14:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A71x8-0007up-1l
	for sip@optimus.ietf.org; Tue, 07 Oct 2003 20:13:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28830
	for <sip@ietf.org>; Tue, 7 Oct 2003 20:13:09 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A71x5-0005f8-00
	for sip@ietf.org; Tue, 07 Oct 2003 20:13:15 -0400
Received: from mail.telverse.com ([4.43.0.5] helo=dc1.telverse.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A71x5-0005dw-00
	for sip@ietf.org; Tue, 07 Oct 2003 20:13:15 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 7 Oct 2003 17:12:44 -0700
Message-ID: <F96BD6D84E58C849A82C730906178517015BF387@dc1.telverse.com>
Thread-Topic: Event Based Heart Beat in SIP
Thread-Index: AcONMOWnwhZWyG2OSpuMPLKANFoOvg==
From: "Samir Srivastava" <ssrivastava@telverse.com>
To: <sip@ietf.org>
Content-Transfer-Encoding: quoted-printable
Subject: [Sip] Event Based Heart Beat in 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>
Content-Transfer-Encoding: quoted-printable

Hi,

The current standard provides OPTIONS to find the liveness of remote SIP
endpoint.
If remote SIP server is not able to response back for the OPTIONS for a
long time,
it results in bunch of OPTIONS requests in the network. There is no
standard
event defined which tells the availability of remote SIP endpoint.=20

Consider SIP endpoints A (local) wants to find out the availabilty of
B(remote).
A subsribes event "READY_TO_PROCESS"  to B, when B is ready to process=20
SIP reqs.  The subscribers of event needs to stored persistenly. As soon
as SIP=20
server is ready for signal processing, it will send the NOTIFY
indicating its
availability. This eliminates the OPTIONS REQs when remote endpoint is
not
available for checking liveness ?=20

Other events can be also added, like update the availability when there
is
no SIP traffic.

Whether checking liveness based on the events was considered earlier ?

Thx
Samir

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Tue Oct  7 20:49:30 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29811
	for <sip-archive@odin.ietf.org>; Tue, 7 Oct 2003 20:49:30 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A72Vp-0001Aa-JV
	for sip-archive@odin.ietf.org; Tue, 07 Oct 2003 20:49:09 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h980n9aJ004497
	for sip-archive@odin.ietf.org; Tue, 7 Oct 2003 20:49:09 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A72Vi-00019n-PT; Tue, 07 Oct 2003 20:49:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A72V4-00018p-1n
	for sip@optimus.ietf.org; Tue, 07 Oct 2003 20:48:22 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29757
	for <sip@ietf.org>; Tue, 7 Oct 2003 20:48:12 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A72V1-0005yf-00
	for sip@ietf.org; Tue, 07 Oct 2003 20:48:19 -0400
Received: from sark.cc.gatech.edu ([130.207.7.23])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A72V1-0005yX-00
	for sip@ietf.org; Tue, 07 Oct 2003 20:48:19 -0400
Received: from tokyo.cc.gatech.edu (tokyo.cc.gatech.edu [130.207.114.15])
	by sark.cc.gatech.edu (8.12.10/8.12.8) with ESMTP id h980mITs013610;
	Tue, 7 Oct 2003 20:48:18 -0400 (EDT)
Received: from localhost (srikanth@localhost)
	by tokyo.cc.gatech.edu (8.12.10/8.12.8) with ESMTP id h980mIWu008169;
	Tue, 7 Oct 2003 20:48:18 -0400 (EDT)
Date: Tue, 7 Oct 2003 20:48:18 -0400 (EDT)
From: Srikanth Sundaragopalan <srikanth@cc.gatech.edu>
To: Samir Srivastava <ssrivastava@telverse.com>
cc: sip@ietf.org
Subject: Re: [Sip] Event Based Heart Beat in SIP
In-Reply-To: <F96BD6D84E58C849A82C730906178517015BF387@dc1.telverse.com>
Message-ID: <Pine.GSO.4.58.0310072040500.7377@tokyo.cc.gatech.edu>
References: <F96BD6D84E58C849A82C730906178517015BF387@dc1.telverse.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>

Refer draft-ietf-simple-presence-10.txt,which talks about essentially
what you have described.

If you want liveliness within a dialog,meaning you want to know whether
the remote end is still active,you might want to look into session timer
features.

regds
Srikanth Sundaragopalan
Graduate Student
College of Computing
Georgia Tech


On Tue, 7 Oct 2003, Samir Srivastava wrote:

> Hi,
>
> The current standard provides OPTIONS to find the liveness of remote SIP
> endpoint.
> If remote SIP server is not able to response back for the OPTIONS for a
> long time,
> it results in bunch of OPTIONS requests in the network. There is no
> standard
> event defined which tells the availability of remote SIP endpoint.
>
> Consider SIP endpoints A (local) wants to find out the availabilty of
> B(remote).
> A subsribes event "READY_TO_PROCESS"  to B, when B is ready to process
> SIP reqs.  The subscribers of event needs to stored persistenly. As soon
> as SIP
> server is ready for signal processing, it will send the NOTIFY
> indicating its
> availability. This eliminates the OPTIONS REQs when remote endpoint is
> not
> available for checking liveness ?
>
> Other events can be also added, like update the availability when there
> is
> no SIP traffic.
>
> Whether checking liveness based on the events was considered earlier ?
>
> Thx
> Samir
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Wed Oct  8 01:47:40 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06101
	for <sip-archive@odin.ietf.org>; Wed, 8 Oct 2003 01:47:40 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A77AJ-0005bG-Ox
	for sip-archive@odin.ietf.org; Wed, 08 Oct 2003 01:47:19 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h985lFt8021520
	for sip-archive@odin.ietf.org; Wed, 8 Oct 2003 01:47:15 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A77A6-0005aR-Vs; Wed, 08 Oct 2003 01:47:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A779c-0005ZK-Rk
	for sip@optimus.ietf.org; Wed, 08 Oct 2003 01:46:32 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06047
	for <sip@ietf.org>; Wed, 8 Oct 2003 01:46:23 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A779Z-0000bD-00
	for sip@ietf.org; Wed, 08 Oct 2003 01:46:29 -0400
Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A779U-0000ah-00
	for sip@ietf.org; Wed, 08 Oct 2003 01:46:24 -0400
Received: from Natarajucl1127 (huawei.com [172.17.1.62])
 by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
 2002)) with ESMTPA id <0HMF005JABXUGT@mta0.huawei.com> for sip@ietf.org; Wed,
 08 Oct 2003 13:44:24 +0800 (CST)
Date: Wed, 08 Oct 2003 11:17:43 +0530
From: "Nataraju A.B." <natarajuab@huawei.com>
Subject: Re: [Sip] ACK retransmission for 2xx
To: Relkem Los <relkem_los@hotmail.com>, sip@ietf.org
Message-id: <010801c38d5f$b2c1ca00$3d02120a@in.huawei.com>
Organization: HTIPL
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
Content-type: multipart/alternative;
 boundary="Boundary_(ID_68RGQdznDbIPGVWpqoEybQ)"
X-Priority: 3
X-MSMail-priority: Normal
References: <BAY2-F70VwcdZ06YO4O0000227a@hotmail.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>

This is a multi-part message in MIME format.

--Boundary_(ID_68RGQdznDbIPGVWpqoEybQ)
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7BIT


  ----- Original Message ----- 
  From: Relkem Los 
  To: natarajuab@huawei.com ; sip@ietf.org 
  Sent: Wednesday, October 08, 2003 10:59 AM
  Subject: Re: [Sip] ACK retransmission for 2xx


  I agree that for the first 2xx with different tags the UAC core should do 
  dns since these are different responses from different destinations.
  I'm still not sure about further 2xx of the same dialog.
  Should I DNS for each Ack retransmission? This can be very time consuming.
  On the other hand if all Acks are sent to the same destination (first IP and 
  Port retrieved by the
  DNS query) there is a chance that this ACK will be sent to an address that 
  no one is listening to. In this case the UAS will keep retransmitting the 
  2xx, The UAC will keep
  retransmitting the ACK (to the wrong address) and the call will never get 
  connected. The UAC has no way to learn that the remote party never got the 
  ACK and cannot recover from it.

  So my question is: Can any one point me to the place in the standard that 
  specifies whether it is needed to do DNS for ACK retransmission of 2xx.

  [ABN] even If you query DNS for each retransmitted 2xx received, the DNS results could be same, since the contact in 2xx will same in all the retransmitted 2xx responses. The above scenario will not happen since UAS might have sent the valid contact in the 2xx response. 
  ACK must reach the UAS if there is no problem with contact address in 2xd response through one of the DNS results. 
  Hence there is no need for repeated DNS query to send ACK for 2xx response 

  Thanks.


  >From: "Nataraju A.B." <natarajuab@huawei.com>
  >To: Relkem Los <relkem_los@hotmail.com>, sip@ietf.org
  >Subject: Re: [Sip] ACK retransmission for 2xx
  >Date: Mon, 06 Oct 2003 18:51:51 +0530
  >
  >Regards,
  >Nataraju A.B.
  >   ----- Original Message -----
  >   From: Relkem Los
  >   To: sip@ietf.org
  >   Sent: Thursday, October 02, 2003 12:28 PM
  >   Subject: [Sip] ACK retransmission for 2xx
  >
  >
  >   Hi,
  >   According to RFC3261 "The UAC core MUST generate an ACK request for each 
  >2xx
  >   received from the transaction layer" and " Once the ACK has been
  >   constructed, the procedures of [4] are used to determine the destination
  >   address, port and transport."
  >   Does this mean that we need to do the DNS procedure for every 
  >retransmission
  >   of this ACK?
  >   Can't this cause the ACK to be sent to a different IP and even use a
  >   different transport for each retransmission?
  >
  >   [ABN]
  >
  >   When UAC receives a 2xx of INVITE it has to generate the ACK response 
  >and has to cache that response and retransmitt for all the responses 
  >received on that dialog. till the expiration of timer 64*T1.
  >
  >   Its better to cache the DNS results and use the same results for each 
  >ACK retransmission on that dialog. At this point of time DNS queried on 
  >contact address in 2xx. This contact URI is more specific to that UAS than 
  >one specified in Req-URI in the initial INVITE. hence it less possible that 
  >the ACK reaching different end points.
  >
  >   for each 2xx with different tags the above set operations must be 
  >repeated ( I assume ). but the what is mentioned in rfc mean that it must 
  >be repeated for all the 2xx received (whether retransmitted (same to-tag) 
  >OR with a different to-tag ).
  >
  >   but rfc does not say about DNS results must be cached or not ( It might 
  >be an implementation issue ).
  >
  >   [ABN]
  >
  >   Thanks.
  >
  >   _________________________________________________________________
  >   Add MSN 8 Internet Software to your existing Internet access and enjoy
  >   patented spam protection and more.  Sign up now!
  >   http://join.msn.com/?page=dept/byoa
  >
  >
  >   _______________________________________________
  >   Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
  >   This list is for NEW development of the core SIP Protocol
  >   Use sip-implementors@cs.columbia.edu for questions on current sip
  >   Use sipping@ietf.org for new developments on the application of sip
  >

  _________________________________________________________________
  MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. 
  http://join.msn.com/?page=features/virus



--Boundary_(ID_68RGQdznDbIPGVWpqoEybQ)
Content-type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 7BIT

<!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.4134.600" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY style="COLOR: #0000ff; FONT-FAMILY: Verdana" bgColor=#ffffff>
<DIV><STRONG><FONT size=2></FONT></STRONG>&nbsp;</DIV>
<BLOCKQUOTE 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV 
  style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B> 
  <A title=relkem_los@hotmail.com href="mailto:relkem_los@hotmail.com">Relkem 
  Los</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>To:</B> <A title=natarajuab@huawei.com 
  href="mailto:natarajuab@huawei.com">natarajuab@huawei.com</A> ; <A 
  title=sip@ietf.org href="mailto:sip@ietf.org">sip@ietf.org</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Sent:</B> Wednesday, October 08, 2003 10:59 
  AM</DIV>
  <DIV style="FONT: 10pt arial"><B>Subject:</B> Re: [Sip] ACK retransmission for 
  2xx</DIV>
  <DIV><BR></DIV>
  <DIV>I agree that for the first 2xx with different tags the UAC core should do 
  <BR>dns since these are different responses from different 
  destinations.<BR>I'm still not sure about further 2xx of the same 
  dialog.<BR>Should I DNS for each Ack retransmission? This can be very time 
  consuming.<BR>On the other hand if all Acks are sent to the same destination 
  (first IP and <BR>Port retrieved by the<BR>DNS query) there is a chance that 
  this ACK will be sent to an address that <BR>no one is listening to. In this 
  case the UAS will keep retransmitting the <BR>2xx, The UAC will 
  keep<BR>retransmitting the ACK (to the wrong address) and the call will never 
  get <BR>connected. The UAC has no way to learn that the remote party never got 
  the <BR>ACK and cannot recover from it.<BR><BR>So my question is: Can any one 
  point me to the place in the standard that <BR>specifies whether it is needed 
  to do DNS for ACK retransmission of 2xx.<BR></DIV>
  <DIV><STRONG><FONT size=2>[ABN] even If you query DNS for each retransmitted 
  2xx received, the DNS results could be same, since the contact in 2xx will 
  same in all the retransmitted 2xx responses. The above scenario will not 
  happen since UAS might have sent the valid contact in the 2xx response. 
  </FONT></STRONG></DIV>
  <DIV><STRONG><FONT size=2>ACK must reach the UAS if there is no problem with 
  contact address in 2xd response through one of the DNS results. 
  </FONT></STRONG></DIV><STRONG><FONT size=2></FONT></STRONG><STRONG><FONT 
  size=2></FONT></STRONG></BLOCKQUOTE>
<BLOCKQUOTE 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px"><STRONG><FONT 
  size=2>Hence there is no need for repeated DNS query to send ACK for 2xx 
  response </FONT></STRONG>
  <DIV><STRONG><FONT size=2></FONT></STRONG><BR>Thanks.<BR><BR><BR>&gt;From: 
  "Nataraju A.B." &lt;<A 
  href="mailto:natarajuab@huawei.com">natarajuab@huawei.com</A>&gt;<BR>&gt;To: 
  Relkem Los &lt;<A 
  href="mailto:relkem_los@hotmail.com">relkem_los@hotmail.com</A>&gt;, <A 
  href="mailto:sip@ietf.org">sip@ietf.org</A><BR>&gt;Subject: Re: [Sip] ACK 
  retransmission for 2xx<BR>&gt;Date: Mon, 06 Oct 2003 18:51:51 
  +0530<BR>&gt;<BR>&gt;Regards,<BR>&gt;Nataraju A.B.<BR>&gt;&nbsp;&nbsp; ----- 
  Original Message -----<BR>&gt;&nbsp;&nbsp; From: Relkem 
  Los<BR>&gt;&nbsp;&nbsp; To: <A 
  href="mailto:sip@ietf.org">sip@ietf.org</A><BR>&gt;&nbsp;&nbsp; Sent: 
  Thursday, October 02, 2003 12:28 PM<BR>&gt;&nbsp;&nbsp; Subject: [Sip] ACK 
  retransmission for 2xx<BR>&gt;<BR>&gt;<BR>&gt;&nbsp;&nbsp; 
  Hi,<BR>&gt;&nbsp;&nbsp; According to RFC3261 "The UAC core MUST generate an 
  ACK request for each <BR>&gt;2xx<BR>&gt;&nbsp;&nbsp; received from the 
  transaction layer" and " Once the ACK has been<BR>&gt;&nbsp;&nbsp; 
  constructed, the procedures of [4] are used to determine the 
  destination<BR>&gt;&nbsp;&nbsp; address, port and 
  transport."<BR>&gt;&nbsp;&nbsp; Does this mean that we need to do the DNS 
  procedure for every <BR>&gt;retransmission<BR>&gt;&nbsp;&nbsp; of this 
  ACK?<BR>&gt;&nbsp;&nbsp; Can't this cause the ACK to be sent to a different IP 
  and even use a<BR>&gt;&nbsp;&nbsp; different transport for each 
  retransmission?<BR>&gt;<BR>&gt;&nbsp;&nbsp; [ABN]<BR>&gt;<BR>&gt;&nbsp;&nbsp; 
  When UAC receives a 2xx of INVITE it has to generate the ACK response 
  <BR>&gt;and has to cache that response and retransmitt for all the responses 
  <BR>&gt;received on that dialog. till the expiration of timer 
  64*T1.<BR>&gt;<BR>&gt;&nbsp;&nbsp; Its better to cache the DNS results and use 
  the same results for each <BR>&gt;ACK retransmission on that dialog. At this 
  point of time DNS queried on <BR>&gt;contact address in 2xx. This contact URI 
  is more specific to that UAS than <BR>&gt;one specified in Req-URI in the 
  initial INVITE. hence it less possible that <BR>&gt;the ACK reaching different 
  end points.<BR>&gt;<BR>&gt;&nbsp;&nbsp; for each 2xx with different tags the 
  above set operations must be <BR>&gt;repeated ( I assume ). but the what is 
  mentioned in rfc mean that it must <BR>&gt;be repeated for all the 2xx 
  received (whether retransmitted (same to-tag) <BR>&gt;OR with a different 
  to-tag ).<BR>&gt;<BR>&gt;&nbsp;&nbsp; but rfc does not say about DNS results 
  must be cached or not ( It might <BR>&gt;be an implementation issue 
  ).<BR>&gt;<BR>&gt;&nbsp;&nbsp; [ABN]<BR>&gt;<BR>&gt;&nbsp;&nbsp; 
  Thanks.<BR>&gt;<BR>&gt;&nbsp;&nbsp; 
  _________________________________________________________________<BR>&gt;&nbsp;&nbsp; 
  Add MSN 8 Internet Software to your existing Internet access and 
  enjoy<BR>&gt;&nbsp;&nbsp; patented spam protection and more.&nbsp; Sign up 
  now!<BR>&gt;&nbsp;&nbsp; <A 
  href="http://join.msn.com/?page=dept/byoa">http://join.msn.com/?page=dept/byoa</A><BR>&gt;<BR>&gt;<BR>&gt;&nbsp;&nbsp; 
  _______________________________________________<BR>&gt;&nbsp;&nbsp; Sip 
  mailing list&nbsp; <A 
  href="https://www1.ietf.org/mailman/listinfo/sip">https://www1.ietf.org/mailman/listinfo/sip</A><BR>&gt;&nbsp;&nbsp; 
  This list is for NEW development of the core SIP Protocol<BR>&gt;&nbsp;&nbsp; 
  Use <A 
  href="mailto:sip-implementors@cs.columbia.edu">sip-implementors@cs.columbia.edu</A> 
  for questions on current sip<BR>&gt;&nbsp;&nbsp; Use <A 
  href="mailto:sipping@ietf.org">sipping@ietf.org</A> for new developments on 
  the application of 
  sip<BR>&gt;<BR><BR>_________________________________________________________________<BR>MSN 
  8 helps eliminate e-mail viruses. Get 2 months FREE*. <BR><A 
  href="http://join.msn.com/?page=features/virus">http://join.msn.com/?page=features/virus</A><BR></DIV></BLOCKQUOTE>
<P></P></BODY></HTML>

--Boundary_(ID_68RGQdznDbIPGVWpqoEybQ)--

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Wed Oct  8 02:51:21 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04131
	for <sip-archive@odin.ietf.org>; Wed, 8 Oct 2003 02:51:21 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A78A0-0001oI-Oe
	for sip-archive@odin.ietf.org; Wed, 08 Oct 2003 02:51:00 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h986p0VB006901
	for sip-archive@odin.ietf.org; Wed, 8 Oct 2003 02:51:00 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7896-0001dt-MU; Wed, 08 Oct 2003 02:50:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A788f-0001c4-4Q
	for sip@optimus.ietf.org; Wed, 08 Oct 2003 02:49:37 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04028
	for <sip@ietf.org>; Wed, 8 Oct 2003 02:49:27 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A788b-0001F1-00
	for sip@ietf.org; Wed, 08 Oct 2003 02:49:33 -0400
Received: from [203.199.83.38] (helo=rediffmail.com)
	by ietf-mx with smtp (Exim 4.12)
	id 1A788Z-0001Eh-00
	for sip@ietf.org; Wed, 08 Oct 2003 02:49:32 -0400
Received: (qmail 12565 invoked by uid 510); 8 Oct 2003 06:34:45 -0000
Date: 8 Oct 2003 06:34:45 -0000
Message-ID: <20031008063445.12564.qmail@webmail28.rediffmail.com>
Received: from unknown (202.153.32.135) by rediffmail.com via HTTP; 08 oct 2003 06:34:44 -0000
MIME-Version: 1.0
From: "Karunakara  Rao" <karu_future@rediffmail.com>
Reply-To: "Karunakara  Rao" <karu_future@rediffmail.com>
To: sip@ietf.org
Content-type: multipart/alternative;
	boundary="Next_1065594884---0-203.199.83.38-12549"
Subject: [Sip] Dialog States
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 multipart mime message


--Next_1065594884---0-203.199.83.38-12549
Content-type: text/html;
	charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

<P>=0AHi,<BR>=0Acan any one help me!!!<BR>=0Ain 3261 info regd dialog is ve=
ry limited<BR>=0Ascenario1: a dialog is in confirmed state, 1st UA sent a r=
e-invite, so TU creates a invite-client transaction, and sent the request. =
then it receives a non-invite request (info/refer etc) from the other 2nd U=
A<BR>=0Athen can TU create another non-invite server trasaction or should i=
t wait till the 1st inv-cli transaction to get over.<BR>=0Acan there be two=
 transaction at a time....plz clarify.<BR>=0A<BR>=0Ai wud be glad to get ur=
 reply<BR>=0A<BR>=0AThanks &amp; regards<BR>=0AKarunakar.<BR>=0A =0A</P>=0A=
<br><br>=0A<A target=3D"_blank" HREF=3D"http://clients.rediff.com/signature=
/track_sig.asp"><IMG SRC=3D"http://ads.rediff.com/RealMedia/ads/adstream_nx=
.cgi/www.rediffmail.com/inbox.htm@Bottom" BORDER=3D0 VSPACE=3D0 HSPACE=3D0 =
HEIGHT=3D74 WIDTH=3D496></a>=0A
--Next_1065594884---0-203.199.83.38-12549
Content-type: text/plain;
	charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,=0Acan any one help me!!!=0Ain 3261 info regd dialog is very limited=0As=
cenario1: a dialog is in confirmed state, 1st UA sent a re-invite, so TU cr=
eates a invite-client transaction, and sent the request. then it receives a=
 non-invite request (info/refer etc) from the other 2nd UA=0Athen can TU cr=
eate another non-invite server trasaction or should it wait till the 1st in=
v-cli transaction to get over.=0Acan there be two transaction at a time....=
plz clarify.=0A=0Ai wud be glad to get ur reply=0A=0AThanks & regards=0AKar=
unakar.=0A=20
--Next_1065594884---0-203.199.83.38-12549--


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Wed Oct  8 02:53:26 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04180
	for <sip-archive@odin.ietf.org>; Wed, 8 Oct 2003 02:53:26 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A78C2-00029l-CW
	for sip-archive@odin.ietf.org; Wed, 08 Oct 2003 02:53:06 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h986r6qw008184
	for sip-archive@odin.ietf.org; Wed, 8 Oct 2003 02:53:06 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A78By-00020x-3N; Wed, 08 Oct 2003 02:53:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A78BW-00020G-PU
	for sip@optimus.ietf.org; Wed, 08 Oct 2003 02:52:34 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04155
	for <sip@ietf.org>; Wed, 8 Oct 2003 02:52:24 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A78BS-0001H2-00
	for sip@ietf.org; Wed, 08 Oct 2003 02:52:30 -0400
Received: from [203.199.83.27] (helo=rediffmail.com)
	by ietf-mx with smtp (Exim 4.12)
	id 1A78BN-0001Gz-00
	for sip@ietf.org; Wed, 08 Oct 2003 02:52:30 -0400
Received: (qmail 28654 invoked by uid 510); 8 Oct 2003 06:14:25 -0000
Date: 8 Oct 2003 06:14:25 -0000
Message-ID: <20031008061425.28653.qmail@webmail17.rediffmail.com>
Received: from unknown (202.153.32.135) by rediffmail.com via HTTP; 08 oct 2003 06:14:25 -0000
MIME-Version: 1.0
From: "Karunakara  Rao" <karu_future@rediffmail.com>
Reply-To: "Karunakara  Rao" <karu_future@rediffmail.com>
To: sip@ietf.org
Content-type: multipart/alternative;
	boundary="Next_1065593665---0-203.199.83.27-28639"
Subject: [Sip] Dialog States
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 multipart mime message


--Next_1065593665---0-203.199.83.27-28639
Content-type: text/html;
	charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

<P>=0AHi,<BR>=0Acan any one help me!!!<BR>=0Ain 3261 info regd dialog is ve=
ry limited<BR>=0Ascenario1: a dialog is in confirmed state, 1st UA sent a r=
e-invite, so TU creates a invite-client transaction, and sent the request. =
then it receives a non-invite request (info/refer etc) from the other 2nd U=
A<BR>=0Athen can TU create another non-invite server trasaction or should i=
t wait till the 1st inv-cli transaction to get over.<BR>=0Acan there be two=
 transaction at a time....plz clarify.<BR>=0A<BR>=0Ai wud be glad to get ur=
 reply<BR>=0A<BR>=0AThanks &amp; regards<BR>=0AKarunakar.<BR>=0A =0A</P>=0A=
<br><br>=0A<A target=3D"_blank" HREF=3D"http://clients.rediff.com/signature=
/track_sig.asp"><IMG SRC=3D"http://ads.rediff.com/RealMedia/ads/adstream_nx=
.cgi/www.rediffmail.com/inbox.htm@Bottom" BORDER=3D0 VSPACE=3D0 HSPACE=3D0 =
HEIGHT=3D74 WIDTH=3D496></a>=0A
--Next_1065593665---0-203.199.83.27-28639
Content-type: text/plain;
	charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,=0Acan any one help me!!!=0Ain 3261 info regd dialog is very limited=0As=
cenario1: a dialog is in confirmed state, 1st UA sent a re-invite, so TU cr=
eates a invite-client transaction, and sent the request. then it receives a=
 non-invite request (info/refer etc) from the other 2nd UA=0Athen can TU cr=
eate another non-invite server trasaction or should it wait till the 1st in=
v-cli transaction to get over.=0Acan there be two transaction at a time....=
plz clarify.=0A=0Ai wud be glad to get ur reply=0A=0AThanks & regards=0AKar=
unakar.=0A=20
--Next_1065593665---0-203.199.83.27-28639--


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Wed Oct  8 02:56:26 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04256
	for <sip-archive@odin.ietf.org>; Wed, 8 Oct 2003 02:56:26 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A78Ew-0002Ld-7Z
	for sip-archive@odin.ietf.org; Wed, 08 Oct 2003 02:56:06 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h986u6rw009007
	for sip-archive@odin.ietf.org; Wed, 8 Oct 2003 02:56:06 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A78Es-0002Kh-Ef; Wed, 08 Oct 2003 02:56:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A78Ef-0002K6-5o
	for sip@optimus.ietf.org; Wed, 08 Oct 2003 02:55:49 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04230
	for <sip@ietf.org>; Wed, 8 Oct 2003 02:55:39 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A78Eb-0001J7-00
	for sip@ietf.org; Wed, 08 Oct 2003 02:55:45 -0400
Received: from [203.199.83.27] (helo=rediffmail.com)
	by ietf-mx with smtp (Exim 4.12)
	id 1A78ER-0001Im-00
	for sip@ietf.org; Wed, 08 Oct 2003 02:55:35 -0400
Received: (qmail 31119 invoked by uid 510); 8 Oct 2003 06:16:23 -0000
Date: 8 Oct 2003 06:16:23 -0000
Message-ID: <20031008061623.31118.qmail@webmail17.rediffmail.com>
Received: from unknown (202.153.32.135) by rediffmail.com via HTTP; 08 oct 2003 06:16:23 -0000
MIME-Version: 1.0
From: "Karunakara  Rao" <karu_future@rediffmail.com>
Reply-To: "Karunakara  Rao" <karu_future@rediffmail.com>
To: sip@ietf.org
Content-type: multipart/alternative;
	boundary="Next_1065593783---0-203.199.83.27-31111"
Subject: [Sip] Dialog States
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 multipart mime message


--Next_1065593783---0-203.199.83.27-31111
Content-type: text/html;
	charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

<P>=0AHi,<BR>=0Acan any one help me!!!<BR>=0Ain 3261 info regd dialog is ve=
ry limited<BR>=0Ascenario1: a dialog is in confirmed state, 1st UA sent a r=
e-invite, so TU creates a invite-client transaction, and sent the request. =
then it receives a non-invite request (info/refer etc) from the other 2nd U=
A<BR>=0Athen can TU create another non-invite server trasaction or should i=
t wait till the 1st inv-cli transaction to get over.<BR>=0Acan there be two=
 transaction at a time....plz clarify.<BR>=0A<BR>=0Ai wud be glad to get ur=
 reply<BR>=0A<BR>=0AThanks &amp; regards<BR>=0AKarunakar.<BR>=0A =0A</P>=0A=
<br><br>=0A<A target=3D"_blank" HREF=3D"http://clients.rediff.com/signature=
/track_sig.asp"><IMG SRC=3D"http://ads.rediff.com/RealMedia/ads/adstream_nx=
.cgi/www.rediffmail.com/inbox.htm@Bottom" BORDER=3D0 VSPACE=3D0 HSPACE=3D0 =
HEIGHT=3D74 WIDTH=3D496></a>=0A
--Next_1065593783---0-203.199.83.27-31111
Content-type: text/plain;
	charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,=0Acan any one help me!!!=0Ain 3261 info regd dialog is very limited=0As=
cenario1: a dialog is in confirmed state, 1st UA sent a re-invite, so TU cr=
eates a invite-client transaction, and sent the request. then it receives a=
 non-invite request (info/refer etc) from the other 2nd UA=0Athen can TU cr=
eate another non-invite server trasaction or should it wait till the 1st in=
v-cli transaction to get over.=0Acan there be two transaction at a time....=
plz clarify.=0A=0Ai wud be glad to get ur reply=0A=0AThanks & regards=0AKar=
unakar.=0A=20
--Next_1065593783---0-203.199.83.27-31111--


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Wed Oct  8 04:42:41 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06585
	for <sip-archive@odin.ietf.org>; Wed, 8 Oct 2003 04:42:41 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A79tk-0007ro-I2
	for sip-archive@odin.ietf.org; Wed, 08 Oct 2003 04:42:20 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h988gKd0030239
	for sip-archive@odin.ietf.org; Wed, 8 Oct 2003 04:42:20 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A79tU-0007pW-Ec; Wed, 08 Oct 2003 04:42:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A79tN-0007of-FE
	for sip@optimus.ietf.org; Wed, 08 Oct 2003 04:41:57 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06537
	for <sip@ietf.org>; Wed, 8 Oct 2003 04:41:47 -0400 (EDT)
From: hisham.khartabil@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A79tK-0002F8-00
	for sip@ietf.org; Wed, 08 Oct 2003 04:41:54 -0400
Received: from mgw-x4.nokia.com ([131.228.20.27])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A79tJ-0002F5-00
	for sip@ietf.org; Wed, 08 Oct 2003 04:41:53 -0400
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h988fnt15474
	for <sip@ietf.org>; Wed, 8 Oct 2003 11:41:49 +0300 (EET DST)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T6527e97913ac158f23077@esvir03nok.nokia.com>;
 Wed, 8 Oct 2003 11:41:49 +0300
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Wed, 8 Oct 2003 11:41:48 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Event Based Heart Beat in SIP
Date: Wed, 8 Oct 2003 11:41:47 +0300
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017971E7@esebe019.ntc.nokia.com>
Thread-Topic: Event Based Heart Beat in SIP
Thread-Index: AcONMOWnwhZWyG2OSpuMPLKANFoOvgARrz0w
To: <ssrivastava@telverse.com>, <sip@ietf.org>
X-OriginalArrivalTime: 08 Oct 2003 08:41:48.0076 (UTC) FILETIME=[02E686C0:01C38D78]
Content-Transfer-Encoding: quoted-printable
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: quoted-printable

Excuse my lack of knowledge about ICMP, but don't you get an ICMP error =
when you send a UDP packet an server that is not listening on the port =
you sent it to?

Also for TCP, you get an error when you try to connect the sockets.

Someone please correct me if I'm wrong.

/Hisham=20

> -----Original Message-----
> From: ext Samir Srivastava [mailto:ssrivastava@telverse.com]
> Sent: Wednesday, October 08, 2003 3:13 AM
> To: sip@ietf.org
> Subject: [Sip] Event Based Heart Beat in SIP
>=20
>=20
> Hi,
>=20
> The current standard provides OPTIONS to find the liveness of=20
> remote SIP
> endpoint.
> If remote SIP server is not able to response back for the=20
> OPTIONS for a
> long time,
> it results in bunch of OPTIONS requests in the network. There is no
> standard
> event defined which tells the availability of remote SIP endpoint.=20
>=20
> Consider SIP endpoints A (local) wants to find out the availabilty of
> B(remote).
> A subsribes event "READY_TO_PROCESS"  to B, when B is ready=20
> to process=20
> SIP reqs.  The subscribers of event needs to stored=20
> persistenly. As soon
> as SIP=20
> server is ready for signal processing, it will send the NOTIFY
> indicating its
> availability. This eliminates the OPTIONS REQs when remote endpoint is
> not
> available for checking liveness ?=20
>=20
> Other events can be also added, like update the availability=20
> when there
> is
> no SIP traffic.
>=20
> Whether checking liveness based on the events was considered earlier ?
>=20
> Thx
> Samir
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Wed Oct  8 15:13:28 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04201
	for <sip-archive@odin.ietf.org>; Wed, 8 Oct 2003 15:13:28 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7JkA-0003jV-3l
	for sip-archive@odin.ietf.org; Wed, 08 Oct 2003 15:13:06 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h98JD6po014325
	for sip-archive@odin.ietf.org; Wed, 8 Oct 2003 15:13:06 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7Jk4-0003iJ-BO; Wed, 08 Oct 2003 15:13:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7Jjw-0003hi-8e
	for sip@optimus.ietf.org; Wed, 08 Oct 2003 15:12:52 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04147
	for <sip@ietf.org>; Wed, 8 Oct 2003 15:12:43 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7Jju-00031B-00
	for sip@ietf.org; Wed, 08 Oct 2003 15:12:50 -0400
Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7Jju-00030J-00
	for sip@ietf.org; Wed, 08 Oct 2003 15:12:50 -0400
Received: from localhost (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h98JCJk1017986;
	Wed, 8 Oct 2003 14:12:19 -0500
Subject: RE: [Sip] Event Based Heart Beat in SIP
From: Dean Willis <dean.willis@softarmor.com>
To: hisham.khartabil@nokia.com
Cc: ssrivastava@telverse.com, sip@ietf.org
In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017971E7@esebe019.ntc.nokia.com>
References: 
	 <2038BCC78B1AD641891A0D1AE133DBB7017971E7@esebe019.ntc.nokia.com>
Content-Type: text/plain
Message-Id: <1065640339.16907.31.camel@bdsl.greycouncil.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 
Date: Wed, 08 Oct 2003 14:12:19 -0500
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

On Wed, 2003-10-08 at 03:41, hisham.khartabil@nokia.com wrote:
> Excuse my lack of knowledge about ICMP, but don't you get an ICMP error when you send a UDP packet an server that is not listening on the port you sent it to?
> 
> Also for TCP, you get an error when you try to connect the sockets.
> 
> Someone please correct me if I'm wrong.

In practical terms, "maybe". If the Internet were pure and
unadulterated, you'd get an ICMP Port Unreachable response.

Unfortunately, lots of systems no longer send such ICMP responses, and
many firewalls block them. It seems that these response codes are useful
for scanning for "open" ports that might later be victimized.

In fact, some of my colleagues go so far as to automatically add packet
filter entries that block future traffic from any address they think
might be probing them. I really enjoy UDP port-scanning these guys using
a spoofed address that happens to correspond to their upstream DNS
server, NTP server, DHCP server, or the like. This holds the same sort
of fascination as popping packing bubbles or scaring oppossum,
millipedes, and other creatures that go fetal when one says "boo!" at
them. But that's another story.

Also, it is not uncommon for server applications to die in such a way
that they continue to "listen" to ports, but don't ever respond -- so
even if ICMP were "live", you'd still get no failure indication. This
seemed to happen a lot with early SIP servers running on early Java VMs,
which I believe was related to the threading model in use.

--
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 exim@www1.ietf.org  Wed Oct  8 16:42:32 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08242
	for <sip-archive@odin.ietf.org>; Wed, 8 Oct 2003 16:42:32 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7L8N-0000JD-RR
	for sip-archive@odin.ietf.org; Wed, 08 Oct 2003 16:42:12 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h98KgBHv001129
	for sip-archive@odin.ietf.org; Wed, 8 Oct 2003 16:42:11 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7L8E-0000He-Mo; Wed, 08 Oct 2003 16:42:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7L7v-0000Cy-41
	for sip@optimus.ietf.org; Wed, 08 Oct 2003 16:41:43 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08229
	for <sip@ietf.org>; Wed, 8 Oct 2003 16:41:33 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7L7t-00047j-00
	for sip@ietf.org; Wed, 08 Oct 2003 16:41:41 -0400
Received: from mail.telverse.com ([4.43.0.5] helo=dc1.telverse.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7L7s-00047d-00
	for sip@ietf.org; Wed, 08 Oct 2003 16:41:40 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Event Based Heart Beat in SIP
Date: Wed, 8 Oct 2003 13:41:10 -0700
Message-ID: <F96BD6D84E58C849A82C730906178517015BF388@dc1.telverse.com>
Thread-Topic: [Sip] Event Based Heart Beat in SIP
Thread-Index: AcON0C4U5IMvnNHGT4WnTzj3jZYBLwACLYUw
From: "Samir Srivastava" <ssrivastava@telverse.com>
To: "Dean Willis" <dean.willis@softarmor.com>, <hisham.khartabil@nokia.com>
Cc: <sip@ietf.org>
Content-Transfer-Encoding: quoted-printable
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: quoted-printable



-----Original Message-----
From: Dean Willis [mailto:dean.willis@softarmor.com]
Sent: Wednesday, October 08, 2003 12:12 PM
To: hisham.khartabil@nokia.com
Cc: Samir Srivastava; sip@ietf.org
Subject: RE: [Sip] Event Based Heart Beat in SIP


On Wed, 2003-10-08 at 03:41, hisham.khartabil@nokia.com wrote:
> Excuse my lack of knowledge about ICMP, but don't you get an ICMP
error when you send a UDP packet an server that is not listening on the
port you sent it to?
>=20
> Also for TCP, you get an error when you try to connect the sockets.
>=20
> Someone please correct me if I'm wrong.

In practical terms, "maybe". If the Internet were pure and
unadulterated, you'd get an ICMP Port Unreachable response.

Unfortunately, lots of systems no longer send such ICMP responses, and
many firewalls block them. It seems that these response codes are useful
for scanning for "open" ports that might later be victimized.

SS>> I have also seen them getting blocked. It's good for security.

In fact, some of my colleagues go so far as to automatically add packet
filter entries that block future traffic from any address they think
might be probing them. I really enjoy UDP port-scanning these guys using
a spoofed address that happens to correspond to their upstream DNS
server, NTP server, DHCP server, or the like. This holds the same sort
of fascination as popping packing bubbles or scaring oppossum,
millipedes, and other creatures that go fetal when one says "boo!" at
them. But that's another story.

Also, it is not uncommon for server applications to die in such a way
that they continue to "listen" to ports, but don't ever respond -- so
even if ICMP were "live", you'd still get no failure indication. This
seemed to happen a lot with early SIP servers running on early Java VMs,
which I believe was related to the threading model in use.

SS>> This is actually the case, where IP /PORT is reachable, but server=20
doesn't respond because it has got stuck up somewhere else. There can
be other application level logic problems in some corner cases when
it can happen. That's why we need the SIP Application level heart beat.=20
The probing client keeps sending the OPTIONS Req to find server's health
when it is dead w.r.t. issuing signaling responses. To avoid these
options=20
requests in these "SIP Unreachable time", the client can stop probing
after
reaching some threshold, if there is a way to give the responsibilty to=20
server to tell clients when it is ready to process the signaling
requests.=20
=20

Thx
Samir


--
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 exim@www1.ietf.org  Wed Oct  8 20:01:29 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15799
	for <sip-archive@odin.ietf.org>; Wed, 8 Oct 2003 20:01:29 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7OEu-0002p5-0t
	for sip-archive@odin.ietf.org; Wed, 08 Oct 2003 20:01:08 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h99017Jc010847
	for sip-archive@odin.ietf.org; Wed, 8 Oct 2003 20:01:07 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7OEo-0002o2-CW; Wed, 08 Oct 2003 20:01:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7OEg-0002mp-JL
	for sip@optimus.ietf.org; Wed, 08 Oct 2003 20:00:54 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15762;
	Wed, 8 Oct 2003 20:00:45 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7OEe-0006BT-00; Wed, 08 Oct 2003 20:00:52 -0400
Received: from gamma.isi.edu ([128.9.144.145])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7OEd-0006BQ-00; Wed, 08 Oct 2003 20:00:51 -0400
Received: from ISI.EDU (jet.isi.edu [128.9.160.87])
	by gamma.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id h9900qO12690;
	Wed, 8 Oct 2003 17:00:52 -0700 (PDT)
Message-Id: <200310090000.h9900qO12690@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: Wed, 08 Oct 2003 17:00:51 -0700
Subject: [Sip] RFC 3608 on Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration
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 3608

        Title:      Session Initiation Protocol (SIP) Extension Header
                    Field for Service Route Discovery During
                    Registration
        Author(s):  D. Willis, B. Hoeneisen
        Status:     Standards Track
        Date:       October 2003
        Mailbox:    dean.willis@softarmor.com, hoeneisen@switch.ch
        Pages:      17
        Characters: 35628
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-sip-scvrtdisco-04.txt

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


This document defines a Session Initiation Protocol (SIP) extension
header field used in conjunction with responses to REGISTER requests
to provide a mechanism by which a registrar may inform a registering
user agent (UA) of a service route that the UA may use to request
outbound services from the registrar's domain.

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: <031008165819.RFC@RFC-EDITOR.ORG>

RETRIEVE: rfc
DOC-ID: rfc3608

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

Content-Type: text/plain
Content-ID: <031008165819.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 exim@www1.ietf.org  Thu Oct  9 02:53:37 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09132
	for <sip-archive@odin.ietf.org>; Thu, 9 Oct 2003 02:53:37 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7Ufj-0006Z8-NB
	for sip-archive@odin.ietf.org; Thu, 09 Oct 2003 02:53:16 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h996rFPF025238
	for sip-archive@odin.ietf.org; Thu, 9 Oct 2003 02:53:15 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7UfW-0006YC-Uq; Thu, 09 Oct 2003 02:53:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7Uep-0006X6-BV
	for sip@optimus.ietf.org; Thu, 09 Oct 2003 02:52:19 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09081
	for <SIP@ietf.org>; Thu, 9 Oct 2003 02:52:10 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7Uel-0002XR-00
	for SIP@ietf.org; Thu, 09 Oct 2003 02:52:15 -0400
Received: from mailgate.siemenscomms.co.uk ([194.129.217.115])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7Uek-0002WN-00
	for SIP@ietf.org; Thu, 09 Oct 2003 02:52:14 -0400
Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk
 (PMDF V6.0-24 #40642) id <0HMH00L019OORA@siemenscomms.co.uk> for SIP@ietf.org;
 Thu, 09 Oct 2003 07:50:48 +0100 (BST)
Received: from beex10.siemenscomms.co.uk ([137.223.246.252])
 by siemenscomms.co.uk (PMDF V6.0-24 #40642)
 with ESMTP id <0HMH00LB69OOJ6@siemenscomms.co.uk>; Thu,
 09 Oct 2003 07:50:48 +0100 (BST)
Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21)
	id <T53CY4J3>; Thu, 09 Oct 2003 07:51:30 +0100
Content-return: allowed
Date: Thu, 09 Oct 2003 07:45:43 +0100
From: "Elwell, John" <john.elwell@siemens.com>
Subject: RE: [Sip] Change of display name
To: Jean-Francois Rey <jean-francois.rey@bst.bsf.alcatel.fr>, SIP@ietf.org
Message-id: <50B1CBA96870A34799A506B2313F2667788C4F@ntht201e>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain
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

Jean-Francois,

I thought the earlier thread to which you refer was leaning towards the use
of UPDATE or re-INVITE with revised identity information. A related thread
was started by Cullen Jennings on 29th August ("Update of display name
during a call"), proposing the use of a revised display name in a From/To
header inside an AIB in an UPDATE or re-INVITE request. The thread led to
the related question of whether a revised P-Asserted-ID header could be
included in an UPDATE or re-INVITE request, but this appeared to be
inconclusive.

John (john.elwell@siemens.com)


> -----Original Message-----
> From: Jean-Francois Rey [mailto:jean-francois.rey@bst.bsf.alcatel.fr] 
> Sent: 01 October 2003 10:53
> To: SIP@ietf.org
> Subject: [Sip] Change of display name
> 
> 
> I'm implementing some attended transfer use cases between a telephone 
> gateway and SIP phones. I need to update the display name when the 
> transfer takes place. Unfortunately, if more than one gateway is 
> involved in the transfer, I cannot use the REFER + replaces 
> mechanism. I 
> know that this topic has already been discussed in this list 
> : Update of 
> display name during a call 
> (http://www1.ietf.org/mail-archive/working-groups/sip/current/
> msg08521.html), 
> Update and P-Asserted-ID 
> (http://www1.ietf.org/mail-archive/working-groups/sip/current/
> msg08142.html). 
> Unfortunately, I'm still a bit unsure of what is the outcome of these 
> threads. Using an identity mechanism (a short term one like 
> P-Asserted-ID or a long term one like AIB) in a UPDATE or re-INVITE 
> seems a bit underspecified to say the least. Could anyone provide 
> guidance on these topics : do we have a consensus ? Would 
> this consensus 
> go beyond telephone gateways experts and include SIP phone and 
> application vendors ? Are there any existing documents or planned 
> actions (new versions of drafts or rfcs, BCP) that would clarify this 
> topic ?
> 
> I played a little bit with SIP phones and I found out that a solution 
> works with many SIP phones : using the usual INVITE + 
> replaces mechanisms.
> 
> So instead of the UPDATE + identity solution
> 
>           Gateway	 Dialog D1	    SIP phone
> 	  |=========================|
> 	  |    (D1)UPDATE	    |
> 	  |------------------------>|
> 
> I tried this :
> 
>           Gateway	 Dialog D1	    SIP phone
> 	  |=========================|
> 	  |    (D2)INVITE	    |
> 	  |	(replaces D1)	    |
> 	  |------------------------>|
> 
> It works fine except if D1 is not confirmed.
> I understand that
> - there might be GRUU/routing problems (but nothing new compared to 
> usual REFER + replaces mechanism),
> - there are more messages being exchanged than in the UPDATE solution 
> (but the INVITE + replaces seems the BCP for attended 
> transfer in SIP).
> 
> So there are issues. OTOH this solution works with many 
> implementations, 
> it can rely on all identity solutions and IMHO it uses nicely the 
> semantic of replaces (which is needed for attended transfer 
> between SIP 
> phones anyway).
> 
> I'd like to have the community's feeling on that topic.
> 
> Thanks,
> Jean-Francois
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Thu Oct  9 02:59:29 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09302
	for <sip-archive@odin.ietf.org>; Thu, 9 Oct 2003 02:59:29 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7UlP-0006zw-5C
	for sip-archive@odin.ietf.org; Thu, 09 Oct 2003 02:59:08 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h996x7q8026860
	for sip-archive@odin.ietf.org; Thu, 9 Oct 2003 02:59:07 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7UlK-0006yZ-9S; Thu, 09 Oct 2003 02:59:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A76u4-0004YL-O1
	for sip@optimus.ietf.org; Wed, 08 Oct 2003 01:30:31 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05589
	for <sip@ietf.org>; Wed, 8 Oct 2003 01:30:19 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A76u1-0000RE-00
	for sip@ietf.org; Wed, 08 Oct 2003 01:30:25 -0400
Received: from bay2-f70.bay2.hotmail.com ([65.54.247.70] helo=hotmail.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A76u1-0000Qn-00
	for sip@ietf.org; Wed, 08 Oct 2003 01:30:25 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Tue, 7 Oct 2003 22:29:55 -0700
Received: from 80.74.106.2 by by2fd.bay2.hotmail.msn.com with HTTP;
	Wed, 08 Oct 2003 05:29:52 GMT
X-Originating-IP: [80.74.106.2]
X-Originating-Email: [relkem_los@hotmail.com]
From: "Relkem Los" <relkem_los@hotmail.com>
To: natarajuab@huawei.com, sip@ietf.org
Subject: Re: [Sip] ACK retransmission for 2xx
Date: Wed, 08 Oct 2003 05:29:52 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY2-F70VwcdZ06YO4O0000227a@hotmail.com>
X-OriginalArrivalTime: 08 Oct 2003 05:29:55.0662 (UTC) FILETIME=[34F78EE0:01C38D5D]
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id BAA05590
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: quoted-printable

I agree that for the first 2xx with different tags the UAC core should do=
=20
dns since these are different responses from different destinations.
I=92m still not sure about further 2xx of the same dialog.
Should I DNS for each Ack retransmission? This can be very time consuming.
On the other hand if all Acks are sent to the same destination (first IP =
and=20
Port retrieved by the
DNS query) there is a chance that this ACK will be sent to an address tha=
t=20
no one is listening to. In this case the UAS will keep retransmitting the=
=20
2xx, The UAC will keep
retransmitting the ACK (to the wrong address) and the call will never get=
=20
connected. The UAC has no way to learn that the remote party never got th=
e=20
ACK and cannot recover from it.

So my question is: Can any one point me to the place in the standard that=
=20
specifies whether it is needed to do DNS for ACK retransmission of 2xx.

Thanks.


>From: "Nataraju A.B." <natarajuab@huawei.com>
>To: Relkem Los <relkem_los@hotmail.com>, sip@ietf.org
>Subject: Re: [Sip] ACK retransmission for 2xx
>Date: Mon, 06 Oct 2003 18:51:51 +0530
>
>Regards,
>Nataraju A.B.
>   ----- Original Message -----
>   From: Relkem Los
>   To: sip@ietf.org
>   Sent: Thursday, October 02, 2003 12:28 PM
>   Subject: [Sip] ACK retransmission for 2xx
>
>
>   Hi,
>   According to RFC3261 "The UAC core MUST generate an ACK request for e=
ach=20
>2xx
>   received from the transaction layer" and " Once the ACK has been
>   constructed, the procedures of [4] are used to determine the destinat=
ion
>   address, port and transport."
>   Does this mean that we need to do the DNS procedure for every=20
>retransmission
>   of this ACK?
>   Can't this cause the ACK to be sent to a different IP and even use a
>   different transport for each retransmission?
>
>   [ABN]
>
>   When UAC receives a 2xx of INVITE it has to generate the ACK response=
=20
>and has to cache that response and retransmitt for all the responses=20
>received on that dialog. till the expiration of timer 64*T1.
>
>   Its better to cache the DNS results and use the same results for each=
=20
>ACK retransmission on that dialog. At this point of time DNS queried on=20
>contact address in 2xx. This contact URI is more specific to that UAS th=
an=20
>one specified in Req-URI in the initial INVITE. hence it less possible t=
hat=20
>the ACK reaching different end points.
>
>   for each 2xx with different tags the above set operations must be=20
>repeated ( I assume ). but the what is mentioned in rfc mean that it mus=
t=20
>be repeated for all the 2xx received (whether retransmitted (same to-tag=
)=20
>OR with a different to-tag ).
>
>   but rfc does not say about DNS results must be cached or not ( It mig=
ht=20
>be an implementation issue ).
>
>   [ABN]
>
>   Thanks.
>
>   _________________________________________________________________
>   Add MSN 8 Internet Software to your existing Internet access and enjo=
y
>   patented spam protection and more.  Sign up now!
>   http://join.msn.com/?page=3Ddept/byoa
>
>
>   _______________________________________________
>   Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>   This list is for NEW development of the core SIP Protocol
>   Use sip-implementors@cs.columbia.edu for questions on current sip
>   Use sipping@ietf.org for new developments on the application of sip
>

_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.=20
http://join.msn.com/?page=3Dfeatures/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 exim@www1.ietf.org  Thu Oct  9 04:57:36 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12374
	for <sip-archive@odin.ietf.org>; Thu, 9 Oct 2003 04:57:36 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7Wbh-00060j-VT
	for sip-archive@odin.ietf.org; Thu, 09 Oct 2003 04:57:14 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h998vDo2023049
	for sip-archive@odin.ietf.org; Thu, 9 Oct 2003 04:57:13 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7WbV-0005yR-DJ; Thu, 09 Oct 2003 04:57:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7WbN-0005sg-9T
	for sip@optimus.ietf.org; Thu, 09 Oct 2003 04:56:53 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12347
	for <sip@ietf.org>; Thu, 9 Oct 2003 04:56:44 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7WbK-0003k9-00
	for sip@ietf.org; Thu, 09 Oct 2003 04:56:50 -0400
Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net)
	by ietf-mx with smtp (Exim 4.12)
	id 1A7WbJ-0003k6-00
	for sip@ietf.org; Thu, 09 Oct 2003 04:56:49 -0400
Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net
          via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Thu, 9 Oct 2003 09:59:30 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] RFC 3608 on Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration
Date: Thu, 9 Oct 2003 09:56:15 +0100
Message-ID: <45730E094814E44488F789C1CDED27AE0219B0D7@gbnewp0758m.eu.ubiquity.net>
Thread-Topic: [Sip] RFC 3608 on Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration
Thread-Index: AcON+F1VTQmhXdgrRYuAQ91l2JFobQASej+g
From: "Chris Boulton" <cboulton@ubiquity.net>
To: <dean.willis@softarmor.com>, <hoeneisen@switch.ch>
Cc: <sip@ietf.org>
Content-Transfer-Encoding: quoted-printable
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: quoted-printable

Dean, Bernie,

This may seem a silly question (I'm sure I will be told that it is ;-),
BUT I was wondering why the use of the 'Supported/Require' headers are
not required with this extension.

Regards,

Chris.


>-----Original Message-----
>From: rfc-editor@rfc-editor.org [mailto:rfc-editor@rfc-editor.org]
>Sent: 09 October 2003 01:01
>Cc: rfc-editor@rfc-editor.org; sip@ietf.org
>Subject: [Sip] RFC 3608 on Session Initiation Protocol (SIP) Extension
>Header Field for Service Route Discovery During Registration
>
>
>A new Request for Comments is now available in online RFC libraries.
>
>
>        RFC 3608
>
>        Title:      Session Initiation Protocol (SIP) Extension Header
>                    Field for Service Route Discovery During
>                    Registration
>        Author(s):  D. Willis, B. Hoeneisen
>        Status:     Standards Track
>        Date:       October 2003
>        Mailbox:    dean.willis@softarmor.com, hoeneisen@switch.ch
>        Pages:      17
>        Characters: 35628
>        Updates/Obsoletes/SeeAlso:    None
>
>        I-D Tag:    draft-ietf-sip-scvrtdisco-04.txt
>
>        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3608.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 exim@www1.ietf.org  Thu Oct  9 05:58:37 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14025
	for <sip-archive@odin.ietf.org>; Thu, 9 Oct 2003 05:58:37 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7XYk-0001aW-IL
	for sip-archive@odin.ietf.org; Thu, 09 Oct 2003 05:58:16 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h999wE12006101
	for sip-archive@odin.ietf.org; Thu, 9 Oct 2003 05:58:14 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7XYX-0001Zq-UE; Thu, 09 Oct 2003 05:58:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7XY6-0001YJ-0F
	for sip@optimus.ietf.org; Thu, 09 Oct 2003 05:57:34 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14002
	for <sip@ietf.org>; Thu, 9 Oct 2003 05:57:23 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7XY1-0004Tl-00
	for sip@ietf.org; Thu, 09 Oct 2003 05:57:29 -0400
Received: from central.switch.ch ([130.59.4.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7XXo-0004Ta-00
	for sip@ietf.org; Thu, 09 Oct 2003 05:57:29 -0400
Received: from machb.switch.ch ([130.59.6.129])
	by central.switch.ch with esmtp (Exim 3.20 #1)
	id 1A7XXH-0002Ql-00; Thu, 09 Oct 2003 11:56:43 +0200
Date: Thu, 9 Oct 2003 11:56:43 +0200 (CEST)
From: Bernie Hoeneisen <bhoeneis@switch.ch>
X-X-Sender: bhoeneis@machb.local
To: Chris Boulton <cboulton@ubiquity.net>
cc: Dean Willis <dean.willis@softarmor.com>, sip@ietf.org
Subject: RE: [Sip] RFC 3608 on Session Initiation Protocol (SIP) Extension
 Header Field for Service Route Discovery During Registration
In-Reply-To: <45730E094814E44488F789C1CDED27AE0219B0D7@gbnewp0758m.eu.ubiquity.net>
Message-ID: <Pine.OSX.4.53.0310091119370.13131@machb.local>
References: <45730E094814E44488F789C1CDED27AE0219B0D7@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>

Hi Chris,

Let me make a brief excursion to the history of Service-Route: I remember
some discussions concerning the possible usage of an option-tag for
(P-)Service-Route in the early stage of the I/D. At that time the working
assumption was, that this would be a P-header field
(i.e. P-Service-Route). Since you cannot Require a P-header field, the
discussion immediately ended at that time.

Lateron working assumption was changed: the P-header field was changed to
a normal header field. But nobody has brought up again a requirement
for an option-tag service-route.

In case such a requirement turns out be useful, we could consider to make
an additional document describing the Require/Supported behavior with
Service-Route.

What is your main motivation for such an option-tag for service-route?

cheers,
 Bernie


On Thu, 9 Oct 2003, Chris Boulton wrote:

> Dean, Bernie,
>
> This may seem a silly question (I'm sure I will be told that it is ;-),
> BUT I was wondering why the use of the 'Supported/Require' headers are
> not required with this extension.
>
> Regards,
>
> Chris.
>
>
> >-----Original Message-----
> >From: rfc-editor@rfc-editor.org [mailto:rfc-editor@rfc-editor.org]
> >Sent: 09 October 2003 01:01
> >Cc: rfc-editor@rfc-editor.org; sip@ietf.org
> >Subject: [Sip] RFC 3608 on Session Initiation Protocol (SIP) Extension
> >Header Field for Service Route Discovery During Registration
> >
> >
> >A new Request for Comments is now available in online RFC libraries.
> >
> >
> >        RFC 3608
> >
> >        Title:      Session Initiation Protocol (SIP) Extension Header
> >                    Field for Service Route Discovery During
> >                    Registration
> >        Author(s):  D. Willis, B. Hoeneisen
> >        Status:     Standards Track
> >        Date:       October 2003
> >        Mailbox:    dean.willis@softarmor.com, hoeneisen@switch.ch
> >        Pages:      17
> >        Characters: 35628
> >        Updates/Obsoletes/SeeAlso:    None
> >
> >        I-D Tag:    draft-ietf-sip-scvrtdisco-04.txt
> >
> >        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3608.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
>

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Thu Oct  9 12:43:44 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28209
	for <sip-archive@odin.ietf.org>; Thu, 9 Oct 2003 12:43:44 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7dso-0007dP-Ai
	for sip-archive@odin.ietf.org; Thu, 09 Oct 2003 12:43:23 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h99GhMUf029343
	for sip-archive@odin.ietf.org; Thu, 9 Oct 2003 12:43:22 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7dsT-0007cY-ON; Thu, 09 Oct 2003 12:43:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7dry-0007bE-9N
	for sip@optimus.ietf.org; Thu, 09 Oct 2003 12:42:30 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27994
	for <sip@ietf.org>; Thu, 9 Oct 2003 12:42:20 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7drw-0000ya-00
	for sip@ietf.org; Thu, 09 Oct 2003 12:42:28 -0400
Received: from magus.nostrum.com ([208.21.192.130] ident=root)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7drv-0000yF-00
	for sip@ietf.org; Thu, 09 Oct 2003 12:42:27 -0400
Received: from dynamicsoft.com (ben@localhost [127.0.0.1])
	by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h99Gf8eY089858;
	Thu, 9 Oct 2003 11:41:15 -0500 (CDT)
	(envelope-from bcampbell@dynamicsoft.com)
Message-ID: <3F858F99.8040605@dynamicsoft.com>
Date: Thu, 09 Oct 2003 11:40:57 -0500
From: Ben Campbell <bcampbell@dynamicsoft.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sean Olson <seancolson@yahoo.com>
CC: hisham.khartabil@nokia.com, pkyzivat@cisco.com, aki.niemi@nokia.com,
        rsparks@dynamicsoft.com, sip@ietf.org
Subject: Re: [Sip] Re:draft-ietf-sip-publish-00.txt
References: <20030930190552.85025.qmail@web41507.mail.yahoo.com>
In-Reply-To: <20030930190552.85025.qmail@web41507.mail.yahoo.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

One of the original arguments for using SIP for this publication 
_at_all_ was the ability to use the SIP rendezvous mechanism. We 
expressly considered a use case where a third party service wanted to 
publish data for a user, but the ESC for that user resided at a _client_ 
device that moves around.

Sean Olson wrote:

> Consistency with what? PUBLISH was built as a
> REGISTER++. In that vein, the To: header is used to
> identify the resource while the Request-URI is used to
> identify the ESC. I don't see a point in "forwarding"
> of PUBLISH. Third party PUBLISHing, yes. 
> 
> --- hisham.khartabil@nokia.com wrote:
> 
>>The way Alice gets her PUBLISH to be delivered to
>>Bob is by registering her AOR (using REGISTER) with
>>a contact header that has Bob's URI with parameter
>>method=PUBLISH. Now, what is the use case for Alice
>>to do that? I don't know.
>>
>>About To-header vs. Request-URI: I favour
>>request-URI for consistency.
>>
>>Regards,
>>Hisham
>>
>>
>>>-----Original Message-----
>>>From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com]
>>>Sent: Tuesday, September 30, 2003 4:40 PM
>>>To: Niemi Aki (NMP/Helsinki)
>>>Cc: Robert Sparks; sip@ietf.org
>>>Subject: Re: [Sip]
>>
>>Re:draft-ietf-sip-publish-00.txt
>>
>>>
>>>
>>>
>>>Aki Niemi wrote:
>>>
>>>>Hi,
>>>>
>>>>As long as I can remember, PUBLISH's use of To
>>
>>and From have been 
>>
>>>>consistent with REGISTER all the way down to
>>
>>explicitly 
>>
>>>allowing for 
>>>
>>>>third-party publications.
>>>
>>>The use of From, and 3rd party publications isn't
>>
>>in question 
>>
>>>here. It 
>>>is the unaffected by how the target is selected.
>>>
>>>I admit I haven't been following the development
>>
>>of PUBLISH closely 
>>
>>>enough to remember whether there has agreement on
>>
>>how the target is 
>>
>>>selected. That is why I asked. Apparently Robert
>>
>>thinks there was 
>>
>>>agreement that the request uri would be used,
>>
>>while you seem to think 
>>
>>>that To will be used.
>>>
>>>I think consistency argues for using the request
>>
>>uri, unless some 
>>
>>>compelling argument wins the day. But that is just
>>
>>my opinion.
>>
>>> > The use of Request-URI as identifying the
>>>
>>>>target resource has admittedly been ambiguously
>>
>>defined. 
>>
>>>The way the 
>>>
>>>>draft currently reads is that they are both kind
>>
>>of used - 
>>
>>>which works 
>>>
>>>>fine if they are the same.
>>>
>>>:-)
>>>
>>>
>>>>But I think Paul brings up an important issue
>>
>>about 
>>
>>>forwarding PUBLISH 
>>>
>>>>requests. What is the use case, and the
>>
>>semantics we are 
>>
>>>looking for?
>>>
>>>>1) Alice's PUBLISH gets forwarded to Bob, whose
>>
>>ESC rejects 
>>
>>>the request.
>>>
>>>>  -> Consequently a forwarded subscription will
>>
>>deliver only
>>
>>>>     Bob's presence
>>>>
>>>>2) Alice's PUBLISH gets forwarded to Bob, whose
>>
>>ESC 
>>
>>>composes the event 
>>>
>>>>state into Bob's presence document.
>>>>
>>>>  -> Consequently a forwarded subscription will
>>
>>deliver the union or
>>
>>>>     some combination of Bob's and Alice's
>>
>>presence
>>
>>>>3) Alice's PUBLISH gets forwarded to Bob, whose
>>
>>ESC 
>>
>>>establishes event 
>>>
>>>>state for Alice
>>>>
>>>>  -> Consequently a forwarded subscription will
>>
>>deliver 
>>
>>>Alice's presence
>>>
>>>>     which is now "parked" in Bob's Presence
>>
>>Server
>>
>>>>Out of these three, I especially like the
>>
>>properties of 3). 
>>
>>>It would 
>>>
>>>>allow one to have a static SIP address, e.g., 
>>>
>>>"sip:aki.niemi@iki.fi", 
>>>
>>>>which would be forwarded to whatever service
>>
>>provider one 
>>
>>>was using at 
>>>
>>>>the time, e.g., "sip:aki.niemi@nokia.com", 
>>>>"sip:hillomunkki@foo.someisp.org". In practice,
>>
>>I could "park" the 
>>
>>>>presence of "sip:aki.niemi@iki.fi" into
>>
>>nokia.com, or 
>>
>>>foo.someisp.org's 
>>>
>>>>presence system.
>>>>
>>>>The problem is that by default, a presence
>>
>>server does 
>>
>>>*not* look at the 
>>>
>>>>To-field. It only looks at the Request-URI to
>>
>>determine the 
>>
>>>requested 
>>>
>>>>resource. So a subscription to
>>
>>"sip:aki.niemi@iki.fi" would 
>>
>>>deliver the 
>>>
>>>>presence of a completely different presentity.
>>>
>>>Yes. While (3) may be interesting in some ways, to
>>
>>be useful 
>>
>>>it requires 
>>>a change in the way subscribe works. And I think
>>
>>that would have many 
>>
>>>unintended consequences. While the scenario might
>>
>>be useful for 
>>
>>>presence, it wouldn't be very appealing for other
>>
>>packages, such as 
>>
>>>"dialog".
>>>
>>>
>>>>I don't much like 2), but that's probably
>>
>>because I don't quite 
>>
>>>>understand the use-case. What would the
>>
>>resulting presence 
>>
>>>document look 
>>>
>>>>like? Would it still have
>>
>>entity="pres:bob@biloxi.com", and 
>>
>>>just have 
>>>
>>>>alice's tuples?
>>>
>>>I also can't think of a use case where this is
>>
>>valid. But 
>>
>>>neither can I 
>>>think of a use case where (3) is valid - I can't
>>
>>think of a business 
>>
>>>model where the operator of the presence server
>>
>>for Bob would 
>>
>>>want to do 
>>>this.
>>>
>>>I think (1) is the interesting use case, and it
>>
>>works regardless of 
>>
>>>whether the target is chosen using the request uri
>>
>>or the To uri.
>>
>>> > IMO, this sort of thing could be more easily
>>
>>achieved by
>>
>>>>configuring Alice's EPAs to publish presence
>>
>>directly to 
>>
>>>>sip:bob@biloxi.com.
>>>
>>>I think if Alice is going away and wants to
>>
>>forward calls to 
>>
>>>Bob, that 
>>>she should do something different with her
>>
>>presence. Probably 
>>
>>>configure 
>>>some static state indicating she is away, and
>>
>>listing Bob as an 
>>
>>>alternative contact. Her forwarding should not
>>
>>include 
>>
>>>subscriptions for 
>>>presence.
>>>
>>>If she neglects to do this then all the
>>
>>alternatives seem to provide 
>>
>>>comparably useless results.
>>>
>>>
>>>>So in my opinion, the key issue really is
>>
>>whether we see 3) 
>>
>>>as useful, 
>>>
>>>>and/or feasible. That is the only use-case I can
>>
>>think of 
>>
>>>right now that 
>>>
>>>>would strictly require using the To-field as the
>>
>>resource 
>>
>>>pointer. This 
>>>
>>>>would also require some clarification to RFC
>>
>>3265 on resource 
>>
>>>>identification, so it's not an entirely
>>
>>uncontroversial 
>>
>>>road to take 
>>>
>>>>either.
>>
> === message truncated ===
> 
> 
> __________________________________
> Do you Yahoo!?
> The New Yahoo! Shopping - with improved product search
> http://shopping.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 exim@www1.ietf.org  Thu Oct  9 14:14:33 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02189
	for <sip-archive@odin.ietf.org>; Thu, 9 Oct 2003 14:14:33 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7fIg-0004ws-OQ
	for sip-archive@odin.ietf.org; Thu, 09 Oct 2003 14:14:12 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h99IEAuC019016
	for sip-archive@odin.ietf.org; Thu, 9 Oct 2003 14:14:10 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7fIY-0004vL-2j; Thu, 09 Oct 2003 14:14:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7fI3-0004uT-UP
	for sip@optimus.ietf.org; Thu, 09 Oct 2003 14:13:32 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02156
	for <sip@ietf.org>; Thu, 9 Oct 2003 14:13:23 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7fI1-0002Dj-00
	for sip@ietf.org; Thu, 09 Oct 2003 14:13:29 -0400
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7fI0-0002CW-00
	for sip@ietf.org; Thu, 09 Oct 2003 14:13:28 -0400
Received: from dynamicsoft.com ([63.113.46.71])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h99ID3Ug028518;
	Thu, 9 Oct 2003 14:13:04 -0400 (EDT)
Message-ID: <3F85A527.1050309@dynamicsoft.com>
Date: Thu, 09 Oct 2003 14:12: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.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Bernie Hoeneisen <bhoeneis@switch.ch>
CC: Chris Boulton <cboulton@ubiquity.net>,
        Dean Willis <dean.willis@softarmor.com>, sip@ietf.org
Subject: Re: [Sip] RFC 3608 on Session Initiation Protocol (SIP) Extension
 Header Field for Service Route Discovery During Registration
References: <45730E094814E44488F789C1CDED27AE0219B0D7@gbnewp0758m.eu.ubiquity.net> <Pine.OSX.4.53.0310091119370.13131@machb.local>
In-Reply-To: <Pine.OSX.4.53.0310091119370.13131@machb.local>
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

You can't really add support for a Supported mechanism later, since 
you run into the problem that if Suported is missing from the 
REGISTER, you can't know if thats because service route isn't 
supported, or if it is supported but the new "add Supported to service 
route draft" is not supported.

The reason why Supported makes sense is, without it, the registrar has 
no way to know whether or not the UA will be able to process the 
Service-Route header field in the response. As such, it will end up 
always needing to insert it, even if none of the UAs understand it. 
THat is wasteful.

-Jonathan R.

Bernie Hoeneisen wrote:

> Hi Chris,
> 
> Let me make a brief excursion to the history of Service-Route: I remember
> some discussions concerning the possible usage of an option-tag for
> (P-)Service-Route in the early stage of the I/D. At that time the working
> assumption was, that this would be a P-header field
> (i.e. P-Service-Route). Since you cannot Require a P-header field, the
> discussion immediately ended at that time.
> 
> Lateron working assumption was changed: the P-header field was changed to
> a normal header field. But nobody has brought up again a requirement
> for an option-tag service-route.
> 
> In case such a requirement turns out be useful, we could consider to make
> an additional document describing the Require/Supported behavior with
> Service-Route.
> 
> What is your main motivation for such an option-tag for service-route?
> 
> cheers,
>  Bernie
> 
> 
> On Thu, 9 Oct 2003, Chris Boulton wrote:
> 
> 
>>Dean, Bernie,
>>
>>This may seem a silly question (I'm sure I will be told that it is ;-),
>>BUT I was wondering why the use of the 'Supported/Require' headers are
>>not required with this extension.
>>
>>Regards,
>>
>>Chris.
>>
>>
>>
>>>-----Original Message-----
>>>From: rfc-editor@rfc-editor.org [mailto:rfc-editor@rfc-editor.org]
>>>Sent: 09 October 2003 01:01
>>>Cc: rfc-editor@rfc-editor.org; sip@ietf.org
>>>Subject: [Sip] RFC 3608 on Session Initiation Protocol (SIP) Extension
>>>Header Field for Service Route Discovery During Registration
>>>
>>>
>>>A new Request for Comments is now available in online RFC libraries.
>>>
>>>
>>>       RFC 3608
>>>
>>>       Title:      Session Initiation Protocol (SIP) Extension Header
>>>                   Field for Service Route Discovery During
>>>                   Registration
>>>       Author(s):  D. Willis, B. Hoeneisen
>>>       Status:     Standards Track
>>>       Date:       October 2003
>>>       Mailbox:    dean.willis@softarmor.com, hoeneisen@switch.ch
>>>       Pages:      17
>>>       Characters: 35628
>>>       Updates/Obsoletes/SeeAlso:    None
>>>
>>>       I-D Tag:    draft-ietf-sip-scvrtdisco-04.txt
>>>
>>>       URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3608.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
>>
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP 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.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
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 exim@www1.ietf.org  Thu Oct  9 14:21:27 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02373
	for <sip-archive@odin.ietf.org>; Thu, 9 Oct 2003 14:21:27 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7fPN-0005Sp-78
	for sip-archive@odin.ietf.org; Thu, 09 Oct 2003 14:21:05 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h99IL5Rr020985
	for sip-archive@odin.ietf.org; Thu, 9 Oct 2003 14:21:05 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7fPJ-0005RA-QJ; Thu, 09 Oct 2003 14:21:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7fOd-0005Pl-TK
	for sip@optimus.ietf.org; Thu, 09 Oct 2003 14:20:24 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02359
	for <sip@ietf.org>; Thu, 9 Oct 2003 14:20:11 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7fOb-0002Hm-00
	for sip@ietf.org; Thu, 09 Oct 2003 14:20:17 -0400
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7fOa-0002HP-00
	for sip@ietf.org; Thu, 09 Oct 2003 14:20:16 -0400
Received: from dynamicsoft.com ([63.113.46.71])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h99IJoUg028527;
	Thu, 9 Oct 2003 14:19:52 -0400 (EDT)
Message-ID: <3F85A6BF.2050801@dynamicsoft.com>
Date: Thu, 09 Oct 2003 14:19:43 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Samir Srivastava <ssrivastava@telverse.com>
CC: Dean Willis <dean.willis@softarmor.com>, hisham.khartabil@nokia.com,
        sip@ietf.org
Subject: Re: [Sip] Event Based Heart Beat in SIP
References: <F96BD6D84E58C849A82C730906178517015BF388@dc1.telverse.com>
In-Reply-To: <F96BD6D84E58C849A82C730906178517015BF388@dc1.telverse.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

An application layer heartbeat is definitely the right thing to do. I 
don't think SUBSCRIBE/NOTIFY is the right thing here, since presumably 
the subscription state itself would frequently be lost in the case of 
a failure and restart. Thus, you need some kind of periodic keepalive.

Many implementations do this today with a variety of different 
technqiues. ANythign that solicits a response from any downstream 
element will more or less work. However, care must be taken in 
designing these mechanisms so as not to cause congestion problems. An 
excellent draft has been written on this topic pertaining to 
keepalives in AAA systems. See section 3.4 of RFC 3539. Having a 
documented recommendation for SIP, similar to this section, would be 
beneficial to the community, I think.

-Jonathan R.

Samir Srivastava wrote:

> 
> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]
> Sent: Wednesday, October 08, 2003 12:12 PM
> To: hisham.khartabil@nokia.com
> Cc: Samir Srivastava; sip@ietf.org
> Subject: RE: [Sip] Event Based Heart Beat in SIP
> 
> 
> On Wed, 2003-10-08 at 03:41, hisham.khartabil@nokia.com wrote:
> 
>>Excuse my lack of knowledge about ICMP, but don't you get an ICMP
> 
> error when you send a UDP packet an server that is not listening on the
> port you sent it to?
> 
>>Also for TCP, you get an error when you try to connect the sockets.
>>
>>Someone please correct me if I'm wrong.
> 
> 
> In practical terms, "maybe". If the Internet were pure and
> unadulterated, you'd get an ICMP Port Unreachable response.
> 
> Unfortunately, lots of systems no longer send such ICMP responses, and
> many firewalls block them. It seems that these response codes are useful
> for scanning for "open" ports that might later be victimized.
> 
> SS>> I have also seen them getting blocked. It's good for security.
> 
> In fact, some of my colleagues go so far as to automatically add packet
> filter entries that block future traffic from any address they think
> might be probing them. I really enjoy UDP port-scanning these guys using
> a spoofed address that happens to correspond to their upstream DNS
> server, NTP server, DHCP server, or the like. This holds the same sort
> of fascination as popping packing bubbles or scaring oppossum,
> millipedes, and other creatures that go fetal when one says "boo!" at
> them. But that's another story.
> 
> Also, it is not uncommon for server applications to die in such a way
> that they continue to "listen" to ports, but don't ever respond -- so
> even if ICMP were "live", you'd still get no failure indication. This
> seemed to happen a lot with early SIP servers running on early Java VMs,
> which I believe was related to the threading model in use.
> 
> SS>> This is actually the case, where IP /PORT is reachable, but server 
> doesn't respond because it has got stuck up somewhere else. There can
> be other application level logic problems in some corner cases when
> it can happen. That's why we need the SIP Application level heart beat. 
> The probing client keeps sending the OPTIONS Req to find server's health
> when it is dead w.r.t. issuing signaling responses. To avoid these
> options 
> requests in these "SIP Unreachable time", the client can stop probing
> after
> reaching some threshold, if there is a way to give the responsibilty to 
> server to tell clients when it is ready to process the signaling
> requests. 
>  
> 
> Thx
> Samir
> 
> 
> --
> 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.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
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 exim@www1.ietf.org  Thu Oct  9 14:24:25 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02481
	for <sip-archive@odin.ietf.org>; Thu, 9 Oct 2003 14:24:25 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7fSF-0005rl-Ft
	for sip-archive@odin.ietf.org; Thu, 09 Oct 2003 14:24:04 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h99IO3Zs022472
	for sip-archive@odin.ietf.org; Thu, 9 Oct 2003 14:24:03 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7fSD-0005o7-RL; Thu, 09 Oct 2003 14:24:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7fRf-0005nk-EW
	for sip@optimus.ietf.org; Thu, 09 Oct 2003 14:23:27 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02463
	for <sip@ietf.org>; Thu, 9 Oct 2003 14:23:18 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7fRc-0002K6-00
	for sip@ietf.org; Thu, 09 Oct 2003 14:23:24 -0400
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7fRc-0002Jp-00
	for sip@ietf.org; Thu, 09 Oct 2003 14:23:24 -0400
Received: from dynamicsoft.com ([63.113.46.71])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h99IMxUg028530;
	Thu, 9 Oct 2003 14:22:59 -0400 (EDT)
Message-ID: <3F85A77C.3010907@dynamicsoft.com>
Date: Thu, 09 Oct 2003 14:22:52 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: x.chen@fle.fujitsu.com
CC: sip@ietf.org
Subject: Re: [Sip] Question on draft Indicating User Agent Capabilities in
 the Sessi on Initiation Protocol
References: <E9978DD405A2D611913500047583E37A4D18AA@fle2.fle.fujitsu.com>
In-Reply-To: <E9978DD405A2D611913500047583E37A4D18AA@fle2.fle.fujitsu.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

The q-value is used to indicate preference amongst contacts. The 
q-value is already present in rfc3261.

-Jonathan R.

x.chen@fle.fujitsu.com wrote:

> Hi all,
> 
> I am just thinking this draft can be expanded to include to indicate the
> callee preference information too.
> 
> The use case could be that when user has multiple terminals with different
> capabilities registered as the contact addresses, the user could tell the
> network (in REGISTER) that for which type of services (content), which of
> his terminals (contact addresses) to be used. For example, for Instant
> Messaging with video content, to my laptop (with better display).
> 
> Or maybe this use case has been addressed by another draft? Please let me
> know.
> 
> Regards
>  
> Xin Chen
> Mobile Network Division
> Fujitsu Laboratories Europe
> Tel: +44(0)2086064453
> Mobile: +44(0)7775741020
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> This e-mail has been scanned by Trend InterScan Software.
> 
> This e-mail (and its attachment(s) if any) is intended for the named 
> addressee(s) only. It may
> contain information which is privileged and confidential within the 
> meaning of the applicable law.
> Unauthorised use, copying or disclosure is strictly prohibited and may 
> be unlawful.
> 
> If you are not the intended recipient please delete this email and 
> contact the sender via email return.
> 
> Fujitsu Laboratories of Europe Ltd (FLE) does not accept responsibility 
> for changes made to this email after
> it was sent. The views expressed in this email may not necessarily be 
> the views held by FLE.
> 
> Unless expressly stated otherwise, this email does not form part of a 
> legally binding contract
> or agreement between the recipient and Fujitsu Laboratories of Europe Ltd (FLE).

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
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 exim@www1.ietf.org  Thu Oct  9 14:32:41 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02786
	for <sip-archive@odin.ietf.org>; Thu, 9 Oct 2003 14:32:41 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7faD-0006Sq-Av
	for sip-archive@odin.ietf.org; Thu, 09 Oct 2003 14:32:20 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h99IWHfU024790
	for sip-archive@odin.ietf.org; Thu, 9 Oct 2003 14:32:17 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7fZx-0006MV-Dq; Thu, 09 Oct 2003 14:32:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7fZf-0006LV-7E
	for sip@optimus.ietf.org; Thu, 09 Oct 2003 14:31:43 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02768
	for <SIP@ietf.org>; Thu, 9 Oct 2003 14:31:34 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7fZc-0002QZ-00
	for SIP@ietf.org; Thu, 09 Oct 2003 14:31:40 -0400
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7fZb-0002QF-00
	for SIP@ietf.org; Thu, 09 Oct 2003 14:31:39 -0400
Received: from dynamicsoft.com ([63.113.46.71])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h99IVBUg028540;
	Thu, 9 Oct 2003 14:31:12 -0400 (EDT)
Message-ID: <3F85A968.4020206@dynamicsoft.com>
Date: Thu, 09 Oct 2003 14:31: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.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Elwell, John" <john.elwell@siemens.com>
CC: Jean-Francois Rey <jean-francois.rey@bst.bsf.alcatel.fr>, SIP@ietf.org
Subject: Re: [Sip] Change of display name
References: <50B1CBA96870A34799A506B2313F2667788C4F@ntht201e>
In-Reply-To: <50B1CBA96870A34799A506B2313F2667788C4F@ntht201e>
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 tend to think it makes sense to be able to update a bunch of SIP 
related state through an UPDATE request. This is beyond the currently 
documented scope of UPDATE, though certainly the intent was to allow 
it. Indeed, the original drafts on UPDATE described its usage to solve 
the "HERFP" problem, whereby an UPDATE was used to change credentials, 
require header values, etc., after the initial INVITE. This aspect of 
UPDATE was removed from the main spec because it was less stable, and 
we needed UPDATE for other, more pressing things. However, I have not 
had the time to follow through and revive those yanked portions of 
UPDATE. Presumably such a draft would cover the ability to change 
P-Asserted-ID and other things as well. Volunteers to revive this draft?

-Jonathan R.





Elwell, John wrote:

> Jean-Francois,
> 
> I thought the earlier thread to which you refer was leaning towards the use
> of UPDATE or re-INVITE with revised identity information. A related thread
> was started by Cullen Jennings on 29th August ("Update of display name
> during a call"), proposing the use of a revised display name in a From/To
> header inside an AIB in an UPDATE or re-INVITE request. The thread led to
> the related question of whether a revised P-Asserted-ID header could be
> included in an UPDATE or re-INVITE request, but this appeared to be
> inconclusive.
> 
> John (john.elwell@siemens.com)
> 
> 
> 
>>-----Original Message-----
>>From: Jean-Francois Rey [mailto:jean-francois.rey@bst.bsf.alcatel.fr] 
>>Sent: 01 October 2003 10:53
>>To: SIP@ietf.org
>>Subject: [Sip] Change of display name
>>
>>
>>I'm implementing some attended transfer use cases between a telephone 
>>gateway and SIP phones. I need to update the display name when the 
>>transfer takes place. Unfortunately, if more than one gateway is 
>>involved in the transfer, I cannot use the REFER + replaces 
>>mechanism. I 
>>know that this topic has already been discussed in this list 
>>: Update of 
>>display name during a call 
>>(http://www1.ietf.org/mail-archive/working-groups/sip/current/
>>msg08521.html), 
>>Update and P-Asserted-ID 
>>(http://www1.ietf.org/mail-archive/working-groups/sip/current/
>>msg08142.html). 
>>Unfortunately, I'm still a bit unsure of what is the outcome of these 
>>threads. Using an identity mechanism (a short term one like 
>>P-Asserted-ID or a long term one like AIB) in a UPDATE or re-INVITE 
>>seems a bit underspecified to say the least. Could anyone provide 
>>guidance on these topics : do we have a consensus ? Would 
>>this consensus 
>>go beyond telephone gateways experts and include SIP phone and 
>>application vendors ? Are there any existing documents or planned 
>>actions (new versions of drafts or rfcs, BCP) that would clarify this 
>>topic ?
>>
>>I played a little bit with SIP phones and I found out that a solution 
>>works with many SIP phones : using the usual INVITE + 
>>replaces mechanisms.
>>
>>So instead of the UPDATE + identity solution
>>
>>          Gateway	 Dialog D1	    SIP phone
>>	  |=========================|
>>	  |    (D1)UPDATE	    |
>>	  |------------------------>|
>>
>>I tried this :
>>
>>          Gateway	 Dialog D1	    SIP phone
>>	  |=========================|
>>	  |    (D2)INVITE	    |
>>	  |	(replaces D1)	    |
>>	  |------------------------>|
>>
>>It works fine except if D1 is not confirmed.
>>I understand that
>>- there might be GRUU/routing problems (but nothing new compared to 
>>usual REFER + replaces mechanism),
>>- there are more messages being exchanged than in the UPDATE solution 
>>(but the INVITE + replaces seems the BCP for attended 
>>transfer in SIP).
>>
>>So there are issues. OTOH this solution works with many 
>>implementations, 
>>it can rely on all identity solutions and IMHO it uses nicely the 
>>semantic of replaces (which is needed for attended transfer 
>>between SIP 
>>phones anyway).
>>
>>I'd like to have the community's feeling on that topic.
>>
>>Thanks,
>>Jean-Francois
>>
>>
>>_______________________________________________
>>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>This list is for NEW development of the core SIP 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.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
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 exim@www1.ietf.org  Thu Oct  9 14:43:39 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03184
	for <sip-archive@odin.ietf.org>; Thu, 9 Oct 2003 14:43:39 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7fkr-0007MA-Jy
	for sip-archive@odin.ietf.org; Thu, 09 Oct 2003 14:43:18 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h99IhHsi028268
	for sip-archive@odin.ietf.org; Thu, 9 Oct 2003 14:43:17 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7fkc-0007Dw-7A; Thu, 09 Oct 2003 14:43:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7fkX-0007DO-G8
	for sip@optimus.ietf.org; Thu, 09 Oct 2003 14:42:58 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03153
	for <sip@ietf.org>; Thu, 9 Oct 2003 14:42:48 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7fkU-0002Yp-00
	for sip@ietf.org; Thu, 09 Oct 2003 14:42:54 -0400
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7fkT-0002Yc-00
	for sip@ietf.org; Thu, 09 Oct 2003 14:42:54 -0400
Received: from dynamicsoft.com ([63.113.46.71])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h99IgTUg028547;
	Thu, 9 Oct 2003 14:42:29 -0400 (EDT)
Message-ID: <3F85AC0D.7060100@dynamicsoft.com>
Date: Thu, 09 Oct 2003 14:42:21 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: =?ISO-8859-2?Q?Szel=E9nyi_Csaba?= <Csaba.Szelenyi@t-systems.co.hu>
CC: sip@ietf.org
Subject: Re: [Sip] Question about Expires header in the INVITE request
References: <29026DD9543DBF4BB2B4F9325683E47A0D5C47@MAILSRV.uns.t-systems.tss>
In-Reply-To: <29026DD9543DBF4BB2B4F9325683E47A0D5C47@MAILSRV.uns.t-systems.tss>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by mail3.dynamicsoft.com id h99IgTUg028547
Content-Transfer-Encoding: quoted-printable
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: quoted-printable

Since the Expires header field contains a relative time, measured in=20
seconds, how can it refer to a time in the past? Negative numbers are=20
not allowed.

-Jonathan R.

Szel=E9nyi Csaba wrote:

> Hello,
>=20
> If the INVITE request contains an Expires header with a value of the pa=
st, what answer should/must be generated? '487 Request Terminated' or '40=
8 Request Timeout'?
>=20
> RFC 3261 section 21.4.25 states, that '487 Request Terminated' response=
 is for BYE and CANCEL requests. The '408 Request Timeout' response "enco=
urages" resending the request. So, from this view I would vote for 408.
>=20
> However according to RFC 3261 section 13.3.1 Item 1:
> 	1. If the request is an INVITE that contains an Expires header
> 	field, the UAS core sets a timer for the number of seconds
> 	indicated in the header field value. When the timer fires, the
> 	invitation is considered to be expired. If the invitation
> 	expires before the UAS has generated a final response, a 487
> 	(Request Terminated) response SHOULD be generated.
> IMHO this would lead me to choose 487. And the 408 response means: "cou=
ld not process and answer the request in a certain time"; 408 does not me=
an to me that an errorous request has arrived to the UAS.=20
>=20
> Any oppinion, URL or reference would be highly appreciated.
>=20
> Thank you in advance.
> Regards,
>=20
> Szelenyi Csaba
> T-Systems RIC
> mailto:Csaba.Szelenyi@t-systems.co.hu
> +36 1 456 5507
> +36 20 477 7778
>=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>=20

--=20
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
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 exim@www1.ietf.org  Thu Oct  9 14:50:35 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03424
	for <sip-archive@odin.ietf.org>; Thu, 9 Oct 2003 14:50:35 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7frW-0007qA-Of
	for sip-archive@odin.ietf.org; Thu, 09 Oct 2003 14:50:14 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h99IoAlh030080
	for sip-archive@odin.ietf.org; Thu, 9 Oct 2003 14:50:10 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7frP-0007kt-2n; Thu, 09 Oct 2003 14:50:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7fqO-0007jK-Pa
	for sip@optimus.ietf.org; Thu, 09 Oct 2003 14:49:00 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03396
	for <SIP@ietf.org>; Thu, 9 Oct 2003 14:48:51 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7fqL-0002eL-00
	for SIP@ietf.org; Thu, 09 Oct 2003 14:48:57 -0400
Received: from smtp.sylantro.com ([65.200.90.207] helo=mail.sylantro.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7fqK-0002dx-00
	for SIP@ietf.org; Thu, 09 Oct 2003 14:48:57 -0400
Received: from 10.10.5.1 by mail.sylantro.com with ESMTP (Tumbleweed MMS
 SMTP Relay (MMS v5.5.3)); Thu, 09 Oct 2003 11:48:00 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Sip] Change of display name
Date: Thu, 9 Oct 2003 11:48:00 -0700
Message-ID: <22ACFCD87A5780449EEBDD6D78BB8DB50C3730@sylmail1.sylantro.com>
Thread-Topic: [Sip] Change of display name
Thread-Index: AcOOk7QJPYvpBNeKQ0WSV+QM4JLjmwAAXAOQ
From: "Venkatesh Venkataramanan" <Venkatesh.Venkataramanan@sylantro.com>
To: "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>,
        "Elwell, John" <john.elwell@siemens.com>
cc: "Jean-Francois Rey" <jean-francois.rey@bst.bsf.alcatel.fr>, SIP@ietf.org
X-WSS-ID: 139B72EA73257-01-01
Content-Type: text/plain;
 charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
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: quoted-printable

We had attempted to capture enabling calling/called party display name =
in
http://www.ietf.org/internet-drafts/draft-venkatar-sipping-called-name-00=
.txt .=20

The draft proposed using the P-Asserted-Identity header in UPDATE, REFER =
and SIP response messages to update the calling and the called UA =
displays of name changes.=20

Regards,
Venkatesh

-----Original Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of
Jonathan Rosenberg
Sent: Thursday, October 09, 2003 11:31 AM
To: Elwell, John
Cc: Jean-Francois Rey; SIP@ietf.org
Subject: Re: [Sip] Change of display name


I tend to think it makes sense to be able to update a bunch of SIP=20
related state through an UPDATE request. This is beyond the currently=20
documented scope of UPDATE, though certainly the intent was to allow=20
it. Indeed, the original drafts on UPDATE described its usage to solve=20
the "HERFP" problem, whereby an UPDATE was used to change credentials,=20
require header values, etc., after the initial INVITE. This aspect of=20
UPDATE was removed from the main spec because it was less stable, and=20
we needed UPDATE for other, more pressing things. However, I have not=20
had the time to follow through and revive those yanked portions of=20
UPDATE. Presumably such a draft would cover the ability to change=20
P-Asserted-ID and other things as well. Volunteers to revive this draft?

-Jonathan R.





Elwell, John wrote:

> Jean-Francois,
>=20
> I thought the earlier thread to which you refer was leaning towards =
the use
> of UPDATE or re-INVITE with revised identity information. A related =
thread
> was started by Cullen Jennings on 29th August ("Update of display name
> during a call"), proposing the use of a revised display name in a =
From/To
> header inside an AIB in an UPDATE or re-INVITE request. The thread led =
to
> the related question of whether a revised P-Asserted-ID header could =
be
> included in an UPDATE or re-INVITE request, but this appeared to be
> inconclusive.
>=20
> John (john.elwell@siemens.com)
>=20
>=20
>=20
>>-----Original Message-----
>>From: Jean-Francois Rey [mailto:jean-francois.rey@bst.bsf.alcatel.fr]=20
>>Sent: 01 October 2003 10:53
>>To: SIP@ietf.org
>>Subject: [Sip] Change of display name
>>
>>
>>I'm implementing some attended transfer use cases between a telephone=20
>>gateway and SIP phones. I need to update the display name when the=20
>>transfer takes place. Unfortunately, if more than one gateway is=20
>>involved in the transfer, I cannot use the REFER + replaces=20
>>mechanism. I=20
>>know that this topic has already been discussed in this list=20
>>: Update of=20
>>display name during a call=20
>>(http://www1.ietf.org/mail-archive/working-groups/sip/current/
>>msg08521.html),=20
>>Update and P-Asserted-ID=20
>>(http://www1.ietf.org/mail-archive/working-groups/sip/current/
>>msg08142.html).=20
>>Unfortunately, I'm still a bit unsure of what is the outcome of these=20
>>threads. Using an identity mechanism (a short term one like=20
>>P-Asserted-ID or a long term one like AIB) in a UPDATE or re-INVITE=20
>>seems a bit underspecified to say the least. Could anyone provide=20
>>guidance on these topics : do we have a consensus ? Would=20
>>this consensus=20
>>go beyond telephone gateways experts and include SIP phone and=20
>>application vendors ? Are there any existing documents or planned=20
>>actions (new versions of drafts or rfcs, BCP) that would clarify this=20
>>topic ?
>>
>>I played a little bit with SIP phones and I found out that a solution=20
>>works with many SIP phones : using the usual INVITE +=20
>>replaces mechanisms.
>>
>>So instead of the UPDATE + identity solution
>>
>>          Gateway	 Dialog D1	    SIP phone
>>	  =
|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D|
>>	  |    (D1)UPDATE	    |
>>	  |------------------------>|
>>
>>I tried this :
>>
>>          Gateway	 Dialog D1	    SIP phone
>>	  =
|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D|
>>	  |    (D2)INVITE	    |
>>	  |	(replaces D1)	    |
>>	  |------------------------>|
>>
>>It works fine except if D1 is not confirmed.
>>I understand that
>>- there might be GRUU/routing problems (but nothing new compared to=20
>>usual REFER + replaces mechanism),
>>- there are more messages being exchanged than in the UPDATE solution=20
>>(but the INVITE + replaces seems the BCP for attended=20
>>transfer in SIP).
>>
>>So there are issues. OTOH this solution works with many=20
>>implementations,=20
>>it can rely on all identity solutions and IMHO it uses nicely the=20
>>semantic of replaces (which is needed for attended transfer=20
>>between SIP=20
>>phones anyway).
>>
>>I'd like to have the community's feeling on that topic.
>>
>>Thanks,
>>Jean-Francois
>>
>>
>>_______________________________________________
>>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>This list is for NEW development of the core SIP Protocol
>>Use sip-implementors@cs.columbia.edu for questions on current sip
>>Use sipping@ietf.org for new developments on the application of sip
>>
>=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>=20

--=20
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
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 exim@www1.ietf.org  Thu Oct  9 14:53:25 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03604
	for <sip-archive@odin.ietf.org>; Thu, 9 Oct 2003 14:53:25 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7fuJ-0008AQ-Jm
	for sip-archive@odin.ietf.org; Thu, 09 Oct 2003 14:53:04 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h99Ir33A031377
	for sip-archive@odin.ietf.org; Thu, 9 Oct 2003 14:53:03 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7fuI-000894-2A; Thu, 09 Oct 2003 14:53:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7ftL-000872-OD
	for sip@optimus.ietf.org; Thu, 09 Oct 2003 14:52:04 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03496
	for <sip@ietf.org>; Thu, 9 Oct 2003 14:51:54 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7ftI-0002h0-00
	for sip@ietf.org; Thu, 09 Oct 2003 14:52:00 -0400
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7ftH-0002gT-00
	for sip@ietf.org; Thu, 09 Oct 2003 14:52:00 -0400
Received: from dynamicsoft.com ([63.113.46.71])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h99IpZUg028550;
	Thu, 9 Oct 2003 14:51:35 -0400 (EDT)
Message-ID: <3F85AE2F.10009@dynamicsoft.com>
Date: Thu, 09 Oct 2003 14:51:27 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Noel Crespi <noel.crespi@int-evry.fr>
CC: sip@ietf.org, "'chadli'" <youssef.chadli@int-evry.fr>
Subject: Re: [Sip] Responses path in SIP.
References: <005801c37dbf$3a9f9bb0$f0649f9d@intevry.fr>
In-Reply-To: <005801c37dbf$3a9f9bb0$f0649f9d@intevry.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by mail3.dynamicsoft.com id h99IpZUg028550
Content-Transfer-Encoding: quoted-printable
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: quoted-printable

The Via header MUST be used. The "should" statement in 20.42 is not=20
normative (its not capitalized).

-Jonathan R.

Noel Crespi wrote:

> Hi,
> In the RFC3261 there seems to be a contradiction about the path taken b=
y=20
> the responses in a SIP transaction. It is in clear if=20
> the responses MUST or SHOULD follow the path defined by the Via header=20
> field.=20
> =20
> Different sections in RFC3261 mandate that responses MUST be sent to th=
e=20
> location indicated in the topmost Via header field value, eg:
> - In section 8.1.1.7: "The Via header field indicates the transport use=
d=20
> for the transaction and identifies the location where the response is t=
o=20
> be sent " =20
> - In section 16.7: "The proxy MUST pass the response to the server=20
> transaction associated with the response context. This will result in=20
> the response being sent to the location now indicated in the topmost Vi=
a=20
> header field value"
> - In section 16.11: "If that address matches the proxy,(it equals a=20
> value this proxy has inserted into previous requests)the proxy MUST=20
> remove that header field value from the response and forward the result=
=20
> to the location indicated in the next Via header field value"
> =20
> However section 20.42 states that: "The Via header field indicates the=20
> path taken by the request so far and indicates the path that should be=20
> followed in routing responses"=20
> =20
> So,  MUST or SHOULD responses in a SIP transaction follow  the path=20
> defined by the Via header field?
> =20
> Regards.
> Y.Chadli / N.Crespi
> INT/GET - Institut National des T=E9l=E9communications

--=20
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
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 exim@www1.ietf.org  Thu Oct  9 15:07:38 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04331
	for <sip-archive@odin.ietf.org>; Thu, 9 Oct 2003 15:07:38 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7g84-0000bW-Jr
	for sip-archive@odin.ietf.org; Thu, 09 Oct 2003 15:07:17 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h99J7GCr002264
	for sip-archive@odin.ietf.org; Thu, 9 Oct 2003 15:07:16 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7g7r-0000Vh-4i; Thu, 09 Oct 2003 15:07:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7g6w-0000U4-Dq
	for sip@optimus.ietf.org; Thu, 09 Oct 2003 15:06:06 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04144
	for <sip@ietf.org>; Thu, 9 Oct 2003 15:05:56 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7g6t-0002sD-00
	for sip@ietf.org; Thu, 09 Oct 2003 15:06:03 -0400
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7g6s-0002rm-00
	for sip@ietf.org; Thu, 09 Oct 2003 15:06:02 -0400
Received: from cisco.com (171.68.223.138)
  by sj-iport-3.cisco.com with ESMTP; 09 Oct 2003 12:13:48 -0700
Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14])
	by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h99J5ULt002551;
	Thu, 9 Oct 2003 12:05:30 -0700 (PDT)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AMJ39076;
	Thu, 9 Oct 2003 12:01:22 -0700 (PDT)
Date: Thu, 9 Oct 2003 12:09:54 -0700
Subject: Re: [Sip] Dialog States
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: sip@ietf.org
To: "Karunakara  Rao" <karu_future@rediffmail.com>
From: Rohan Mahy <rohan@cisco.com>
In-Reply-To: <20031008061623.31118.qmail@webmail17.rediffmail.com>
Message-Id: <2A8BBF43-FA8C-11D7-A0FD-0003938AF740@cisco.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
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

yes, you can have two transactions at the same time.  In future, please 
direct these types of questions to the sip-implementors list.

thanks,
-rohan


On Tuesday, October 7, 2003, at 11:16 PM, Karunakara Rao wrote:
> Hi,
> can any one help me!!!
> in 3261 info regd dialog is very limited
> scenario1: a dialog is in confirmed state, 1st UA sent a re-invite, so 
> TU creates a invite-client transaction, and sent the request. then it 
> receives a non-invite request (info/refer etc) from the other 2nd UA
> then can TU create another non-invite server trasaction or should it 
> wait till the 1st inv-cli transaction to get over.
> can there be two transaction at a time....plz clarify.
>
> i wud be glad to get ur reply
>
> Thanks & regards
> Karunakar.


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Thu Oct  9 15:15:48 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05156
	for <sip-archive@odin.ietf.org>; Thu, 9 Oct 2003 15:15:48 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7gFx-0001PF-24
	for sip-archive@odin.ietf.org; Thu, 09 Oct 2003 15:15:25 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h99JFPaI005399
	for sip-archive@odin.ietf.org; Thu, 9 Oct 2003 15:15:25 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7gFa-0001O9-Ps; Thu, 09 Oct 2003 15:15:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7gEn-0001K4-Sj
	for sip@optimus.ietf.org; Thu, 09 Oct 2003 15:14:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04983
	for <sip@ietf.org>; Thu, 9 Oct 2003 15:14:06 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7gEm-0002zd-00
	for sip@ietf.org; Thu, 09 Oct 2003 15:14:12 -0400
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7gEk-0002zJ-00
	for sip@ietf.org; Thu, 09 Oct 2003 15:14:12 -0400
Received: from cisco.com (171.71.177.238)
  by sj-iport-3.cisco.com with ESMTP; 09 Oct 2003 12:21:57 -0700
Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h99JDcXg017600;
	Thu, 9 Oct 2003 12:13:39 -0700 (PDT)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AMJ40315;
	Thu, 9 Oct 2003 12:09:29 -0700 (PDT)
Date: Thu, 9 Oct 2003 12:17:59 -0700
Subject: Re: [Sip] A SIP grammar question.
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: sip@ietf.org
To: Idnani Ajaykumar-AIDNANI1 <Ajaykumar.Idnani@motorola.com>
From: Rohan Mahy <rohan@cisco.com>
In-Reply-To: <8F37768D4D9CD71192CF00065BF2598B931F8D@il27exm02.cig.mot.com>
Message-Id: <4B93ABD8-FA8D-11D7-A0FD-0003938AF740@cisco.com>
Content-Transfer-Encoding: quoted-printable
X-Mailer: Apple Mail (2.552)
Content-Transfer-Encoding: quoted-printable
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: quoted-printable


On Monday, September 29, 2003, at 11:01 AM, Idnani Ajaykumar-AIDNANI1=20
wrote:

> Hi All,
>
> I had a question about the 'From' and 'To' addresses in SIP, and while=20=

> I was going through the grammar, I noticed that the grammar allows for=20=

> a 'From' and 'To' address to NOT have any 'userinfo' in the name-addr=20=

> spec. Is this really desired? Or was this done so as to accommodate=20
> the Request-URI in the same grammar rules? If this was desired, under=20=

> what circumstances one would have a 'From' or 'To' address with no=20
> 'userinfo'. Could you have a 'From' address of 'From: Anonymous=20
> <sip:anonymous.invalid>', when the identity of the caller is to be=20
> hidden?=A0


yes, the grammar is completely fine.  For example, these are all=20
perfectly OK =46rom header fields:

From: <sip:anonymous.invalid>
From: <sip:flight-status.united.com>
From: <sip:elvis.org>

thanks,
-rohan


> For your convenience I am including the relevant grammar lines from=20
> the RFC below.
>
> =A0
>
> FROM ADDRESS
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> =A0
>
> =46rom =3D ( "From" / "f" ) HCOLON from-spec
>
> from-spec=3D ( name-addr / addr-spec )
>
> *( SEMI from-param )
>
> from-param=3D tag-param / generic-param
>
> tag-param=3D "tag" EQUAL token
>
> =A0
>
> TO ADDRESS
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> =A0
>
> To =3D ( "To" / "t" ) HCOLON ( name-addr
>
> / addr-spec ) *( SEMI to-param )
>
> to-param=3D tag-param / generic-param
>
> =A0
>
> REQUEST-URI
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> =A0
>
> Request-URI =3D SIP-URI / SIPS-URI / absoluteURI
>
> absoluteURI=3D scheme ":" ( hier-part / opaque-part )
>
> =A0
>
> NAME-ADDR
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> =A0
>
> name-addr=3D [ display-name ] LAQUOT addr-spec RAQUOT
>
> addr-spec=3D SIP-URI / SIPS-URI / absoluteURI
>
> display-name=3D *(token LWS)/ quoted-string
>
> =A0
>
> SIP-URI =3D "sip:" [ userinfo ] hostport
>
> uri-parameters[ headers ]
>
> SIPS-URI =3D "sips:" [ userinfo ] hostport
>
> uri-parameters[ headers ]
>
> userinfo=3D ( user / telephone-subscriber ) [ ":" password ] "@"
>
> user=3D 1*( unreserved / escaped / user-unreserved )
>
> user-unreserved =3D "&" / "=3D" / "+" / "$" / "," / ";" / "?" / "/"
>
> password=3D *( unreserved / escaped /
>
> "&" / "=3D" / "+" / "$" / "," )
>
> hostport=3D host [ ":" port ]
>
> =A0
>
> =A0
>
> Appreciate your help
>
> =A0
>
> Thanks and Regards
>
> - Ajay
>


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Thu Oct  9 15:50:32 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07460
	for <sip-archive@odin.ietf.org>; Thu, 9 Oct 2003 15:50:32 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7gna-0003gE-8y
	for sip-archive@odin.ietf.org; Thu, 09 Oct 2003 15:50:10 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h99JoAMT014144
	for sip-archive@odin.ietf.org; Thu, 9 Oct 2003 15:50:10 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7gnT-0003fY-SB; Thu, 09 Oct 2003 15:50:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7gmf-0003e7-B7
	for sip@optimus.ietf.org; Thu, 09 Oct 2003 15:49:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07425
	for <sip@ietf.org>; Thu, 9 Oct 2003 15:49:05 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7gmd-0003UB-00
	for sip@ietf.org; Thu, 09 Oct 2003 15:49:11 -0400
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7gmc-0003To-00
	for sip@ietf.org; Thu, 09 Oct 2003 15:49:11 -0400
Received: from dynamicsoft.com ([63.113.46.71])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h99JmdUg028581;
	Thu, 9 Oct 2003 15:48:39 -0400 (EDT)
Message-ID: <3F85BB8F.6010900@dynamicsoft.com>
Date: Thu, 09 Oct 2003 15:48:31 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Rohan Mahy <rohan@cisco.com>
CC: sip@ietf.org
Subject: Re: [Sip] Calle capabilities device ID: take 2
References: <5582537E-D33A-11D7-B410-0003938AF740@cisco.com>
In-Reply-To: <5582537E-D33A-11D7-B410-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

About to rev callee-caps, and wanted to conclude on this point.

Rohan makes a good point. Since we all agree we need GRUU for 
transfer, the use cases for device ID are not clear, and we can 
certainly add a device ID later on if we want. So, I will not include 
device-id, uri-user or uri-domain in the next rev of callee-caps.

Thanks,
Jonathan R.

Rohan Mahy wrote:

> 
> On Wednesday, August 13, 2003, at 11:11 AM, Jonathan Rosenberg wrote:
> 
>> Folks,
>>
>> I posted a note on this about a month back, with no responses. This is 
>> a big remaining open issue in callee caps and we want to resolve it. 
>> So, please take a look and respond.
>>
>> One of the issues I raised today during the meeting was on the utility 
>> of the uri-user and uri-domain parameters in 
>> draft-ietf-sip-callee-caps. The primary purpose that these serve is a 
>> means of identifying a UA instance. In order to accomplish 
>> applicaitons like assisted call transfer, a UA would send INVITE to 
>> the AOR of the transfer target, and include an Accept-Contact with the 
>> uri-user and uri-domain equal to those of the UA instance.
>>
>> Now, it turns out that uri-user and uri-domain are not very helpful 
>> when used this way. GRUU is a better approach. However, thats almost a 
>> secondary issue.
>>
>> The primary issue is that uri-user and uri-domain are ugly, and they 
>> repeat information already in the registration. The suggestion, made 
>> by Paul, was to instead define a device-id attribute. This ID would be 
>> long lived - burned into firmware of a device, perhaps. It would be 
>> included in a registration as a unique ID for the device or software 
>> instance, as the case may be.
>>
>> You could use this callee capability attribute for the assisted 
>> transfer just as you could use uri-user and uri-domain. It has the 
>> same problems that still make GRUU a better solution. However, during 
>> the meeting, folks like the idea of a device-id attribute as something 
>> useful for lots of other applications.
> 
> 
> I agree that a device ID would be useful for lots of things, but not for 
> transfer. I think you really need to use a GRUU for that.
> 
> This identified for me that we may all have some very different ideas 
> about what problems we'd like to solve with a device ID.  So, lets get 
> some requirements on the list (a few sentences each).  If we come to 
> consensus on what we need a device ID for, lets include it.  Otherwise, 
> we can add the appropriate capability or capabilities later.  Lots of 
> stuff depends on callerprefs and callee-caps.  Lets finish them everyone.
> 
> thanks,
> -rohan
> 
> 
>> So, I would like to invite comment and discussion on (1) whether you 
>> like the idea of replacing the uri-user and uri-domain attributes with 
>> device-id (a better name may be needed, like instance-id), (2) what 
>> kind of usages you had in mind for it, for good or for evil.
>>
>> Thanks,
>> Jonathan R.
>> -- 
>> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
>> Chief Technology Officer                    Parsippany, NJ 07054-2711
>> dynamicsoft
>> 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
> 
> 

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
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 exim@www1.ietf.org  Thu Oct  9 16:55:43 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10562
	for <sip-archive@odin.ietf.org>; Thu, 9 Oct 2003 16:55:43 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7hog-0007GU-Bu
	for sip-archive@odin.ietf.org; Thu, 09 Oct 2003 16:55:22 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h99KtMji027873
	for sip-archive@odin.ietf.org; Thu, 9 Oct 2003 16:55:22 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7hoM-0007Er-SX; Thu, 09 Oct 2003 16:55:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7hnY-0007EH-66
	for sip@optimus.ietf.org; Thu, 09 Oct 2003 16:54:12 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10506
	for <sip@ietf.org>; Thu, 9 Oct 2003 16:54:03 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7hnW-0004Ov-00
	for sip@ietf.org; Thu, 09 Oct 2003 16:54:10 -0400
Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7hnV-0004OZ-00
	for sip@ietf.org; Thu, 09 Oct 2003 16:54:09 -0400
Received: from localhost (localhost.localdomain [127.0.0.1])
	by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h99Krbd05547
	for <sip@ietf.org>; Thu, 9 Oct 2003 15:53:37 -0500
From: Robert Sparks <rsparks@dynamicsoft.com>
To: sip@ietf.org
Content-Type: text/plain
Message-Id: <1065732813.942.39.camel@RjS.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.4 
Date: Thu, 09 Oct 2003 15:53:34 -0500
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] SIMPLEt 2
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 second SIMPLE interop event will be held December 3-5, 2003
in Banff, Alberta, Canada hosted by Jasomi Networks.

Registration is open until November 15. Details can be found at
http://simplet.jasomi.com/

RjS


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Thu Oct  9 18:22:44 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14704
	for <sip-archive@odin.ietf.org>; Thu, 9 Oct 2003 18:22:44 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7jAt-0004WG-HJ
	for sip-archive@odin.ietf.org; Thu, 09 Oct 2003 18:22:24 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h99MMNq9017314
	for sip-archive@odin.ietf.org; Thu, 9 Oct 2003 18:22:23 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7jAY-0004UH-PV; Thu, 09 Oct 2003 18:22:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7jAM-0004Ts-Cg
	for sip@optimus.ietf.org; Thu, 09 Oct 2003 18:21:50 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14672
	for <sip@ietf.org>; Thu, 9 Oct 2003 18:21:40 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7jAJ-0005Q4-00
	for sip@ietf.org; Thu, 09 Oct 2003 18:21:47 -0400
Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7jAH-0005Pj-00
	for sip@ietf.org; Thu, 09 Oct 2003 18:21:45 -0400
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h99ML9Tu011770
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
	for <sip@ietf.org>; Thu, 9 Oct 2003 17:21:09 -0500
Received: (from dwillis@localhost)
	by bdsl.greycouncil.com (8.12.8/8.12.8/Submit) id h99ML9St011768
	for sip@ietf.org; Thu, 9 Oct 2003 17:21:09 -0500
X-Authentication-Warning: bdsl.greycouncil.com: dwillis set sender to dean.willis@softarmor.com using -f
From: Dean Willis <dean.willis@softarmor.com>
To: sip@ietf.org
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1065738068.7619.67.camel@bdsl.greycouncil.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 
Date: Thu, 09 Oct 2003 17:21:08 -0500
Content-Transfer-Encoding: 7bit
Subject: [Sip] Agenda topics, 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>
Content-Transfer-Encoding: 7bit


I'll be assembling the SIP WG agenda for Minneapolis. If you have
something you want to talk about, please let me know.

Thanks,

--
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 exim@www1.ietf.org  Fri Oct 10 00:51:53 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25180
	for <sip-archive@odin.ietf.org>; Fri, 10 Oct 2003 00:51:53 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7pFU-0001TX-PL
	for sip-archive@odin.ietf.org; Fri, 10 Oct 2003 00:51:32 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9A4pWnA005613
	for sip-archive@odin.ietf.org; Fri, 10 Oct 2003 00:51:32 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7pF2-0001Mn-0h; Fri, 10 Oct 2003 00:51:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7pE7-0001FY-Ov
	for sip@optimus.ietf.org; Fri, 10 Oct 2003 00:50:07 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25141
	for <sip@ietf.org>; Fri, 10 Oct 2003 00:49:57 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7pE4-0001S0-00
	for sip@ietf.org; Fri, 10 Oct 2003 00:50:04 -0400
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7pE4-0001RL-00
	for sip@ietf.org; Fri, 10 Oct 2003 00:50:04 -0400
Received: from cisco.com (171.71.177.254)
  by sj-iport-3.cisco.com with ESMTP; 09 Oct 2003 21:57:55 -0700
Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9A4nWJs011801;
	Thu, 9 Oct 2003 21:49:32 -0700 (PDT)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AMJ89101;
	Thu, 9 Oct 2003 21:45:19 -0700 (PDT)
Date: Thu, 9 Oct 2003 15:36:56 -0700
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: rohan@cisco.com
To: sip@ietf.org
From: Rohan Mahy <rohan@cisco.com>
Content-Transfer-Encoding: 7bit
Message-Id: <16CE9E1B-FAA9-11D7-A0FD-0003938AF740@cisco.com>
X-Mailer: Apple Mail (2.552)
Content-Transfer-Encoding: 7bit
Subject: [Sip] Is the Join draft ready for WGLC?
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 looked through my notes and I don't see any open issues 
regarding the Join draft.  The document contains additional 
authorization language, it includes a reference to callee-caps for the 
isFocus parameter and is aligned with the conferencing framework and 
cc-conferencing, but does not depend on them. Unless someone can come 
up with a good reason to delay this draft, I will ask Dean to issue a 
WGLC on it.

http://www.ietf.org/internet-drafts/draft-ietf-sip-join-02.txt

many 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 exim@www1.ietf.org  Fri Oct 10 02:03:10 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00781
	for <sip-archive@odin.ietf.org>; Fri, 10 Oct 2003 02:03:10 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7qMS-0005j7-1G
	for sip-archive@odin.ietf.org; Fri, 10 Oct 2003 02:02:48 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9A62ljD021955
	for sip-archive@odin.ietf.org; Fri, 10 Oct 2003 02:02:47 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7qLj-0005gB-2F; Fri, 10 Oct 2003 02:02:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7ZHv-0006kh-Vl
	for sip@optimus.ietf.org; Thu, 09 Oct 2003 07:48:59 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16352
	for <sip@ietf.org>; Thu, 9 Oct 2003 07:48:52 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7ZHv-0005MU-00
	for sip@ietf.org; Thu, 09 Oct 2003 07:48:59 -0400
Received: from [80.74.106.10] (helo=nt-mail.radvision.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7ZHu-0005MR-00
	for sip@ietf.org; Thu, 09 Oct 2003 07:48:58 -0400
Received: from nt-mail.tlv.radvision.com [172.20.2.100]
	by nt-mail.radvision.com
	with XWall v3.26 ;
	Thu, 9 Oct 2003 13:48:32 +0200
Received: by nt-mail.tlv.radvision.com with Internet Mail Service (5.5.2653.19)
	id <4DPLV8AA>; Thu, 9 Oct 2003 13:48:32 +0200
Message-ID: <99FF181D4C99564F8D623069E1DDB25E237C54@nt-mail.tlv.radvision.com>
From: Yochi Moran <ymoran@radvision.com>
To: "'sip@ietf.org'" <sip@ietf.org>
Date: Thu, 9 Oct 2003 13:48:31 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="windows-1255"
Subject: [Sip] TO header in Registration request
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,

Which address ahould be in TO header in REGISTER message:
UA address (name@ua_ip_address ) or proxy address (name@proxy.com)?

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 exim@www1.ietf.org  Fri Oct 10 08:28:50 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24174
	for <sip-archive@odin.ietf.org>; Fri, 10 Oct 2003 08:28:50 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7wNe-0007EL-DN
	for sip-archive@odin.ietf.org; Fri, 10 Oct 2003 08:28:27 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9ACSQbL027787
	for sip-archive@odin.ietf.org; Fri, 10 Oct 2003 08:28:26 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7wNF-0007Cg-K0; Fri, 10 Oct 2003 08:28:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7wMf-0007Br-Id
	for sip@optimus.ietf.org; Fri, 10 Oct 2003 08:27:26 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24121
	for <SIP@ietf.org>; Fri, 10 Oct 2003 08:27:17 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7wMe-0002IU-00
	for SIP@ietf.org; Fri, 10 Oct 2003 08:27:24 -0400
Received: from mailgate.siemenscomms.co.uk ([194.129.217.115])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7wMd-0002Ht-00
	for SIP@ietf.org; Fri, 10 Oct 2003 08:27:23 -0400
Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk
 (PMDF V6.0-24 #40642) id <0HMJ00H01JV68V@siemenscomms.co.uk> for SIP@ietf.org;
 Fri, 10 Oct 2003 13:25:54 +0100 (BST)
Received: from beex10.siemenscomms.co.uk ([137.223.246.252])
 by siemenscomms.co.uk (PMDF V6.0-24 #40642)
 with ESMTP id <0HMJ00HPZJUZ1H@siemenscomms.co.uk>; Fri,
 10 Oct 2003 13:25:47 +0100 (BST)
Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21)
	id <T53CZK4V>; Fri, 10 Oct 2003 13:26:29 +0100
Content-return: allowed
Date: Fri, 10 Oct 2003 13:20:41 +0100
From: "Elwell, John" <john.elwell@siemens.com>
Subject: RE: [Sip] Change of display name
To: "'Venkatesh Venkataramanan'" <Venkatesh.Venkataramanan@sylantro.com>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: Jean-Francois Rey <jean-francois.rey@bst.bsf.alcatel.fr>, SIP@ietf.org
Message-id: <50B1CBA96870A34799A506B2313F266761FD87@ntht201e>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain
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

Venkatesh,

This may well be of interest, but to solve the problem raised at the start
of this thread I would also like to see P-Asserted-ID in an UPDATE or
re-INVITE request.

John (john.elwell@siemens.com)

> -----Original Message-----
> From: Venkatesh Venkataramanan 
> [mailto:Venkatesh.Venkataramanan@sylantro.com] 
> Sent: 09 October 2003 19:48
> To: Jonathan Rosenberg; Elwell, John
> Cc: Jean-Francois Rey; SIP@ietf.org
> Subject: RE: [Sip] Change of display name
> 
> 
> We had attempted to capture enabling calling/called party 
> display name in
> http://www.ietf.org/internet-drafts/draft-venkatar-sipping-cal
> led-name-00.txt . 
> 
> The draft proposed using the P-Asserted-Identity header in 
> UPDATE, REFER and SIP response messages to update the calling 
> and the called UA displays of name changes. 
> 
> Regards,
> Venkatesh
> 
> -----Original Message-----
> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of
> Jonathan Rosenberg
> Sent: Thursday, October 09, 2003 11:31 AM
> To: Elwell, John
> Cc: Jean-Francois Rey; SIP@ietf.org
> Subject: Re: [Sip] Change of display name
> 
> 
> I tend to think it makes sense to be able to update a bunch of SIP 
> related state through an UPDATE request. This is beyond the currently 
> documented scope of UPDATE, though certainly the intent was to allow 
> it. Indeed, the original drafts on UPDATE described its usage 
> to solve 
> the "HERFP" problem, whereby an UPDATE was used to change 
> credentials, 
> require header values, etc., after the initial INVITE. This aspect of 
> UPDATE was removed from the main spec because it was less stable, and 
> we needed UPDATE for other, more pressing things. However, I have not 
> had the time to follow through and revive those yanked portions of 
> UPDATE. Presumably such a draft would cover the ability to change 
> P-Asserted-ID and other things as well. Volunteers to revive 
> this draft?
> 
> -Jonathan R.
> 
> 
> 
> 
> 
> Elwell, John wrote:
> 
> > Jean-Francois,
> > 
> > I thought the earlier thread to which you refer was leaning 
> towards the use
> > of UPDATE or re-INVITE with revised identity information. A 
> related thread
> > was started by Cullen Jennings on 29th August ("Update of 
> display name
> > during a call"), proposing the use of a revised display 
> name in a From/To
> > header inside an AIB in an UPDATE or re-INVITE request. The 
> thread led to
> > the related question of whether a revised P-Asserted-ID 
> header could be
> > included in an UPDATE or re-INVITE request, but this appeared to be
> > inconclusive.
> > 
> > John (john.elwell@siemens.com)
> > 
> > 
> > 
> >>-----Original Message-----
> >>From: Jean-Francois Rey 
> [mailto:jean-francois.rey@bst.bsf.alcatel.fr] 
> >>Sent: 01 October 2003 10:53
> >>To: SIP@ietf.org
> >>Subject: [Sip] Change of display name
> >>
> >>
> >>I'm implementing some attended transfer use cases between a 
> telephone 
> >>gateway and SIP phones. I need to update the display name when the 
> >>transfer takes place. Unfortunately, if more than one gateway is 
> >>involved in the transfer, I cannot use the REFER + replaces 
> >>mechanism. I 
> >>know that this topic has already been discussed in this list 
> >>: Update of 
> >>display name during a call 
> >>(http://www1.ietf.org/mail-archive/working-groups/sip/current/
> >>msg08521.html), 
> >>Update and P-Asserted-ID 
> >>(http://www1.ietf.org/mail-archive/working-groups/sip/current/
> >>msg08142.html). 
> >>Unfortunately, I'm still a bit unsure of what is the 
> outcome of these 
> >>threads. Using an identity mechanism (a short term one like 
> >>P-Asserted-ID or a long term one like AIB) in a UPDATE or re-INVITE 
> >>seems a bit underspecified to say the least. Could anyone provide 
> >>guidance on these topics : do we have a consensus ? Would 
> >>this consensus 
> >>go beyond telephone gateways experts and include SIP phone and 
> >>application vendors ? Are there any existing documents or planned 
> >>actions (new versions of drafts or rfcs, BCP) that would 
> clarify this 
> >>topic ?
> >>
> >>I played a little bit with SIP phones and I found out that 
> a solution 
> >>works with many SIP phones : using the usual INVITE + 
> >>replaces mechanisms.
> >>
> >>So instead of the UPDATE + identity solution
> >>
> >>          Gateway	 Dialog D1	    SIP phone
> >>	  |=========================|
> >>	  |    (D1)UPDATE	    |
> >>	  |------------------------>|
> >>
> >>I tried this :
> >>
> >>          Gateway	 Dialog D1	    SIP phone
> >>	  |=========================|
> >>	  |    (D2)INVITE	    |
> >>	  |	(replaces D1)	    |
> >>	  |------------------------>|
> >>
> >>It works fine except if D1 is not confirmed.
> >>I understand that
> >>- there might be GRUU/routing problems (but nothing new compared to 
> >>usual REFER + replaces mechanism),
> >>- there are more messages being exchanged than in the 
> UPDATE solution 
> >>(but the INVITE + replaces seems the BCP for attended 
> >>transfer in SIP).
> >>
> >>So there are issues. OTOH this solution works with many 
> >>implementations, 
> >>it can rely on all identity solutions and IMHO it uses nicely the 
> >>semantic of replaces (which is needed for attended transfer 
> >>between SIP 
> >>phones anyway).
> >>
> >>I'd like to have the community's feeling on that topic.
> >>
> >>Thanks,
> >>Jean-Francois
> >>
> >>
> >>_______________________________________________
> >>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >>This list is for NEW development of the core SIP 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.                600 Lanidex Plaza
> Chief Technology Officer                    Parsippany, NJ 07054-2711
> dynamicsoft
> 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 exim@www1.ietf.org  Fri Oct 10 10:38:49 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00825
	for <sip-archive@odin.ietf.org>; Fri, 10 Oct 2003 10:38:49 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7yPT-0007Cd-MP
	for sip-archive@odin.ietf.org; Fri, 10 Oct 2003 10:38:28 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AEcRv7027683
	for sip-archive@odin.ietf.org; Fri, 10 Oct 2003 10:38:27 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7yP4-0007B4-15; Fri, 10 Oct 2003 10:38:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7yOU-00070k-UO
	for sip@optimus.ietf.org; Fri, 10 Oct 2003 10:37:26 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00759
	for <sip@ietf.org>; Fri, 10 Oct 2003 10:37:17 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7yOS-0004Bh-00
	for sip@ietf.org; Fri, 10 Oct 2003 10:37:24 -0400
Received: from pmesmtp01.wcom.com ([199.249.20.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7yOR-0004B6-00
	for sip@ietf.org; Fri, 10 Oct 2003 10:37:23 -0400
Received: from pmismtp03.wcomnet.com ([166.38.62.38])
 by firewall.wcom.com (Iplanet MTA 5.2)
 with ESMTP id <0HMJ00L7BPQJGF@firewall.wcom.com> for sip@ietf.org; Fri,
 10 Oct 2003 14:32:43 +0000 (GMT)
Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com
 (iPlanet Messaging Server 5.1 HotFix 0.7 (built May  7 2002))
 with SMTP id <0HMJ00M01PK8AQ@pmismtp03.wcomnet.com>; Fri,
 10 Oct 2003 14:32:43 +0000 (GMT)
Received: from hsinnreich2 ([166.50.113.110])
 by pmismtp03.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7
 2002)) with ESMTP id <0HMJ00LOBPP2BT@pmismtp03.wcomnet.com>; Fri,
 10 Oct 2003 14:31:50 +0000 (GMT)
Date: Fri, 10 Oct 2003 09:31:51 -0500
From: Henry Sinnreich <Henry.Sinnreich@mci.com>
Subject: RE: [Sip] Is the Join draft ready for WGLC?
In-reply-to: <16CE9E1B-FAA9-11D7-A0FD-0003938AF740@cisco.com>
To: "'Rohan Mahy'" <rohan@cisco.com>, sip@ietf.org
Message-id: <0HMJ00LOCPP2BT@pmismtp03.wcomnet.com>
Organization: WorldCom, Inc.
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Mailer: Microsoft Office Outlook, Build 11.0.5329
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
Thread-index: AcOO6lz7mojVkgmOQxuGCN9AeRIhlgAT8BlA
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 have no problem with the last call. This is an excellent basic approach,
though some more complexity may be required in practice. For example, if the
3rd party joins an existing conference, a password and URL may also be
required to join the webshare or data collaboration part of the conference.

Would it be useful to include such an example in some related document? A
topic for the XCON contributors?

Thanks, Henry

Henry Sinnreich

MCI
400 International Parkway
Richardson, Texas 75081
USA

Have you disconnected the PBX?

-----Original Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Rohan Mahy
Sent: Thursday, October 09, 2003 5:37 PM
To: sip@ietf.org
Cc: rohan@cisco.com
Subject: [Sip] Is the Join draft ready for WGLC?

Hi,

I have looked through my notes and I don't see any open issues 
regarding the Join draft.  The document contains additional 
authorization language, it includes a reference to callee-caps for the 
isFocus parameter and is aligned with the conferencing framework and 
cc-conferencing, but does not depend on them. Unless someone can come 
up with a good reason to delay this draft, I will ask Dean to issue a 
WGLC on it.

http://www.ietf.org/internet-drafts/draft-ietf-sip-join-02.txt

many 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 exim@www1.ietf.org  Fri Oct 10 12:04:45 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04852
	for <sip-archive@odin.ietf.org>; Fri, 10 Oct 2003 12:04:45 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7zkd-0004wu-Tu
	for sip-archive@odin.ietf.org; Fri, 10 Oct 2003 12:04:24 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AG4Ni8018966
	for sip-archive@odin.ietf.org; Fri, 10 Oct 2003 12:04:23 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7zkI-0004vC-0v; Fri, 10 Oct 2003 12:04:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7zjz-0004uH-GU
	for sip@optimus.ietf.org; Fri, 10 Oct 2003 12:03:43 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04802
	for <sip@ietf.org>; Fri, 10 Oct 2003 12:03:34 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7zjy-0005XC-00
	for sip@ietf.org; Fri, 10 Oct 2003 12:03:42 -0400
Received: from web21409.mail.yahoo.com ([216.136.232.79])
	by ietf-mx with smtp (Exim 4.12)
	id 1A7zjx-0005X8-00
	for sip@ietf.org; Fri, 10 Oct 2003 12:03:41 -0400
Message-ID: <20031010160338.22566.qmail@web21409.mail.yahoo.com>
Received: from [137.48.136.139] by web21409.mail.yahoo.com via HTTP; Fri, 10 Oct 2003 09:03:38 PDT
Date: Fri, 10 Oct 2003 09:03:38 -0700 (PDT)
From: arun kumar <selva_arun@yahoo.com>
To: sip@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [Sip] Reqesting knowelegge
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 am new to SIP and i wanted to know 

  1. After the server has received INVITE message from
its SIP service provider, why does it need to send the
180 Ringing and 200 OK messages through the proxy
servers as the server now know the location of the
requestor? what are the issues connected by sending
the 180 Ringing and 200 OK messages to the requestor
directly by-passing the proxies servers ? 

 2. Initially why does the requestor sends the INVITE
message to its SIP service provider or proxy servers ?
is it because it wants to make use of its DNS/lookup
services. In that case DNS work on UDP which does not
require any response ?

 I am grateful for all ur help.

 Thanks,
  Arun.

=====
Selvaraj arunkumar
909 South 70th plaza,apt #30
Omaha -68106,Nebraska.
Ph: (Res) 1-402-934-5073
      (Mob) 1-402-850-8926
      (Off) 1-402-554-2034
     
========================

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.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 exim@www1.ietf.org  Fri Oct 10 12:53:35 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06984
	for <sip-archive@odin.ietf.org>; Fri, 10 Oct 2003 12:53:35 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A80Vt-0000oM-OH
	for sip-archive@odin.ietf.org; Fri, 10 Oct 2003 12:53:14 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AGrDZX003060
	for sip-archive@odin.ietf.org; Fri, 10 Oct 2003 12:53:13 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A80Vh-0000mg-Oq; Fri, 10 Oct 2003 12:53:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A80Uo-0000kv-0T
	for sip@optimus.ietf.org; Fri, 10 Oct 2003 12:52:06 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06901
	for <sip@ietf.org>; Fri, 10 Oct 2003 12:51:56 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A80Um-00069I-00
	for sip@ietf.org; Fri, 10 Oct 2003 12:52:04 -0400
Received: from central.switch.ch ([130.59.4.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A80Ul-00068x-00
	for sip@ietf.org; Fri, 10 Oct 2003 12:52:03 -0400
Received: from machb.switch.ch ([130.59.6.129])
	by central.switch.ch with esmtp (Exim 3.20 #1)
	id 1A80UE-0003nr-00; Fri, 10 Oct 2003 18:51:30 +0200
Date: Fri, 10 Oct 2003 18:51:24 +0200 (CEST)
From: Bernie Hoeneisen <bhoeneis@switch.ch>
X-X-Sender: bhoeneis@machb.local
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
cc: Chris Boulton <cboulton@ubiquity.net>,
        Dean Willis <dean.willis@softarmor.com>, sip@ietf.org
Subject: Re: [Sip] RFC 3608 on Session Initiation Protocol (SIP) Extension
 Header Field for Service Route Discovery During Registration
In-Reply-To: <3F85A527.1050309@dynamicsoft.com>
Message-ID: <Pine.OSX.4.53.0310101013240.13131@machb.local>
References: <45730E094814E44488F789C1CDED27AE0219B0D7@gbnewp0758m.eu.ubiquity.net>
 <Pine.OSX.4.53.0310091119370.13131@machb.local> <3F85A527.1050309@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>


On Thu, 9 Oct 2003, Jonathan Rosenberg wrote:

> You can't really add support for a Supported mechanism later, since
> you run into the problem that if Suported is missing from the
> REGISTER, you can't know if thats because service route isn't
> supported, or if it is supported but the new "add Supported to service
> route draft" is not supported.

IMHO there are ways to handle this, e.g. with local policy at the
Registrar.

The question, which remains:
Is there a requirement / use case for standardizing an option tag
"service-route" to be used in Supported and/or Require header fields?

If yes, we could have a closer look at the feasibility.

cheers,
 Bernie



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Fri Oct 10 14:11:38 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10350
	for <sip-archive@odin.ietf.org>; Fri, 10 Oct 2003 14:11:38 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A81jP-00074W-UY
	for sip-archive@odin.ietf.org; Fri, 10 Oct 2003 14:11:16 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AIBFJA027178
	for sip-archive@odin.ietf.org; Fri, 10 Oct 2003 14:11:15 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A81jB-00073b-TG; Fri, 10 Oct 2003 14:11:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A81j4-000738-2c
	for sip@optimus.ietf.org; Fri, 10 Oct 2003 14:10:54 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10316
	for <SIP@ietf.org>; Fri, 10 Oct 2003 14:10:45 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A81j1-00077x-00
	for SIP@ietf.org; Fri, 10 Oct 2003 14:10:51 -0400
Received: from smtp.sylantro.com ([65.200.90.207] helo=mail.sylantro.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A81j0-00077n-00
	for SIP@ietf.org; Fri, 10 Oct 2003 14:10:50 -0400
Received: from 10.10.5.1 by mail.sylantro.com with ESMTP (Tumbleweed MMS
 SMTP Relay (MMS v5.5.3)); Fri, 10 Oct 2003 11:09:53 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Sip] Change of display name
Date: Fri, 10 Oct 2003 11:09:53 -0700
Message-ID: <22ACFCD87A5780449EEBDD6D78BB8DB50C3735@sylmail1.sylantro.com>
Thread-Topic: [Sip] Change of display name
Thread-Index: AcOPKc+Aw0cJR6MVRJiLKcZi72nikgAJIoNA
From: "Venkatesh Venkataramanan" <Venkatesh.Venkataramanan@sylantro.com>
To: "Elwell, John" <john.elwell@siemens.com>,
        "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>
cc: "Jean-Francois Rey" <jean-francois.rey@bst.bsf.alcatel.fr>, SIP@ietf.org
X-WSS-ID: 13982A7B460-01-01
Content-Type: text/plain;
 charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
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: quoted-printable

John:

The discussion at the start of the thread is one of the requirements we =
attempted to solve as a part of this draft (last bullet item mentioned =
in the Requirements section of this draft is to do with updating =
displays in call scenarios like transfers, retrieving a parked call and =
features of that nature).=20

The modified table for P-Asserted-Identity header in this draft, makes =
the header optional in a SIP UPDATE request (enabling this header in =
this request was to satisfy the last requirement). We ended up focusing =
on its usage in a SIP response. We should have added content to clarify =
how we addressed the last requirement and why the draft proposed =
enabling the header in a SIP UPDATE request.

Regards,
Venkatesh

-----Original Message-----
From: Elwell, John [mailto:john.elwell@siemens.com]
Sent: Friday, October 10, 2003 5:21 AM
To: Venkatesh Venkataramanan; Jonathan Rosenberg
Cc: Jean-Francois Rey; SIP@ietf.org
Subject: RE: [Sip] Change of display name


Venkatesh,

This may well be of interest, but to solve the problem raised at the =
start
of this thread I would also like to see P-Asserted-ID in an UPDATE or
re-INVITE request.

John (john.elwell@siemens.com)

> -----Original Message-----
> From: Venkatesh Venkataramanan=20
> [mailto:Venkatesh.Venkataramanan@sylantro.com]=20
> Sent: 09 October 2003 19:48
> To: Jonathan Rosenberg; Elwell, John
> Cc: Jean-Francois Rey; SIP@ietf.org
> Subject: RE: [Sip] Change of display name
>=20
>=20
> We had attempted to capture enabling calling/called party=20
> display name in
> http://www.ietf.org/internet-drafts/draft-venkatar-sipping-cal
> led-name-00.txt .=20
>=20
> The draft proposed using the P-Asserted-Identity header in=20
> UPDATE, REFER and SIP response messages to update the calling=20
> and the called UA displays of name changes.=20
>=20
> Regards,
> Venkatesh
>=20
> -----Original Message-----
> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of
> Jonathan Rosenberg
> Sent: Thursday, October 09, 2003 11:31 AM
> To: Elwell, John
> Cc: Jean-Francois Rey; SIP@ietf.org
> Subject: Re: [Sip] Change of display name
>=20
>=20
> I tend to think it makes sense to be able to update a bunch of SIP=20
> related state through an UPDATE request. This is beyond the currently=20
> documented scope of UPDATE, though certainly the intent was to allow=20
> it. Indeed, the original drafts on UPDATE described its usage=20
> to solve=20
> the "HERFP" problem, whereby an UPDATE was used to change=20
> credentials,=20
> require header values, etc., after the initial INVITE. This aspect of=20
> UPDATE was removed from the main spec because it was less stable, and=20
> we needed UPDATE for other, more pressing things. However, I have not=20
> had the time to follow through and revive those yanked portions of=20
> UPDATE. Presumably such a draft would cover the ability to change=20
> P-Asserted-ID and other things as well. Volunteers to revive=20
> this draft?
>=20
> -Jonathan R.
>=20
>=20
>=20
>=20
>=20
> Elwell, John wrote:
>=20
> > Jean-Francois,
> >=20
> > I thought the earlier thread to which you refer was leaning=20
> towards the use
> > of UPDATE or re-INVITE with revised identity information. A=20
> related thread
> > was started by Cullen Jennings on 29th August ("Update of=20
> display name
> > during a call"), proposing the use of a revised display=20
> name in a From/To
> > header inside an AIB in an UPDATE or re-INVITE request. The=20
> thread led to
> > the related question of whether a revised P-Asserted-ID=20
> header could be
> > included in an UPDATE or re-INVITE request, but this appeared to be
> > inconclusive.
> >=20
> > John (john.elwell@siemens.com)
> >=20
> >=20
> >=20
> >>-----Original Message-----
> >>From: Jean-Francois Rey=20
> [mailto:jean-francois.rey@bst.bsf.alcatel.fr]=20
> >>Sent: 01 October 2003 10:53
> >>To: SIP@ietf.org
> >>Subject: [Sip] Change of display name
> >>
> >>
> >>I'm implementing some attended transfer use cases between a=20
> telephone=20
> >>gateway and SIP phones. I need to update the display name when the=20
> >>transfer takes place. Unfortunately, if more than one gateway is=20
> >>involved in the transfer, I cannot use the REFER + replaces=20
> >>mechanism. I=20
> >>know that this topic has already been discussed in this list=20
> >>: Update of=20
> >>display name during a call=20
> >>(http://www1.ietf.org/mail-archive/working-groups/sip/current/
> >>msg08521.html),=20
> >>Update and P-Asserted-ID=20
> >>(http://www1.ietf.org/mail-archive/working-groups/sip/current/
> >>msg08142.html).=20
> >>Unfortunately, I'm still a bit unsure of what is the=20
> outcome of these=20
> >>threads. Using an identity mechanism (a short term one like=20
> >>P-Asserted-ID or a long term one like AIB) in a UPDATE or re-INVITE=20
> >>seems a bit underspecified to say the least. Could anyone provide=20
> >>guidance on these topics : do we have a consensus ? Would=20
> >>this consensus=20
> >>go beyond telephone gateways experts and include SIP phone and=20
> >>application vendors ? Are there any existing documents or planned=20
> >>actions (new versions of drafts or rfcs, BCP) that would=20
> clarify this=20
> >>topic ?
> >>
> >>I played a little bit with SIP phones and I found out that=20
> a solution=20
> >>works with many SIP phones : using the usual INVITE +=20
> >>replaces mechanisms.
> >>
> >>So instead of the UPDATE + identity solution
> >>
> >>          Gateway	 Dialog D1	    SIP phone
> >>	  =
|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D|
> >>	  |    (D1)UPDATE	    |
> >>	  |------------------------>|
> >>
> >>I tried this :
> >>
> >>          Gateway	 Dialog D1	    SIP phone
> >>	  =
|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D|
> >>	  |    (D2)INVITE	    |
> >>	  |	(replaces D1)	    |
> >>	  |------------------------>|
> >>
> >>It works fine except if D1 is not confirmed.
> >>I understand that
> >>- there might be GRUU/routing problems (but nothing new compared to=20
> >>usual REFER + replaces mechanism),
> >>- there are more messages being exchanged than in the=20
> UPDATE solution=20
> >>(but the INVITE + replaces seems the BCP for attended=20
> >>transfer in SIP).
> >>
> >>So there are issues. OTOH this solution works with many=20
> >>implementations,=20
> >>it can rely on all identity solutions and IMHO it uses nicely the=20
> >>semantic of replaces (which is needed for attended transfer=20
> >>between SIP=20
> >>phones anyway).
> >>
> >>I'd like to have the community's feeling on that topic.
> >>
> >>Thanks,
> >>Jean-Francois
> >>
> >>
> >>_______________________________________________
> >>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >>This list is for NEW development of the core SIP Protocol
> >>Use sip-implementors@cs.columbia.edu for questions on current sip
> >>Use sipping@ietf.org for new developments on the application of sip
> >>
> >=20
> >=20
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip
> >=20
>=20
> --=20
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Technology Officer                    Parsippany, NJ 07054-2711
> dynamicsoft
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>=20
>=20



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Fri Oct 10 16:41:48 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21865
	for <sip-archive@odin.ietf.org>; Fri, 10 Oct 2003 16:41:48 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A844k-0002sf-CB
	for sip-archive@odin.ietf.org; Fri, 10 Oct 2003 16:41:26 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AKfQ4O011015
	for sip-archive@odin.ietf.org; Fri, 10 Oct 2003 16:41:26 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A844O-0002qe-82; Fri, 10 Oct 2003 16:41:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A843X-0002oJ-Mi
	for sip@optimus.ietf.org; Fri, 10 Oct 2003 16:40:11 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21747
	for <sip@ietf.org>; Fri, 10 Oct 2003 16:40:02 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A843V-0002L9-00
	for sip@ietf.org; Fri, 10 Oct 2003 16:40:09 -0400
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A843T-0002Kb-00
	for sip@ietf.org; Fri, 10 Oct 2003 16:40:07 -0400
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9AKdTJs000454;
	Fri, 10 Oct 2003 13:39:29 -0700 (PDT)
Received: from cisco.com ([161.44.79.51])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ADB34158;
	Fri, 10 Oct 2003 16:39:28 -0400 (EDT)
Message-ID: <3F871900.8010309@cisco.com>
Date: Fri, 10 Oct 2003 16:39:28 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Rohan Mahy <rohan@cisco.com>
CC: Idnani Ajaykumar-AIDNANI1 <Ajaykumar.Idnani@motorola.com>, sip@ietf.org
Subject: Re: [Sip] A SIP grammar question.
References: <4B93ABD8-FA8D-11D7-A0FD-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

> On Monday, September 29, 2003, at 11:01 AM, Idnani Ajaykumar-AIDNANI1 
> wrote:
> 
>> Hi All,
>>
>> I had a question about the 'From' and 'To' addresses in SIP, and while 
>> I was going through the grammar, I noticed that the grammar allows for 
>> a 'From' and 'To' address to NOT have any 'userinfo' in the name-addr 
>> spec. Is this really desired? Or was this done so as to accommodate 
>> the Request-URI in the same grammar rules? If this was desired, under 
>> what circumstances one would have a 'From' or 'To' address with no 
>> 'userinfo'. Could you have a 'From' address of 'From: Anonymous 
>> <sip:anonymous.invalid>', when the identity of the caller is to be 
>> hidden? 

The userinfo portion is used to distinguish between different logical 
destinations that share the same address and port. If there is only one 
destination then there is no need for a userpart.

	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 exim@www1.ietf.org  Sat Oct 11 06:54:41 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28459
	for <sip-archive@odin.ietf.org>; Sat, 11 Oct 2003 06:54:41 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A8HO4-0007YN-2a
	for sip-archive@odin.ietf.org; Sat, 11 Oct 2003 06:54:16 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9BAsGTT029036
	for sip-archive@odin.ietf.org; Sat, 11 Oct 2003 06:54:16 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A8HNp-0007Xi-Pm; Sat, 11 Oct 2003 06:54:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A8HNh-0007XQ-1A
	for sip@optimus.ietf.org; Sat, 11 Oct 2003 06:53:53 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28424
	for <sip@ietf.org>; Sat, 11 Oct 2003 06:53:41 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A8HNc-00032h-00
	for sip@ietf.org; Sat, 11 Oct 2003 06:53:48 -0400
Received: from nan-smtp-13.noos.net ([212.198.2.121] helo=smtp.noos.fr)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A8HNb-00032S-00
	for sip@ietf.org; Sat, 11 Oct 2003 06:53:48 -0400
Received: (qmail 6423 invoked by uid 0); 11 Oct 2003 10:53:02 -0000
Received: (qmail 62964493 invoked by uid 0); 9 Oct 2003 07:54:25 -0000
Received: from unknown (HELO asgard.ietf.org) ([132.151.6.40])
          (envelope-sender <owner-ietf-announce@ietf.org>)
          by 212.198.2.77 (qmail-ldap-1.03) with SMTP
          for <chum@noos.fr>; 9 Oct 2003 07:54:25 -0000
Received: from majordomo by asgard.ietf.org with local (Exim 4.14)
	id 1A7OEv-0000Jx-J3
	for ietf-announce-list@asgard.ietf.org; Wed, 08 Oct 2003 20:01:09 -0400
Received: from ietf.org ([10.27.2.28])
	by asgard.ietf.org with esmtp (Exim 4.14)
	id 1A7OEg-0000Ic-2o
	for all-ietf@asgard.ietf.org; Wed, 08 Oct 2003 20:00:54 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15762;
	Wed, 8 Oct 2003 20:00:45 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7OEe-0006BT-00; Wed, 08 Oct 2003 20:00:52 -0400
Received: from gamma.isi.edu ([128.9.144.145])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7OEd-0006BQ-00; Wed, 08 Oct 2003 20:00:51 -0400
Received: from ISI.EDU (jet.isi.edu [128.9.160.87])
	by gamma.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id h9900qO12690;
	Wed, 8 Oct 2003 17:00:52 -0700 (PDT)
Message-Id: <200310090000.h9900qO12690@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: Wed, 08 Oct 2003 17:00:51 -0700
Precedence: bulk
Subject: [Sip] RFC 3608 on Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
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 3608

        Title:      Session Initiation Protocol (SIP) Extension Header
                    Field for Service Route Discovery During
                    Registration
        Author(s):  D. Willis, B. Hoeneisen
        Status:     Standards Track
        Date:       October 2003
        Mailbox:    dean.willis@softarmor.com, hoeneisen@switch.ch
        Pages:      17
        Characters: 35628
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-sip-scvrtdisco-04.txt

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


This document defines a Session Initiation Protocol (SIP) extension
header field used in conjunction with responses to REGISTER requests
to provide a mechanism by which a registrar may inform a registering
user agent (UA) of a service route that the UA may use to request
outbound services from the registrar's domain.

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: <031008165819.RFC@RFC-EDITOR.ORG>

RETRIEVE: rfc
DOC-ID: rfc3608

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

Content-Type: text/plain
Content-ID: <031008165819.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 exim@www1.ietf.org  Sat Oct 11 13:55:44 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07338
	for <sip-archive@odin.ietf.org>; Sat, 11 Oct 2003 13:55:44 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A8NxY-0006zN-IK
	for sip-archive@odin.ietf.org; Sat, 11 Oct 2003 13:55:23 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9BHtKFl026862
	for sip-archive@odin.ietf.org; Sat, 11 Oct 2003 13:55:20 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A8NxG-0006yY-Km; Sat, 11 Oct 2003 13:55:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A8Nx9-0006yF-IJ
	for sip@optimus.ietf.org; Sat, 11 Oct 2003 13:54:55 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07332
	for <sip@ietf.org>; Sat, 11 Oct 2003 13:54:46 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A8Nx7-00063c-00
	for sip@ietf.org; Sat, 11 Oct 2003 13:54:53 -0400
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A8Nx6-00063Z-00
	for sip@ietf.org; Sat, 11 Oct 2003 13:54:52 -0400
Received: from cisco.com (171.71.177.254)
  by sj-iport-3.cisco.com with ESMTP; 11 Oct 2003 11:03:10 -0700
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9BHsKUt009213;
	Sat, 11 Oct 2003 10:54:21 -0700 (PDT)
Received: from [10.0.1.100] (sjc-vpn3-816.cisco.com [10.21.67.48])
	by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AIX95967;
	Sat, 11 Oct 2003 10:54:19 -0700 (PDT)
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Fri, 10 Oct 2003 22:32:33 -0700
Subject: Re: [Sip] SIPIT Interop problem with ;user=phone
From: Cullen Jennings <fluffy@cisco.com>
To: Brian Rosen <Brian.Rosen@marconi.com>, "'Rohan Mahy'" <rohan@cisco.com>,
        Paul Kyzivat <pkyzivat@cisco.com>
CC: "'sip@ietf.org'" <sip@ietf.org>
Message-ID: <BBACE401.200EF%fluffy@cisco.com>
In-Reply-To: <313680C9A886D511A06000204840E1CF070B5F5B@whq-msgusr-02.pit.comms.marconi.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3148714460_4292416"
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.

--B_3148714460_4292416
Content-type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable


At the huge risk of encouraging more messages on this topic.... Would any o=
f
you be willing to summarize the useful conclusions of this thread =AD even
just the outline the main schools of thought even if there is no consensus
on which one should be used.

Cullen



On 10/3/03 10:03, "Rosen, Brian" <Brian.Rosen@marconi.com> wrote:

> I'm pausing, as requested, but several of the proposal's scale.
> =20
> Brian
>> -----Original Message-----
>> From: Francois Audet [mailto:audet@nortelnetworks.com]
>> Sent: Friday, October 03, 2003 12:06 PM
>> To: 'alex.audu@alcatel.com'
>> Cc: 'Rohan Mahy'; 'Rosen, Brian'; 'Paul Kyzivat'; 'Dean Willis'; 'Stastn=
y
>> Richard'; 'Bob Penfield'; 'sip@ietf.org'
>> Subject: RE: [Sip] SIPIT Interop problem with ;user=3Dphone
>>=20
>>=20
>> That's the whole point. It's the only proposal that scales. The other
>> proposals have the problem that they don't scale because they assume a s=
ingle
>> dialing plan per proxy.
>>=20
>> This proposals allows as many dialling plans as you want. This is useful=
 for
>> multi-tennant, geographically disperse enterprises, virtual private tele=
phony
>> services, etc.
>>=20
>>=20
>> -----Original Message-----
>> From: Alex Audu [mailto:alex.audu@alcatel.com]
>> Sent: Friday, October 03, 2003 07:55
>> To: Audet, Francois [SC100:4K02:EXCH]
>> Cc: 'Rohan Mahy'; 'Rosen, Brian'; 'Paul Kyzivat'; 'Dean Willis'; 'Stastn=
y
>> Richard'; 'Bob Penfield'; 'sip@ietf.org'
>> Subject: Re: [Sip] SIPIT Interop problem with ;user=3Dphone
>>=20
>>=20
>> Hello Francois,=20
>> How will your proposal scale?  I am not too sure.
>> Regards,=20
>> Alex.=20
>> Francois Audet wrote:
>>  =20
>>> > Several times in this thread, I have given motivations for
>>> > functionality you can get if you follow my proposal, such as
>>> > one proxy=20
>>> > handling multiple digit maps (for example in a multi-tenant
>>> > situation).=20
>>> >   You have not addressed these cases.  Nobody has provided
>>> > any technical
>>> > reason why my proposal doesn't work, and I have given many
>>> > reasons why=20
>>> > it works.  I will have an ID out in a few days which describes the
>>> > motivations and detailed scenarios for my approach.  Until
>>> > then, let's=20
>>> > please pause this thread.
>> Finally! Agreed 100%.
>>  =20
>=20



--B_3148714460_4292416
Content-type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [Sip] SIPIT Interop problem with ;user=3Dphone</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Verdana"><BR>
At the huge risk of encouraging more messages on this topic.... Would any o=
f you be willing to summarize the useful conclusions of this thread &#8211; =
even just the outline the main schools of thought even if there is no consen=
sus on which one should be used.<BR>
<BR>
Cullen<BR>
<BR>
<BR>
<BR>
On 10/3/03 10:03, &quot;Rosen, Brian&quot; &lt;Brian.Rosen@marconi.com&gt; =
wrote:<BR>
<BR>
</FONT><BLOCKQUOTE><FONT COLOR=3D"#0000FF"><FONT FACE=3D"Arial">I'm pausing, as=
 requested, but several of the proposal's scale.<BR>
</FONT></FONT><FONT FACE=3D"Verdana"> <BR>
</FONT><FONT COLOR=3D"#0000FF"><FONT FACE=3D"Arial">Brian<BR>
</FONT></FONT><BLOCKQUOTE><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma">-----Original =
Message-----<BR>
<B>From:</B> Francois Audet [mailto:audet@nortelnetworks.com]<BR>
<B>Sent:</B> Friday, October 03, 2003 12:06 PM<BR>
<B>To:</B> 'alex.audu@alcatel.com'<BR>
<B>Cc:</B> 'Rohan Mahy'; 'Rosen, Brian'; 'Paul Kyzivat'; 'Dean Willis'; 'St=
astny Richard'; 'Bob Penfield'; 'sip@ietf.org'<BR>
<B>Subject:</B> RE: [Sip] SIPIT Interop problem with ;user=3Dphone<BR>
<BR>
</FONT></FONT><FONT FACE=3D"Verdana"><BR>
<FONT SIZE=3D"2">That's the whole point. It's the only proposal that scales. =
The other proposals have the problem that they don't scale because they assu=
me a single dialing plan per proxy.<BR>
</FONT><BR>
<FONT SIZE=3D"2">This proposals allows as many dialling plans as you want. Th=
is is useful for multi-tennant, geographically disperse enterprises, virtual=
 private telephony services, etc.<BR>
</FONT><BR>
<BR>
<FONT SIZE=3D"2">-----Original Message-----</FONT> <BR>
<FONT SIZE=3D"2">From: Alex Audu [mailto:alex.audu@alcatel.com] <BR>
Sent: Friday, October 03, 2003 07:55</FONT> <BR>
<FONT SIZE=3D"2">To: Audet, Francois [SC100:4K02:EXCH]</FONT> <BR>
<FONT SIZE=3D"2">Cc: 'Rohan Mahy'; 'Rosen, Brian'; 'Paul Kyzivat'; 'Dean Will=
is'; 'Stastny Richard'; 'Bob Penfield'; 'sip@ietf.org'</FONT> <BR>
<FONT SIZE=3D"2">Subject: Re: [Sip] SIPIT Interop problem with ;user=3Dphone</F=
ONT> <BR>
<BR>
<BR>
<FONT SIZE=3D"2">Hello Francois, <BR>
How will your proposal scale? &nbsp;I am not too sure. <BR>
Regards, <BR>
Alex. <BR>
Francois Audet wrote: <BR>
&nbsp;&nbsp;<BR>
&gt; Several times in this thread, I have given motivations for <BR>
&gt; functionality you can get if you follow my proposal, such as <BR>
&gt; one proxy <BR>
&gt; handling multiple digit maps (for example in a multi-tenant <BR>
&gt; situation). <BR>
&gt; &nbsp;&nbsp;You have not addressed these cases. &nbsp;Nobody has provi=
ded <BR>
&gt; any technical <BR>
&gt; reason why my proposal doesn't work, and I have given many <BR>
&gt; reasons why <BR>
&gt; it works. &nbsp;I will have an ID out in a few days which describes th=
e <BR>
&gt; motivations and detailed scenarios for my approach. &nbsp;Until <BR>
&gt; then, let's <BR>
&gt; please pause this thread. <BR>
Finally! Agreed 100%. <BR>
&nbsp;</FONT> <BR>
</FONT></BLOCKQUOTE><FONT FACE=3D"Verdana"><BR>
</FONT></BLOCKQUOTE><FONT FACE=3D"Verdana"><BR>
</FONT>
</BODY>
</HTML>


--B_3148714460_4292416--


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Sat Oct 11 13:59:25 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07445
	for <sip-archive@odin.ietf.org>; Sat, 11 Oct 2003 13:59:25 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A8O19-0007Jc-Jr
	for sip-archive@odin.ietf.org; Sat, 11 Oct 2003 13:59:03 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9BHx38K028075
	for sip-archive@odin.ietf.org; Sat, 11 Oct 2003 13:59:03 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A8O17-0007I4-HT; Sat, 11 Oct 2003 13:59:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A8O0E-0007HK-Re
	for sip@optimus.ietf.org; Sat, 11 Oct 2003 13:58:07 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07419
	for <sip@ietf.org>; Sat, 11 Oct 2003 13:57:57 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A8O0C-00065n-00
	for sip@ietf.org; Sat, 11 Oct 2003 13:58:04 -0400
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A8O0B-00065F-00
	for sip@ietf.org; Sat, 11 Oct 2003 13:58:04 -0400
Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9BHvT5R014272;
	Sat, 11 Oct 2003 10:57:30 -0700 (PDT)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AML01206;
	Sat, 11 Oct 2003 10:53:04 -0700 (PDT)
Date: Sat, 11 Oct 2003 10:50:51 -0700
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: Dean Willis <dean.willis@softarmor.com>, rohan@cisco.com
To: sip@ietf.org
From: Rohan Mahy <rohan@cisco.com>
Content-Transfer-Encoding: 7bit
Message-Id: <7439E026-FC13-11D7-A0FD-0003938AF740@cisco.com>
X-Mailer: Apple Mail (2.552)
Content-Transfer-Encoding: 7bit
Subject: [Sip] WGLC for SIP S/MIME AES 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

Hello Everyone,

I'd like to begin Working Group Last Call on:

http://www.ietf.org/internet-drafts/draft-ietf-sip-smime-aes-01.txt

The only open issue with this draft was a question about adding 
examples.  Instead a more comprehensive examples document is being 
prepared separately.  As far as the author and the chairs are aware 
there are no other issues with the draft.  Please send your comments to 
the list.

WGLC closes on October 31, 2003

many 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 exim@www1.ietf.org  Sat Oct 11 13:59:26 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07460
	for <sip-archive@odin.ietf.org>; Sat, 11 Oct 2003 13:59:26 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A8O1A-0007Lp-6F
	for sip-archive@odin.ietf.org; Sat, 11 Oct 2003 13:59:05 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9BHx3eg028097
	for sip-archive@odin.ietf.org; Sat, 11 Oct 2003 13:59:03 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A8O19-0007Ih-76; Sat, 11 Oct 2003 13:59:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A8O0F-0007HP-Hy
	for sip@optimus.ietf.org; Sat, 11 Oct 2003 13:58:07 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07422
	for <sip@ietf.org>; Sat, 11 Oct 2003 13:57:57 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A8O0D-00065s-00
	for sip@ietf.org; Sat, 11 Oct 2003 13:58:05 -0400
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A8O0C-00065F-00
	for sip@ietf.org; Sat, 11 Oct 2003 13:58:04 -0400
Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9BHvWUt010239;
	Sat, 11 Oct 2003 10:57:33 -0700 (PDT)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AML01207;
	Sat, 11 Oct 2003 10:53:05 -0700 (PDT)
Date: Sat, 11 Oct 2003 10:54:07 -0700
Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: Dean Willis <dean.willis@softarmor.com>, rohan@cisco.com,
        gonzalo.Camarillo@ericsson.com
To: sip@ietf.org
From: Rohan Mahy <rohan@cisco.com>
Content-Transfer-Encoding: 7bit
Message-Id: <E90CE267-FC13-11D7-A0FD-0003938AF740@cisco.com>
X-Mailer: Apple Mail (2.552)
Content-Transfer-Encoding: 7bit
Subject: [Sip] WGLC for URI and Header Parameter Registries
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'd like to begin Working Group Last Call on:

http://www.ietf.org/internet-drafts/draft-ietf-sip-parameter-registry- 
00.txt

	and

http://www.ietf.org/internet-drafts/draft-ietf-sip-uri-parameter-reg- 
00.txt

As agreed at IETF57, the draft will contain a registry of the standard  
parameters.  The group could not come to consensus on whether to  
register non-standard parameters, so we will address this issue at a  
later date.  Please send your comments to the list.

This WGLC ends Oct 31, 2003.

many 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 exim@www1.ietf.org  Sun Oct 12 10:21:51 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19125
	for <sip-archive@odin.ietf.org>; Sun, 12 Oct 2003 10:21:50 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A8h6A-00065p-MU
	for sip-archive@odin.ietf.org; Sun, 12 Oct 2003 10:21:31 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9CELUuT023363
	for sip-archive@odin.ietf.org; Sun, 12 Oct 2003 10:21:30 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A8h5i-00061L-2f; Sun, 12 Oct 2003 10:21:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A8h4o-00060D-L1
	for sip@optimus.ietf.org; Sun, 12 Oct 2003 10:20:06 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19068
	for <sip@ietf.org>; Sun, 12 Oct 2003 10:19:56 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A8h4m-00001E-00
	for sip@ietf.org; Sun, 12 Oct 2003 10:20:04 -0400
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A8h4l-00001B-00
	for sip@ietf.org; Sun, 12 Oct 2003 10:20:04 -0400
Received: from cisco.com (171.68.223.137)
  by sj-iport-3.cisco.com with ESMTP; 12 Oct 2003 07:28:34 -0700
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15])
	by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h9CEJVFA005896;
	Sun, 12 Oct 2003 07:19:31 -0700 (PDT)
Received: from [10.0.1.100] (sjc-vpn2-557.cisco.com [10.21.114.45])
	by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AIY10844;
	Sun, 12 Oct 2003 07:19:30 -0700 (PDT)
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sat, 11 Oct 2003 11:19:24 -0700
Subject: Re: [Sip] WGLC for SIP S/MIME AES draft
From: Cullen Jennings <fluffy@cisco.com>
To: <sip@ietf.org>
CC: Dean Willis <dean.willis@softarmor.com>, Rohan Mahy <rohan@cisco.com>
Message-ID: <BBAD97BC.20172%fluffy@cisco.com>
In-Reply-To: <7439E026-FC13-11D7-A0FD-0003938AF740@cisco.com>
Mime-version: 1.0
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


Looks good to me.

Cullen


On 10/11/03 10:50, "Rohan Mahy" <rohan@cisco.com> wrote:

> Hello Everyone,
> 
> I'd like to begin Working Group Last Call on:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-sip-smime-aes-01.txt
> 
> The only open issue with this draft was a question about adding
> examples.  Instead a more comprehensive examples document is being
> prepared separately.  As far as the author and the chairs are aware
> there are no other issues with the draft.  Please send your comments to
> the list.
> 
> WGLC closes on October 31, 2003
> 
> many 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 exim@www1.ietf.org  Mon Oct 13 10:04:47 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05727
	for <sip-archive@odin.ietf.org>; Mon, 13 Oct 2003 10:04:46 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A93JC-0002rx-9W
	for sip-archive@odin.ietf.org; Mon, 13 Oct 2003 10:04:26 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9DE4Q12011025
	for sip-archive@odin.ietf.org; Mon, 13 Oct 2003 10:04:26 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A93Io-0002kM-NU; Mon, 13 Oct 2003 10:04:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A81BE-00048Q-5X
	for sip@optimus.ietf.org; Fri, 10 Oct 2003 13:35:56 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09102
	for <sip@ietf.org>; Fri, 10 Oct 2003 13:35:47 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A81BB-0006jk-00
	for sip@ietf.org; Fri, 10 Oct 2003 13:35:53 -0400
Received: from zdemail04.zdem.compaq.com ([161.114.112.28])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A81BB-0006jH-00
	for sip@ietf.org; Fri, 10 Oct 2003 13:35:53 -0400
Received: from demexg11.emea.cpqcorp.net (demexg11.emea.cpqcorp.net [16.41.86.63])
	by zdemail04.zdem.compaq.com (Postfix) with ESMTP id 4A0FBC05
	for <sip@ietf.org>; Fri, 10 Oct 2003 19:35:14 +0200 (CEST)
Received: from demexc02.emea.cpqcorp.net ([16.41.86.72]) by demexg11.emea.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673);
	 Fri, 10 Oct 2003 19:35:14 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C38F54.DCAEF384"
Date: Fri, 10 Oct 2003 19:35:13 +0200
Message-ID: <D058F9E891C36C468711FCA4357F742E06F66B@demexc02.emea.cpqcorp.net>
Thread-Topic: interwork timer in RFC 3398
Thread-Index: AcOJVEbFQfuW34ZrS7msVdlaSC+wogF/+8PQ
From: "El Moussawi, Ali" <ali.el-moussawi@hp.com>
To: <sip@ietf.org>
X-OriginalArrivalTime: 10 Oct 2003 17:35:14.0201 (UTC) FILETIME=[DCDD2090:01C38F54]
Subject: [Sip] interwork timer in RFC 3398
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_001_01C38F54.DCAEF384
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello all,
In section 7.1.6 from RFC 3398 (ISUP to SIP mapping), the call flow
talks about interwork timer.
Does this timer correspond to a standard ITU timer (like T9, T7, etc
...) ?
When should it exactly be started ? Right after IAM sent or after ACM
received ?
=20
Another question about the same call flow :
Why does the MGC have to send SDP in his 183, while SDP contained in the
initial INVITE is sufficient to establish early media in backward
direction ?
=20
Thanks a lot !
=20
Ali

------_=_NextPart_001_01C38F54.DCAEF384
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D055343017-10102003><FONT face=3DArial color=3D#0000ff =
size=3D2>Hello=20
all,</FONT></SPAN></DIV>
<DIV><SPAN class=3D055343017-10102003><FONT face=3DArial color=3D#0000ff =
size=3D2>In=20
section 7.1.6 from RFC 3398 (ISUP to SIP mapping), the call flow talks =
about=20
interwork timer.</FONT></SPAN></DIV>
<DIV><SPAN class=3D055343017-10102003><FONT face=3DArial color=3D#0000ff =
size=3D2>Does=20
this timer correspond to a standard ITU timer (like T9, T7, etc ...)=20
?</FONT></SPAN></DIV>
<DIV><SPAN class=3D055343017-10102003><FONT face=3DArial color=3D#0000ff =
size=3D2>When=20
should it exactly be started ? Right after IAM sent or after ACM =
received=20
?</FONT></SPAN></DIV>
<DIV><SPAN class=3D055343017-10102003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D055343017-10102003><FONT face=3DArial color=3D#0000ff =

size=3D2>Another question about the same call flow :</FONT></SPAN></DIV>
<DIV><SPAN class=3D055343017-10102003><FONT face=3DArial color=3D#0000ff =
size=3D2>Why=20
does the MGC have to send SDP in his 183, while SDP contained in the =
initial=20
INVITE is sufficient to establish early media in backward direction=20
?</FONT></SPAN></DIV>
<DIV><SPAN class=3D055343017-10102003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D055343017-10102003><FONT face=3DArial color=3D#0000ff =
size=3D2>Thanks=20
a lot !</FONT></SPAN></DIV>
<DIV><SPAN class=3D055343017-10102003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D055343017-10102003><FONT face=3DArial color=3D#0000ff =

size=3D2>Ali</FONT></SPAN></DIV></BODY></HTML>
=00
------_=_NextPart_001_01C38F54.DCAEF384--

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Mon Oct 13 10:31:42 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07964
	for <sip-archive@odin.ietf.org>; Mon, 13 Oct 2003 10:31:42 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A93jG-0004nb-1p
	for sip-archive@odin.ietf.org; Mon, 13 Oct 2003 10:31:22 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9DEVLpO018386
	for sip-archive@odin.ietf.org; Mon, 13 Oct 2003 10:31:21 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A93iw-0004l1-AP; Mon, 13 Oct 2003 10:31:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A93i4-0004iR-Fq
	for sip@optimus.ietf.org; Mon, 13 Oct 2003 10:30:08 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07805
	for <sip@ietf.org>; Mon, 13 Oct 2003 10:29:58 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A93i2-0003KN-00
	for sip@ietf.org; Mon, 13 Oct 2003 10:30:06 -0400
Received: from mail4.dynamicsoft.com ([63.110.3.100])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A93i1-0003Jm-00
	for sip@ietf.org; Mon, 13 Oct 2003 10:30:05 -0400
Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8])
	by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h9DETJiM009386;
	Mon, 13 Oct 2003 10:29:19 -0400 (EDT)
Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <4X07VHMV>; Mon, 13 Oct 2003 09:29:18 -0500
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E86501@dyn-tx-exch-001.dynamicsoft.com>
From: Adam Roach <adam@dynamicsoft.com>
To: "'El Moussawi, Ali'" <ali.el-moussawi@hp.com>, sip@ietf.org
Subject: RE: [Sip] interwork timer in RFC 3398
Date: Mon, 13 Oct 2003 09:29:18 -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>

> In section 7.1.6 from RFC 3398 (ISUP to SIP mapping), the call flow
> talks about interwork timer. Does this timer correspond to a standard
> ITU timer (like T9, T7, etc ...) ?

No. This timer is necessary to ensure that the ISUP circuit is
freed, even if the SIP endpoint dies. Its value is up to the
implementor; I would allow long enough for the announcement
to be played several times -- probably on the order of 1 minute.

> When should it exactly be started ? Right after IAM sent or
> after ACM received ?

That's really an implementation choice; however, since it's
not necessary unless an ACM is received with a cause code
in it, I would wait for the ACM.

> Another question about the same call flow :
> Why does the MGC have to send SDP in his 183, while SDP
> contained in the initial INVITE is sufficient to establish
> early media in backward direction ?

You're right; it's not strictly necessary in this case. For
most of the early media cases in this document, there was
a potential need for forward media (e.g. to send DTMF to an
IVR system), and this use case was copied largely from those.

/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 exim@www1.ietf.org  Mon Oct 13 12:04:47 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12752
	for <sip-archive@odin.ietf.org>; Mon, 13 Oct 2003 12:04:47 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A95BG-0000m2-Qb
	for sip-archive@odin.ietf.org; Mon, 13 Oct 2003 12:04:26 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9DG4MsV002968
	for sip-archive@odin.ietf.org; Mon, 13 Oct 2003 12:04:22 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A95Aw-0000ii-7z; Mon, 13 Oct 2003 12:04:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A95A3-0000g0-BY
	for sip@optimus.ietf.org; Mon, 13 Oct 2003 12:03:07 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12675
	for <sip@ietf.org>; Mon, 13 Oct 2003 12:02:57 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A95A2-0004kE-00
	for sip@ietf.org; Mon, 13 Oct 2003 12:03:06 -0400
Received: from mgw-x1.nokia.com ([131.228.20.21])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A95A1-0004kB-00
	for sip@ietf.org; Mon, 13 Oct 2003 12:03:05 -0400
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9DG33Z03525
	for <sip@ietf.org>; Mon, 13 Oct 2003 19:03:03 +0300 (EET DST)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T65433d3944ac158f2513e@esvir05nok.ntc.nokia.com>;
 Mon, 13 Oct 2003 19:03:02 +0300
Received: from nokia.com ([10.162.12.114]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Mon, 13 Oct 2003 19:03:01 +0300
Message-ID: <3F8ACCB5.6000804@nokia.com>
Date: Mon, 13 Oct 2003 19:03:01 +0300
From: Aki Niemi <aki.niemi@nokia.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030827
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ext Rohan Mahy <rohan@cisco.com>
CC: sip@ietf.org, Dean Willis <dean.willis@softarmor.com>,
        gonzalo.Camarillo@ericsson.com
Subject: Re: [Sip] WGLC for URI and Header Parameter Registries
References: <E90CE267-FC13-11D7-A0FD-0003938AF740@cisco.com>
In-Reply-To: <E90CE267-FC13-11D7-A0FD-0003938AF740@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 13 Oct 2003 16:03:01.0782 (UTC) FILETIME=[7A863B60:01C391A3]
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 couple of comments to these drafts. I'm not at all against a 
registry for header/URI parameters, I think they are an excellent idea. 
I just think these drafts are incomplete. You can't set up a registry 
without specifying the policy by which the names and numbers in that 
registry get assigned.

For example, the below drafts currently seem to state that header/URI 
parameters are allocated as Specification Required (as per policies in 
RFC2343), i.e., you need an RFC. However, it doesn't state that 
explicitly. It might also be saying that they are allocated based on 
IETF Consensus, or even Standards Action. Simply stating "RFC" isn't enough.

Then to the question of what would be proper policy.

I think a proper policy here would be First Come First Served, or 
something like that. I don't think it's a good idea to require a 
published RFC for all parameters. For example, event package names are 
allocated as First Come First Served and don't require an RFC. Event 
packages can also define event header parameters - why should they 
require an RFC when the package itself didn't?

Also, a nit: the "id" Event header parameter is missing from the initial 
list of header params.

	-- Aki Niemi


On 11.10.2003 20:54, ext Rohan Mahy:
> Hello Everyone,
> 
> I'd like to begin Working Group Last Call on:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-sip-parameter-registry- 
> 00.txt
> 
>     and
> 
> http://www.ietf.org/internet-drafts/draft-ietf-sip-uri-parameter-reg- 
> 00.txt
> 
> As agreed at IETF57, the draft will contain a registry of the standard  
> parameters.  The group could not come to consensus on whether to  
> register non-standard parameters, so we will address this issue at a  
> later date.  Please send your comments to the list.
> 
> This WGLC ends Oct 31, 2003.
> 
> many 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 exim@www1.ietf.org  Mon Oct 13 14:30:39 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19148
	for <sip-archive@odin.ietf.org>; Mon, 13 Oct 2003 14:30:39 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A97SU-00007s-KM
	for sip-archive@odin.ietf.org; Mon, 13 Oct 2003 14:30:18 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9DIUI36000426
	for sip-archive@odin.ietf.org; Mon, 13 Oct 2003 14:30:18 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A97SE-00005w-Rp; Mon, 13 Oct 2003 14:30:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A97S5-00005Y-QR
	for sip@optimus.ietf.org; Mon, 13 Oct 2003 14:29:54 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19073
	for <sip@ietf.org>; Mon, 13 Oct 2003 14:29:44 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A97S3-0006VW-00
	for sip@ietf.org; Mon, 13 Oct 2003 14:29:51 -0400
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A97S2-0006VI-00
	for sip@ietf.org; Mon, 13 Oct 2003 14:29:50 -0400
Received: from cisco.com (171.68.223.138)
  by sj-iport-5.cisco.com with ESMTP; 13 Oct 2003 11:30:01 -0700
Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14])
	by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h9DITIH7028083;
	Mon, 13 Oct 2003 11:29:18 -0700 (PDT)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AML84795;
	Mon, 13 Oct 2003 11:24:30 -0700 (PDT)
Date: Mon, 13 Oct 2003 11:33:42 -0700
Subject: Re: [Sip] TO header in Registration request
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: "'sip@ietf.org'" <sip@ietf.org>
To: Yochi Moran <ymoran@radvision.com>
From: Rohan Mahy <rohan@cisco.com>
In-Reply-To: <99FF181D4C99564F8D623069E1DDB25E237C54@nt-mail.tlv.radvision.com>
Message-Id: <C5C4C2CF-FDAB-11D7-8F17-0003938AF740@cisco.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
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,

In future, please read the examples in RFC3261 and 
draft-ietf-sipping-basic-call-flows-02.txt  before posting these types 
of questions. If you still can't figure out the answer to an 
implementation question such as this, please send to the 
sip-implementors mailing list instead:

> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip

On Thursday, October 9, 2003, at 04:48 AM, Yochi Moran wrote:
> Which address ahould be in TO header in REGISTER message:
> UA address (name@ua_ip_address )

you seem to mean a Contact address here.  a Contact address goes in the 
Contact header.

> or proxy address (name@proxy.com)?

you seem to mean an Address-of-record (AOR).  an AOR goes in the To 
header.

thx,
-r

> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Mon Oct 13 15:38:29 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22877
	for <sip-archive@odin.ietf.org>; Mon, 13 Oct 2003 15:38:29 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A98Vy-0003ai-KW
	for sip-archive@odin.ietf.org; Mon, 13 Oct 2003 15:38:07 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9DJbwJY013795
	for sip-archive@odin.ietf.org; Mon, 13 Oct 2003 15:37:58 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A98V3-0003Gm-P0; Mon, 13 Oct 2003 15:37:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A98Uq-0003GC-7g
	for sip@optimus.ietf.org; Mon, 13 Oct 2003 15:36:48 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22795
	for <sip@ietf.org>; Mon, 13 Oct 2003 15:36:39 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A98Uo-0007Di-00
	for sip@ietf.org; Mon, 13 Oct 2003 15:36:46 -0400
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A98Uo-0007DQ-00
	for sip@ietf.org; Mon, 13 Oct 2003 15:36:46 -0400
Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9DJaCvA016128;
	Mon, 13 Oct 2003 12:36:12 -0700 (PDT)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AML93168;
	Mon, 13 Oct 2003 12:31:27 -0700 (PDT)
Date: Mon, 13 Oct 2003 11:51:54 -0700
Subject: Re: [Sip] Reqesting knowelegge
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: sip@ietf.org
To: arun kumar <selva_arun@yahoo.com>
From: Rohan Mahy <rohan@cisco.com>
In-Reply-To: <20031010160338.22566.qmail@web21409.mail.yahoo.com>
Message-Id: <507239A5-FDAE-11D7-8F17-0003938AF740@cisco.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
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,

Please note the following statement placed at the end of each message 
posted to this mailing list.
> This list is for NEW development of the core SIP Protocol

This mailing list is not an appropriate place to ask general questions 
of a tutorial nature. In addition to the SIP specifications, there are 
several good books on SIP which can help you understand SIP better.  
I've attached some links below.

SIP Demystified
http://www.amazon.com/exec/obidos/ASIN/0071373403/thesipcenter-20

Internet Communications with SIP
http://www.amazon.com/exec/obidos/ASIN/0471413992/thesipcenter-20

SIP: Understanding the Session Initiation Protocol
http://www.amazon.com/exec/obidos/ASIN/1580531687/thesipcenter-20

thanks,
-rohan


On Friday, October 10, 2003, at 09:03 AM, arun kumar wrote:
> Hi,
>     I am new to SIP and i wanted to know
>
>   1. After the server has received INVITE message from
> its SIP service provider, why does it need to send the
> 180 Ringing and 200 OK messages through the proxy
> servers as the server now know the location of the
> requestor? what are the issues connected by sending
> the 180 Ringing and 200 OK messages to the requestor
> directly by-passing the proxies servers ?
>
>  2. Initially why does the requestor sends the INVITE
> message to its SIP service provider or proxy servers ?
> is it because it wants to make use of its DNS/lookup
> services. In that case DNS work on UDP which does not
> require any response ?
>
>  I am grateful for all ur help.
>
>  Thanks,
>   Arun.
>
> =====
> Selvaraj arunkumar
> 909 South 70th plaza,apt #30
> Omaha -68106,Nebraska.
> Ph: (Res) 1-402-934-5073
>       (Mob) 1-402-850-8926
>       (Off) 1-402-554-2034
>
> ========================
>
> __________________________________
> Do you Yahoo!?
> The New Yahoo! Shopping - with improved product search
> http://shopping.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 exim@www1.ietf.org  Tue Oct 14 19:53:37 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10138
	for <sip-archive@odin.ietf.org>; Tue, 14 Oct 2003 19:53:37 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A9YyT-0004fn-SR
	for sip-archive@odin.ietf.org; Tue, 14 Oct 2003 19:53:15 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9ENr98E017959
	for sip-archive@odin.ietf.org; Tue, 14 Oct 2003 19:53:09 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A9YyM-0004fK-8d; Tue, 14 Oct 2003 19:53:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A9YxO-0004ea-By
	for sip@optimus.ietf.org; Tue, 14 Oct 2003 19:52:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10123
	for <sip@ietf.org>; Tue, 14 Oct 2003 19:51:53 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A9YxM-0003i5-00
	for sip@ietf.org; Tue, 14 Oct 2003 19:52:00 -0400
Received: from mail.telverse.com ([4.43.0.5] helo=dc1.telverse.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A9YxL-0003hY-00
	for sip@ietf.org; Tue, 14 Oct 2003 19:52:00 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Event Based Heart Beat in SIP
Date: Tue, 14 Oct 2003 16:51:18 -0700
Message-ID: <F96BD6D84E58C849A82C730906178517015BF38B@dc1.telverse.com>
Thread-Topic: [Sip] Event Based Heart Beat in SIP
Thread-Index: AcOOkf/CVLIRGfjVTVKn7CU4eLGQOAEFWjsQ
From: "Samir Srivastava" <ssrivastava@telverse.com>
To: "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>
Cc: "Dean Willis" <dean.willis@softarmor.com>, <hisham.khartabil@nokia.com>,
        <sip@ietf.org>
Content-Transfer-Encoding: quoted-printable
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: quoted-printable

I am proposing an event similar to "cold-start" trap in SNMP. The way=20
SNMP agents keep track of Trap Subscribers across restarts, SIP servers
can keep track of this proposed event's subscribers. Using the similar=20
approach, I think subscription-state will not be lost in restart and=20
failure.

I looked in 3539, it is like, sending OPTIONS, based on the traffic
monitoring. That's fine.  It also attempts to open the connection=20
periodically, if it goes to closed state. Which is similar to sending
OPTIONS periodically if server is not responding.

We can document receommendation similar to it for SIP. I am willing to
volunteer for it.

Thx
Samir

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Thursday, October 09, 2003 11:20 AM
To: Samir Srivastava
Cc: Dean Willis; hisham.khartabil@nokia.com; sip@ietf.org
Subject: Re: [Sip] Event Based Heart Beat in SIP


An application layer heartbeat is definitely the right thing to do. I=20
don't think SUBSCRIBE/NOTIFY is the right thing here, since presumably=20
the subscription state itself would frequently be lost in the case of=20
a failure and restart. Thus, you need some kind of periodic keepalive.
=20
Many implementations do this today with a variety of different=20
technqiues. ANythign that solicits a response from any downstream=20
element will more or less work. However, care must be taken in=20
designing these mechanisms so as not to cause congestion problems. An=20
excellent draft has been written on this topic pertaining to=20
keepalives in AAA systems. See section 3.4 of RFC 3539. Having a=20
documented recommendation for SIP, similar to this section, would be=20
beneficial to the community, I think.

-Jonathan R.

Samir Srivastava wrote:

>=20
> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]
> Sent: Wednesday, October 08, 2003 12:12 PM
> To: hisham.khartabil@nokia.com
> Cc: Samir Srivastava; sip@ietf.org
> Subject: RE: [Sip] Event Based Heart Beat in SIP
>=20
>=20
> On Wed, 2003-10-08 at 03:41, hisham.khartabil@nokia.com wrote:
>=20
>>Excuse my lack of knowledge about ICMP, but don't you get an ICMP
>=20
> error when you send a UDP packet an server that is not listening on
the
> port you sent it to?
>=20
>>Also for TCP, you get an error when you try to connect the sockets.
>>
>>Someone please correct me if I'm wrong.
>=20
>=20
> In practical terms, "maybe". If the Internet were pure and
> unadulterated, you'd get an ICMP Port Unreachable response.
>=20
> Unfortunately, lots of systems no longer send such ICMP responses, and
> many firewalls block them. It seems that these response codes are
useful
> for scanning for "open" ports that might later be victimized.
>=20
> SS>> I have also seen them getting blocked. It's good for security.
>=20
> In fact, some of my colleagues go so far as to automatically add
packet
> filter entries that block future traffic from any address they think
> might be probing them. I really enjoy UDP port-scanning these guys
using
> a spoofed address that happens to correspond to their upstream DNS
> server, NTP server, DHCP server, or the like. This holds the same sort
> of fascination as popping packing bubbles or scaring oppossum,
> millipedes, and other creatures that go fetal when one says "boo!" at
> them. But that's another story.
>=20
> Also, it is not uncommon for server applications to die in such a way
> that they continue to "listen" to ports, but don't ever respond -- so
> even if ICMP were "live", you'd still get no failure indication. This
> seemed to happen a lot with early SIP servers running on early Java
VMs,
> which I believe was related to the threading model in use.
>=20
> SS>> This is actually the case, where IP /PORT is reachable, but
server=20
> doesn't respond because it has got stuck up somewhere else. There can
> be other application level logic problems in some corner cases when
> it can happen. That's why we need the SIP Application level heart
beat.=20
> The probing client keeps sending the OPTIONS Req to find server's
health
> when it is dead w.r.t. issuing signaling responses. To avoid these
> options=20
> requests in these "SIP Unreachable time", the client can stop probing
> after
> reaching some threshold, if there is a way to give the responsibilty
to=20
> server to tell clients when it is ready to process the signaling
> requests.=20
> =20
>=20
> Thx
> Samir
>=20
>=20
> --
> Dean
>=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>=20

--=20
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
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 exim@www1.ietf.org  Wed Oct 15 04:01:36 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19614
	for <sip-archive@odin.ietf.org>; Wed, 15 Oct 2003 04:01:36 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A9gan-0002B6-8s
	for sip-archive@odin.ietf.org; Wed, 15 Oct 2003 04:01:14 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9F81DCU008314
	for sip-archive@odin.ietf.org; Wed, 15 Oct 2003 04:01:13 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A9gSs-0001fo-0p; Wed, 15 Oct 2003 03:53:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A9gS3-0001d2-7y
	for sip@optimus.ietf.org; Wed, 15 Oct 2003 03:52:11 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19335
	for <sip@ietf.org>; Wed, 15 Oct 2003 03:52:03 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A9gS0-0000oA-00
	for sip@ietf.org; Wed, 15 Oct 2003 03:52:08 -0400
Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A9gRs-0000na-00
	for sip@ietf.org; Wed, 15 Oct 2003 03:52:08 -0400
Received: from K19120a (huawei.com [172.17.1.62])
 by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
 2002)) with ESMTPA id <0HMS00B8FGFJLV@mta0.huawei.com> for sip@ietf.org; Wed,
 15 Oct 2003 15:50:08 +0800 (CST)
Date: Wed, 15 Oct 2003 15:49:51 +0800
From: KangDongping <kangdp@huawei.com>
To: sip@ietf.org
Message-id: <00ae01c392f0$ea8f1dc0$4e04460a@K19120a>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
Content-Transfer-Encoding: 7BIT
Subject: [Sip] about <draft-ietf-sipping-conferencing-models-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

Hi
       At the http://www.watersprings.org/pub/id/index-wgs.html, the <draft-ietf-sipping-conferencing-models-01.txt > was marked by  "expired",  I want know which draft or RFC document replace it?

regards

KangDongping

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Wed Oct 15 14:37:03 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15173
	for <sip-archive@odin.ietf.org>; Wed, 15 Oct 2003 14:37:02 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A9qVk-0001Dg-PE
	for sip-archive@odin.ietf.org; Wed, 15 Oct 2003 14:36:41 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FIaeKC004630
	for sip-archive@odin.ietf.org; Wed, 15 Oct 2003 14:36:40 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A9qV7-0001AH-Iu; Wed, 15 Oct 2003 14:36:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A9qUY-00018j-Hm
	for sip@optimus.ietf.org; Wed, 15 Oct 2003 14:35:26 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15084
	for <sip@ietf.org>; Wed, 15 Oct 2003 14:35:17 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A9qUV-0001VL-00
	for sip@ietf.org; Wed, 15 Oct 2003 14:35:23 -0400
Received: from dgesmtp02.wcom.com ([199.249.16.17])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A9qUV-0001VA-00
	for sip@ietf.org; Wed, 15 Oct 2003 14:35:23 -0400
Received: from pmismtp02.wcomnet.com ([166.38.62.37])
 by firewall.wcom.com (Iplanet MTA 5.2)
 with ESMTP id <0HMT00KHLA5LJQ@firewall.wcom.com> for sip@ietf.org; Wed,
 15 Oct 2003 18:32:09 +0000 (GMT)
Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com
 (iPlanet Messaging Server 5.1 HotFix 0.7 (built May  7 2002))
 with SMTP id <0HMT00E01A1TTN@pmismtp02.wcomnet.com>; Wed,
 15 Oct 2003 18:32:09 +0000 (GMT)
Received: from xs578v3521.mci.com ([166.50.129.18])
 by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7
 2002)) with ESMTP id <0HMT00DPZA3D4T@pmismtp02.wcomnet.com>; Wed,
 15 Oct 2003 18:30:51 +0000 (GMT)
Date: Wed, 15 Oct 2003 13:30:44 -0500
From: Alan Johnston <alan.johnston@mci.com>
Subject: Re: [Sip] about <draft-ietf-sipping-conferencing-models-01.txt >
In-reply-to: <00ae01c392f0$ea8f1dc0$4e04460a@K19120a>
X-Sender: Alan.Johnston@pop.mcit.com
To: KangDongping <kangdp@huawei.com>, sip@ietf.org
Message-id: <5.2.1.1.0.20031015132937.02cd6d88@pop.mcit.com>
MIME-version: 1.0
X-Mailer: QUALCOMM Windows Eudora Version 5.2.1
Content-type: text/plain; charset=us-ascii; format=flowed
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>

http://www.ietf.org/internet-drafts/draft-ietf-sipping-conferencing-framework-00.txt

For latest SIP and SIPPING WG documents, visit the WG charter page (e.g. 
http://www.ietf.org/html.charters/sipping-charter.html)

Thanks,
Alan Johnston
MCI
sip:alan@sipstation.com

At 03:49 PM 10/15/2003 +0800, KangDongping wrote:
>Hi
>        At the http://www.watersprings.org/pub/id/index-wgs.html, the 
> <draft-ietf-sipping-conferencing-models-01.txt > was marked 
> by  "expired",  I want know which draft or RFC document replace it?
>
>regards
>
>KangDongping
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Wed Oct 15 19:43:38 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29835
	for <sip-archive@odin.ietf.org>; Wed, 15 Oct 2003 19:43:38 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A9vIR-0007nJ-Sf
	for sip-archive@odin.ietf.org; Wed, 15 Oct 2003 19:43:17 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FNhFgv029957
	for sip-archive@odin.ietf.org; Wed, 15 Oct 2003 19:43:15 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A9vID-0007mH-HP; Wed, 15 Oct 2003 19:43:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A9vHP-0007lJ-FY
	for sip@optimus.ietf.org; Wed, 15 Oct 2003 19:42:11 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29804
	for <sip@ietf.org>; Wed, 15 Oct 2003 19:42:02 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A9vHN-0005QR-00
	for sip@ietf.org; Wed, 15 Oct 2003 19:42:09 -0400
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A9vHN-0005QH-00
	for sip@ietf.org; Wed, 15 Oct 2003 19:42:09 -0400
Received: from cisco.com (171.71.177.254)
  by sj-iport-3.cisco.com with ESMTP; 15 Oct 2003 16:51:26 -0700
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9FNfbeH008487;
	Wed, 15 Oct 2003 16:41:37 -0700 (PDT)
Received: from [171.71.191.163] (dhcp-171-71-191-163.cisco.com [171.71.191.163])
	by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AJB01869;
	Wed, 15 Oct 2003 16:41:36 -0700 (PDT)
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Wed, 15 Oct 2003 12:16:14 -0700
Subject: Re: [Sip] sip-mib: removal of sipStatusCodeClassesTable
From: Cullen Jennings <fluffy@cisco.com>
To: Kevin Lingle <klingle@cisco.com>
CC: Mary Barnes <mbarnes@nortelnetworks.com>, <orit1@microsoft.com>,
        AC Mahendran <mahendra@qualcomm.com>,
        Jean-Francois Mule <jf.mule@cablelabs.com>, <sip@ietf.org>
Message-ID: <BBB2EB0E.2089B%fluffy@cisco.com>
In-Reply-To: <3F7DAE29.7090806@cisco.com>
Mime-version: 1.0
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


I was suggesting considering removing the whole thing but don't have a super
strong opinion. I'm all for making the MIB as simple as possible to
implement while still providing the relevant information. This aggregated
table might make it easier to use the mib but does not have any extra
information that is not available some other way in the MIB. I'm always
worried about providing the same data two ways and try to provide the data
at the most atomic level.


On 10/3/03 10:13, "Kevin Lingle" <klingle@cisco.com> wrote:

> 
> 
> Cullen Jennings wrote:
>> One tiny comment on this ....
>> 
>> A 407 may not be an indication that anything bad is happening. I'm not sure
>> there is much use in grouping all the 4xx together.
> 
> cullen,
> 
> do i detect, in this comment, that perhap you could see usefulness in
> any of the other classes ;) (eg, 6xx);  or do you still essentially want
> the entire table removed?
> 
> it would be good to hear the views of others (assigned reviewers especially).
> 
> i don't have any great attachement to the table.  i was ready to remove it
> based on cullens original comments and then i got feed back (below)
> with a point of view supporting the concept behind this table.
> 
> if i don't here any other support for the table, then i'll remove it from the
> mib.
> 
> kevin
> 
>> 
>> Cullen
>> 
>> 
>> On 9/26/03 6:38 AM, "Kevin Lingle" <klingle@cisco.com> wrote:
>> 
>> 
>>> additionally...
>>> 
>>> recently i was cc'd on an email where one developer
>>> asked another for a list of statistics that could be
>>> used as a measure of the health/well-being of a sip
>>> proxy.    the developer responded in terms of the sip
>>> stats we have in the sip-common-mib and said the following
>>> about some objects from the sipStatusCodeClassesTable:
>>> 
>>> -----
>>> Successful responses - When calls are successful, these counters
>>> should be going up.
>>> 
>>>   sipStatsSuccessClassIns       Counter32, /* 200 OK response */
>>>   sipStatsSuccessClassOuts      Counter32,
>>> 
>>> Failure responses - A very high value for these counters indicates
>>> calls failing in the network. Typically, if calls are not failing,
>>> these counters should have low values and increment slowly.
>>> 
>>>   sipStatsReqFailClassIns       Counter32, /* 4XX class errors */
>>>   sipStatsReqFailClassOuts      Counter32,
>>>   sipStatsServerFailClassIns    Counter32, /* 5xx class errors */
>>>   sipStatsServerFailClassOuts   Counter32,
>>>   sipStatsGlobalFailClassIns    Counter32, /* 6xx class errors */
>>>   sipStatsGlobalFailClassOuts   Counter32,
>>> --------
>>> 
>>> so i chimed in saying that there was a proposal to
>>> remove this table from the mib.  if that were to
>>> occur, was there a small subset of individual rsp code
>>> counters that could be polled in order to draw
>>> the same conclusion on failures.
>>> 
>>> the answer i got back was that all of the individial
>>> 4xx,5xx,6xx counters.  a subset of "important" counters
>>> really wasn't feasible.
>>> 
>>> if that is the case, then aren't these per class stats
>>> potentially of use in quickly gauging whether a sip system
>>> may be experiencing problems that warrent further investigation?
>>> 
>>> kevin
>>> 
>>> 
>>> Kevin Lingle wrote:
>>> 
>>>> hi all,
>>>> 
>>>> a proposal in on the table to remove this table from
>>>> the SIP-COMMON-MIB.  cullen was the only one of the reviewers
>>>> who raised this issue explicitly.  i wanted to give others a
>>>> chance to comment on it.
>>>> 
>>>> orit, did allude to there being too many counters and suggested
>>>> removal of some summary counters.  he didn't mention this table
>>>> by name though (i don't think).
>>>> 
>>>> these are "summary counters", but were defined this way to give
>>>> a high level (gross) indicator of problems so a manager could
>>>> to and probe a system further for the details.  working at a
>>>> more granular level of rsp code counters would require more polling
>>>> on the part of snmp managers.  that was the thought behind providing
>>>> these aggregate counters.
>>>> 
>>>> http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-07.txt
>>>> 
>>>> comments?
>>>> 
>>>> kevin
>>> 
>> 
>> 
> 


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Thu Oct 16 04:51:57 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25052
	for <sip-archive@odin.ietf.org>; Thu, 16 Oct 2003 04:51:57 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AA3r1-0001CO-VV
	for sip-archive@odin.ietf.org; Thu, 16 Oct 2003 04:51:35 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9G8pU2F004550
	for sip-archive@odin.ietf.org; Thu, 16 Oct 2003 04:51:30 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AA3qa-0001Ai-Bk; Thu, 16 Oct 2003 04:51:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AA3qQ-00019I-To
	for sip@optimus.ietf.org; Thu, 16 Oct 2003 04:50:55 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25031
	for <sip@ietf.org>; Thu, 16 Oct 2003 04:50:44 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AA3qN-0002Fp-00
	for sip@ietf.org; Thu, 16 Oct 2003 04:50:51 -0400
Received: from mta2.huawei.com ([61.144.161.24] helo=huawei.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AA3qI-0002FS-00
	for sip@ietf.org; Thu, 16 Oct 2003 04:50:51 -0400
Received: from huawei.com (localhost [127.0.0.1])
 by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26
 2002)) with ESMTP id <0HMU000QCDXNHP@mta2.huawei.com> for sip@ietf.org; Thu,
 16 Oct 2003 16:51:23 +0800 (CST)
Received: from mailin.huawei.com ([10.18.1.252])
 by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26
 2002)) with ESMTP id <0HMU009W9DXK7X@mta2.huawei.com> for sip@ietf.org; Thu,
 16 Oct 2003 16:51:23 +0800 (CST)
Received: from nkannanCL1068 ([10.18.2.68])
 by mailin.huawei.com (Netscape Messaging Server 4.15)
 with ESMTP id HMUE1W00.O0N; Thu, 16 Oct 2003 16:53:56 +0800
Date: Thu, 16 Oct 2003 14:22:16 +0530
From: Natesan Kannan <nkannan@huawei.com>
Subject: Re: [Sip] interwork timer in RFC 3398
To: Adam Roach <adam@dynamicsoft.com>,
        "'El Moussawi, Ali'" <ali.el-moussawi@hp.com>, sip@ietf.org
Reply-to: Natesan Kannan <nkannan@huawei.com>
Message-id: <003a01c393c2$d75a1750$4402120a@in.huawei.com>
Organization: huawei
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: 
 <9BF66EBF6BEFD942915B4D4D45C051F3E86501@dyn-tx-exch-001.dynamicsoft.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

On a totally different subject wrt to RFC 3398, the state machine in section
7.2 has wrong section numbers for event descriptions, probably copied from
the earlier draft.
Sorry if it has already been taken care of...
-Kannan
*****************************************************************
This e-mail and its attachments contain confidential information from
HUAWEI, which is intended only for the person or entity whose address is
listed above. Any use of the information contained herein in any way
(including, but not limited to, total or partial disclosure, reproduction,
or dissemination) by persons other than the intended recipient(s) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!
*****************************************************************



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Thu Oct 16 09:17:45 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02092
	for <sip-archive@odin.ietf.org>; Thu, 16 Oct 2003 09:17:44 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AA80K-0000j3-3O
	for sip-archive@odin.ietf.org; Thu, 16 Oct 2003 09:17:24 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9GDHNLK002699
	for sip-archive@odin.ietf.org; Thu, 16 Oct 2003 09:17:23 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AA7zy-0007Y3-Kk; Thu, 16 Oct 2003 09:17:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AA7zM-0004oQ-Ii
	for sip@optimus.ietf.org; Thu, 16 Oct 2003 09:16:25 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02045
	for <sip@ietf.org>; Thu, 16 Oct 2003 09:16:14 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AA7zK-0004ie-00
	for sip@ietf.org; Thu, 16 Oct 2003 09:16:22 -0400
Received: from imr2.ericy.com ([198.24.6.3])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AA7zJ-0004iN-00
	for sip@ietf.org; Thu, 16 Oct 2003 09:16:22 -0400
Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51])
	by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id h9GDFfO8007902;
	Thu, 16 Oct 2003 08:15:41 -0500 (CDT)
Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.31.119]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59)
	id S8VDBP1H; Thu, 16 Oct 2003 08:14:59 -0500
Message-ID: <3F8E99FA.1030004@ericsson.com>
Date: Thu, 16 Oct 2003 16:15:38 +0300
X-Sybari-Trust: c83c41b6 406a040f c001c63b 00000138
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Aki Niemi <aki.niemi@nokia.com>
CC: ext Rohan Mahy <rohan@cisco.com>, sip@ietf.org,
        Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] WGLC for URI and Header Parameter Registries
References: <E90CE267-FC13-11D7-A0FD-0003938AF740@cisco.com> <3F8ACCB5.6000804@nokia.com>
In-Reply-To: <3F8ACCB5.6000804@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

Aki,

the policy you are talking about is exactly what the WG could not agree 
on. The conclusion was that, for the time being, we will start keeping 
track of RFC-defined parameters (the two drafts under WGLC). Meanwhile, 
we will work on the proper policy to use in the future. For example, if 
someone defines a SIP parameter in a Nokia technical report, it is OK to 
register it or not... we will count with you for those discussions ;o)

 > Also, a nit: the "id" Event header parameter is missing from the initial
 > list of header params.

Thanks for pointing this out.

Gonzalo


Aki Niemi wrote:

> Hi,
> 
> I have a couple of comments to these drafts. I'm not at all against a 
> registry for header/URI parameters, I think they are an excellent idea. 
> I just think these drafts are incomplete. You can't set up a registry 
> without specifying the policy by which the names and numbers in that 
> registry get assigned.
> 
> For example, the below drafts currently seem to state that header/URI 
> parameters are allocated as Specification Required (as per policies in 
> RFC2343), i.e., you need an RFC. However, it doesn't state that 
> explicitly. It might also be saying that they are allocated based on 
> IETF Consensus, or even Standards Action. Simply stating "RFC" isn't 
> enough.
> 
> Then to the question of what would be proper policy.
> 
> I think a proper policy here would be First Come First Served, or 
> something like that. I don't think it's a good idea to require a 
> published RFC for all parameters. For example, event package names are 
> allocated as First Come First Served and don't require an RFC. Event 
> packages can also define event header parameters - why should they 
> require an RFC when the package itself didn't?
> 
> Also, a nit: the "id" Event header parameter is missing from the initial 
> list of header params.
> 
>     -- Aki Niemi
> 
> 
> On 11.10.2003 20:54, ext Rohan Mahy:
> 
>> Hello Everyone,
>>
>> I'd like to begin Working Group Last Call on:
>>
>> http://www.ietf.org/internet-drafts/draft-ietf-sip-parameter-registry- 
>> 00.txt
>>
>>     and
>>
>> http://www.ietf.org/internet-drafts/draft-ietf-sip-uri-parameter-reg- 
>> 00.txt
>>
>> As agreed at IETF57, the draft will contain a registry of the 
>> standard  parameters.  The group could not come to consensus on 
>> whether to  register non-standard parameters, so we will address this 
>> issue at a  later date.  Please send your comments to the list.
>>
>> This WGLC ends Oct 31, 2003.
>>
>> many 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
> 
> 

-- 
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 exim@www1.ietf.org  Thu Oct 16 09:30:31 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02378
	for <sip-archive@odin.ietf.org>; Thu, 16 Oct 2003 09:30:31 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AA8Ch-0001xE-2M
	for sip-archive@odin.ietf.org; Thu, 16 Oct 2003 09:30:11 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9GDUAX0007403
	for sip-archive@odin.ietf.org; Thu, 16 Oct 2003 09:30:10 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AA8CY-0001tz-KY; Thu, 16 Oct 2003 09:30:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A93pl-0005S3-Vh
	for sip@optimus.ietf.org; Mon, 13 Oct 2003 10:38:05 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08347;
	Mon, 13 Oct 2003 10:37:55 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A93pj-0003UX-00; Mon, 13 Oct 2003 10:38:03 -0400
Received: from mail4.telekom.de ([195.243.210.197])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A93pi-0003TR-00; Mon, 13 Oct 2003 10:38:02 -0400
Received: from g8pbr.blf01.telekom.de by mail2.dmz.telekom.de with ESMTP; Mon, 13 Oct 2003 16:37:14 +0200
Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <4ZRHWLV6>; Mon, 13 Oct 2003 16:37:22 +0200
Message-Id: <953B9B08F98DD61183F8000347AE660102862C5B@G8PPV.blf01.telekom.de>
From: "Jesske, R" <R.Jesske@t-com.net>
To: sip@ietf.org, sipping@ietf.org
Date: Mon, 13 Oct 2003 16:37:15 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
Subject: [Sip] WG: draft-mahy-iptel-cpc-00
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: quoted-printable

Hello
In Absense of any oppinion within the IPTEL WG I would like to ask the =
SIP/SIPPING Group if there is any oppinion about this issue?

Best Regards

Roland

-----Urspr=FCngliche Nachricht-----
Von: Jesske, Roland=20
Gesendet: Dienstag, 7. Oktober 2003 13:31
An: iptel@ietf.org
Cc: Alexeitsev, Denis; P=F6tzl, Joachim; Tolksdorf, Christian; =
Sch=FCtte,
Wolfgang; Pinker, Gerold; Benz, Robert
Betreff: draft-mahy-iptel-cpc-00=20


Dear all,
With regard to the draft draft-mahy-iptel-cpc-00 are there any =
activities to extend the tel URI with the cpc parameter?
If yes where I can find more information? If no what is needed to put =
this forward as an issue.

I'm also looking on interworking the Closed User Group PSTN/ISDN =
Supplementary Service with SIP. To make this service also available =
within SIP a extension with the regarding ISUP indications (Closed user =
group interlock code and Closed user group call indicator) are needed.

As they have the same character as the CPC I'm wondering if some body =
had some thoughts on an extension of the tel URI with such kind of =
parameters to make the CUG Service also in SIP available.

Best Regards

Roland Jesske





Deutsche Telekom AG
T Com Zentrale
Roland Jesske, T38-12
Section T38; Signalling, Gateways and Switching Systems=20
Am Kavalleriesand 3, 64295 Darmstadt, Germany
Phone:  +49 6151 83-5940=20
Fax:      +49 6151 83-4577=20
email:   r.jesske@t-com.net




_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Thu Oct 16 10:17:02 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02377
	for <sip-archive@odin.ietf.org>; Thu, 16 Oct 2003 09:30:31 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AA8Ch-0001xM-3D
	for sip-archive@odin.ietf.org; Thu, 16 Oct 2003 09:30:11 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9GDUA8N007404
	for sip-archive@odin.ietf.org; Thu, 16 Oct 2003 09:30:10 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AA8Ca-0001uM-Ti; Thu, 16 Oct 2003 09:30:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AA2q3-0005j1-N2
	for sip@optimus.ietf.org; Thu, 16 Oct 2003 03:46:27 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23598;
	Thu, 16 Oct 2003 03:46:17 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AA2q0-0001mZ-00; Thu, 16 Oct 2003 03:46:24 -0400
Received: from mail4.telekom.de ([195.243.210.197])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AA2q0-0001mJ-00; Thu, 16 Oct 2003 03:46:24 -0400
Received: from g8pbr.blf01.telekom.de by mail2.dmz.telekom.de with ESMTP; Thu, 16 Oct 2003 09:45:52 +0200
Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <4ZRH6GBK>; Thu, 16 Oct 2003 09:45:52 +0200
Message-Id: <953B9B08F98DD61183F8000347AE660102862C6C@G8PPV.blf01.telekom.de>
From: "Jesske, R" <R.Jesske@t-com.net>
To: sip@ietf.org, sipping@ietf.org
Date: Thu, 16 Oct 2003 09:45:52 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
Subject: [Sip] WG: draft-mahy-iptel-cpc-00
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: quoted-printable

In absence of opinions within the IPTEL group I would like to ask if =
the SIP/SIPPING group has any?

Best Regards


Roland

-----Urspr=FCngliche Nachricht-----
Von: Jesske, Roland=20
Gesendet: Dienstag, 7. Oktober 2003 13:31
An: iptel@ietf.org
Cc: Alexeitsev, Denis; P=F6tzl, Joachim; Tolksdorf, Christian; =
Sch=FCtte,
Wolfgang; Pinker, Gerold; Benz, Robert
Betreff: draft-mahy-iptel-cpc-00=20


Dear all,
With regard to the draft draft-mahy-iptel-cpc-00 are there any =
activities to extend the tel URI with the cpc parameter?
If yes where I can find more information? If no what is needed to put =
this forward as an issue.

I'm also looking on interworking the Closed User Group PSTN/ISDN =
Supplementary Service with SIP. To make this service also available =
within SIP a extension with the regarding ISUP indications (Closed user =
group interlock code and Closed user group call indicator) are needed.

As they have the same character as the CPC I'm wondering if some body =
had some thoughts on an extension of the tel URI with such kind of =
parameters to make the CUG Service also in SIP available.

Best Regards

Roland Jesske





Deutsche Telekom AG
T Com Zentrale
Roland Jesske, T38-12
Section T38; Signalling, Gateways and Switching Systems=20
Am Kavalleriesand 3, 64295 Darmstadt, Germany
Phone:  +49 6151 83-5940=20
Fax:      +49 6151 83-4577=20
email:   r.jesske@t-com.net




_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Thu Oct 16 13:38:40 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12552
	for <sip-archive@odin.ietf.org>; Thu, 16 Oct 2003 13:38:40 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AAC4p-0007R3-Gv
	for sip-archive@odin.ietf.org; Thu, 16 Oct 2003 13:38:20 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9GHcJZt028577
	for sip-archive@odin.ietf.org; Thu, 16 Oct 2003 13:38:19 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AAC4Z-0007Q9-4y; Thu, 16 Oct 2003 13:38:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AAC3e-00078y-S8
	for sip@optimus.ietf.org; Thu, 16 Oct 2003 13:37:06 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12508
	for <sip@ietf.org>; Thu, 16 Oct 2003 13:36:57 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AAC3c-0007UW-00
	for sip@ietf.org; Thu, 16 Oct 2003 13:37:04 -0400
Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AAC3b-0007UG-00
	for sip@ietf.org; Thu, 16 Oct 2003 13:37:03 -0400
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h9GHaI7M014366
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Thu, 16 Oct 2003 12:36:18 -0500
Received: (from dwillis@localhost)
	by bdsl.greycouncil.com (8.12.8/8.12.8/Submit) id h9GHaIW4014364;
	Thu, 16 Oct 2003 12:36:18 -0500
X-Authentication-Warning: bdsl.greycouncil.com: dwillis set sender to dean.willis@softarmor.com using -f
Subject: Re: [Sip] WGLC for URI and Header Parameter Registries
From: Dean Willis <dean.willis@softarmor.com>
To: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Cc: Aki Niemi <aki.niemi@nokia.com>, ext Rohan Mahy <rohan@cisco.com>,
        sip@ietf.org
In-Reply-To: <3F8E99FA.1030004@ericsson.com>
References: <E90CE267-FC13-11D7-A0FD-0003938AF740@cisco.com>
	 <3F8ACCB5.6000804@nokia.com>  <3F8E99FA.1030004@ericsson.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1066325778.14055.12.camel@bdsl.greycouncil.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 
Date: Thu, 16 Oct 2003 12:36:18 -0500
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, 2003-10-16 at 08:15, Gonzalo Camarillo wrote:
> the policy you are talking about is exactly what the WG could not agree 
> on. The conclusion was that, for the time being, we will start keeping 
> track of RFC-defined parameters (the two drafts under WGLC). Meanwhile, 
> we will work on the proper policy to use in the future. For example, if 
> someone defines a SIP parameter in a Nokia technical report, it is OK to 
> register it or not... we will count with you for those discussions ;o)
> 

I think, though, that we have to have some statement of policy in the
draft before sending this up to IESG. We can, of course, change the
policy later, so I'd suggest starting with the most restrictive langauge
and loosening up later if it seems important.

I would not now object to to a policy that says roughly "IANA registered
paramters must be defined by an IETF specification" but retains the
ability to use non-registered parameters without being "in violation of
the specification." The logic is "If a parameter is IANA registered, it
is a reserved word and has special meanings that we expect to be
globally relevant. If a parameter is NOT registered, it's a personal
matter."

I think we want the barrier somewhat high for the declaration of a new
"reserved word" in our vocabulary.

--
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 exim@www1.ietf.org  Thu Oct 16 13:53:36 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13585
	for <sip-archive@odin.ietf.org>; Thu, 16 Oct 2003 13:53:36 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AACJH-0008Ln-WB
	for sip-archive@odin.ietf.org; Thu, 16 Oct 2003 13:53:16 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9GHrFA9032093
	for sip-archive@odin.ietf.org; Thu, 16 Oct 2003 13:53:15 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AACJ4-0008Kq-Ix; Thu, 16 Oct 2003 13:53:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AACIv-0008KH-PU
	for sip@optimus.ietf.org; Thu, 16 Oct 2003 13:52:53 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13547
	for <sip@ietf.org>; Thu, 16 Oct 2003 13:52:43 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AACIt-0007k9-00
	for sip@ietf.org; Thu, 16 Oct 2003 13:52:51 -0400
Received: from pmesmtp01.wcom.com ([199.249.20.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AACIs-0007jQ-00
	for sip@ietf.org; Thu, 16 Oct 2003 13:52:50 -0400
Received: from pmismtp01.wcomnet.com ([166.38.62.36])
 by firewall.wcom.com (Iplanet MTA 5.2)
 with ESMTP id <0HMV0000J2XKBD@firewall.wcom.com> for sip@ietf.org; Thu,
 16 Oct 2003 17:51:20 +0000 (GMT)
Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com
 (iPlanet Messaging Server 5.1 HotFix 0.7 (built May  7 2002))
 with SMTP id <0HMV00L012WI35@pmismtp01.wcomnet.com> for sip@ietf.org; Thu,
 16 Oct 2003 17:51:20 +0000 (GMT)
Received: from xs578v3521.mci.com ([166.50.104.62])
 by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7
 2002)) with ESMTP id <0HMV00JBY2XBYH@pmismtp01.wcomnet.com> for sip@ietf.org;
 Thu, 16 Oct 2003 17:51:12 +0000 (GMT)
Date: Thu, 16 Oct 2003 12:51:10 -0500
From: Alan Johnston <alan.johnston@mci.com>
X-Sender: Alan.Johnston@pop.mcit.com
To: sip@ietf.org
Message-id: <5.2.1.1.0.20031016124933.02c90250@pop.mcit.com>
MIME-version: 1.0
X-Mailer: QUALCOMM Windows Eudora Version 5.2.1
Content-type: text/plain; charset=us-ascii; format=flowed
Subject: [Sip] Fwd: I-D ACTION:draft-johnston-sip-osp-token-05.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>

All,

This revision should address all the comments and issues raised during the 
WG Expert Review.  I believe it is ready for publication as a P header.

Thanks,
Alan Johnston
MCI
sip:alan@sipstation.com


>Date: Tue, 14 Oct 2003 15:35:30 -0400
>From: Internet-Drafts@ietf.org
>Subject: I-D ACTION:draft-johnston-sip-osp-token-05.txt
>Sender: owner-ietf-announce@ietf.org
>To: IETF-Announce: ;
>Reply-to: Internet-Drafts@ietf.org
>Original-recipient: rfc822;alan.johnston@mci.com
>
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>
>         Title           : Session Initiation Protocol Private Extension for
>                           an OSP Authorization Token
>         Author(s)       : A. Johnston, D. Rawlins, et. al.
>         Filename        : draft-johnston-sip-osp-token-05.txt
>         Pages           : 9
>         Date            : 2003-2-13
>
>This draft proposes a private extension to the Session Initiation
>Protocol (SIP) for carrying OSP (Open Settlements Protocol)
>authorization tokens in applications such as clearinghouses.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-johnston-sip-osp-token-05.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-johnston-sip-osp-token-05.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-johnston-sip-osp-token-05.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.
>Content-Type: text/plain
>Content-ID:     <2003-10-14141956.I-D@ietf.org>
>
>ENCODING mime
>FILE /internet-drafts/draft-johnston-sip-osp-token-05.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-johnston-sip-osp-token-05.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 exim@www1.ietf.org  Thu Oct 16 16:03:41 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20199
	for <sip-archive@odin.ietf.org>; Thu, 16 Oct 2003 16:03:41 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AAELA-0007Gr-Jy
	for sip-archive@odin.ietf.org; Thu, 16 Oct 2003 16:03:21 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9GK3KJL027950
	for sip-archive@odin.ietf.org; Thu, 16 Oct 2003 16:03:20 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AAEKs-0007ER-0w; Thu, 16 Oct 2003 16:03:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AAEKQ-0007Dc-BI
	for sip@optimus.ietf.org; Thu, 16 Oct 2003 16:02:34 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20157
	for <sip@ietf.org>; Thu, 16 Oct 2003 16:02:24 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AAEKO-0001KI-00
	for sip@ietf.org; Thu, 16 Oct 2003 16:02:32 -0400
Received: from imr2.ericy.com ([198.24.6.3])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AAEKN-0001KE-00
	for sip@ietf.org; Thu, 16 Oct 2003 16:02:32 -0400
Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51])
	by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id h9GK1pO8022504;
	Thu, 16 Oct 2003 15:01:52 -0500 (CDT)
Received: from ericsson.com (EFO9N000L5C7100 [153.88.94.6]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59)
	id S8VDC64Q; Thu, 16 Oct 2003 15:01:08 -0500
Message-ID: <3F8EF91E.80309@ericsson.com>
Date: Thu, 16 Oct 2003 23:01:34 +0300
X-Sybari-Trust: 303a14ad 406a040f c001c63b 00000138
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dean Willis <dean.willis@softarmor.com>
CC: Aki Niemi <aki.niemi@nokia.com>, ext Rohan Mahy <rohan@cisco.com>,
        sip@ietf.org
Subject: Re: [Sip] WGLC for URI and Header Parameter Registries
References: <E90CE267-FC13-11D7-A0FD-0003938AF740@cisco.com>	 <3F8ACCB5.6000804@nokia.com>  <3F8E99FA.1030004@ericsson.com> <1066325778.14055.12.camel@bdsl.greycouncil.com>
In-Reply-To: <1066325778.14055.12.camel@bdsl.greycouncil.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

Dean,

It sounds good to me. Could you provide a paragraph that summarizes what 
you just proposed? I will add it into the draft.

Thanks,

Gonzalo

Dean Willis wrote:

> On Thu, 2003-10-16 at 08:15, Gonzalo Camarillo wrote:
> 
>>the policy you are talking about is exactly what the WG could not agree 
>>on. The conclusion was that, for the time being, we will start keeping 
>>track of RFC-defined parameters (the two drafts under WGLC). Meanwhile, 
>>we will work on the proper policy to use in the future. For example, if 
>>someone defines a SIP parameter in a Nokia technical report, it is OK to 
>>register it or not... we will count with you for those discussions ;o)
>>
> 
> 
> I think, though, that we have to have some statement of policy in the
> draft before sending this up to IESG. We can, of course, change the
> policy later, so I'd suggest starting with the most restrictive langauge
> and loosening up later if it seems important.
> 
> I would not now object to to a policy that says roughly "IANA registered
> paramters must be defined by an IETF specification" but retains the
> ability to use non-registered parameters without being "in violation of
> the specification." The logic is "If a parameter is IANA registered, it
> is a reserved word and has special meanings that we expect to be
> globally relevant. If a parameter is NOT registered, it's a personal
> matter."
> 
> I think we want the barrier somewhat high for the declaration of a new
> "reserved word" in our vocabulary.
> 
> --
> 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 exim@www1.ietf.org  Thu Oct 16 19:22:40 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29879
	for <sip-archive@odin.ietf.org>; Thu, 16 Oct 2003 19:22:40 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AAHRj-0000mI-2L
	for sip-archive@odin.ietf.org; Thu, 16 Oct 2003 19:22:21 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9GNMJK9002987
	for sip-archive@odin.ietf.org; Thu, 16 Oct 2003 19:22:19 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AAHRS-0000lU-NH; Thu, 16 Oct 2003 19:22:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AAHQy-0000l4-IB
	for sip@optimus.ietf.org; Thu, 16 Oct 2003 19:21:33 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29863
	for <sip@ietf.org>; Thu, 16 Oct 2003 19:21:21 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AAHQw-00042m-00
	for sip@ietf.org; Thu, 16 Oct 2003 19:21:30 -0400
Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AAHQw-00042T-00
	for sip@ietf.org; Thu, 16 Oct 2003 19:21:30 -0400
Received: from softarmor.com (bdsl.66.12.12.254.gte.net [66.12.12.254])
	(authenticated bits=0)
	by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h9GNKk7M016655
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO);
	Thu, 16 Oct 2003 18:20:46 -0500
Message-ID: <3F8F27CC.3080905@softarmor.com>
Date: Thu, 16 Oct 2003 18:20:44 -0500
From: Dean Willis <dean.willis@softarmor.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
CC: Aki Niemi <aki.niemi@nokia.com>, ext Rohan Mahy <rohan@cisco.com>,
        sip@ietf.org
Subject: Re: [Sip] WGLC for URI and Header Parameter Registries
References: <E90CE267-FC13-11D7-A0FD-0003938AF740@cisco.com>	 <3F8ACCB5.6000804@nokia.com>  <3F8E99FA.1030004@ericsson.com> <1066325778.14055.12.camel@bdsl.greycouncil.com> <3F8EF91E.80309@ericsson.com>
In-Reply-To: <3F8EF91E.80309@ericsson.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

Gonzalo Camarillo wrote:

> It sounds good to me. Could you provide a paragraph that summarizes what 
> you just proposed? I will add it into the draft.


Citing RFC 2434:

       "Specification Required - Values and their meaning must be
       documented in an RFC or other permanent and readily available
       reference, in sufficient detail so that interoperability
       between independent implementations is possible."

Ok -- mightconsider applying it to both reg drafts.


Revise and extend "Use of the Registry"

3 Use of the Registry

    SIP and SIPS URI Parameters must be documented in an RFC in order to
    be registered by IANA. This documentation MUST fully explain the
    syntax, intended usage and semantics of the parameter. The intent of
    this requirement is to assure inetroperability between independent
    implementations, and to prevent accidental namespace collisions
    between implementations of dissimialr features.

    RFCs defining SIP URI or SIPS URI parameters MUST register them with
    IANA as described below.

    Registered SIP or SIPS URI parameters are to be considered "reserved
    words".  In order to preserve interoperability, registered parameters
    MUST be used in a manner consistent with that described in their
    defining RFC. Implementations MUST NOT utilize "private" or "locally
    defined" URI parameters that conflict with registered parameters.

    Note that although unregistered SIP and SIPS URI parameters may be
    used in implementations, developers are cautioned that usage of such
    parameters is risky. New SIP and SIPS URI parameters may be
    registered at any time, and there is no assurance that these
    new registered URI parameters will not conflict with unregistered
    parameters currently in use.



In IANA Considerations Section, add new section (4.2?)


4.2 Registration Policy for SIP Request-URI Parameters

    As per the terminology in RFC 2434, the registration policy for SIP
    and SIPS URI Parameters shall be "Specification Required".

    For the purposes of this registry, the parameter for which IANA
    registration is requested must be defined by an RFC. There is no
    requirement that this RFC be standards-track.


--
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 exim@www1.ietf.org  Fri Oct 17 11:54:34 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07963
	for <sip-archive@odin.ietf.org>; Fri, 17 Oct 2003 11:54:34 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AAWve-0003eW-8c
	for sip-archive@odin.ietf.org; Fri, 17 Oct 2003 11:54:14 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HFsEpg014034
	for sip-archive@odin.ietf.org; Fri, 17 Oct 2003 11:54:14 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AAWuT-0003Vi-K1; Fri, 17 Oct 2003 11:53:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AAWtt-0003Uw-ME
	for sip@optimus.ietf.org; Fri, 17 Oct 2003 11:52:25 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07921
	for <sip@ietf.org>; Fri, 17 Oct 2003 11:52:15 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AAWts-0004wr-00
	for sip@ietf.org; Fri, 17 Oct 2003 11:52:24 -0400
Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AAWtr-0004wm-00
	for sip@ietf.org; Fri, 17 Oct 2003 11:52:23 -0400
Received: from localhost (localhost.localdomain [127.0.0.1])
	by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h9HFpod28295
	for <sip@ietf.org>; Fri, 17 Oct 2003 10:51:50 -0500
From: Robert Sparks <rsparks@dynamicsoft.com>
To: sip@ietf.org
Content-Type: text/plain
Message-Id: <1066405909.958.25.camel@RjS.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.4 
Date: Fri, 17 Oct 2003 10:51:49 -0500
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Default value for Accept:
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 a request contains no Accept header field, the
application processing that request is instructed
by 3261 to use a default value of "application/sdp".

Thus, if a client issues an OPTIONS or an INVITE with
no Accept header field, the response body, if present,
MUST be application/sdp. In particular, it cannot be
multipart/<whatever>.

This has interesting ramifications for the S/MIME
security tools we've been trying to focus towards.
A server cannot use them to secure a message unless
the client explicitly declares support for multipart/mime
in any request it sends?

Is this OK? Do we want to try to adjust the default
value of Accept (and what endpoints are required to
understand)? Or do we just rely on pressuring the
endpoints to always provide an Accept header with a
whole bunch of stuff listed?

RjS


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Fri Oct 17 13:03:34 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10537
	for <sip-archive@odin.ietf.org>; Fri, 17 Oct 2003 13:03:33 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AAY0Q-0006vZ-KY
	for sip-archive@odin.ietf.org; Fri, 17 Oct 2003 13:03:14 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HH3EDK026623
	for sip-archive@odin.ietf.org; Fri, 17 Oct 2003 13:03:14 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AAY0D-0006ug-Uf; Fri, 17 Oct 2003 13:03:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AAXzk-0006tw-KL
	for sip@optimus.ietf.org; Fri, 17 Oct 2003 13:02:32 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10455
	for <sip@ietf.org>; Fri, 17 Oct 2003 13:02:21 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AAXzi-0005fL-00
	for sip@ietf.org; Fri, 17 Oct 2003 13:02:30 -0400
Received: from mail1.dynamicsoft.com ([63.113.40.10])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AAXzi-0005eq-00
	for sip@ietf.org; Fri, 17 Oct 2003 13:02:30 -0400
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h9HGwqqR026962
	for <sip@ietf.org>; Fri, 17 Oct 2003 12:58:52 -0400 (EDT)
Received: from dynamicsoft.com (NJ-AKRISTENSEN [63.113.46.5]) by DYN-EXCH-001.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id 4JPVHHPJ; Fri, 17 Oct 2003 13:01:54 -0400
Message-ID: <3F902081.9050206@dynamicsoft.com>
Date: Fri, 17 Oct 2003 13:01:53 -0400
From: Anders Kristensen <akristensen@dynamicsoft.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: SIP <sip@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] 3pcc draft: SDP seq-no issue
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 the example in section 10.2 of the 3pcc draft, 
draft-ietf-sipping-3pcc-04.txt, the controller disconnects the callee 
(called party of b2bua or 3pcc call) by sending a re-INVITE with a 
connection address in the .invalid domain. Later on the called party is 
reconnected with the caller by using one of the 3pcc flows.

One problem with this, not mentioned in the draft, is that the 
controller has to bump up the o= SDP version number when sending the 
disconnect re-INVITE. Since the caller may not have to change its SDP in 
offer (5) and answer (16) it may not update its SDP version number, 
meaning the controller will have to rewrite it in (17) answer3' sent to 
the callee (and keep on doing it for any subsequent re-INVITEs).

It seems that SDP version numbers could be an issue whenever any of the 
flows is used after initial call establishment?

BTW, RFC 3264 has the following slightly curious formulation:

    When issuing an offer that modifies the session,
    the "o=" line of the new SDP MUST be identical to that in the
    previous SDP, except that the version in the origin field MUST
    increment by one from the previous SDP.  If the version in the origin
    line does not increment, the SDP MUST be identical to the SDP with
    that version number.  The answerer MUST be prepared to receive an
    offer that contains SDP with a version that has not changed; this is
    effectively a no-op.

Is "MUST increment by one" supposed to be interpreted to mean "by at 
least one" or is this really intended to strengthen the requirements of 
RFC 2327?

Thanks,
Anders


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Fri Oct 17 16:21:36 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22524
	for <sip-archive@odin.ietf.org>; Fri, 17 Oct 2003 16:21:36 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AAb62-0000Ib-Ie
	for sip-archive@odin.ietf.org; Fri, 17 Oct 2003 16:21:16 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HKLEPD001146
	for sip-archive@odin.ietf.org; Fri, 17 Oct 2003 16:21:14 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AAb5q-0000HS-E7; Fri, 17 Oct 2003 16:21:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AAb5M-0000Gp-Iq
	for sip@optimus.ietf.org; Fri, 17 Oct 2003 16:20:32 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22503
	for <sip@ietf.org>; Fri, 17 Oct 2003 16:20:22 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AAb5K-0000vh-00
	for sip@ietf.org; Fri, 17 Oct 2003 16:20:30 -0400
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AAb5K-0000v9-00
	for sip@ietf.org; Fri, 17 Oct 2003 16:20:30 -0400
Received: from cisco.com (64.102.124.12)
  by sj-iport-5.cisco.com with ESMTP; 17 Oct 2003 13:20:13 -0700
Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27])
	by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9HKJuFH024723;
	Fri, 17 Oct 2003 16:19:56 -0400 (EDT)
Received: from cisco.com (klingle-linux.cisco.com [64.102.93.48])
	by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AQX62034;
	Fri, 17 Oct 2003 13:19:56 -0700 (PDT)
Message-ID: <3F904EEC.2080108@cisco.com>
Date: Fri, 17 Oct 2003 16:19:56 -0400
From: Kevin Lingle <klingle@cisco.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Cullen Jennings <fluffy@cisco.com>
CC: Mary Barnes <mbarnes@nortelnetworks.com>, orit1@microsoft.com,
        AC Mahendran
 <mahendra@qualcomm.com>,
        Jean-Francois Mule <jf.mule@cablelabs.com>, sip@ietf.org
Subject: Re: [Sip] sip-mib: removal of sipStatusCodeClassesTable
References: <BBB2EB0E.2089B%fluffy@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

cullen,

understood.  as no one else has stood up as an advocate for
keeping the table, i'll plan on removing it.

kevin

Cullen Jennings wrote:
> I was suggesting considering removing the whole thing but don't have a super
> strong opinion. I'm all for making the MIB as simple as possible to
> implement while still providing the relevant information. This aggregated
> table might make it easier to use the mib but does not have any extra
> information that is not available some other way in the MIB. I'm always
> worried about providing the same data two ways and try to provide the data
> at the most atomic level.
> 
> 
> On 10/3/03 10:13, "Kevin Lingle" <klingle@cisco.com> wrote:
> 
> 
>>
>>Cullen Jennings wrote:
>>
>>>One tiny comment on this ....
>>>
>>>A 407 may not be an indication that anything bad is happening. I'm not sure
>>>there is much use in grouping all the 4xx together.
>>
>>cullen,
>>
>>do i detect, in this comment, that perhap you could see usefulness in
>>any of the other classes ;) (eg, 6xx);  or do you still essentially want
>>the entire table removed?
>>
>>it would be good to hear the views of others (assigned reviewers especially).
>>
>>i don't have any great attachement to the table.  i was ready to remove it
>>based on cullens original comments and then i got feed back (below)
>>with a point of view supporting the concept behind this table.
>>
>>if i don't here any other support for the table, then i'll remove it from the
>>mib.
>>
>>kevin
>>
>>
>>>Cullen
>>>
>>>
>>>On 9/26/03 6:38 AM, "Kevin Lingle" <klingle@cisco.com> wrote:
>>>
>>>
>>>
>>>>additionally...
>>>>
>>>>recently i was cc'd on an email where one developer
>>>>asked another for a list of statistics that could be
>>>>used as a measure of the health/well-being of a sip
>>>>proxy.    the developer responded in terms of the sip
>>>>stats we have in the sip-common-mib and said the following
>>>>about some objects from the sipStatusCodeClassesTable:
>>>>
>>>>-----
>>>>Successful responses - When calls are successful, these counters
>>>>should be going up.
>>>>
>>>>  sipStatsSuccessClassIns       Counter32, /* 200 OK response */
>>>>  sipStatsSuccessClassOuts      Counter32,
>>>>
>>>>Failure responses - A very high value for these counters indicates
>>>>calls failing in the network. Typically, if calls are not failing,
>>>>these counters should have low values and increment slowly.
>>>>
>>>>  sipStatsReqFailClassIns       Counter32, /* 4XX class errors */
>>>>  sipStatsReqFailClassOuts      Counter32,
>>>>  sipStatsServerFailClassIns    Counter32, /* 5xx class errors */
>>>>  sipStatsServerFailClassOuts   Counter32,
>>>>  sipStatsGlobalFailClassIns    Counter32, /* 6xx class errors */
>>>>  sipStatsGlobalFailClassOuts   Counter32,
>>>>--------
>>>>
>>>>so i chimed in saying that there was a proposal to
>>>>remove this table from the mib.  if that were to
>>>>occur, was there a small subset of individual rsp code
>>>>counters that could be polled in order to draw
>>>>the same conclusion on failures.
>>>>
>>>>the answer i got back was that all of the individial
>>>>4xx,5xx,6xx counters.  a subset of "important" counters
>>>>really wasn't feasible.
>>>>
>>>>if that is the case, then aren't these per class stats
>>>>potentially of use in quickly gauging whether a sip system
>>>>may be experiencing problems that warrent further investigation?
>>>>
>>>>kevin
>>>>
>>>>
>>>>Kevin Lingle wrote:
>>>>
>>>>
>>>>>hi all,
>>>>>
>>>>>a proposal in on the table to remove this table from
>>>>>the SIP-COMMON-MIB.  cullen was the only one of the reviewers
>>>>>who raised this issue explicitly.  i wanted to give others a
>>>>>chance to comment on it.
>>>>>
>>>>>orit, did allude to there being too many counters and suggested
>>>>>removal of some summary counters.  he didn't mention this table
>>>>>by name though (i don't think).
>>>>>
>>>>>these are "summary counters", but were defined this way to give
>>>>>a high level (gross) indicator of problems so a manager could
>>>>>to and probe a system further for the details.  working at a
>>>>>more granular level of rsp code counters would require more polling
>>>>>on the part of snmp managers.  that was the thought behind providing
>>>>>these aggregate counters.
>>>>>
>>>>>http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-07.txt
>>>>>
>>>>>comments?
>>>>>
>>>>>kevin
>>>>
>>>
> 
> 


-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Kevin R. Lingle       919.392.2029
  http://www.klove.com                               http://www.air1.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 exim@www1.ietf.org  Sat Oct 18 22:26:28 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16132
	for <sip-archive@odin.ietf.org>; Sat, 18 Oct 2003 22:26:28 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AB3Gi-00050l-Sh
	for sip-archive@odin.ietf.org; Sat, 18 Oct 2003 22:26:08 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9J2Q8JF019205
	for sip-archive@odin.ietf.org; Sat, 18 Oct 2003 22:26:08 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AB3Ff-0004Lw-4g; Sat, 18 Oct 2003 22:25:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AB3En-0003zM-1h
	for sip@optimus.ietf.org; Sat, 18 Oct 2003 22:24:09 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16066
	for <sip@ietf.org>; Sat, 18 Oct 2003 22:23:57 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AB3Ej-0001IH-00
	for sip@ietf.org; Sat, 18 Oct 2003 22:24:05 -0400
Received: from ams-iport-1.cisco.com ([144.254.74.5])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AB3Ej-0001I3-00
	for sip@ietf.org; Sat, 18 Oct 2003 22:24:05 -0400
Received: from cisco.com (171.71.177.254)
  by ams-iport-1.cisco.com with ESMTP; 19 Oct 2003 04:21:40 +0200
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9J2NWiw006323;
	Sat, 18 Oct 2003 19:23:33 -0700 (PDT)
Received: from [10.0.1.100] (sjc-vpn3-242.cisco.com [10.21.64.242])
	by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AJD33181;
	Sat, 18 Oct 2003 19:23:32 -0700 (PDT)
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sat, 18 Oct 2003 19:17:50 -0700
From: Cullen Jennings <fluffy@cisco.com>
To: <sip@ietf.org>
CC: Cullen Jennings <fluffy@cisco.com>
Message-ID: <BBB7425E.21061%fluffy@cisco.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] New ID related to voicemail and history requirements
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 have submitted a new draft that deals with meeting a subset of the
"history" requirements for sending calls to voicemail systems. Until it
shows up in the archive, you can find it at:

http://www.employees.org/~fluffy/ietf/
       draft-jennings-sip-voicemail-uri-00.txt

Or 

http://www.employees.org/~fluffy/ietf/
       draft-jennings-sip-voicemail-uri-00.html

Cullen


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Sun Oct 19 01:43:19 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18849
	for <sip-archive@odin.ietf.org>; Sun, 19 Oct 2003 01:43:18 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AB6LB-0001e5-Jt
	for sip-archive@odin.ietf.org; Sun, 19 Oct 2003 01:42:58 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9J5gvBJ006261
	for sip-archive@odin.ietf.org; Sun, 19 Oct 2003 01:42:57 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AB6KH-0001ID-9I; Sun, 19 Oct 2003 01:42:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AB6JZ-0001CH-U1
	for sip@optimus.ietf.org; Sun, 19 Oct 2003 01:41:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18811
	for <sip@ietf.org>; Sun, 19 Oct 2003 01:41:08 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AB6JW-0002gI-00
	for sip@ietf.org; Sun, 19 Oct 2003 01:41:14 -0400
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AB6JW-0002g6-00
	for sip@ietf.org; Sun, 19 Oct 2003 01:41:14 -0400
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9J5ehjP017889;
	Sat, 18 Oct 2003 22:40:43 -0700 (PDT)
Received: from [10.0.1.100] (sjc-vpn3-607.cisco.com [10.21.66.95])
	by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AJD35832;
	Sat, 18 Oct 2003 22:40:42 -0700 (PDT)
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sat, 18 Oct 2003 22:07:20 -0700
Subject: Re: [Sip] Default value for Accept:
From: Cullen Jennings <fluffy@cisco.com>
To: Robert Sparks <rsparks@dynamicsoft.com>, <sip@ietf.org>
Message-ID: <BBB76A18.210E5%fluffy@cisco.com>
In-Reply-To: <1066405909.958.25.camel@RjS.localdomain>
Mime-version: 1.0
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


3261 has multipart as a MAY. A call flow that looks like send a multipart
INVITE, get back and error with an Accept header, then send a non multipart
is sort of disgusting but it sounds like that is what you have to do.

Practically speaking, how would folks feel about making multipart a MUST or
at least a SHOULD be able to receive.

Cullen



On 10/17/03 8:51, "Robert Sparks" <rsparks@dynamicsoft.com> wrote:

> If a request contains no Accept header field, the
> application processing that request is instructed
> by 3261 to use a default value of "application/sdp".
> 
> Thus, if a client issues an OPTIONS or an INVITE with
> no Accept header field, the response body, if present,
> MUST be application/sdp. In particular, it cannot be
> multipart/<whatever>.
> 
> This has interesting ramifications for the S/MIME
> security tools we've been trying to focus towards.
> A server cannot use them to secure a message unless
> the client explicitly declares support for multipart/mime
> in any request it sends?
> 
> Is this OK? Do we want to try to adjust the default
> value of Accept (and what endpoints are required to
> understand)? Or do we just rely on pressuring the
> endpoints to always provide an Accept header with a
> whole bunch of stuff listed?
> 
> RjS
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Sun Oct 19 01:43:19 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18864
	for <sip-archive@odin.ietf.org>; Sun, 19 Oct 2003 01:43:19 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AB6LB-0001dC-Gg
	for sip-archive@odin.ietf.org; Sun, 19 Oct 2003 01:42:58 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9J5gvc2006260
	for sip-archive@odin.ietf.org; Sun, 19 Oct 2003 01:42:57 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AB6KI-0001IS-Pf; Sun, 19 Oct 2003 01:42:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AB6Jd-0001Ca-Ie
	for sip@optimus.ietf.org; Sun, 19 Oct 2003 01:41:22 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18814
	for <sip@ietf.org>; Sun, 19 Oct 2003 01:41:12 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AB6Ja-0002gN-00
	for sip@ietf.org; Sun, 19 Oct 2003 01:41:18 -0400
Received: from ams-iport-1.cisco.com ([144.254.74.5])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AB6JZ-0002g9-00
	for sip@ietf.org; Sun, 19 Oct 2003 01:41:17 -0400
Received: from cisco.com (171.71.177.254)
  by ams-iport-1.cisco.com with ESMTP; 19 Oct 2003 07:38:53 +0200
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9J5eiiw003353;
	Sat, 18 Oct 2003 22:40:44 -0700 (PDT)
Received: from [10.0.1.100] (sjc-vpn3-607.cisco.com [10.21.66.95])
	by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AJD35833;
	Sat, 18 Oct 2003 22:40:43 -0700 (PDT)
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sat, 18 Oct 2003 22:11:07 -0700
Subject: Re: [Sip] WGLC for URI and Header Parameter Registries
From: Cullen Jennings <fluffy@cisco.com>
To: Dean Willis <dean.willis@softarmor.com>, <Gonzalo.Camarillo@ericsson.com>
CC: Aki Niemi <aki.niemi@nokia.com>, ext Rohan Mahy <rohan@cisco.com>,
        <sip@ietf.org>
Message-ID: <BBB76AFB.210E6%fluffy@cisco.com>
In-Reply-To: <3F8F27CC.3080905@softarmor.com>
Mime-version: 1.0
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


Should we make a recommendation that non RFC stuff uses x- to avoid name
conflicts later? 

Cullen

I won't even mention the logical next things to bring up :-)


On 10/16/03 16:20, "Dean Willis" <dean.willis@softarmor.com> wrote:

> Gonzalo Camarillo wrote:
> 
>> It sounds good to me. Could you provide a paragraph that summarizes what
>> you just proposed? I will add it into the draft.
> 
> 
> Citing RFC 2434:
> 
>      "Specification Required - Values and their meaning must be
>      documented in an RFC or other permanent and readily available
>      reference, in sufficient detail so that interoperability
>      between independent implementations is possible."
> 
> Ok -- mightconsider applying it to both reg drafts.
> 
> 
> Revise and extend "Use of the Registry"
> 
> 3 Use of the Registry
> 
>   SIP and SIPS URI Parameters must be documented in an RFC in order to
>   be registered by IANA. This documentation MUST fully explain the
>   syntax, intended usage and semantics of the parameter. The intent of
>   this requirement is to assure inetroperability between independent
>   implementations, and to prevent accidental namespace collisions
>   between implementations of dissimialr features.
> 
>   RFCs defining SIP URI or SIPS URI parameters MUST register them with
>   IANA as described below.
> 
>   Registered SIP or SIPS URI parameters are to be considered "reserved
>   words".  In order to preserve interoperability, registered parameters
>   MUST be used in a manner consistent with that described in their
>   defining RFC. Implementations MUST NOT utilize "private" or "locally
>   defined" URI parameters that conflict with registered parameters.
> 
>   Note that although unregistered SIP and SIPS URI parameters may be
>   used in implementations, developers are cautioned that usage of such
>   parameters is risky. New SIP and SIPS URI parameters may be
>   registered at any time, and there is no assurance that these
>   new registered URI parameters will not conflict with unregistered
>   parameters currently in use.
> 
> 
> 
> In IANA Considerations Section, add new section (4.2?)
> 
> 
> 4.2 Registration Policy for SIP Request-URI Parameters
> 
>   As per the terminology in RFC 2434, the registration policy for SIP
>   and SIPS URI Parameters shall be "Specification Required".
> 
>   For the purposes of this registry, the parameter for which IANA
>   registration is requested must be defined by an RFC. There is no
>   requirement that this RFC be standards-track.
> 
> 
> --
> 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 exim@www1.ietf.org  Sun Oct 19 09:14:32 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07350
	for <sip-archive@odin.ietf.org>; Sun, 19 Oct 2003 09:14:32 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABDNq-0003op-Hs
	for sip-archive@odin.ietf.org; Sun, 19 Oct 2003 09:14:11 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9JDEAmZ014620
	for sip-archive@odin.ietf.org; Sun, 19 Oct 2003 09:14:10 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABDNi-0003mE-0v; Sun, 19 Oct 2003 09:14:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABDN9-0003Yv-5G
	for sip@optimus.ietf.org; Sun, 19 Oct 2003 09:13:27 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07249
	for <sip@ietf.org>; Sun, 19 Oct 2003 09:13:17 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABDN7-0005ED-00
	for sip@ietf.org; Sun, 19 Oct 2003 09:13:25 -0400
Received: from cs.columbia.edu ([128.59.16.20])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABDN7-0005E9-00
	for sip@ietf.org; Sun, 19 Oct 2003 09:13:25 -0400
Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8])
	by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id h9JDDHLZ010079;
	Sun, 19 Oct 2003 09:13:17 -0400 (EDT)
Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1])
	by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h9JDDGq23234;
	Sun, 19 Oct 2003 09:13:16 -0400
Message-ID: <3F928DEB.8070508@cs.columbia.edu>
Date: Sun, 19 Oct 2003 09:13:15 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Cullen Jennings <fluffy@cisco.com>
CC: Dean Willis <dean.willis@softarmor.com>, Gonzalo.Camarillo@ericsson.com,
        Aki Niemi <aki.niemi@nokia.com>, ext Rohan Mahy <rohan@cisco.com>,
        sip@ietf.org
Subject: Re: [Sip] WGLC for URI and Header Parameter Registries
References: <BBB76AFB.210E6%fluffy@cisco.com>
In-Reply-To: <BBB76AFB.210E6%fluffy@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

Cullen Jennings wrote:

> Should we make a recommendation that non RFC stuff uses x- to avoid name
> conflicts later? 
> 
> Cullen
> 
> I won't even mention the logical next things to bring up :-)
> 

I'm not sure if this is in jest, so pardon my standard rant. The X- 
convention solves no problem and simply makes it more difficult to 
eventually migrate non-RFC stuff to RFC stuff.

Any X- name space would avoid collision with RFC-documented names only, 
but not with other non-RFC names. However, the former is not a problem 
since those names are publically documented and, according to the 
proposal, registered. Collision is much more likely between two 
companies or non-IETF standardization groups developing extensions, as 
they don't have an easy way to find out what others are up to. They 
would typically only find out once a product ships or a spec is 
published, when it is often too late to make changes without large costs.

Thus, separate, global namespaces for non-RFC/non-IANA extensions have 
no benefit whatsoever, in my opinion.

Henning



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Sun Oct 19 20:04:43 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23595
	for <sip-archive@odin.ietf.org>; Sun, 19 Oct 2003 20:04:43 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABNX3-0001AB-U7
	for sip-archive@odin.ietf.org; Sun, 19 Oct 2003 20:04:22 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9K04Lgq004414
	for sip-archive@odin.ietf.org; Sun, 19 Oct 2003 20:04:21 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABNWj-00016X-OY; Sun, 19 Oct 2003 20:04:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABNWT-00014G-Lc
	for sip@optimus.ietf.org; Sun, 19 Oct 2003 20:03:45 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23571
	for <sip@ietf.org>; Sun, 19 Oct 2003 20:03:36 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABNWR-0001Wm-00
	for sip@ietf.org; Sun, 19 Oct 2003 20:03:43 -0400
Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABNWR-0001Wc-00
	for sip@ietf.org; Sun, 19 Oct 2003 20:03:43 -0400
Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57])
	by ihemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id h9K03AP13077
	for <sip@ietf.org>; Sun, 19 Oct 2003 19:03:11 -0500 (CDT)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2656.59)
	id <4M3WQKR3>; Mon, 20 Oct 2003 01:03:09 +0100
Message-ID: <475FF955A05DD411980D00508B6D5FB00A14F4E1@en0033exch001u.uk.lucent.com>
From: "Drage, Keith (Keith)" <drage@lucent.com>
To: aki.niemi@nokia.com, sip@ietf.org
Date: Mon, 20 Oct 2003 01:03:07 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
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>

Clause 7. Delete "Note that" from the second sentence, as this is normative material.

Clause 7.1.1, table 1, entries for the Expires header are incorrect. Need to separate Request and 2xx Response into separate rows. The expires header is mandatory for 2xx responses.

Clause 7.1.1, table 1, need to include entry for the Min-Expires header. It is mandatory in a 423 response.

Clause 7.1.1, table 1, Event header. The "a" and "m" are in the wrong columns.

Clause 7.1.1, table 1, should include the Allow-Events header even though it is not defined in RFC 3261 but in RFC 3265.

regards

Keith



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

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Sun Oct 19 20:11:26 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23695
	for <sip-archive@odin.ietf.org>; Sun, 19 Oct 2003 20:11:26 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABNdZ-000317-BK
	for sip-archive@odin.ietf.org; Sun, 19 Oct 2003 20:11:05 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9K0B5Wj011573
	for sip-archive@odin.ietf.org; Sun, 19 Oct 2003 20:11:05 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABNdW-0002zq-Js; Sun, 19 Oct 2003 20:11:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABNd8-0002vP-U8
	for sip@optimus.ietf.org; Sun, 19 Oct 2003 20:10:38 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23677
	for <sip@ietf.org>; Sun, 19 Oct 2003 20:10:29 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABNd6-0001bn-00
	for sip@ietf.org; Sun, 19 Oct 2003 20:10:36 -0400
Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABNd6-0001bW-00
	for sip@ietf.org; Sun, 19 Oct 2003 20:10:36 -0400
Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57])
	by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id h9K0A3829256
	for <sip@ietf.org>; Sun, 19 Oct 2003 19:10:04 -0500 (CDT)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2656.59)
	id <4M3WQKS2>; Mon, 20 Oct 2003 01:10:02 +0100
Message-ID: <475FF955A05DD411980D00508B6D5FB00A14F4E2@en0033exch001u.uk.lucent.com>
From: "Drage, Keith (Keith)" <drage@lucent.com>
To: aki.niemi@nokia.com, sip@ietf.org
Subject: RE: [Sip] (no subject)
Date: Mon, 20 Oct 2003 01:10:01 +0100
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>

Sorry, this set of nit comments relates to draft-ietf-sip-publish-00

regards

Keith

> -----Original Message-----
> From: Drage, Keith (Keith) [mailto:drage@lucent.com]
> Sent: 20 October 2003 01:03
> To: aki.niemi@nokia.com; sip@ietf.org
> Subject: [Sip] (no subject)
> 
> 
> Clause 7. Delete "Note that" from the second sentence, as 
> this is normative material.
> 
> Clause 7.1.1, table 1, entries for the Expires header are 
> incorrect. Need to separate Request and 2xx Response into 
> separate rows. The expires header is mandatory for 2xx responses.
> 
> Clause 7.1.1, table 1, need to include entry for the 
> Min-Expires header. It is mandatory in a 423 response.
> 
> Clause 7.1.1, table 1, Event header. The "a" and "m" are in 
> the wrong columns.
> 
> Clause 7.1.1, table 1, should include the Allow-Events header 
> even though it is not defined in RFC 3261 but in RFC 3265.
> 
> regards
> 
> Keith
> 
> 
> 
> Keith Drage
> Lucent Technologies
> drage@lucent.com
> tel: +44 1793 776249
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Mon Oct 20 00:22:40 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29313
	for <sip-archive@odin.ietf.org>; Mon, 20 Oct 2003 00:22:40 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABRYj-0001AU-73
	for sip-archive@odin.ietf.org; Mon, 20 Oct 2003 00:22:21 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9K4MLlw004431
	for sip-archive@odin.ietf.org; Mon, 20 Oct 2003 00:22:21 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABRYP-00011r-DH; Mon, 20 Oct 2003 00:22:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABRYF-0000x9-Re
	for sip@optimus.ietf.org; Mon, 20 Oct 2003 00:21:51 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29298
	for <sip@ietf.org>; Mon, 20 Oct 2003 00:21:40 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABRYD-0003d7-00
	for sip@ietf.org; Mon, 20 Oct 2003 00:21:49 -0400
Received: from ams-iport-1.cisco.com ([144.254.74.5])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABRYC-0003d2-00
	for sip@ietf.org; Mon, 20 Oct 2003 00:21:48 -0400
Received: from cisco.com (171.71.177.254)
  by ams-iport-1.cisco.com with ESMTP; 20 Oct 2003 06:19:24 +0200
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9K4LEj0013342;
	Sun, 19 Oct 2003 21:21:16 -0700 (PDT)
Received: from [10.0.1.7] (sjc-vpn1-366.cisco.com [10.21.97.110])
	by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AJD55876;
	Sun, 19 Oct 2003 21:21:14 -0700 (PDT)
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sun, 19 Oct 2003 21:19:42 -0700
From: Cullen Jennings <fluffy@cisco.com>
To: <sip@ietf.org>
CC: Cullen Jennings <fluffy@cisco.com>
Message-ID: <BBB8B06E.21185%fluffy@cisco.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Example call flows using S/MIME and TLS
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 have submitted an ID with example call flows that use TLS and S/MIME.
Until it shows up in the drafts directory, you can find it at:

http://www.employees.org/~fluffy/ietf/draft-jennings-sip-sec-flows-00.html

Or

http://www.employees.org/~fluffy/ietf/draft-jennings-sip-sec-flows-00.txt

Cullen


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Mon Oct 20 04:05:44 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17008
	for <sip-archive@odin.ietf.org>; Mon, 20 Oct 2003 04:05:44 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABV2Y-0003AM-HX
	for sip-archive@odin.ietf.org; Mon, 20 Oct 2003 04:05:22 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9K85MJV012111
	for sip-archive@odin.ietf.org; Mon, 20 Oct 2003 04:05:22 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABV2E-00036P-ET; Mon, 20 Oct 2003 04:05:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABV1j-0002un-F5
	for sip@optimus.ietf.org; Mon, 20 Oct 2003 04:04:31 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16975
	for <sip@ietf.org>; Mon, 20 Oct 2003 04:04:22 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABV1g-0005VQ-00
	for sip@ietf.org; Mon, 20 Oct 2003 04:04:28 -0400
Received: from [80.74.106.10] (helo=nt-mail.radvision.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABV1e-0005VI-00
	for sip@ietf.org; Mon, 20 Oct 2003 04:04:26 -0400
Received: from nt-mail.tlv.radvision.com [172.20.2.100]
	by nt-mail.radvision.com
	with XWall v3.26 ;
	Mon, 20 Oct 2003 10:03:52 +0200
Received: by nt-mail.tlv.radvision.com with Internet Mail Service (5.5.2653.19)
	id <4DPLXA61>; Mon, 20 Oct 2003 10:03:52 +0200
Message-ID: <99FF181D4C99564F8D623069E1DDB25E24D579@nt-mail.tlv.radvision.com>
From: "Udi Tirosh (Weintrob)" <udiw@radvision.com>
To: "'Cullen Jennings'" <fluffy@cisco.com>
Cc: sip@ietf.org
Subject: RE: [Sip] Example call flows using S/MIME and TLS
Date: Mon, 20 Oct 2003 10:03:52 +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 looked at the examples with great interest, I think some more
clarifications are needed in the area of a) connection breaking and b) the
usage of mutual authentication and post connection assertions. I will try
and describe the difficulties I am seeing:

A. connection breaking:
Lets assume that UA a.example.com (A) is connecting to it's proxy
p.example.com (P) over TLS. the certificate mechanism combined with post
connection assertion does prove to the A that P is "ok". but TCP, on which
TLS is build might be broken. in RFC 3261 (18.2.2) it is stated that:
        "If that
         connection is no longer open, the server SHOULD open a
         connection to the IP address in the "received" parameter, if
         present, using the port in the "sent-by" value, or the default
         port for that transport, if no port is specified.  If that
         connection attempt fails, the server SHOULD use the procedures
         in [4] for servers in order to determine the IP address and
         port to open the connection and send the response to."
So P should open a new TLS connection to send the response to the A. Now,
for that to work over TLS, A must have a certificate. More over, as I
understand it the client will have no means to "post connection assert"  the
connection and the responses will arrive unverified. 

B. mutual authentication between proxies.
What is the best way for two proxies to use a bi directional TLS
communication?
Option 1: the proxies will open  a TLS connection using mutual
authentication, but this way only one of the proxies (the one that initiated
the connection) will be able to post connection assert.

Option 2: each proxy will open a TLS connection to the other proxy. and post
connect assert on this connection. but now we have 2 open connection rather
than 1.

I will appreciate some more input on those matters.
Regards,
Udi.



-----Original Message-----
From: Cullen Jennings [mailto:fluffy@cisco.com]
Sent: Monday, October 20, 2003 6:20 AM
To: sip@ietf.org
Cc: Cullen Jennings
Subject: [Sip] Example call flows using S/MIME and TLS
Importance: High



I have submitted an ID with example call flows that use TLS and S/MIME.
Until it shows up in the drafts directory, you can find it at:

http://www.employees.org/~fluffy/ietf/draft-jennings-sip-sec-flows-00.html

Or

http://www.employees.org/~fluffy/ietf/draft-jennings-sip-sec-flows-00.txt

Cullen


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Mon Oct 20 07:29:47 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21918
	for <sip-archive@odin.ietf.org>; Mon, 20 Oct 2003 07:29:46 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABYE0-00028c-Fn
	for sip-archive@odin.ietf.org; Mon, 20 Oct 2003 07:29:24 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KBTONk008159
	for sip-archive@odin.ietf.org; Mon, 20 Oct 2003 07:29:24 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABYDd-00022D-TM; Mon, 20 Oct 2003 07:29:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABYDQ-0001yp-Iz
	for sip@optimus.ietf.org; Mon, 20 Oct 2003 07:28:48 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21887
	for <sip@ietf.org>; Mon, 20 Oct 2003 07:28:40 -0400 (EDT)
From: hisham.khartabil@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABYDP-00071S-00
	for sip@ietf.org; Mon, 20 Oct 2003 07:28:48 -0400
Received: from mgw-x1.nokia.com ([131.228.20.21])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABYDP-000717-00
	for sip@ietf.org; Mon, 20 Oct 2003 07:28:47 -0400
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9KBS4d13628
	for <sip@ietf.org>; Mon, 20 Oct 2003 14:28:04 +0300 (EET DST)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T65664dfc54ac158f253b2@esvir05nok.ntc.nokia.com>;
 Mon, 20 Oct 2003 14:28:03 +0300
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Mon, 20 Oct 2003 14:28:02 +0300
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Default value for Accept:
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
Date: Mon, 20 Oct 2003 14:28:02 +0300
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017972B5@esebe019.ntc.nokia.com>
Thread-Topic: [Sip] Default value for Accept:
Thread-Index: AcOUxujg/gQHQY08QymcaQ3ZFvISJgCNZgJw
To: <rsparks@dynamicsoft.com>, <sip@ietf.org>
X-OriginalArrivalTime: 20 Oct 2003 11:28:02.0620 (UTC) FILETIME=[392627C0:01C396FD]
Content-Transfer-Encoding: quoted-printable
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: quoted-printable

The specification could be modified to be S/MIME friendly.  Making a =
multipart a SHOULD or a MUST to receive, as Cullen suggests, is one way. =
The other is to specify that if Accept-header is missing in the request, =
then the sender MUST be able to receive application/sdp or multipart =
bodies.

Regards,
Hisham

> -----Original Message-----
> From: ext Robert Sparks [mailto:rsparks@dynamicsoft.com]
> Sent: Friday, October 17, 2003 6:52 PM
> To: sip@ietf.org
> Subject: [Sip] Default value for Accept:
>=20
>=20
> If a request contains no Accept header field, the
> application processing that request is instructed
> by 3261 to use a default value of "application/sdp".
>=20
> Thus, if a client issues an OPTIONS or an INVITE with
> no Accept header field, the response body, if present,
> MUST be application/sdp. In particular, it cannot be
> multipart/<whatever>.
>=20
> This has interesting ramifications for the S/MIME
> security tools we've been trying to focus towards.
> A server cannot use them to secure a message unless
> the client explicitly declares support for multipart/mime
> in any request it sends?
>=20
> Is this OK? Do we want to try to adjust the default
> value of Accept (and what endpoints are required to
> understand)? Or do we just rely on pressuring the
> endpoints to always provide an Accept header with a
> whole bunch of stuff listed?
>=20
> RjS
>=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Mon Oct 20 09:51:34 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26200
	for <sip-archive@odin.ietf.org>; Mon, 20 Oct 2003 09:51:34 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABaRF-0000RM-Gn
	for sip-archive@odin.ietf.org; Mon, 20 Oct 2003 09:51:13 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KDpDVB001686
	for sip-archive@odin.ietf.org; Mon, 20 Oct 2003 09:51:13 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABaR4-0000OA-Td; Mon, 20 Oct 2003 09:51:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABaQr-0000LP-42
	for sip@optimus.ietf.org; Mon, 20 Oct 2003 09:50:51 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26169
	for <sip@ietf.org>; Mon, 20 Oct 2003 09:50:39 -0400 (EDT)
From: hisham.khartabil@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABaQp-0000Nl-00
	for sip@ietf.org; Mon, 20 Oct 2003 09:50:47 -0400
Received: from mgw-x4.nokia.com ([131.228.20.27])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABaMv-0000M9-00
	for sip@ietf.org; Mon, 20 Oct 2003 09:47:11 -0400
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9KDkZX11631
	for <sip@ietf.org>; Mon, 20 Oct 2003 16:46:35 +0300 (EET DST)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T6566ccccf7ac158f23077@esvir03nok.nokia.com>;
 Mon, 20 Oct 2003 16:46:34 +0300
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Mon, 20 Oct 2003 16:46:34 +0300
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] WGLC for URI and Header Parameter Registries
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
Date: Mon, 20 Oct 2003 16:46:34 +0300
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017972BA@esebe019.ntc.nokia.com>
Thread-Topic: [Sip] WGLC for URI and Header Parameter Registries
Thread-Index: AcOUDIs7SD1ikPRnSHWsh8uRzGsfjAC8QrFA
To: <dean.willis@softarmor.com>, <Gonzalo.Camarillo@ericsson.com>
Cc: <aki.niemi@nokia.com>, <rohan@cisco.com>, <sip@ietf.org>
X-OriginalArrivalTime: 20 Oct 2003 13:46:34.0623 (UTC) FILETIME=[937D28F0:01C39710]
Content-Transfer-Encoding: quoted-printable
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: quoted-printable

I thought the whole point of these drafts was to require everyone to =
register at IANA. What is the point if I still don't have to register? =
If no registering is mandated, then there will be clashes.

Regards,
Hisham

> -----Original Message-----
> From: ext Dean Willis [mailto:dean.willis@softarmor.com]
> Sent: Thursday, October 16, 2003 8:36 PM
> To: Gonzalo Camarillo
> Cc: Niemi Aki (NMP/Helsinki); ext Rohan Mahy; sip@ietf.org
> Subject: Re: [Sip] WGLC for URI and Header Parameter Registries
>=20
>=20
> On Thu, 2003-10-16 at 08:15, Gonzalo Camarillo wrote:
> > the policy you are talking about is exactly what the WG=20
> could not agree=20
> > on. The conclusion was that, for the time being, we will=20
> start keeping=20
> > track of RFC-defined parameters (the two drafts under=20
> WGLC). Meanwhile,=20
> > we will work on the proper policy to use in the future. For=20
> example, if=20
> > someone defines a SIP parameter in a Nokia technical=20
> report, it is OK to=20
> > register it or not... we will count with you for those=20
> discussions ;o)
> >=20
>=20
> I think, though, that we have to have some statement of policy in the
> draft before sending this up to IESG. We can, of course, change the
> policy later, so I'd suggest starting with the most=20
> restrictive langauge
> and loosening up later if it seems important.
>=20
> I would not now object to to a policy that says roughly "IANA=20
> registered
> paramters must be defined by an IETF specification" but retains the
> ability to use non-registered parameters without being "in=20
> violation of
> the specification." The logic is "If a parameter is IANA=20
> registered, it
> is a reserved word and has special meanings that we expect to be
> globally relevant. If a parameter is NOT registered, it's a personal
> matter."
>=20
> I think we want the barrier somewhat high for the declaration of a new
> "reserved word" in our vocabulary.
>=20
> --
> Dean
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Mon Oct 20 10:35:59 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28944
	for <sip-archive@odin.ietf.org>; Mon, 20 Oct 2003 10:35:59 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABb8F-0003A6-Ky
	for sip-archive@odin.ietf.org; Mon, 20 Oct 2003 10:35:39 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KEZdEo012095
	for sip-archive@odin.ietf.org; Mon, 20 Oct 2003 10:35:39 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABb7p-0002yg-Ny; Mon, 20 Oct 2003 10:35:13 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABb4b-0002F0-As
	for sip@optimus.ietf.org; Mon, 20 Oct 2003 10:31:53 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28719
	for <sip@ietf.org>; Mon, 20 Oct 2003 10:31:42 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABb4Y-0000oD-00
	for sip@ietf.org; Mon, 20 Oct 2003 10:31:51 -0400
Received: from imr2.ericy.com ([198.24.6.3])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABb4Y-0000n7-00
	for sip@ietf.org; Mon, 20 Oct 2003 10:31:50 -0400
Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51])
	by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id h9KEV9O8023229;
	Mon, 20 Oct 2003 09:31:09 -0500 (CDT)
Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.31.110]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59)
	id S8VDP65F; Mon, 20 Oct 2003 09:30:21 -0500
Message-ID: <3F93F1A9.2080806@ericsson.com>
Date: Mon, 20 Oct 2003 17:31:05 +0300
X-Sybari-Trust: 1f15230e 406a040f c001c63b 00000138
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: hisham.khartabil@nokia.com
CC: dean.willis@softarmor.com, aki.niemi@nokia.com, rohan@cisco.com,
        sip@ietf.org
References: <2038BCC78B1AD641891A0D1AE133DBB7017972BA@esebe019.ntc.nokia.com>
In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017972BA@esebe019.ntc.nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Non-RFC-defined parameter registries
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 would like to keep the WGLC about *RFC-defined* parameters and the 
discussions about *non-RFC-defined* parameters separate. That was the 
agreement we reached in Vienna.

So, I have changed the subject of this thread, since it deals with the 
latter.

Hisham, answering your question: I agree that we should register them to 
avoid colissions.

Gonzalo

hisham.khartabil@nokia.com wrote:

> I thought the whole point of these drafts was to require everyone to register at IANA. What is the point if I still don't have to register? If no registering is mandated, then there will be clashes.
> 
> 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 exim@www1.ietf.org  Mon Oct 20 12:05:33 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01943
	for <sip-archive@odin.ietf.org>; Mon, 20 Oct 2003 12:05:33 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABcWt-0000kF-Ma
	for sip-archive@odin.ietf.org; Mon, 20 Oct 2003 12:05:12 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KG5BOK002804
	for sip-archive@odin.ietf.org; Mon, 20 Oct 2003 12:05:11 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABcWl-0000gK-1y; Mon, 20 Oct 2003 12:05:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABcWc-0000eI-GO
	for sip@optimus.ietf.org; Mon, 20 Oct 2003 12:04:54 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01906
	for <sip@ietf.org>; Mon, 20 Oct 2003 12:04:44 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABcWb-0001ku-00
	for sip@ietf.org; Mon, 20 Oct 2003 12:04:53 -0400
Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABcWZ-0001k9-00
	for sip@ietf.org; Mon, 20 Oct 2003 12:04:52 -0400
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h9KG46Bf003166
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Mon, 20 Oct 2003 11:04:06 -0500
Received: (from dwillis@localhost)
	by bdsl.greycouncil.com (8.12.8/8.12.8/Submit) id h9KG45ce003164;
	Mon, 20 Oct 2003 11:04:05 -0500
X-Authentication-Warning: bdsl.greycouncil.com: dwillis set sender to dean.willis@softarmor.com using -f
Subject: RE: [Sip] WGLC for URI and Header Parameter Registries
From: Dean Willis <dean.willis@softarmor.com>
To: hisham.khartabil@nokia.com
Cc: Gonzalo.Camarillo@ericsson.com, aki.niemi@nokia.com, rohan@cisco.com,
        sip@ietf.org
In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017972BA@esebe019.ntc.nokia.com>
References: 
	 <2038BCC78B1AD641891A0D1AE133DBB7017972BA@esebe019.ntc.nokia.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1066665845.3002.23.camel@bdsl.greycouncil.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 
Date: Mon, 20 Oct 2003 11:04:05 -0500
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 Mon, 2003-10-20 at 08:46, hisham.khartabil@nokia.com wrote:
> I thought the whole point of these drafts was to require everyone to register at IANA. What is the point if I still don't have to register? If no registering is mandated, then there will be clashes.

The point was that the REALLY important parameter names, the ones that
NEED to interoperate and not clash, get registered.  And since they're
important enough to register, we want to know what they mean and how
they work, so a specification is required.

We had consensus that these important parameters needed to be in a
registry.

We did NOT have consensus that every parameter that might ever be used
for a one-off application needed to be registered.


So, what we're doing is defining a registry with a tight admissions
policy so we can get critical stufff "on the books", and we have the
option of relaxing that policy, if needed, at some future time, should
we ever have a consensus to do so.

--
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 exim@www1.ietf.org  Mon Oct 20 15:00:45 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08620
	for <sip-archive@odin.ietf.org>; Mon, 20 Oct 2003 15:00:44 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABfGS-0003WV-AF
	for sip-archive@odin.ietf.org; Mon, 20 Oct 2003 15:00:24 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KJ0NmQ013465
	for sip-archive@odin.ietf.org; Mon, 20 Oct 2003 15:00:23 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABfG8-0003Nm-RB; Mon, 20 Oct 2003 15:00:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABfFe-0003CH-P6
	for sip@optimus.ietf.org; Mon, 20 Oct 2003 14:59:35 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08269
	for <sip@ietf.org>; Mon, 20 Oct 2003 14:59:24 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABfFb-0003VD-00
	for sip@ietf.org; Mon, 20 Oct 2003 14:59:31 -0400
Received: from machine77.level3.com ([209.244.4.106] helo=cc26-01.idc1.level3.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABfFb-0003Th-00
	for sip@ietf.org; Mon, 20 Oct 2003 14:59:31 -0400
Received: from cc26-01.idc1.level3.com (localhost [127.0.0.1])
	by localhost (Postfix) with ESMTP
	id 67F9184357; Mon, 20 Oct 2003 18:59:00 +0000 (GMT)
Received: from idc1exc0001.corp.global.level3.com (idc1exc0001.corp.global.level3.com [10.1.7.194])
	by cc26-01.idc1.level3.com (Postfix) with SMTP
	id 6DAA68729A; Mon, 20 Oct 2003 18:58:59 +0000 (GMT)
Received: from idc1exc0004.corp.global.level3.com ([10.1.8.20]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Mon, 20 Oct 2003 12:58:58 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.6470.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 20 Oct 2003 12:58:58 -0600
Message-ID: <99148FC6551C9641A4B1CDE206D89544805B84@idc1exc0004.corp.global.level3.com>
Thread-Topic: Resource-Priority
Thread-Index: AcOXIB3nBASsXwrwRCCPED3GsIaCWAAFkrEA
From: "Srivastava, Samir" <Samir.Srivastava@Level3.com>
To: <schulzrinne@cs.columbia.edu>, <jmpolk@cisco.com>
Cc: <sip@ietf.org>
X-OriginalArrivalTime: 20 Oct 2003 18:58:58.0928 (UTC) FILETIME=[37F71F00:01C3973C]
Content-Transfer-Encoding: quoted-printable
Subject: [Sip] draft-ietf-sip-resource-priority-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: quoted-printable

Hi,
=20
   Below are are some comments on the =
draft-ietf-sip-resource-priority-01.txt .

1. Sec 3, P 6, It lists other methods where Resource-Priority can be =
used.
   REFER method is missing. It should be optional in REFER.=20

2. Table given in the section 3, doesn't allow Resource-Priority for=20
   OPTIONS Req and Accept-Resource-Priority for its Rsp. It should be
   allowed. Allowing this text exists in sec 4.6

3. Table given in section 3, makes the Accept-Resource-Priority "m"=20
   (MUST) for 420 whereas it should be optional. SIP device which is=20
   3261 compliant and not supporting this extension, will not have it.

4. Sec 3, P 6, In the para below table, it mentions =
"Accept-Resource-Priority=20
   is only returned in 420 (Not Supported) responses" which is =
incomplete,
   it MUST be in 417.

5. It needs to state the behaviour if Priority of 3261 and =
"Resource-Priority"=20
   both are specified in a REQ, They might have conflicting values. As =
per
   3261, Priority header may be factored into the call routing.

6.  In Sec 3, following BNF needs to be corrected.
=20
Resource-Priority  =3D  "Resource-Priority" HCOLON
                       (*COMMA Resource-value)
Accept-Resource-Priority _  "Accept-Resource-Priority" HCOLON
                                    Resource-value (*COMMA =
Resource-value)

The correct format should be

Resource-Priority  =3D  "Resource-Priority" HCOLON Resource-value
                       *(COMMA Resource-value)

Accept-Resource-Priority =3D "Accept-Resource-Priority" HCOLON
                            Resource-value *(COMMA Resource-value)


7. Why the values are taken as "NameSpace.<Priority>" , We can have NV=20
   pairs, with comma separated values and semicolon between different=20
   namespaces, Just for better brevity/expression ratio. Not much
   inclined to any choices.

8. It will be better, if it lists the changes from the earlier drafts =
and
   table of contents.

Thx
Samir




_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Mon Oct 20 17:49:32 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07521
	for <sip-archive@odin.ietf.org>; Mon, 20 Oct 2003 17:49:32 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABhto-00005G-PN
	for sip-archive@odin.ietf.org; Mon, 20 Oct 2003 17:49:12 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KLnCrN000318
	for sip-archive@odin.ietf.org; Mon, 20 Oct 2003 17:49:12 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABhte-0008Pv-69; Mon, 20 Oct 2003 17:49:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABhtY-0008Ml-0Y
	for sip@optimus.ietf.org; Mon, 20 Oct 2003 17:48:56 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07466
	for <sip@ietf.org>; Mon, 20 Oct 2003 17:48:45 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABhtV-0001Ns-00
	for sip@ietf.org; Mon, 20 Oct 2003 17:48:53 -0400
Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABhtU-0001Mq-00
	for sip@ietf.org; Mon, 20 Oct 2003 17:48:52 -0400
Received: from txdwillis (bdsl.66.12.12.254.gte.net [66.12.12.254])
	(authenticated bits=0)
	by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h9KLmDBe005103
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO);
	Mon, 20 Oct 2003 16:48:13 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: <sip@ietf.org>
Cc: "'Rohan Mahy'" <rohan@cisco.com>, <mankin@psg.com>
Date: Mon, 20 Oct 2003 16:48:00 -0500
Message-ID: <004701c39753$d584b630$e1036e3f@txdwillis>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
In-Reply-To: <16CE9E1B-FAA9-11D7-A0FD-0003938AF740@cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Content-Transfer-Encoding: 7bit
Subject: [Sip] WGLC for Join --  draft-ietf-sip-join-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>
Content-Transfer-Encoding: 7bit



On 10/9, Rohan polled to see if there were any objections to proceding with
WGLC for the the Join draft.

Since I didn't see any objections, I'd like to go ahead and begin that
working group last call.

Please review and make any final comments on:

http://www.ietf.org/internet-drafts/draft-ietf-sip-join-02.txt


Working Group Last Call will close November 4, 2003.

--
Dean Willis
SIP Co-Chair



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Mon Oct 20 22:53:51 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19991
	for <sip-archive@odin.ietf.org>; Mon, 20 Oct 2003 22:53:51 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABmeJ-00010x-90
	for sip-archive@odin.ietf.org; Mon, 20 Oct 2003 22:53:32 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9L2rV4s003840
	for sip-archive@odin.ietf.org; Mon, 20 Oct 2003 22:53:31 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABmdp-0000q3-Fk; Mon, 20 Oct 2003 22:53:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABmd7-0000bs-35
	for sip@optimus.ietf.org; Mon, 20 Oct 2003 22:52:17 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19969
	for <sip@ietf.org>; Mon, 20 Oct 2003 22:52:06 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABmd3-000614-00
	for sip@ietf.org; Mon, 20 Oct 2003 22:52:13 -0400
Received: from cs.columbia.edu ([128.59.16.20])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABmd2-00060w-00
	for sip@ietf.org; Mon, 20 Oct 2003 22:52:12 -0400
Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8])
	by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id h9L2qALZ024746;
	Mon, 20 Oct 2003 22:52:10 -0400 (EDT)
Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1])
	by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h9L2q2q02884;
	Mon, 20 Oct 2003 22:52:09 -0400
Message-ID: <3F949F51.1050906@cs.columbia.edu>
Date: Mon, 20 Oct 2003 22:52:01 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Samir.Srivastava@Level3.com, sip@ietf.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] draft-ietf-sip-resource-priority-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

Thanks for the comments. Leaving out the editorial issues that we'll be 
addressing in the post-WGLC phase, one question/comment:

> 7. Why the values are taken as "NameSpace.<Priority>" , We can have NV
>    pairs, with comma separated values and semicolon between different
>    namespaces, Just for better brevity/expression ratio. Not much
>    inclined to any choices. 

I'm not exactly sure what you had in mind here. Something like

namespace;priority,namespace;priority

?

If so, this would not conform to the standard conventions for SIP 
headers. Could you please explain?






_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Tue Oct 21 03:09:00 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08540
	for <sip-archive@odin.ietf.org>; Tue, 21 Oct 2003 03:09:00 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABqdE-0000ug-G9
	for sip-archive@odin.ietf.org; Tue, 21 Oct 2003 03:08:41 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9L78ex3003509
	for sip-archive@odin.ietf.org; Tue, 21 Oct 2003 03:08:40 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABqce-0000mG-Kr; Tue, 21 Oct 2003 03:08:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABqcP-0000h8-12
	for sip@optimus.ietf.org; Tue, 21 Oct 2003 03:07:49 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08514
	for <sip@ietf.org>; Tue, 21 Oct 2003 03:07:37 -0400 (EDT)
From: hisham.khartabil@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABqcK-0000S5-00
	for sip@ietf.org; Tue, 21 Oct 2003 03:07:44 -0400
Received: from mgw-x1.nokia.com ([131.228.20.21])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABqcJ-0000S2-00
	for sip@ietf.org; Tue, 21 Oct 2003 03:07:44 -0400
Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])
	by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9L77hd06162
	for <sip@ietf.org>; Tue, 21 Oct 2003 10:07:43 +0300 (EET DST)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T656a85fff1ac158f21082@esvir01nok.ntc.nokia.com>;
 Tue, 21 Oct 2003 10:07:43 +0300
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747);
	 Tue, 21 Oct 2003 10:07:43 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] WGLC for URI and Header Parameter Registries
Date: Tue, 21 Oct 2003 10:07:43 +0300
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017972C9@esebe019.ntc.nokia.com>
Thread-Topic: [Sip] WGLC for URI and Header Parameter Registries
Thread-Index: AcOXI+iCR27gcbaISWmx/OQ16BRysAAfem/Q
To: <dean.willis@softarmor.com>
Cc: <Gonzalo.Camarillo@ericsson.com>, <aki.niemi@nokia.com>, <rohan@cisco.com>,
        <sip@ietf.org>
X-OriginalArrivalTime: 21 Oct 2003 07:07:43.0622 (UTC) FILETIME=[05E9F260:01C397A2]
Content-Transfer-Encoding: quoted-printable
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: quoted-printable



> -----Original Message-----
> From: ext Dean Willis [mailto:dean.willis@softarmor.com]
> Sent: Monday, October 20, 2003 7:04 PM
> To: Khartabil Hisham (NMP-MSW/Helsinki)
> Cc: Gonzalo.Camarillo@ericsson.com; Niemi Aki (NMP/Helsinki);
> rohan@cisco.com; sip@ietf.org
> Subject: RE: [Sip] WGLC for URI and Header Parameter Registries
>=20
>=20
> On Mon, 2003-10-20 at 08:46, hisham.khartabil@nokia.com wrote:
> > I thought the whole point of these drafts was to require=20
> everyone to register at IANA. What is the point if I still=20
> don't have to register? If no registering is mandated, then=20
> there will be clashes.
>=20
> The point was that the REALLY important parameter names, the ones that
> NEED to interoperate and not clash, get registered.  And since they're
> important enough to register, we want to know what they mean and how
> they work, so a specification is required.
>=20
> We had consensus that these important parameters needed to be in a
> registry.
>=20
> We did NOT have consensus that every parameter that might ever be used
> for a one-off application needed to be registered.

What does "one-off application" mean?

/Hisham

>=20
>=20
> So, what we're doing is defining a registry with a tight admissions
> policy so we can get critical stufff "on the books", and we have the
> option of relaxing that policy, if needed, at some future time, should
> we ever have a consensus to do so.
>=20
> --
> Dean
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Tue Oct 21 04:10:42 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09743
	for <sip-archive@odin.ietf.org>; Tue, 21 Oct 2003 04:10:42 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABraw-00027M-RX
	for sip-archive@odin.ietf.org; Tue, 21 Oct 2003 04:10:22 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9L8AMQF008081
	for sip-archive@odin.ietf.org; Tue, 21 Oct 2003 04:10:22 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABrae-000205-C5; Tue, 21 Oct 2003 04:10:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABraM-0001vb-UK
	for sip@optimus.ietf.org; Tue, 21 Oct 2003 04:09:46 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09677
	for <sip@ietf.org>; Tue, 21 Oct 2003 04:09:36 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABraK-0000pl-00
	for sip@ietf.org; Tue, 21 Oct 2003 04:09:44 -0400
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABraJ-0000pM-00
	for sip@ietf.org; Tue, 21 Oct 2003 04:09:43 -0400
Received: from dynamicsoft.com ([63.113.46.28])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h9L89Ica003009
	for <sip@ietf.org>; Tue, 21 Oct 2003 04:09:18 -0400 (EDT)
Message-ID: <3F94E9A9.5020707@dynamicsoft.com>
Date: Tue, 21 Oct 2003 04:09:13 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
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] GRUU Mechanism I-D
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've submitted a new I-D that proposes a specific mechanism for GRUUs 
that meets the requiremetns draft under discussion in sipping. Based 
on our conclusion in the list discussion, the GRUU is placed into the 
Contact header field, and therefore does not require both caller and 
callee to support it.

Until the I-D appears in the archives, you can pick up a copy at:
http://www.jdrosen.net/papers/draft-rosenberg-sip-gruu-00.txt

There are still some open issues. The most notable one, I think, is 
how a UA knows about whether it can construct a GRUU locally, or 
whether it needs to obtain one from its provider. The draft recommends 
that a UA never try to use a locally constructed one. This is under 
the premise that it will never have a good way to know whether it is 
globally reachable. The drawback to this, of course, is that we will 
never see direct UA to UA signaling anymore.

Comments and questions welcome.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
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 exim@www1.ietf.org  Tue Oct 21 10:01:54 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17794
	for <sip-archive@odin.ietf.org>; Tue, 21 Oct 2003 10:01:54 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABx4o-0002qN-PB
	for sip-archive@odin.ietf.org; Tue, 21 Oct 2003 10:01:35 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LE1YXk010927
	for sip-archive@odin.ietf.org; Tue, 21 Oct 2003 10:01:34 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABx4J-0002eq-4Q; Tue, 21 Oct 2003 10:01:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABx3o-0002WU-Fy
	for sip@optimus.ietf.org; Tue, 21 Oct 2003 10:00:32 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17749
	for <sip@ietf.org>; Tue, 21 Oct 2003 10:00:20 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABx3m-0003gB-00
	for sip@ietf.org; Tue, 21 Oct 2003 10:00:30 -0400
Received: from ams-iport-1.cisco.com ([144.254.74.5])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABx3l-0003fk-00
	for sip@ietf.org; Tue, 21 Oct 2003 10:00:30 -0400
Received: from cisco.com (171.71.177.254)
  by ams-iport-1.cisco.com with ESMTP; 21 Oct 2003 15:58:01 +0200
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9LDxsiw008413;
	Tue, 21 Oct 2003 06:59:55 -0700 (PDT)
Received: from cisco.com ([161.44.79.51])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ADI25174;
	Tue, 21 Oct 2003 09:59:53 -0400 (EDT)
Message-ID: <3F953BD9.7040505@cisco.com>
Date: Tue, 21 Oct 2003 09:59:53 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: sip@ietf.org
Subject: Re: [Sip] GRUU Mechanism I-D
References: <3F94E9A9.5020707@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

Jonathan,

This is looking good!

I did find a few issues worth mentioning:

1) impact on registration refreshes:

Section 4.1 says: "... the Contact URI in the REGISTER request SHOULD 
NOT contain the gruu Contact header field parameter."

The question is whether a registration refresh should contain the gruu 
previously returned, and if it does, whether than changes behavior. For 
instance, a refresh that contains the old gruu might indicate a desire 
to retain that gruu, while a refresh without it might be interpretted as 
a request for a new gruu. The messy case would be where a registration 
contains a gruu parameter that isn't a valid gruu for that registrar.

I don't have strong feelings about what the details are here - only that 
the behavior should be better defined.

2) Should register response contain "Supported: gruu"? You don't mention 
or show that, but it seems like a reasonable thing.

3) Section 4.3 says:

    When a UA (UA 1) wishes to generate a request to another UA, UA 2,
    and UA 1 and UA 2 are involved in an active dialog, and the request
    is not associated with the existing dialog, and UA 2 indicated
    support for this extension, UA 1 SHOULD send the request to the
    remote target URI if UA 2. Examples of such requests are SUBSCRIBE
    and REFER. Currently, RFC 3261 describes the notion of dialog
    sharing, which would advocate generation of these requests within the
    context of the existing dialog. This specification supercedes that
    behavior. In cases where UA 1 wishes to send the request, but UA 2
    has not indicated support for GRUU, UA 1 SHOULD send the request on
    the existing dialog.

If gruus were universally supported and dialog sharing had never been 
invented then this may have been a good idea. But as things are I think 
this just makes a bad situation worse - you still have to support dialog 
sharing, and also implement added logic to not use it under certain 
circumstances. My preference is just to omit this paragraph altogether. 
If a gruu is present, it provides an option that may be used if desired, 
but there is nothing normative about it.

In the case of REFER there may be added negatives to this approach. A 
REFER received in dialog with an INVITE can be interpretted as having 
different semantics from a REFER outside of a dialog. This is a useful 
distinction that is lost with the proposed change.

	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 exim@www1.ietf.org  Tue Oct 21 11:32:38 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23458
	for <sip-archive@odin.ietf.org>; Tue, 21 Oct 2003 11:32:38 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AByUc-0002si-P7
	for sip-archive@odin.ietf.org; Tue, 21 Oct 2003 11:32:18 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LFWIId011070
	for sip-archive@odin.ietf.org; Tue, 21 Oct 2003 11:32:18 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AByUL-0002p2-N6; Tue, 21 Oct 2003 11:32:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AByUE-0002o6-6C
	for sip@optimus.ietf.org; Tue, 21 Oct 2003 11:31:54 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23445
	for <sip@ietf.org>; Tue, 21 Oct 2003 11:31:43 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AByUD-00052o-00
	for sip@ietf.org; Tue, 21 Oct 2003 11:31:53 -0400
Received: from magus.nostrum.com ([208.21.192.130] ident=root)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AByUC-00052l-00
	for sip@ietf.org; Tue, 21 Oct 2003 11:31:52 -0400
Received: from dynamicsoft.com (ben@localhost [127.0.0.1])
	by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9LFVnF8013447;
	Tue, 21 Oct 2003 10:31:50 -0500 (CDT)
	(envelope-from bcampbell@dynamicsoft.com)
Message-ID: <3F955155.2090804@dynamicsoft.com>
Date: Tue, 21 Oct 2003 10:31:33 -0500
From: Ben Campbell <bcampbell@dynamicsoft.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: hisham.khartabil@nokia.com
CC: rsparks@dynamicsoft.com, sip@ietf.org
Subject: Re: [Sip] Default value for Accept:
References: <2038BCC78B1AD641891A0D1AE133DBB7017972B5@esebe019.ntc.nokia.com>
In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017972B5@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:

> The specification could be modified to be S/MIME friendly.  Making a multipart a SHOULD or a MUST to receive, as Cullen suggests, is one way. The other is to specify that if Accept-header is missing in the request, then the sender MUST be able to receive application/sdp or multipart bodies.

I would agree with both making multipart (at least) a SHOULD, and making 
it part of the default Accept value. But that would create backwards 
compatability issues, and the try multipart-fail-try again use case the 
Cullen mentions would become common. Is this something we can live with?

> 
> Regards,
> Hisham
> 
> 
>>-----Original Message-----
>>From: ext Robert Sparks [mailto:rsparks@dynamicsoft.com]
>>Sent: Friday, October 17, 2003 6:52 PM
>>To: sip@ietf.org
>>Subject: [Sip] Default value for Accept:
>>
>>
>>If a request contains no Accept header field, the
>>application processing that request is instructed
>>by 3261 to use a default value of "application/sdp".
>>
>>Thus, if a client issues an OPTIONS or an INVITE with
>>no Accept header field, the response body, if present,
>>MUST be application/sdp. In particular, it cannot be
>>multipart/<whatever>.
>>
>>This has interesting ramifications for the S/MIME
>>security tools we've been trying to focus towards.
>>A server cannot use them to secure a message unless
>>the client explicitly declares support for multipart/mime
>>in any request it sends?
>>
>>Is this OK? Do we want to try to adjust the default
>>value of Accept (and what endpoints are required to
>>understand)? Or do we just rely on pressuring the
>>endpoints to always provide an Accept header with a
>>whole bunch of stuff listed?
>>
>>RjS
>>
>>
>>_______________________________________________
>>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Tue Oct 21 13:36:55 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27559
	for <sip-archive@odin.ietf.org>; Tue, 21 Oct 2003 13:36:55 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AC0Qv-0003fv-7O
	for sip-archive@odin.ietf.org; Tue, 21 Oct 2003 13:36:37 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LHabG5014121
	for sip-archive@odin.ietf.org; Tue, 21 Oct 2003 13:36:37 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AC0QL-0003Qk-Ej; Tue, 21 Oct 2003 13:36:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AC0QF-0003PH-NO
	for sip@optimus.ietf.org; Tue, 21 Oct 2003 13:35:55 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27468
	for <sip@ietf.org>; Tue, 21 Oct 2003 13:35:43 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AC0QD-0006Qb-00
	for sip@ietf.org; Tue, 21 Oct 2003 13:35:53 -0400
Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AC0QC-0006QK-00
	for sip@ietf.org; Tue, 21 Oct 2003 13:35:52 -0400
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h9LHZ6Bf010075
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Tue, 21 Oct 2003 12:35:06 -0500
Received: (from dwillis@localhost)
	by bdsl.greycouncil.com (8.12.8/8.12.8/Submit) id h9LHZ662010073;
	Tue, 21 Oct 2003 12:35:06 -0500
X-Authentication-Warning: bdsl.greycouncil.com: dwillis set sender to dean.willis@softarmor.com using -f
Subject: RE: [Sip] WGLC for URI and Header Parameter Registries
From: Dean Willis <dean.willis@softarmor.com>
To: hisham.khartabil@nokia.com
Cc: Gonzalo.Camarillo@ericsson.com, aki.niemi@nokia.com, rohan@cisco.com,
        sip@ietf.org
In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017972C9@esebe019.ntc.nokia.com>
References: 
	 <2038BCC78B1AD641891A0D1AE133DBB7017972C9@esebe019.ntc.nokia.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1066757706.9917.19.camel@bdsl.greycouncil.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 
Date: Tue, 21 Oct 2003 12:35:06 -0500
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 Tue, 2003-10-21 at 02:07, hisham.khartabil@nokia.com wrote:
> Dean sai:
> > We did NOT have consensus that every parameter that might ever be used
> > for a one-off application needed to be registered.
> 
> What does "one-off application" mean?

"One-off" is a colloquialism for a thing used one time and then
discarded or obsoleted.

An example here might be a college student who is working on an
application using SIP to invite his friends to play a game that he just
wrote as a class project. The invitation carries a new parameter he made
up, "Game=X78hj9p" that the SIP proxy uses to route players to the right
game session.

Since he hasn't written the RFC to register the parameter "Game" and
define exactly what the value "X78hj9p" means, we'd have to send out the
protocol police to arrest him for violating the specification. Or even
worse, perhaps his professor would force him to write the RFC, and then
"Game" could ONLY be used as he had previously specified it, and every
other college student from then on out with have to come up with
something else to call their new parameter. In short, something that has
no reason to be "standardized" would suddenly become an IANA registered
reality . . . (this is especially aggravating on an open-registration
first-come-first-served registery).

Or we go with plan B -- since "Game" isn't a registered parameter, he
can use it however he wants, and if it breaks something (like the
different use of "Game" in his roommate's class project), that's his
problem. Or his roomates. But if he tries to reuse "lr", which we DID
register (and define in an RFC), his professor can slap him around and
point out the documentation for what he did wrong.

--
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 exim@www1.ietf.org  Tue Oct 21 15:59:45 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04484
	for <sip-archive@odin.ietf.org>; Tue, 21 Oct 2003 15:59:45 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AC2f7-0000Ja-TQ
	for sip-archive@odin.ietf.org; Tue, 21 Oct 2003 15:59:25 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LJxPn6001151
	for sip-archive@odin.ietf.org; Tue, 21 Oct 2003 15:59:25 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AC2el-0000CZ-4X; Tue, 21 Oct 2003 15:59:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AC2eC-0008Jd-3T
	for sip@optimus.ietf.org; Tue, 21 Oct 2003 15:58:28 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04127;
	Tue, 21 Oct 2003 15:58:17 -0400 (EDT)
Message-Id: <200310211958.PAA04127@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, 21 Oct 2003 15:58:16 -0400
Subject: [Sip] I-D ACTION:draft-jennings-sip-sec-flows-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		: Example call flows using SIP security mechanisms
	Author(s)	: C. Jennings
	Filename	: draft-jennings-sip-sec-flows-00.txt
	Pages		: 43
	Date		: 2003-10-21
	
This document shows call flows demonstrating the use of SIPS, TLS,
and S/MIME in SIP. This draft provides information that helps
implementors build interoperable SIP software. It is purely
informational. To help facilitate interoperability testing, it
includes certificates used in the example call flows and a CA
certificate to create certificates for testing.

Warning - this is a very early draft of this document. The call flows
in it have not been verified against multiple versions of the
software and have reasonable odds of being wrong.

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-jennings-sip-sec-flows-00.txt

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

Content-Type: text/plain
Content-ID:	<2003-10-21153508.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 exim@www1.ietf.org  Tue Oct 21 16:00:29 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04670
	for <sip-archive@odin.ietf.org>; Tue, 21 Oct 2003 16:00:29 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AC2fp-0000g3-8n
	for sip-archive@odin.ietf.org; Tue, 21 Oct 2003 16:00:09 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LK07Px002388
	for sip-archive@odin.ietf.org; Tue, 21 Oct 2003 16:00:07 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AC2fk-0000a6-Gu; Tue, 21 Oct 2003 16:00:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AC2f1-0000GZ-Hp
	for sip@optimus.ietf.org; Tue, 21 Oct 2003 15:59:19 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04367;
	Tue, 21 Oct 2003 15:59:08 -0400 (EDT)
Message-Id: <200310211959.PAA04367@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, 21 Oct 2003 15:59:08 -0400
Subject: [Sip] I-D ACTION:draft-mahy-sip-remote-cc-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		: Remote Call Control in SIP using the REFER method 
			  and the session-oriented dialog package
	Author(s)	: R. Mahy, O. Levin
	Filename	: draft-mahy-sip-remote-cc-00.txt
	Pages		: 19
	Date		: 2003-10-21
	
This document describes how to use the SIP REFER method and the
dialog package to manipulate conversations, dialogs, and sessions on
remote User Agents.  This functionality is most  useful for
collections of loosely coupled User Agents that wish to present a
coordinated user experience.  It does not require a Third-Party Call
Control controller to be involved in any of the manipulated dialogs.

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-mahy-sip-remote-cc-00.txt

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

Content-Type: text/plain
Content-ID:	<2003-10-21153722.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 exim@www1.ietf.org  Tue Oct 21 20:47:39 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21690
	for <sip-archive@odin.ietf.org>; Tue, 21 Oct 2003 20:47:39 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AC79j-0006Ye-Jo
	for sip-archive@odin.ietf.org; Tue, 21 Oct 2003 20:47:20 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9M0lJST025147
	for sip-archive@odin.ietf.org; Tue, 21 Oct 2003 20:47:19 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AC79S-0006SL-3R; Tue, 21 Oct 2003 20:47:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AC78W-0006EW-IS
	for sip@optimus.ietf.org; Tue, 21 Oct 2003 20:46:04 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21658
	for <sip@ietf.org>; Tue, 21 Oct 2003 20:45:53 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AC78U-0005mW-00
	for sip@ietf.org; Tue, 21 Oct 2003 20:46:02 -0400
Received: from machine77.level3.com ([209.244.4.106] helo=cc26-01.idc1.level3.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AC78T-0005mF-00
	for sip@ietf.org; Tue, 21 Oct 2003 20:46:01 -0400
Received: from cc26-01.idc1.level3.com (localhost [127.0.0.1])
	by localhost (Postfix) with ESMTP
	id 291AF848C4; Wed, 22 Oct 2003 00:45:26 +0000 (GMT)
Received: from idc1exc0001.corp.global.level3.com (idc1exc0001.corp.global.level3.com [10.1.7.194])
	by cc26-01.idc1.level3.com (Postfix) with SMTP
	id E2EE28483A; Wed, 22 Oct 2003 00:45:25 +0000 (GMT)
Received: from idc1exc0004.corp.global.level3.com ([10.1.8.20]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 21 Oct 2003 18:45:25 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.6470.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 21 Oct 2003 18:45:25 -0600
Message-ID: <99148FC6551C9641A4B1CDE206D89544805B85@idc1exc0004.corp.global.level3.com>
Thread-Topic: draft-ietf-sip-resource-priority-01.txt
Thread-Index: AcOXflbPrXAeFlsWSseNQMR+XOmiPQAtRbrA
From: "Srivastava, Samir" <Samir.Srivastava@Level3.com>
To: "Henning Schulzrinne" <hgs@cs.columbia.edu>
Cc: <sip@ietf.org>
X-OriginalArrivalTime: 22 Oct 2003 00:45:25.0778 (UTC) FILETIME=[C84E7720:01C39835]
Content-Transfer-Encoding: quoted-printable
Subject: [Sip] RE: draft-ietf-sip-resource-priority-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: quoted-printable


Hi,

As per my proposal, the sample RP header looks like

Resource-Priority: q735 =3D 1, 2, 3,4 ; dsn =3D flash, immediate=20

It doesn't repeat Namespace. "," is used for multiple value separator,
and ";" is used as namespace separator as per SIP convention. =20

Thx
Samir

-----Original Message-----
From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20
Sent: Monday, October 20, 2003 7:52 PM
To: Srivastava, Samir; sip@ietf.org
Subject: draft-ietf-sip-resource-priority-01.txt

Thanks for the comments. Leaving out the editorial issues that we'll be=20
addressing in the post-WGLC phase, one question/comment:

> 7. Why the values are taken as "NameSpace.<Priority>" , We can have NV
>    pairs, with comma separated values and semicolon between different
>    namespaces, Just for better brevity/expression ratio. Not much
>    inclined to any choices.=20

I'm not exactly sure what you had in mind here. Something like

namespace;priority,namespace;priority

?

If so, this would not conform to the standard conventions for SIP=20
headers. Could you please explain?






_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Tue Oct 21 21:54:34 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23271
	for <sip-archive@odin.ietf.org>; Tue, 21 Oct 2003 21:54:34 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AC8CV-0001DO-BT
	for sip-archive@odin.ietf.org; Tue, 21 Oct 2003 21:54:16 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9M1sFOm004611
	for sip-archive@odin.ietf.org; Tue, 21 Oct 2003 21:54:15 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AC8CI-00018b-0k; Tue, 21 Oct 2003 21:54:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AC8Bg-0000yg-TT
	for sip@optimus.ietf.org; Tue, 21 Oct 2003 21:53:25 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23259
	for <sip@ietf.org>; Tue, 21 Oct 2003 21:53:13 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AC8Bd-0006Ko-00
	for sip@ietf.org; Tue, 21 Oct 2003 21:53:21 -0400
Received: from cs.columbia.edu ([128.59.16.20])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AC8Bd-0006Kg-00
	for sip@ietf.org; Tue, 21 Oct 2003 21:53:21 -0400
Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8])
	by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id h9M1rKLZ009187;
	Tue, 21 Oct 2003 21:53:20 -0400 (EDT)
Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1])
	by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h9M1rDv12108;
	Tue, 21 Oct 2003 21:53:19 -0400
Message-ID: <3F95E307.2000709@cs.columbia.edu>
Date: Tue, 21 Oct 2003 21:53:11 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Srivastava, Samir" <Samir.Srivastava@Level3.com>
CC: sip@ietf.org
References: <99148FC6551C9641A4B1CDE206D89544805B85@idc1exc0004.corp.global.level3.com>
In-Reply-To: <99148FC6551C9641A4B1CDE206D89544805B85@idc1exc0004.corp.global.level3.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Re: draft-ietf-sip-resource-priority-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

Srivastava, Samir wrote:

> Hi,
> 
> As per my proposal, the sample RP header looks like
> 
> Resource-Priority: q735 = 1, 2, 3,4 ; dsn = flash, immediate 
> 
> It doesn't repeat Namespace. "," is used for multiple value separator,
> and ";" is used as namespace separator as per SIP convention.  
> 

Unfortunately, this does not conform to the SIP header naming 
convention, which has the ',' as the high-order separator. In addition, 
and more importantly, it would be unlikely (and illegal in most cases) 
to enumerate multiple values from the same namespace, as that has no 
real meaning.


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Tue Oct 21 22:57:32 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24843
	for <sip-archive@odin.ietf.org>; Tue, 21 Oct 2003 22:57:32 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AC9BS-0002Fq-41
	for sip-archive@odin.ietf.org; Tue, 21 Oct 2003 22:57:14 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9M2vEUV008660
	for sip-archive@odin.ietf.org; Tue, 21 Oct 2003 22:57:14 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AC9BF-0002Cy-Dy; Tue, 21 Oct 2003 22:57:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AC9AR-00024w-UH
	for sip@optimus.ietf.org; Tue, 21 Oct 2003 22:56:11 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24798
	for <sip@ietf.org>; Tue, 21 Oct 2003 22:55:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AC9AO-0006uL-00
	for sip@ietf.org; Tue, 21 Oct 2003 22:56:08 -0400
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AC9AN-0006tQ-00
	for sip@ietf.org; Tue, 21 Oct 2003 22:56:07 -0400
Received: from dynamicsoft.com ([63.113.46.14])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h9M2tYca003502;
	Tue, 21 Oct 2003 22:55:34 -0400 (EDT)
Message-ID: <3F95F1A2.2060107@dynamicsoft.com>
Date: Tue, 21 Oct 2003 22:55:30 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@cisco.com>
CC: sip@ietf.org
Subject: Re: [Sip] GRUU Mechanism I-D
References: <3F94E9A9.5020707@dynamicsoft.com> <3F953BD9.7040505@cisco.com>
In-Reply-To: <3F953BD9.7040505@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

Thanks for the comments, Paul. Responses inline.

Paul Kyzivat wrote:

> Jonathan,
> 
> This is looking good!
> 
> I did find a few issues worth mentioning:
> 
> 1) impact on registration refreshes:
> 
> Section 4.1 says: "... the Contact URI in the REGISTER request SHOULD 
> NOT contain the gruu Contact header field parameter."
> 
> The question is whether a registration refresh should contain the gruu 
> previously returned, and if it does, whether than changes behavior. For 
> instance, a refresh that contains the old gruu might indicate a desire 
> to retain that gruu, while a refresh without it might be interpretted as 
> a request for a new gruu. The messy case would be where a registration 
> contains a gruu parameter that isn't a valid gruu for that registrar.
> 
> I don't have strong feelings about what the details are here - only that 
> the behavior should be better defined.

I think we should keep things simple here. Things get complex if you 
allow the GRUU for a particular contact URI to change, either at the 
request of the UA, or because of some decision by the registrar. If 
you require that, as long as a Contact URI is registered to an AOR, 
the GRUU for that Contact URI is fixed, I think thats a good thing. In 
this case, there is no reason for the UA to provide the gruu in the 
REGISTER request.



> 
> 2) Should register response contain "Supported: gruu"? You don't mention 
> or show that, but it seems like a reasonable thing.

Normally, if Supported is in a request, the response would contain a 
Require header if that extension is needed to process the response. In 
this case, I don't think it is NEEDED to process the response. That 
is, if the extension is ignored, the response is still processed 
correctly.

I dont see the point in placing Supported into the REGISTER response. 
The presence of the gruu parameters indicates that the extension is 
supported.

> 
> 3) Section 4.3 says:
> 
>    When a UA (UA 1) wishes to generate a request to another UA, UA 2,
>    and UA 1 and UA 2 are involved in an active dialog, and the request
>    is not associated with the existing dialog, and UA 2 indicated
>    support for this extension, UA 1 SHOULD send the request to the
>    remote target URI if UA 2. Examples of such requests are SUBSCRIBE
>    and REFER. Currently, RFC 3261 describes the notion of dialog
>    sharing, which would advocate generation of these requests within the
>    context of the existing dialog. This specification supercedes that
>    behavior. In cases where UA 1 wishes to send the request, but UA 2
>    has not indicated support for GRUU, UA 1 SHOULD send the request on
>    the existing dialog.
> 
> If gruus were universally supported and dialog sharing had never been 
> invented then this may have been a good idea. But as things are I think 
> this just makes a bad situation worse - you still have to support dialog 
> sharing, and also implement added logic to not use it under certain 
> circumstances. 

Right. Such is the pain of transitioning from a mechanism that 
frequently won't work, but is currently standardized, to one that will 
work much better, and is now being introduced.


> My preference is just to omit this paragraph altogether. 
> If a gruu is present, it provides an option that may be used if desired, 
> but there is nothing normative about it.

Well, I would like us to move away from dialog reuse, and its best, I 
think, if we give guidance to implementors about this, rather than let 
them continue to use dialog reuse.

> 
> In the case of REFER there may be added negatives to this approach. A 
> REFER received in dialog with an INVITE can be interpretted as having 
> different semantics from a REFER outside of a dialog. This is a useful 
> distinction that is lost with the proposed change.

This is a good point. Of course, the REAL problem here is that the 
REFER request ought to go on the dialog, followed by a separate 
SUBSCRIBE to the GRUU, in order to track progress of the refer. That 
is, its the implicit subscriptions which makes this complicated.

That said, we may need to except REFER from this rule. Bleh.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
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 exim@www1.ietf.org  Tue Oct 21 23:05:43 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25055
	for <sip-archive@odin.ietf.org>; Tue, 21 Oct 2003 23:05:43 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AC9JM-0003hk-Rx
	for sip-archive@odin.ietf.org; Tue, 21 Oct 2003 23:05:25 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9M35Ovm014240
	for sip-archive@odin.ietf.org; Tue, 21 Oct 2003 23:05:24 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AC9J7-0003eA-VC; Tue, 21 Oct 2003 23:05:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AC9IT-0003Xu-UM
	for sip@optimus.ietf.org; Tue, 21 Oct 2003 23:04:30 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25036
	for <sip@ietf.org>; Tue, 21 Oct 2003 23:04:17 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AC9IQ-0006zb-00
	for sip@ietf.org; Tue, 21 Oct 2003 23:04:26 -0400
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AC9IP-0006zG-00
	for sip@ietf.org; Tue, 21 Oct 2003 23:04:25 -0400
Received: from dynamicsoft.com ([63.113.46.14])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h9M33wca003506;
	Tue, 21 Oct 2003 23:03:58 -0400 (EDT)
Message-ID: <3F95F39A.2020701@dynamicsoft.com>
Date: Tue, 21 Oct 2003 23:03:54 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ben Campbell <bcampbell@dynamicsoft.com>
CC: hisham.khartabil@nokia.com, rsparks@dynamicsoft.com, sip@ietf.org
Subject: Re: [Sip] Default value for Accept:
References: <2038BCC78B1AD641891A0D1AE133DBB7017972B5@esebe019.ntc.nokia.com> <3F955155.2090804@dynamicsoft.com>
In-Reply-To: <3F955155.2090804@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 am hesitant to make such a substantial change as to now mandate 
support for multipart.

In practice, I think that the send/fail/retry will not be so common. I 
would be surprised if UA's, by *default* sign everything they send. I 
believe a more common case will be that users will dial from their 
phone books, which will have additional info on whether or not that 
recipient has, in the past, indicated that it can accept multipart and 
signed bodies. Thats no guarantee about support for future calls, but 
its a good bet.

Also, note that we already have a bug with regards to default Accept 
values. RFC 3261 says that the default is application/sdp. But rfc3265 
says something quite different:

> 3.1.3. Additional SUBSCRIBE Header Values
> 
>    Because SUBSCRIBE requests create a dialog as defined in SIP [1],
>    they MAY contain an "Accept" header.  This header, if present,
>    indicates the body formats allowed in subsequent NOTIFY requests.
>    Event packages MUST define the behavior for SUBSCRIBE requests
>    without "Accept" headers; usually, this will connote a single,
>    default body type.

which says that each package defines the default value of Accept.

-Jonathan R.


Ben Campbell wrote:

> hisham.khartabil@nokia.com wrote:
> 
>> The specification could be modified to be S/MIME friendly.  Making a 
>> multipart a SHOULD or a MUST to receive, as Cullen suggests, is one 
>> way. The other is to specify that if Accept-header is missing in the 
>> request, then the sender MUST be able to receive application/sdp or 
>> multipart bodies.
> 
> 
> I would agree with both making multipart (at least) a SHOULD, and making 
> it part of the default Accept value. But that would create backwards 
> compatability issues, and the try multipart-fail-try again use case the 
> Cullen mentions would become common. Is this something we can live with?
> 
>>
>> Regards,
>> Hisham
>>
>>
>>> -----Original Message-----
>>> From: ext Robert Sparks [mailto:rsparks@dynamicsoft.com]
>>> Sent: Friday, October 17, 2003 6:52 PM
>>> To: sip@ietf.org
>>> Subject: [Sip] Default value for Accept:
>>>
>>>
>>> If a request contains no Accept header field, the
>>> application processing that request is instructed
>>> by 3261 to use a default value of "application/sdp".
>>>
>>> Thus, if a client issues an OPTIONS or an INVITE with
>>> no Accept header field, the response body, if present,
>>> MUST be application/sdp. In particular, it cannot be
>>> multipart/<whatever>.
>>>
>>> This has interesting ramifications for the S/MIME
>>> security tools we've been trying to focus towards.
>>> A server cannot use them to secure a message unless
>>> the client explicitly declares support for multipart/mime
>>> in any request it sends?
>>>
>>> Is this OK? Do we want to try to adjust the default
>>> value of Accept (and what endpoints are required to
>>> understand)? Or do we just rely on pressuring the
>>> endpoints to always provide an Accept header with a
>>> whole bunch of stuff listed?
>>>
>>> RjS
>>>
>>>
>>> _______________________________________________
>>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>> This list is for NEW development of the core SIP 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
> 

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
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 exim@www1.ietf.org  Wed Oct 22 02:07:42 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06652
	for <sip-archive@odin.ietf.org>; Wed, 22 Oct 2003 02:07:42 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACC9R-0006Sz-RO
	for sip-archive@odin.ietf.org; Wed, 22 Oct 2003 02:07:22 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9M67LTI024784
	for sip-archive@odin.ietf.org; Wed, 22 Oct 2003 02:07:21 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACC98-0006HB-3l; Wed, 22 Oct 2003 02:07:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACC8a-00069g-5v
	for sip@optimus.ietf.org; Wed, 22 Oct 2003 02:06:28 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05262
	for <sip@ietf.org>; Wed, 22 Oct 2003 02:06:17 -0400 (EDT)
From: hisham.khartabil@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACC8W-0000aM-00
	for sip@ietf.org; Wed, 22 Oct 2003 02:06:24 -0400
Received: from mgw-x4.nokia.com ([131.228.20.27])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACC8V-0000aH-00
	for sip@ietf.org; Wed, 22 Oct 2003 02:06:23 -0400
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9M66Lq20220
	for <sip@ietf.org>; Wed, 22 Oct 2003 09:06:21 +0300 (EET DST)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T656f742a3eac158f23077@esvir03nok.nokia.com>;
 Wed, 22 Oct 2003 09:06:20 +0300
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747);
	 Wed, 22 Oct 2003 09:06:21 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] WGLC for URI and Header Parameter Registries
Date: Wed, 22 Oct 2003 09:06:21 +0300
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017972E8@esebe019.ntc.nokia.com>
Thread-Topic: [Sip] WGLC for URI and Header Parameter Registries
Thread-Index: AcOX+cocOLRorn8mTo+ZyXJ8piIcigAaEx4g
To: <dean.willis@softarmor.com>
Cc: <Gonzalo.Camarillo@ericsson.com>, <aki.niemi@nokia.com>, <rohan@cisco.com>,
        <sip@ietf.org>
X-OriginalArrivalTime: 22 Oct 2003 06:06:21.0248 (UTC) FILETIME=[9D760400:01C39862]
Content-Transfer-Encoding: quoted-printable
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: quoted-printable

I agree with that, but what would you call the parameters created by =
3GPP? are they one-off? They are certainly not thrown away after being =
used once.

I'm not suggesting that every parameter needs an RFC. I'm suggesting =
that every parameter needs to be registered.

If the student's project starts to be widely used and adopted, then he =
needs to register his parameter. I don't know when you do and when you =
don't need and RFC. That's a separate issue.

/Hisham

> -----Original Message-----
> From: ext Dean Willis [mailto:dean.willis@softarmor.com]
> Sent: Tuesday, October 21, 2003 8:35 PM
> To: Khartabil Hisham (NMP-MSW/Helsinki)
> Cc: Gonzalo.Camarillo@ericsson.com; Niemi Aki (NMP/Helsinki);
> rohan@cisco.com; sip@ietf.org
> Subject: RE: [Sip] WGLC for URI and Header Parameter Registries
>=20
>=20
> On Tue, 2003-10-21 at 02:07, hisham.khartabil@nokia.com wrote:
> > Dean sai:
> > > We did NOT have consensus that every parameter that might=20
> ever be used
> > > for a one-off application needed to be registered.
> >=20
> > What does "one-off application" mean?
>=20
> "One-off" is a colloquialism for a thing used one time and then
> discarded or obsoleted.
>=20
> An example here might be a college student who is working on an
> application using SIP to invite his friends to play a game=20
> that he just
> wrote as a class project. The invitation carries a new=20
> parameter he made
> up, "Game=3DX78hj9p" that the SIP proxy uses to route players=20
> to the right
> game session.
>=20
> Since he hasn't written the RFC to register the parameter "Game" and
> define exactly what the value "X78hj9p" means, we'd have to=20
> send out the
> protocol police to arrest him for violating the specification. Or even
> worse, perhaps his professor would force him to write the=20
> RFC, and then
> "Game" could ONLY be used as he had previously specified it, and every
> other college student from then on out with have to come up with
> something else to call their new parameter. In short,=20
> something that has
> no reason to be "standardized" would suddenly become an IANA=20
> registered
> reality . . . (this is especially aggravating on an open-registration
> first-come-first-served registery).
>=20
> Or we go with plan B -- since "Game" isn't a registered parameter, he
> can use it however he wants, and if it breaks something (like the
> different use of "Game" in his roommate's class project), that's his
> problem. Or his roomates. But if he tries to reuse "lr", which we DID
> register (and define in an RFC), his professor can slap him around and
> point out the documentation for what he did wrong.
>=20
> --
> Dean
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Wed Oct 22 06:15:40 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02079
	for <sip-archive@odin.ietf.org>; Wed, 22 Oct 2003 06:15:40 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACG1S-0004Gx-02
	for sip-archive@odin.ietf.org; Wed, 22 Oct 2003 06:15:22 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MAFL56016356
	for sip-archive@odin.ietf.org; Wed, 22 Oct 2003 06:15:21 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACG1C-0004CK-CY; Wed, 22 Oct 2003 06:15:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACG11-00049r-Ka
	for sip@optimus.ietf.org; Wed, 22 Oct 2003 06:14:55 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02015
	for <sip@ietf.org>; Wed, 22 Oct 2003 06:14:43 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACG0x-000334-00
	for sip@ietf.org; Wed, 22 Oct 2003 06:14:51 -0400
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACG0w-00032j-00
	for sip@ietf.org; Wed, 22 Oct 2003 06:14:51 -0400
Received: from dynamicsoft.com ([63.113.46.14])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h9MAEQca003636
	for <sip@ietf.org>; Wed, 22 Oct 2003 06:14:26 -0400 (EDT)
Message-ID: <3F96587E.6090707@dynamicsoft.com>
Date: Wed, 22 Oct 2003 06:14: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.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "'sip@ietf.org'" <sip@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Caller preferences update
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've just submitted updates to the caller prefs and callee caps 
specifications. Until they appear in the archives, you can pick them 
up at:


http://www.jdrosen.net/papers/draft-ietf-sip-callerprefs-10.txt
http://www.jdrosen.net/papers/draft-ietf-sip-callee-caps-01.txt

Here are the changes:

* removed msgserver and attendant tags. Replaced them with an "actor" 
tag that can have values of attendant, msg-taker, information and 
principal. We were running into problems with overlapping definitions 
for the various attributes, and this seemed the best way to fix it.

* created a separate media feature tag registry for sip-specific 
parameters, and split the parameters between the two registries

* as a result of the creation of the new registry, the name of the 
feature tags in the sip registry is "sip.methods" and 
"sip.description", for example, with a leading "sip.". Added encoding 
rules which strip out this prefix for known feature tags.

* clarified the distinction between capabilities and characteristics, 
and provided additional guidance on constructing registrations in 
cases where characteristics were non-deterministic

* removed uri-user and uri-domain entirely, and did not add the device 
id tag that was discussed on the list



At this point, there are no open issues or known problems, and I 
believe that (this time, REALLY!) we are done.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
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 exim@www1.ietf.org  Wed Oct 22 10:11:52 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10525
	for <sip-archive@odin.ietf.org>; Wed, 22 Oct 2003 10:11:51 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACJhz-0000v7-Pv
	for sip-archive@odin.ietf.org; Wed, 22 Oct 2003 10:11:32 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MEBVZP003534
	for sip-archive@odin.ietf.org; Wed, 22 Oct 2003 10:11:31 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACJhV-0000pF-Dl; Wed, 22 Oct 2003 10:11:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACJhQ-0000oB-PE
	for sip@optimus.ietf.org; Wed, 22 Oct 2003 10:10:57 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10412
	for <sip@ietf.org>; Wed, 22 Oct 2003 10:10:45 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACJhO-0005im-00
	for sip@ietf.org; Wed, 22 Oct 2003 10:10:54 -0400
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACJhN-0005iW-00
	for sip@ietf.org; Wed, 22 Oct 2003 10:10:54 -0400
Received: from cisco.com (64.102.124.13)
  by sj-iport-5.cisco.com with ESMTP; 22 Oct 2003 07:12:21 -0700
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9MEAJN0008624;
	Wed, 22 Oct 2003 10:10:20 -0400 (EDT)
Received: from cisco.com ([161.44.79.51])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ADJ16595;
	Wed, 22 Oct 2003 10:10:18 -0400 (EDT)
Message-ID: <3F968FCA.1060907@cisco.com>
Date: Wed, 22 Oct 2003 10:10:18 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: sip@ietf.org
Subject: Re: [Sip] GRUU Mechanism I-D
References: <3F94E9A9.5020707@dynamicsoft.com> <3F953BD9.7040505@cisco.com> <3F95F1A2.2060107@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



Jonathan Rosenberg wrote:
> 
>> 1) impact on registration refreshes:
>>
>> Section 4.1 says: "... the Contact URI in the REGISTER request SHOULD 
>> NOT contain the gruu Contact header field parameter."
>>
>> The question is whether a registration refresh should contain the gruu 
>> previously returned, and if it does, whether than changes behavior. 
>> For instance, a refresh that contains the old gruu might indicate a 
>> desire to retain that gruu, while a refresh without it might be 
>> interpretted as a request for a new gruu. The messy case would be 
>> where a registration contains a gruu parameter that isn't a valid gruu 
>> for that registrar.
>>
>> I don't have strong feelings about what the details are here - only 
>> that the behavior should be better defined.
> 
> I think we should keep things simple here. Things get complex if you 
> allow the GRUU for a particular contact URI to change, either at the 
> request of the UA, or because of some decision by the registrar. If you 
> require that, as long as a Contact URI is registered to an AOR, the GRUU 
> for that Contact URI is fixed, I think thats a good thing. In this case, 
> there is no reason for the UA to provide the gruu in the REGISTER request.

My goal is also to keep things simple here. If you said that the contact 
in a register request MUST not contain the gruu parameter, and required 
that the gruu paramter in the response MUST be constant across 
registration refreshes, then the contract would be clear.

If you say the contact in the register request SHOULD not contain a gruu 
parameter you open pandora's box of questions about what the behavior is 
in that case - what if the parameter has a different value than what the 
register believes it should be???

And unless you say the gruu parameter MUST be constant across all 
refreshes of the registration, the UA will have to check for a possible 
change in the value, and be prepared to make compensating actions if it 
does change.

The flip side of this is that it is possible the registrar could crash 
and get amnesia. Normally it might recover its memory because of 
refreshes, because a new registration and a refresh are identical. But 
this *might* result in creation of a different gruu value. Perhaps this 
is a bad scenario, because a decent registrar will have persistent 
storage, but it is at least worth mentioning.

An advantage of having the UA include the gruu in refreshes is that it 
is an easy way to provide an extra consistency check between it and the 
registrar. If the gruu passed in doesn't match what the registrar wants 
to return, then it can return an error. To recover, the UA would then 
have to register without a gruu parameter, and would know that the gruu 
returned is new.

I think you are asking for trouble if you allow a gruu to be in the 
register request and don't report on it when it is wrong.

>> 2) Should register response contain "Supported: gruu"? You don't 
>> mention or show that, but it seems like a reasonable thing.
> 
> Normally, if Supported is in a request, the response would contain a 
> Require header if that extension is needed to process the response. In 
> this case, I don't think it is NEEDED to process the response. That is, 
> if the extension is ignored, the response is still processed correctly.
> 
> I dont see the point in placing Supported into the REGISTER response. 
> The presence of the gruu parameters indicates that the extension is 
> supported.

ok.

>> 3) Section 4.3 says:
>>
>>    When a UA (UA 1) wishes to generate a request to another UA, UA 2,
>>    and UA 1 and UA 2 are involved in an active dialog, and the request
>>    is not associated with the existing dialog, and UA 2 indicated
>>    support for this extension, UA 1 SHOULD send the request to the
>>    remote target URI if UA 2. Examples of such requests are SUBSCRIBE
>>    and REFER. Currently, RFC 3261 describes the notion of dialog
>>    sharing, which would advocate generation of these requests within the
>>    context of the existing dialog. This specification supercedes that
>>    behavior. In cases where UA 1 wishes to send the request, but UA 2
>>    has not indicated support for GRUU, UA 1 SHOULD send the request on
>>    the existing dialog.
>>
>> If gruus were universally supported and dialog sharing had never been 
>> invented then this may have been a good idea. But as things are I 
>> think this just makes a bad situation worse - you still have to 
>> support dialog sharing, and also implement added logic to not use it 
>> under certain circumstances. 
> 
> Right. Such is the pain of transitioning from a mechanism that 
> frequently won't work, but is currently standardized, to one that will 
> work much better, and is now being introduced.
> 
>> My preference is just to omit this paragraph altogether. If a gruu is 
>> present, it provides an option that may be used if desired, but there 
>> is nothing normative about it.
> 
> Well, I would like us to move away from dialog reuse, and its best, I 
> think, if we give guidance to implementors about this, rather than let 
> them continue to use dialog reuse.
> 
>> In the case of REFER there may be added negatives to this approach. A 
>> REFER received in dialog with an INVITE can be interpretted as having 
>> different semantics from a REFER outside of a dialog. This is a useful 
>> distinction that is lost with the proposed change.
> 
> This is a good point. Of course, the REAL problem here is that the REFER 
> request ought to go on the dialog, followed by a separate SUBSCRIBE to 
> the GRUU, in order to track progress of the refer. That is, its the 
> implicit subscriptions which makes this complicated.
> 
> That said, we may need to except REFER from this rule. Bleh.

If we need to exempt REFER, then we have admitted that we can't phase 
out shared dialogs. Then, if we have to continue to support shared 
dialogs, why do we want to tell people not to use them?

Some mistakes, once made, are best lived with. I think this may be one 
of those.

	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 exim@www1.ietf.org  Wed Oct 22 10:30:40 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11905
	for <sip-archive@odin.ietf.org>; Wed, 22 Oct 2003 10:30:40 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACK0D-0005In-Vj
	for sip-archive@odin.ietf.org; Wed, 22 Oct 2003 10:30:21 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MEULeJ020377
	for sip-archive@odin.ietf.org; Wed, 22 Oct 2003 10:30:21 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACJzw-00059k-8l; Wed, 22 Oct 2003 10:30:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACJza-00054j-EW
	for sip@optimus.ietf.org; Wed, 22 Oct 2003 10:29:42 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11771
	for <sip@ietf.org>; Wed, 22 Oct 2003 10:29:30 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACJzW-0005yK-00
	for sip@ietf.org; Wed, 22 Oct 2003 10:29:38 -0400
Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACJzW-0005x2-00
	for sip@ietf.org; Wed, 22 Oct 2003 10:29:38 -0400
Received: from localhost (localhost.localdomain [127.0.0.1])
	by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h9MESvd16199
	for <sip@ietf.org>; Wed, 22 Oct 2003 09:28:57 -0500
From: Robert Sparks <rsparks@dynamicsoft.com>
To: sip@ietf.org
Content-Type: multipart/mixed; boundary="=-r7MtjLbKszS5bZJSul2O"
Message-Id: <1066832936.937.25.camel@RjS.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.4 
Date: Wed, 22 Oct 2003 09:28:56 -0500
Subject: [Sip] [Fwd: I-D ACTION:draft-sparks-sip-noninvite-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>


--=-r7MtjLbKszS5bZJSul2O
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

-----Forwarded Message-----
> From: Internet-Drafts@ietf.org
> Subject: I-D ACTION:draft-sparks-sip-noninvite-01.txt
> Date: Mon, 20 Oct 2003 15:40:19 -0400
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title		: Considerations for the Session Initiation 
> 			  Protocol's non-INVITE Transaction
> 	Author(s)	: R. Sparks
> 	Filename	: draft-sparks-sip-noninvite-01.txt
> 	Pages		: 17
> 	Date		: 2003-10-20
> 	
> This draft explores several issues with the Session Initiation
> Protocol's non-INVITE transaction. It focuses on the use of
> provisional responses and on problems related to transaction
> timeouts. It proposes two alternative improvements to the existing
> situation.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-sparks-sip-noninvite-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-sparks-sip-noninvite-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-sparks-sip-noninvite-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.
> 

--=-r7MtjLbKszS5bZJSul2O
Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org"
Content-Transfer-Encoding: 7bit

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

ENCODING mime
FILE /internet-drafts/draft-sparks-sip-noninvite-01.txt

--=-r7MtjLbKszS5bZJSul2O
Content-Type: Message/External-body; name="draft-sparks-sip-noninvite-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts"
Content-Transfer-Encoding: 7bit


--=-r7MtjLbKszS5bZJSul2O--


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Wed Oct 22 11:42:48 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14877
	for <sip-archive@odin.ietf.org>; Wed, 22 Oct 2003 11:42:48 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACL80-00013r-0F
	for sip-archive@odin.ietf.org; Wed, 22 Oct 2003 11:42:29 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MFgRU6004021
	for sip-archive@odin.ietf.org; Wed, 22 Oct 2003 11:42:27 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACL7Z-0000yZ-Pf; Wed, 22 Oct 2003 11:42:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACL6y-0000ts-2a
	for sip@optimus.ietf.org; Wed, 22 Oct 2003 11:41:24 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14828
	for <sip@ietf.org>; Wed, 22 Oct 2003 11:41:13 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACL6w-0006sE-00
	for sip@ietf.org; Wed, 22 Oct 2003 11:41:23 -0400
Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACL6v-0006rb-00
	for sip@ietf.org; Wed, 22 Oct 2003 11:41:22 -0400
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h9MFeXBf017130
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Wed, 22 Oct 2003 10:40:34 -0500
Received: (from dwillis@localhost)
	by bdsl.greycouncil.com (8.12.8/8.12.8/Submit) id h9MFeXlX017128;
	Wed, 22 Oct 2003 10:40:33 -0500
X-Authentication-Warning: bdsl.greycouncil.com: dwillis set sender to dean.willis@softarmor.com using -f
Subject: RE: [Sip] WGLC for URI and Header Parameter Registries
From: Dean Willis <dean.willis@softarmor.com>
To: hisham.khartabil@nokia.com
Cc: Gonzalo.Camarillo@ericsson.com, aki.niemi@nokia.com, rohan@cisco.com,
        sip@ietf.org
In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017972E8@esebe019.ntc.nokia.com>
References: 
	 <2038BCC78B1AD641891A0D1AE133DBB7017972E8@esebe019.ntc.nokia.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1066837233.9925.89.camel@bdsl.greycouncil.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 
Date: Wed, 22 Oct 2003 10:40:33 -0500
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 Wed, 2003-10-22 at 01:06, hisham.khartabil@nokia.com wrote:
> I agree with that, but what would you call the parameters created by
> 3GPP? are they one-off? They are certainly not thrown away after being
> used once.
> 

The 3GPP p-headers are documented by informational RFCs, as required by
RFC 3427. I'm not up to date on any parameters they've proposed, but I
would expect those to be properly documented, if there are any.

> I'm not suggesting that every parameter needs an RFC. I'm suggesting
> that every parameter needs to be registered.

You mean "every WIDELY USED parameter", right? That would make it
consistent with what you say next . . .

> If the student's project starts to be widely used and adopted, then he
> needs to register his parameter. I don't know when you do and when you
> don't need and RFC. That's a separate issue.

Well, under the policy we have proposed, if the parameter starts to be
widely used, then it needs an RFC.

One alternative that might make you happier is a policy of
"Specification Required", where that specification can be any publicly
acessible body of work recognized by the RFC Editor, including ITU and
3GPP specs.

--
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 exim@www1.ietf.org  Wed Oct 22 12:46:48 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17215
	for <sip-archive@odin.ietf.org>; Wed, 22 Oct 2003 12:46:48 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACM7x-0001qu-Cp
	for sip-archive@odin.ietf.org; Wed, 22 Oct 2003 12:46:30 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MGkTlb007114
	for sip-archive@odin.ietf.org; Wed, 22 Oct 2003 12:46:29 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACM7W-0001nW-4C; Wed, 22 Oct 2003 12:46:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACM6y-0001kF-Gl
	for sip@optimus.ietf.org; Wed, 22 Oct 2003 12:45:29 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17165
	for <sip@ietf.org>; Wed, 22 Oct 2003 12:45:16 -0400 (EDT)
From: hisham.khartabil@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACM6w-0007dN-00
	for sip@ietf.org; Wed, 22 Oct 2003 12:45:26 -0400
Received: from mgw-x4.nokia.com ([131.228.20.27])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACM6v-0007dK-00
	for sip@ietf.org; Wed, 22 Oct 2003 12:45:26 -0400
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9MGjOq26411
	for <sip@ietf.org>; Wed, 22 Oct 2003 19:45:24 +0300 (EET DST)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T6571bd3fc8ac158f24b5d@esvir04nok.ntc.nokia.com>;
 Wed, 22 Oct 2003 19:45:24 +0300
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Wed, 22 Oct 2003 19:45:24 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] WGLC for URI and Header Parameter Registries
Date: Wed, 22 Oct 2003 19:45:23 +0300
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017972FB@esebe019.ntc.nokia.com>
Thread-Topic: [Sip] WGLC for URI and Header Parameter Registries
Thread-Index: AcOYsvYLne01lvFzQc+yLfr6znAeHAACGdFw
To: <dean.willis@softarmor.com>
Cc: <Gonzalo.Camarillo@ericsson.com>, <aki.niemi@nokia.com>, <rohan@cisco.com>,
        <sip@ietf.org>
X-OriginalArrivalTime: 22 Oct 2003 16:45:24.0133 (UTC) FILETIME=[E399F550:01C398BB]
Content-Transfer-Encoding: quoted-printable
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: quoted-printable



> -----Original Message-----
> From: ext Dean Willis [mailto:dean.willis@softarmor.com]
> Sent: Wednesday, October 22, 2003 6:41 PM
> To: Khartabil Hisham (NMP-MSW/Helsinki)
> Cc: Gonzalo.Camarillo@ericsson.com; Niemi Aki (NMP/Helsinki);
> rohan@cisco.com; sip@ietf.org
> Subject: RE: [Sip] WGLC for URI and Header Parameter Registries
>=20
>=20
> On Wed, 2003-10-22 at 01:06, hisham.khartabil@nokia.com wrote:
> > I agree with that, but what would you call the parameters created by
> > 3GPP? are they one-off? They are certainly not thrown away=20
> after being
> > used once.
> >=20
>=20
> The 3GPP p-headers are documented by informational RFCs, as=20
> required by
> RFC 3427. I'm not up to date on any parameters they've proposed, but I
> would expect those to be properly documented, if there are any.

I am referring to parameters that will be proposed in the future :) 3GPP =
delegates have the impression that if the parameter would be defined =
just for 3GPP use, then it does not need to be registered. I think it =
does.

>=20
> > I'm not suggesting that every parameter needs an RFC. I'm suggesting
> > that every parameter needs to be registered.
>=20
> You mean "every WIDELY USED parameter", right? That would make it
> consistent with what you say next . . .

Yes.

>=20
> > If the student's project starts to be widely used and=20
> adopted, then he
> > needs to register his parameter. I don't know when you do=20
> and when you
> > don't need and RFC. That's a separate issue.
>=20
> Well, under the policy we have proposed, if the parameter starts to be
> widely used, then it needs an RFC.
>=20
> One alternative that might make you happier is a policy of
> "Specification Required", where that specification can be any publicly
> acessible body of work recognized by the RFC Editor, including ITU and
> 3GPP specs.

This sounds great, and does make me happier actually :)

/Hisham

>=20
> --
> Dean
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Wed Oct 22 18:59:33 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03682
	for <sip-archive@odin.ietf.org>; Wed, 22 Oct 2003 18:59:33 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACRwh-00076g-UQ
	for sip-archive@odin.ietf.org; Wed, 22 Oct 2003 18:59:15 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MMxFVg027314
	for sip-archive@odin.ietf.org; Wed, 22 Oct 2003 18:59:15 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACRwT-000734-GN; Wed, 22 Oct 2003 18:59:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACRwO-00072K-15
	for sip@optimus.ietf.org; Wed, 22 Oct 2003 18:58:56 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03647;
	Wed, 22 Oct 2003 18:58:42 -0400 (EDT)
Message-Id: <200310222258.SAA03647@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, 22 Oct 2003 18:58:42 -0400
Subject: [Sip] I-D ACTION:draft-rosenberg-sip-gruu-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		: Obtaining and Using Globally Routable User Agent (UA)
			  URIs (GRUU) in the Session Initiation Protocol (SIP)
	Author(s)	: J. Rosenberg
	Filename	: draft-rosenberg-sip-gruu-00.txt
	Pages		: 14
	Date		: 2003-10-22
	
Several applications of the Session Initiation Protocol (SIP) require
a user agent (UA) to construct and distribute a URI which can be used
by anyone on the Internet to route a call to that specific UA
instance. A URI which routes to a specific UA instance is called a
Globally Routable UA URI (GRUU). This document describes an extension
to SIP for obtaining a GRUU from a server, and for communicating a
GRUU to a peer within a dialog.

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

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

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-rosenberg-sip-gruu-00.txt

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

Content-Type: text/plain
Content-ID:	<2003-10-22183203.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 exim@www1.ietf.org  Wed Oct 22 22:32:40 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14701
	for <sip-archive@odin.ietf.org>; Wed, 22 Oct 2003 22:32:40 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACVGv-0006gT-Oz
	for sip-archive@odin.ietf.org; Wed, 22 Oct 2003 22:32:21 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N2WL4J025687
	for sip-archive@odin.ietf.org; Wed, 22 Oct 2003 22:32:21 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACVGc-0006cq-8L; Wed, 22 Oct 2003 22:32:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACVGF-0006ZG-9g
	for sip@optimus.ietf.org; Wed, 22 Oct 2003 22:31:39 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14639
	for <sip@ietf.org>; Wed, 22 Oct 2003 22:31:27 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACVGB-0007HF-00
	for sip@ietf.org; Wed, 22 Oct 2003 22:31:35 -0400
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACVGB-0007Gn-00
	for sip@ietf.org; Wed, 22 Oct 2003 22:31:35 -0400
Received: from dynamicsoft.com ([63.113.46.9])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h9N2Unca004305;
	Wed, 22 Oct 2003 22:30:51 -0400 (EDT)
Message-ID: <3F973D54.3070506@dynamicsoft.com>
Date: Wed, 22 Oct 2003 22:30:44 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@cisco.com>
CC: sip@ietf.org
Subject: Re: [Sip] GRUU Mechanism I-D
References: <3F94E9A9.5020707@dynamicsoft.com> <3F953BD9.7040505@cisco.com> <3F95F1A2.2060107@dynamicsoft.com> <3F968FCA.1060907@cisco.com>
In-Reply-To: <3F968FCA.1060907@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.

Paul Kyzivat wrote:


>> I think we should keep things simple here. Things get complex if you 
>> allow the GRUU for a particular contact URI to change, either at the 
>> request of the UA, or because of some decision by the registrar. If 
>> you require that, as long as a Contact URI is registered to an AOR, 
>> the GRUU for that Contact URI is fixed, I think thats a good thing. In 
>> this case, there is no reason for the UA to provide the gruu in the 
>> REGISTER request.
> 
> 
> My goal is also to keep things simple here. If you said that the contact 
> in a register request MUST not contain the gruu parameter, and required 
> that the gruu paramter in the response MUST be constant across 
> registration refreshes, then the contract would be clear.
> 
> If you say the contact in the register request SHOULD not contain a gruu 
> parameter you open pandora's box of questions about what the behavior is 
> in that case - what if the parameter has a different value than what the 
> register believes it should be???

If its present in the request, it should be ignored. It has no 
meaning. Thus, the wording we need is that the registrar MUST ignore 
any gruu parameters in the register request.

> 
> And unless you say the gruu parameter MUST be constant across all 
> refreshes of the registration, the UA will have to check for a possible 
> change in the value, and be prepared to make compensating actions if it 
> does change.

Right, we need to specify that the gruu must be constant across refreshes.


> 
> The flip side of this is that it is possible the registrar could crash 
> and get amnesia. Normally it might recover its memory because of 
> refreshes, because a new registration and a refresh are identical. But 
> this *might* result in creation of a different gruu value. Perhaps this 
> is a bad scenario, because a decent registrar will have persistent 
> storage, but it is at least worth mentioning.

I thought about that. I believe a registrar can meet the requirement 
without even having persistent storage of the mappings. Thus, I do not 
believe it is an undo burden to impose the requiremetn.

The problem is, if the gruu changes, the UA is going to potentially 
need to do a lot of work to update it across all active dialogs. There 
is also a period of time after which the old gruu is invalid, 
according to the server, but the UA has not discovered this and 
informed their peers in existing dialogs. During this window, any 
mid-dialog requests sent by the peer will fail, and that is bad.




> 
> An advantage of having the UA include the gruu in refreshes is that it 
> is an easy way to provide an extra consistency check between it and the 
> registrar. If the gruu passed in doesn't match what the registrar wants 
> to return, then it can return an error. To recover, the UA would then 
> have to register without a gruu parameter, and would know that the gruu 
> returned is new.

If the UA wants to check the gruu against what the server thinks, it 
can just send a REGISTER and look at the gruu in the response.

> 
> I think you are asking for trouble if you allow a gruu to be in the 
> register request and don't report on it when it is wrong.

I think we should say that it MUST be ignored by the registrar, and 
SHOULD NOT be inserted by the UA.


>>
>> This is a good point. Of course, the REAL problem here is that the 
>> REFER request ought to go on the dialog, followed by a separate 
>> SUBSCRIBE to the GRUU, in order to track progress of the refer. That 
>> is, its the implicit subscriptions which makes this complicated.
>>
>> That said, we may need to except REFER from this rule. Bleh.
> 
> 
> If we need to exempt REFER, then we have admitted that we can't phase 
> out shared dialogs. Then, if we have to continue to support shared 
> dialogs, why do we want to tell people not to use them?

If there is no way to fix this for REFER, I would have to agree with 
you. However, if there is a possibility to update REFER to take 
advantage of gruu, and thus avoid dialog reuse, then it makes sense. 
AFAICT, the fix to REFER is not hard at all. The recipient of the 
REFER, who creates the NOTIFY, would simply send it to the gruu of the 
referor, and use a different dialog ID. There is still an implicit 
subscription, but the NOTIFY creates a new, separate dialog.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
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 exim@www1.ietf.org  Thu Oct 23 05:51:37 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10637
	for <sip-archive@odin.ietf.org>; Thu, 23 Oct 2003 05:51:37 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACc7i-0007A0-4M
	for sip-archive@odin.ietf.org; Thu, 23 Oct 2003 05:51:18 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N9pIpP027466
	for sip-archive@odin.ietf.org; Thu, 23 Oct 2003 05:51:18 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACc7S-00074Z-8V; Thu, 23 Oct 2003 05:51:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACc6q-0006wG-W5
	for sip@optimus.ietf.org; Thu, 23 Oct 2003 05:50:25 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10599
	for <sip@ietf.org>; Thu, 23 Oct 2003 05:50:13 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACc6n-0004Tr-00
	for sip@ietf.org; Thu, 23 Oct 2003 05:50:21 -0400
Received: from david.siemens.de ([192.35.17.14])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACc6m-0004To-00
	for sip@ietf.org; Thu, 23 Oct 2003 05:50:20 -0400
Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14])
	by david.siemens.de (8.11.7/8.11.7) with ESMTP id h9N9oKI08017
	for <sip@ietf.org>; Thu, 23 Oct 2003 11:50:20 +0200 (MEST)
Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85])
	by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id h9N9oJ217247
	for <sip@ietf.org>; Thu, 23 Oct 2003 11:50:19 +0200 (MEST)
Received: from ICN.Siemens.De (pc83001539.mchh.siemens.de [139.21.7.34] (may be forged))
	by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id LAA24586;
	Thu, 23 Oct 2003 11:50:19 +0200 (MET DST)
Message-ID: <3F97A459.CC16A6D@ICN.Siemens.De>
Date: Thu, 23 Oct 2003 11:50:18 +0200
From: Joachim =?iso-8859-1?Q?Kro=DF?= <Joachim.Kross@ICN.Siemens.De>
X-Mailer: Mozilla 4.78 [de]C-CCK-MCD DT  (Windows NT 5.0; U)
X-Accept-Language: de
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] Section 18.1.1 (on MTU and transport) of RFC 3261 and SigComp
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

Dear all,

I asked this question on the sip-implementors list some time ago, but it
seems no one is implementing this yet. So please permit me to ask this
question here where SIP itself is being developed.

I am wondering how the selection of the transport protocol described in
section 18.1.1 of RFC 3261 (i.e. for requests greater path MTU - 200, or
greater 1300 if the path MTU is unknown, TCP MUST be used) is done in
the presence of SigComp. Is the decision whether TCP shall be used made
based on the length of the uncompressed or the compressed request? Is
there any normative reference for this (I haven't found one)?

Thank you!

Regards,
Joachim

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Thu Oct 23 06:40:34 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12326
	for <sip-archive@odin.ietf.org>; Thu, 23 Oct 2003 06:40:34 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACct5-0007vm-Cj
	for sip-archive@odin.ietf.org; Thu, 23 Oct 2003 06:40:15 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NAeEn5030475
	for sip-archive@odin.ietf.org; Thu, 23 Oct 2003 06:40:14 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACcsw-0007uA-9f; Thu, 23 Oct 2003 06:40:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACcsb-0007r3-6S
	for sip@optimus.ietf.org; Thu, 23 Oct 2003 06:39:45 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12298
	for <sip@ietf.org>; Thu, 23 Oct 2003 06:39:33 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACcsW-00058A-00
	for sip@ietf.org; Thu, 23 Oct 2003 06:39:40 -0400
Received: from [193.122.18.249] (helo=emily.fle.fujitsu.com)
	by ietf-mx with smtp (Exim 4.12)
	id 1ACcsW-000583-00
	for sip@ietf.org; Thu, 23 Oct 2003 06:39:40 -0400
Received: from 10.142.50.249 by emily.fle.fujitsu.com (InterScan E-Mail VirusWall NT); Thu, 23 Oct 2003 11:36:40 +0100
Received: by fle2.fle.fujitsu.com with Internet Mail Service (5.5.2657.72)
	id <V35KJTZ1>; Thu, 23 Oct 2003 11:38:14 +0100
Message-ID: <E9978DD405A2D611913500047583E37A4D1A99@fle2.fle.fujitsu.com>
From: Xin Chen <x.chen@fle.fujitsu.com>
To: "'sip@ietf.org'" <sip@ietf.org>
Date: Thu, 23 Oct 2003 11:38:14 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: multipart/mixed;
	boundary="----=_NextPartTM-000-d692b89c-42e8-4895-bd28-05d6b34cf0b5"
Subject: [Sip] Question on rfc3310 Hypertext Transfer Protocol (HTTP) Digest Aut
 hentication Using Authentication and Key Agreement (AKA)
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.

------=_NextPartTM-000-d692b89c-42e8-4895-bd28-05d6b34cf0b5
Content-Type: text/plain

Hi,

My question is that if REGISTER procedure is used to authenticate the user
agent, then it can only authenticate the device which initiate the REGISTER.


What happen if the REGISTER contains multiple contact addresses which
possibly represent multiple devices, does that mean all the other devices
are authenticated also?

If forking happens, how to provide confidentially and integration to the SIP
messages towards the other contact addresses?

I am not sure whether these questions are within the scope of the RFC or
not, but your comment and thoughts are appreciated. 

Regards
 
Xin Chen
Mobile Network Division
Fujitsu Laboratories Europe
Tel: +44(0)2086064453
Mobile: +44(0)7775741020


-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] 
Sent: 21 October 2003 09:09
To: sip@ietf.org
Subject: [Sip] GRUU Mechanism I-D


Folks,

I've submitted a new I-D that proposes a specific mechanism for GRUUs 
that meets the requiremetns draft under discussion in sipping. Based 
on our conclusion in the list discussion, the GRUU is placed into the 
Contact header field, and therefore does not require both caller and 
callee to support it.

Until the I-D appears in the archives, you can pick up a copy at:
http://www.jdrosen.net/papers/draft-rosenberg-sip-gruu-00.txt

There are still some open issues. The most notable one, I think, is 
how a UA knows about whether it can construct a GRUU locally, or 
whether it needs to obtain one from its provider. The draft recommends 
that a UA never try to use a locally constructed one. This is under 
the premise that it will never have a good way to know whether it is 
globally reachable. The drawback to this, of course, is that we will 
never see direct UA to UA signaling anymore.

Comments and questions welcome.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
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

------=_NextPartTM-000-d692b89c-42e8-4895-bd28-05d6b34cf0b5
Content-Type: text/plain;
	name="InterScan_Disclaimer.txt"
Content-Disposition: attachment;
	filename="InterScan_Disclaimer.txt"
Content-Transfer-Encoding: 7bit

This e-mail has been scanned by Trend InterScan Software.

This e-mail (and its attachment(s) if any) is intended for the named 
addressee(s) only. It may
contain information which is privileged and confidential within the 
meaning of the applicable law.
Unauthorised use, copying or disclosure is strictly prohibited and may 
be unlawful.

If you are not the intended recipient please delete this email and 
contact the sender via email return.

Fujitsu Laboratories of Europe Ltd (FLE) does not accept responsibility 
for changes made to this email after
it was sent. The views expressed in this email may not necessarily be 
the views held by FLE.

Unless expressly stated otherwise, this email does not form part of a 
legally binding contract
or agreement between the recipient and Fujitsu Laboratories of Europe Ltd (FLE).

------=_NextPartTM-000-d692b89c-42e8-4895-bd28-05d6b34cf0b5--

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Thu Oct 23 07:14:36 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13316
	for <sip-archive@odin.ietf.org>; Thu, 23 Oct 2003 07:14:36 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACdPz-0006hL-NL
	for sip-archive@odin.ietf.org; Thu, 23 Oct 2003 07:14:16 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NBEF08025689
	for sip-archive@odin.ietf.org; Thu, 23 Oct 2003 07:14:15 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACdPn-0006eY-17; Thu, 23 Oct 2003 07:14:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACdP6-0006am-T6
	for sip@optimus.ietf.org; Thu, 23 Oct 2003 07:13:21 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13281
	for <sip@ietf.org>; Thu, 23 Oct 2003 07:13:10 -0400 (EDT)
From: hisham.khartabil@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACdP6-0005Wt-00
	for sip@ietf.org; Thu, 23 Oct 2003 07:13:20 -0400
Received: from mgw-x1.nokia.com ([131.228.20.21])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACdP5-0005Wq-00
	for sip@ietf.org; Thu, 23 Oct 2003 07:13:19 -0400
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9NBDEI01085
	for <sip@ietf.org>; Thu, 23 Oct 2003 14:13:14 +0300 (EET DST)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T6575b3785dac158f250bc@esvir05nok.ntc.nokia.com>;
 Thu, 23 Oct 2003 14:13:12 +0300
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747);
	 Thu, 23 Oct 2003 14:13:12 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Section 18.1.1 (on MTU and transport) of RFC 3261 and SigComp
Date: Thu, 23 Oct 2003 14:13:12 +0300
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797300@esebe019.ntc.nokia.com>
Thread-Topic: [Sip] Section 18.1.1 (on MTU and transport) of RFC 3261 and SigComp
Thread-Index: AcOZTSx8AKr1mQ99Rb+wjOXazfNCTgACHT3g
To: <Joachim.Kross@ICN.Siemens.De>, <sip@ietf.org>
X-OriginalArrivalTime: 23 Oct 2003 11:13:12.0895 (UTC) FILETIME=[A61224F0:01C39956]
Content-Transfer-Encoding: quoted-printable
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: quoted-printable

That's a really good question.

It makes more sense to measure the request after compressing it, since =
doing so before compression gives you false indication. But if after =
compression you realise that the message is actually greater than path =
MTU - 200, or greater 1300 if the path MTU is unknown (can certainly =
happen with the first compressed message), then you need to go back and =
change all the headers that need changing and thereafter compress again.

Regards,
Hisham

> -----Original Message-----
> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of ext
> Joachim Kro=DF
> Sent: Thursday, October 23, 2003 12:50 PM
> To: sip@ietf.org
> Subject: [Sip] Section 18.1.1 (on MTU and transport) of RFC 3261 and
> SigComp
>=20
>=20
> Dear all,
>=20
> I asked this question on the sip-implementors list some time=20
> ago, but it
> seems no one is implementing this yet. So please permit me to ask this
> question here where SIP itself is being developed.
>=20
> I am wondering how the selection of the transport protocol=20
> described in
> section 18.1.1 of RFC 3261 (i.e. for requests greater path=20
> MTU - 200, or
> greater 1300 if the path MTU is unknown, TCP MUST be used) is done in
> the presence of SigComp. Is the decision whether TCP shall be=20
> used made
> based on the length of the uncompressed or the compressed request? Is
> there any normative reference for this (I haven't found one)?
>=20
> Thank you!
>=20
> Regards,
> Joachim
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Thu Oct 23 08:37:40 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16021
	for <sip-archive@odin.ietf.org>; Thu, 23 Oct 2003 08:37:40 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACeiM-00071b-4i
	for sip-archive@odin.ietf.org; Thu, 23 Oct 2003 08:37:18 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NCbH3i026998
	for sip-archive@odin.ietf.org; Thu, 23 Oct 2003 08:37:17 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACei6-0006xo-HA; Thu, 23 Oct 2003 08:37:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACehd-0006uD-Vn
	for sip@optimus.ietf.org; Thu, 23 Oct 2003 08:36:33 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15971
	for <sip@ietf.org>; Thu, 23 Oct 2003 08:36:24 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACehc-0006ao-00
	for sip@ietf.org; Thu, 23 Oct 2003 08:36:32 -0400
Received: from h-135-207-24-16.research.att.com ([135.207.24.16] helo=linux.research.att.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACehc-0006ab-00
	for sip@ietf.org; Thu, 23 Oct 2003 08:36:32 -0400
Received: from unixmail.research.att.com (unixmail.research.att.com [135.207.26.71])
	by linux.research.att.com (8.12.8/8.12.8) with ESMTP id h9NChaKO017971
	for <sip@ietf.org>; Thu, 23 Oct 2003 08:43:36 -0400
Received: from fish.research.att.com (fish.research.att.com [135.207.27.137])
	by unixmail.research.att.com (8.12.8+Sun/8.8.7) with ESMTP id h9NCXpZn005879;
	Thu, 23 Oct 2003 08:33:51 -0400 (EDT)
From: William Marshall <wtm@research.att.com>
Received: (from wtm@localhost)
	by fish.research.att.com (SGI-8.9.3/8.8.5) id IAA53399;
	Thu, 23 Oct 2003 08:35:43 -0400 (EDT)
Date: Thu, 23 Oct 2003 08:35:43 -0400 (EDT)
Message-Id: <200310231235.IAA53399@fish.research.att.com>
To: sip@ietf.org
Subject: Re: [Sip] WGLC for URI and Header Parameter Registries
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>

Two comments regarding draft-ietf-sip-parameter-registry-00:

(1) In the IANA registry for header parameters, I do not think it
should be necessary to include every parameter that is defined in the same
document that defines the header.  A single reference to the header
document should be sufficient (which is already done in another IANA
registry).  It is really only the extensions that we need to be
concerned with, e.g. those defined in the original document as 
"token EQUAL value".
I really do not think it is a burden on someone defining a new
parameter to check the document referenced in the header registry
for all initial parameters, and to not conflict with those.
This could even be made a little easier by including two document
references for every parameter extension - first to the base spec 
that defines the header, and second to the spec that defines the
new parameter.

If the above comment is accepted, then the initial list becomes
much shorter, including (I believe) only the Via parameters comp
and rport (which should reference RFC 3581).

If the above comment is not accepted, then the initial list is much
too short.  There are numerous other parameters defined in current
RFCs.  For instance, in 3261, the Authorization header includes 
parameters "username", "uri", "qop", "cnonce", "nc", and "response",
in addition to the "auth-param-name = token" extension.  Likewise
the "Proxy-Authenticate" header has a mechanism defined for 
extensions, so needs its current parameter names included in the
registry.

(2) There are other "parameters" that are defined for headers that
are not of the simple form "token EQUAL value", but rather just as
"token".  These should also be included in the registry.   Section 
4.1 of the draft should includes examples of both of these cases.

One example is the "Privacy" header defined in RFC 3323, which includes 
"token" as one of the options for "priv-value"; any document that 
defines one of these new tokens should have its value registered too.  

If the decision on point (1) above is that all existing parameters
need to be included in the registry, then "header", "session", "user",
"none", and "critical" also need to be added to the list.  Also,
in RFC3261 are headers such as "Priority" that have extensions defined
like this.

Bill Marshall
wtm@research.att.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 exim@www1.ietf.org  Thu Oct 23 10:04:29 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22182
	for <sip-archive@odin.ietf.org>; Thu, 23 Oct 2003 10:04:29 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACg4Q-0007o3-3c
	for sip-archive@odin.ietf.org; Thu, 23 Oct 2003 10:04:10 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NE4AeJ029949
	for sip-archive@odin.ietf.org; Thu, 23 Oct 2003 10:04:10 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACg4H-0007jm-Su; Thu, 23 Oct 2003 10:04:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACg3X-0007an-Qd
	for sip@optimus.ietf.org; Thu, 23 Oct 2003 10:03:15 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22056
	for <sip@ietf.org>; Thu, 23 Oct 2003 10:03:04 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACg3V-0000T2-00
	for sip@ietf.org; Thu, 23 Oct 2003 10:03:13 -0400
Received: from smtp1.aruba.it ([62.149.128.200])
	by ietf-mx with smtp (Exim 4.12)
	id 1ACg3V-0000Sj-00
	for sip@ietf.org; Thu, 23 Oct 2003 10:03:13 -0400
Received: (qmail 29208 invoked from network); 23 Oct 2003 13:59:23 -0000
Received: from unknown (HELO braies.giandrea.com) (217.57.90.126)
  by smtp1.aruba.it with SMTP; 23 Oct 2003 13:59:23 -0000
Message-Id: <6.0.0.22.2.20031023160210.01c34728@pop3.giandrea.com>
X-Sender: andrea/giandrea.com@pop3.giandrea.com
X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22
Date: Thu, 23 Oct 2003 16:02:15 +0200
To: sip@ietf.org
From: giAndrea <andrea@giandrea.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Rating: smtp1.aruba.it 1.6.2 0/1000/N
Subject: [Sip] Building Application for Windows
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 would like to build a simple application to send IM with Sip using C o 
C++ Language under Windows OS. I would like to use this application to 
trace SIP messagge flow. Where can I found  C library?

Thanks. Andrea


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Thu Oct 23 11:17:28 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28528
	for <sip-archive@odin.ietf.org>; Thu, 23 Oct 2003 11:17:28 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AChD2-0004bi-58
	for sip-archive@odin.ietf.org; Thu, 23 Oct 2003 11:17:08 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NFH8vo017704
	for sip-archive@odin.ietf.org; Thu, 23 Oct 2003 11:17:08 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AChCw-0004aN-Ce; Thu, 23 Oct 2003 11:17:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AChCk-0004ZE-ET
	for sip@optimus.ietf.org; Thu, 23 Oct 2003 11:16:50 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28455
	for <sip@ietf.org>; Thu, 23 Oct 2003 11:16:40 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AChCj-00028x-00
	for sip@ietf.org; Thu, 23 Oct 2003 11:16:49 -0400
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AChCj-00027w-00
	for sip@ietf.org; Thu, 23 Oct 2003 11:16:49 -0400
Received: from cisco.com (64.102.124.12)
  by sj-iport-5.cisco.com with ESMTP; 23 Oct 2003 08:18:34 -0700
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9NFGFFH022192;
	Thu, 23 Oct 2003 11:16:15 -0400 (EDT)
Received: from cisco.com ([161.44.79.51])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ADK16661;
	Thu, 23 Oct 2003 11:16:13 -0400 (EDT)
Message-ID: <3F97F0BD.6000304@cisco.com>
Date: Thu, 23 Oct 2003 11:16:13 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: sip@ietf.org
Subject: Re: [Sip] GRUU Mechanism I-D
References: <3F94E9A9.5020707@dynamicsoft.com> <3F953BD9.7040505@cisco.com> <3F95F1A2.2060107@dynamicsoft.com> <3F968FCA.1060907@cisco.com> <3F973D54.3070506@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



Jonathan Rosenberg wrote:
> 
> If its present in the request, it should be ignored. It has no meaning. 
> Thus, the wording we need is that the registrar MUST ignore any gruu 
> parameters in the register request.
...
> Right, we need to specify that the gruu must be constant across refreshes.

OK

> The problem is, if the gruu changes, the UA is going to potentially need 
> to do a lot of work to update it across all active dialogs. There is 
> also a period of time after which the old gruu is invalid, according to 
> the server, but the UA has not discovered this and informed their peers 
> in existing dialogs. During this window, any mid-dialog requests sent by 
> the peer will fail, and that is bad.

Yes. These are all good reasons to mandate that the gruu can't change 
across refreshes.

I presume this requirement only applies across refreshes, rather than a 
requirment that the same contact address, registered with the same AOR, 
must always yield the same gruu???

>>> That said, we may need to except REFER from this rule. Bleh.
>>
>> If we need to exempt REFER, then we have admitted that we can't phase 
>> out shared dialogs. Then, if we have to continue to support shared 
>> dialogs, why do we want to tell people not to use them?
> 
> If there is no way to fix this for REFER, I would have to agree with 
> you. However, if there is a possibility to update REFER to take 
> advantage of gruu, and thus avoid dialog reuse, then it makes sense. 
> AFAICT, the fix to REFER is not hard at all. The recipient of the REFER, 
> who creates the NOTIFY, would simply send it to the gruu of the referor, 
> and use a different dialog ID. There is still an implicit subscription, 
> but the NOTIFY creates a new, separate dialog.

There is an additional semantic when a REFER is sent within an existing 
dialog - it has an implicit association with the other things sharing 
that dialog. When a refer of an invite arrives in a dialog that already 
has an invite that association can be significant. The UAS may have 
several calls that all share the same contact address, but the dialog 
distinguishes one of them.

That need for that could be eliminated if every call used a unique 
contact address, perhaps by using a GRUU with a unique grid.

I think discussion is required over whether we want to go down that 
path, with the goal of replacing every possible use for shared dialogs. 
The GRUU stuff can proceed without first making that decision.

	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 exim@www1.ietf.org  Thu Oct 23 12:14:46 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03700
	for <sip-archive@odin.ietf.org>; Thu, 23 Oct 2003 12:14:46 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACi6V-0007gm-49
	for sip-archive@odin.ietf.org; Thu, 23 Oct 2003 12:14:27 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NGERYk029498
	for sip-archive@odin.ietf.org; Thu, 23 Oct 2003 12:14:27 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACi65-0007Ze-48; Thu, 23 Oct 2003 12:14:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACi5x-0007Up-15
	for sip@optimus.ietf.org; Thu, 23 Oct 2003 12:13:53 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03576;
	Thu, 23 Oct 2003 12:13:42 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACi5v-0003mK-00; Thu, 23 Oct 2003 12:13:51 -0400
Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACi5u-0003lG-00; Thu, 23 Oct 2003 12:13:51 -0400
Received: from localhost.cisco.com (localhost.localdomain [127.0.0.1])
	by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h9NGDBd09030;
	Thu, 23 Oct 2003 11:13:11 -0500
From: Robert Sparks <rsparks@dynamicsoft.com>
To: simple@ietf.org, sip@ietf.org, sip-implementors@cs.columbia.edu
Content-Type: text/plain
Message-Id: <1066925585.11527.12.camel@RjS.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.4 
Date: Thu, 23 Oct 2003 11:13:05 -0500
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Registration is now open for SIPIt 14
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

SIPIt 14 will take place February 8-13 in Cannes, France.

The event will be hosted by by ETSI. More details and
registration are available at
http://www.etsi.org/plugtests/SIPIT14.htm

>From Philippe Cousin at ETSI Plugtests:

ETSI is happy to host the SIPit event again and to provide
its free support to the SIP community. Sponsors are welcome 
either to support the global event or for the social event.
Should your company be interested to helping sponser this
nice event, please contact philippe.cousin@etsi.org

RjS


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Thu Oct 23 12:18:05 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04530
	for <sip-archive@odin.ietf.org>; Thu, 23 Oct 2003 12:18:04 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACi9g-0000Eu-1y
	for sip-archive@odin.ietf.org; Thu, 23 Oct 2003 12:17:44 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NGHhYA000860
	for sip-archive@odin.ietf.org; Thu, 23 Oct 2003 12:17:43 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACi90-0008Ol-3n; Thu, 23 Oct 2003 12:17:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACi80-00087a-SP
	for sip@optimus.ietf.org; Thu, 23 Oct 2003 12:16:00 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03789
	for <sip@ietf.org>; Thu, 23 Oct 2003 12:15:49 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACi7z-0003rA-00
	for sip@ietf.org; Thu, 23 Oct 2003 12:15:59 -0400
Received: from [202.144.91.188] (helo=ipgen-india.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACi7y-0003qN-00
	for sip@ietf.org; Thu, 23 Oct 2003 12:15:59 -0400
Received: from pop3.sify.net [202.144.76.11] by ipgen-india.com []
	with DomainPOP (MDaemon.PRO.v5.0.7.R)
	for <sip@ietf.org>; Thu, 23 Oct 2003 21:50:36 +0530
Delivered-To: ipgen-india.com-sunku@ipgen-india.com
X-Filter: xFilter/SifyMail - No Filter defined (http://mail.sify.com)
Received: (sifymail 3969 invoked by uid 7010); Thu Oct 23 21:38:59 2003
Received: (sifymail 3967 invoked by uid 7010); 23 Oct 2003 21:38:59 +0530
Received: from 202.144.76.19 (HELO WMRP01.maa.sify.net) (202.144.76.19)
  by 202.144.76.11 with SMTP; 23 Oct 2003 21:38:59 +0530
Received: (sifymail 5854 invoked by uid 7005); 23 Oct 2003 21:38:59 +0530
Received: from 202.144.76.19 (HELO WMRP01.maa.sify.net) (202.144.76.19)
  by 202.144.76.19 with SMTP; 23 Oct 2003 21:38:59 +0530
Received: (sifymail 5849 invoked by uid 7005); 23 Oct 2003 21:38:58 +0530
Received: from 128.59.16.73 (HELO rogue.cs.columbia.edu) (128.59.16.73)
  by 202.144.76.19 with SMTP; 23 Oct 2003 21:38:58 +0530
Received: from cs.columbia.edu ([128.59.16.20])
	by rogue.cs.columbia.edu with esmtp (Exim 4.12)
	id 1ACi6A-000082-00; Thu, 23 Oct 2003 12:14:06 -0400
Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com ([63.110.3.64])
	by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id h9NGDvLZ029396
	for <sip-implementors@cs.columbia.edu>;
	Thu, 23 Oct 2003 12:13:58 -0400 (EDT)
Received: from localhost.cisco.com (localhost.localdomain [127.0.0.1])
	id h9NGDBd09030;	Thu, 23 Oct 2003 11:13:11 -0500
From: Robert Sparks <rsparks@dynamicsoft.com>
To: simple@ietf.org, sip@ietf.org, sip-implementors@cs.columbia.edu
Content-Type: text/plain
Message-Id: <1066925585.11527.12.camel@RjS.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.4 
Date: Thu, 23 Oct 2003 11:13:05 -0500
Content-Transfer-Encoding: 7bit
X-BeenThere: sip-implementors@cs.columbia.edu
X-Mailman-Version: 2.1.1
Precedence: list
X-Spam-Rating: 202.144.76.19 1.33 0/0/N
X-Spam-Rating: 202.144.76.19 1.33 0/0/N
X-Spam-Rating: 202.144.76.11 1.33 0/0/N
X-MDRemoteIP: 202.144.76.11
X-MDRcpt-To: sip@ietf.org
X-MDaemon-Deliver-To: sip@ietf.org
Content-Transfer-Encoding: 7bit
Subject: [Sip] [Sip-implementors] Registration is now open for SIPIt 14
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
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

SIPIt 14 will take place February 8-13 in Cannes, France.

The event will be hosted by by ETSI. More details and
registration are available at
http://www.etsi.org/plugtests/SIPIT14.htm

>From Philippe Cousin at ETSI Plugtests:

ETSI is happy to host the SIPit event again and to provide
its free support to the SIP community. Sponsors are welcome 
either to support the global event or for the social event.
Should your company be interested to helping sponser this
nice event, please contact philippe.cousin@etsi.org

RjS

_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Thu Oct 23 14:02:43 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09635
	for <sip-archive@odin.ietf.org>; Thu, 23 Oct 2003 14:02:43 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACjmx-00045k-DE
	for sip-archive@odin.ietf.org; Thu, 23 Oct 2003 14:02:23 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NI2NiU015670
	for sip-archive@odin.ietf.org; Thu, 23 Oct 2003 14:02:23 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACjme-0003tx-71; Thu, 23 Oct 2003 14:02:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACjlg-0003hl-Uu
	for sip@optimus.ietf.org; Thu, 23 Oct 2003 14:01:04 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09448;
	Thu, 23 Oct 2003 14:00:54 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACjle-0005dC-00; Thu, 23 Oct 2003 14:01:02 -0400
Received: from magus.nostrum.com ([208.21.192.130] ident=root)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACjld-0005cv-00; Thu, 23 Oct 2003 14:01:01 -0400
Received: from dynamicsoft.com (ben@localhost [127.0.0.1])
	by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9NI0gF8055971;
	Thu, 23 Oct 2003 13:00:51 -0500 (CDT)
	(envelope-from bcampbell@dynamicsoft.com)
Message-ID: <3F981735.8050605@dynamicsoft.com>
Date: Thu, 23 Oct 2003 13:00:21 -0500
From: Ben Campbell <bcampbell@dynamicsoft.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: sip@ietf.org, "'sipping@ietf.org'" <sipping@ietf.org>,
        "'xcon@ietf.org'" <xcon@ietf.org>, simple@ietf.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Softarmor Site Down
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 asked me to forward this on to the various lists:

Softarmor.com is down due to a hardware failure. Dean is rushing to fix 
the problem as I write this. This will affect HTTP and email.




_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Thu Oct 23 15:13:26 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13909
	for <sip-archive@odin.ietf.org>; Thu, 23 Oct 2003 15:13:26 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACktN-0008Ge-FV
	for sip-archive@odin.ietf.org; Thu, 23 Oct 2003 15:13:05 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NJD5Ok031743
	for sip-archive@odin.ietf.org; Thu, 23 Oct 2003 15:13:05 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACktI-0008CS-HP; Thu, 23 Oct 2003 15:13:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACkso-0008A5-AJ
	for sip@optimus.ietf.org; Thu, 23 Oct 2003 15:12:30 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13739;
	Thu, 23 Oct 2003 15:12:20 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACksm-0006iC-00; Thu, 23 Oct 2003 15:12:28 -0400
Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACksm-0006hU-00; Thu, 23 Oct 2003 15:12:28 -0400
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h9NJBew6001569
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Thu, 23 Oct 2003 14:11:40 -0500
Received: (from dwillis@localhost)
	by bdsl.greycouncil.com (8.12.8/8.12.8/Submit) id h9NJBe6Q001567;
	Thu, 23 Oct 2003 14:11:40 -0500
X-Authentication-Warning: bdsl.greycouncil.com: dwillis set sender to dean.willis@softarmor.com using -f
Subject: Re: [Sip] Softarmor Site Down
From: Dean Willis <dean.willis@softarmor.com>
To: Ben Campbell <bcampbell@dynamicsoft.com>
Cc: sip@ietf.org, "'sipping@ietf.org'" <sipping@ietf.org>,
        "'xcon@ietf.org'" <xcon@ietf.org>, simple@ietf.org
In-Reply-To: <3F981735.8050605@dynamicsoft.com>
References: <3F981735.8050605@dynamicsoft.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1066936299.1538.2.camel@bdsl.greycouncil.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 
Date: Thu, 23 Oct 2003 14:11:39 -0500
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, we seem to be back up. 

Apparently, power supplies have an MTBF of exactly 1 day longer than
their warranty, with a very narrow standard deviation around that mean.

The new one has 3 fans -- I don't know if that means it will last three
times as long, or is three times more likely to fail.

--
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 exim@www1.ietf.org  Thu Oct 23 15:20:29 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15173
	for <sip-archive@odin.ietf.org>; Thu, 23 Oct 2003 15:20:29 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACl0A-000161-DN
	for sip-archive@odin.ietf.org; Thu, 23 Oct 2003 15:20:06 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NJK6Ur004189
	for sip-archive@odin.ietf.org; Thu, 23 Oct 2003 15:20:06 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACl07-00014k-7L; Thu, 23 Oct 2003 15:20:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACkzt-00013X-Lk
	for sip@optimus.ietf.org; Thu, 23 Oct 2003 15:19:49 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15125
	for <sip@ietf.org>; Thu, 23 Oct 2003 15:19:39 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACkzs-0006yZ-00
	for sip@ietf.org; Thu, 23 Oct 2003 15:19:48 -0400
Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACkzr-0006xt-00
	for sip@ietf.org; Thu, 23 Oct 2003 15:19:47 -0400
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h9NJJ6w6001684
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Thu, 23 Oct 2003 14:19:06 -0500
Received: (from dwillis@localhost)
	by bdsl.greycouncil.com (8.12.8/8.12.8/Submit) id h9NJJ6IN001682;
	Thu, 23 Oct 2003 14:19:06 -0500
X-Authentication-Warning: bdsl.greycouncil.com: dwillis set sender to dean.willis@softarmor.com using -f
Subject: RE: [Sip] WGLC for URI and Header Parameter Registries
From: Dean Willis <dean.willis@softarmor.com>
To: hisham.khartabil@nokia.com
Cc: Gonzalo.Camarillo@ericsson.com, aki.niemi@nokia.com, rohan@cisco.com,
        sip@ietf.org
In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017972FB@esebe019.ntc.nokia.com>
References: 
	 <2038BCC78B1AD641891A0D1AE133DBB7017972FB@esebe019.ntc.nokia.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1066936745.1525.9.camel@bdsl.greycouncil.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 
Date: Thu, 23 Oct 2003 14:19:05 -0500
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 Wed, 2003-10-22 at 11:45, hisham.khartabil@nokia.com wrote:
> > 
> > The 3GPP p-headers are documented by informational RFCs, as 
> > required by
> > RFC 3427. I'm not up to date on any parameters they've proposed, but I
> > would expect those to be properly documented, if there are any.
> 
> I am referring to parameters that will be proposed in the future :)
> 3GPP delegates have the impression that if the parameter would be
> defined just for 3GPP use, then it does not need to be registered. I
> think it does.

I don't know. Do you think that there will ever be an implementation of
a 3GPP spec that tries to talk to an Internet systems? I'm kind of
hoping the two will interoperate . . . at least a little bit.
Parameter-name conflicts, especially for stuff REQUIRED by 3GPP, would
not help this much. So I'd really like to see their "widely implemented"
parameters registered.

> > 
> > One alternative that might make you happier is a policy of
> > "Specification Required", where that specification can be any publicly
> > acessible body of work recognized by the RFC Editor, including ITU and
> > 3GPP specs.
> 
> This sounds great, and does make me happier actually :)

OK, so would we all (except maybe Bill Marshall, who just proposed a
"very short list" approach) be happy with "Specification Required"
language that would allow registration of a parameter based on 3GPP
specifications without an RFC?

--
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 exim@www1.ietf.org  Thu Oct 23 15:26:30 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15437
	for <sip-archive@odin.ietf.org>; Thu, 23 Oct 2003 15:26:29 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACl60-0001q0-DS
	for sip-archive@odin.ietf.org; Thu, 23 Oct 2003 15:26:09 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NJQ8kl006835
	for sip-archive@odin.ietf.org; Thu, 23 Oct 2003 15:26:08 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACl5u-0001l7-00; Thu, 23 Oct 2003 15:26:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACl59-0001hq-Hw
	for sip@optimus.ietf.org; Thu, 23 Oct 2003 15:25:15 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15398
	for <sip@ietf.org>; Thu, 23 Oct 2003 15:25:05 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACl58-00074T-00
	for sip@ietf.org; Thu, 23 Oct 2003 15:25:14 -0400
Received: from machine77.level3.com ([209.244.4.106] helo=cc26-01.idc1.level3.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACl57-00074Q-00
	for sip@ietf.org; Thu, 23 Oct 2003 15:25:13 -0400
Received: from cc26-01.idc1.level3.com (localhost [127.0.0.1])
	by localhost (Postfix) with ESMTP
	id 7504B87631; Thu, 23 Oct 2003 19:24:31 +0000 (GMT)
Received: from idc1exc0001.corp.global.level3.com (idc1exc0001.corp.global.level3.com [10.1.7.194])
	by cc26-01.idc1.level3.com (Postfix) with SMTP
	id 428128AEEA; Thu, 23 Oct 2003 19:24:28 +0000 (GMT)
Received: from idc1exc0004.corp.global.level3.com ([10.1.8.20]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Thu, 23 Oct 2003 13:24:28 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.6470.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Section 18.1.1 (on MTU and transport) of RFC 3261 and SigComp
Date: Thu, 23 Oct 2003 13:24:27 -0600
Message-ID: <99148FC6551C9641A4B1CDE206D89544805B86@idc1exc0004.corp.global.level3.com>
Thread-Topic: [Sip] Section 18.1.1 (on MTU and transport) of RFC 3261 and SigComp
Thread-Index: AcOZTSx8AKr1mQ99Rb+wjOXazfNCTgACHT3gABEmiMA=
From: "Srivastava, Samir" <Samir.Srivastava@Level3.com>
To: <hisham.khartabil@nokia.com>, <Joachim.Kross@ICN.Siemens.De>,
        <sip@ietf.org>
X-OriginalArrivalTime: 23 Oct 2003 19:24:28.0019 (UTC) FILETIME=[469D2430:01C3999B]
Content-Transfer-Encoding: quoted-printable
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: quoted-printable


Max Path MTU size cannot be assumed to 1500, even if Ethernet is there. =
It
might be changed administratively, due to various reasons. I think it
is good to look into the work of Path MTU discovery group. And put some
recommendations for transporting SIP.

Regards
Samir

-----Original Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of =
hisham.khartabil@nokia.com
Sent: Thursday, October 23, 2003 4:13 AM
To: Joachim.Kross@ICN.Siemens.De; sip@ietf.org
Subject: RE: [Sip] Section 18.1.1 (on MTU and transport) of RFC 3261 and =
SigComp

That's a really good question.

It makes more sense to measure the request after compressing it, since =
doing so before compression gives you false indication. But if after =
compression you realise that the message is actually greater than path =
MTU - 200, or greater 1300 if the path MTU is unknown (can certainly =
happen with the first compressed message), then you need to go back and =
change all the headers that need changing and thereafter compress again.

Regards,
Hisham

> -----Original Message-----
> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of ext
> Joachim Kro=DF
> Sent: Thursday, October 23, 2003 12:50 PM
> To: sip@ietf.org
> Subject: [Sip] Section 18.1.1 (on MTU and transport) of RFC 3261 and
> SigComp
>=20
>=20
> Dear all,
>=20
> I asked this question on the sip-implementors list some time=20
> ago, but it
> seems no one is implementing this yet. So please permit me to ask this
> question here where SIP itself is being developed.
>=20
> I am wondering how the selection of the transport protocol=20
> described in
> section 18.1.1 of RFC 3261 (i.e. for requests greater path=20
> MTU - 200, or
> greater 1300 if the path MTU is unknown, TCP MUST be used) is done in
> the presence of SigComp. Is the decision whether TCP shall be=20
> used made
> based on the length of the uncompressed or the compressed request? Is
> there any normative reference for this (I haven't found one)?
>=20
> Thank you!
>=20
> Regards,
> Joachim
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Thu Oct 23 15:29:24 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15534
	for <sip-archive@odin.ietf.org>; Thu, 23 Oct 2003 15:29:24 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACl8p-0002DL-9s
	for sip-archive@odin.ietf.org; Thu, 23 Oct 2003 15:29:03 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NJT3SF008455
	for sip-archive@odin.ietf.org; Thu, 23 Oct 2003 15:29:03 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACl8m-0002BO-Ts; Thu, 23 Oct 2003 15:29:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACl8Z-0002AH-J6
	for sip@optimus.ietf.org; Thu, 23 Oct 2003 15:28:47 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15516
	for <sip@ietf.org>; Thu, 23 Oct 2003 15:28:37 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACl8Y-00076v-00
	for sip@ietf.org; Thu, 23 Oct 2003 15:28:46 -0400
Received: from opus.cs.columbia.edu ([128.59.20.100])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACl8X-00076r-00
	for sip@ietf.org; Thu, 23 Oct 2003 15:28:45 -0400
Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143])
	(authenticated bits=0)
	by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id h9NJSMAL027958
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 23 Oct 2003 15:28:22 -0400 (EDT)
Message-ID: <3F982BD6.7040306@cs.columbia.edu>
Date: Thu, 23 Oct 2003 15:28:22 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dean Willis <dean.willis@softarmor.com>
CC: hisham.khartabil@nokia.com, Gonzalo.Camarillo@ericsson.com,
        aki.niemi@nokia.com, rohan@cisco.com, sip@ietf.org
Subject: Re: [Sip] WGLC for URI and Header Parameter Registries
References: <2038BCC78B1AD641891A0D1AE133DBB7017972FB@esebe019.ntc.nokia.com> <1066936745.1525.9.camel@bdsl.greycouncil.com>
In-Reply-To: <1066936745.1525.9.camel@bdsl.greycouncil.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

Dean Willis wrote:


> OK, so would we all (except maybe Bill Marshall, who just proposed a
> "very short list" approach) be happy with "Specification Required"
> language that would allow registration of a parameter based on 3GPP
> specifications without an RFC?

I would push this one step further.

One practical problem is one of timing. Implementations are often done 
(and recommended) long before the final spec (RFC, 3GPP final version, 
etc.) is available.

That is also the stage where a central registry is most useful, given 
that it is difficult for developers to track all I-Ds and other 
in-progress standards documents. In some cases, access to these 
documents is restricted or it is difficult to find the relevant ones. 
(Quick, which 23.* documents define SIP parameters and which of the 
dated directories should you look at?)

One suggestion would be to register parameters from *WG* I-Ds, for 
example, as in draft-ietf-*, and equivalent maturity levels from other 
SDOs. The registration could have a 'preliminary' asterisk of some sort 
to indicate the lack of final documentation status.

Henning


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Thu Oct 23 15:30:28 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15597
	for <sip-archive@odin.ietf.org>; Thu, 23 Oct 2003 15:30:27 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACl9q-0002ZU-Az
	for sip-archive@odin.ietf.org; Thu, 23 Oct 2003 15:30:07 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NJU6I9009854
	for sip-archive@odin.ietf.org; Thu, 23 Oct 2003 15:30:06 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACl9n-0002UY-Ny; Thu, 23 Oct 2003 15:30:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACl93-0002Lq-4H
	for sip@optimus.ietf.org; Thu, 23 Oct 2003 15:29:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15528
	for <sip@ietf.org>; Thu, 23 Oct 2003 15:29:07 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACl91-00077i-00
	for sip@ietf.org; Thu, 23 Oct 2003 15:29:15 -0400
Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACl91-00076s-00
	for sip@ietf.org; Thu, 23 Oct 2003 15:29:15 -0400
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h9NJShw6001739
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Thu, 23 Oct 2003 14:28:43 -0500
Received: (from dwillis@localhost)
	by bdsl.greycouncil.com (8.12.8/8.12.8/Submit) id h9NJShc5001737;
	Thu, 23 Oct 2003 14:28:43 -0500
X-Authentication-Warning: bdsl.greycouncil.com: dwillis set sender to dean.willis@softarmor.com using -f
Subject: Re: [Sip] Question on rfc3310 Hypertext Transfer Protocol (HTTP)
	Digest Aut hentication Using Authentication and Key Agreement (AKA)
From: Dean Willis <dean.willis@softarmor.com>
To: Xin Chen <x.chen@fle.fujitsu.com>
Cc: "'sip@ietf.org'" <sip@ietf.org>
In-Reply-To: <E9978DD405A2D611913500047583E37A4D1A99@fle2.fle.fujitsu.com>
References: <E9978DD405A2D611913500047583E37A4D1A99@fle2.fle.fujitsu.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1066937323.1526.20.camel@bdsl.greycouncil.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 
Date: Thu, 23 Oct 2003 14:28:43 -0500
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, 2003-10-23 at 05:38, Xin Chen wrote:
> Hi,
> 
> My question is that if REGISTER procedure is used to authenticate the user
> agent, then it can only authenticate the device which initiate the REGISTER.
> 
> 
> What happen if the REGISTER contains multiple contact addresses which
> possibly represent multiple devices, does that mean all the other devices
> are authenticated also?
> 
> If forking happens, how to provide confidentially and integration to the SIP
> messages towards the other contact addresses?
> 
> I am not sure whether these questions are within the scope of the RFC or
> not, but your comment and thoughts are appreciated. 
> 

1) This type of question is probably better-addressed to the SIP
Implementors list. Perhaps we should even include it in the FAQ?

2) In the typical case, authentication of a REGISTER request simply
establishes that the request in question came from a user agent with
credentials to authenticate against the address-of-record in question.
It does NOT establish anything about future requests coming from that
user agent, or about contacts registered by that request.

Authentication of a REGISTER request does NOTHING to provide
confidentiality or message protection of traffic back toward the
registering UA, nor to any other UA for which a "Contact" exists. That's
why we have "sips" and TLS. And the ability to authenticate EVERY
request, not just REGISTER.

3GPP has done something "special" here -- during the registration
transaction, they establish keying for a transport-level
integrity-protected (and optionally encrypted) tunnel between the UA and
its edge proxy. This tunnel then protects future messages between the
two, and since the edge proxy is trusted (and every other proxy, for
that matter), allows for transitive trust all the way through the
system. This isn't a general case solution, but they feel it works in a
telecom operator environment. This is why there are all sorts of
applicability statement and scope warnings in the RFCs defining 3GPP
P-headers -- if used in the outside world, the sensistive information
therein would be likely to be compromised.

--
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 exim@www1.ietf.org  Thu Oct 23 15:31:25 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15691
	for <sip-archive@odin.ietf.org>; Thu, 23 Oct 2003 15:31:25 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AClAm-0002sY-VY
	for sip-archive@odin.ietf.org; Thu, 23 Oct 2003 15:31:05 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NJV4T9011013
	for sip-archive@odin.ietf.org; Thu, 23 Oct 2003 15:31:04 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AClAl-0002ql-1X; Thu, 23 Oct 2003 15:31:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AClA2-0002ea-F7
	for sip@optimus.ietf.org; Thu, 23 Oct 2003 15:30:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15578
	for <sip@ietf.org>; Thu, 23 Oct 2003 15:30:08 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AClA0-000792-00
	for sip@ietf.org; Thu, 23 Oct 2003 15:30:16 -0400
Received: from h-135-207-24-16.research.att.com ([135.207.24.16] helo=linux.research.att.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACl9v-00078O-00
	for sip@ietf.org; Thu, 23 Oct 2003 15:30:16 -0400
Received: from unixmail.research.att.com (unixmail.research.att.com [135.207.26.71])
	by linux.research.att.com (8.12.8/8.12.8) with ESMTP id h9NJbJ2q021580;
	Thu, 23 Oct 2003 15:37:19 -0400
Received: from fish.research.att.com (fish.research.att.com [135.207.27.137])
	by unixmail.research.att.com (8.12.8+Sun/8.8.7) with ESMTP id h9NJRRZn018278;
	Thu, 23 Oct 2003 15:27:27 -0400 (EDT)
From: William Marshall <wtm@research.att.com>
Received: (from wtm@localhost)
	by fish.research.att.com (SGI-8.9.3/8.8.5) id PAA51902;
	Thu, 23 Oct 2003 15:29:36 -0400 (EDT)
Date: Thu, 23 Oct 2003 15:29:36 -0400 (EDT)
Message-Id: <200310231929.PAA51902@fish.research.att.com>
To: sip@ietf.org
Cc: dean.willis@softarmor.com
Subject: RE: [Sip] WGLC for URI and Header Parameter Registries
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>

Dean wrote:
> > > 
> > > One alternative that might make you happier is a policy of
> > > "Specification Required", where that specification can be any publicly
> > > acessible body of work recognized by the RFC Editor, including ITU and
> > > 3GPP specs.
> > 
> > This sounds great, and does make me happier actually :)
> 
> OK, so would we all (except maybe Bill Marshall, who just proposed a
> "very short list" approach) be happy with "Specification Required"
> language that would allow registration of a parameter based on 3GPP
> specifications without an RFC?

I don't think I was disagreeing with this at all.  The parameter values
clearly need to be documented, and somewhere where their definition
can be retrieved easily by everyone.  

My argument for the "very short list" is that the "initial" bunch of 
parameter values, documented in the same RFC as where the header is 
documented, should not need to be added to the IANA registrary 
as "additional" parameters.

Bill Marshall
wtm@research.att.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 exim@www1.ietf.org  Thu Oct 23 16:42:31 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17964
	for <sip-archive@odin.ietf.org>; Thu, 23 Oct 2003 16:42:31 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACmHb-0003Lt-R6
	for sip-archive@odin.ietf.org; Thu, 23 Oct 2003 16:42:11 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NKgBQ3012879
	for sip-archive@odin.ietf.org; Thu, 23 Oct 2003 16:42:11 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACmHR-0003JN-Iw; Thu, 23 Oct 2003 16:42:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACmGT-0003Ao-32
	for sip@optimus.ietf.org; Thu, 23 Oct 2003 16:41:01 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17925
	for <sip@ietf.org>; Thu, 23 Oct 2003 16:40:50 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACmGQ-0000E8-00
	for sip@ietf.org; Thu, 23 Oct 2003 16:40:59 -0400
Received: from ams-iport-1.cisco.com ([144.254.74.5])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACmGQ-0000Dz-00
	for sip@ietf.org; Thu, 23 Oct 2003 16:40:58 -0400
Received: from cisco.com (171.71.177.254)
  by ams-iport-1.cisco.com with ESMTP; 23 Oct 2003 22:38:27 +0200
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9NKeMj0014823;
	Thu, 23 Oct 2003 13:40:24 -0700 (PDT)
Received: from cisco.com ([161.44.79.51])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ADK53295;
	Thu, 23 Oct 2003 16:40:21 -0400 (EDT)
Message-ID: <3F983CB5.2030201@cisco.com>
Date: Thu, 23 Oct 2003 16:40:21 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: sdonovan@dynamicsoft.com, Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: sip@ietf.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Comments on draft-ietf-sip-session-timer-12
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 have a couple of comments on this, one serious, the other editorial.

The serious one: In 7.1, 2nd to last paragraph:

    A UAC MAY include a Session-Expires in an initial session refresh
    request if it wishes for a session timer to be applied to the
    session. The value of this header field indicates the session
    interval desired by the UAC.  If a Min-SE header is included in the
    initial session refresh request, the value of the Session-Expires
    MUST be equal to the value in Min-SE.

This can't be right. This says that if the UAC wants to specify a value 
then no negotiation about the value is possible. This first appeared in 
v-11. I would suggest a fix, but I can't figure out what the intent was.

Surely it should be ok for the UAC to include a Min-SE, and a 
Session-Expires with a value greater than that in Min-SE, thus giving 
the proxies and the UAS an opportunity to set Min-SE higher or 
Session-Expires lower.


The editorial one: In the introduction, the following paragraphs:

    This refresh mechanism has additional applications. For the same
    reasons a call stateful proxy server would like to determine whether
    the session is still active, a user agent would like to make this
    determination. This determination can be made at a user agent without
    the use of SIP level mechanisms; for audio sessions, periodic RTCP
    packets serve as an indication of liveness [5]. However, it is
    desirable to separate SIP session liveness from the details of the
    particular session.

    Another application of the session timer is in the construction of a
    SIP Network Address Translator (NAT) Application Level Gateway (ALG)
    [6]. The ALG embedded in a NAT will need to maintain state for the
    duration of a call. This state must eventually be removed. Relying on
    a BYE to trigger the removal of state, besides being unreliable,
    introduces a potential denial of service attack.

are really pointless. A UA doesn't need session timer to refresh 
sessions - it can send a reINVITE or UPDATE whenever it is curious. And 
the ALG must either be a proxy (in which case it falls within the 
primary purpose of session timer), or else it is a B2BUA (in which case 
it is a UA and can refresh on its own.) So neither of these is really an 
additional application of the mechanism. I think both paragraphs can be 
removed.

Otherwise this looks good to me.

	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 exim@www1.ietf.org  Fri Oct 24 06:48:30 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24802
	for <sip-archive@odin.ietf.org>; Fri, 24 Oct 2003 06:48:30 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACzUK-0001m0-QK
	for sip-archive@odin.ietf.org; Fri, 24 Oct 2003 06:48:12 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OAmCcE006758
	for sip-archive@odin.ietf.org; Fri, 24 Oct 2003 06:48:12 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACzUC-0001ig-0D; Fri, 24 Oct 2003 06:48:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABuMg-00060e-Bh
	for sip@optimus.ietf.org; Tue, 21 Oct 2003 07:07:50 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13235
	for <sip@ietf.org>; Tue, 21 Oct 2003 07:07:37 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABuMb-0002EE-00
	for sip@ietf.org; Tue, 21 Oct 2003 07:07:45 -0400
Received: from goliath.siemens.de ([192.35.17.28])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABuMb-0002EB-00
	for sip@ietf.org; Tue, 21 Oct 2003 07:07:45 -0400
Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14])
	by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id h9LB7j214913
	for <sip@ietf.org>; Tue, 21 Oct 2003 13:07:45 +0200 (MEST)
Received: from blues.mchh.siemens.de (blues.mchh.siemens.de [139.21.204.206])
	by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id h9LB7ir09168
	for <sip@ietf.org>; Tue, 21 Oct 2003 13:07:44 +0200 (MEST)
Received: from mchh253e.mchh.siemens.de (mchh253e.mchh.siemens.de [139.21.200.63])
	by blues.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id NAA16887
	for <sip@ietf.org>; Tue, 21 Oct 2003 13:06:08 +0200 (MET DST)
Received: by mchh253e.mchh.siemens.de with Internet Mail Service (5.5.2653.19)
	id <V2TWTVRP>; Tue, 21 Oct 2003 13:06:51 +0200
Message-ID: <76592C4D3DA1AC4FB8424084D10D31A8BE063F@mchh2c4e.mchh.siemens.de>
From: Kross Joachim <joachim.kross@siemens.com>
To: sip@ietf.org
Date: Tue, 21 Oct 2003 13:06:48 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Subject: [Sip] Section 18.1.1 (on MTU and transport) of RFC 3261 and SigComp
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,

I asked this question on the sip-implementors list some time ago, but it seems no one is implementing this yet. So please permit me to ask this question here where SIP itself is being developed.

I am wondering how the selection of the transport protocol described in section 18.1.1 of RFC 3261 (i.e. for requests greater path MTU - 200, or greater 1300 if the path MTU is unknown, TCP MUST be used) is done in the presence of SigComp. Is the decision whether TCP shall be used made based on the length of the uncompressed or the compressed request? Is there any normative reference for this (I haven't found one)?

Thank you!

Regards,
Joachim


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Fri Oct 24 07:11:55 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25735
	for <sip-archive@odin.ietf.org>; Fri, 24 Oct 2003 07:11:55 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACzqy-0007mO-9o
	for sip-archive@odin.ietf.org; Fri, 24 Oct 2003 07:11:38 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OBBZsM029824
	for sip-archive@odin.ietf.org; Fri, 24 Oct 2003 07:11:35 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACzqZ-0007VD-8l; Fri, 24 Oct 2003 07:11:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACzpy-0007KH-2u
	for sip@optimus.ietf.org; Fri, 24 Oct 2003 07:10:34 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25681
	for <sip@ietf.org>; Fri, 24 Oct 2003 07:10:21 -0400 (EDT)
From: aki.niemi@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACzpt-0001hV-00
	for sip@ietf.org; Fri, 24 Oct 2003 07:10:29 -0400
Received: from mgw-x1.nokia.com ([131.228.20.21])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACzps-0001hS-00
	for sip@ietf.org; Fri, 24 Oct 2003 07:10:29 -0400
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9OBATI18184
	for <sip@ietf.org>; Fri, 24 Oct 2003 14:10:29 +0300 (EET DST)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T657ad72818ac158f257fd@esvir05nok.ntc.nokia.com> for <sip@ietf.org>;
 Fri, 24 Oct 2003 14:10:17 +0300
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747);
	 Fri, 24 Oct 2003 14:10:17 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 24 Oct 2003 14:10:17 +0300
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D59290@esebe013.ntc.nokia.com>
Thread-Topic: New PUBLISH draft
Thread-Index: AcOaG205H28f++DSQSyWQ+qSbaJQxw==
To: <sip@ietf.org>
X-OriginalArrivalTime: 24 Oct 2003 11:10:17.0568 (UTC) FILETIME=[67FB1E00:01C39A1F]
Content-Transfer-Encoding: quoted-printable
Subject: [Sip] New PUBLISH 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: quoted-printable

All,

I've updated the PUBLISH draft to reflect the recent discussions, as =
well as a number of other comments I've received. Until this appears in =
the I-D directories, I've placed a copy at:

http://www.saunalahti.fi/~apniem/drafts/draft-ietf-sip-publish-01.html
http://www.saunalahti.fi/~apniem/drafts/draft-ietf-sip-publish-01.txt

I think we are pretty much ready for last call with this one, but I =
still think more people need to look at it either before or during LC =
(BTW, thanks to those who've already provided comments).=20

IMO, there is one part of the draft that deserves special attention, and =
I'd appreciate it if people could go over the usage of etags in this =
draft once more. I've received very little comments on it, which can of =
course be a good sign. I'd like to be sure, though.  ;-)

Regards,
Aki=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Fri Oct 24 08:24:45 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27582
	for <sip-archive@odin.ietf.org>; Fri, 24 Oct 2003 08:24:45 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AD0zO-0000sg-6x
	for sip-archive@odin.ietf.org; Fri, 24 Oct 2003 08:24:24 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OCOMUs003380
	for sip-archive@odin.ietf.org; Fri, 24 Oct 2003 08:24:22 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AD0z6-0000eG-KK; Fri, 24 Oct 2003 08:24:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AD04l-0002dy-MP
	for sip@optimus.ietf.org; Fri, 24 Oct 2003 07:25:51 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26071
	for <sip@ietf.org>; Fri, 24 Oct 2003 07:25:42 -0400 (EDT)
From: aki.niemi@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AD04l-0001sf-00
	for sip@ietf.org; Fri, 24 Oct 2003 07:25:51 -0400
Received: from mgw-x4.nokia.com ([131.228.20.27])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AD04k-0001sc-00
	for sip@ietf.org; Fri, 24 Oct 2003 07:25:50 -0400
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9OBPmI14786
	for <sip@ietf.org>; Fri, 24 Oct 2003 14:25:48 +0300 (EET DST)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T657ae54362ac158f24cae@esvir04nok.ntc.nokia.com>;
 Fri, 24 Oct 2003 14:25:42 +0300
Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747);
	 Fri, 24 Oct 2003 14:25:41 +0300
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Fri, 24 Oct 2003 14:25:41 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Question on rfc3310 Hypertext Transfer Protocol (HTTP) Digest Aut hentication Using Authentication and Key Agreement (AKA)
Date: Fri, 24 Oct 2003 14:25:41 +0300
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D90C9@esebe013.ntc.nokia.com>
Thread-Topic: [Sip] Question on rfc3310 Hypertext Transfer Protocol (HTTP) Digest Aut hentication Using Authentication and Key Agreement (AKA)
Thread-Index: AcOaFSsw9onlupSDSuS8FS/6ZzhOvgACk6ig
To: <x.chen@fle.fujitsu.com>, <dean.willis@softarmor.com>
Cc: <sip@ietf.org>
X-OriginalArrivalTime: 24 Oct 2003 11:25:41.0609 (UTC) FILETIME=[8EC09590:01C39A21]
Content-Transfer-Encoding: quoted-printable
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: quoted-printable

Hi,

I think you are right that in a 3GPP system, registering multiple =
contacts that point to different terminals would have problems because =
of the way the SA establishment is done as part of the authentication =
challenge/response exchange. Obviously, a request forking to a terminal =
that has no valid SA would fail. However, what would be the use case for =
doing this sort of thing?

This is also not a 3GPP deficiency per se, but has implications in other =
systems as well. If I register a contact address that I'm not in =
possession of myself, there are many things that can potentially go =
wrong. What if the target UA's lease on that address runs out, and =
someone else claims it? What if that UA doesn't support the capabilities =
advertised in the contact I registered?

In any case, I think RFC 3310 (which specifies the AKA protocol based =
Digest authentication) has quite nothing to do with this, and neither =
does any other IETF specification that I can think of off the top of my =
head.

Cheers,
Aki  =20

 > -----Original Message-----
 > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On=20
 > Behalf Of ext Xin
 > Chen
 > Sent: 24 October, 2003 12:53
 > To: 'Dean Willis'
 > Cc: 'sip@ietf.org'
 > Subject: RE: [Sip] Question on rfc3310 Hypertext Transfer Protocol
 > (HTTP) Digest Aut hentication Using Authentication and Key Agreement
 > (AKA)
 >=20
 >=20
 > Hi Dean,
 >=20
 > Thanks for your answer. Exactly, that the questions are from=20
 > my study in
 > 3GPP specifications.=20
 >=20
 > I think there is a problem in 3GPP to support multiple=20
 > contact addresses in
 > a single REGISTER. Since more likely, each contact address=20
 > will be another
 > terminal, however, only the terminal which initiates the=20
 > REGISTER could be
 > authenticated successfully and have a security association=20
 > established after
 > the registration. However, terminals representing other=20
 > contact addresses do
 > not have that SA, so if forking happens, messages to the=20
 > other terminals
 > will be unprotected or even dropped off in the network.
 >=20
 > You suggest to address this question in sip implementer,=20
 > thanks. However, I
 > am not sure this is purely an implementation issue or not.=20
 > We would like to
 > see some general guidelines on solving this problem perhaps.
 >=20
 > Hope see you again sometime in 3GPP again:-)
 >=20
 > Regards
 > =20
 > Xin Chen
 > Mobile Network Division
 > Fujitsu Laboratories Europe
 > Tel: +44(0)2086064453
 > Mobile: +44(0)7775741020
 >=20
 >=20
 > -----Original Message-----
 > From: Dean Willis [mailto:dean.willis@softarmor.com]=20
 > Sent: 23 October 2003 20:29
 > To: Xin Chen
 > Cc: 'sip@ietf.org'
 > Subject: Re: [Sip] Question on rfc3310 Hypertext Transfer=20
 > Protocol (HTTP)
 > Digest Aut hentication Using Authentication and Key Agreement (AKA)
 >=20
 >=20
 > On Thu, 2003-10-23 at 05:38, Xin Chen wrote:
 > > Hi,
 > >=20
 > > My question is that if REGISTER procedure is used to=20
 > authenticate the=20
 > > user agent, then it can only authenticate the device which=20
 > initiate=20
 > > the REGISTER.
 > >=20
 > >=20
 > > What happen if the REGISTER contains multiple contact=20
 > addresses which=20
 > > possibly represent multiple devices, does that mean all the other=20
 > > devices are authenticated also?
 > >=20
 > > If forking happens, how to provide confidentially and=20
 > integration to=20
 > > the SIP messages towards the other contact addresses?
 > >=20
 > > I am not sure whether these questions are within the scope=20
 > of the RFC=20
 > > or not, but your comment and thoughts are appreciated.
 > >=20
 >=20
 > 1) This type of question is probably better-addressed to the SIP
 > Implementors list. Perhaps we should even include it in the FAQ?
 >=20
 > 2) In the typical case, authentication of a REGISTER request simply
 > establishes that the request in question came from a user agent with
 > credentials to authenticate against the address-of-record in=20
 > question. It
 > does NOT establish anything about future requests coming=20
 > from that user
 > agent, or about contacts registered by that request.
 >=20
 > Authentication of a REGISTER request does NOTHING to provide=20
 > confidentiality
 > or message protection of traffic back toward the registering=20
 > UA, nor to any
 > other UA for which a "Contact" exists. That's why we have=20
 > "sips" and TLS.
 > And the ability to authenticate EVERY request, not just REGISTER.
 >=20
 > 3GPP has done something "special" here -- during the registration
 > transaction, they establish keying for a transport-level=20
 > integrity-protected
 > (and optionally encrypted) tunnel between the UA and its=20
 > edge proxy. This
 > tunnel then protects future messages between the two, and=20
 > since the edge
 > proxy is trusted (and every other proxy, for that matter), allows for
 > transitive trust all the way through the system. This isn't=20
 > a general case
 > solution, but they feel it works in a telecom operator=20
 > environment. This is
 > why there are all sorts of applicability statement and scope=20
 > warnings in the
 > RFCs defining 3GPP P-headers -- if used in the outside=20
 > world, the sensistive
 > information therein would be likely to be compromised.
 >=20
 > --
 > Dean
 >=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Fri Oct 24 10:53:08 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05655
	for <sip-archive@odin.ietf.org>; Fri, 24 Oct 2003 10:53:08 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AD3J3-00032Z-QN
	for sip-archive@odin.ietf.org; Fri, 24 Oct 2003 10:52:49 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OEqnPr011683
	for sip-archive@odin.ietf.org; Fri, 24 Oct 2003 10:52:49 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AD3IJ-0002np-3c; Fri, 24 Oct 2003 10:52:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AD3IC-0002ku-C3
	for sip@optimus.ietf.org; Fri, 24 Oct 2003 10:51:56 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05459;
	Fri, 24 Oct 2003 10:51:43 -0400 (EDT)
Message-Id: <200310241451.KAA05459@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, 24 Oct 2003 10:51:43 -0400
Subject: [Sip] I-D ACTION:draft-ietf-sip-history-info-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.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title		: An Extension to the Session Initiation Protocol for Request History Information
	Author(s)	: M. Barnes
	Filename	: draft-ietf-sip-history-info-01.txt
	Pages		: 25
	Date		: 2003-10-23
	
This draft defines a standard mechanism for capturing the history 
information associated with a SIP request.  This capability enables 
many enhanced services by providing the information as to how and why 
a call arrives at a specific application or user.  This draft defines 
a new optional SIP header, History-Info, for capturing the history 
information in requests. A new option tag, HistInfo, to be included 
in the Supported header is defined to allow UAs to indicate whether 
the HistInfo should be returned in responses to a request which has 
captured the history information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-history-info-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-ietf-sip-history-info-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-ietf-sip-history-info-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:	<2003-10-24103842.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-history-info-01.txt

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

Content-Type: text/plain
Content-ID:	<2003-10-24103842.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 exim@www1.ietf.org  Fri Oct 24 10:53:26 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05703
	for <sip-archive@odin.ietf.org>; Fri, 24 Oct 2003 10:53:26 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AD3JL-0003A1-UT
	for sip-archive@odin.ietf.org; Fri, 24 Oct 2003 10:53:07 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OEr7oP012117
	for sip-archive@odin.ietf.org; Fri, 24 Oct 2003 10:53:07 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AD3JF-00037F-Mz; Fri, 24 Oct 2003 10:53:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AD3IM-0002pz-Bc
	for sip@optimus.ietf.org; Fri, 24 Oct 2003 10:52:06 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05496;
	Fri, 24 Oct 2003 10:51:53 -0400 (EDT)
Message-Id: <200310241451.KAA05496@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, 24 Oct 2003 10:51:52 -0400
Subject: [Sip] I-D ACTION:draft-ietf-sip-callerprefs-10.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		: Caller Preferences for the Session Initiation Protocol (SIP)
	Author(s)	: J. Rosenberg, H. Schulzrinne, P. Kyzivat
	Filename	: draft-ietf-sip-callerprefs-10.txt
	Pages		: 33
	Date		: 2003-10-23
	
This document describes a set of extensions to the Session Initiation
Protocol (SIP) which allow a caller to express preferences about
request handling in servers. These preferences include the ability to
select which URIs a request gets routed to, and to specify certain
request handling directives in proxies and redirect servers. It does
so by defining four new request headers, Accept-Contact, Reject-
Contact, Require-Contact and Request-Disposition, which specify the
caller's preferences. The extension also defines new parameters for
the Contact header that describe the capabilities and characteristics
of a UA.

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-callerprefs-10.txt

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

Content-Type: text/plain
Content-ID:	<2003-10-24103933.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 exim@www1.ietf.org  Fri Oct 24 10:53:26 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05706
	for <sip-archive@odin.ietf.org>; Fri, 24 Oct 2003 10:53:26 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AD3JM-0003Ar-B5
	for sip-archive@odin.ietf.org; Fri, 24 Oct 2003 10:53:08 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OEr80m012187
	for sip-archive@odin.ietf.org; Fri, 24 Oct 2003 10:53:08 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AD3JH-000382-3A; Fri, 24 Oct 2003 10:53:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AD3IY-0002vB-4Q
	for sip@optimus.ietf.org; Fri, 24 Oct 2003 10:52:18 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05525;
	Fri, 24 Oct 2003 10:52:05 -0400 (EDT)
Message-Id: <200310241452.KAA05525@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, 24 Oct 2003 10:52:05 -0400
Subject: [Sip] I-D ACTION:draft-ietf-sip-callee-caps-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.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title		: Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)
	Author(s)	: J. Rosenberg
	Filename	: draft-ietf-sip-callee-caps-01.txt
	Pages		: 40
	Date		: 2003-10-23
	
This specification defines mechanisms by which a Session Initiation
Protocol (SIP) user agent can convey its capabilities and
characteristics to other user agents. These capabilities are conveyed
as parameters of the Contact header field.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-callee-caps-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-ietf-sip-callee-caps-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-ietf-sip-callee-caps-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:	<2003-10-24103945.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-callee-caps-01.txt

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

Content-Type: text/plain
Content-ID:	<2003-10-24103945.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 exim@www1.ietf.org  Fri Oct 24 13:07:49 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18291
	for <sip-archive@odin.ietf.org>; Fri, 24 Oct 2003 13:07:49 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AD5PO-0006At-GG
	for sip-archive@odin.ietf.org; Fri, 24 Oct 2003 13:07:31 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OH7Uhf023726
	for sip-archive@odin.ietf.org; Fri, 24 Oct 2003 13:07:30 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AD5Ow-0005uh-Ln; Fri, 24 Oct 2003 13:07:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AD5O4-0005fe-4x
	for sip@optimus.ietf.org; Fri, 24 Oct 2003 13:06:08 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18143
	for <sip@ietf.org>; Fri, 24 Oct 2003 13:05:55 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AD5O2-0000yK-00
	for sip@ietf.org; Fri, 24 Oct 2003 13:06:06 -0400
Received: from mail.siemenscom.com ([12.146.131.10])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AD5O1-0000yC-00
	for sip@ietf.org; Fri, 24 Oct 2003 13:06:05 -0400
Received: from imail1.icn.siemens.com (mail-stc.siemenscom.com [165.218.65.50])
	by mail.siemenscom.com (8.9.3p092403/8.9.3) with ESMTP id KAA07695
	for <sip@ietf.org>; Fri, 24 Oct 2003 10:03:09 -0700 (PDT)
Received: from stca200a.bus.sc.rolm.com (stca200a.bus.sc.rolm.com [165.218.68.180])
	by imail1.icn.siemens.com (8.12.10/8.12.10) with ESMTP id h9OH0G1k018661
	for <sip@ietf.org>; Fri, 24 Oct 2003 10:00:16 -0700 (PDT)
Received: by stca200a.bus.sc.rolm.com with Internet Mail Service (5.5.2657.72)
	id <VDL4QZ3S>; Fri, 24 Oct 2003 10:06:02 -0700
Message-ID: <DA2CCB2AC5F7E447B18E19D786093BB201C1CF07@stca952a.eng.sc.rolm.com>
From: "Karapetkov, Stefan H" <Stefan.H.Karapetkov@icn.siemens.com>
To: sip@ietf.org
Date: Fri, 24 Oct 2003 10:00:01 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C39A50.438BF414"
Subject: [Sip] Using domain name instead of IP address in 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>

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_01C39A50.438BF414
Content-Type: text/plain

Hello,

 

RFC 3236 section 6 discusses "constructing SIP URIs" for inclusion in a
Contact header. The RFC talks about clients and servers, and the problem
that it is trying to solve concerns a proxy client trying to locate a proxy
server. It is not clear to me if this RFC is intended to cover the case of a
proxy trying to locate a UA, e.g. a SIP phone or a SIP soft client. 

 

The only reason the RFC gives for using a domain name instead of an IP
address is because of the possible need to use a back-up server. By using
the domain name the DNS server can resolve the domain name to either the
main server or the back-up server. However, in the case of a SIP phone or
SIP client, back-up does not apply.

 

All products we have seen at SIPit use an IP address in the Contact header,
not a domain name. Does anyone see value in using a domain name in a SIP UA
implementation instead of the currently used IP address?

 

Regards,

Stefan 

 


------_=_NextPart_001_01C39A50.438BF414
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">


<meta name=Generator content="Microsoft Word 10 (filtered)">
<title>Message</title>

<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
p
	{margin-right:0in;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.emailstyle18
	{font-family:Arial;
	color:navy;}
span.emailstyle19
	{font-family:Arial;
	color:navy;}
span.emailstyle20
	{font-family:Arial;
	color:navy;}
span.EmailStyle21
	{font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=blue>

<div class=Section1>

<p class=MsoNormal><font size=3 color=navy face="Times New Roman"><span
style='font-size:12.0pt;color:navy'>Hello</span></font><font size=2 color=navy
face=Arial><span style='font-size:10.0pt;font-family:Arial;color:navy'>,</span></font></p>

<div>

<p class=MsoNormal><font size=3 color=navy face="Times New Roman"><span
style='font-size:12.0pt;color:navy'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>RFC 3236 </span></font><font size=2
color=blue face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:blue'>section 6 </span></font><font size=2 color=navy face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:navy'>discusses </span></font><font
size=2 color=blue face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:blue'>&quot;constructing SIP URIs&quot; for inclusion in a Contact
header. </span></font><font size=2 color=navy face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:navy'>The </span></font><font
size=2 color=blue face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:blue'>RFC </span></font><font size=2 color=navy face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:navy'>talks </span></font><font
size=2 color=blue face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:blue'>about clients and servers, and the problem that it is trying to
solve concerns a proxy client trying to locate a proxy server. It is not clear to
me if this RFC is intended to cover the case of a proxy trying to locate a UA, e.g.
a SIP phone or a SIP soft client. </span></font></p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>The only reason </span></font><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>the RFC </span></font><font size=2 color=blue face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:blue'>gives for using a domain
name instead of an IP address is because of the possible need to use a back-up
server. By using the domain name the DNS server can resolve the domain name to
either the main server or the back-up server. However, in the case of a </span></font><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>SIP </span></font><font size=2 color=blue face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:blue'>phone</span></font><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'> or SIP client</span></font><font size=2 color=blue face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:blue'>, back-up does not apply.</span></font></p>

</div>

<div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

<div>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>All products we have seen at SIPit use an
IP address in the Contact header, not a domain name. Does anyone see value in
using a domain name in a SIP UA implementation instead of the currently used IP
address?</span></font></p>

</div>

<div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

<div>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>Regards,</span></font></p>

</div>

<div>

<p class=MsoNormal><font size=3 color=navy face="Times New Roman"><span
style='font-size:12.0pt;color:navy'>Stefan</span></font>&nbsp;</p>

</div>

<div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C39A50.438BF414--

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Fri Oct 24 13:29:37 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19201
	for <sip-archive@odin.ietf.org>; Fri, 24 Oct 2003 13:29:37 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AD5kS-000352-BO
	for sip-archive@odin.ietf.org; Fri, 24 Oct 2003 13:29:17 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OHTGNU011782
	for sip-archive@odin.ietf.org; Fri, 24 Oct 2003 13:29:16 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AD5kD-0002xP-LG; Fri, 24 Oct 2003 13:29:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AD5k1-0002um-NG
	for sip@optimus.ietf.org; Fri, 24 Oct 2003 13:28:50 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19157
	for <sip@ietf.org>; Fri, 24 Oct 2003 13:28:39 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AD5jz-0001Ky-00
	for sip@ietf.org; Fri, 24 Oct 2003 13:28:47 -0400
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AD5jz-0001Kl-00
	for sip@ietf.org; Fri, 24 Oct 2003 13:28:47 -0400
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9OHQHb28208;
	Fri, 24 Oct 2003 13:26:17 -0400 (EDT)
Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id VR2R4QL5; Fri, 24 Oct 2003 13:26:18 -0400
Received: from nortelnetworks.com (acart1b2.ca.nortel.com [47.129.129.12]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id SZW5NGX6; Fri, 24 Oct 2003 13:26:18 -0400
Message-ID: <3F9960B7.5060800@nortelnetworks.com>
Date: Fri, 24 Oct 2003 13:26:15 -0400
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Tom Taylor <taylor@nortelnetworks.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Henning Schulzrinne <hgs@cs.columbia.edu>
CC: Dean Willis <dean.willis@softarmor.com>, hisham.khartabil@nokia.com,
        Gonzalo.Camarillo@ericsson.com, aki.niemi@nokia.com, rohan@cisco.com,
        sip@ietf.org
Subject: Re: [Sip] WGLC for URI and Header Parameter Registries
References: <2038BCC78B1AD641891A0D1AE133DBB7017972FB@esebe019.ntc.nokia.com> <1066936745.1525.9.camel@bdsl.greycouncil.com> <3F982BD6.7040306@cs.columbia.edu>
In-Reply-To: <3F982BD6.7040306@cs.columbia.edu>
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

We took that approach in the Megaco package registry.

Henning Schulzrinne wrote:

...

> 
> One suggestion would be to register parameters from *WG* I-Ds, for 
> example, as in draft-ietf-*, and equivalent maturity levels from other 
> SDOs. The registration could have a 'preliminary' asterisk of some sort 
> to indicate the lack of final documentation status.
> 
> Henning
> 
...


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Fri Oct 24 13:45:30 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19813
	for <sip-archive@odin.ietf.org>; Fri, 24 Oct 2003 13:45:30 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AD5zp-0007b4-Nz
	for sip-archive@odin.ietf.org; Fri, 24 Oct 2003 13:45:10 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OHj9QX029136
	for sip-archive@odin.ietf.org; Fri, 24 Oct 2003 13:45:09 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AD5zi-0007XP-Qz; Fri, 24 Oct 2003 13:45:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AD5yo-00079M-1i
	for sip@optimus.ietf.org; Fri, 24 Oct 2003 13:44:06 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19716
	for <sip@ietf.org>; Fri, 24 Oct 2003 13:43:55 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AD5yl-0001XC-00
	for sip@ietf.org; Fri, 24 Oct 2003 13:44:03 -0400
Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AD5yk-0001Wp-00
	for sip@ietf.org; Fri, 24 Oct 2003 13:44:02 -0400
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h9OHhUw6007788
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Fri, 24 Oct 2003 12:43:30 -0500
Received: (from dwillis@localhost)
	by bdsl.greycouncil.com (8.12.8/8.12.8/Submit) id h9OHhU3h007786;
	Fri, 24 Oct 2003 12:43:30 -0500
X-Authentication-Warning: bdsl.greycouncil.com: dwillis set sender to dean.willis@softarmor.com using -f
Subject: RE: [Sip] Question on rfc3310 Hypertext Transfer Protocol (HTTP) 
	Digest Aut hentication Using Authentication and Key Agreement (AKA)
From: Dean Willis <dean.willis@softarmor.com>
To: Xin Chen <x.chen@fle.fujitsu.com>
Cc: "'sip@ietf.org'" <sip@ietf.org>
In-Reply-To: <E9978DD405A2D611913500047583E37A4D1AB4@fle2.fle.fujitsu.com>
References: <E9978DD405A2D611913500047583E37A4D1AB4@fle2.fle.fujitsu.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1067017409.6724.136.camel@bdsl.greycouncil.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 
Date: Fri, 24 Oct 2003 12:43:30 -0500
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 Fri, 2003-10-24 at 04:52, Xin Chen wrote:
> I think there is a problem in 3GPP to support multiple contact addresses in
> a single REGISTER. Since more likely, each contact address will be another
> terminal, however, only the terminal which initiates the REGISTER could be
> authenticated successfully and have a security association established after
> the registration. However, terminals representing other contact addresses do
> not have that SA, so if forking happens, messages to the other terminals
> will be unprotected or even dropped off in the network.

Admittedly, I haven't been to 3GPP in a while, and maybe you folks have
changed something. I suppose if people start spenidng lots of money
buying IMS systems, I'll be compelled to show up and find out . . .

But, here's how I understand it to work. 

Each mobile sends a REGISTER containing only its own Contact. Each
registration accumulates a Path, which is stored in the registrar along
with the Contact. The registration transaction sets up session keying
for a security association between the P-CSCF and the mobile, and the
P-CSCF learns (by observing the transaction) enough about the identity
of the mobile to assert the identity of the mobile on future
transactions on that security association.

Now, here's the interesting bit (and this part may have changed). The
mobile actually registers with a "private" identity, and it may request
(p-requested-identity) any one of a number of possible public identities
on future transacations. How does the P-CSCF know that the mobile is
allowed to request the given public identity, and that it (the P-CSCF)
should assert this identity on behalf of the mobile by replacing the
p-requested-identity header field with a p-asserted-identity header
field? At one time (and 3GPP may still work this way) the 200 OK in
response to the authenticated REGISTER carried a list of "allowable
public identities" associated with the privtae identity that had
registered. Both the mobile (some debate here, they may have decided to
provision this data in the mobile rather than send it between the P-CSCF
and the mobile) and the P-CSCF would store this set of public identities
in association with the security association. In a later transacation,
the mobile could reference one of these identities in a
p-requested-identity header field, and iff that identitiy was known to
the P-CSCF and associated with this security association, the P-CSCF
would replace the p-requested-identity header field with a
p-asserted-identity header field having the same value.

So, how would the mobile associate an external address-of-record with
itself? It seems that the correct procedure would be to do what would
effectively be a third-party registration, setting the mobiles'
Address-of-Record (NOT Contact) as the Contact for the foreign
Address-of-Record. By doing this, requests for the foreign AOR would be
directed toward the mobile's AOR (its serving S-CSCF), and thence to the
mobile's Contact, along the recorded Path and its associated security
association.

This begs the question of "How do we associate just this mobile's
Contact, not the mobiles AOR, with a foregin AOR?" The answer, as far as
I know, remains unresolved. I suspect a "clean" answer here will depend
on the resolution of the GRUU/device identity work in IETF.

--
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 exim@www1.ietf.org  Fri Oct 24 15:29:45 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25695
	for <sip-archive@odin.ietf.org>; Fri, 24 Oct 2003 15:29:45 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AD7ci-00073U-MH
	for sip-archive@odin.ietf.org; Fri, 24 Oct 2003 15:29:24 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OJTO7m027061
	for sip-archive@odin.ietf.org; Fri, 24 Oct 2003 15:29:24 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AD7cL-0006yw-Ol; Fri, 24 Oct 2003 15:29:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AD7bh-0006uA-CD
	for sip@optimus.ietf.org; Fri, 24 Oct 2003 15:28:21 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25642
	for <sip@ietf.org>; Fri, 24 Oct 2003 15:28:11 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AD7bg-00033g-00
	for sip@ietf.org; Fri, 24 Oct 2003 15:28:20 -0400
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AD7bf-000334-00
	for sip@ietf.org; Fri, 24 Oct 2003 15:28:19 -0400
Received: from cisco.com (171.71.177.237)
  by sj-iport-2.cisco.com with ESMTP; 24 Oct 2003 12:25:32 -0700
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9OJRkjP011436;
	Fri, 24 Oct 2003 12:27:46 -0700 (PDT)
Received: from cisco.com ([161.44.79.51])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ADL30127;
	Fri, 24 Oct 2003 15:27:45 -0400 (EDT)
Message-ID: <3F997D31.1010603@cisco.com>
Date: Fri, 24 Oct 2003 15:27:45 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Karapetkov, Stefan H" <Stefan.H.Karapetkov@icn.siemens.com>
CC: sip@ietf.org
Subject: Re: [Sip] Using domain name instead of IP address in Contact header
References: <DA2CCB2AC5F7E447B18E19D786093BB201C1CF07@stca952a.eng.sc.rolm.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



Karapetkov, Stefan H wrote:
> Hello,
> 
> RFC 3236 section 6 discusses "constructing SIP URIs" for inclusion in a 
> Contact header. The RFC talks about clients and servers, and the problem 
> that it is trying to solve concerns a proxy client trying to locate a 
> proxy server. It is not clear to me if this RFC is intended to cover the 
> case of a proxy trying to locate a UA, e.g. a SIP phone or a SIP soft 
> client.
> 
> The only reason the RFC gives for using a domain name instead of an IP 
> address is because of the possible need to use a back-up server. By 
> using the domain name the DNS server can resolve the domain name to 
> either the main server or the back-up server. However, in the case of a 
> SIP phone or SIP client, back-up does not apply.
 >
> All products we have seen at SIPit use an IP address in the Contact 
> header, not a domain name. Does anyone see value in using a domain name 
> in a SIP UA implementation instead of the currently used IP address?

Certainly there are common cases where a UA does not have a backup, and 
in those cases an IP address may be just as useful as a domain name.

BUT, there are important cases where a UA may be backed up. E.g. 
Gateways, IVRs, music-on-hold servers.

Thus it is important that domain names be supported. In a particular 
case, where it is your device and you are providing the address, you may 
elect to use an IP address. But please don't assume that others do the same.

	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 exim@www1.ietf.org  Fri Oct 24 17:34:14 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01195
	for <sip-archive@odin.ietf.org>; Fri, 24 Oct 2003 17:34:14 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AD9ZC-0007eB-Dq
	for sip-archive@odin.ietf.org; Fri, 24 Oct 2003 17:33:55 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OLXsjN029340
	for sip-archive@odin.ietf.org; Fri, 24 Oct 2003 17:33:54 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AD9YM-0007JY-14; Fri, 24 Oct 2003 17:33:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AD9Y0-0007E0-On
	for sip@optimus.ietf.org; Fri, 24 Oct 2003 17:32:40 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01140
	for <sip@ietf.org>; Fri, 24 Oct 2003 17:32:29 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AD9Xy-0004rt-00
	for sip@ietf.org; Fri, 24 Oct 2003 17:32:38 -0400
Received: from [207.253.219.211] (helo=dialexia.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AD9Xx-0004rp-00
	for sip@ietf.org; Fri, 24 Oct 2003 17:32:38 -0400
content-class: urn:content-classes:message
Date: Fri, 24 Oct 2003 17:31:59 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Message-ID: <6E568364FFE27044A3C9C2DE767D20740B616E@3wexch.dialexia.com>
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Thread-Topic: 481 Call/Transaction Does Not Exist   vs  501 Not Implemented 
Thread-Index: AcOadkFXouxz3RATT7iVIseMGObytA==
From: "Hechmi Khlifi" <hkhlifi@dialexia.com>
To: <sip@ietf.org>
Content-Transfer-Encoding: quoted-printable
Subject: [Sip] 481 Call/Transaction Does Not Exist   vs  501 Not Implemented
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: quoted-printable

Hi,
I have a question about the 481 and 501 SIP responses.=20

I want to know if i  send a SIP INFO request   to a  UA  without having =
a Dialog with him,  what will be its  response when he doesn't support =
the INFO method,=20
will it be a
481 Call/Transaction Does Not Exist=20

or=20
501 Not Implemented=20

can anyone  Help me please.

Hechmi  Khlifi=20
R&D Dept.
Dialexia Communications, Inc.=20
1755 St-Regis Boul. Suite 210=20
Dollard-des-Ormeaux, Qc=20
H9B 2M9 Canada=20
Tel: 1-514-421-5918 (X 215)=20
Fax: 1-514-421-1817=20
Email: hkhlifi@dialexia.com=20



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Fri Oct 24 18:02:05 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02191
	for <sip-archive@odin.ietf.org>; Fri, 24 Oct 2003 18:02:05 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ADA0A-0005vD-Ur
	for sip-archive@odin.ietf.org; Fri, 24 Oct 2003 18:01:47 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OM1k5r022711
	for sip-archive@odin.ietf.org; Fri, 24 Oct 2003 18:01:46 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AD9zS-0005cJ-Nf; Fri, 24 Oct 2003 18:01:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AD9yU-0005UP-VD
	for sip@optimus.ietf.org; Fri, 24 Oct 2003 18:00:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02066
	for <sip@ietf.org>; Fri, 24 Oct 2003 17:59:50 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AD9yS-0005GT-00
	for sip@ietf.org; Fri, 24 Oct 2003 18:00:00 -0400
Received: from broadsoft.com ([198.104.184.110])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AD9yR-0005GO-00
	for sip@ietf.org; Fri, 24 Oct 2003 17:59:59 -0400
Received: from tate (host4.brodsoft.com [66.160.10.4] (may be forged))
	by broadsoft.com (8.12.10/8.12.9) with SMTP id h9OLxwlf070634
	for <sip@ietf.org>; Fri, 24 Oct 2003 17:59:59 -0400 (EDT)
Reply-To: <brett@broadsoft.com>
From: "Brett Tate" <brett@broadsoft.com>
To: <sip@ietf.org>
Subject: RE: [Sip] 481 Call/Transaction Does Not Exist   vs  501 Not Implemented
Date: Fri, 24 Oct 2003 18:00:30 -0400
Message-ID: <002a01c39a7a$3e7bbc50$2b01a8c0@broadsoft.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 CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <6E568364FFE27044A3C9C2DE767D20740B616E@3wexch.dialexia.com>
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 have a question about the 481 and 
> 501 SIP responses. 
> 
> I want to know if i  send a SIP INFO request
> to a  UA without having a Dialog with him,  
> what will be its  response when he doesn't 
> support the INFO method, will it be a
> 481 Call/Transaction Does Not Exist 
> 
> or 
> 501 Not Implemented 
> 
> can anyone  Help me please.

If your INFO has a To tag,
it should be a 481; however I have 
commonly observed 501's, 415's, 400's, 
and various other responses during
interops and sipits.  This type of
problem was one reason that the Allow 
header has become mandatory.
Thus you might not want to send
INFO to check dialog state unless you 
have received an Allow indicating that 
they support it.


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Sat Oct 25 01:53:36 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13946
	for <sip-archive@odin.ietf.org>; Sat, 25 Oct 2003 01:53:36 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ADHMR-00014q-QW
	for sip-archive@odin.ietf.org; Sat, 25 Oct 2003 01:53:16 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9P5rFva004136
	for sip-archive@odin.ietf.org; Sat, 25 Oct 2003 01:53:15 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ADHMD-00013m-CA; Sat, 25 Oct 2003 01:53:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ADHLd-000119-6J
	for sip@optimus.ietf.org; Sat, 25 Oct 2003 01:52:25 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13933
	for <sip@ietf.org>; Sat, 25 Oct 2003 01:52:15 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ADHLZ-0001On-00
	for sip@ietf.org; Sat, 25 Oct 2003 01:52:21 -0400
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ADHLZ-0001Oj-00
	for sip@ietf.org; Sat, 25 Oct 2003 01:52:21 -0400
Received: from dynamicsoft.com ([63.113.46.5])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h9P5plca005276;
	Sat, 25 Oct 2003 01:51:47 -0400 (EDT)
Message-ID: <3F9A0F6F.6020005@dynamicsoft.com>
Date: Sat, 25 Oct 2003 01:51:43 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@cisco.com>
CC: sip@ietf.org
Subject: Re: [Sip] GRUU Mechanism I-D
References: <3F94E9A9.5020707@dynamicsoft.com> <3F953BD9.7040505@cisco.com> <3F95F1A2.2060107@dynamicsoft.com> <3F968FCA.1060907@cisco.com> <3F973D54.3070506@dynamicsoft.com> <3F97F0BD.6000304@cisco.com>
In-Reply-To: <3F97F0BD.6000304@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.

Paul Kyzivat wrote:


>> The problem is, if the gruu changes, the UA is going to potentially 
>> need to do a lot of work to update it across all active dialogs. There 
>> is also a period of time after which the old gruu is invalid, 
>> according to the server, but the UA has not discovered this and 
>> informed their peers in existing dialogs. During this window, any 
>> mid-dialog requests sent by the peer will fail, and that is bad.
> 
> 
> Yes. These are all good reasons to mandate that the gruu can't change 
> across refreshes.

Right.

> 
> I presume this requirement only applies across refreshes, rather than a 
> requirment that the same contact address, registered with the same AOR, 
> must always yield the same gruu???

Right. I thought about that, and I came to the conclusion that to 
require the gruu to be the same for each particular contact URI 
FOREVER was too onerous. So, its only within the context of a refresh 
interval.

> 
>>>> That said, we may need to except REFER from this rule. Bleh.
>>>
>>>
>>> If we need to exempt REFER, then we have admitted that we can't phase 
>>> out shared dialogs. Then, if we have to continue to support shared 
>>> dialogs, why do we want to tell people not to use them?
>>
>>
>> If there is no way to fix this for REFER, I would have to agree with 
>> you. However, if there is a possibility to update REFER to take 
>> advantage of gruu, and thus avoid dialog reuse, then it makes sense. 
>> AFAICT, the fix to REFER is not hard at all. The recipient of the 
>> REFER, who creates the NOTIFY, would simply send it to the gruu of the 
>> referor, and use a different dialog ID. There is still an implicit 
>> subscription, but the NOTIFY creates a new, separate dialog.
> 
> 
> There is an additional semantic when a REFER is sent within an existing 
> dialog - it has an implicit association with the other things sharing 
> that dialog. When a refer of an invite arrives in a dialog that already 
> has an invite that association can be significant.

Right. I was proposing that the REFER still go on the existing dialog, 
its just that the implicit subscription it establishes is a separate 
dialog.

> The UAS may have 
> several calls that all share the same contact address, but the dialog 
> distinguishes one of them.

Right.

> 
> That need for that could be eliminated if every call used a unique 
> contact address, perhaps by using a GRUU with a unique grid.

Uniquiness of GRUU across different dialogs is something we need to 
talk about. THe app interaction proposal I recently submitted more or 
less makes use of such a uniqueness property, and I think we want it 
as a genreal rule. However, in this one specific case, I dont think 
its needed.

> 
> I think discussion is required over whether we want to go down that 
> path, with the goal of replacing every possible use for shared dialogs. 
> The GRUU stuff can proceed without first making that decision.

Probably true, but then again if we can come to consensus on this 
together, it would facilitate implementations I think.

-Jonathan R.



-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
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 exim@www1.ietf.org  Mon Oct 27 13:28:38 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28533
	for <sip-archive@odin.ietf.org>; Mon, 27 Oct 2003 13:28:38 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEC6E-0007a5-W4
	for sip-archive@odin.ietf.org; Mon, 27 Oct 2003 13:28:18 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RISIB1029082
	for sip-archive@odin.ietf.org; Mon, 27 Oct 2003 13:28:18 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEC5y-0007XC-9I; Mon, 27 Oct 2003 13:28:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEC5X-0007V7-P5
	for sip@optimus.ietf.org; Mon, 27 Oct 2003 13:27:35 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28513
	for <sip@ietf.org>; Mon, 27 Oct 2003 13:27:24 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AEC5V-0001XT-00
	for sip@ietf.org; Mon, 27 Oct 2003 13:27:33 -0500
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AEC5V-0001XL-00
	for sip@ietf.org; Mon, 27 Oct 2003 13:27:33 -0500
Received: from cisco.com (171.71.177.238)
  by sj-iport-2.cisco.com with ESMTP; 27 Oct 2003 10:25:28 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9RIQwQa013798;
	Mon, 27 Oct 2003 10:27:01 -0800 (PST)
Received: from cisco.com ([161.44.79.51])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ADM39440;
	Mon, 27 Oct 2003 13:26:57 -0500 (EST)
Message-ID: <3F9D6371.2020404@cisco.com>
Date: Mon, 27 Oct 2003 13:26:57 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@cisco.com>
CC: sip@ietf.org
Subject: Re: [Sip] Re:draft-ietf-sip-publish-01.txt
References: <200309111850.OAA05054@ietf.org> <3F748625.3030403@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

Aki,

Just a nit:

Section 6:

    4.  The ESC SHOULD determine if the authenticated user is authorized
        to perform event state publication for the identified by the ...

s/for the identified/for the resource identified/

	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 exim@www1.ietf.org  Mon Oct 27 15:35:31 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07982
	for <sip-archive@odin.ietf.org>; Mon, 27 Oct 2003 15:35:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEE52-0006nf-1V
	for sip-archive@odin.ietf.org; Mon, 27 Oct 2003 15:35:12 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RKZBt3026081
	for sip-archive@odin.ietf.org; Mon, 27 Oct 2003 15:35:11 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEE4t-0006lc-Cy; Mon, 27 Oct 2003 15:35:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEE3t-0006gh-15
	for sip@optimus.ietf.org; Mon, 27 Oct 2003 15:34:01 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07817
	for <sip@ietf.org>; Mon, 27 Oct 2003 15:33:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AEE3r-00041i-00
	for sip@ietf.org; Mon, 27 Oct 2003 15:33:59 -0500
Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AEE3q-00041M-00
	for sip@ietf.org; Mon, 27 Oct 2003 15:33:58 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h9RKWfd22926;
	Mon, 27 Oct 2003 14:32:43 -0600
Subject: Re: [Sip] New PUBLISH draft
From: Robert Sparks <rsparks@dynamicsoft.com>
To: Aki Niemi <aki.niemi@nokia.com>
Cc: sip@ietf.org
In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D59290@esebe013.ntc.nokia.com>
References: 
	 <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D59290@esebe013.ntc.nokia.com>
Content-Type: text/plain
Message-Id: <1067286758.940.22.camel@RjS.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.4 
Date: Mon, 27 Oct 2003 14:32:39 -0600
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

This draft still has sections that use the To: header field to identify
the state being manipulated. It was my understanding that we decided to
go with the Request-URI.

RjS


On Fri, 2003-10-24 at 06:10, aki.niemi@nokia.com wrote:
> All,
> 
> I've updated the PUBLISH draft to reflect the recent discussions, as well as a number of other comments I've received. Until this appears in the I-D directories, I've placed a copy at:
> 
> http://www.saunalahti.fi/~apniem/drafts/draft-ietf-sip-publish-01.html
> http://www.saunalahti.fi/~apniem/drafts/draft-ietf-sip-publish-01.txt
> 
> I think we are pretty much ready for last call with this one, but I still think more people need to look at it either before or during LC (BTW, thanks to those who've already provided comments). 
> 
> IMO, there is one part of the draft that deserves special attention, and I'd appreciate it if people could go over the usage of etags in this draft once more. I've received very little comments on it, which can of course be a good sign. I'd like to be sure, though.  ;-)
> 
> Regards,
> Aki 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Mon Oct 27 17:13:30 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20041
	for <sip-archive@odin.ietf.org>; Mon, 27 Oct 2003 17:13:29 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEFbs-0008L1-5j
	for sip-archive@odin.ietf.org; Mon, 27 Oct 2003 17:13:12 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RMDCuT032050
	for sip-archive@odin.ietf.org; Mon, 27 Oct 2003 17:13:12 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEFau-00086R-Oo; Mon, 27 Oct 2003 17:12:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEFaA-0007qV-Sr
	for sip@optimus.ietf.org; Mon, 27 Oct 2003 17:11:26 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19593;
	Mon, 27 Oct 2003 17:11:13 -0500 (EST)
Message-Id: <200310272211.RAA19593@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: Mon, 27 Oct 2003 17:11:13 -0500
Subject: [Sip] I-D ACTION:draft-ietf-sip-publish-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.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title		: Session Initiation Protocol (SIP) Extension for Event State
                              Publication
	Author(s)	: A. Niemi
	Filename	: draft-ietf-sip-publish-01.txt
	Pages		: 35
	Date		: 2003-10-24
	
This document describes an extension to the Session Initiation
Protocol (SIP) for publishing event state used within the framework
for SIP Event Notification. The first application of this extension
is targeted at the publication of presence information.
The mechanism described in this document can be extended to support
publication of any event state, for which there exists an appropriate
event package. It is not intended to be a general-purpose mechanism
for transport of arbitrary data, as there are better-suited
mechanisms for this purpose (FTP, HTTP, etc.)

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-publish-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-ietf-sip-publish-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-ietf-sip-publish-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:	<2003-10-27171549.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-publish-01.txt

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

Content-Type: text/plain
Content-ID:	<2003-10-27171549.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 exim@www1.ietf.org  Mon Oct 27 17:40:41 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23629
	for <sip-archive@odin.ietf.org>; Mon, 27 Oct 2003 17:40:41 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEG2B-0002hI-1c
	for sip-archive@odin.ietf.org; Mon, 27 Oct 2003 17:40:23 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RMeMUC010310
	for sip-archive@odin.ietf.org; Mon, 27 Oct 2003 17:40:22 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEG1q-0002eJ-Qp; Mon, 27 Oct 2003 17:40:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEG0t-0002Zk-1g
	for sip@optimus.ietf.org; Mon, 27 Oct 2003 17:39:03 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23418
	for <sip@ietf.org>; Mon, 27 Oct 2003 17:38:50 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AEG0q-0000Z2-00
	for sip@ietf.org; Mon, 27 Oct 2003 17:39:00 -0500
Received: from magus.nostrum.com ([208.21.192.130] ident=root)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AEG0p-0000Yz-00
	for sip@ietf.org; Mon, 27 Oct 2003 17:38:59 -0500
Received: from dynamicsoft.com (ben@localhost [127.0.0.1])
	by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9RMceF8067251;
	Mon, 27 Oct 2003 16:38:51 -0600 (CST)
	(envelope-from bcampbell@dynamicsoft.com)
Message-ID: <3F9D9E4D.2040602@dynamicsoft.com>
Date: Mon, 27 Oct 2003 16:38:05 -0600
From: Ben Campbell <bcampbell@dynamicsoft.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Aki Niemi <aki.niemi@nokia.com>
CC: sip@ietf.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Comments on publish-01
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 some comments on publish-01. These are not necessarily specific 
to 01 changes--I apologize if I bring up old concerns again, or mention 
something now that I should have mentioned previously.


Thanks!

Ben.

--------------------------------------------------------------

4.3: Why do we require all publish packages to support partial 
publication? This seems more a presence requirement than a generic 
publish requirement.

4.4: Why do we need to specify default expiration times? Why is this not 
just local policy of the ESC?

5 (last paragraph): I _think_ the intent is to say you should not send a 
new request to a particular ESC when a previous one is pending for the 
_same_ ESC, correct? This seems to be the spirit of the text, but there 
is room for someone to interpret this to say that I cannot send a new 
publish to any ESC if I have not gotten a response from a particular ESC.

5.2 Paragraph 1: Still says To header indicates the AoR. I am pretty 
sure we had consensus in SIMPLE that this should be the r-URI. (Although 
I recognize we have had a new controversy on the SIP list about this.)

Paragraph 2: Can it _ever_ be carried anywhere else? If not, we should 
drop the word "typically"

5.3: This seems to conflict with the meaning of 4.4. Nothing is 
mentioned in 5.3 about a default expiration.

5.4 para 5, 1st sentence:

"The If-Match header field containing an entity-tag preconditions the 
PUBLISH request to refresh a specific instance of event state in the 
ESC." Sentence is confusing to me. Are we using the word "preconditions" 
as a verb?

Same paragraph: Nit: I suspect that "i.e." (which translates as "that 
is", really should mean "for example", as there are other situations 
other than expired state that could cause this result. (For example, the 
state never existed at all.)

Last paragraph: I think this should be MUST NOT. Doesn't the presence of 
a body explicily make this into a modify request, instead of a refresh?

5.7 First paragraph: Should use r-uri, not To header.

6 step 8 last para: Do we want to limit this to explictly 500? In the 
example you give, it may be that 504 makes more sense.

Table 1: Accept explicitly disallowed in requests? What if a future 
publish package uses bodies in responses? Would it not make sense to 
allow Accept in the request for such a package?

Security Considerations: Do we need to comment on the interaction 
between PUBLISH and the possibility of e2e signatures on presence 
documents? I don't know if that belongs here or not.




_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Tue Oct 28 05:35:45 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14788
	for <sip-archive@odin.ietf.org>; Tue, 28 Oct 2003 05:35:45 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AERCB-0000S6-G7
	for sip-archive@odin.ietf.org; Tue, 28 Oct 2003 05:35:27 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SAZRuO001738
	for sip-archive@odin.ietf.org; Tue, 28 Oct 2003 05:35:27 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AERBm-0000PG-PD; Tue, 28 Oct 2003 05:35:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AERBB-0000Lx-Uh
	for sip@optimus.ietf.org; Tue, 28 Oct 2003 05:34:25 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14709
	for <sip@ietf.org>; Tue, 28 Oct 2003 05:34:13 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AERB8-0007VM-00
	for sip@ietf.org; Tue, 28 Oct 2003 05:34:22 -0500
Received: from [202.97.224.98] (helo=mail.hl.cn)
	by ietf-mx with smtp (Exim 4.12)
	id 1AERB7-0007VB-00
	for sip@ietf.org; Tue, 28 Oct 2003 05:34:21 -0500
Received: from mail.hl.cn([127.0.0.1]) by mail.hl.cn(AIMC 2.9.5.6)
	with SMTP id jm43f9ea560; Tue, 28 Oct 2003 18:23:02 +0800
Received: from asgard.ietf.org([132.151.6.40]) by mail.hl.cn(AIMC 2.9.5.6)
	with SMTP id jm3c3f996789; Sat, 25 Oct 2003 00:22:27 +0800
Received: from majordomo by asgard.ietf.org with local (Exim 4.14)
	id 1AD3kO-0007Oq-KQ
	for ietf-announce-list@asgard.ietf.org; Fri, 24 Oct 2003 11:21:04 -0400
Received: from ietf.org ([10.27.2.28])
	by asgard.ietf.org with esmtp (Exim 4.14)
	id 1AD3IK-0007ur-7b
	for all-ietf@asgard.ietf.org; Fri, 24 Oct 2003 10:52:04 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05496;
	Fri, 24 Oct 2003 10:51:53 -0400 (EDT)
Message-Id: <200310241451.KAA05496@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, 24 Oct 2003 10:51:52 -0400
Precedence: bulk
X-AIMC-AUTH: (null)
X-AIMC-MAILFROM: owner-ietf-announce@ietf.org
X-AIMC-AUTH: (null)
X-AIMC-MAILFROM: Internet-Drafts@ietf.org
Subject: [Sip] I-D ACTION:draft-ietf-sip-callerprefs-10.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
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		: Caller Preferences for the Session Initiation Protocol (SIP)
	Author(s)	: J. Rosenberg, H. Schulzrinne, P. Kyzivat
	Filename	: draft-ietf-sip-callerprefs-10.txt
	Pages		: 33
	Date		: 2003-10-23
	
This document describes a set of extensions to the Session Initiation
Protocol (SIP) which allow a caller to express preferences about
request handling in servers. These preferences include the ability to
select which URIs a request gets routed to, and to specify certain
request handling directives in proxies and redirect servers. It does
so by defining four new request headers, Accept-Contact, Reject-
Contact, Require-Contact and Request-Disposition, which specify the
caller's preferences. The extension also defines new parameters for
the Contact header that describe the capabilities and characteristics
of a UA.

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-callerprefs-10.txt

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

Content-Type: text/plain
Content-ID:	<2003-10-24103933.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 exim@www1.ietf.org  Tue Oct 28 15:46:59 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25888
	for <sip-archive@odin.ietf.org>; Tue, 28 Oct 2003 15:46:57 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEaje-0001yH-BH
	for sip-archive@odin.ietf.org; Tue, 28 Oct 2003 15:46:38 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SKkcON007503
	for sip-archive@odin.ietf.org; Tue, 28 Oct 2003 15:46:38 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEaj7-0001cV-NN; Tue, 28 Oct 2003 15:46:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEaig-0001T1-Ao
	for sip@optimus.ietf.org; Tue, 28 Oct 2003 15:45:38 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25648;
	Tue, 28 Oct 2003 15:45:26 -0500 (EST)
Message-Id: <200310282045.PAA25648@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, 28 Oct 2003 15:45:26 -0500
Subject: [Sip] I-D ACTION:draft-ietf-sip-guidelines-07.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		: Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP)
	Author(s)	: J. Rosenberg
	Filename	: draft-ietf-sip-guidelines-07.txt
	Pages		: 28
	Date		: 2003-10-28
	
The Session Initiation Protocol (SIP) is a flexible, yet simple tool
for establishing interactive connections across the Internet. Part of
this flexibility is the ease with which it can be extended. In order
to facilitate effective and interoperable extensions to SIP, some
guidelines need to be followed when developing SIP extensions. This
document outlines a set of such guidelines for authors of SIP
extensions.

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-guidelines-07.txt

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

Content-Type: text/plain
Content-ID:	<2003-10-28160111.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 exim@www1.ietf.org  Wed Oct 29 04:47:40 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00534
	for <sip-archive@odin.ietf.org>; Wed, 29 Oct 2003 04:47:40 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEmvA-0001i2-Sl
	for sip-archive@odin.ietf.org; Wed, 29 Oct 2003 04:47:20 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9T9lK9m006511
	for sip-archive@odin.ietf.org; Wed, 29 Oct 2003 04:47:20 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEmur-0001eJ-No; Wed, 29 Oct 2003 04:47:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEmts-0001aU-Qx
	for sip@optimus.ietf.org; Wed, 29 Oct 2003 04:46:00 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00461
	for <sip@ietf.org>; Wed, 29 Oct 2003 04:45:49 -0500 (EST)
From: aki.niemi@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AEmtp-000591-00
	for sip@ietf.org; Wed, 29 Oct 2003 04:45:57 -0500
Received: from mgw-x1.nokia.com ([131.228.20.21])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AEmto-00058x-00
	for sip@ietf.org; Wed, 29 Oct 2003 04:45:56 -0500
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9T9jsP07181
	for <sip@ietf.org>; Wed, 29 Oct 2003 11:45:54 +0200 (EET)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T659412b984ac158f258f8@esvir05nok.ntc.nokia.com>;
 Wed, 29 Oct 2003 11:45:52 +0200
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747);
	 Wed, 29 Oct 2003 11:45:51 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Re:draft-ietf-sip-publish-01.txt
Date: Wed, 29 Oct 2003 11:45:50 +0200
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D90E2@esebe013.ntc.nokia.com>
Thread-Topic: [Sip] Re:draft-ietf-sip-publish-01.txt
Thread-Index: AcOcuDY9LNL8e7RaSSWSXhJ+ptwqwwBSSnmw
To: <pkyzivat@cisco.com>
Cc: <sip@ietf.org>
X-OriginalArrivalTime: 29 Oct 2003 09:45:51.0728 (UTC) FILETIME=[70920700:01C39E01]
Content-Transfer-Encoding: quoted-printable
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: quoted-printable

Thanks, added.

Aki

 > -----Original Message-----
 > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of ext
 > Paul Kyzivat
 > Sent: 27 October, 2003 20:27
 > To: Paul Kyzivat
 > Cc: sip@ietf.org
 > Subject: Re: [Sip] Re:draft-ietf-sip-publish-01.txt
 >=20
 >=20
 > Aki,
 >=20
 > Just a nit:
 >=20
 > Section 6:
 >=20
 >     4.  The ESC SHOULD determine if the authenticated user=20
 > is authorized
 >         to perform event state publication for the=20
 > identified by the ...
 >=20
 > s/for the identified/for the resource identified/
 >=20
 > 	Paul
 >=20
 >=20
 > _______________________________________________
 > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
 > This list is for NEW development of the core SIP Protocol
 > Use sip-implementors@cs.columbia.edu for questions on current sip
 > Use sipping@ietf.org for new developments on the application of sip
 >=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Wed Oct 29 04:50:31 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00755
	for <sip-archive@odin.ietf.org>; Wed, 29 Oct 2003 04:50:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEmxv-0002Ae-Uz
	for sip-archive@odin.ietf.org; Wed, 29 Oct 2003 04:50:12 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9T9oBUH008287
	for sip-archive@odin.ietf.org; Wed, 29 Oct 2003 04:50:11 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEmxn-00024n-5T; Wed, 29 Oct 2003 04:50:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEmws-000219-OE
	for sip@optimus.ietf.org; Wed, 29 Oct 2003 04:49:06 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00639
	for <sip@ietf.org>; Wed, 29 Oct 2003 04:48:55 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AEmwp-0005C2-00
	for sip@ietf.org; Wed, 29 Oct 2003 04:49:03 -0500
Received: from [80.74.106.10] (helo=nt-mail.radvision.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AEmwo-0005Bz-00
	for sip@ietf.org; Wed, 29 Oct 2003 04:49:03 -0500
Received: from nt-mail.tlv.radvision.com [172.20.2.100]
	by nt-mail.radvision.com
	with XWall v3.26 ;
	Wed, 29 Oct 2003 11:48:20 +0200
Received: by nt-mail.tlv.radvision.com with Internet Mail Service (5.5.2653.19)
	id <4DPLYN1Y>; Wed, 29 Oct 2003 11:48:20 +0200
Message-ID: <99FF181D4C99564F8D623069E1DDB25E22A8E6@nt-mail.tlv.radvision.com>
From: Ofra Wachsman <Ofra@radvision.com>
To: sip@ietf.org
Cc: "'rsparks@dynamicsoft.com'" <rsparks@dynamicsoft.com>
Date: Wed, 29 Oct 2003 11:48:19 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="windows-1255"
Subject: [Sip] when to stop sending NOTIFY about a REFER progress
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.
My question is when to stop sending NOTIFY about a refer progress.
lf a call-leg was created because of a refer request, it sends the INVITE
request, and for every incoming response a NOTIFY request should be sent to
the referrer until receiving a final response. 
The question is what counts as a final response? 3xx or 401/407 are final
responses or not? 
Since we might still receive 200 response, after receiving 401 we may not
send NOTIFY with 401 indication, and send NOTIFY when the 200 will be
received.

> Best Wishes
> 
> Ofra 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Wed Oct 29 10:22:36 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12567
	for <sip-archive@odin.ietf.org>; Wed, 29 Oct 2003 10:22:35 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEs9J-0003Vc-3O
	for sip-archive@odin.ietf.org; Wed, 29 Oct 2003 10:22:17 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TFMHc6013431
	for sip-archive@odin.ietf.org; Wed, 29 Oct 2003 10:22:17 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEs95-0003Pe-9l; Wed, 29 Oct 2003 10:22:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEs8U-0003KR-Ns
	for sip@optimus.ietf.org; Wed, 29 Oct 2003 10:21:26 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12546;
	Wed, 29 Oct 2003 10:21:14 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AEs8S-0002Ru-00; Wed, 29 Oct 2003 10:21:24 -0500
Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AEs8R-0002Rh-00; Wed, 29 Oct 2003 10:21:23 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h9TFKqd07162;
	Wed, 29 Oct 2003 09:20:52 -0600
From: Robert Sparks <rsparks@dynamicsoft.com>
To: simple@ietf.org, sip-implementors@cs.columbia.edu, sip@ietf.org
In-Reply-To: <1063221430.882.190.camel@RjS.localdomain>
References: <1063221430.882.190.camel@RjS.localdomain>
Content-Type: text/plain
Message-Id: <1067440852.1005.18.camel@RjS.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.4 
Date: Wed, 29 Oct 2003 09:20:53 -0600
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Re: SIMPLEt 2
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

SIMPLEt 2 registration closes in about two weeks.

If you have not already registered, please do so now.

If you plan to register, but for some reason have to wait
until the last minute, please send me a note letting me know
you are planning to attend.

Registration information can be found at
http://simplet.jasomi.com

Thanks!

RjS




_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Wed Oct 29 10:23:29 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12619
	for <sip-archive@odin.ietf.org>; Wed, 29 Oct 2003 10:23:29 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEsAA-0003vS-VH
	for sip-archive@odin.ietf.org; Wed, 29 Oct 2003 10:23:10 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TFNAC6015090
	for sip-archive@odin.ietf.org; Wed, 29 Oct 2003 10:23:10 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEsA3-0003on-Vp; Wed, 29 Oct 2003 10:23:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEs9u-0003iA-0T
	for sip@optimus.ietf.org; Wed, 29 Oct 2003 10:22:54 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12589
	for <sip@ietf.org>; Wed, 29 Oct 2003 10:22:42 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AEs9r-0002Sz-00
	for sip@ietf.org; Wed, 29 Oct 2003 10:22:51 -0500
Received: from [202.144.91.188] (helo=ipgen-india.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AEs9o-0002So-00
	for sip@ietf.org; Wed, 29 Oct 2003 10:22:51 -0500
Received: from pop3.sify.net [202.144.76.11] by ipgen-india.com []
	with DomainPOP (MDaemon.PRO.v5.0.7.R)
	for <sip@ietf.org>; Wed, 29 Oct 2003 20:58:31 +0530
Delivered-To: ipgen-india.com-sunku@ipgen-india.com
X-Filter: xFilter/SifyMail - No Filter defined (http://mail.sify.com)
Received: (sifymail 16972 invoked by uid 7010); Wed Oct 29 20:45:44 2003
Received: (sifymail 16970 invoked by uid 7010); 29 Oct 2003 20:45:44 +0530
Received: from 202.144.76.19 (HELO WMRP01.maa.sify.net) (202.144.76.19)
  by 202.144.76.11 with SMTP; 29 Oct 2003 20:45:44 +0530
Received: (sifymail 22254 invoked by uid 7005); 29 Oct 2003 20:45:44 +0530
Received: from 202.144.76.19 (HELO WMRP01.maa.sify.net) (202.144.76.19)
  by 202.144.76.19 with SMTP; 29 Oct 2003 20:45:44 +0530
Received: (sifymail 22248 invoked by uid 7005); 29 Oct 2003 20:45:44 +0530
Received: from 128.59.16.73 (HELO rogue.cs.columbia.edu) (128.59.16.73)
  by 202.144.76.19 with SMTP; 29 Oct 2003 20:45:44 +0530
Received: from cs.columbia.edu ([128.59.16.20])
	by rogue.cs.columbia.edu with esmtp (Exim 4.12)
	id 1AEs8h-0003wV-03; Wed, 29 Oct 2003 10:21:39 -0500
Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com ([63.110.3.64])
	by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id h9TFLTLZ017021
	for <sip-implementors@cs.columbia.edu>;
	Wed, 29 Oct 2003 10:21:29 -0500 (EST)
Received: from localhost (localhost.localdomain [127.0.0.1])
	id h9TFKqd07162;	Wed, 29 Oct 2003 09:20:52 -0600
From: Robert Sparks <rsparks@dynamicsoft.com>
To: simple@ietf.org, sip-implementors@cs.columbia.edu, sip@ietf.org
In-Reply-To: <1063221430.882.190.camel@RjS.localdomain>
References: <1063221430.882.190.camel@RjS.localdomain>
Content-Type: text/plain
Message-Id: <1067440852.1005.18.camel@RjS.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.4 
Date: Wed, 29 Oct 2003 09:20:53 -0600
Content-Transfer-Encoding: 7bit
X-BeenThere: sip-implementors@cs.columbia.edu
X-Mailman-Version: 2.1.1
Precedence: list
X-Spam-Rating: 202.144.76.19 1.33 0/0/N
X-Spam-Rating: 202.144.76.19 1.33 0/0/N
X-Spam-Rating: 202.144.76.11 1.33 0/0/N
X-MDRemoteIP: 202.144.76.11
X-MDRcpt-To: sip@ietf.org
X-MDaemon-Deliver-To: sip@ietf.org
Content-Transfer-Encoding: 7bit
Subject: [Sip] [Sip-implementors] Re: SIMPLEt 2
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
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

SIMPLEt 2 registration closes in about two weeks.

If you have not already registered, please do so now.

If you plan to register, but for some reason have to wait
until the last minute, please send me a note letting me know
you are planning to attend.

Registration information can be found at
http://simplet.jasomi.com

Thanks!

RjS



_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Wed Oct 29 11:49:00 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18501
	for <sip-archive@odin.ietf.org>; Wed, 29 Oct 2003 11:49:00 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEtUs-000789-Ao
	for sip-archive@odin.ietf.org; Wed, 29 Oct 2003 11:48:40 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TGmcDH027352
	for sip-archive@odin.ietf.org; Wed, 29 Oct 2003 11:48:38 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEtUJ-0006nG-Qh; Wed, 29 Oct 2003 11:48:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEtU7-0006jH-W8
	for sip@optimus.ietf.org; Wed, 29 Oct 2003 11:47:52 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18413
	for <sip@ietf.org>; Wed, 29 Oct 2003 11:47:40 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AEtU6-0004ja-00
	for sip@ietf.org; Wed, 29 Oct 2003 11:47:50 -0500
Received: from [216.90.186.146] (helo=mail.ipnetfusion.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AEtU6-0004jX-00
	for sip@ietf.org; Wed, 29 Oct 2003 11:47:50 -0500
Received: from ipnetfusion.com (pc223 [192.1.2.223])
	(authenticated)
	by mail.ipnetfusion.com (8.11.6/8.11.6) with ESMTP id h9TGlnM10687;
	Wed, 29 Oct 2003 10:47:49 -0600
Message-ID: <3F9FEF36.6050709@ipnetfusion.com>
Date: Wed, 29 Oct 2003 10:47:50 -0600
From: cthakker <cthakker@ipnetfusion.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: sip@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] IP Address vs Domain name in the from 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>
Content-Transfer-Encoding: 7bit

Hi,
 We are testing out a SIP proxy which can accept requests from a SIP 
gateway or SIP endpoints.
 Should the INVITE sent by the SIP gateway be any different from the one 
sent by SIP endpoints ? (It seems that the proxy accepts requests from a 
gateway only if the from header is of the form - <sip:caller@SUT_IP> and 
it accepts requests from end points only if it is of the form 
<sip:caller@remote_id:port>) Is this behaviour valid ?
 Is there any document that explains how a gateway may modify the 
request before forwarding it to the SIP Proxy ?

 Thank you in advance,

 Chintan
 ipNetFusion Inc,
 Dallas TX


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Thu Oct 30 03:36:42 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13887
	for <sip-archive@odin.ietf.org>; Thu, 30 Oct 2003 03:36:42 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AF8I1-0006fA-H6
	for sip-archive@odin.ietf.org; Thu, 30 Oct 2003 03:36:22 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9U8aL03025556
	for sip-archive@odin.ietf.org; Thu, 30 Oct 2003 03:36:21 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AF8Hj-0006cS-Nk; Thu, 30 Oct 2003 03:36:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AF8Gx-0006af-Ey
	for sip@optimus.ietf.org; Thu, 30 Oct 2003 03:35:15 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13816
	for <sip@ietf.org>; Thu, 30 Oct 2003 03:35:05 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AF8Gu-0007SG-00
	for sip@ietf.org; Thu, 30 Oct 2003 03:35:12 -0500
Received: from [212.91.166.210] (helo=mail.batmbg.com)
	by ietf-mx with smtp (Exim 4.12)
	id 1AF8Gi-0007RH-00
	for sip@ietf.org; Thu, 30 Oct 2003 03:35:11 -0500
Received: (qmail 20449 invoked from network); 30 Oct 2003 08:51:08 -0000
Received: from dune.batmbg.com (192.168.0.15)
  by mars.batmbg.com with SMTP; 30 Oct 2003 08:51:08 -0000
Date: Thu, 30 Oct 2003 10:33:56 +0200
From: George Petrov Georgiev-Rusiichev <george_r@batmbg.com>
X-Mailer: The Bat! (v2.00.6)
Reply-To: George Petrov Georgiev-Rusiichev <george_r@batmbg.com>
Organization: BATM Advanced Communications
X-Priority: 3 (Normal)
Message-ID: <45141189049.20031030103356@batmbg.com>
To: sip@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] question about 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>
Content-Transfer-Encoding: 7bit

Hi all
  I'm not sure that hare is the most appropriate place to ask this
  question, but is there anybody who can give me an idea whether Contact: header
  could exist as a multiple header field rows. In RFC3261 is
  written :

Multiple header field rows with the same field-name MAY be present in
   a message if and only if the entire field-value for that header field
   is defined as a comma-separated list (that is, if follows the grammar
   defined in Section 7.3).  

 And the grammar for Contact: is

Contact        =  ("Contact" / "m" ) HCOLON
                  ( STAR / (contact-param *(COMMA contact-param)))

 which doesn't match
                  
header  =  "header-name" HCOLON header-value *(COMMA header-value)
  
The problem is that there are many servers that puts Contact: in multiple header
field rows e.g. SIP Express router (SER)

-- 
 George                          mailto:george_r@batmbg.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 exim@www1.ietf.org  Thu Oct 30 04:04:39 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14443
	for <sip-archive@odin.ietf.org>; Thu, 30 Oct 2003 04:04:39 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AF8j4-0001aP-EQ
	for sip-archive@odin.ietf.org; Thu, 30 Oct 2003 04:04:18 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9U94IqA006031
	for sip-archive@odin.ietf.org; Thu, 30 Oct 2003 04:04:18 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AF8ip-0001Xd-Cf; Thu, 30 Oct 2003 04:04:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEqUl-00051w-PJ
	for sip@optimus.ietf.org; Wed, 29 Oct 2003 08:36:19 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06863
	for <sip@ietf.org>; Wed, 29 Oct 2003 08:36:09 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AEqUk-0000hh-00
	for sip@ietf.org; Wed, 29 Oct 2003 08:36:18 -0500
Received: from mxout.iskon.hr ([213.191.128.10] ident=qmailr)
	by ietf-mx with smtp (Exim 4.12)
	id 1AEqUj-0000hY-00
	for sip@ietf.org; Wed, 29 Oct 2003 08:36:17 -0500
Received: (qmail 29112 invoked from network); 29 Oct 2003 14:36:05 +0100
Received: from webmail1.iskon.hr (HELO net.hr) (213.191.133.144)
  by mxout.iskon.hr with SMTP; 29 Oct 2003 14:36:05 +0100
Received: from net.hr ([213.191.133.144]) by net.hr ; Wed, 29 Oct 2003 14:36:04 +0100
From: "Damir Bilajbegovi=?ISO-8859-2?B?5g==?=" <bilaj@net.hr>
Reply-to: bilaj@net.hr
To: sip@ietf.org
Date: Wed, 29 Oct 2003 14:36:04 +0100
Message-id: <3f9fc244.301.0@net.hr>
X-User-Info: 193.81.246.12
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: 7bit
X-Rcpt-To: <sip@ietf.org>
Content-Transfer-Encoding: 7bit
Subject: [Sip] IP version in SDP
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 there is IPv6 address in the SDP (in field c:) in SIP client which
understands only Ipv4, will he discard the message, or just ignore and
procede further on.
    Thanks in advance. 
          Damir Bilajbegovic

--
Trebate bolji pristup internetu?
Nazovite IskonInternet na 0800 1000 ili pogledajte
http://www.iskon.biz/individualni/usluge/dialup/

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Thu Oct 30 05:03:42 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15737
	for <sip-archive@odin.ietf.org>; Thu, 30 Oct 2003 05:03:41 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AF9eC-0007PU-65
	for sip-archive@odin.ietf.org; Thu, 30 Oct 2003 05:03:20 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UA3KhZ028410
	for sip-archive@odin.ietf.org; Thu, 30 Oct 2003 05:03:20 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AF9dw-0007LO-5z; Thu, 30 Oct 2003 05:03:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AF9dB-0007HJ-G3
	for sip@optimus.ietf.org; Thu, 30 Oct 2003 05:02:17 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15717
	for <sip@ietf.org>; Thu, 30 Oct 2003 05:02:06 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AF9d7-0000b5-00
	for sip@ietf.org; Thu, 30 Oct 2003 05:02:13 -0500
Received: from tcen-ul-mailsv01.telkom.co.za ([198.54.206.131] ident=root)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AF9d6-0000aw-00
	for sip@ietf.org; Thu, 30 Oct 2003 05:02:12 -0500
Received: from CNTRRA20-GTW01.telkom.co.za (cntrra20-gtw01.telkom.co.za [165.143.130.156])
	by tcen-ul-mailsv01.telkom.co.za (8.11.2/8.11.2/2002061301) with ESMTP id h9UA2A209535
	for <sip@ietf.org>; Thu, 30 Oct 2003 12:02:10 +0200
Received: from CNTRRA20-XS01.telkom.co.za ([165.143.130.229]) by 165.143.130.156 with InterScan Messaging Security Suite; Thu, 30 Oct 2003 12:02:10 +0200
Received: from CNTRRA20-XS11.telkom.co.za ([165.143.131.216]) by CNTRRA20-XS01.telkom.co.za with Microsoft SMTPSVC(5.0.2195.6713);
	 Thu, 30 Oct 2003 12:02:11 +0200
Received: from PRTRRA06-XS11.telkom.co.za ([165.144.220.121]) by CNTRRA20-XS11.telkom.co.za with Microsoft SMTPSVC(5.0.2195.6713);
	 Thu, 30 Oct 2003 12:02:10 +0200
Received: from prtrra06-xcs00.telkom.co.za ([165.144.220.77]) by PRTRRA06-XS11.telkom.co.za with Microsoft SMTPSVC(5.0.2195.5329);
	 Thu, 30 Oct 2003 12:02:09 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6344.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 30 Oct 2003 12:02:08 +0200
Message-ID: <D089FB6CAAD809488347065A686340254F646A@PRTRRA06-XCS00.telkom.co.za>
Thread-Topic: Basic question
Thread-Index: AcOezNuLPafID6N5TkSvST3bloXOYw==
From: "Rupert Kruger (RC)" <Krugerrc@telkom.co.za>
To: <sip@ietf.org>
X-OriginalArrivalTime: 30 Oct 2003 10:02:09.0325 (UTC) FILETIME=[E1AD3DD0:01C39ECC]
Content-Transfer-Encoding: quoted-printable
Subject: [Sip] Basic 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: quoted-printable

Hi,

I'm fairly new to SIP, and need help: For multipoint video
conferencing, in H.323, one had the MCU that registers with the
gatekeeper. But for SIP, there are only three basic servers: Proxy,
Redirect, and Registrar - so I cannot see where a SIP "MCU" would come
in. Will it be some sort of server, or a UA that has multiple
connections? What does the architecture look like for a conference
with 3 or more SIP end-users?

Any help would be greatly appreciated.

Rupert Kruger

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Thu Oct 30 10:51:39 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27832
	for <sip-archive@odin.ietf.org>; Thu, 30 Oct 2003 10:51:39 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFF4y-0003rz-Nm
	for sip-archive@odin.ietf.org; Thu, 30 Oct 2003 10:51:21 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UFpKbK014817
	for sip-archive@odin.ietf.org; Thu, 30 Oct 2003 10:51:20 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFF4h-0003gJ-4R; Thu, 30 Oct 2003 10:51:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFF46-0003b3-9l
	for sip@optimus.ietf.org; Thu, 30 Oct 2003 10:50:26 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27736
	for <sip@ietf.org>; Thu, 30 Oct 2003 10:50:14 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AFF43-0005HF-00
	for sip@ietf.org; Thu, 30 Oct 2003 10:50:23 -0500
Received: from vtg-um-e2k1.cisco.com ([171.70.93.55] helo=vtg-um-e2k1.sj21ad.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AFF43-0005GM-00
	for sip@ietf.org; Thu, 30 Oct 2003 10:50:23 -0500
Received: from cisco.com ([128.107.140.110]) by vtg-um-e2k1.sj21ad.cisco.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Thu, 30 Oct 2003 07:48:32 -0800
Message-ID: <3FA1331A.8030706@cisco.com>
Date: Thu, 30 Oct 2003 07:49:46 -0800
From: Charles Eckel <eckelcu@cisco.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: George Petrov Georgiev-Rusiichev <george_r@batmbg.com>
CC: sip@ietf.org
Subject: Re: [Sip] question about Contact  header
References: <45141189049.20031030103356@batmbg.com>
In-Reply-To: <45141189049.20031030103356@batmbg.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 30 Oct 2003 15:48:32.0171 (UTC) FILETIME=[4537DFB0:01C39EFD]
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 George,

Yes. The following are both valid:

Contact: <sip:alice1@atlanta.com>
Contact: <sip:alice2@atlanta.com>

and

Contact: <sip:alice1@atlanta.com>,<sip:alice2@atlanta.com>

Cheers,
Charles


George Petrov Georgiev-Rusiichev wrote:
> Hi all
>   I'm not sure that hare is the most appropriate place to ask this
>   question, but is there anybody who can give me an idea whether Contact: header
>   could exist as a multiple header field rows. In RFC3261 is
>   written :
> 
> Multiple header field rows with the same field-name MAY be present in
>    a message if and only if the entire field-value for that header field
>    is defined as a comma-separated list (that is, if follows the grammar
>    defined in Section 7.3).  
> 
>  And the grammar for Contact: is
> 
> Contact        =  ("Contact" / "m" ) HCOLON
>                   ( STAR / (contact-param *(COMMA contact-param)))
> 
>  which doesn't match
>                   
> header  =  "header-name" HCOLON header-value *(COMMA header-value)
>   
> The problem is that there are many servers that puts Contact: in multiple header
> field rows e.g. SIP Express router (SER)
> 


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Thu Oct 30 14:24:32 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05633
	for <sip-archive@odin.ietf.org>; Thu, 30 Oct 2003 14:24:32 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFIOy-0008Ce-Ts
	for sip-archive@odin.ietf.org; Thu, 30 Oct 2003 14:24:12 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UJOCxu031474
	for sip-archive@odin.ietf.org; Thu, 30 Oct 2003 14:24:12 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFIOp-00085D-1f; Thu, 30 Oct 2003 14:24:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFIOk-00083U-2z
	for sip@optimus.ietf.org; Thu, 30 Oct 2003 14:23:58 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05567;
	Thu, 30 Oct 2003 14:23:46 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AFIOh-0000T2-00; Thu, 30 Oct 2003 14:23:55 -0500
Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AFIOg-0000Si-00; Thu, 30 Oct 2003 14:23:54 -0500
Received: from txdwillis (bdsl.66.12.12.254.gte.net [66.12.12.254])
	(authenticated bits=0)
	by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h9UJNNw5022641
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO);
	Thu, 30 Oct 2003 13:23:23 -0600
From: "Dean Willis" <dwillis@dynamicsoft.com>
To: <sip@ietf.org>, <sipping@ietf.org>, <simple@ietf.org>, <xcon@ietf.org>,
        <iptel@ietf.org>
Date: Thu, 30 Oct 2003 13:23:04 -0600
Message-ID: <002201c39f1b$3dc54e20$e1036e3f@txdwillis>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 7bit
Subject: [Sip] Maintenance on softarmor web site Thursday 30Oct2003
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


1:30 PM USCST

The main server (www.softarmor.com) will be down for the next few hours
while I replace the OS.

In the interim, if you need web content, it's available at
http://kevlar.softarmor.com/

Anybody using the main box as a relay for email will also be affected.

Cheers,

--
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 exim@www1.ietf.org  Fri Oct 31 01:00:53 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00472
	for <sip-archive@odin.ietf.org>; Fri, 31 Oct 2003 01:00:53 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFSKn-0002r2-7b
	for sip-archive@odin.ietf.org; Fri, 31 Oct 2003 01:00:33 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9V60X7S010913
	for sip-archive@odin.ietf.org; Fri, 31 Oct 2003 01:00:33 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFSKO-0002kI-91; Fri, 31 Oct 2003 01:00:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFSJS-0002cU-Bv
	for sip@optimus.ietf.org; Fri, 31 Oct 2003 00:59:10 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00358;
	Fri, 31 Oct 2003 00:58:57 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AFSJO-0001Uo-00; Fri, 31 Oct 2003 00:59:06 -0500
Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AFSJO-0001Ul-00; Fri, 31 Oct 2003 00:59:06 -0500
Received: from softarmor.com (c-24-1-178-197.client.comcast.net [24.1.178.197])
	(authenticated bits=0)
	by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h9V5x2v4007287
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 30 Oct 2003 23:59:03 -0600
Message-ID: <3FA1FA2A.6040003@softarmor.com>
Date: Thu, 30 Oct 2003 23:59:06 -0600
From: Dean Willis <dean.willis@softarmor.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: sip@ietf.org, sipping@ietf.org, simple@ietf.org, xcon@ietf.org,
        iptel@ietf.org
Subject: Re: [Sip] Maintenance on softarmor web site Thursday 30Oct2003
References: <002201c39f1b$3dc54e20$e1036e3f@txdwillis>
In-Reply-To: <002201c39f1b$3dc54e20$e1036e3f@txdwillis>
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:
> 1:30 PM USCST
> 
> The main server (www.softarmor.com) will be down for the next few hours
> while I replace the OS.
> 
> In the interim, if you need web content, it's available at
> http://kevlar.softarmor.com/
> 
> Anybody using the main box as a relay for email will also be affected.
> 
> Cheers,
> 
> --
> Dean

Everything should be back in working order, I think. Maybe. Note that 
everything has been rekeyed.

--
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 exim@www1.ietf.org  Fri Oct 31 10:08:57 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01820
	for <sip-archive@odin.ietf.org>; Fri, 31 Oct 2003 10:08:57 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFatD-0001Hx-Vx
	for sip-archive@odin.ietf.org; Fri, 31 Oct 2003 10:08:40 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9VF8dtB004895
	for sip-archive@odin.ietf.org; Fri, 31 Oct 2003 10:08:39 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFard-0000sE-On; Fri, 31 Oct 2003 10:07:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFaqf-0000hA-Lu
	for sip@optimus.ietf.org; Fri, 31 Oct 2003 10:06:01 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01362
	for <sip@ietf.org>; Fri, 31 Oct 2003 10:05:48 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AFaqd-0001KP-00
	for sip@ietf.org; Fri, 31 Oct 2003 10:05:59 -0500
Received: from rtp-core-2.cisco.com ([64.102.124.13])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AFaqc-0001Jj-00
	for sip@ietf.org; Fri, 31 Oct 2003 10:05:58 -0500
Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27])
	by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9VF5RuR001602;
	Fri, 31 Oct 2003 10:05:27 -0500 (EST)
Received: from cisco.com (rtp-xdm1.cisco.com [64.102.17.80])
	by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ASL15498;
	Fri, 31 Oct 2003 07:05:25 -0800 (PST)
Message-ID: <3FA27A35.93589C31@cisco.com>
Date: Fri, 31 Oct 2003 10:05:25 -0500
From: Manoj Bhatia <manojb@cisco.com>
Organization: Cisco Systems, Inc. , RTP, NC, USA
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: cthakker <cthakker@ipnetfusion.com>
CC: sip@ietf.org
Subject: Re: [Sip] IP Address vs Domain name in the from header
References: <3F9FEF36.6050709@ipnetfusion.com>
Content-Type: multipart/alternative;
 boundary="------------80631A504975AB3D7B4D1129"
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>


--------------80631A504975AB3D7B4D1129
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I don't know which gateway are you talking about, but a SIP GW has
to behave like a SIP UA.
If you send more details of the flow, it will be helpful.

thanks
-Manoj

cthakker wrote:

> Hi,
>  We are testing out a SIP proxy which can accept requests from a SIP
> gateway or SIP endpoints.
>  Should the INVITE sent by the SIP gateway be any different from the one
> sent by SIP endpoints ? (It seems that the proxy accepts requests from a
> gateway only if the from header is of the form - <sip:caller@SUT_IP> and
> it accepts requests from end points only if it is of the form
> <sip:caller@remote_id:port>) Is this behaviour valid ?
>  Is there any document that explains how a gateway may modify the
> request before forwarding it to the SIP Proxy ?
>
>  Thank you in advance,
>
>  Chintan
>  ipNetFusion Inc,
>  Dallas TX
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip

--
Manoj Bhatia                           |        |         |
manojb@cisco.com                       |       :|:       :|:
7025 Kit Creek Road, RTP, NC - 27709   |     :|||||:   :|||||:
Ph: 919-392-3873  Fax:919-392-6801     |  C i s c o S y s t e m s



--------------80631A504975AB3D7B4D1129
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
I don't know which gateway are you talking about, but a SIP&nbsp;GW has
<br>to behave like a SIP&nbsp;UA.
<br>If you send more details of the flow, it will be helpful.
<p>thanks
<br>-Manoj
<p>cthakker wrote:
<blockquote TYPE=CITE>Hi,
<br>&nbsp;We are testing out a SIP proxy which can accept requests from
a SIP
<br>gateway or SIP endpoints.
<br>&nbsp;Should the INVITE sent by the SIP gateway be any different from
the one
<br>sent by SIP endpoints ? (It seems that the proxy accepts requests from
a
<br>gateway only if the from header is of the form - &lt;sip:caller@SUT_IP>
and
<br>it accepts requests from end points only if it is of the form
<br>&lt;sip:caller@remote_id:port>) Is this behaviour valid ?
<br>&nbsp;Is there any document that explains how a gateway may modify
the
<br>request before forwarding it to the SIP Proxy ?
<p>&nbsp;Thank you in advance,
<p>&nbsp;Chintan
<br>&nbsp;ipNetFusion Inc,
<br>&nbsp;Dallas TX
<p>_______________________________________________
<br>Sip mailing list&nbsp; <a href="https://www1.ietf.org/mailman/listinfo/sip">https://www1.ietf.org/mailman/listinfo/sip</a>
<br>This list is for NEW development of the core SIP Protocol
<br>Use sip-implementors@cs.columbia.edu for questions on current sip
<br>Use sipping@ietf.org for new developments on the application of sip</blockquote>

<pre>--&nbsp;
Manoj Bhatia&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |
manojb@cisco.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; :|:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; :|:
7025 Kit Creek Road, RTP, NC - 27709&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; :|||||:&nbsp;&nbsp; :|||||:
Ph: 919-392-3873&nbsp; Fax:919-392-6801&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; C i s c o S y s t e m s</pre>
&nbsp;</html>

--------------80631A504975AB3D7B4D1129--


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