From mailnull@www1.ietf.org  Tue Apr  1 12:14:41 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00647
	for <sip-archive@odin.ietf.org>; Tue, 1 Apr 2003 12:14:41 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h31HcVl11509
	for sip-archive@odin.ietf.org; Tue, 1 Apr 2003 12:38:31 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31HbvK11484;
	Tue, 1 Apr 2003 12:37:57 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31HXpK09548
	for <sip@optimus.ietf.org>; Tue, 1 Apr 2003 12:33:51 -0500
Received: from ss8mail1.ss8ott (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00284
	for <sip@ietf.org>; Tue, 1 Apr 2003 12:09:30 -0500 (EST)
Received: by smtp.ss8.com with Internet Mail Service (5.5.2653.19)
	id <HD686FQ1>; Tue, 1 Apr 2003 12:13:09 -0500
Message-ID: <8BAF8B40C4D2D411ADC300508BD63D69040EB4BE@smtp.ss8.com>
From: Hongchang Tian <Hongchang.Tian@SS8.com>
To: "'Takuya Sawada'" <tu-sawada@kddi.com>, tomimura@sei.co.jp, sip@ietf.org
Subject: RE: [Sip] Interaction RFC3262 and Record-Route header included in
	 18xresponse
Date: Tue, 1 Apr 2003 12:13:08 -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>

Another concern is the CSeq sequence number IN CSeq Hdr field for PRACK.

1).  According to RFC3261 (12.2.1.1, requests within a dialog MUST contain 
strictly monotonically increasing and contiguous CSeq sequence numbers
(increasing-by-one)
in each direction (excepting ACK and CANCEL of course, whose numbers equal
the requests 
being acknowledged or cancelled).  

2).  RFC3262 doesn't address the CSeq Hdr field for PRACK.

3).  Personally I think it makes sense for PRACK to follow the ACK rule
regarding
the CSeq sequence numbers (the same as the initial request.

Any comment about the above?


Cheers,


Hongchang Tian
Software Designer
Tel:  613-592-2100 x3266
Fax: 613-592-9634

SS8 Networks, Inc.
495 March Road
Kanata ON K2K 3G1
hongchang.tian@SS8.com
www.SS8.com

Notice to Recipient:  This e-mail is meant only for the intended
recipient(s) of the transmission, and contains confidential information,
which is proprietary to SS8 Networks, Inc.  Any unauthorized use, copying,
distribution, or dissemination is strictly prohibited.   All rights to this
information is reserved by SS8 Networks, Inc.  If you are not the intended
recipient, please contact the sender by reply e-mail and please delete this
e-mail from your system and destroy any copies.  





-----Original Message-----
From: Takuya Sawada [mailto:tu-sawada@kddi.com]
Sent: Friday, February 28, 2003 7:33 AM
To: tomimura@sei.co.jp; sip@ietf.org
Subject: Re: [Sip] Interaction RFC3262 and Record-Route header included
in 18xresponse


Hello,

I think you are correct, as described in RFCs.

- CANCEL and ACK for non-2xx are related to (INVITE) TRANSACTION.
- PRACK is related to (early) DIALOG (established by INVITE).
That is why they are different.

Note that ACK for 2xx is constructed as PRACK except that it
uses routing information from 2xx not from reliable 18x.

Regards,
Takuya Sawada

> Dear all,
> 
> I would like to clarify when we use PRACK and Record-Route header for 18x
> response.
> 
> Consider the following scenario. The UAC receives 18x response with
> Record-Route header, and route set and remote target are updated based on
> section 12.1.2 of RFC3261:
> 
> UAC           Proxy
> ----INVITE---->
> <--- 18x  ----- w/ Record-Route header
> ---- PRACK ---> 
> 
> 
> ---
> Question 1)
> 
> When the UAC construct PRACK, it MUST follow the procedure described in
> section 12.2.1.1 of RFC3261, and Request-URI should be changed to the
remote
> target, and also Route header should be included.
> 
> Is that correct?
> 
> 
> ---
> Question 2)
> 
> In case the UAC try to cancel the call:
> 
> UAC           Proxy
> ----INVITE---->
> <--- 18x  ----- w/ Record-Route header
> ---- PRACK ---> 
> <--- 200 OK----
> 
> ----CANCEL----> 
> <--- 200 OK----
> 
> <--- 487 ------
> ---- ACK ----->
> 
> 
> When the UAC construct CANCEL, as described in section 9.1 of RFC3261, it
> MUST use the same Request-URI as in the original INVITE. It means that the
> UAC MUST NOT use route set and remote target information received already
in
> Record-Route header.
> 
> Is that correct? 
> 
> ---
> 
> Question 3) 
> 
> In the scenario described in Question 2), the UAC finally sends ACK after
> receiving 487 response.
> 
> When the UAC construct ACK, as described in section 17.1.1.3 of RFC3261,
it
> MUST use the same Request-URI as in the original INVITE. It means that the
> UAC MUST NOT use route set and remote target information received already
in
> Record-Route header.
> 
> Is that correct? 
> 
> ---
> 
> Thank you very much for your assistance.
> 
> Regards,
> - Eiji Tomimura
> 
> 
> 
> -- 
> Eiji Tomimura 
> Senior Engineer 
> Systems Technology Dept., Information Technology R&D Laboratories
> Sumitomo Electric Industries, Ltd.
> Phone: +81-6-6466-5632  Fax: +81-6-6462-4586  Email: tomimura@sei.co.jp
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip


--------
Takuya Sawada
KDDI Corporation (KDDI)
KDDI Bldg. 2-3-2 Nishishinjuku Shinjuku-ku, 
Tokyo 163-8003, Japan
Tel: +81-3-3347-7406
Fax: +81-3-3347-7418
tu-sawada@kddi.com
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Wed Apr  2 02:55:29 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29856
	for <sip-archive@odin.ietf.org>; Wed, 2 Apr 2003 02:55:29 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h328JbI13343
	for sip-archive@odin.ietf.org; Wed, 2 Apr 2003 03:19:37 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h328IsK13244;
	Wed, 2 Apr 2003 03:18:54 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h328EVK12947
	for <sip@optimus.ietf.org>; Wed, 2 Apr 2003 03:14:31 -0500
Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29587
	for <sip@ietf.org>; Wed, 2 Apr 2003 02:49:51 -0500 (EST)
From: hisham.khartabil@nokia.com
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.5) with ESMTP id h327uH520273
	for <sip@ietf.org>; Wed, 2 Apr 2003 10:56:17 +0300 (EET DST)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T615a6a386bac158f24165d@esvir04nok.ntc.nokia.com>;
 Wed, 2 Apr 2003 10:52:18 +0300
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Wed, 2 Apr 2003 10:52:18 +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"
Subject: RE: [Sip] Interaction RFC3262 and Record-Route header included in 18xresponse
Date: Wed, 2 Apr 2003 10:52:17 +0300
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE747C@esebe019.ntc.nokia.com>
Thread-Topic: [Sip] Interaction RFC3262 and Record-Route header included in 18xresponse
Thread-Index: AcL4c7o6dtLYhuhYRsuIIIKE/OdRnQAePryA
To: <Hongchang.Tian@ss8.com>, <tu-sawada@kddi.com>, <tomimura@sei.co.jp>,
        <sip@ietf.org>
X-OriginalArrivalTime: 02 Apr 2003 07:52:18.0173 (UTC) FILETIME=[C8A08AD0:01C2F8EC]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h328EWK12949
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit

PRACK is a request within a dialog.

Regards,
Hisham

> -----Original Message-----
> From: ext Hongchang Tian [mailto:Hongchang.Tian@ss8.com]
> Sent: Tuesday, April 01, 2003 8:13 PM
> To: 'Takuya Sawada'; tomimura@sei.co.jp; sip@ietf.org
> Subject: RE: [Sip] Interaction RFC3262 and Record-Route 
> header included
> in 18xresponse
> 
> 
> Another concern is the CSeq sequence number IN CSeq Hdr field 
> for PRACK.
> 
> 1).  According to RFC3261 (12.2.1.1, requests within a dialog 
> MUST contain 
> strictly monotonically increasing and contiguous CSeq sequence numbers
> (increasing-by-one)
> in each direction (excepting ACK and CANCEL of course, whose 
> numbers equal
> the requests 
> being acknowledged or cancelled).  
> 
> 2).  RFC3262 doesn't address the CSeq Hdr field for PRACK.
> 
> 3).  Personally I think it makes sense for PRACK to follow 
> the ACK rule
> regarding
> the CSeq sequence numbers (the same as the initial request.
> 
> Any comment about the above?
> 
> 
> Cheers,
> 
> 
> Hongchang Tian
> Software Designer
> Tel:  613-592-2100 x3266
> Fax: 613-592-9634
> 
> SS8 Networks, Inc.
> 495 March Road
> Kanata ON K2K 3G1
> hongchang.tian@SS8.com
> www.SS8.com
> 
> Notice to Recipient:  This e-mail is meant only for the intended
> recipient(s) of the transmission, and contains confidential 
> information,
> which is proprietary to SS8 Networks, Inc.  Any unauthorized 
> use, copying,
> distribution, or dissemination is strictly prohibited.   All 
> rights to this
> information is reserved by SS8 Networks, Inc.  If you are not 
> the intended
> recipient, please contact the sender by reply e-mail and 
> please delete this
> e-mail from your system and destroy any copies.  
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Takuya Sawada [mailto:tu-sawada@kddi.com]
> Sent: Friday, February 28, 2003 7:33 AM
> To: tomimura@sei.co.jp; sip@ietf.org
> Subject: Re: [Sip] Interaction RFC3262 and Record-Route 
> header included
> in 18xresponse
> 
> 
> Hello,
> 
> I think you are correct, as described in RFCs.
> 
> - CANCEL and ACK for non-2xx are related to (INVITE) TRANSACTION.
> - PRACK is related to (early) DIALOG (established by INVITE).
> That is why they are different.
> 
> Note that ACK for 2xx is constructed as PRACK except that it
> uses routing information from 2xx not from reliable 18x.
> 
> Regards,
> Takuya Sawada
> 
> > Dear all,
> > 
> > I would like to clarify when we use PRACK and Record-Route 
> header for 18x
> > response.
> > 
> > Consider the following scenario. The UAC receives 18x response with
> > Record-Route header, and route set and remote target are 
> updated based on
> > section 12.1.2 of RFC3261:
> > 
> > UAC           Proxy
> > ----INVITE---->
> > <--- 18x  ----- w/ Record-Route header
> > ---- PRACK ---> 
> > 
> > 
> > ---
> > Question 1)
> > 
> > When the UAC construct PRACK, it MUST follow the procedure 
> described in
> > section 12.2.1.1 of RFC3261, and Request-URI should be 
> changed to the
> remote
> > target, and also Route header should be included.
> > 
> > Is that correct?
> > 
> > 
> > ---
> > Question 2)
> > 
> > In case the UAC try to cancel the call:
> > 
> > UAC           Proxy
> > ----INVITE---->
> > <--- 18x  ----- w/ Record-Route header
> > ---- PRACK ---> 
> > <--- 200 OK----
> > 
> > ----CANCEL----> 
> > <--- 200 OK----
> > 
> > <--- 487 ------
> > ---- ACK ----->
> > 
> > 
> > When the UAC construct CANCEL, as described in section 9.1 
> of RFC3261, it
> > MUST use the same Request-URI as in the original INVITE. It 
> means that the
> > UAC MUST NOT use route set and remote target information 
> received already
> in
> > Record-Route header.
> > 
> > Is that correct? 
> > 
> > ---
> > 
> > Question 3) 
> > 
> > In the scenario described in Question 2), the UAC finally 
> sends ACK after
> > receiving 487 response.
> > 
> > When the UAC construct ACK, as described in section 
> 17.1.1.3 of RFC3261,
> it
> > MUST use the same Request-URI as in the original INVITE. It 
> means that the
> > UAC MUST NOT use route set and remote target information 
> received already
> in
> > Record-Route header.
> > 
> > Is that correct? 
> > 
> > ---
> > 
> > Thank you very much for your assistance.
> > 
> > Regards,
> > - Eiji Tomimura
> > 
> > 
> > 
> > -- 
> > Eiji Tomimura 
> > Senior Engineer 
> > Systems Technology Dept., Information Technology R&D Laboratories
> > Sumitomo Electric Industries, Ltd.
> > Phone: +81-6-6466-5632  Fax: +81-6-6462-4586  Email: 
> tomimura@sei.co.jp
> > 
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip
> 
> 
> --------
> Takuya Sawada
> KDDI Corporation (KDDI)
> KDDI Bldg. 2-3-2 Nishishinjuku Shinjuku-ku, 
> Tokyo 163-8003, Japan
> Tel: +81-3-3347-7406
> Fax: +81-3-3347-7418
> tu-sawada@kddi.com
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Wed Apr  2 04:02:33 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01108
	for <sip-archive@odin.ietf.org>; Wed, 2 Apr 2003 04:02:33 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h329Qh418777
	for sip-archive@odin.ietf.org; Wed, 2 Apr 2003 04:26:43 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h329QDK18750;
	Wed, 2 Apr 2003 04:26:13 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h329MMK18583
	for <sip@optimus.ietf.org>; Wed, 2 Apr 2003 04:22:22 -0500
Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01017
	for <sip@ietf.org>; Wed, 2 Apr 2003 03:57:40 -0500 (EST)
Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120])
	by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h32908UE016217;
	Wed, 2 Apr 2003 11:00:08 +0200 (MEST)
Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55)
	id 2A4KWDZY; Wed, 2 Apr 2003 11:00:08 +0200
Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19])
	by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h32908Av002181;
	Wed, 2 Apr 2003 12:00:08 +0300 (EET DST)
Message-ID: <3E8AA692.6060200@lmf.ericsson.se>
Date: Wed, 02 Apr 2003 12:00:02 +0300
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Drage, Keith (Keith)" <drage@lucent.com>
CC: "'sip@ietf.org'" <sip@ietf.org>,
        "'jari.arkko@ericsson.com'"
 <jari.arkko@ericsson.com>,
        "'vesa.torvinen@ericsson.fi'"
 <vesa.torvinen@lmf.ericsson.se>,
        "'Gonzalo.Camarillo@ericsson.com'"
 <Gonzalo.Camarillo@ericsson.com>,
        "'aki.niemi@nokia.com'"
 <aki.niemi@nokia.com>,
        "'tao.haukka@nokia.com'" <tao.haukka@nokia.com>
References: <475FF955A05DD411980D00508B6D5FB00439EC6D@en0033exch001u.uk.lucent.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Re: Some comments on RFC 3329 (Security Mechanism Agreement for the
 S	ession 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>
Content-Transfer-Encoding: 7bit

Keith,

thanks for your comments. Answers inline.

Drage, Keith (Keith) wrote:
 > In looking at this RFC we detect some issues that ought to be
 > resolved even though this is a published RFC. There is also an issue
 > that is raised with regard to RFC 3261.
 >
 > 1)	Section 2.6, table 1. The Security-Verify header is not included
 > in the PRACK according to the table. It is our belief that the header
 > should be applicable to all methods except ACK and CANCEL, where we
 > agree that it makes no sense.

Yes, when you were discussing these issues within 3GPP, I already 
acknowledge this error. PRACKs should not be an exception. The only 
exceptions are CANCELs and ACKs.

We have two choices here.

1) Since you and we know that it is an errata, you add a note to your 
3GPP spec accordingly and when/if we release a revised version of 
sec-agree, we will correct it. This is what we have done with RFC3261 
and bugzilla so far.

2) We publish this errata at http://www.rfc-editor.org/errata.html

For such a small thing, I would go for option 1, although I will be glad 
to publish the errata if you feel more comfortable.


 > 2)	Section 2.3.1, 9th paragraph. In relation to the above comment,
 > this text states:
 >
 > All the subsequent SIP requests sent by the client to that server
 > SHOULD make use of the security mechanism initiated in the previous
 > step.  These requests MUST contain a Security-Verify header field
 > that mirrors the server's list received previously in the Security-
 > Server header field.  These requests MUST also have both a Require
 > and Proxy-Require header fields with the value "sec-agree".
 >
 > This text should explicitly exclude the ACK and CANCEL requests.
 > Something along the lines of:
 >
 > All the subsequent SIP requests except the ACK request and the CANCEL
 >  request sent by the client to that server...
 >

Yes, I agree that adding such a clarification would help people 
understand. However, I consider this as an editorial comment, rather 
than a technical one, so I do not see a need for publishing an errata 
about this. In any event, I will log your comment and this will be 
clarified in future potential revisions of the document. Thanks.

 > 3)	Section 6.4 defines the new status code 494 (By the way what is
 > the distinction between the term "status code" and "response code" -
 > RFC 3261 seems to use both interchangeably).

There is no distintion. Status code is the original term, but response 
code is probably better understood by many. We may want to clarify this 
in future revisions of RFC3261.

 > Unlike other codes in
 > RFC 3261, this RFC does not define any semantic meaning to the status
 > code.

The semantics may not be defined explicitily, but they are clear by 
reading the document.

 > While obviously we should not define user action on receiving status
 > codes, one idea we would like to convey is that any recovery by the
 > user caused by a 494 being sent in response to a Security-Verify
 > header check, specified in 2.3.1 as follows:
 >
 > The server can proceed processing a particular request if, and only
 > if, the list was not modified.  If modification of the list is
 > detected, the server MUST respond to the client with a 494 (Security
 > Agreement Required) response.  This response MUST include the
 > server's unmodified list of supported security mechanisms.  If the
 > list was not modified, and the server is a proxy, it MUST remove the
 > "sec-agree" value from both the Require and Proxy-Require header
 > fields, and then remove the header fields if no values remain.
 >
 > should be appropriate to the security mechanism that is being agreed,
 > rather than a matter of sticking the appropriate headers in the next
 > method to be sent. Thus if the security architecture used specifies
 > doing the security agreement over the REGISTER method, then that is
 > the method that must be used for the recovery.
 >
 > Some extra words in 6.4 to this effect would be useful.
 >
 > I would suggest something along the lines of:
 >
 > "The server received a request which either requires a security
 > agreement to be made, or the security agreement indicated did not
 > match that already made. In order to continue, the UAC will need to
 > make a new security agreement using requests appropriate to the
 > security mechanism for which agreement is made. Any existing dialogs
 > can have been terminated as a result of the loss of the security
 > agreement."
 >

Again, I agree with your comment, but I consider this to be an editorial 
one (clarification requested). I believe that it is clear that you have 
to re-try the same request, since this is standard behaviour in SIP. for 
example, I send a REGISTER and I get back an error code saying that the 
server cannot decrypt the request. I re-try the REGISTER, not any other 
random request...

In any event, I log your comment in order to clarify this in future 
potential revisions. Thanks.

 > 4)	General. The document is inconsistent in its use of the Require
 > and Proxy-Require headers compared to RFC 3261. As a result I believe
 > changes are probably required to both documents.
 >
 > The current situation in RFC 3261 is that proxies use the
 > Proxy-Require header, and that UAs user the Require header. Neither
 > entity is allowed to remove items from either header.
 >
 > RFC 3329 currently seems to allow proxies to read and react to
 > contents of the Require header, and both Proxy-Require and Require
 > headers have the sec-agree option-tags removed by a proxy.
 >
 > What I believe should happen is that RFC 3261 should be modified to
 > specify "d" for proxies in the table that Jonathan dislikes - I mean
 > table 2 and 3 of RFC 3261 for both these headers. Text concerning
 > these headers should be modifed such that where a proxy is reacting
 > and providing capabilities in accordance with the
 > extension/application described in the Proxy-Require header, then the
 > application/extension can define procedures for the deletion of
 > option-tags relating to that extension/application in both the
 > Require and Proxy-Require headers. Unless this is defined in the
 > extension/application, then the proxy must not remove option-tags.
 >
 > What needs to change in RFC 3329 is that proxy procedures should
 > react only to the Proxy-Require header contents, and UAs should react
 > only to Require header contents, strictly in accordance with RFC
 > 3261. The procedures currently define the modification of
 > Proxy-Require and Require headers for this extension.
 >

This is actually a thing that would be good to clarify. The reason why a 
proxy can remove a sec-agree tag from a Require header is that the 
Proxy-Require header contained the sec-agree tag as well. Therefore, 
since the proxy understands sec-agree, it is safe for it to remove it. 
But in general, it would be unsafe for a proxy to remove any other tag 
in the Require header.

And the reason a client needs to add tgs to both, require and 
proxy-require is that it wants to make sure that its next hop, no matter 
if it is a proxy or a UA, uses sec-agree.

Thanks for the comments,

Cheers,

Gonzalo

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



From mailnull@www1.ietf.org  Wed Apr  2 06:25:53 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03812
	for <sip-archive@odin.ietf.org>; Wed, 2 Apr 2003 06:25:53 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h32Bo5129691
	for sip-archive@odin.ietf.org; Wed, 2 Apr 2003 06:50:05 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32BnaK29619;
	Wed, 2 Apr 2003 06:49:36 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h326xCK27940
	for <sip@optimus.ietf.org>; Wed, 2 Apr 2003 01:59:12 -0500
Received: from web20504.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA01327
	for <sip@ietf.org>; Wed, 2 Apr 2003 01:34:35 -0500 (EST)
Message-ID: <20030402063702.41671.qmail@web20504.mail.yahoo.com>
Received: from [212.143.185.30] by web20504.mail.yahoo.com via HTTP; Tue, 01 Apr 2003 22:37:02 PST
Date: Tue, 1 Apr 2003 22:37:02 -0800 (PST)
From: Jay Morris <jay_m_morris@yahoo.com>
To: sip@ietf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1497885904-1049265422=:41458"
Subject: [Sip] Record-Route and 1xx
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-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-1497885904-1049265422=:41458
Content-Type: text/plain; charset=us-ascii

 Hi,
The usage of Route and Record Route is still not clear to me when 1xx responses are used.

1.Should Record-Route headers be copied to any 1xx response of an early dialog?

2. Should requests sent before the dialog is established use this Record-Route list for routing the request?

3. Should the route list be replaced for each 1xx response of an early dialog or should the UAC use only the first received Record-Route list for this purpose?

Thanks,
Jay.

 



---------------------------------
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
--0-1497885904-1049265422=:41458
Content-Type: text/html; charset=us-ascii

&nbsp;Hi,
<P class=MsoNormal>The usage of Route and Record Route is still not clear to me when 1xx responses are used.</P>
<P class=MsoNormal>1.Should Record-Route headers be copied to any 1xx response of an early dialog?</P>
<P class=MsoNormal>2. Should requests sent before the dialog is established use this Record-Route list for routing the request?</P>
<P class=MsoNormal>3. Should the route list be replaced for each 1xx response of an early dialog or should the UAC use only the first received Record-Route list for this purpose?</P>
<P class=MsoNormal>Thanks,<BR>Jay.</P>
<P class=MsoNormal>&nbsp;</P><p><br><hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/finance/mailsig/*http://tax.yahoo.com">Yahoo! Tax Center</a> - File online, calculators, forms, and more
--0-1497885904-1049265422=:41458--
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Wed Apr  2 09:31:07 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10403
	for <sip-archive@odin.ietf.org>; Wed, 2 Apr 2003 09:31:07 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h32EtNJ12141
	for sip-archive@odin.ietf.org; Wed, 2 Apr 2003 09:55:23 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32EsoK12061;
	Wed, 2 Apr 2003 09:54:50 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32EolK11913
	for <sip@optimus.ietf.org>; Wed, 2 Apr 2003 09:50:47 -0500
Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10236
	for <sip@ietf.org>; Wed, 2 Apr 2003 09:25:59 -0500 (EST)
From: hisham.khartabil@nokia.com
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.5) with ESMTP id h32EWQ506785
	for <sip@ietf.org>; Wed, 2 Apr 2003 17:32:26 +0300 (EET DST)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T615bd4e8baac158f24991@esvir04nok.ntc.nokia.com>;
 Wed, 2 Apr 2003 17:28:27 +0300
Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Wed, 2 Apr 2003 17:28:26 +0300
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Wed, 2 Apr 2003 17:28:26 +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"
Subject: RE: [Sip] Record-Route and 1xx
Date: Wed, 2 Apr 2003 17:28:25 +0300
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE7483@esebe019.ntc.nokia.com>
Thread-Topic: [Sip] Record-Route and 1xx
Thread-Index: AcL5EN1tHTHPaK5aSQSrrX5WF/KHUwAD/TIg
To: <jay_m_morris@yahoo.com>, <sip@ietf.org>
X-OriginalArrivalTime: 02 Apr 2003 14:28:26.0077 (UTC) FILETIME=[1F66E0D0:01C2F924]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h32EolK11914
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit


> -----Original Message-----
> From: ext Jay Morris [mailto:jay_m_morris@yahoo.com]
> Sent: Wednesday, April 02, 2003 9:37 AM
> To: sip@ietf.org
> Subject: [Sip] Record-Route and 1xx
> 
> 
>  Hi, 
> The usage of Route and Record Route is still not clear to me when 1xx responses are used.
> 1.Should Record-Route headers be copied to any 1xx response of an early dialog?

yes


> 2. Should requests sent before the dialog is established use this Record-Route list for routing the request?

A dialog is established with 1xx (and early dialog). Your question should ask if requests are sent before the dialog is confirmed,  should they use this Record-Route list for routing the request. The answer is yes.

> 3. Should the route list be replaced for each 1xx response of an early dialog or should the UAC use only the first received Record-Route list for this
>  purpose?

Replace. Also the 2xx that confirms the dialog replaces the route set. After that, route set is not replaceable.

Regards,
Hisham


> Thanks,
> Jay.
enter - File online, calculators, forms, and more
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Wed Apr  2 10:30:23 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13800
	for <sip-archive@odin.ietf.org>; Wed, 2 Apr 2003 10:30:23 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h32FsfH17370
	for sip-archive@odin.ietf.org; Wed, 2 Apr 2003 10:54:41 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32Fs6K17286;
	Wed, 2 Apr 2003 10:54:06 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32Fj6K16703
	for <sip@optimus.ietf.org>; Wed, 2 Apr 2003 10:45:06 -0500
Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13368
	for <sip@ietf.org>; Wed, 2 Apr 2003 10:20:16 -0500 (EST)
From: jh@lohi.eng.song.fi
Received: from harjus.eng.song.fi ([195.10.149.20])
	by lohi.eng.song.fi with esmtp (Exim 3.36 #1 (Debian))
	id 190k4a-0007em-00; Wed, 02 Apr 2003 18:22:44 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16011.68.389612.344249@harjus.eng.song.fi>
Date: Wed, 2 Apr 2003 18:22:44 +0300
To: hisham.khartabil@nokia.com
Cc: <jay_m_morris@yahoo.com>, <sip@ietf.org>
Subject: RE: [Sip] Record-Route and 1xx
In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7FE7483@esebe019.ntc.nokia.com>
References: <2038BCC78B1AD641891A0D1AE133DBB7FE7483@esebe019.ntc.nokia.com>
X-Mailer: VM 7.07 under Emacs 21.2.1
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

hisham.khartabil@nokia.com writes:

 > Replace. Also the 2xx that confirms the dialog replaces the route
 > set. After that, route set is not replaceable. 

which is a bad thing and should be considered a bug.

-- juha

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



From mailnull@www1.ietf.org  Wed Apr  2 12:20:02 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19637
	for <sip-archive@odin.ietf.org>; Wed, 2 Apr 2003 12:20:02 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h32HiLO29379
	for sip-archive@odin.ietf.org; Wed, 2 Apr 2003 12:44:21 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32HhrK29353;
	Wed, 2 Apr 2003 12:43:53 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32He1K29194
	for <sip@optimus.ietf.org>; Wed, 2 Apr 2003 12:40:01 -0500
Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19478
	for <sip@ietf.org>; Wed, 2 Apr 2003 12:15:11 -0500 (EST)
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 h32HHc927106
	for <sip@ietf.org>; Wed, 2 Apr 2003 11:17:38 -0600
From: Robert Sparks <rsparks@dynamicsoft.com>
To: sip@ietf.org
Content-Type: text/plain
Message-Id: <1049303814.1198.20.camel@RjS.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.3 
Date: 02 Apr 2003 11:16:55 -0600
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] SIMPLE interoperability test event
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-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

For those that might not be watching the SIMPLE list closely -

Registration is now open for the SIMPLE interoperability test.
Please see http://simplet.jasomi.com for details.

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 mailnull@www1.ietf.org  Wed Apr  2 16:01:38 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08948
	for <sip-archive@odin.ietf.org>; Wed, 2 Apr 2003 16:01:38 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h32LQ2v18010
	for sip-archive@odin.ietf.org; Wed, 2 Apr 2003 16:26:02 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32LPPK17914;
	Wed, 2 Apr 2003 16:25:25 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32LIcK17483
	for <sip@optimus.ietf.org>; Wed, 2 Apr 2003 16:18:38 -0500
Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08730
	for <sip@ietf.org>; Wed, 2 Apr 2003 15:53:42 -0500 (EST)
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 h32Ku0Og031287
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO);
	Wed, 2 Apr 2003 14:56:03 -0600
From: "Dean Willis" <dwillis@dynamicsoft.com>
To: <sip@ietf.org>
Cc: <mankin@psg.com>, "Rohan Mahy" <rohan@cisco.com>,
        "Jon Peterson \(jon.peterson@NeuStar.com\)" <jon.peterson@neustar.biz>
Date: Wed, 2 Apr 2003 14:55:53 -0600
Message-ID: <006201c2f95a$41d97b60$ee036e3f@txdwillis>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h32LIcK17484
Subject: [Sip] Please give consideration to SIMPLE event-list 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: 8bit


Please give consideration to the SIMPLE event-list draft:

http://www.ietf.org/internet-drafts/draft-ietf-simple-event-list-01.txt

The SIMPLE working group has started a formal last call on this draft.

The SIP-chairs/Transport-ADs have not concluded on exactly how/if this draft
will be formally considered by the SIP working group before proceeding to
the IESG, but we should at least be aawre of the draft and assist in the
WGLC within SIMPLE to speed things up.

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 mailnull@www1.ietf.org  Wed Apr  2 23:57:53 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24391
	for <sip-archive@odin.ietf.org>; Wed, 2 Apr 2003 23:57:52 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h334xvN25335
	for sip-archive@odin.ietf.org; Wed, 2 Apr 2003 23:59:57 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h334x0K25295;
	Wed, 2 Apr 2003 23:59:00 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h334twK25194
	for <sip@optimus.ietf.org>; Wed, 2 Apr 2003 23:55:58 -0500
Received: from web20507.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA24325
	for <sip@ietf.org>; Wed, 2 Apr 2003 23:53:22 -0500 (EST)
Message-ID: <20030403045549.68561.qmail@web20507.mail.yahoo.com>
Received: from [212.143.185.30] by web20507.mail.yahoo.com via HTTP; Wed, 02 Apr 2003 20:55:49 PST
Date: Wed, 2 Apr 2003 20:55:49 -0800 (PST)
From: Jay Morris <jay_m_morris@yahoo.com>
Subject: RE: [Sip] Record-Route and 1xx
To: hisham.khartabil@nokia.com, sip@ietf.org
In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7FE7483@esebe019.ntc.nokia.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1177000088-1049345749=:68229"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-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-1177000088-1049345749=:68229
Content-Type: text/plain; charset=us-ascii


Is this the case for any 1xx, or should the 1xx be reliable?
What about 100 response.
Jay.
 hisham.khartabil@nokia.com wrote:
> -----Original Message-----
> From: ext Jay Morris [mailto:jay_m_morris@yahoo.com]
> Sent: Wednesday, April 02, 2003 9:37 AM
> To: sip@ietf.org
> Subject: [Sip] Record-Route and 1xx
> 
> 
> Hi, 
> The usage of Route and Record Route is still not clear to me when 1xx responses are used.
> 1.Should Record-Route headers be copied to any 1xx response of an early dialog?

yes


> 2. Should requests sent before the dialog is established use this Record-Route list for routing the request?

A dialog is established with 1xx (and early dialog). Your question should ask if requests are sent before the dialog is confirmed, should they use this Record-Route list for routing the request. The answer is yes.

> 3. Should the route list be replaced for each 1xx response of an early dialog or should the UAC use only the first received Record-Route list for this
> purpose?

Replace. Also the 2xx that confirms the dialog replaces the route set. After that, route set is not replaceable.

Regards,
Hisham


> Thanks,
> Jay.
enter - File online, calculators, forms, and more
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


---------------------------------
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
--0-1177000088-1049345749=:68229
Content-Type: text/html; charset=us-ascii

<P>Is this the case for any 1xx, or should the 1xx be reliable?
<P>What about 100 response.
<P>Jay.
<P>&nbsp;<B><I>hisham.khartabil@nokia.com</I></B> wrote:
<BLOCKQUOTE style="BORDER-LEFT: #1010ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px"><BR>&gt; -----Original Message-----<BR>&gt; From: ext Jay Morris [mailto:jay_m_morris@yahoo.com]<BR>&gt; Sent: Wednesday, April 02, 2003 9:37 AM<BR>&gt; To: sip@ietf.org<BR>&gt; Subject: [Sip] Record-Route and 1xx<BR>&gt; <BR>&gt; <BR>&gt; Hi, <BR>&gt; The usage of Route and Record Route is still not clear to me when 1xx responses are used.<BR>&gt; 1.Should Record-Route headers be copied to any 1xx response of an early dialog?<BR><BR>yes<BR><BR><BR>&gt; 2. Should requests sent before the dialog is established use this Record-Route list for routing the request?<BR><BR>A dialog is established with 1xx (and early dialog). Your question should ask if requests are sent before the dialog is confirmed, should they use this Record-Route list for routing the request. The answer is yes.<BR><BR>&gt; 3. Should the route list be replaced for each 1xx response of an early dialog or should the UAC use o!
 nly the first received Record-Route list for this<BR>&gt; purpose?<BR><BR>Replace. Also the 2xx that confirms the dialog replaces the route set. After that, route set is not replaceable.<BR><BR>Regards,<BR>Hisham<BR><BR><BR>&gt; Thanks,<BR>&gt; Jay.<BR>enter - File online, calculators, forms, and more<BR>_______________________________________________<BR>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip<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><p><br><hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/finance/mailsig/*http://tax.yahoo.com">Yahoo! Tax Center</a> - File online, calculators, forms, and more
--0-1177000088-1049345749=:68229--
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Thu Apr  3 03:35:47 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10210
	for <sip-archive@odin.ietf.org>; Thu, 3 Apr 2003 03:35:47 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h338bv821438
	for sip-archive@odin.ietf.org; Thu, 3 Apr 2003 03:37:57 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h338ZfK20551;
	Thu, 3 Apr 2003 03:35:41 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h338VKK20346
	for <sip@optimus.ietf.org>; Thu, 3 Apr 2003 03:31:20 -0500
Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10122
	for <sip@ietf.org>; Thu, 3 Apr 2003 03:28:39 -0500 (EST)
Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h338V7Bd010409;
	Thu, 3 Apr 2003 03:31:09 -0500 (EST)
Message-ID: <3E8BF142.2070804@dynamicsoft.com>
Date: Thu, 03 Apr 2003 03:30:58 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jay Morris <jay_m_morris@yahoo.com>
CC: hisham.khartabil@nokia.com, sip@ietf.org
Subject: Re: [Sip] Record-Route and 1xx
References: <20030403045549.68561.qmail@web20507.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



Jay Morris wrote:
> Is this the case for any 1xx, or should the 1xx be reliable?

It is the case for any 1xx.

> 
> What about 100 response.

No:

> 12.1 Creation of a Dialog
> 
>    Dialogs are created through the generation of non-failure responses
>    to requests with specific methods.  Within this specification, only
>    2xx and 101-199 responses with a To tag, where the request was
>    INVITE, will establish a dialog.

Notice that 100 is left out of the picture.

-Jonathan R.


-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             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 mailnull@www1.ietf.org  Thu Apr  3 03:40:14 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10246
	for <sip-archive@odin.ietf.org>; Thu, 3 Apr 2003 03:40:14 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h338gPR21668
	for sip-archive@odin.ietf.org; Thu, 3 Apr 2003 03:42:25 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h338eIK21589;
	Thu, 3 Apr 2003 03:40:18 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h338XBK20408
	for <sip@optimus.ietf.org>; Thu, 3 Apr 2003 03:33:11 -0500
Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10135
	for <sip@ietf.org>; Thu, 3 Apr 2003 03:30:29 -0500 (EST)
Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h338WwBd010412;
	Thu, 3 Apr 2003 03:32:59 -0500 (EST)
Message-ID: <3E8BF1B1.4050903@dynamicsoft.com>
Date: Thu, 03 Apr 2003 03:32:49 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: jh@lohi.eng.song.fi
CC: hisham.khartabil@nokia.com, jay_m_morris@yahoo.com, sip@ietf.org
Subject: Re: [Sip] Record-Route and 1xx
References: <2038BCC78B1AD641891A0D1AE133DBB7FE7483@esebe019.ntc.nokia.com> <16011.68.389612.344249@harjus.eng.song.fi>
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 had long discussions on replacing the route set. It had serious 
backwards compatibility issues. We did conclude that it was possible to 
define an extension that allowed you to explicitly ask to be removed 
from the route set. So, if you feel you really need this feature, please 
go ahead and write up some reuqirements and a proposed mechanism.

-Jonathan R.

jh@lohi.eng.song.fi wrote:
> hisham.khartabil@nokia.com writes:
> 
>  > Replace. Also the 2xx that confirms the dialog replaces the route
>  > set. After that, route set is not replaceable. 
> 
> which is a bad thing and should be considered a bug.
> 
> -- juha
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             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 mailnull@www1.ietf.org  Thu Apr  3 03:53:23 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10515
	for <sip-archive@odin.ietf.org>; Thu, 3 Apr 2003 03:53:23 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h338tYv22421
	for sip-archive@odin.ietf.org; Thu, 3 Apr 2003 03:55:34 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h338rPK22330;
	Thu, 3 Apr 2003 03:53:25 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h338oPK22195
	for <sip@optimus.ietf.org>; Thu, 3 Apr 2003 03:50:25 -0500
Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10406
	for <sip@ietf.org>; Thu, 3 Apr 2003 03:47:43 -0500 (EST)
Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h338oABd010420;
	Thu, 3 Apr 2003 03:50:11 -0500 (EST)
Message-ID: <3E8BF5B9.500@dynamicsoft.com>
Date: Thu, 03 Apr 2003 03:50:01 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Vijay Gaur <vgaur@aastra.com>
CC: sip@ietf.org
Subject: Re: [Sip] SIP Client Transaction
References: <F924CEFBBF62D611A0C600D0B76ED037490325@cvxmail.ana.aastra.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.

Vijay Gaur wrote:
> Hi,
>   RFC 3261 section "17.1.1.1 Overview of INVITE Transaction" specifies the
> state machine for Client INVITE transaction. In the diagram if client
> transaction state comes to proceeding after receiving 1xx message, no timers
> are started. It is not specified that if no message is  received further in
> this state, how this transaction will be terminated. There is no timer
> specified to clear this transaction. 

For proxies, timer C is used (see section 16.8 of rfc3261). For a user 
agent, its an application problem. Only the application knows how long 
it wishes to let the phone ring before giving up.


> Do we need to start timer B again in
> this state and clear the transaction after timer B expiry?

When timer B fires, the transaction is terminated. See figure 6 of rfc3261.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             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 mailnull@www1.ietf.org  Thu Apr  3 04:04:32 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10782
	for <sip-archive@odin.ietf.org>; Thu, 3 Apr 2003 04:04:32 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3396he23300
	for sip-archive@odin.ietf.org; Thu, 3 Apr 2003 04:06:43 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3394WK23171;
	Thu, 3 Apr 2003 04:04:32 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3391TK22786
	for <sip@optimus.ietf.org>; Thu, 3 Apr 2003 04:01:29 -0500
Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10620
	for <sip@ietf.org>; Thu, 3 Apr 2003 03:58:47 -0500 (EST)
Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h33918Bd010423;
	Thu, 3 Apr 2003 04:01:11 -0500 (EST)
Message-ID: <3E8BF84B.4020100@dynamicsoft.com>
Date: Thu, 03 Apr 2003 04:00:59 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: vkenneally@cit.ie
CC: sip@ietf.org
Subject: Re: [Sip] Registration Query
References: <NIEFLFDIBJCPCKAMIGBPGENNCFAA.vkenneally@cit.ie>
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



Valerie Kenneally wrote:
> Hi all,
> 
>  Assume a User Agent is registering with a SIP Server.  The SIP Server
> challenges the User Agent with regard to Authorization.  The User Agent
> replies with the appropriate information.  My question-when the User Agent
> responds to the challenge will the Call-ID and From tag or this message be
> the same as the first REGISTER message sent?  All info greatly accepted!

Yes. Section 8.1.3.5 addresses this case:

> In all of the above cases, the request is retried by creating a new
>    request with the appropriate modifications.  This new request
>    constitutes a new transaction and SHOULD have the same value of the
>    Call-ID, To, and From of the previous request, but the CSeq should
>    contain a new sequence number that is one higher than the previous.
> 
> 
> 
> Rosenberg, et. al.          Standards Track                    [Page 45]
> 
> RFC 3261            SIP: Session Initiation Protocol           June 2002
> 
> 
>    With other 4xx responses, including those yet to be defined, a retry
>    may or may not be possible depending on the method and the use case.


-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             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 mailnull@www1.ietf.org  Thu Apr  3 04:15:31 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10973
	for <sip-archive@odin.ietf.org>; Thu, 3 Apr 2003 04:15:30 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h339Hgk24703
	for sip-archive@odin.ietf.org; Thu, 3 Apr 2003 04:17:42 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h339FXK24587;
	Thu, 3 Apr 2003 04:15:33 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h339CfK24433
	for <sip@optimus.ietf.org>; Thu, 3 Apr 2003 04:12:42 -0500
Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10864
	for <sip@ietf.org>; Thu, 3 Apr 2003 04:09:59 -0500 (EST)
Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h339CKBd010430;
	Thu, 3 Apr 2003 04:12:20 -0500 (EST)
Message-ID: <3E8BFAEB.2040708@dynamicsoft.com>
Date: Thu, 03 Apr 2003 04:12:11 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Cullen Jennings <fluffy@cisco.com>
CC: Eron Stein <eronstein@hotmail.com>, sip@ietf.org
Subject: Re: [Sip] TLS post connection verification
References: <DLEHICEBMNEIPCACNLPCOEJDCHAA.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:
> If element A wants to send a SIP message over TLS to a next hop called
> foo.com, A needs to check that the SubjectAltName in the certificate
> provided over the TLS connection to A matches foo.com. Openssl can not do
> this for you automatically, A needs to call the SSL_get_peer_certificate
> after A has connected. foo.com may request, and look at, the certificate of
> A or may not depending on if mutual TLS is being done or not.

Right. The question was, would the server do an equivalent 
post-connection validation based on that certificate. The answer is that 
it depends. In the case of a peering relationship between proxies, it 
would probably check the subjectAltName against a list of valid peers, 
and it would be a matter of policy about whether to accept or reject 
requests identified as coming from users in that domain or other domains 
(for example, rfc3325). You can also use mutual TLS to authenticate a 
UAC, typically a UAC which is an application server of some sort. The 
same kind of policy would applied depending on the type of requests the 
application was needing to generate.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             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 mailnull@www1.ietf.org  Thu Apr  3 04:20:08 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11034
	for <sip-archive@odin.ietf.org>; Thu, 3 Apr 2003 04:20:08 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h339MJh24959
	for sip-archive@odin.ietf.org; Thu, 3 Apr 2003 04:22:19 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h339KFK24889;
	Thu, 3 Apr 2003 04:20:15 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h339FRK24578
	for <sip@optimus.ietf.org>; Thu, 3 Apr 2003 04:15:27 -0500
Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10911
	for <sip@ietf.org>; Thu, 3 Apr 2003 04:12:44 -0500 (EST)
Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h339FFBd010433;
	Thu, 3 Apr 2003 04:15:15 -0500 (EST)
Message-ID: <3E8BFB9A.3080306@dynamicsoft.com>
Date: Thu, 03 Apr 2003 04:15:06 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: murali <muraliv@bharatmail.com>
CC: sip@ietf.org
Subject: Re: [Sip] sip grammar
References: <200303171523.h2HFNK716291@bharatmail.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 example message is not correct. The angle brackets need to be around 
the URI.

-Jonathan R.

murali wrote:
> Hi,
> 
> 	When i was going through the SIP Document: draft-ietf-sip-call-flows-05.txt
> i came across a From Header which is like this
> 
> INVITE sip:+1-650-555-2222@ss1.wcom.com;user=phone SIP/2.0
> Via: SIP/2.0/UDP ift.here.com:5060
> From: sip:+1-303-555-1111@ift.here.com;user=phone
> To: <sip:+1-650-555-2222@ss1.wcom.com;user=phone>
> Call-ID: 1717@ift.here.com
> CSeq: 17 INVITE
> Contact: <sip:+1-303-555-1111@ift.here.com;user=phone>
> Content-Type: application/sdp
> Content-Length: 146
> 
> v=0
> o=IFAXTERMINAL01 2890844527 2890844527 IN IP4 ift.here.com
> s=Session SDP
> c=IN IP4 iftmg.here.com
> t=0 0
> m=audio 3456 RTP/AVP 0
> a=rtpmap:0 PCMU/8000
> (Ref: 3.1.7 Successful SIP to SIP with re-INVITE) 
> 
> but Section 20.20 of RFC 3261 says that
> "Even if the "display-name" is empty, the "name-addr" form MUST be 
> used if the "addr-spec" contains a comma, question mark, or semicolon"
> 
> so, i'd like to know if the above usage is correct?
>  In case it is correct how do i differentiate between the from parameters and URI-parameters as both are delimited by ;.
> I mean to say that i can very well take that(user=phone) as generic parameter in from parameters instead of taking it as uri parameter
> 
> Thanks in advance
> Murali
> 
> 
> 
> -------
> Murali Voleti,
> #503,Maheswari complex,
> Masab Tank,
> Hyderabad
> Tele:(040) 6502272 ext:211
> 
> _____________________________________________________________
> Get Your Free ScanMail and Email At http://mail.ttkbharatplanet.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 Scientist                             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 mailnull@www1.ietf.org  Thu Apr  3 04:31:16 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11293
	for <sip-archive@odin.ietf.org>; Thu, 3 Apr 2003 04:31:16 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h339XSl25504
	for sip-archive@odin.ietf.org; Thu, 3 Apr 2003 04:33:28 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h339VNK25405;
	Thu, 3 Apr 2003 04:31:23 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h339SFK25248
	for <sip@optimus.ietf.org>; Thu, 3 Apr 2003 04:28:15 -0500
Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11153
	for <sip@ietf.org>; Thu, 3 Apr 2003 04:25:32 -0500 (EST)
Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h339S2Bd010437;
	Thu, 3 Apr 2003 04:28:03 -0500 (EST)
Message-ID: <3E8BFE99.8080303@dynamicsoft.com>
Date: Thu, 03 Apr 2003 04:27:53 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
CC: "Drage, Keith (Keith)" <drage@lucent.com>, "'sip@ietf.org'" <sip@ietf.org>,
        "'jari.arkko@ericsson.com'" <jari.arkko@ericsson.com>,
        "'vesa.torvinen@ericsson.fi'" <vesa.torvinen@lmf.ericsson.se>,
        "'Gonzalo.Camarillo@ericsson.com'" <Gonzalo.Camarillo@ericsson.com>,
        "'aki.niemi@nokia.com'" <aki.niemi@nokia.com>,
        "'tao.haukka@nokia.com'" <tao.haukka@nokia.com>
Subject: Re: [Sip] Re: Some comments on RFC 3329 (Security Mechanism Agreement
 for the S	ession Initiation Protocol)
References: <475FF955A05DD411980D00508B6D5FB00439EC6D@en0033exch001u.uk.lucent.com> <3E8AA692.6060200@lmf.ericsson.se>
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:

>  > 4)    General. The document is inconsistent in its use of the Require
>  > and Proxy-Require headers compared to RFC 3261. As a result I believe
>  > changes are probably required to both documents.
>  >
>  > The current situation in RFC 3261 is that proxies use the
>  > Proxy-Require header, and that UAs user the Require header. Neither
>  > entity is allowed to remove items from either header.
>  >
>  > RFC 3329 currently seems to allow proxies to read and react to
>  > contents of the Require header, and both Proxy-Require and Require
>  > headers have the sec-agree option-tags removed by a proxy.
>  >
>  > What I believe should happen is that RFC 3261 should be modified to
>  > specify "d" for proxies in the table that Jonathan dislikes - I mean
>  > table 2 and 3 of RFC 3261 for both these headers. Text concerning
>  > these headers should be modifed such that where a proxy is reacting
>  > and providing capabilities in accordance with the
>  > extension/application described in the Proxy-Require header, then the
>  > application/extension can define procedures for the deletion of
>  > option-tags relating to that extension/application in both the
>  > Require and Proxy-Require headers. Unless this is defined in the
>  > extension/application, then the proxy must not remove option-tags.
>  >
>  > What needs to change in RFC 3329 is that proxy procedures should
>  > react only to the Proxy-Require header contents, and UAs should react
>  > only to Require header contents, strictly in accordance with RFC
>  > 3261. The procedures currently define the modification of
>  > Proxy-Require and Require headers for this extension.
>  >
> 
> This is actually a thing that would be good to clarify. The reason why a 
> proxy can remove a sec-agree tag from a Require header is that the 
> Proxy-Require header contained the sec-agree tag as well. Therefore, 
> since the proxy understands sec-agree, it is safe for it to remove it. 
> But in general, it would be unsafe for a proxy to remove any other tag 
> in the Require header.
> 
> And the reason a client needs to add tgs to both, require and 
> proxy-require is that it wants to make sure that its next hop, no matter 
> if it is a proxy or a UA, uses sec-agree.

Interrestingly, RFC3329 is not the first RFC to have a proxy remove a 
proxy-require header. RFC 3323 (Privacy extensions) does the same thing 
for much the same reason. As such, I agree that this is probably a bug 
in RFC3261, and that evil table 2/3 should be modified to amr, with 
explanatory text explaining under what conditions. I don't think proxies 
can modify Require, however.

I've logged the bug into bugzilla:
http://bugs.sipit.net/sipwg/show_bug.cgi?id=707

THanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             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 mailnull@www1.ietf.org  Thu Apr  3 04:45:15 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11624
	for <sip-archive@odin.ietf.org>; Thu, 3 Apr 2003 04:45:15 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h339lRp27228
	for sip-archive@odin.ietf.org; Thu, 3 Apr 2003 04:47:27 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h339j3K27064;
	Thu, 3 Apr 2003 04:45:03 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h339fqK26877
	for <sip@optimus.ietf.org>; Thu, 3 Apr 2003 04:41:52 -0500
Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11515
	for <sip@ietf.org>; Thu, 3 Apr 2003 04:39:09 -0500 (EST)
Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h339fXBd010444;
	Thu, 3 Apr 2003 04:41:36 -0500 (EST)
Message-ID: <3E8C01C4.6060707@dynamicsoft.com>
Date: Thu, 03 Apr 2003 04:41:24 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Patrick Lam <patrickl@astri.org>
CC: sip@ietf.org
Subject: Re: [Sip] Difference between dialog and session in SIP?
References: <008a01c2f76c$a8ac0690$2306050a@patrickXP>
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



Patrick Lam wrote:
> Dear all:
> 
> I am a little confused about the concept of a dialog.  What exactly is
> the difference between a dialog and a session? 

A dialog is a sip relationship. A session is a media relationship.

> Does dialog mean a "call
> has already been setup" in the signaling sense, while a session mean the
> "media has already been setup" in the media sense?

Thats pretty much right.

> 
> Also, what does "part of a dialog" mean?  Are "INVITE", "ACK" and the
> responses considered "part of a dialog"?

Dialog represents state, which includes sequence numbers, route sets, 
and URIs. A request sent as part of a dialog means that it includes 
route headers from the route set of the dialog, and uses the next 
highest sequence number in the dialog.'

> 
> What does "outside the dialog" mean then?  Is a request is outside the
> dialog, does it still affect or change anything "inside the dialog"
> then?

Outside the dialog means that it is not within the context of a dialog. 
It doesnt use the callid, cseq, or route sets of any existing dialogs, 
and when such a reuqest is set, it has no impact on the state of an 
existing dialog.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             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 mailnull@www1.ietf.org  Thu Apr  3 04:50:55 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11724
	for <sip-archive@odin.ietf.org>; Thu, 3 Apr 2003 04:50:55 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h339r7327566
	for sip-archive@odin.ietf.org; Thu, 3 Apr 2003 04:53:07 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h339oxK27468;
	Thu, 3 Apr 2003 04:50:59 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h339kBK27126
	for <sip@optimus.ietf.org>; Thu, 3 Apr 2003 04:46:11 -0500
Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11577
	for <sip@ietf.org>; Thu, 3 Apr 2003 04:43:27 -0500 (EST)
Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h339jtBd010447;
	Thu, 3 Apr 2003 04:45:56 -0500 (EST)
Message-ID: <3E8C02CA.7010200@dynamicsoft.com>
Date: Thu, 03 Apr 2003 04:45:46 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: murali <muraliv@bharatmail.com>
CC: sip@ietf.org
Subject: Re: [Sip] how do you segregate host from token?
References: <200303250802.h2P82X713030@bharatmail.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.

murali wrote:
 > Hi,
 >
 > In the field generic-param, its mentioned that generic-param =
 > token[EQUAL gen-value}
 >
 > now gen-value = token/host/quoted-string. If host is an IPV4 address
 > or IPV6 address, its fine. But, if host is a hostname which in turn
 > is defined as hostname = *(domainlabel".")toplabel [.] token also has
 > the same allowable characters as allowed in domainname.
 >
 > So, if I am writing a parser for gen-value, when do I recognize it as
 > a token and when do I recognise it as a host with a hostname which
 > comprises of a domainlabel followed by a toplabel?

I don't think you can distinguish, and I dont think it matters. The 
value of the generic param will depend on which generic param it is. So, 
just store it as token, and when the application processes it, it can 
properly determine whether its a domain name or a token.

-Jonathan R.


-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             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 mailnull@www1.ietf.org  Thu Apr  3 05:05:22 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12083
	for <sip-archive@odin.ietf.org>; Thu, 3 Apr 2003 05:05:22 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h33A7Yf28980
	for sip-archive@odin.ietf.org; Thu, 3 Apr 2003 05:07:34 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33A5NK28228;
	Thu, 3 Apr 2003 05:05:23 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33A2CK28102
	for <sip@optimus.ietf.org>; Thu, 3 Apr 2003 05:02:12 -0500
Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11960
	for <sip@ietf.org>; Thu, 3 Apr 2003 04:59:28 -0500 (EST)
Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125])
	by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h33A1sI3028115;
	Thu, 3 Apr 2003 12:01:54 +0200 (MEST)
Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55)
	id 2A497L9V; Thu, 3 Apr 2003 12:01:55 +0200
Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19])
	by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h33A1sAv023494;
	Thu, 3 Apr 2003 13:01:54 +0300 (EET DST)
Message-ID: <3E8C0690.1060702@lmf.ericsson.se>
Date: Thu, 03 Apr 2003 13:01:52 +0300
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: "Drage, Keith (Keith)" <drage@lucent.com>,
        "'sip@ietf.org'"
 <sip@ietf.org>,
        "'jari.arkko@ericsson.com'" <jari.arkko@ericsson.com>,
        "'vesa.torvinen@ericsson.fi'" <vesa.torvinen@lmf.ericsson.se>,
        "'Gonzalo.Camarillo@ericsson.com'"
 <Gonzalo.Camarillo@ericsson.com>,
        "'aki.niemi@nokia.com'"
 <aki.niemi@nokia.com>,
        "'tao.haukka@nokia.com'" <tao.haukka@nokia.com>
Subject: Re: [Sip] Re: Some comments on RFC 3329 (Security Mechanism Agreement
 for the S	ession Initiation Protocol)
References: <475FF955A05DD411980D00508B6D5FB00439EC6D@en0033exch001u.uk.lucent.com> <3E8AA692.6060200@lmf.ericsson.se> <3E8BFE99.8080303@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,

> Interrestingly, RFC3329 is not the first RFC to have a proxy remove a 
> proxy-require header. RFC 3323 (Privacy extensions) does the same thing 
> for much the same reason. As such, I agree that this is probably a bug 
> in RFC3261, and that evil table 2/3 should be modified to amr, with 
> explanatory text explaining under what conditions. I don't think proxies 
> can modify Require, however.

In general, proxies cannot modify Require. However, sec-agree is a very 
special mechanism that is inteded to be used *only* with the next hop. 
That's why the UAC adds both Proxy-Require and Require to the request. 
To cover the case where the next (first) hop is already the UAS (which 
would ignore the proxy-require header).

In any event, sec-agree lets the proxy remove the Require tag because 
the same tag (sec-agree) appears in the proxy-require, and this ensures 
that the proxy understands sec-agree and knows what it is doing when is 
removing the Require tag.

Of course, Require header removal by proxies in any other scenario would 
be very bad.

Gonzalo

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



From mailnull@www1.ietf.org  Thu Apr  3 05:46:31 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13036
	for <sip-archive@odin.ietf.org>; Thu, 3 Apr 2003 05:46:31 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h33Amjc00329
	for sip-archive@odin.ietf.org; Thu, 3 Apr 2003 05:48:45 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33AkJK32620;
	Thu, 3 Apr 2003 05:46:19 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33AgGK32477
	for <sip@optimus.ietf.org>; Thu, 3 Apr 2003 05:42:16 -0500
Received: from web20514.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA12885
	for <sip@ietf.org>; Thu, 3 Apr 2003 05:39:30 -0500 (EST)
Message-ID: <20030403104159.99414.qmail@web20514.mail.yahoo.com>
Received: from [212.143.185.30] by web20514.mail.yahoo.com via HTTP; Thu, 03 Apr 2003 02:41:59 PST
Date: Thu, 3 Apr 2003 02:41:59 -0800 (PST)
From: Jay Morris <jay_m_morris@yahoo.com>
Subject: Re: [Sip] Record-Route and 1xx
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>, jh@lohi.eng.song.fi
Cc: hisham.khartabil@nokia.com, jay_m_morris@yahoo.com, sip@ietf.org
In-Reply-To: <3E8BF1B1.4050903@dynamicsoft.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1719648727-1049366519=:97978"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-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-1719648727-1049366519=:97978
Content-Type: text/plain; charset=us-ascii


Actually, my question was naive. I don’t need any special feature, I just want to do things according to the standard and now I am really confused about what I should do.
I summarize below the behavior I think is according to the standard. Please correct me if I’m wrong:

 Server behavior:

   When an Initial Invite is received take Record-Route list from message and build internal route list.
   Copy record route list to any 1xx (other then 100) response of the invite.
   Copy record route list to the Invite 2xx response.
   Use the route list for routing any outgoing request.
   After dialog is confirmed ignore any Record-Route header in refresh Invite requests.

 Client behavior

   When first 1xx response is received take Record Route list from the response message and build a temporary route set.
   Use this route set for any request sent before the dialog moves to the confirmed state.
   Ignore Record Route headers of other 1xx responses.
   When 2xx is received for the Invite replace the route set and use it for further requests.
   After dialog is confirmed ignore any Record-Route header in refresh Invite requests.

 Is that correct? Especially number 3 of the client behavior.

What does the standard say?

Thanks,

Jay.

 Jonathan Rosenberg <jdrosen@dynamicsoft.com> wrote:We had long discussions on replacing the route set. It had serious 
backwards compatibility issues. We did conclude that it was possible to 
define an extension that allowed you to explicitly ask to be removed 
from the route set. So, if you feel you really need this feature, please 
go ahead and write up some reuqirements and a proposed mechanism.

-Jonathan R.

jh@lohi.eng.song.fi wrote:
> hisham.khartabil@nokia.com writes:
> 
> > Replace. Also the 2xx that confirms the dialog replaces the route
> > set. After that, route set is not replaceable. 
> 
> which is a bad thing and should be considered a bug.
> 
> -- juha
> 
> _______________________________________________
> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 

-- 
Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
Chief Scientist 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


---------------------------------
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
--0-1719648727-1049366519=:97978
Content-Type: text/html; charset=us-ascii

<P>Actually, my question was naive. I don’t need any special feature, I just want to do things according to the standard and now I am really confused about what I should do.
<P class=MsoNormal>I summarize below the behavior I think is according to the standard. Please correct me if I’m wrong:</P>
<P class=MsoNormal>&nbsp;Server behavior:</P>
<OL style="MARGIN-TOP: 0in" type=1>
<LI class=MsoNormal style="mso-list: l0 level1 lfo1; tab-stops: list .5in">When an Initial Invite is received take Record-Route list from message and build internal route list.</LI>
<LI class=MsoNormal style="mso-list: l0 level1 lfo1; tab-stops: list .5in">Copy record route list to any 1xx (other then 100) response of the invite.</LI>
<LI class=MsoNormal style="mso-list: l0 level1 lfo1; tab-stops: list .5in">Copy record route list to the Invite 2xx response.</LI>
<LI class=MsoNormal style="mso-list: l0 level1 lfo1; tab-stops: list .5in">Use the route list for routing any outgoing request.</LI>
<LI class=MsoNormal style="mso-list: l0 level1 lfo1; tab-stops: list .5in">After dialog is confirmed ignore any Record-Route header in refresh Invite requests.</LI></OL>
<P class=MsoNormal>&nbsp;Client behavior</P>
<OL style="MARGIN-TOP: 0in" type=1>
<LI class=MsoNormal style="mso-list: l1 level1 lfo2; tab-stops: list .5in">When first 1xx response is received take Record Route list from the response message and build a temporary route set.</LI>
<LI class=MsoNormal style="mso-list: l1 level1 lfo2; tab-stops: list .5in">Use this route set for any request sent before the dialog moves to the confirmed state.</LI>
<LI class=MsoNormal style="mso-list: l1 level1 lfo2; tab-stops: list .5in">Ignore Record Route headers of other 1xx responses.</LI>
<LI class=MsoNormal style="mso-list: l1 level1 lfo2; tab-stops: list .5in">When 2xx is received for the Invite replace the route set and use it for further requests.</LI>
<LI class=MsoNormal style="mso-list: l1 level1 lfo2; tab-stops: list .5in">After dialog is confirmed ignore any Record-Route header in refresh Invite requests.</LI></OL>
<P class=MsoNormal>&nbsp;Is that correct? Especially number 3 of the client behavior.</P>
<P class=MsoNormal>What does the standard say?</P>
<P class=MsoNormal>Thanks,</P>
<P class=MsoNormal>Jay.</P>
<P>&nbsp;<B><I>Jonathan Rosenberg &lt;jdrosen@dynamicsoft.com&gt;</I></B> wrote:
<BLOCKQUOTE style="BORDER-LEFT: #1010ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px">We had long discussions on replacing the route set. It had serious <BR>backwards compatibility issues. We did conclude that it was possible to <BR>define an extension that allowed you to explicitly ask to be removed <BR>from the route set. So, if you feel you really need this feature, please <BR>go ahead and write up some reuqirements and a proposed mechanism.<BR><BR>-Jonathan R.<BR><BR>jh@lohi.eng.song.fi wrote:<BR>&gt; hisham.khartabil@nokia.com writes:<BR>&gt; <BR>&gt; &gt; Replace. Also the 2xx that confirms the dialog replaces the route<BR>&gt; &gt; set. After that, route set is not replaceable. <BR>&gt; <BR>&gt; which is a bad thing and should be considered a bug.<BR>&gt; <BR>&gt; -- juha<BR>&gt; <BR>&gt; _______________________________________________<BR>&gt; Sip mailing list https://www1.ietf.org/mailman/listinfo/sip<BR>&gt; This list is for NEW development of the core SIP Protoco!
 l<BR>&gt; Use sip-implementors@cs.columbia.edu for questions on current sip<BR>&gt; Use sipping@ietf.org for new developments on the application of sip<BR>&gt; <BR><BR>-- <BR>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza<BR>Chief Scientist Parsippany, NJ 07054-2711<BR>dynamicsoft<BR>jdrosen@dynamicsoft.com FAX: (973) 952-5050<BR>http://www.jdrosen.net PHONE: (973) 952-5000<BR>http://www.dynamicsoft.com<BR><BR>_______________________________________________<BR>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip<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><p><br><hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/finance/mailsig/*http://tax.yahoo.com">Yahoo! Tax Center</a> - File online, calculators, forms, and more
--0-1719648727-1049366519=:97978--
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Thu Apr  3 06:03:13 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13691
	for <sip-archive@odin.ietf.org>; Thu, 3 Apr 2003 06:03:13 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h33B5QR01379
	for sip-archive@odin.ietf.org; Thu, 3 Apr 2003 06:05:26 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33B3MK01273;
	Thu, 3 Apr 2003 06:03:22 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33B03K01062
	for <sip@optimus.ietf.org>; Thu, 3 Apr 2003 06:00:03 -0500
Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13374
	for <sip@ietf.org>; Thu, 3 Apr 2003 05:57:18 -0500 (EST)
Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125])
	by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h33AxjRs027485;
	Thu, 3 Apr 2003 12:59:45 +0200 (MEST)
Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55)
	id 2A4979JP; Thu, 3 Apr 2003 12:59:45 +0200
Received: from lmf.ericsson.se ([131.160.31.93])
	by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h33AxjAv027071;
	Thu, 3 Apr 2003 13:59:45 +0300 (EET DST)
Message-ID: <3E8C1420.C8465FAE@lmf.ericsson.se>
Date: Thu, 03 Apr 2003 13:59:44 +0300
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jay Morris <jay_m_morris@yahoo.com>
CC: Jonathan Rosenberg <jdrosen@dynamicsoft.com>, jh@lohi.eng.song.fi,
        hisham.khartabil@nokia.com, sip@ietf.org
Subject: Re: [Sip] Record-Route and 1xx
References: <20030403104159.99414.qmail@web20514.mail.yahoo.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit


Hi,

I would say number 3 for the client behaviour is correct, as long as you
remember that it is per leg (or whatever we call it nowadays...),
identified by the To header tag.

I had some issues on the changing of route set in 18x and 200, in the
"Re: [Sip] NOTIFY establishes a dialog" thread, but I haven't seen any
comments on those...

Regards,

Christer Holmberg
Ericsson Finland



Jay Morris wrote:

> Actually, my question was naive. I don’t need any special feature, I
> just want to do things according to the standard and now I am really
> confused about what I should do.
>
> I summarize below the behavior I think is according to the standard.
> Please correct me if I’m wrong:
>
>  Server behavior:
>
>   1. When an Initial Invite is received take Record-Route list from
>      message and build internal route list.
>   2. Copy record route list to any 1xx (other then 100) response of
>      the invite.
>   3. Copy record route list to the Invite 2xx response.
>   4. Use the route list for routing any outgoing request.
>   5. After dialog is confirmed ignore any Record-Route header in
>      refresh Invite requests.
>
>  Client behavior
>
>   1. When first 1xx response is received take Record Route list from
>      the response message and build a temporary route set.
>   2. Use this route set for any request sent before the dialog moves
>      to the confirmed state.
>   3. Ignore Record Route headers of other 1xx responses.
>   4. When 2xx is received for the Invite replace the route set and use
>      it for further requests.
>   5. After dialog is confirmed ignore any Record-Route header in
>      refresh Invite requests.
>
>  Is that correct? Especially number 3 of the client behavior.
>
> What does the standard say?
>
> Thanks,
>
> Jay.
>
>  Jonathan Rosenberg <jdrosen@dynamicsoft.com> wrote:
>
>      We had long discussions on replacing the route set. It had
>      serious
>      backwards compatibility issues. We did conclude that it was
>      possible to
>      define an extension that allowed you to explicitly ask to be
>      removed
>      from the route set. So, if you feel you really need this
>      feature, please
>      go ahead and write up some reuqirements and a proposed
>      mechanism.
>
>      -Jonathan R.
>
>      jh@lohi.eng.song.fi wrote:
>      > hisham.khartabil@nokia.com writes:
>      >
>      > > Replace. Also the 2xx that confirms the dialog replaces
>      the route
>      > > set. After that, route set is not replaceable.
>      >
>      > which is a bad thing and should be considered a bug.
>      >
>      > -- juha
>      >
>      > _______________________________________________
>      > Sip mailing list
>      https://www1.ietf.org/mailmaan/listinfo/sip
>      > This list is for NEW development of the core SIP Protoco!
>      l
>      > 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 Scientist Parsippany, NJ 07054-2711
>      dynamicsoft
>      jdrosen@ddynamicsoft.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
>
>
> -----------------------------------------------------------------------
> Do you Yahoo!?
> Yahoo! Tax Center - File online, calculators, forms, and more

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



From mailnull@www1.ietf.org  Thu Apr  3 06:27:39 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14135
	for <sip-archive@odin.ietf.org>; Thu, 3 Apr 2003 06:27:39 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h33BTqH03281
	for sip-archive@odin.ietf.org; Thu, 3 Apr 2003 06:29:52 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33BRkK03209;
	Thu, 3 Apr 2003 06:27:46 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33BOLK03064
	for <sip@optimus.ietf.org>; Thu, 3 Apr 2003 06:24:21 -0500
Received: from rautu (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14018
	for <sip@ietf.org>; Thu, 3 Apr 2003 06:21:31 -0500 (EST)
Received: from jh by rautu with local (Exim 3.35 #1 (Debian))
	id 1912gR-000089-00; Thu, 03 Apr 2003 14:15:03 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16012.6029.710352.281381@lohi.eng.song.fi>
Date: Thu, 3 Apr 2003 14:14:21 +0300
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: hisham.khartabil@nokia.com, jay_m_morris@yahoo.com, sip@ietf.org
Subject: Re: [Sip] Record-Route and 1xx
In-Reply-To: <3E8BF1B1.4050903@dynamicsoft.com>
References: <2038BCC78B1AD641891A0D1AE133DBB7FE7483@esebe019.ntc.nokia.com>
        <16011.68.389612.344249@harjus.eng.song.fi>
        <3E8BF1B1.4050903@dynamicsoft.com>
X-Mailer: VM 7.07 under Emacs 21.2.1
From: Juha Heinanen <jh@lohi.eng.song.fi>
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 writes:
                                                                                
 > We had long discussions on replacing the route set. It had serious
 > backwards compatibility issues. We did conclude that it was possible
 > to define an extension that allowed you to explicitly ask to be
 > removed from the route set. So, if you feel you really need this
 > feature, please go ahead and write up some reuqirements and a
 > proposed mechanism.

for example, if my dual mode (mobile network, wlan) UA has started a
dialog at a mobile network and then does a re-invite at a wlan hotspot,
i want that re-invite to change the ENTIRE route set. otherwise it is
highly likely (based on past experience on the behavior of mobile
operators) that they would keep on charging me for the rest of the call
per minute until their proxy sees the bye.  the same holds for things
like presence notifications.  i don't what them to keep on going back to
the proxy of the mobile operator.

my proposal is simply to change the route set and update the UAs
accordingly.

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



From mailnull@www1.ietf.org  Thu Apr  3 06:49:58 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14998
	for <sip-archive@odin.ietf.org>; Thu, 3 Apr 2003 06:49:57 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h33BqBX05481
	for sip-archive@odin.ietf.org; Thu, 3 Apr 2003 06:52:11 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33BnvK05374;
	Thu, 3 Apr 2003 06:49:57 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33BkQK04978
	for <sip@optimus.ietf.org>; Thu, 3 Apr 2003 06:46:26 -0500
Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14815
	for <sip@ietf.org>; Thu, 3 Apr 2003 06:43:41 -0500 (EST)
Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120])
	by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h33Bk7Rs012336;
	Thu, 3 Apr 2003 13:46:07 +0200 (MEST)
Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55)
	id 2A4K0V2Q; Thu, 3 Apr 2003 13:46:08 +0200
Received: from lmf.ericsson.se ([131.160.31.93])
	by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h33Bk8Av000025;
	Thu, 3 Apr 2003 14:46:08 +0300 (EET DST)
Message-ID: <3E8C1EFF.C836FC1A@lmf.ericsson.se>
Date: Thu, 03 Apr 2003 14:46:07 +0300
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Juha Heinanen <jh@lohi.eng.song.fi>
CC: Jonathan Rosenberg <jdrosen@dynamicsoft.com>, hisham.khartabil@nokia.com,
        jay_m_morris@yahoo.com, sip@ietf.org
Subject: Re: [Sip] Record-Route and 1xx
References: <2038BCC78B1AD641891A0D1AE133DBB7FE7483@esebe019.ntc.nokia.com>
	        <16011.68.389612.344249@harjus.eng.song.fi>
	        <3E8BF1B1.4050903@dynamicsoft.com> <16012.6029.710352.281381@lohi.eng.song.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit


Hi Juha,

How can you make sure that the re-INVITE will reach the UAS, if you send it
to another proxy? Or, would you insert the WHOLE new route set in the
re-INVITE, including all the proxies between yourself and the UAS? How will
your terminal know that route set?

I am not saying it wouldn't be useful to change the route set during the
session - I am just trying to understand your example :)

What I would like to see also, is an example where it is useful to change
the route set between the 18x and 200 of the initial INVITE. In the other
mail I mentioned some issue which could came up with such behvaiour...

Regards,

Christer Holmberg
Ericsson Finland


Juha Heinanen wrote:

> Jonathan Rosenberg writes:
>
>  > We had long discussions on replacing the route set. It had serious
>  > backwards compatibility issues. We did conclude that it was possible
>  > to define an extension that allowed you to explicitly ask to be
>  > removed from the route set. So, if you feel you really need this
>  > feature, please go ahead and write up some reuqirements and a
>  > proposed mechanism.
>
> for example, if my dual mode (mobile network, wlan) UA has started a
> dialog at a mobile network and then does a re-invite at a wlan hotspot,
> i want that re-invite to change the ENTIRE route set. otherwise it is
> highly likely (based on past experience on the behavior of mobile
> operators) that they would keep on charging me for the rest of the call
> per minute until their proxy sees the bye.  the same holds for things
> like presence notifications.  i don't what them to keep on going back to
> the proxy of the mobile operator.
>
> my proposal is simply to change the route set and update the UAs
> accordingly.
>
> -- juha
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip

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



From mailnull@www1.ietf.org  Thu Apr  3 07:11:27 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16888
	for <sip-archive@odin.ietf.org>; Thu, 3 Apr 2003 07:11:27 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h33CDfZ07563
	for sip-archive@odin.ietf.org; Thu, 3 Apr 2003 07:13:41 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33CBVK07456;
	Thu, 3 Apr 2003 07:11:31 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33C84K07328
	for <sip@optimus.ietf.org>; Thu, 3 Apr 2003 07:08:05 -0500
Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16721
	for <sip@ietf.org>; Thu, 3 Apr 2003 07:05:19 -0500 (EST)
From: hisham.khartabil@nokia.com
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.5) with ESMTP id h33CBj522801
	for <sip@ietf.org>; Thu, 3 Apr 2003 15:11:45 +0300 (EET DST)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T61607a5acfac158f23118@esvir03nok.nokia.com>;
 Thu, 3 Apr 2003 15:07:39 +0300
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Thu, 3 Apr 2003 15:07:36 +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"
Subject: RE: [Sip] Record-Route and 1xx
Date: Thu, 3 Apr 2003 15:07:36 +0300
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE7498@esebe019.ntc.nokia.com>
Thread-Topic: [Sip] Record-Route and 1xx
Thread-Index: AcL51Wg0t5wdjmfjRDW4rKZcAzYVAgAA8vIQ
To: <jh@lohi.eng.song.fi>, <jdrosen@dynamicsoft.com>
Cc: <jay_m_morris@yahoo.com>, <sip@ietf.org>
X-OriginalArrivalTime: 03 Apr 2003 12:07:36.0779 (UTC) FILETIME=[9DA411B0:01C2F9D9]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h33C85K07329
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit

How do you change the whole route set when you use the remote-target uri to populate the request-uri? You must know the route set before hand or have to break the rule where you place the remote-target in the request-URI for requests within dialogs.

You could simply build an application that moves you into a new call but does not result in breaking your media.

/Hisham

> -----Original Message-----
> From: ext Juha Heinanen [mailto:jh@lohi.eng.song.fi]
> Sent: Thursday, April 03, 2003 2:14 PM
> To: Jonathan Rosenberg
> Cc: Khartabil Hisham (NMP/Helsinki); jay_m_morris@yahoo.com;
> sip@ietf.org
> Subject: Re: [Sip] Record-Route and 1xx
> 
> 
> Jonathan Rosenberg writes:
>                                                               
>                   
>  > We had long discussions on replacing the route set. It had serious
>  > backwards compatibility issues. We did conclude that it 
> was possible
>  > to define an extension that allowed you to explicitly ask to be
>  > removed from the route set. So, if you feel you really need this
>  > feature, please go ahead and write up some reuqirements and a
>  > proposed mechanism.
> 
> for example, if my dual mode (mobile network, wlan) UA has started a
> dialog at a mobile network and then does a re-invite at a 
> wlan hotspot,
> i want that re-invite to change the ENTIRE route set. otherwise it is
> highly likely (based on past experience on the behavior of mobile
> operators) that they would keep on charging me for the rest 
> of the call
> per minute until their proxy sees the bye.  the same holds for things
> like presence notifications.  i don't what them to keep on 
> going back to
> the proxy of the mobile operator.
> 
> my proposal is simply to change the route set and update the UAs
> accordingly.
> 
> -- juha
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Thu Apr  3 07:19:04 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17212
	for <sip-archive@odin.ietf.org>; Thu, 3 Apr 2003 07:19:04 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h33CLIa08022
	for sip-archive@odin.ietf.org; Thu, 3 Apr 2003 07:21:18 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33CJEK07859;
	Thu, 3 Apr 2003 07:19:14 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33CGCK07695
	for <sip@optimus.ietf.org>; Thu, 3 Apr 2003 07:16:12 -0500
Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16947
	for <sip@ietf.org>; Thu, 3 Apr 2003 07:13:27 -0500 (EST)
From: jh@lohi.eng.song.fi
Received: from harjus.eng.song.fi ([195.10.149.20])
	by lohi.eng.song.fi with esmtp (Exim 3.36 #1 (Debian))
	id 1913dK-0000lo-00; Thu, 03 Apr 2003 15:15:54 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16012.9722.145670.375833@harjus.eng.song.fi>
Date: Thu, 3 Apr 2003 15:15:54 +0300
To: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
Cc: Jonathan Rosenberg <jdrosen@dynamicsoft.com>, hisham.khartabil@nokia.com,
        jay_m_morris@yahoo.com, sip@ietf.org
Subject: Re: [Sip] Record-Route and 1xx
In-Reply-To: <3E8C1EFF.C836FC1A@lmf.ericsson.se>
References: <2038BCC78B1AD641891A0D1AE133DBB7FE7483@esebe019.ntc.nokia.com>
	<16011.68.389612.344249@harjus.eng.song.fi>
	<3E8BF1B1.4050903@dynamicsoft.com>
	<16012.6029.710352.281381@lohi.eng.song.fi>
	<3E8C1EFF.C836FC1A@lmf.ericsson.se>
X-Mailer: VM 7.07 under Emacs 21.2.1
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Christer Holmberg writes:

 > How can you make sure that the re-INVITE will reach the UAS, if you send it
 > to another proxy? Or, would you insert the WHOLE new route set in the
 > re-INVITE, including all the proxies between yourself and the UAS? How will
 > your terminal know that route set?

i guess i didn't make myself clear.  when my UA connects to the wlan, it
learns its outbound proxy (if any) via dhcp.  it then issues a normal
invite which gets record routed by the (possible) new set of proxies.
that new recorded route will then be used for subsequent request and the
mobile operators' proxies are out of the loop.

-- juha



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



From mailnull@www1.ietf.org  Thu Apr  3 07:44:47 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17827
	for <sip-archive@odin.ietf.org>; Thu, 3 Apr 2003 07:44:47 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h33Cl2F10387
	for sip-archive@odin.ietf.org; Thu, 3 Apr 2003 07:47:02 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33CkcK10362;
	Thu, 3 Apr 2003 07:46:38 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33ChtK10157
	for <sip@optimus.ietf.org>; Thu, 3 Apr 2003 07:43:55 -0500
Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17765
	for <sip@ietf.org>; Thu, 3 Apr 2003 07:41:09 -0500 (EST)
Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125])
	by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h33ChZI3012612;
	Thu, 3 Apr 2003 14:43:35 +0200 (MEST)
Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55)
	id 2A49880N; Thu, 3 Apr 2003 14:43:36 +0200
Received: from lmf.ericsson.se ([131.160.31.93])
	by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h33ChaAv004227;
	Thu, 3 Apr 2003 15:43:36 +0300 (EET DST)
Message-ID: <3E8C2C77.DC9173F3@lmf.ericsson.se>
Date: Thu, 03 Apr 2003 15:43:35 +0300
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: jh@lohi.eng.song.fi
CC: Jonathan Rosenberg <jdrosen@dynamicsoft.com>, hisham.khartabil@nokia.com,
        jay_m_morris@yahoo.com, sip@ietf.org
Subject: Re: [Sip] Record-Route and 1xx
References: <2038BCC78B1AD641891A0D1AE133DBB7FE7483@esebe019.ntc.nokia.com>
		<16011.68.389612.344249@harjus.eng.song.fi>
		<3E8BF1B1.4050903@dynamicsoft.com>
		<16012.6029.710352.281381@lohi.eng.song.fi>
		<3E8C1EFF.C836FC1A@lmf.ericsson.se> <16012.9722.145670.375833@harjus.eng.song.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit


Hi Juha,

>  >How can you make sure that the re-INVITE will reach the UAS, if you send it
>  >to another proxy? Or, would you insert the WHOLE new route set in the
>  >re-INVITE, including all the proxies between yourself and the UAS? How will
>  >your terminal know that route set?
>
> i guess i didn't make myself clear.  when my UA connects to the wlan, it
> learns its outbound proxy (if any) via dhcp.  it then issues a normal
> invite which gets record routed by the (possible) new set of proxies.
> that new recorded route will then be used for subsequent request and the
> mobile operators' proxies are out of the loop.

Well, then my question is, again: how can you be sure that the re-INVITE, send to
the "new" outbound proxy, will actually reach the same UAS you are currently
having a session with?

Regards,

Christer Holmberg
Ericsson Finland

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



From mailnull@www1.ietf.org  Thu Apr  3 09:04:42 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20220
	for <sip-archive@odin.ietf.org>; Thu, 3 Apr 2003 09:04:42 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h33E6xb16330
	for sip-archive@odin.ietf.org; Thu, 3 Apr 2003 09:06:59 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33E6JK16266;
	Thu, 3 Apr 2003 09:06:19 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33E0GK15970
	for <sip@optimus.ietf.org>; Thu, 3 Apr 2003 09:00:16 -0500
Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20013
	for <sip@ietf.org>; Thu, 3 Apr 2003 08:57:27 -0500 (EST)
From: jh@lohi.eng.song.fi
Received: from harjus.eng.song.fi ([195.10.149.20])
	by lohi.eng.song.fi with esmtp (Exim 3.36 #1 (Debian))
	id 1915Fz-0000tu-00; Thu, 03 Apr 2003 16:59:55 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16012.15963.71111.547859@harjus.eng.song.fi>
Date: Thu, 3 Apr 2003 16:59:55 +0300
To: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
Cc: Jonathan Rosenberg <jdrosen@dynamicsoft.com>, hisham.khartabil@nokia.com,
        jay_m_morris@yahoo.com, sip@ietf.org
Subject: Re: [Sip] Record-Route and 1xx
In-Reply-To: <3E8C2C77.DC9173F3@lmf.ericsson.se>
References: <2038BCC78B1AD641891A0D1AE133DBB7FE7483@esebe019.ntc.nokia.com>
	<16011.68.389612.344249@harjus.eng.song.fi>
	<3E8BF1B1.4050903@dynamicsoft.com>
	<16012.6029.710352.281381@lohi.eng.song.fi>
	<3E8C1EFF.C836FC1A@lmf.ericsson.se>
	<16012.9722.145670.375833@harjus.eng.song.fi>
	<3E8C2C77.DC9173F3@lmf.ericsson.se>
X-Mailer: VM 7.07 under Emacs 21.2.1
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Christer Holmberg writes:

 > Well, then my question is, again: how can you be sure that the
 > re-INVITE, send to the "new" outbound proxy, will actually reach the
 > same UAS you are currently having a session with?

the re-invite would be sent to the aor of the uas, i.e., not to its ip
address, and assuming that the uas is still registered, re-invite would
reach it.

by the way, like jonathan said, we should first discuss the requirements
and after that figure out the possible solutions.  and the requirement
is that when the ua moves to another network, a compete new route must
be recorded.

-- juha


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



From mailnull@www1.ietf.org  Thu Apr  3 09:26:08 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20890
	for <sip-archive@odin.ietf.org>; Thu, 3 Apr 2003 09:26:08 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h33ESQg18239
	for sip-archive@odin.ietf.org; Thu, 3 Apr 2003 09:28:26 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33ERtK18189;
	Thu, 3 Apr 2003 09:27:55 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33EMcK17951
	for <sip@optimus.ietf.org>; Thu, 3 Apr 2003 09:22:38 -0500
Received: from web20509.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20655
	for <sip@ietf.org>; Thu, 3 Apr 2003 09:19:45 -0500 (EST)
Message-ID: <20030403142208.68895.qmail@web20509.mail.yahoo.com>
Received: from [212.143.185.30] by web20509.mail.yahoo.com via HTTP; Thu, 03 Apr 2003 06:22:08 PST
Date: Thu, 3 Apr 2003 06:22:08 -0800 (PST)
From: Jay Morris <jay_m_morris@yahoo.com>
Subject: Re: [Sip] Record-Route and 1xx
To: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
Cc: Jonathan Rosenberg <jdrosen@dynamicsoft.com>, jh@lohi.eng.song.fi,
        hisham.khartabil@nokia.com, sip@ietf.org
In-Reply-To: <3E8C1420.C8465FAE@lmf.ericsson.se>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-202044022-1049379728=:67809"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-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-202044022-1049379728=:67809
Content-Type: text/plain; charset=us-ascii


Thanks for the response. 
Lets say that I have the following scenario
     UA1                 B2B1           B2B2          UA2
     
     -----INV------->
     
     <----180 rel---
     
     -----PRACK----->
     
     <----200--------
                         
       
                      -----INV------->
     
                      <----180 rel---
     
     <------180 rel--     
     
     -----PRACK-----> ---PRACK-------->
     
     <----200-------- <----200--------
   
   
   If the UA1 will not update the route set according to the second 180 response the prack will never  get to B2B2.
   Is this even possible scenario?
   
Jay.
 Christer Holmberg <christer.holmberg@lmf.ericsson.se> wrote:
Hi,

I would say number 3 for the client behaviour is correct, as long as you
remember that it is per leg (or whatever we call it nowadays...),
identified by the To header tag.

I had some issues on the changing of route set in 18x and 200, in the
"Re: [Sip] NOTIFY establishes a dialog" thread, but I haven't seen any
comments on those...

Regards,

Christer Holmberg
Ericsson Finland



Jay Morris wrote:

> Actually, my question was naive. I don’t need any special feature, I
> just want to do things according to the standard and now I am really
> confused about what I should do.
>
> I summarize below the behavior I think is according to the standard.
> Please correct me if I’m wrong:
>
> Server behavior:
>
> 1. When an Initial Invite is received take Record-Route list from
> message and build internal route list.
> 2. Copy record route list to any 1xx (other then 100) response of
> the invite.
> 3. Copy record route list to the Invite 2xx response.
> 4. Use the route list for routing any outgoing request.
> 5. After dialog is confirmed ignore any Record-Route header in
> refresh Invite requests.
>
> Client behavior
>
> 1. When first 1xx response is received take Record Route list from
> the response message and build a temporary route set.
> 2. Use this route set for any request sent before the dialog moves
> to the confirmed state.
> 3. Ignore Record Route headers of other 1xx responses.
> 4. When 2xx is received for the Invite replace the route set and use
> it for further requests.
> 5. After dialog is confirmed ignore any Record-Route header in
> refresh Invite requests.
>
> Is that correct? Especially number 3 of the client behavior.
>
> What does the standard say?
>
> Thanks,
>
> Jay.
>
> Jonathan Rosenberg wrote:
>
> We had long discussions on replacing the route set. It had
> serious
> backwards compatibility issues. We did conclude that it was
> possible to
> define an extension that allowed you to explicitly ask to be
> removed
> from the route set. So, if you feel you really need this
> feature, please
> go ahead and write up some reuqirements and a proposed
> mechanism.
>
> -Jonathan R.
>
> jh@lohi.eng.song.fi wrote:
> > hisham.khartabil@nokia.com writes:
> >
> > > Replace. Also the 2xx that confirms the dialog replaces
> the route
> > > set. After that, route set is not replaceable.
> >
> > which is a bad thing and should be considered a bug.
> >
> > -- juha
> >
> > _______________________________________________
> > Sip mailing list
> https://www1.ietf.org/mailmaan/listinfo/sip
> > This list is for NEW development of the core SIP Protoco!
> l
> > 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 Scientist Parsippany, NJ 07054-2711
> dynamicsoft
> jdrosen@ddynamicsoft.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
>
>
> -----------------------------------------------------------------------
> Do you Yahoo!?
> Yahoo! Tax Center - File online, calculators, forms, and more



---------------------------------
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
--0-202044022-1049379728=:67809
Content-Type: text/html; charset=us-ascii

<P>Thanks for the response. <BR>Lets say that I have the following scenario
<P>&nbsp;&nbsp;&nbsp;&nbsp; UA1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; B2B1&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; B2B2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; UA2<BR>&nbsp;&nbsp;&nbsp;&nbsp; <BR>&nbsp;&nbsp;&nbsp;&nbsp; -----INV-------&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp; <BR>&nbsp;&nbsp;&nbsp;&nbsp; &lt;----180 rel---<BR>&nbsp;&nbsp;&nbsp;&nbsp; <BR>&nbsp;&nbsp;&nbsp;&nbsp; -----PRACK-----&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp; <BR>&nbsp;&nbsp;&nbsp;&nbsp; &lt;----200--------<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -----INV-------&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp; <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs!
 p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;----180 rel---<BR>&nbsp;&nbsp;&nbsp;&nbsp; <BR>&nbsp;&nbsp;&nbsp;&nbsp; &lt;------180 rel--&nbsp;&nbsp;&nbsp;&nbsp; <BR>&nbsp;&nbsp;&nbsp;&nbsp; <BR>&nbsp;&nbsp;&nbsp;&nbsp; -----PRACK-----&gt; ---PRACK--------&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp; <BR>&nbsp;&nbsp;&nbsp;&nbsp; &lt;----200-------- &lt;----200--------<BR>&nbsp;&nbsp; <BR>&nbsp;&nbsp; <BR>&nbsp;&nbsp; If the UA1 will not update the route&nbsp;set according to the second 180 response the prack will never&nbsp; get to B2B2.<BR>&nbsp;&nbsp; Is this even possible scenario?<BR>&nbsp;&nbsp; 
<P>Jay.
<P>&nbsp;<B><I>Christer Holmberg &lt;christer.holmberg@lmf.ericsson.se&gt;</I></B> wrote:
<BLOCKQUOTE style="BORDER-LEFT: #1010ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px"><BR>Hi,<BR><BR>I would say number 3 for the client behaviour is correct, as long as you<BR>remember that it is per leg (or whatever we call it nowadays...),<BR>identified by the To header tag.<BR><BR>I had some issues on the changing of route set in 18x and 200, in the<BR>"Re: [Sip] NOTIFY establishes a dialog" thread, but I haven't seen any<BR>comments on those...<BR><BR>Regards,<BR><BR>Christer Holmberg<BR>Ericsson Finland<BR><BR><BR><BR>Jay Morris wrote:<BR><BR>&gt; Actually, my question was naive. I don’t need any special feature, I<BR>&gt; just want to do things according to the standard and now I am really<BR>&gt; confused about what I should do.<BR>&gt;<BR>&gt; I summarize below the behavior I think is according to the standard.<BR>&gt; Please correct me if I’m wrong:<BR>&gt;<BR>&gt; Server behavior:<BR>&gt;<BR>&gt; 1. When an Initial Invite is received take Record-Route list from<!
 BR>&gt; message and build internal route list.<BR>&gt; 2. Copy record route list to any 1xx (other then 100) response of<BR>&gt; the invite.<BR>&gt; 3. Copy record route list to the Invite 2xx response.<BR>&gt; 4. Use the route list for routing any outgoing request.<BR>&gt; 5. After dialog is confirmed ignore any Record-Route header in<BR>&gt; refresh Invite requests.<BR>&gt;<BR>&gt; Client behavior<BR>&gt;<BR>&gt; 1. When first 1xx response is received take Record Route list from<BR>&gt; the response message and build a temporary route set.<BR>&gt; 2. Use this route set for any request sent before the dialog moves<BR>&gt; to the confirmed state.<BR>&gt; 3. Ignore Record Route headers of other 1xx responses.<BR>&gt; 4. When 2xx is received for the Invite replace the route set and use<BR>&gt; it for further requests.<BR>&gt; 5. After dialog is confirmed ignore any Record-Route header in<BR>&gt; refresh Invite requests.<BR>&gt;<BR>&gt; Is that correct? Especially number 3 of !
 the client behavior.<BR>&gt;<BR>&gt; What does the standard say?<BR>&g
t;<BR>&gt; Thanks,<BR>&gt;<BR>&gt; Jay.<BR>&gt;<BR>&gt; Jonathan Rosenberg <JDROSEN@DYNAMICSOFT.COM>wrote:<BR>&gt;<BR>&gt; We had long discussions on replacing the route set. It had<BR>&gt; serious<BR>&gt; backwards compatibility issues. We did conclude that it was<BR>&gt; possible to<BR>&gt; define an extension that allowed you to explicitly ask to be<BR>&gt; removed<BR>&gt; from the route set. So, if you feel you really need this<BR>&gt; feature, please<BR>&gt; go ahead and write up some reuqirements and a proposed<BR>&gt; mechanism.<BR>&gt;<BR>&gt; -Jonathan R.<BR>&gt;<BR>&gt; jh@lohi.eng.song.fi wrote:<BR>&gt; &gt; hisham.khartabil@nokia.com writes:<BR>&gt; &gt;<BR>&gt; &gt; &gt; Replace. Also the 2xx that confirms the dialog replaces<BR>&gt; the route<BR>&gt; &gt; &gt; set. After that, route set is not replaceable.<BR>&gt; &gt;<BR>&gt; &gt; which is a bad thing and should be considered a bug.<BR>&gt; &gt;<BR>&gt; &gt; -- juha<BR>&gt; &gt;<BR>&gt; &gt; __________________!
 _____________________________<BR>&gt; &gt; Sip mailing list<BR>&gt; https://www1.ietf.org/mailmaan/listinfo/sip<BR>&gt; &gt; This list is for NEW development of the core SIP Protoco!<BR>&gt; l<BR>&gt; &gt; Use sip-implementors@cs.columbia.edu for questions on<BR>&gt; current sip<BR>&gt; &gt; Use sipping@ietf.org for new developments on the<BR>&gt; application of sip<BR>&gt; &gt;<BR>&gt;<BR>&gt; --<BR>&gt; Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza<BR>&gt; Chief Scientist Parsippany, NJ 07054-2711<BR>&gt; dynamicsoft<BR>&gt; jdrosen@ddynamicsoft.com FAX: (973) 952-5050<BR>&gt; http://www.jdrosen.net PHONE: (973) 952-5000<BR>&gt; http://www.dynamicsoft.com<BR>&gt;<BR>&gt; _______________________________________________<BR>&gt; Sip mailing list https://www1.ietf.org/mailman/listinfo/sip<BR>&gt; This list is for NEW development of the core SIP Protocol<BR>&gt; Use sip-implementors@cs.columbia.edu for questions on<BR>&gt; current sip<BR>&gt; Use sipping@ietf.org for new deve!
 lopments on the application<BR>&gt; of sip<BR>&gt;<BR>&gt;<BR>&gt; ---
--------------------------------------------------------------------<BR>&gt; Do you Yahoo!?<BR>&gt; Yahoo! Tax Center - File online, calculators, forms, and more<BR></BLOCKQUOTE><p><br><hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/finance/mailsig/*http://tax.yahoo.com">Yahoo! Tax Center</a> - File online, calculators, forms, and more
--0-202044022-1049379728=:67809--
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Thu Apr  3 09:45:55 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21715
	for <sip-archive@odin.ietf.org>; Thu, 3 Apr 2003 09:45:55 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h33EmDA20724
	for sip-archive@odin.ietf.org; Thu, 3 Apr 2003 09:48:13 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33EljK20626;
	Thu, 3 Apr 2003 09:47:45 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33EgYK20296
	for <sip@optimus.ietf.org>; Thu, 3 Apr 2003 09:42:34 -0500
Received: from zrc2s0jx.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21500
	for <sip@ietf.org>; Thu, 3 Apr 2003 09:39:45 -0500 (EST)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h33Eg2804903;
	Thu, 3 Apr 2003 08:42:06 -0600 (CST)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <HNP4QG6B>; Thu, 3 Apr 2003 08:42:03 -0600
Message-ID: <1B54FA3A2709D51195C800508BF9386A09DABC24@zrc2c000.us.nortel.com>
From: "Mary Barnes" <mbarnes@nortelnetworks.com>
To: murali <muraliv@bharatmail.com>
Cc: sip@ietf.org
Subject: RE: [Sip] sip grammar
Date: Thu, 3 Apr 2003 08:42:00 -0600 
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

Hi Murali,

Just as an FYI, you're looking at an old document, so it's not surprising
there might be some errors.  The call flows were moved to the SIPPING WG and
they're now in 3 separate documents:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-basic-call-flows-01.t
xt
http://www.ietf.org/internet-drafts/draft-ietf-sipping-pstn-call-flows-01.tx
t
http://www.ietf.org/internet-drafts/draft-ietf-sipping-torture-tests-00.txt

And then there's a fourth document with service examples:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-service-examples-04.t
xt

Regards,
Mary H. Barnes

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Thursday, April 03, 2003 3:15 AM
To: murali
Cc: sip@ietf.org
Subject: Re: [Sip] sip grammar


The example message is not correct. The angle brackets need to be around 
the URI.

-Jonathan R.

murali wrote:
> Hi,
> 
> 	When i was going through the SIP Document:
draft-ietf-sip-call-flows-05.txt
> i came across a From Header which is like this
> 
> INVITE sip:+1-650-555-2222@ss1.wcom.com;user=phone SIP/2.0
> Via: SIP/2.0/UDP ift.here.com:5060
> From: sip:+1-303-555-1111@ift.here.com;user=phone
> To: <sip:+1-650-555-2222@ss1.wcom.com;user=phone>
> Call-ID: 1717@ift.here.com
> CSeq: 17 INVITE
> Contact: <sip:+1-303-555-1111@ift.here.com;user=phone>
> Content-Type: application/sdp
> Content-Length: 146
> 
> v=0
> o=IFAXTERMINAL01 2890844527 2890844527 IN IP4 ift.here.com
> s=Session SDP
> c=IN IP4 iftmg.here.com
> t=0 0
> m=audio 3456 RTP/AVP 0
> a=rtpmap:0 PCMU/8000
> (Ref: 3.1.7 Successful SIP to SIP with re-INVITE) 
> 
> but Section 20.20 of RFC 3261 says that
> "Even if the "display-name" is empty, the "name-addr" form MUST be 
> used if the "addr-spec" contains a comma, question mark, or semicolon"
> 
> so, i'd like to know if the above usage is correct?
>  In case it is correct how do i differentiate between the from parameters
and URI-parameters as both are delimited by ;.
> I mean to say that i can very well take that(user=phone) as generic
parameter in from parameters instead of taking it as uri parameter
> 
> Thanks in advance
> Murali
> 
> 
> 
> -------
> Murali Voleti,
> #503,Maheswari complex,
> Masab Tank,
> Hyderabad
> Tele:(040) 6502272 ext:211
> 
> _____________________________________________________________
> Get Your Free ScanMail and Email At http://mail.ttkbharatplanet.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 Scientist                             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 mailnull@www1.ietf.org  Thu Apr  3 10:18:32 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24399
	for <sip-archive@odin.ietf.org>; Thu, 3 Apr 2003 10:18:32 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h33FKpa23643
	for sip-archive@odin.ietf.org; Thu, 3 Apr 2003 10:20:51 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33FKAK23566;
	Thu, 3 Apr 2003 10:20:10 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33F4bK21881
	for <sip@optimus.ietf.org>; Thu, 3 Apr 2003 10:04:37 -0500
Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22320
	for <sip@ietf.org>; Thu, 3 Apr 2003 10:01:48 -0500 (EST)
From: jh@lohi.eng.song.fi
Received: from harjus.eng.song.fi ([195.10.149.20])
	by lohi.eng.song.fi with esmtp (Exim 3.36 #1 (Debian))
	id 1916GG-0000zB-00; Thu, 03 Apr 2003 18:04:16 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16012.19824.504350.572522@harjus.eng.song.fi>
Date: Thu, 3 Apr 2003 18:04:16 +0300
To: Christer Holmberg <christer.holmberg@lmf.ericsson.se>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        hisham.khartabil@nokia.com, jay_m_morris@yahoo.com, sip@ietf.org
Subject: Re: [Sip] Record-Route and 1xx
In-Reply-To: <16012.15963.71111.547859@harjus.eng.song.fi>
References: <2038BCC78B1AD641891A0D1AE133DBB7FE7483@esebe019.ntc.nokia.com>
	<16011.68.389612.344249@harjus.eng.song.fi>
	<3E8BF1B1.4050903@dynamicsoft.com>
	<16012.6029.710352.281381@lohi.eng.song.fi>
	<3E8C1EFF.C836FC1A@lmf.ericsson.se>
	<16012.9722.145670.375833@harjus.eng.song.fi>
	<3E8C2C77.DC9173F3@lmf.ericsson.se>
	<16012.15963.71111.547859@harjus.eng.song.fi>
X-Mailer: VM 7.07 under Emacs 21.2.1
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

may be jonathan's uri leasing stuff could be useful in getting the
re-invite to the uas.

-- juha

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



From mailnull@www1.ietf.org  Thu Apr  3 10:23:49 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24603
	for <sip-archive@odin.ietf.org>; Thu, 3 Apr 2003 10:23:49 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h33FQ8C23964
	for sip-archive@odin.ietf.org; Thu, 3 Apr 2003 10:26:08 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33FPXK23937;
	Thu, 3 Apr 2003 10:25:33 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33F7IK22479
	for <sip@optimus.ietf.org>; Thu, 3 Apr 2003 10:07:18 -0500
Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22606
	for <sip@ietf.org>; Thu, 3 Apr 2003 10:04:28 -0500 (EST)
From: aki.niemi@nokia.com
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.5) with ESMTP id h33FAt528731
	for <sip@ietf.org>; Thu, 3 Apr 2003 18:10:55 +0300 (EET DST)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T61611e7e4dac158f24991@esvir04nok.ntc.nokia.com>;
 Thu, 3 Apr 2003 18:06:56 +0300
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Thu, 3 Apr 2003 18:06:55 +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"
Subject: RE: [Sip] Record-Route and 1xx
Date: Thu, 3 Apr 2003 18:06:55 +0300
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9019451FC@esebe013.ntc.nokia.com>
Thread-Topic: [Sip] Record-Route and 1xx
Thread-Index: AcL560dZdVzRjMIORF2ydm3YLltGewABeu9g
To: <jh@lohi.eng.song.fi>, <christer.holmberg@lmf.ericsson.se>
Cc: <jdrosen@dynamicsoft.com>, <hisham.khartabil@nokia.com>,
        <jay_m_morris@yahoo.com>, <sip@ietf.org>
X-OriginalArrivalTime: 03 Apr 2003 15:06:55.0976 (UTC) FILETIME=[AA9F3E80:01C2F9F2]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h33F7IK22480
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit

Hi Juha,

 > -----Original Message-----
 > From: ext jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi]
 > Sent: 03 April, 2003 17:00
 > To: Christer Holmberg
 > Cc: Jonathan Rosenberg; Khartabil Hisham (NMP/Helsinki);
 > jay_m_morris@yahoo.com; sip@ietf.org
 > Subject: Re: [Sip] Record-Route and 1xx
 > 
 > 
 > Christer Holmberg writes:
 > 
 >  > Well, then my question is, again: how can you be sure that the
 >  > re-INVITE, send to the "new" outbound proxy, will 
 > actually reach the
 >  > same UAS you are currently having a session with?
 > 
 > the re-invite would be sent to the aor of the uas, i.e., not 
 > to its ip
 > address, and assuming that the uas is still registered, 
 > re-invite would
 > reach it.

Not necessarily. There are no guarantees that the proxies route the request to the exact same UA. For example, there may have been a CPL script in place that takes time of day into account.

 > by the way, like jonathan said, we should first discuss the 
 > requirements
 > and after that figure out the possible solutions.  and the 
 > requirement
 > is that when the ua moves to another network, a compete new 
 > route must
 > be recorded.

There is a contradiction within that requirement. A route set is inherent to a dialog, hence it cannot be changed without replacing the rest of the dialog, i.e., making a completely new INVITE instead of a re-INVITE.

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 mailnull@www1.ietf.org  Thu Apr  3 10:44:05 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25828
	for <sip-archive@odin.ietf.org>; Thu, 3 Apr 2003 10:44:05 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h33FkOv26730
	for sip-archive@odin.ietf.org; Thu, 3 Apr 2003 10:46:24 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33FhZK26343;
	Thu, 3 Apr 2003 10:43:35 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33FbtK25731
	for <sip@optimus.ietf.org>; Thu, 3 Apr 2003 10:37:55 -0500
Received: from web20505.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25282
	for <sip@ietf.org>; Thu, 3 Apr 2003 10:35:04 -0500 (EST)
Message-ID: <20030403153733.88278.qmail@web20505.mail.yahoo.com>
Received: from [212.143.185.30] by web20505.mail.yahoo.com via HTTP; Thu, 03 Apr 2003 07:37:33 PST
Date: Thu, 3 Apr 2003 07:37:33 -0800 (PST)
From: Jay Morris <jay_m_morris@yahoo.com>
Subject: Re: [Sip] Registration Query
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>, vkenneally@cit.ie
Cc: sip@ietf.org
In-Reply-To: <3E8BF84B.4020100@dynamicsoft.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1174244996-1049384253=:87505"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-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-1174244996-1049384253=:87505
Content-Type: text/plain; charset=us-ascii


Hi,
I can't find section 8.1.3.5 in the standard. Where is it?
Thanks,
Jay.
 Jonathan Rosenberg <jdrosen@dynamicsoft.com> wrote:

Valerie Kenneally wrote:
> Hi all,
> 
> Assume a User Agent is registering with a SIP Server. The SIP Server
> challenges the User Agent with regard to Authorization. The User Agent
> replies with the appropriate information. My question-when the User Agent
> responds to the challenge will the Call-ID and From tag or this message be
> the same as the first REGISTER message sent? All info greatly accepted!

Yes. Section 8.1.3.5 addresses this case:

> In all of the above cases, the request is retried by creating a new
> request with the appropriate modifications. This new request
> constitutes a new transaction and SHOULD have the same value of the
> Call-ID, To, and From of the previous request, but the CSeq should
> contain a new sequence number that is one higher than the previous.
> 
> 
> 
> Rosenberg, et. al. Standards Track [Page 45]
> 
> RFC 3261 SIP: Session Initiation Protocol June 2002
> 
> 
> With other 4xx responses, including those yet to be defined, a retry
> may or may not be possible depending on the method and the use case.


-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
Chief Scientist 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


---------------------------------
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
--0-1174244996-1049384253=:87505
Content-Type: text/html; charset=us-ascii

<P>Hi,
<P>I can't find section 8.1.3.5 in the standard. Where is it?
<P>Thanks,
<P>Jay.
<P>&nbsp;<B><I>Jonathan Rosenberg &lt;jdrosen@dynamicsoft.com&gt;</I></B> wrote:
<BLOCKQUOTE style="BORDER-LEFT: #1010ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px"><BR><BR>Valerie Kenneally wrote:<BR>&gt; Hi all,<BR>&gt; <BR>&gt; Assume a User Agent is registering with a SIP Server. The SIP Server<BR>&gt; challenges the User Agent with regard to Authorization. The User Agent<BR>&gt; replies with the appropriate information. My question-when the User Agent<BR>&gt; responds to the challenge will the Call-ID and From tag or this message be<BR>&gt; the same as the first REGISTER message sent? All info greatly accepted!<BR><BR>Yes. Section 8.1.3.5 addresses this case:<BR><BR>&gt; In all of the above cases, the request is retried by creating a new<BR>&gt; request with the appropriate modifications. This new request<BR>&gt; constitutes a new transaction and SHOULD have the same value of the<BR>&gt; Call-ID, To, and From of the previous request, but the CSeq should<BR>&gt; contain a new sequence number that is one higher than the previous.<BR>&gt; <BR>&gt; !
 <BR>&gt; <BR>&gt; Rosenberg, et. al. Standards Track [Page 45]<BR>&gt; <BR>&gt; RFC 3261 SIP: Session Initiation Protocol June 2002<BR>&gt; <BR>&gt; <BR>&gt; With other 4xx responses, including those yet to be defined, a retry<BR>&gt; may or may not be possible depending on the method and the use case.<BR><BR><BR>-Jonathan R.<BR>-- <BR>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza<BR>Chief Scientist Parsippany, NJ 07054-2711<BR>dynamicsoft<BR>jdrosen@dynamicsoft.com FAX: (973) 952-5050<BR>http://www.jdrosen.net PHONE: (973) 952-5000<BR>http://www.dynamicsoft.com<BR><BR>_______________________________________________<BR>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip<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><p><br><hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/finance/mailsig/*http://tax.yahoo.com">Yahoo! Tax Center</a> - File online, calculators, forms, and more
--0-1174244996-1049384253=:87505--
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Thu Apr  3 14:20:06 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07769
	for <sip-archive@odin.ietf.org>; Thu, 3 Apr 2003 14:20:06 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h33JMTh18976
	for sip-archive@odin.ietf.org; Thu, 3 Apr 2003 14:22:29 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33JLxK18957;
	Thu, 3 Apr 2003 14:21:59 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33JEUK18546
	for <sip@optimus.ietf.org>; Thu, 3 Apr 2003 14:14:30 -0500
Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07569
	for <sip@ietf.org>; Thu, 3 Apr 2003 14:11:36 -0500 (EST)
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 h33JCvOg008001
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO);
	Thu, 3 Apr 2003 13:13:54 -0600
From: "Dean Willis" <dean.willis@softarmor.com>
To: "'Jay Morris'" <jay_m_morris@yahoo.com>,
        "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>, <vkenneally@cit.ie>
Cc: <sip@ietf.org>
Subject: RE: [Sip] Registration Query
Date: Thu, 3 Apr 2003 13:12:43 -0600
Message-ID: <002401c2fa15$22d46fc0$ee036e3f@txdwillis>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0025_01C2F9E2.D839FFC0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <20030403153733.88278.qmail@web20505.mail.yahoo.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.

------=_NextPart_000_0025_01C2F9E2.D839FFC0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Page 44 of the txt formatted document at:
=20
http://www.ietf.org/rfc/rfc3261.txt?number=3D3261
=20
Wait, is this an April 1 thing? Somebody asked a question I could =
actually
answer. That can't be right!
=20
--
Dean

-----Original Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Jay =
Morris
Sent: Thursday, April 03, 2003 9:38 AM
To: Jonathan Rosenberg; vkenneally@cit.ie
Cc: sip@ietf.org
Subject: Re: [Sip] Registration Query



Hi,=20


I can't find section 8.1.3.5 in the standard. Where is it?=20


Thanks,=20


Jay.=20


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

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

<META content=3D"MSHTML 6.00.2800.1141" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D943271019-03042003>Page=20
44 of the txt formatted document at:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D943271019-03042003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D943271019-03042003><A=20
href=3D"http://www.ietf.org/rfc/rfc3261.txt?number=3D3261">http://www.iet=
f.org/rfc/rfc3261.txt?number=3D3261</A></SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D943271019-03042003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D943271019-03042003>Wait,=20
is this an April 1 thing? Somebody asked a question I could actually =
answer.=20
That can't be right!</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D943271019-03042003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D943271019-03042003>--<BR>Dean</SPAN></FONT></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  sip-admin@ietf.org [mailto:sip-admin@ietf.org] <B>On Behalf Of </B>Jay =

  Morris<BR><B>Sent:</B> Thursday, April 03, 2003 9:38 AM<BR><B>To:</B> =
Jonathan=20
  Rosenberg; vkenneally@cit.ie<BR><B>Cc:</B> =
sip@ietf.org<BR><B>Subject:</B> Re:=20
  [Sip] Registration Query<BR><BR></FONT></DIV>
  <P>Hi,=20
  <P>I can't find section 8.1.3.5 in the standard. Where is it?=20
  <P>Thanks,=20
  <P>Jay. </P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0025_01C2F9E2.D839FFC0--

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



From mailnull@www1.ietf.org  Fri Apr  4 08:25:27 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21213
	for <sip-archive@odin.ietf.org>; Fri, 4 Apr 2003 08:25:27 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h34DSCx15083
	for sip-archive@odin.ietf.org; Fri, 4 Apr 2003 08:28:12 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34DRSK15037;
	Fri, 4 Apr 2003 08:27:28 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34DLrK14848
	for <sip@optimus.ietf.org>; Fri, 4 Apr 2003 08:21:53 -0500
Received: from hoemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21126
	for <sip@ietf.org>; Fri, 4 Apr 2003 08:18:37 -0500 (EST)
Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57])
	by hoemail2.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h34DL4q08284
	for <sip@ietf.org>; Fri, 4 Apr 2003 08:21:04 -0500 (EST)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19)
	id <XNTDDGXT>; Fri, 4 Apr 2003 14:21:03 +0100
Message-ID: <475FF955A05DD411980D00508B6D5FB0081DB661@en0033exch001u.uk.lucent.com>
From: "Drage, Keith (Keith)" <drage@lucent.com>
To: Jay Morris <jay_m_morris@yahoo.com>
Cc: sip@ietf.org
Subject: RE: [Sip] Registration Query
Date: Fri, 4 Apr 2003 14:21:00 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

Can I suggest you try somewhere between 8.1.3.4 and 8.2.

It is certainly there tonight, but who knows where it might be tomorrow.

Are you sure you are looking at

http://www.ietf.org/rfc/rfc3261.txt

which is the approved version as an RFC.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: drage@lucent.com 
-----Original Message-----
From: Jay Morris [mailto:jay_m_morris@yahoo.com]
Sent: 03 April 2003 16:38
To: Jonathan Rosenberg; vkenneally@cit.ie
Cc: sip@ietf.org
Subject: Re: [Sip] Registration Query


Hi, 
I can't find section 8.1.3.5 in the standard. Where is it? 
Thanks, 
Jay. 
 Jonathan Rosenberg <jdrosen@dynamicsoft.com> wrote: 


Valerie Kenneally wrote:
> Hi all,
> 
> Assume a User Agent is registering with a SIP Server. The SIP Server
> challenges the User Agent with regard to Authorization. The User Agent
> replies with the appropriate information. My question-when the User Agent
> responds to the challenge will the Call-ID and From tag or this message be
> the same as the first REGISTER message sent? All info greatly accepted!

Yes. Section 8.1.3.5 addresses this case:

> In all of the above cases, the request is retried by creating a new
> request with the appropriate modifications. This new request
> constitutes a new transaction and SHOULD have the same value of the
> Call-ID, To, and From of the previous request, but the CSeq should
> contain a new sequence number that is one higher than the previous.
> 
> ! 
> 
> Rosenberg, et. al. Standards Track [Page 45]
> 
> RFC 3261 SIP: Session Initiation Protocol June 2002
> 
> 
> With other 4xx responses, including those yet to be defined, a retry
> may or may not be possible depending on the method and the use case.


-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
Chief Scientist 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




Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Fri Apr  4 18:44:21 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14210
	for <sip-archive@odin.ietf.org>; Fri, 4 Apr 2003 18:44:21 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h34NlKa00601
	for sip-archive@odin.ietf.org; Fri, 4 Apr 2003 18:47:20 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34Nkd800565;
	Fri, 4 Apr 2003 18:46:39 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34NgY800370
	for <sip@optimus.ietf.org>; Fri, 4 Apr 2003 18:42:34 -0500
Received: from relay01.valueweb.net (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14139
	for <sip@ietf.org>; Fri, 4 Apr 2003 18:39:04 -0500 (EST)
Received: from thor.valueweb.net ([216.219.254.23]:28832 "EHLO
	thor.valueweb.net") by relay01.valueweb.net with ESMTP
	id <S232806AbTDDXlc>; Fri, 4 Apr 2003 18:41:32 -0500
Received: from [66.180.120.50] ([66.180.120.50]:44306 "HELO frankyuan")
	by thor.valueweb.net with SMTP id <S297539AbTDDXl0>;
	Fri, 4 Apr 2003 18:41:26 -0500
Message-ID: <012201c2fb03$b09d7ce0$6500a8c0@frankyuan>
Reply-To: "Frank Yuan" <frankyuan@emergent-netsolutions.com>
From: "Frank Yuan" <frankyuan@emergent-netsolutions.com>
To: <sip@ietf.org>
Date: 	Fri, 4 Apr 2003 17:41:12 -0600
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_011F_01C2FAD1.62467A10"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Subject: [Sip] how to send  user defined parameters with INVITE?
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_011F_01C2FAD1.62467A10
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable




Hi,

Is there a way to send user defined parameter with INVITE or STATUS msg?
Since H323 uses Q931 as signaling control and Q931 has user info element =
in SETUP msg,=20
H323 can send Setup Msg with user info.

How about SIP?  If SIP can do it, could you let me know how?


Thanx

Frank

------=_NextPart_000_011F_01C2FAD1.62467A10
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4807.2300" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><BR></DIV>
<DIV><FONT face=3DArial size=3D2>Hi,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Is there a way to send user defined =
parameter with=20
INVITE or STATUS msg?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Since H323 uses Q931 as signaling =
control and Q931=20
has user info element in SETUP msg, </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>H323 can send Setup Msg with user=20
info.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>How about SIP?&nbsp; If SIP can do it, =
could you=20
let me know how?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanx</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Frank</FONT></DIV></BODY></HTML>

------=_NextPart_000_011F_01C2FAD1.62467A10--

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



From mailnull@www1.ietf.org  Sat Apr  5 16:19:50 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14891
	for <sip-archive@odin.ietf.org>; Sat, 5 Apr 2003 16:19:50 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h35LNEL21393
	for sip-archive@odin.ietf.org; Sat, 5 Apr 2003 16:23:14 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h35LMU821353;
	Sat, 5 Apr 2003 16:22:30 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h35LDt821052
	for <sip@optimus.ietf.org>; Sat, 5 Apr 2003 16:13:55 -0500
Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14656
	for <sip@ietf.org>; Sat, 5 Apr 2003 16:10:00 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.26])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h35LCUBd012052;
	Sat, 5 Apr 2003 16:12:30 -0500 (EST)
Message-ID: <3E8F46B8.1040203@dynamicsoft.com>
Date: Sat, 05 Apr 2003 16:12:24 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: jh@lohi.eng.song.fi
CC: Christer Holmberg <christer.holmberg@lmf.ericsson.se>,
        hisham.khartabil@nokia.com, jay_m_morris@yahoo.com, sip@ietf.org
Subject: Re: [Sip] Record-Route and 1xx
References: <2038BCC78B1AD641891A0D1AE133DBB7FE7483@esebe019.ntc.nokia.com>	<16011.68.389612.344249@harjus.eng.song.fi>	<3E8BF1B1.4050903@dynamicsoft.com>	<16012.6029.710352.281381@lohi.eng.song.fi>	<3E8C1EFF.C836FC1A@lmf.ericsson.se>	<16012.9722.145670.375833@harjus.eng.song.fi>	<3E8C2C77.DC9173F3@lmf.ericsson.se>	<16012.15963.71111.547859@harjus.eng.song.fi> <16012.19824.504350.572522@harjus.eng.song.fi>
In-Reply-To: <16012.19824.504350.572522@harjus.eng.song.fi>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Yes, this is exactly the kind of stuff it would be useful for. In fact, 
you would issue an INVITE w. Replaces to the GRUU, and it would 
effectively replace the old call leg. Handover wont exactly be smooth, 
though....

-Jonathan R.

jh@lohi.eng.song.fi wrote:
> may be jonathan's uri leasing stuff could be useful in getting the
> re-invite to the uas.
> 
> -- juha
> 

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             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 mailnull@www1.ietf.org  Sat Apr  5 16:24:52 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14928
	for <sip-archive@odin.ietf.org>; Sat, 5 Apr 2003 16:24:52 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h35LSHe21538
	for sip-archive@odin.ietf.org; Sat, 5 Apr 2003 16:28:17 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h35LRm821512;
	Sat, 5 Apr 2003 16:27:48 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h35LN3821389
	for <sip@optimus.ietf.org>; Sat, 5 Apr 2003 16:23:03 -0500
Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14873
	for <sip@ietf.org>; Sat, 5 Apr 2003 16:19:08 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.26])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h35LLgBd012056;
	Sat, 5 Apr 2003 16:21:42 -0500 (EST)
Message-ID: <3E8F48E0.2030500@dynamicsoft.com>
Date: Sat, 05 Apr 2003 16:21:36 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
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: Jay Morris <jay_m_morris@yahoo.com>
CC: Christer Holmberg <christer.holmberg@lmf.ericsson.se>, jh@lohi.eng.song.fi,
        hisham.khartabil@nokia.com, sip@ietf.org
Subject: Re: [Sip] Record-Route and 1xx
References: <20030403142208.68895.qmail@web20509.mail.yahoo.com>
In-Reply-To: <20030403142208.68895.qmail@web20509.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

inline.

Jay Morris wrote:
> Thanks for the response.
> Lets say that I have the following scenario
> 
>      UA1                 B2B1           B2B2          UA2
>     
>      -----INV------->
>     
>      <----180 rel---
>           -----PRACK----->
>     
>      <----200--------
>                         
>       
>                       -----INV------->
>     
>                       <----180 rel---
>     
>      <------180 rel--    
>     
>      -----PRACK-----> ---PRACK-------->
>     
>      <----200-------- <----200--------
>   
>   
>    If the UA1 will not update the route set according to the second 180 
> response the prack will never  get to B2B2.

Sure it will. These are b2buas, not proxies. Since b2b1 is a UA, it is 
responsible for generating the PRACK to the 18x received from b2b2, and 
if it wants, it can forward the 180 upstream to ua1.

-Jonathan R.


-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             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 mailnull@www1.ietf.org  Sat Apr  5 16:31:02 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15025
	for <sip-archive@odin.ietf.org>; Sat, 5 Apr 2003 16:31:02 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h35LYQn21781
	for sip-archive@odin.ietf.org; Sat, 5 Apr 2003 16:34:26 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h35LY8821765;
	Sat, 5 Apr 2003 16:34:08 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h35LTt821592
	for <sip@optimus.ietf.org>; Sat, 5 Apr 2003 16:29:55 -0500
Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14958
	for <sip@ietf.org>; Sat, 5 Apr 2003 16:25:59 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.26])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h35LSXBd012059;
	Sat, 5 Apr 2003 16:28:33 -0500 (EST)
Message-ID: <3E8F4A7B.10601@dynamicsoft.com>
Date: Sat, 05 Apr 2003 16:28:27 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
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: Jay Morris <jay_m_morris@yahoo.com>
CC: jh@lohi.eng.song.fi, hisham.khartabil@nokia.com, sip@ietf.org
Subject: Re: [Sip] Record-Route and 1xx
References: <20030403104159.99414.qmail@web20514.mail.yahoo.com>
In-Reply-To: <20030403104159.99414.qmail@web20514.mail.yahoo.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit

Yes, all of this is correct according to the spec. Here is the words, 
from Section 12.1.2:

    When a UAC receives a response that establishes a dialog, it
    constructs the state of the dialog.  This state MUST be maintained
    for the duration of the dialog.

Note that this means that the state is set only upon creation, which 
means the first 1xx response. THis is modified by the speific behavior 
for INVITE, from 13.2.2.4:

    If the dialog identifier in the 2xx response matches the dialog
    identifier of an existing dialog, the dialog MUST be transitioned to
    the "confirmed" state, and the route set for the dialog MUST be
    recomputed based on the 2xx response using the procedures of Section
    12.2.1.2.  Otherwise, a new dialog in the "confirmed" state MUST be
    constructed using the procedures of Section 12.1.2.

-Jonathan R.

Jay Morris wrote:
> Actually, my question was naive. I don’t need any special feature, I 
> just want to do things according to the standard and now I am really 
> confused about what I should do.
> 
> I summarize below the behavior I think is according to the standard. 
> Please correct me if I’m wrong:
> 
>  Server behavior:
> 
>    1. When an Initial Invite is received take Record-Route list from
>       message and build internal route list.
>    2. Copy record route list to any 1xx (other then 100) response of the
>       invite.
>    3. Copy record route list to the Invite 2xx response.
>    4. Use the route list for routing any outgoing request.
>    5. After dialog is confirmed ignore any Record-Route header in
>       refresh Invite requests.
> 
>  Client behavior
> 
>    1. When first 1xx response is received take Record Route list from
>       the response message and build a temporary route set.
>    2. Use this route set for any request sent before the dialog moves to
>       the confirmed state.
>    3. Ignore Record Route headers of other 1xx responses.
>    4. When 2xx is received for the Invite replace the route set and use
>       it for further requests.
>    5. After dialog is confirmed ignore any Record-Route header in
>       refresh Invite requests.
> 
>  Is that correct? Especially number 3 of the client behavior.
> 
> What does the standard say?
> 
> Thanks,
> 
> Jay.
> 
>  */Jonathan Rosenberg <jdrosen@dynamicsoft.com>/* wrote:
> 
>     We had long discussions on replacing the route set. It had serious
>     backwards compatibility issues. We did conclude that it was possible to
>     define an extension that allowed you to explicitly ask to be removed
>     from the route set. So, if you feel you really need this feature,
>     please
>     go ahead and write up some reuqirements and a proposed mechanism.
> 
>     -Jonathan R.
> 
>     jh@lohi.eng.song.fi wrote:
>      > hisham.khartabil@nokia.com writes:
>      >
>      > > Replace. Also the 2xx that confirms the dialog replaces the route
>      > > set. After that, route set is not replaceable.
>      >
>      > which is a bad thing and should be considered a bug.
>      >
>      > -- juha
>      >
>      > _______________________________________________
>      > Sip mailing list https://www1.ietf.org/mailmaan/listinfo/sip
>      > This list is for NEW development of the core SIP 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 Scientist 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
> 
> 
> ------------------------------------------------------------------------
> Do you Yahoo!?
> Yahoo! Tax Center 
> <http://us.rd.yahoo.com/finance/mailsig/*http://tax.yahoo.com> - File 
> online, calculators, forms, and more

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             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 mailnull@www1.ietf.org  Sat Apr  5 16:35:58 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15098
	for <sip-archive@odin.ietf.org>; Sat, 5 Apr 2003 16:35:58 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h35LdMK22743
	for sip-archive@odin.ietf.org; Sat, 5 Apr 2003 16:39:22 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h35Ld5822730;
	Sat, 5 Apr 2003 16:39:05 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h35LVW821649
	for <sip@optimus.ietf.org>; Sat, 5 Apr 2003 16:31:32 -0500
Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14968
	for <sip@ietf.org>; Sat, 5 Apr 2003 16:27:37 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.26])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h35LU2Bd012062;
	Sat, 5 Apr 2003 16:30:02 -0500 (EST)
Message-ID: <3E8F4AD4.5070507@dynamicsoft.com>
Date: Sat, 05 Apr 2003 16:29:56 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
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: Jay Morris <jay_m_morris@yahoo.com>
CC: vkenneally@cit.ie, sip@ietf.org
Subject: Re: [Sip] Registration Query
References: <20030403153733.88278.qmail@web20505.mail.yahoo.com>
In-Reply-To: <20030403153733.88278.qmail@web20505.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

Page 45 of RFC 3261.

-Jonathan R.

Jay Morris wrote:
> Hi,
> 
> I can't find section 8.1.3.5 in the standard. Where is it?
> 
> Thanks,
> 
> Jay.
> 
>  */Jonathan Rosenberg <jdrosen@dynamicsoft.com>/* wrote:
> 
> 
> 
>     Valerie Kenneally wrote:
>      > Hi all,
>      >
>      > Assume a User Agent is registering with a SIP Server. The SIP Server
>      > challenges the User Agent with regard to Authorization. The User
>     Agent
>      > replies with the appropriate information. My question-when the
>     User Agent
>      > responds to the challenge will the Call-ID and From tag or this
>     message be
>      > the same as the first REGISTER message sent? All info greatly
>     accepted!
> 
>     Yes. Section 8.1.3.5 addresses this case:
> 
>      > In all of the above cases, the request is retried by creating a new
>      > request with the appropriate modifications. This new request
>      > constitutes a new transaction and SHOULD have the same value of the
>      > Call-ID, To, and From of the previous request, but the CSeq should
>      > contain a new sequence number that is one higher than the previous.
>      >
>      > !
>      >
>      > Rosenberg, et. al. Standards Track [Page 45]
>      >
>      > RFC 3261 SIP: Session Initiation Protocol June 2002
>      >
>      >
>      > With other 4xx responses, including those yet to be defined, a retry
>      > may or may not be possible depending on the method and the use case.
> 
> 
>     -Jonathan R.
>     -- 
>     Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
>     Chief Scientist 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
> 
> 
> ------------------------------------------------------------------------
> Do you Yahoo!?
> Yahoo! Tax Center 
> <http://us.rd.yahoo.com/finance/mailsig/*http://tax.yahoo.com> - File 
> online, calculators, forms, and more

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             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 mailnull@www1.ietf.org  Sun Apr  6 01:48:46 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23049
	for <sip-archive@odin.ietf.org>; Sun, 6 Apr 2003 01:48:46 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h366qMk17894
	for sip-archive@odin.ietf.org; Sun, 6 Apr 2003 01:52:22 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h366pV817839;
	Sun, 6 Apr 2003 01:51:31 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h366ib817613
	for <sip@optimus.ietf.org>; Sun, 6 Apr 2003 01:44:37 -0500
Received: from telesoft.indts.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22888
	for <sip@ietf.org>; Sun, 6 Apr 2003 01:40:27 -0500 (EST)
Received: from indts_fs.indts.com (indts_fs.indts.com [201.64.64.29])
	by telesoft.indts.com (8.11.6/8.11.6) with ESMTP id h366VRI07212
	for <sip@ietf.org>; Sun, 6 Apr 2003 12:01:27 +0530
Received: by INDTS_FS with Internet Mail Service (5.5.2650.21)
	id <H1090JNZ>; Sun, 6 Apr 2003 12:12:54 +0530
Message-ID: <F73B646FCC01D5118F530002B32C3372010A58E8@INDTS_FS>
From: Nitin Kumar <nitin@indts.com>
To: "'sip@ietf.org'" <sip@ietf.org>
Date: Sun, 6 Apr 2003 12:12:51 +0530 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sip] 486/603 Response issue in Proxy server
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

hi Folks,

Would like to get some clue on following issue.

I am using "SIP express Router" as my proxy server to test our SIP user
agents.
Now if one UA(lets say party A) sends INVITE to other UA (lets say party B)
via proxy server, we are finding that any non-2xx response (like 486 busy,
603 decline) received by proxy server from party B is not forwarded to party
A. Moreover proxy server is also sending valid ACK to non-2xx response to
party B. 

	A				PS (SIP express router)
B
	|					|
|
	|----------INVITE------------>|					|
	|
|----------INVITE------------>|	
	|<---------100 trying---------|					|
	|					|<---------100
trying---------|
	|					|
|
	|					|<---------180
trying---------|
	|<---------180 trying---------|					|
	|					|
|
	|					|<---------603
decline--------|
	|	603 not forwarded	      |
|
	|
|------------ACK------------->|
	|					|
|
	|					|
|
	|					|
|

any idea what may be the reason?

In case of successful call everything works fine.

will appreciate some clue from sip experts.

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



From mailnull@www1.ietf.org  Sun Apr  6 03:14:27 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23464
	for <sip-archive@odin.ietf.org>; Sun, 6 Apr 2003 03:14:27 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h367I4m19579
	for sip-archive@odin.ietf.org; Sun, 6 Apr 2003 03:18:04 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h367Hh819549;
	Sun, 6 Apr 2003 03:17:43 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h367Ef819456
	for <sip@optimus.ietf.org>; Sun, 6 Apr 2003 03:14:41 -0400
Received: from web20510.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA23402
	for <sip@ietf.org>; Sun, 6 Apr 2003 03:10:32 -0400 (EDT)
Message-ID: <20030406071304.28704.qmail@web20510.mail.yahoo.com>
Received: from [212.143.185.30] by web20510.mail.yahoo.com via HTTP; Sat, 05 Apr 2003 23:13:04 PST
Date: Sat, 5 Apr 2003 23:13:04 -0800 (PST)
From: Jay Morris <jay_m_morris@yahoo.com>
Subject: Re: [Sip] Registration Query
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: vkenneally@cit.ie, sip@ietf.org
In-Reply-To: <3E8F4AD4.5070507@dynamicsoft.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1599331755-1049613184=:28699"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-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-1599331755-1049613184=:28699
Content-Type: text/plain; charset=us-ascii


Hi,
1. I am looking at the pdf version and the section numbering is different. I was under the impression I can use the pdf safely. I guess I was wrong. Do you know where I can find a pdf version with the correct numbering.
2. The section still does not say if the from-tag should remain the same or not.
For dialogs the answer should be yes but I'm not sure about registrations.
Jay.
 Jonathan Rosenberg <jdrosen@dynamicsoft.com> wrote:Page 45 of RFC 3261.

-Jonathan R.

Jay Morris wrote:
> Hi,
> 
> I can't find section 8.1.3.5 in the standard. Where is it?
> 
> Thanks,
> 
> Jay.
> 
> */Jonathan Rosenberg /* wrote:
> 
> 
> 
> Valerie Kenneally wrote:
> > Hi all,
> >
> > Assume a User Agent is registering with a SIP Server. The SIP Server
> > challenges the User Agent with regard to Authorization. The User
> Agent
> > replies with the appropriate information. My question-when the
> User Agent
> > responds to the challenge will the Call-ID and From tag or this
> message be
> > the same as the first REGISTER message sent? All info greatly
> accepted!
> 
> Yes. Section 8.1.3.5 addresses this case:
> 
> > In all of the above cases, the request is retried by creating a new
> > request with the appropriate modifications. This new request
> > constitutes a new transaction and SHOULD have the same value of the
> > Call-ID, To, and From of the previous request, but the CSeq should
> > contain a new sequence number that is one higher than the previous.
> >
> > !
> >
> > Rosenberg, et. al. Standards Track [Page 45]
> >
> > RFC 3261 SIP: Session Initiation Protocol June 2002
> >
> >
> > With other 4xx responses, including those yet to be defined, a retry
> > may or may not be possible depending on the method and the use case.
> 
> 
> -Jonathan R.
> -- 
> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
> Chief Scientist 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
> 
> 
> ------------------------------------------------------------------------
> Do you Yahoo!?
> Yahoo! Tax Center 
> - File 
> online, calculators, forms, and more

-- 
Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
Chief Scientist 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


---------------------------------
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
--0-1599331755-1049613184=:28699
Content-Type: text/html; charset=us-ascii

<P>Hi,
<P>1. I am looking at the pdf version and the section numbering is different. I was under the impression I can use the pdf safely. I guess I was wrong. Do you know where I can find a pdf version with the correct numbering.
<P>2. The section still does not say if the from-tag should remain the same or not.<BR>For dialogs the answer should be yes but I'm not sure about registrations.
<P>Jay.
<P>&nbsp;<B><I>Jonathan Rosenberg &lt;jdrosen@dynamicsoft.com&gt;</I></B> wrote:
<BLOCKQUOTE style="BORDER-LEFT: #1010ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px">Page 45 of RFC 3261.<BR><BR>-Jonathan R.<BR><BR>Jay Morris wrote:<BR>&gt; Hi,<BR>&gt; <BR>&gt; I can't find section 8.1.3.5 in the standard. Where is it?<BR>&gt; <BR>&gt; Thanks,<BR>&gt; <BR>&gt; Jay.<BR>&gt; <BR>&gt; */Jonathan Rosenberg <JDROSEN@DYNAMICSOFT.COM>/* wrote:<BR>&gt; <BR>&gt; <BR>&gt; <BR>&gt; Valerie Kenneally wrote:<BR>&gt; &gt; Hi all,<BR>&gt; &gt;<BR>&gt; &gt; Assume a User Agent is registering with a SIP Server. The SIP Server<BR>&gt; &gt; challenges the User Agent with regard to Authorization. The User<BR>&gt; Agent<BR>&gt; &gt; replies with the appropriate information. My question-when the<BR>&gt; User Agent<BR>&gt; &gt; responds to the challenge will the Call-ID and From tag or this<BR>&gt; message be<BR>&gt; &gt; the same as the first REGISTER message sent? All info greatly<BR>&gt; accepted!<BR>&gt; <BR>&gt; Yes. Section 8.1.3.5 addresses this case:<BR>&gt; <BR>&gt;!
  &gt; In all of the above cases, the request is retried by creating a new<BR>&gt; &gt; request with the appropriate modifications. This new request<BR>&gt; &gt; constitutes a new transaction and SHOULD have the same value of the<BR>&gt; &gt; Call-ID, To, and From of the previous request, but the CSeq should<BR>&gt; &gt; contain a new sequence number that is one higher than the previous.<BR>&gt; &gt;<BR>&gt; &gt; !<BR>&gt; &gt;<BR>&gt; &gt; Rosenberg, et. al. Standards Track [Page 45]<BR>&gt; &gt;<BR>&gt; &gt; RFC 3261 SIP: Session Initiation Protocol June 2002<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt; With other 4xx responses, including those yet to be defined, a retry<BR>&gt; &gt; may or may not be possible depending on the method and the use case.<BR>&gt; <BR>&gt; <BR>&gt; -Jonathan R.<BR>&gt; -- <BR>&gt; Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza<BR>&gt; Chief Scientist Parsippany, NJ 07054-2711<BR>&gt; dynamicsoft<BR>&gt; jdrosen@dynamicsoft.com FAX: (973) 952-5050<BR>!
 &gt; http://www.jdrosen.net PHONE: (973) 952-5000<BR>&gt; http://www.d
ynamicsoft.com<BR>&gt; <BR>&gt; _______________________________________________<BR>&gt; Sip mailing list https://www1.ietf.org/mailman/listinfo/sip<BR>&gt; This list is for NEW development of the core SIP Protocol<BR>&gt; Use sip-implementors@cs.columbia.edu for questions on current sip<BR>&gt; Use sipping@ietf.org for new developments on the application of sip<BR>&gt; <BR>&gt; <BR>&gt; ------------------------------------------------------------------------<BR>&gt; Do you Yahoo!?<BR>&gt; Yahoo! Tax Center <BR>&gt; - File <BR>&gt; online, calculators, forms, and more<BR><BR>-- <BR>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza<BR>Chief Scientist Parsippany, NJ 07054-2711<BR>dynamicsoft<BR>jdrosen@dynamicsoft.com FAX: (973) 952-5050<BR>http://www.jdrosen.net PHONE: (973) 952-5000<BR>http://www.dynamicsoft.com<BR><BR>_______________________________________________<BR>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip<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><p><br><hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/finance/mailsig/*http://tax.yahoo.com">Yahoo! Tax Center</a> - File online, calculators, forms, and more
--0-1599331755-1049613184=:28699--
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Sun Apr  6 05:28:58 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24912
	for <sip-archive@odin.ietf.org>; Sun, 6 Apr 2003 05:28:58 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h369Wam30698
	for sip-archive@odin.ietf.org; Sun, 6 Apr 2003 05:32:36 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h369WC830677;
	Sun, 6 Apr 2003 05:32:12 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h369S4830569
	for <sip@optimus.ietf.org>; Sun, 6 Apr 2003 05:28:04 -0400
Received: from web20511.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA24869
	for <sip@ietf.org>; Sun, 6 Apr 2003 05:23:55 -0400 (EDT)
Message-ID: <20030406092625.80351.qmail@web20511.mail.yahoo.com>
Received: from [212.143.185.30] by web20511.mail.yahoo.com via HTTP; Sun, 06 Apr 2003 01:26:25 PST
Date: Sun, 6 Apr 2003 01:26:25 -0800 (PST)
From: Jay Morris <jay_m_morris@yahoo.com>
To: sip@ietf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1922179823-1049621185=:80284"
Subject: [Sip] day in Date header -  two different definitions 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>

--0-1922179823-1049621185=:80284
Content-Type: text/plain; charset=us-ascii


Hi

in RFC 3261 I found two different definitions for DATE header, and I don't know which one is the correct one:

In chapter 25.1 - the DATE header must have the wkday parameter. (e.g. Date: Sat, 13 Nov 2010 23:29:00 GMT)

In chapter 20.17, however, I found that "Unlike HTTP/1.1,   SIP only supports the most recent RFC 1123 [20] format for dates."

well, according to this definition, the wkday parameter is optional.

(e.g. Date: 13 Nov 2010 23:29:00 GMT)

[RFC1123]

5.2.14 RFC-822 Date and Time Specification: RFC-822 Section 5

[RFC822]

5. DATE AND TIME SPECIFICATION

5.1. SYNTAX

date-time = [ day "," ] date time ; dd mm yy; hh:mm:ss zzz

well, which definition is the correct one?

Jay

 



---------------------------------
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
--0-1922179823-1049621185=:80284
Content-Type: text/html; charset=us-ascii

<P>Hi</P>
<P>in RFC 3261 I found two different definitions for DATE header, and I don't know which one is the correct one:</P>
<P>In chapter 25.1 - the DATE header must have the wkday parameter. (e.g. Date: Sat, 13 Nov 2010 23:29:00 GMT)</P>
<P>In chapter 20.17, however, I found that "Unlike HTTP/1.1,&nbsp;&nbsp; SIP only supports the most recent RFC 1123 [20] format for dates."</P>
<P>well, according to this definition, the wkday parameter is optional.</P>
<P>(e.g. Date:&nbsp;13 Nov 2010 23:29:00 GMT)</P><FONT size=2>
<P>[RFC1123]</P>
<P>5.2.14 RFC-822 Date and Time Specification: RFC-822 Section 5</P>
<P>[RFC822]</P>
<P>5. DATE AND TIME SPECIFICATION</P>
<P>5.1. SYNTAX</P>
<P>date-time = [ day "," ] date time ; dd mm yy; hh:mm:ss zzz</P>
<P>well, which definition is the correct one?</P>
<P>Jay</P></FONT>
<P>&nbsp;</P><p><br><hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/finance/mailsig/*http://tax.yahoo.com">Yahoo! Tax Center</a> - File online, calculators, forms, and more
--0-1922179823-1049621185=:80284--
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Mon Apr  7 00:23:56 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13739
	for <sip-archive@odin.ietf.org>; Mon, 7 Apr 2003 00:23:56 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h374Rw127726
	for sip-archive@odin.ietf.org; Mon, 7 Apr 2003 00:27:58 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h374R0827713;
	Mon, 7 Apr 2003 00:27:00 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h374MI827590
	for <sip@optimus.ietf.org>; Mon, 7 Apr 2003 00:22:18 -0400
Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13673
	for <sip@ietf.org>; Mon, 7 Apr 2003 00:17:43 -0400 (EDT)
Received: from txdwillis (12-239-241-155.client.attbi.com [12.239.241.155])
	(authenticated bits=0)
	by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h374JHOg015691
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO);
	Sun, 6 Apr 2003 23:20:00 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: "'Jay Morris'" <jay_m_morris@yahoo.com>,
        "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>
Cc: <vkenneally@cit.ie>, <sip@ietf.org>
Subject: RE: [Sip] Registration Query
Date: Sun, 6 Apr 2003 23:18:51 -0500
Message-ID: <001101c2fcbc$e5334970$b37ba8c0@txdwillis>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0012_01C2FC92.FC5D4170"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <20030406071304.28704.qmail@web20510.mail.yahoo.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.

------=_NextPart_000_0012_01C2FC92.FC5D4170
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20
One wil rarely find a "good" PDF of a document that has gone to RFC. =
This is
because of the publication process -- the RFC editor takes the text of =
the
final approved draft and converts it to ROFF. They then apply the =
standard
edits to make it a properly formatted RFC. This text is reviewed by the
authors during "Authors 48", and further amended.  Eventually, a final =
.txt
file is produced and published. Sometimes the authors try and recover a
working version of the document for future editing, and MAY produce a =
PDF
from this.
=20
In short, use the text version as the reference once something makes it =
to
RFC . . .
=20
--
Dean

-----Original Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Jay =
Morris
Sent: Sunday, April 06, 2003 1:13 AM
To: Jonathan Rosenberg
Cc: vkenneally@cit.ie; sip@ietf.org
Subject: Re: [Sip] Registration Query



Hi,=20


1. I am looking at the pdf version and the section numbering is =
different. I
was under the impression I can use the pdf safely. I guess I was wrong. =
Do
you know where I can find a pdf version with the correct numbering.=20


2. The section still does not say if the from-tag should remain the same =
or
not.
For dialogs the answer should be yes but I'm not sure about =
registrations.=20


Jay.=20


 Jonathan Rosenberg <jdrosen@dynamicsoft.com> wrote:=20


Page 45 of RFC 3261.

-Jonathan R.

Jay Morris wrote:
> Hi,
>=20
> I can't find section 8.1.3.5 in the standard. Where is it?
>=20
> Thanks,
>=20
> Jay.
>=20
> */Jonathan Rosenberg /* wrote:
>=20
>=20
>=20
> Valerie Kenneally wrote:
> > Hi all,
> >
> > Assume a User Agent is registering with a SIP Server. The SIP Server
> > challenges the User Agent with regard to Authorization. The User
> Agent
> > replies with the appropriate information. My question-when the
> User Agent
> > responds to the challenge will the Call-ID and From tag or this
> message be
> > the same as the first REGISTER message sent? All info greatly
> accepted!
>=20
> Yes. Section 8.1.3.5 addresses this case:
>=20
>! > In all of the above cases, the request is retried by creating a new
> > request with the appropriate modifications. This new request
> > constitutes a new transaction and SHOULD have the same value of the
> > Call-ID, To, and From of the previous request, but the CSeq should
> > contain a new sequence number that is one higher than the previous.
> >
> > !
> >
> > Rosenberg, et. al. Standards Track [Page 45]
> >
> > RFC 3261 SIP: Session Initiation Protocol June 2002
> >
> >
> > With other 4xx responses, including those yet to be defined, a retry
> > may or may not be possible depending on the method and the use case.
>=20
>=20
> -Jonathan R.
> --=20
> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
> Chief Scientist Parsippany, NJ 07054-2711
> dynamicsoft
> jdrosen@dynamicsoft.com FAX: (973) 952-5050
! > http://www.jdrosen.net PHONE: (973) 952-5000
> http://www.d ynamicsoft.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
>=20
>=20
> =
------------------------------------------------------------------------
> Do you Yahoo!?
> Yahoo! Tax Center=20
> - File=20
> online, calculators, forms, and more

--=20
Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
Chief Scientist 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




  _____ =20

Do you Yahoo!?
Yahoo! Tax  =
<http://us.rd.yahoo.com/finance/mailsig/*http://tax.yahoo.com>
Center - File online, calculators, forms, and more


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

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

<META content=3D"MSHTML 6.00.2800.1141" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D348351404-07042003><FONT face=3DArial color=3D#0000ff =
size=3D2>One=20
wil rarely find a "good" PDF of a document that has gone to RFC. This is =
because=20
of the publication process -- the RFC editor takes the text of the final =

approved draft and converts it to ROFF. They then apply the standard =
edits to=20
make it a properly formatted RFC. This text is reviewed by the authors =
during=20
"Authors 48", and further amended.&nbsp; Eventually, a final .txt file =
is=20
produced and published. Sometimes the authors try and recover a working =
version=20
of the document for future editing, and MAY produce a PDF from=20
this.</FONT></SPAN></DIV>
<DIV><SPAN class=3D348351404-07042003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D348351404-07042003><FONT face=3DArial color=3D#0000ff =
size=3D2>In=20
short, use the text version as the reference once something makes it to =
RFC . .=20
.</FONT></SPAN></DIV>
<DIV><SPAN class=3D348351404-07042003><FONT face=3DArial color=3D#0000ff =

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

size=3D2>--</FONT></SPAN></DIV>
<DIV><SPAN class=3D348351404-07042003><FONT face=3DArial color=3D#0000ff =

size=3D2>Dean</FONT></SPAN></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  sip-admin@ietf.org [mailto:sip-admin@ietf.org] <B>On Behalf Of </B>Jay =

  Morris<BR><B>Sent:</B> Sunday, April 06, 2003 1:13 AM<BR><B>To:</B> =
Jonathan=20
  Rosenberg<BR><B>Cc:</B> vkenneally@cit.ie; =
sip@ietf.org<BR><B>Subject:</B> Re:=20
  [Sip] Registration Query<BR><BR></FONT></DIV>
  <P>Hi,=20
  <P>1. I am looking at the pdf version and the section numbering is =
different.=20
  I was under the impression I can use the pdf safely. I guess I was =
wrong. Do=20
  you know where I can find a pdf version with the correct numbering.=20
  <P>2. The section still does not say if the from-tag should remain the =
same or=20
  not.<BR>For dialogs the answer should be yes but I'm not sure about=20
  registrations.=20
  <P>Jay.=20
  <P>&nbsp;<B><I>Jonathan Rosenberg =
&lt;jdrosen@dynamicsoft.com&gt;</I></B>=20
  wrote:=20
  <BLOCKQUOTE=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px =
solid">Page=20
    45 of RFC 3261.<BR><BR>-Jonathan R.<BR><BR>Jay Morris wrote:<BR>&gt; =

    Hi,<BR>&gt; <BR>&gt; I can't find section 8.1.3.5 in the standard. =
Where is=20
    it?<BR>&gt; <BR>&gt; Thanks,<BR>&gt; <BR>&gt; Jay.<BR>&gt; <BR>&gt;=20
    */Jonathan Rosenberg <JDROSEN@DYNAMICSOFT.COM>/* wrote:<BR>&gt; =
<BR>&gt;=20
    <BR>&gt; <BR>&gt; Valerie Kenneally wrote:<BR>&gt; &gt; Hi =
all,<BR>&gt;=20
    &gt;<BR>&gt; &gt; Assume a User Agent is registering with a SIP =
Server. The=20
    SIP Server<BR>&gt; &gt; challenges the User Agent with regard to=20
    Authorization. The User<BR>&gt; Agent<BR>&gt; &gt; replies with the=20
    appropriate information. My question-when the<BR>&gt; User =
Agent<BR>&gt;=20
    &gt; responds to the challenge will the Call-ID and From tag or =
this<BR>&gt;=20
    message be<BR>&gt; &gt; the same as the first REGISTER message sent? =
All=20
    info greatly<BR>&gt; accepted!<BR>&gt; <BR>&gt; Yes. Section 8.1.3.5 =

    addresses this case:<BR>&gt; <BR>&gt;! &gt; In all of the above =
cases, the=20
    request is retried by creating a new<BR>&gt; &gt; request with the=20
    appropriate modifications. This new request<BR>&gt; &gt; constitutes =
a new=20
    transaction and SHOULD have the same value of the<BR>&gt; &gt; =
Call-ID, To,=20
    and From of the previous request, but the CSeq should<BR>&gt; &gt; =
contain a=20
    new sequence number that is one higher than the previous.<BR>&gt;=20
    &gt;<BR>&gt; &gt; !<BR>&gt; &gt;<BR>&gt; &gt; Rosenberg, et. al. =
Standards=20
    Track [Page 45]<BR>&gt; &gt;<BR>&gt; &gt; RFC 3261 SIP: Session =
Initiation=20
    Protocol June 2002<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt; With other =
4xx=20
    responses, including those yet to be defined, a retry<BR>&gt; &gt; =
may or=20
    may not be possible depending on the method and the use =
case.<BR>&gt;=20
    <BR>&gt; <BR>&gt; -Jonathan R.<BR>&gt; -- <BR>&gt; Jonathan D. =
Rosenberg,=20
    Ph.D. 600 Lanidex Plaza<BR>&gt; Chief Scientist Parsippany, NJ=20
    07054-2711<BR>&gt; dynamicsoft<BR>&gt; jdrosen@dynamicsoft.com FAX: =
(973)=20
    952-5050<BR>! &gt; http://www.jdrosen.net PHONE: (973) =
952-5000<BR>&gt;=20
    http://www.d ynamicsoft.com<BR>&gt; <BR>&gt;=20
    _______________________________________________<BR>&gt; Sip mailing =
list=20
    https://www1.ietf.org/mailman/listinfo/sip<BR>&gt; This list is for =
NEW=20
    development of the core SIP Protocol<BR>&gt; Use=20
    sip-implementors@cs.columbia.edu for questions on current =
sip<BR>&gt; Use=20
    sipping@ietf.org for new developments on the application of =
sip<BR>&gt;=20
    <BR>&gt; <BR>&gt;=20
    =
------------------------------------------------------------------------<=
BR>&gt;=20
    Do you Yahoo!?<BR>&gt; Yahoo! Tax Center <BR>&gt; - File <BR>&gt; =
online,=20
    calculators, forms, and more<BR><BR>-- <BR>Jonathan D. Rosenberg, =
Ph.D. 600=20
    Lanidex Plaza<BR>Chief Scientist Parsippany, NJ=20
    07054-2711<BR>dynamicsoft<BR>jdrosen@dynamicsoft.com FAX: (973)=20
    952-5050<BR>http://www.jdrosen.net PHONE: (973)=20
    =
952-5000<BR>http://www.dynamicsoft.com<BR><BR>___________________________=
____________________<BR>Sip=20
    mailing list https://www1.ietf.org/mailman/listinfo/sip<BR>This list =
is for=20
    NEW development of the core SIP! Protocol<BR>Use=20
    sip-implementors@cs.columbia.edu for questions on current sip<BR>Use =

    sipping@ietf.org for new developments on the application of =
sip</BLOCKQUOTE>
  <P><BR>
  <HR SIZE=3D1>
  Do you Yahoo!?<BR><A=20
  =
href=3D"http://us.rd.yahoo.com/finance/mailsig/*http://tax.yahoo.com">Yah=
oo! Tax=20
  Center</A> - File online, calculators, forms, and=20
more</BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0012_01C2FC92.FC5D4170--

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



From mailnull@www1.ietf.org  Mon Apr  7 07:37:27 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16547
	for <sip-archive@odin.ietf.org>; Mon, 7 Apr 2003 07:37:27 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h37BfcC03538
	for sip-archive@odin.ietf.org; Mon, 7 Apr 2003 07:41:38 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37BeU803500;
	Mon, 7 Apr 2003 07:40:30 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37BZC802233
	for <sip@optimus.ietf.org>; Mon, 7 Apr 2003 07:35:12 -0400
Received: from mail.cit.ie (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15686
	for <sip@ietf.org>; Mon, 7 Apr 2003 07:30:30 -0400 (EDT)
Received: from EEB174W2Kvk (unverified [157.190.81.172]) by cit.ie
 (Rockliffe SMTPRA 5.2.5) with SMTP id <B0000428726@mail.cit.ie> for <sip@ietf.org>;
 Mon, 7 Apr 2003 12:33:00 +0100
Reply-To: <vkenneally@cit.ie>
From: "Valerie Kenneally" <vkenneally@cit.ie>
To: <sip@ietf.org>
Date: Mon, 7 Apr 2003 12:32:57 +0100
Message-ID: <NIEFLFDIBJCPCKAMIGBPKEBBCGAA.vkenneally@cit.ie>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Content-Transfer-Encoding: 7bit
Subject: [Sip] Via line format
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi All,

  I am aware that the Via line can contain parameters such as "maddr",
"ttl", "ttl", "received" and "branch".  My question-Is there is a specific
order to these parameters when they are included in the Via line.

Valerie Kenneally


-------------------Legal  Disclaimer---------------------------------------

The above electronic mail transmission is confidential and intended only for the person to whom it is addressed. Its contents may be protected by legal and/or professional privilege. Should it be received by you in error please contact the sender at the above quoted email address. Any unauthorised form of reproduction of this message is strictly prohibited. The Institute does not guarantee the security of any information electronically transmitted and is not liable if the information contained in this communication is not a proper and complete record of the message as transmitted by the sender nor for any delay in its receipt.

----------------------------------------------------------------------------------------

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



From mailnull@www1.ietf.org  Mon Apr  7 12:21:05 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25472
	for <sip-archive@odin.ietf.org>; Mon, 7 Apr 2003 12:21:05 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h37GPLJ24260
	for sip-archive@odin.ietf.org; Mon, 7 Apr 2003 12:25:21 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37GMT824038;
	Mon, 7 Apr 2003 12:22:29 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37GAo823505
	for <sip@optimus.ietf.org>; Mon, 7 Apr 2003 12:10:50 -0400
Received: from broadsoft.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24748
	for <sip@ietf.org>; Mon, 7 Apr 2003 12:06:04 -0400 (EDT)
Received: from tate (host4.brodsoft.com [66.160.10.4] (may be forged)) by broadsoft.com (8.12.6p2) id h37G8ZDx015356; Mon, 7 Apr 2003 12:08:35 -0400 (EDT)
Reply-To: <brett@broadsoft.com>
From: "Brett Tate" <brett@broadsoft.com>
To: <sip@ietf.org>
Subject: RE: [Sip] Via line format
Date: Mon, 7 Apr 2003 12:12:01 -0400
Message-ID: <000001c2fd20$6ce2aa10$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: <NIEFLFDIBJCPCKAMIGBPKEBBCGAA.vkenneally@cit.ie>
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 am aware that the Via line can contain 
> parameters such as "maddr", "ttl", "received" 
> and "branch".  My question-Is there is a 
> specific order to these parameters when 
> they are included in the Via line.

No.

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



From mailnull@www1.ietf.org  Tue Apr  8 07:26:51 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06738
	for <sip-archive@odin.ietf.org>; Tue, 8 Apr 2003 07:26:51 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h38BVVB16166
	for sip-archive@odin.ietf.org; Tue, 8 Apr 2003 07:31:31 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38BUn816123;
	Tue, 8 Apr 2003 07:30:49 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38BQv815994
	for <sip@optimus.ietf.org>; Tue, 8 Apr 2003 07:26:57 -0400
Received: from hotsip.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06622
	for <sip@ietf.org>; Tue, 8 Apr 2003 07:21:47 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Date: Tue, 8 Apr 2003 13:24:16 +0200
Message-ID: <FE03AFC4B33E7447979123987BD65F45141E5B@exchange.hotsip.com>
Thread-Topic: RFC suggests wrong error response for out of sequence requests?
thread-index: AcL9wV7/KYhmXkt8Qea9rmKQlg3S8g==
From: "Christian Jansson" <christian.jansson@hotsip.com>
To: <sip@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h38BQv815995
Subject: [Sip] RFC suggests wrong error response for out of sequence requests?
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit


It can't be the fault of the UAS that an incoming request has a lower
sequence number than one already seen. Therefore I think that it is very
strange for the UAS to send a 500 Server Internal Error as the text from
the RFC below states, as the UAS may not have any error that can be
repaired. Shouldn't the UAS send out a 4xx class response like 400 Out
of Sequence instead, which will indicate that the source of the error is
on the UAC side?

RFC3261 page 77, sixth line from the top
"If the remote sequence number was not empty, but the sequence number
of the request is lower than the remote sequence number, the request
is out of order and MUST be rejected with a 500 (Server Internal
Error) response."

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



From mailnull@www1.ietf.org  Tue Apr  8 16:50:26 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01606
	for <sip-archive@odin.ietf.org>; Tue, 8 Apr 2003 16:50:25 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h38KtIP29093
	for sip-archive@odin.ietf.org; Tue, 8 Apr 2003 16:55:18 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38KsU829003;
	Tue, 8 Apr 2003 16:54:30 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38Kmp828754
	for <sip@optimus.ietf.org>; Tue, 8 Apr 2003 16:48:51 -0400
Received: from broadsoft.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01421
	for <sip@ietf.org>; Tue, 8 Apr 2003 16:43:28 -0400 (EDT)
Received: from tate (host4.brodsoft.com [66.160.10.4] (may be forged)) by broadsoft.com (8.12.6p2) id h38Kk26C019363; Tue, 8 Apr 2003 16:46:02 -0400 (EDT)
Reply-To: <brett@broadsoft.com>
From: "Brett Tate" <brett@broadsoft.com>
To: <sip@ietf.org>
Subject: RE: [Sip] RFC suggests wrong error response for out of sequence requests?
Date: Tue, 8 Apr 2003 16:49:30 -0400
Message-ID: <001a01c2fe10$5a851c40$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
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <FE03AFC4B33E7447979123987BD65F45141E5B@exchange.hotsip.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

> It can't be the fault of the UAS that an 
> incoming request has a lower sequence number 
> than one already seen. Therefore I think that 
> it is very strange for the UAS to send a 
> 500 Server Internal Error as the text from
> the RFC below states, as the UAS may not have 
> any error that can be repaired. 

The cseq out of order could be the fault 
of a bad UAS.  However I agree that it is 
likely the fault of the UAC sending a subsequent 
request prior to receiving acknowledgement 
of a prior request.  And yes the response
reason text of 500 can be adjusted to 
provide clarity for the given situation 
(i.e. "500 cseq value must be higher than 6").

The important thing is to communicate that
you did not process the request and that
you might be able to process the same request
with higher cseq at a later time.

I would prefer a unique response code for 
cseq out of order.  However 500 works ok in
the spirit of reusing response codes and
triggering an old UAC to potentially retry
the request.

> Shouldn't the UAS send out a 4xx class 
> response like 400 Out of Sequence instead, 
> which will indicate that the source of 
> the error is on the UAC side?

The UAC is not guaranteed to be the source
of the problem.  The currently specified
4xx responses that potentially contain a
retry-after header are even less informative
than the 500.

> RFC3261 page 77, sixth line from the top
> "If the remote sequence number was not 
> empty, but the sequence number of the 
> request is lower than the remote sequence 
> number, the request is out of order and 
> MUST be rejected with a 500 (Server Internal
> Error) response."

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



From mailnull@www1.ietf.org  Wed Apr  9 04:04:07 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17624
	for <sip-archive@odin.ietf.org>; Wed, 9 Apr 2003 04:04:07 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3989Dp22753
	for sip-archive@odin.ietf.org; Wed, 9 Apr 2003 04:09:13 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3988f822710;
	Wed, 9 Apr 2003 04:08:42 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3981T821366
	for <sip@optimus.ietf.org>; Wed, 9 Apr 2003 04:01:29 -0400
Received: from mail.astri.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17471
	for <sip@ietf.org>; Wed, 9 Apr 2003 03:55:50 -0400 (EDT)
Received: from patrickXP (Firewall [203.198.202.1])
	by mail.astri.org (8.11.6/8.11.2) with ESMTP id h3984OY03156
	for <sip@ietf.org>; Wed, 9 Apr 2003 16:04:24 +0800
From: "Patrick Lam" <patrickl@astri.org>
To: <sip@ietf.org>
Date: Wed, 9 Apr 2003 16:00:59 +0800
Message-ID: <001301c2fe6e$282c1330$2306050a@patrickXP>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0014_01C2FEB1.364F5330"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
X-MS-TNEF-Correlator: 00000000A495D97211F6D54497CF24BD1531C79F44DA2800
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Subject: [Sip] Relationship between Dialog and Call-ID
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0014_01C2FEB1.364F5330
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear all:

I am a little confused about the relationship between a dialog and the
Call-ID:

1.	Do requests "within the same dialog" use identical Call-ID, while
requests "outside of a dialog" use different Call-ID than those =
"within"?
2.	In the last paragraph on p.16 in RFC 3261:

"This re-INVITE references the existing dialog so that the other party =
knows
that it is to modify an existing session instead of establishing a new
session."

What does the re-INVITE use to refer to the existing dialog?  Call-ID?

Thanks very much in advance.

Regards,

Patrick

------=_NextPart_000_0014_01C2FEB1.364F5330
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Disposition: attachment;
	filename="winmail.dat"
Content-Transfer-Encoding: base64

eJ8+IjsIAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANMHBAAJABAAAAAAAAMA+gAB
A5AGAOQRAAAnAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB
AAAAKAAAAFJlbGF0aW9uc2hpcCBiZXR3ZWVuIERpYWxvZyBhbmQgQ2FsbC1JRAACAXEAAQAAABYA
AAABwv5uJ9yl3xsd4l1GapShhfIgG20MAAACAR0MAQAAABgAAABTTVRQOlBBVFJJQ0tMQEFTVFJJ
Lk9SRwALAAEOAAAAAEAABg4AAMoEbv7CAQIBCg4BAAAAGAAAAAAAAACkldlyEfbVRJfPJL0VMcef
woAAAAMAFA4AAAAACwAfDgEAAAACAQkQAQAAAKQNAACgDQAAcSkAAExaRnW2IbfVgwAKAHJjcGc5
NQFADHVjAFABBHN0c2jBBXBiY2gxNA70CQCbD3AO5WgN4BBGYmkBQ4ELYG5nMTAzMxGm5GZlEiAy
OAH3AqQDY0cCAA9wCsBzZXQC0XAocnEyAAAqCqFub60U4CATEBYxNhIwMA4wzjQWsQHQFqA0fQdt
AoPvAFAD1BSPFZtiFnEW4BZCbxuEF2AHEwKDMgRGGU0x9RWMNxaRORYzFwIW4Bdg/whVB7IYdBJQ
AvIZRyFwD6D/Gf8B0BIgFoAkEBagEiAkZUR9UwdwU3VuFYJmgwdABUDLzszlfRh09yKRFDwhcDYi
rxYzFqApWwh9UE0LgGdMaVUBJWe3c7LTqfrFfukmNCfCJt8n7yj/KgJAeypGK+Q3IZ8tjyO/JMJA
ayUEK+Q4FB4yNRIyEiDRB20gQ0Ur5Dk1PxbQ0zZvN3V5cgKDNBjBLH2uNhjBOb8DgkcJ0Ws7NN8c
4TvOHOE8/wOCVAhwOzQ7IYEsfTcw0UBfA4IoSORlYglwdyk7NCavQ0C/Nl9EdgcQAaAN4EVVNUXf
9jgtdUdvQiWxDeA7NCxPLzygIYFKv0SjVgiQdG76YQeBZUVVNSEY/DY4BxN9N8Y0OFFQzTl3UkU7
FTXvGM88qFJEPkg1HOFV/kAm+1JEQaY1IYFV/UNXUkRE6941MeFbXlHMSHs1SVFV/fdKd1JETAk1
LXFV/k32XNXdT441NSEdHTY2MTfAIIj9N8Y1OFFnPjl1aK07FTyy/x0dPKZorD5IQBJtT0AkaKy/
QaZN4nB+Q1VorETrNjHh73OPaE91okiKNklRcH5KdftorEwJNi1xcH9N9HT9T46fQ0AC1BlOBgAl
EyBXB5DudASRJW8YoTgUD4H2Kkb/gt8rXBbghK+B9i/nhrY7Nb+BD4n1gnwCgAKRCOY7CW/yMI8P
ZTJg8JA6kVGRD/+SGZAkkkKQr5R/lD2Tv5Hv/5A/EvATIJoKmyGa35vpkCR/nBKaf55Png2dj5u/
n4Q5f3BAotSkMZxTpDACgg8AeapsB5BoCeB0AABxAyE+bBGBBRABQBXgA/BkY+x0bAqxAGBzCrCn
kBlwEafSbnVtg4FhdXRibwBgZGp1DwAFEGe8aHSm0QoBpqAKAWkBkHRwMAOyMg+gEecSqFz+awSR
KmFwQBASArIQwgBg7wEyD2GuAQ+RYwnAp1CrYzxucKu5r5ITIAMwc278ZXgZwAewBbAAwAJzFaBc
Y3MSIAMwqVBkqrBpznYWEA7wGaBtaRDAsoC5CfAgRAEQqQAlwVAKwMZhCcCq0GggRgIhsbTdDxAx
AFAPEANgdwswqaCJAYBzV6dQdGhCElB3qaAKsLKAbBIgNSC3JHJft5gQALcGAYC5B2K5B3L5twJj
YgqwMbC68jIAu1PxBPBlbGynQbbQtnEBQP8PELLQACAlsbWBRRC4IL2mPwlQvcQMsb3Tp8C9xGRn
376mwCC/pq1wvcR2AzCmav+nT6hfqW+qfMXREfOrRRLj/6tRrV+ub690x2fKlLDFtbC/svyxVE5g
AaCl0LG3NbJa77QQCNAc0LDBYsNwCYACIN+yMqWhGZDC4JyQObWwExDgNyBIeXAEkKphPoP9sfM2
zp+ckM+/0Mu08Lxg/6cwCYDRn0NAsloL47uwxdH/yFMAUMjFDoHJZtP9sykO8D3RsXMCIFJxDvAF
oG1w2xXy1M9FAMADEFOlskNA/6VjSmDCD8MfxC/FP8ZPq8j/H9GtJnBAyMVwQMlWElCu/3+wBuWS
0/jUosvzsLLQrVDvC2JOYLEBsbc514zSotqff9un0K0AcBXgAZBMMAIgIPePIBLgjyBuvEClYwwB
37//4M/h3+Lv4//lD8h/5y/oP//pT7EBAdDuz+/f8OaDEOxE/wvw2cCmb/Nv9H/1j6qoPKD/q2+s
f9kfyZ+vr7Cy/F7MTf/+T0wB1gDxMewkscMBAKWgv71wzcHfUA+CD3SzMHDHADuDEN3ALS1RWxBe
ADg38/iBD5FoeUUQ3cAQFKXQ97LQ05ATI24dgPYxE5UEkt0TMmoT9hUgFKZm1eMUBf+loAIQ8PHZ
wBbUAgC8QBQF/+vws5Ed8BAREzIAAhlGEOgGMn1AWHA3Njk0DZgKXCcusBuxMC4hItsThAMQYtxB
G7ExISD44OdIsAJAqvJpLS1g9jIeYlcVIA+FuvB4HmRuHmEg/xxSEv8kQBQYIcYVLxY/F0/3GF8Z
bxD1NhtREeD6IRvE4dnAJ2ExQhxPHVUeQPtQgPYyOR7dLBKqYSwRIG//E7P4gRQ2LxUjAC/HL7Yk
P78lTyZfJ28oeklQG8QyHD//Kx7aUIigHvs5A6phOQItv/8TvyKvI78x/zMPNB81LxHg+wYgG7Uz
Nv84D6QwOT1GMv86YkYxOt8hfyKPPe8+/0AP/0EfQi8o614QKd9E/wEAy6D/iLEfClOjqmFTokf/
Ls8v378w70xfTW9Of0+PNjk1RB/9Uq84hJFT+2DSVQJg0VV//zvvSj9LT1m/Ws9b31zvQ1n+Nl6/
Kx4GMB7eH8YgP0jff0nvZX9mj2efaK9pvyi+N+9RXx0CG5NtHDg5LXuDIAL/e5Fvv1aPV59Yr3Qf
dS92P5t3TzY5OGvfKx40M0ZN34ijqmGIon1W3IBt7ZAdge8Pgt3B/AARsDkdYPwADyj+b71ByhGm
IA/YjRaLb4zLfdzgdYOxAPCyIA8kmiB2YnTNwCB7VdIAAYFu/w8VDYKR0pLze4AGICkBkvP30QaU
RIwQMwYQijAdkAIAvdGxd8wwjCAFsJYDaAWg/jh7gO2gs5C80M2wOKK80PhuYmoCMKBAsoD4sPjg
r7FhpfC58I6waLFgepjSs8Ag3oByZ+vwmiFogrPz34DJMWd2mvmZsQQgOnH/Q2DZwZuQnHUo8KtQ
msKZsP+BUZuCnkGkQHJQ3PGiYLMQ/wDw8NAF8MoSmNGlsNGwpEDgdmlld2uDcTZgoOIfvDACcAax
+QACUGx5dP+ScOvwjrCYMaJ3BEDegANw/wJQ03DdML2Q1CBjsAIwY7D/kdGDcQDwooCh0QHQzcC2
IT+icZHRvWDA0WOwEoBrcu/TgI6w8NCnMXe3MJHRoNP/p7GQsQ2wsNEFMAOAoALr8L+8QqTh1gEe
MGNAs5FkpGH78yC3MHCQwAHQAjEd0Kcn/w2CtgDw4JVm7aGNgKIxkJA8dGQA4rDx+QCYoW5of/GR
riOuoqACHmKuMtwhY/xpZt7g32CYM5IAtWEC8JmuMWx2t4CyEXVjmTD/shKB4rKig3QR8PkAAvAC
oJ8F8LHRAvAfoL1wIC6MdP+yJuZAssK9kAIgsz+0T7Vf/mwGQALwkIG3D7gfuS+ygL/HcALwpeC2
37uvvLUptZyPNmC6f79vvJViICh5cf/An7JTlqG+T8MfxC/FP7KA/3kAxoKzD8fvyP/BDQbwxo/v
zB/NL84/snE5yw/Qr9G/+9LGlfFyCZAQ8evxAL8Bz/8C3wPv9oXXwtng6wr3Ar4Q/wXfBu/5cvkv
CT8KTfIQCIHb7cEG8GPg4evwc92MCC/j3pEHtCBEZdng8KCqYO46eXHkT5O3IBuR2dF9Ul/oj92p
6jXmD+cZSfCgbd3woCDY0BCwYxAgnzBjwG+kUa5wD9CQsHT/8K9QII+fcBEB/8GeMGlwIB0A/aKQ
ZQ0RvQCp0NpAqZD/QQuucPCSQw5hLUlEOv/qNeo1EBSEU9fY6ssHF+UP8+0f5ygxLjngD9DXpdh0
/x472R4fDtof2ySREdt/H/W/3N/d5eq/93/4j+dWb/DB/HF1n4CkEOqfA57ghQUK/+ET55Eb8JWA
Bw8Drwkv50bv2XASUNhR8JJziwLyRAr/9wgfDR8KOTQQDwwPEi/nRv4gpFEV3+cKjpGlEBgQ/jDf
F/8W+vM1Gk/nGSwOkOEQ/+9xBn8UfxGfEq8KvyAvF+/P5wrwUd2RiyBvZvIXI0//IG8lbxM/KH8k
ryW/F3ap0P5m34CfcKUQ8yby4d7A8uH+bxfBLB8pPy4/Io8yPy1//y6PDnc13zL/N/8rXzo/Nz/7
OE/nkT/0L/U/9k8+3z/v/ec3MvoVPe9E70X/7lYO9LvesNSwIAGSoAABUGgm4DnyAHAulyAZoPIA
UkbkQyCIsDYx86bXvEhS/9ia2X/aj//P3K/dvFOB3sz/iMCPsuCUnwDhFZ8A4abfIP/iT+NWVrIC
n+u/6m9bbzvP/1iCNR1dr5Tx4TBQ8EkPV86750RagFThEB8wn3AtY2+BZHlJTlZJVEXwwf8wQ4Lg
HzDwkoRgjuK8YfJF/nMGUDEx8HStIK9RTEKggP4gkkKHkGW/ZIhp5FPwGaDzaGEGUG1vMBFrIDFR
aMf/skCfkPEhTWHUsOfQrnAncf8fAY2hjuAO0fKRa59sqqLQ/ndvZrWAYP9em1gKNRRagL89lXRP
7GjsnXIPZPFXagL/mNBoVWVxZ2UXsm4RZ9NuAvtoj6mQPxv/el9k8UGGXIn/XWZe90nvvhB0j4Pv
5yhlIN3ewGtlUI5RayBttrBM0NvYUZlwdt7Am+AueP+GT+3nRlKwENfhc4Kfg6+Ev/+Fzx1Pgb36
hU+PUJ9Rr1K/f1PPAhqM75A/jw+QH+cKUPPxAJbAY2uMr5o/m09iDwlcO30ApAADAN4/n04AAAMA
CVkDAAAAAwBAZQAAAAALABOACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAMAFYAIIAYAAAAA
AMAAAAAAAABGAAAAABCFAAAAAAAAAwAbgAggBgAAAAAAwAAAAAAAAEYAAAAAUoUAABuXAQADACKA
CCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAAAEAAI4AIIAYAAAAAAMAAAAAAAABGAAAAAGCFAAAA
zAvxvP//HwsAQoAIIAYAAAAAAMAAAAAAAABGAAAAAIKFAAABAAAAHgBJgAggBgAAAAAAwAAAAAAA
AEYAAAAAVIUAAAEAAAAFAAAAMTAuMAAAAAALAHWACCAGAAAAAADAAAAAAAAARgAAAAAGhQAAAAAA
AAsAdoAIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwB3gAggBgAAAAAAwAAAAAAAAEYAAAAA
GIUAAAAAAAACAfgPAQAAABAAAACkldlyEfbVRJfPJL0VMcefAgH6DwEAAAAQAAAApJXZchH21USX
zyS9FTHHnwIB+w8BAAAAlgAAAAAAAAA4obsQBeUQGqG7CAArKlbCAABtc3BzdC5kbGwAAAAAAE5J
VEH5v7gBAKoAN9luAAAAQzpcRG9jdW1lbnRzIGFuZCBTZXR0aW5nc1xwYXRyaWNrbFxMb2NhbCBT
ZXR0aW5nc1xBcHBsaWNhdGlvbiBEYXRhXE1pY3Jvc29mdFxPdXRsb29rXE91dGxvb2sucHN0AAAA
AwD+DwUAAAADAA00/TcCAAIBFDQBAAAAEAAAAE5JVEH5v7gBAKoAN9luAAACAX8AAQAAADEAAAAw
MDAwMDAwMEE0OTVEOTcyMTFGNkQ1NDQ5N0NGMjRCRDE1MzFDNzlGNDREQTI4MDAAAAAAAwAGEOES
nOUDAAcQxwEAAAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABERUFSQUxMOklBTUFMSVRUTEVD
T05GVVNFREFCT1VUVEhFUkVMQVRJT05TSElQQkVUV0VFTkFESUFMT0dBTkRUSEVDQUxMLUlEOjFE
T1JFUVVFU1RTIldJVEhJTlRIRVNBTUVEAAAAALkO

------=_NextPart_000_0014_01C2FEB1.364F5330--

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



From mailnull@www1.ietf.org  Wed Apr  9 05:03:56 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18687
	for <sip-archive@odin.ietf.org>; Wed, 9 Apr 2003 05:03:55 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h39992Q27041
	for sip-archive@odin.ietf.org; Wed, 9 Apr 2003 05:09:02 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3998H826994;
	Wed, 9 Apr 2003 05:08:17 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3992A825933
	for <sip@optimus.ietf.org>; Wed, 9 Apr 2003 05:02:10 -0400
Received: from shardagate.mahindrabt.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18578
	for <sip@ietf.org>; Wed, 9 Apr 2003 04:56:30 -0400 (EDT)
Received: from thisdomain (mailscan.sharda.mahindrabt.com [10.5.0.97])
	by shardagate.mahindrabt.com (8.12.8/8.12.8) with ESMTP id h398ws4L004707
	for <sip@ietf.org>; Wed, 9 Apr 2003 14:28:59 +0530
Received: from intranet.sharda.mahindrabt.com by mahindrabt.com ; Wed, 09 Apr 2003 14:15:15 +0530
Date: Wed, 09 Apr 2003 14:15:15 +0530
X-Originating-IP: 10.5.0.15
X-Auth-User: ashishn@mahindrabt.com
Received: from dscp00212 ([10.5.3.103])
	by intranet.sharda.mahindrabt.com (8.9.3/8.9.3) with SMTP id OAA18155
	for <sip@ietf.org>; Wed, 9 Apr 2003 14:27:47 +0530
From: "Ashish Naik" <ashishn@mahindrabt.com>
To: "Sip@Ietf. Org" <sip@ietf.org>
Date: Wed, 9 Apr 2003 14:31:28 +0530
Message-ID: <NFBBIJAAOFNEMIHBIFPIGEHADHAA.ashishn@mahindrabt.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0006_01C2FEA4.B4CB01D0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Subject: [Sip] Session Mobility 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>

This is a multi-part message in MIME format.

------=_NextPart_000_0006_01C2FEA4.B4CB01D0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

How is SIP going to address session mobility ? Is there any initiative taken
up for this ?

SIP is said to be a better alternative than Mobile IP. Can I have some
latest development document references ?
Regards,
Ashish Naik
-------------------
CoE Mobile Computing
Phone: 4018100 Ext 3070

*********************************************************
Disclaimer

This message (including any attachments) contains 
confidential information intended for a specific 
individual and purpose, and is protected by law. 
If you are not the intended recipient, you should 
delete this message and are hereby notified that 
any disclosure, copying, or distribution of this
message, or the taking of any action based on it, 
is strictly prohibited.

*********************************************************
Visit us at http://www.mahindrabt.com


------=_NextPart_000_0006_01C2FEA4.B4CB01D0
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.2800.1106" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D312355908-09042003><FONT face=3DArial size=3D2>How is =
SIP going to=20
address session mobility ? Is there any initiative taken up for this ?=20
</FONT></SPAN></DIV>
<DIV><SPAN class=3D312355908-09042003><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D312355908-09042003><FONT face=3DArial size=3D2>SIP is =
said to be a=20
better alternative than Mobile IP. Can I have some latest development =
document=20
references ?</FONT></SPAN></DIV>
<P><FONT face=3DArial size=3D2>Regards,<BR>Ashish =
Naik<BR>-------------------<BR>CoE=20
Mobile Computing<BR>Phone: 4018100 Ext 3070 </FONT></P>
<DIV>&nbsp;</DIV></BODY></HTML>

<html>
<br>
*********************************************************<br>
Disclaimer<br>
<br>
This message (including any attachments) contains <br>
confidential information intended for a specific <br>
individual and purpose, and is protected by law. <br>
If you are not the intended recipient, you should <br>
delete this message and are hereby notified that <br>
any disclosure, copying, or distribution of this<br>
message, or the taking of any action based on it, <br>
is strictly prohibited.<br>
<br>
*********************************************************<br>
Visit us at http://www.mahindrabt.com<br>
<br>
</html>

------=_NextPart_000_0006_01C2FEA4.B4CB01D0--


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



From mailnull@www1.ietf.org  Wed Apr  9 05:08:51 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18809
	for <sip-archive@odin.ietf.org>; Wed, 9 Apr 2003 05:08:51 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h399Dww27251
	for sip-archive@odin.ietf.org; Wed, 9 Apr 2003 05:13:58 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h399De827221;
	Wed, 9 Apr 2003 05:13:40 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3998s827017
	for <sip@optimus.ietf.org>; Wed, 9 Apr 2003 05:08:54 -0400
Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18672
	for <sip@ietf.org>; Wed, 9 Apr 2003 05:03:14 -0400 (EDT)
From: rakhan@hss.hns.com
Received: from hindon.hss.co.in (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h3993fB05766
	for <sip@ietf.org>; Wed, 9 Apr 2003 14:33:41 +0530 (IST)
Received: from ultra.hss.co.in (ultra [192.168.100.5])
	by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h3993Z905725;
	Wed, 9 Apr 2003 14:33:36 +0530 (IST)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id h3996U607449;
	Wed, 9 Apr 2003 14:36:30 +0530 (IST)
Subject: Re: [Sip] Relationship between Dialog and Call-ID
To: "Patrick Lam" <patrickl@astri.org>
Cc: <sip@ietf.org>
Date: Wed, 9 Apr 2003 14:37:41 +0530
Message-ID: <OF0D68BDB7.C627CC26-ON65256D03.00316033@hss.hns.com>
X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 09/04/2003
 02:31:39 PM
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>







Hello Patrick,

1. Yes. Message within same dialog use same Call-ID

In case of re-INVITE same Call-ID facilitates in relating  re-INVITE to the
existing session.
The (to, from, Call-ID) are maintaind same as that in original INVITE.



Rayees






"Patrick Lam" <patrickl@astri.org>@ietf.org on 04/09/2003 01:30:59 PM

Sent by:    sip-admin@ietf.org


To:    <sip@ietf.org>
cc:

Subject:    [Sip] Relationship between Dialog and Call-ID


Dear all:

I am a little confused about the relationship between a dialog and the
Call-ID:

1.    Do requests "within the same dialog" use identical Call-ID, while
requests "outside of a dialog" use different Call-ID than those "within"?
2.    In the last paragraph on p.16 in RFC 3261:

"This re-INVITE references the existing dialog so that the other party
knows
that it is to modify an existing session instead of establishing a new
session."

What does the re-INVITE use to refer to the existing dialog?  Call-ID?

Thanks very much in advance.

Regards,

 Patrick
[Filename: winmail.dat, Content-Type: application/ms-tnef]
The attachment file in the message has been removed as per HSS E-mail
Policy.



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



From mailnull@www1.ietf.org  Wed Apr  9 05:30:57 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19308
	for <sip-archive@odin.ietf.org>; Wed, 9 Apr 2003 05:30:57 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h399a5k28319
	for sip-archive@odin.ietf.org; Wed, 9 Apr 2003 05:36:05 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h399Zh828258;
	Wed, 9 Apr 2003 05:35:43 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h399Rt827878
	for <sip@optimus.ietf.org>; Wed, 9 Apr 2003 05:27:55 -0400
Received: from mail.astri.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19178
	for <sip@ietf.org>; Wed, 9 Apr 2003 05:22:12 -0400 (EDT)
Received: from patrickXP (Firewall [203.198.202.1])
	by mail.astri.org (8.11.6/8.11.2) with ESMTP id h399UfY06011;
	Wed, 9 Apr 2003 17:30:41 +0800
From: "Patrick Lam" <patrickl@astri.org>
To: "'Phil Reynolds'" <PReynolds@ridgewaysystems.com>
Cc: <sip@ietf.org>
Subject: RE: [Sip] Relationship between Dialog and Call-ID
Date: Wed, 9 Apr 2003 17:27:14 +0800
Message-ID: <001f01c2fe7a$34a2b9a0$2306050a@patrickXP>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0020_01C2FEBD.42C5F9A0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
X-MS-TNEF-Correlator: 00000000A495D97211F6D54497CF24BD1531C79F24DC2800
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <8B83B157C5AE224E95D390F65FEEA3EA038ADD@rwmail.internal.ridgewaysystems.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.

------=_NextPart_000_0020_01C2FEBD.42C5F9A0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Phil:

Thanks for your answer.  Just a little more to clarify: when I send an
re-INVITE for a particular dialog, I have to use the same Call-ID, =
To/From
tag for that particular dialog?  Would the re-INVITE be forked as well?  =
If
so, what would I do with the re-INVITE?

Thanks again.

Patrick

-----Original Message-----
From: Phil Reynolds [mailto:PReynolds@ridgewaysystems.com]=20
Sent: Wednesday, April 09, 2003 4:52 PM
To: Patrick Lam
Subject: RE: [Sip] Relationship between Dialog and Call-ID

A dialog is identified by the Call-ID, to-tag and from-tag. The Call-ID
itself is insufficient as the same INVITE may have been forked to =
several
different recipients that may all create dialogs.

	 -----Original Message-----
	From: 	sip-admin@ietf.org [mailto:sip-admin@ietf.org]  On Behalf Of
Patrick Lam
	Sent:	09 April 2003 09:01
	To:	sip@ietf.org
	Subject:	[Sip] Relationship between Dialog and Call-ID

	Dear all:

	I am a little confused about the relationship between a dialog and
the Call-ID:

	1.	Do requests "within the same dialog" use identical Call-ID,
while requests "outside of a dialog" use different Call-ID than those
"within"?
	2.	In the last paragraph on p.16 in RFC 3261:

	"This re-INVITE references the existing dialog so that the other
party knows that it is to modify an existing session instead of =
establishing
a new session."

	What does the re-INVITE use to refer to the existing dialog?
Call-ID?

	Thanks very much in advance.

	Regards,

	Patrick

------=_NextPart_000_0020_01C2FEBD.42C5F9A0
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Disposition: attachment;
	filename="winmail.dat"
Content-Transfer-Encoding: base64

eJ8+Ig4JAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANMHBAAJABEAGwAAAAMAFgEB
A5AGAKQUAAAsAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAA
AAAAHgBwAAEAAAAuAAAAW1NpcF0gUmVsYXRpb25zaGlwIGJldHdlZW4gRGlhbG9nIGFuZCBDYWxs
LUlEAAAAAgFxAAEAAAAgAAAAAcL+bifcpd8bHeJdRmqUoYXyIBttDAABq2igAAEQpEACAR0MAQAA
ABgAAABTTVRQOlBBVFJJQ0tMQEFTVFJJLk9SRwALAAEOAAAAAEAABg4AyiYsev7CAQIBCg4BAAAA
GAAAAAAAAACkldlyEfbVRJfPJL0VMcefwoAAAAMAFA4AAAAACwAfDgEAAAAeACgOAQAAACoAAAAw
MDAwMDAwMwFwYXRyaWNrbEBhc3RyaS5vcmcBcG9wLmFzdHJpLm9yZwAAAB4AKQ4BAAAAKgAAADAw
MDAwMDAzAXBhdHJpY2tsQGFzdHJpLm9yZwFwb3AuYXN0cmkub3JnAAAAAgEJEAEAAAB4DwAAdA8A
AGQtAABMWkZ1Z5x4ZYMACgByY3BnOTUBQAx1YwBQAQRzdHNowQVwYmNoMTQO9AkAmw9wDuVoDeAQ
RmJpAUOBC2BuZzEwMzMRpuRmZRIgMjgB9wKkA2NHAgAPcArAc2V0AtFwKHJxMgAAKgqhbm+tFOAg
ExAWMTYSMDAOMM40FrEB0BagNH0HbQKD7wBQA9QUjxWbYhZxFuAWQm8bhBdgBxMCgzIERhlNMfUV
jDcWkTkWMxcCFuAXYB8IVQeyGHQPoBQtMTM2jxnvFjMWoCQ7fVBNC4DQZ0xpVRWCZgdABUAAt3Oy
06n6xenyfQKDMzUY3yLPGvcWpPMbYhdhYWgDcSbEIrEhv7coTyPfJOJAJSYmxDgUHhYyL+IswiAH
bSBDRT0mxDkwDxbQMT8yRXly7QKDNBjBK502GME0jwOC+kcJ0Ws2BBzhNp4c4TfPPQOCVAhwNgQS
UCuONzdDOw8yRChIZWIJcHf+KTYEIY8+EDEvP0YHEAGgbw3gQCUnISudOCyVQj9C/yXxDeA2BCtv
N3A9AUWPP3OiVgiQdG5hB4FlQCXfL/EnXDEIBxMyljQzIUud9zRHTRU15TUYzzd4TRQ5GL41HOFQ
zjr2TRQ8djU9Ae9QzT4nTRQ/uzVAkVYuTJy9Q0s1Jy9FOE0URtk1LJHvUM5IxlelSl41L/EdHTEG
7jEykCCIMpY1MyFiDjRF/2N9NeU3gh0dN3ZjfDkYOuL/aB869GN8PHZIsmtOPiVjfH0/uzZAkW5f
Yx9wckNaNt9b0WtORUVjfEbZNiyRa0+/SMRvzUpeRTAUDyg1ICUmdCBXB5B0BJElrya1OO9LbzEJ
KrMylzhN/zQ5gbX/NeUzEFCfN3mBtDkYMxBTX/862YG0PHYzEFX/PhmBtD+7/zMQWO9BqYzFQ1oz
EFvfRTn/gbRG2TMQXq9IqYzFSl4zEK8+MYAtmHCMTVQn0GlAJf8kMHvvSNUvB33mAoACkQjmyjsJ
bzCdz2UyW8Ce+v+gEZ/PoNme5KECn2+jP6L9/6J/oK+e/xLwEyCoyqnhqZ//qqme5KrSqT+tD6zN
rE+qf/+uRIgxsZSIMasTiDACgg8AVHlsB5BoCeB0AABxfQMhbBGBBRABQBXgA/Bk2GN0bAqxAGBz
CrC2UCMn0LaSbnVtfpFhdcR0bwBgZGp1DwAFEHhnaHS1kQoBtWAKAWnpAZBwMAOyMg+gEecSqPxc
awSRJUFrEBASArIQwt8AYAEyD2G8wQ+RYwnAthB5uiNucLp5vlITIAMwc/huZXgoIAewBbAAwAJz
uRWgY3MSIAMwuBBkuXCcaXYWEA7wKABtaRDAc8FACfAgRAEQt8B+wVCNCsBhCcC5kGggRgIhu8B0
DxAxAFAPEANgdwswE7hgAYBzV7YQdGhC7xJQuGAKsMFAbBIgL/DF5L5yxlgQAMXGAYDHx2LHx/Jy
xcJjYgqwLGDJsiyw48oTBPBlbGy2AcWQxTH/AUAPEMGQACB+scRBP+DG4H/MZglQzIQMscyTtoDM
hGS+Z81mzuDOZrwwzIR2AzD/tSq2D7cfuC+5PNSREfO6Bf8S47oRvB+9L7401ifZVL+FX8RwwbzA
FIGRAmBlwHc138EawtAI0BzQv4Fi0jAJgL8CIMDytGEn8NGgEiA3U0Djl1BJIEh5cASQuSE5U/3A
szbdX6tQ3n/fi8OwyyD/tfAJgOBfPhDBGgPQRTDeMf8zIABwB3B+IL/R1vUAUNeFvw6B2CbivcHp
DvDgcXMCIC9NQQ7wneALUHnjfyBF+wDAAxBTtHI+EJzzFaCd4OJ2AlEge1XgwLXhnOT9FaFnBTDv
IvAyDEDwQblV97VXzJAO4WElAO6U35HvEufzEy/gEjA4NwBQ34r0ZO1kwDMSIDzwfQFVS1AC0flK
gGJqAGAJ8MFAECACAbfAMA8g06Bl13AFsHr3YrPO4ADAcmcLgc7gaNJB98sAe7LO4Hb5ifhB1BAL
gJ0+EDAOgfog+wU5OA+gu/lSKsB3+fT80WsQagWg/m0swAeQJ5D3YbRw4HBrENJ2CJB3awuAZJEg
/uLfBPAHQBLxDuHsYXTvsAuA//gg9sEAd9Qw7cDTYNJADGD3KAB+wOLgbAuQArEJMf8x/7VQAID/
0dHACUDE4QBxCTHPCSDPkQLAP+BrcsLQ+CD7FeAFMXfF8Aky/uIFsQhg//dA6SC/oLmQ03C9wguA
ywKrAuHkwWZ6wGzCUWQCYfvRgMXwcAbw0cDSIRxgBSf734KagG8sYPWV5uEoEi2AvdHAZLVCv7EM
FcKkY+JQuwwy9Htz9sPwoRWhbgwxzGx2xkAPoXVjwDAPot/MMATAEDL/MZ5gdPUQ+rB/0uAn0LpQ
8KLD0L/QgfAu/+/lD8VrEBBSfsDSEBDPEd//Eu/HsdLg9iD4oBSvFb8Wz35sQJDS4APgFG8ZPxpF
Kd8TLJEgGA8c/xolYpAge3H/Hi8P4yyQG88gnyGvIr8QAf8+MCQSEJ8lfyaPHp0v8CQf/ymvKr8r
zxABMyAory5PL1//MGXwwNIAxPDsYJmw61G1L//Rz9Lf0+/xZTdhaLHtCbnf/7rv1vTX0tePvZ++
rXuC5vi/B+DEsDsr6L/W5mNwUD6g0Gw6DQo1UiBFpUOfnUSpVEaPRKkZ0WtzRn/TRJr3oSB5Y6Eg
mrCFkPGcwC4gIHtzQf9DD0r/7UUhSjlBTLAgNmAEgLSQ1iB4UJ3gIDjgIA3AN3DAaWZ5OiB3tMDr
UFxJIHsw90BMsSCd4C3ASU5WSVRFTV9Ob/9Pf0TWTCOB8DdhXhHC0EXhf8FQA9AHkFR/VY9Wn0TW
LP9bj0SaU0BooMGRUjECUVIgv7TAU1B7AWRACFFUAERZrx9av12vXN9jf0gDby9G/5qBUiDDQGEf
Yi9lH1erxZBzyhBYj2c/TTBpT0SpV89v8AjQYANT5yBi5tFs/39Lmz2AU5FKUOTgyyBssUm6ZlNQ
b2TAUvBrcXdus79TQOMgUuC5cMOQbws/Ra/fcE9Hx0oUw0A10S51j3af50TXyhA5cGNrZ19oa8DA
/4YR7Ot49TVENg83HzgvOT//uUd8H30vfj9/QoqykSLVkf/KcPqwPYW5UYWfhq0+lohB03p+iEAg
LY2CT/sT3DH+Tf4Rw0BT8I2CDJNNQs3gv4g/iU+KX4tvjH9m0jqIDz+Qv5HPkt+T741RRUMgUtxl
eYCwCNBKUFvtwoKwNDpQm1ZA2NGOsHdhXHlznXDn0PfQLv3BXX8MhI9/ll+Xb5h/mY+NJFN/MwGV
b5/foO+h/6MPmrNXs6uwv7BzZJ1gZMBB/fA5myEwOWTA1ZA8kCA09jrtUMMATZ5fpT+mT6df/6hv
jNlmoKSfrc+u36/vsP/zmrR7pCBMYGCsT7MPtB/3tS+2P6OqdQ9ADEGyb7o/T7tPvF+9b5qzUkVS
0Fv+U/EQnjCbUNXAa9DjMPzA1/EQb9EAkGVTEURZU0yx/wxwYKhoTnj8f3+AjRpgMzJrGmDpsDTM
IjLhYMyTOHv2kRpgM8zwzCILoMwTNesLkM5TN8zzNvaCy+PPo/o5zBM4z3DMIgtgzPMAEb/NYzyA
9pDMI90wzBQy2mB90uQ50VTNsNHUzHHMIzXP4pDU5PxgzCM2NdFU9RDv0dTSQdbkzAU5zHX7gMz0
79HAzWPM0syTMs402jDOov+CdYOvhLS/wzyAwC/CT3pf5UUhQVk1IGlKUO0AMwH3UqD+8AxwYuyA
YBJgpatg7YKwLWchxxNmZuHjQk0g/3ggYIfhMAIQAnBy8OFCD8D0dWYIoGP+8AMQcjJgF/9vde3A
7IBfU2/gUxFx1VIx/w/QX3A68MpwB9DmEN1w5mL77EDmQHDmUuaya3Hn0ghR/1JQ/gDFkG/wWUSd
4MkPyhn/0UKAftsN0UKESb//3j/fT/9Xxb832bDxszxCM0DPADzP//JSQDT2o/Kfwu+Mz43f+8Lz
7V870WktzGPKoNci7t//zEXbDf8zhEa5RvX/9w/4H//5L/o/lKs70IRQL9D1bwO/nwTPBd8G7wf/
OyBwLYLgim014EDmUHRmLlhAvRoAW3wC5lBz0BNCZnPQ/8gBUTAJzwrfC+8M/w4P+s4wSFlQRRcP
+vtSTDFUEEsgIpv1EB9nIv8JvxOfFK8Vv8GPfsInwqqQN4RQEYM70GI14H7AIAAA0Mnqefm6zhEA
jIIAqgBLqQtUAgAlEAMlEeAkHTQBJRFtAGEAaQBsAAB0AG8AOgBz0SbxcAAtJtFkJrEnAChuAEAm
8WUnMWYA4i4nUXIAZyURNTB8Av9z0MgwnCASimwA8bE98R4v/x8/IE8Wzxn/G38QtioEHV//LE8t
Xy5vL3/6+8VAuQozn180rzW/Ns8337d2T+iQQvZla2DlcU9y8DMPOs873/887z3/Pw+4CYeYOc9C
D0Mf/0QvRT+9v6RiCW9JT0pfS29/TH9Nj7ejq0Cq1auDq0A6/9iwR/9QD1EfUi9TP1RPsbr/Tz9Y
b1l/Wo9bn1yvD8YQp/9XH18PYB9hL2I/Y0++L14//2b/aA9pH2ovaz+3o8UPxh//xyns7+3/7w/w
H4Rf8n/zj930mkTsEP2w67E6dpx9D1X0qUnroG3roCDKoHTHeTDoQJ4AbmZ15VD+IP1tMG/bMObD
7AB0T+iQgkD+ZIA/9Kl1iOJZf0393dFC/8qgzAL/j82i2v7MAnrPe9/zfO/0izEubROP5H6S6TCZ
7ABxdfyw6vFcJ9Ew//THkhd48OJQ29DmyODUk2Hb9LiSFyCDEeFlY+mh4pf+d5sRg+KS/5QKg4GP
IehA/m9AwIVRld+W7enY5LbrIb2VEm+XoZn/lHmciz+JH3+KL3i/jK+Nv47Pj9/0mjL9kbRJlRRu
YBJhpWH84OmQzHBom0DokHAu2bDlwZHEsEZDINpANjF/Rv93f6SfeZ+mv/G/yD+AAvTT/6l8kiag
Am1iIXC/r7NvqRb/IXCpvqj2uvHkcOFB7ADHoDfndOwA6gNj/LDmw2V47+FA4bBugODGc+kw6yPi
Uq5v4lGi8LAxdOfwa6+xz+sFsaDhMukhbW/p0euR/+iQvZflUPzAdHHlwuwwEFB/m8KZoW0wyqB0
ob3xgkBu/GV3wnaRsJyRbWK3X7N/X4i8tv/Gn7kfui5X6zJk/m+9JbwIl5LpIbyj6RK9X/3soD/1
QOKVopbIabI/yi/vqP/0i+Rw45BrmdDpcefwXG119FCtEhBQduOQY3vU3/SpZezd2D/0qXQgZ/n+
AXMs2h/bL/TWR0XFoyfS38cPrgR9AOMwHgBCEAEAAABNAAAAPDhCODNCMTU3QzVBRTIyNEU5NUQz
OTBGNjVGRUVBM0VBMDM4QUREQHJ3bWFpbC5pbnRlcm5hbC5yaWRnZXdheXN5c3RlbXMuY29tPgAA
AAADAJIQAAAAAAMA3j+fTgAAAwAJWQMAAAADAEBlAAAAAAsAE4AIIAYAAAAAAMAAAAAAAABGAAAA
AAOFAAAAAAAAAwAVgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADABuACCAGAAAAAADAAAAA
AAAARgAAAABShQAAG5cBAAMAIoAIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAAQAAjgAggBgAA
AAAAwAAAAAAAAEYAAAAAYIUAAADMC/G8//8fCwBCgAggBgAAAAAAwAAAAAAAAEYAAAAAgoUAAAEA
AAAeAEmACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAUAAAAxMC4wAAAAAAsAdYAIIAYAAAAA
AMAAAAAAAABGAAAAAAaFAAAAAAAACwB2gAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADAHeA
CCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAAIB+A8BAAAAEAAAAKSV2XIR9tVEl88kvRUxx58C
AfoPAQAAABAAAACkldlyEfbVRJfPJL0VMcefAgH7DwEAAACWAAAAAAAAADihuxAF5RAaobsIACsq
VsIAAG1zcHN0LmRsbAAAAAAATklUQfm/uAEAqgA32W4AAABDOlxEb2N1bWVudHMgYW5kIFNldHRp
bmdzXHBhdHJpY2tsXExvY2FsIFNldHRpbmdzXEFwcGxpY2F0aW9uIERhdGFcTWljcm9zb2Z0XE91
dGxvb2tcT3V0bG9vay5wc3QAAAADAP4PBQAAAAMADTT9NwIAAgEUNAEAAAAQAAAATklUQfm/uAEA
qgA32W4AAAIBfwABAAAAMQAAADAwMDAwMDAwQTQ5NUQ5NzIxMUY2RDU0NDk3Q0YyNEJEMTUzMUM3
OUYyNERDMjgwMAAAAAADAAYQIULMGAMABxCqBAAAAwAQEAAAAAADABEQAAAAAB4ACBABAAAAZQAA
AFBISUw6VEhBTktTRk9SWU9VUkFOU1dFUkpVU1RBTElUVExFTU9SRVRPQ0xBUklGWTpXSEVOSVNF
TkRBTlJFLUlOVklURUZPUkFQQVJUSUNVTEFSRElBTE9HLElIQVZFVE9VU0UAAAAASEo=

------=_NextPart_000_0020_01C2FEBD.42C5F9A0--

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



From mailnull@www1.ietf.org  Wed Apr  9 09:49:52 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27711
	for <sip-archive@odin.ietf.org>; Wed, 9 Apr 2003 09:49:52 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h39Dt4c14605
	for sip-archive@odin.ietf.org; Wed, 9 Apr 2003 09:55:04 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39Drr814528;
	Wed, 9 Apr 2003 09:53:53 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39Dk6814239
	for <sip@optimus.ietf.org>; Wed, 9 Apr 2003 09:46:06 -0400
Received: from gateus.nmss.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27492;
	Wed, 9 Apr 2003 09:40:21 -0400 (EDT)
Received: from [10.1.3.12] by gateus.nmss.com
          via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; 9 Apr 2003 08:38:08 UT
Subject: RE: [Sip] Relationship between Dialog and Call-ID
To: "Patrick Lam" <patrickl@astri.org>
Cc: "'Phil Reynolds'" <PReynolds@ridgewaysystems.com>, sip@ietf.org,
        sip-admin@ietf.org
X-Mailer: Lotus Notes Release 5.0.10  March 22, 2002
Message-ID: <OFD8C5A335.B1DD8A8E-ON85256D03.004B32BB-85256D03.004B54B0@nmss.com>
From: "Vishal Phirke" <vishal_phirke@nmss.com>
Date: Wed, 9 Apr 2003 09:41:29 -0400
X-MIMETrack: Serialize by Router on NAMASMTP02/NMS Communications(Release 5.0.11  |July
 24, 2002) at 04/09/2003 09:38:47 AM
MIME-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=0ABBE790DFD972CD8f9e8a93df938690918c0ABBE790DFD972CD"
Content-Disposition: inline
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

--0__=0ABBE790DFD972CD8f9e8a93df938690918c0ABBE790DFD972CD
Content-type: text/plain; charset=us-ascii


I don't think the re-invite will be forked. The re-invite most likely will
travel directly end-to-end or using route header. The forking is done only
for the first invite. Correct me if I am wrong.
-Vishal


                                                                                                           
                      "Patrick Lam"                                                                        
                      <patrickl@astri.o        To:       "'Phil Reynolds'" <PReynolds@ridgewaysystems.com> 
                      rg>                      cc:       <sip@ietf.org>                                    
                      Sent by:                 Subject:  RE: [Sip] Relationship between Dialog and Call-ID 
                      <sip-admin@ietf.o                                                                    
                      rg>                                                                                  
                                                                                                           
                                                                                                           
                      04/09/2003 05:27                                                                     
                      AM                                                                                   
                                                                                                           
                                                                                                           




Phil:

Thanks for your answer.  Just a little more to clarify: when I send an
re-INVITE for a particular dialog, I have to use the same Call-ID, To/From
tag for that particular dialog?  Would the re-INVITE be forked as well?  If
so, what would I do with the re-INVITE?

Thanks again.

Patrick

-----Original Message-----
From: Phil Reynolds [mailto:PReynolds@ridgewaysystems.com]
Sent: Wednesday, April 09, 2003 4:52 PM
To: Patrick Lam
Subject: RE: [Sip] Relationship between Dialog and Call-ID

A dialog is identified by the Call-ID, to-tag and from-tag. The Call-ID
itself is insufficient as the same INVITE may have been forked to several
different recipients that may all create dialogs.

              -----Original Message-----
             From:             sip-admin@ietf.org
[mailto:sip-admin@ietf.org]  On Behalf Of
Patrick Lam
             Sent:             09 April 2003 09:01
             To:         sip@ietf.org
             Subject:          [Sip] Relationship between Dialog and
Call-ID

             Dear all:

             I am a little confused about the relationship between a dialog
and
the Call-ID:

             1.          Do requests "within the same dialog" use identical
Call-ID,
while requests "outside of a dialog" use different Call-ID than those
"within"?
             2.          In the last paragraph on p.16 in RFC 3261:

             "This re-INVITE references the existing dialog so that the
other
party knows that it is to modify an existing session instead of
establishing
a new session."

             What does the re-INVITE use to refer to the existing dialog?
Call-ID?

             Thanks very much in advance.

             Regards,

             Patrick
(See attached file: winmail.dat)



--0__=0ABBE790DFD972CD8f9e8a93df938690918c0ABBE790DFD972CD
Content-type: application/octet-stream; 
	name="winmail.dat"
Content-Disposition: attachment; filename="winmail.dat"
Content-Transfer-Encoding: base64

eJ8+Ig4JAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANMHBAAJABEAGwAAAAMAFgEB
A5AGAKQUAAAsAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAA
AAAAHgBwAAEAAAAuAAAAW1NpcF0gUmVsYXRpb25zaGlwIGJldHdlZW4gRGlhbG9nIGFuZCBDYWxs
LUlEAAAAAgFxAAEAAAAgAAAAAcL+bifcpd8bHeJdRmqUoYXyIBttDAABq2igAAEQpEACAR0MAQAA
ABgAAABTTVRQOlBBVFJJQ0tMQEFTVFJJLk9SRwALAAEOAAAAAEAABg4AyiYsev7CAQIBCg4BAAAA
GAAAAAAAAACkldlyEfbVRJfPJL0VMcefwoAAAAMAFA4AAAAACwAfDgEAAAAeACgOAQAAACoAAAAw
MDAwMDAwMwFwYXRyaWNrbEBhc3RyaS5vcmcBcG9wLmFzdHJpLm9yZwAAAB4AKQ4BAAAAKgAAADAw
MDAwMDAzAXBhdHJpY2tsQGFzdHJpLm9yZwFwb3AuYXN0cmkub3JnAAAAAgEJEAEAAAB4DwAAdA8A
AGQtAABMWkZ1Z5x4ZYMACgByY3BnOTUBQAx1YwBQAQRzdHNowQVwYmNoMTQO9AkAmw9wDuVoDeAQ
RmJpAUOBC2BuZzEwMzMRpuRmZRIgMjgB9wKkA2NHAgAPcArAc2V0AtFwKHJxMgAAKgqhbm+tFOAg
ExAWMTYSMDAOMM40FrEB0BagNH0HbQKD7wBQA9QUjxWbYhZxFuAWQm8bhBdgBxMCgzIERhlNMfUV
jDcWkTkWMxcCFuAXYB8IVQeyGHQPoBQtMTM2jxnvFjMWoCQ7fVBNC4DQZ0xpVRWCZgdABUAAt3Oy
06n6xenyfQKDMzUY3yLPGvcWpPMbYhdhYWgDcSbEIrEhv7coTyPfJOJAJSYmxDgUHhYyL+IswiAH
bSBDRT0mxDkwDxbQMT8yRXly7QKDNBjBK502GME0jwOC+kcJ0Ws2BBzhNp4c4TfPPQOCVAhwNgQS
UCuONzdDOw8yRChIZWIJcHf+KTYEIY8+EDEvP0YHEAGgbw3gQCUnISudOCyVQj9C/yXxDeA2BCtv
N3A9AUWPP3OiVgiQdG5hB4FlQCXfL/EnXDEIBxMyljQzIUud9zRHTRU15TUYzzd4TRQ5GL41HOFQ
zjr2TRQ8djU9Ae9QzT4nTRQ/uzVAkVYuTJy9Q0s1Jy9FOE0URtk1LJHvUM5IxlelSl41L/EdHTEG
7jEykCCIMpY1MyFiDjRF/2N9NeU3gh0dN3ZjfDkYOuL/aB869GN8PHZIsmtOPiVjfH0/uzZAkW5f
Yx9wckNaNt9b0WtORUVjfEbZNiyRa0+/SMRvzUpeRTAUDyg1ICUmdCBXB5B0BJElrya1OO9LbzEJ
KrMylzhN/zQ5gbX/NeUzEFCfN3mBtDkYMxBTX/862YG0PHYzEFX/PhmBtD+7/zMQWO9BqYzFQ1oz
EFvfRTn/gbRG2TMQXq9IqYzFSl4zEK8+MYAtmHCMTVQn0GlAJf8kMHvvSNUvB33mAoACkQjmyjsJ
bzCdz2UyW8Ce+v+gEZ/PoNme5KECn2+jP6L9/6J/oK+e/xLwEyCoyqnhqZ//qqme5KrSqT+tD6zN
rE+qf/+uRIgxsZSIMasTiDACgg8AVHlsB5BoCeB0AABxfQMhbBGBBRABQBXgA/Bk2GN0bAqxAGBz
CrC2UCMn0LaSbnVtfpFhdcR0bwBgZGp1DwAFEHhnaHS1kQoBtWAKAWnpAZBwMAOyMg+gEecSqPxc
awSRJUFrEBASArIQwt8AYAEyD2G8wQ+RYwnAthB5uiNucLp5vlITIAMwc/huZXgoIAewBbAAwAJz
uRWgY3MSIAMwuBBkuXCcaXYWEA7wKABtaRDAc8FACfAgRAEQt8B+wVCNCsBhCcC5kGggRgIhu8B0
DxAxAFAPEANgdwswE7hgAYBzV7YQdGhC7xJQuGAKsMFAbBIgL/DF5L5yxlgQAMXGAYDHx2LHx/Jy
xcJjYgqwLGDJsiyw48oTBPBlbGy2AcWQxTH/AUAPEMGQACB+scRBP+DG4H/MZglQzIQMscyTtoDM
hGS+Z81mzuDOZrwwzIR2AzD/tSq2D7cfuC+5PNSREfO6Bf8S47oRvB+9L7401ifZVL+FX8RwwbzA
FIGRAmBlwHc138EawtAI0BzQv4Fi0jAJgL8CIMDytGEn8NGgEiA3U0Djl1BJIEh5cASQuSE5U/3A
szbdX6tQ3n/fi8OwyyD/tfAJgOBfPhDBGgPQRTDeMf8zIABwB3B+IL/R1vUAUNeFvw6B2CbivcHp
DvDgcXMCIC9NQQ7wneALUHnjfyBF+wDAAxBTtHI+EJzzFaCd4OJ2AlEge1XgwLXhnOT9FaFnBTDv
IvAyDEDwQblV97VXzJAO4WElAO6U35HvEufzEy/gEjA4NwBQ34r0ZO1kwDMSIDzwfQFVS1AC0flK
gGJqAGAJ8MFAECACAbfAMA8g06Bl13AFsHr3YrPO4ADAcmcLgc7gaNJB98sAe7LO4Hb5ifhB1BAL
gJ0+EDAOgfog+wU5OA+gu/lSKsB3+fT80WsQagWg/m0swAeQJ5D3YbRw4HBrENJ2CJB3awuAZJEg
/uLfBPAHQBLxDuHsYXTvsAuA//gg9sEAd9Qw7cDTYNJADGD3KAB+wOLgbAuQArEJMf8x/7VQAID/
0dHACUDE4QBxCTHPCSDPkQLAP+BrcsLQ+CD7FeAFMXfF8Aky/uIFsQhg//dA6SC/oLmQ03C9wguA
ywKrAuHkwWZ6wGzCUWQCYfvRgMXwcAbw0cDSIRxgBSf734KagG8sYPWV5uEoEi2AvdHAZLVCv7EM
FcKkY+JQuwwy9Htz9sPwoRWhbgwxzGx2xkAPoXVjwDAPot/MMATAEDL/MZ5gdPUQ+rB/0uAn0LpQ
8KLD0L/QgfAu/+/lD8VrEBBSfsDSEBDPEd//Eu/HsdLg9iD4oBSvFb8Wz35sQJDS4APgFG8ZPxpF
Kd8TLJEgGA8c/xolYpAge3H/Hi8P4yyQG88gnyGvIr8QAf8+MCQSEJ8lfyaPHp0v8CQf/ymvKr8r
zxABMyAory5PL1//MGXwwNIAxPDsYJmw61G1L//Rz9Lf0+/xZTdhaLHtCbnf/7rv1vTX0tePvZ++
rXuC5vi/B+DEsDsr6L/W5mNwUD6g0Gw6DQo1UiBFpUOfnUSpVEaPRKkZ0WtzRn/TRJr3oSB5Y6Eg
mrCFkPGcwC4gIHtzQf9DD0r/7UUhSjlBTLAgNmAEgLSQ1iB4UJ3gIDjgIA3AN3DAaWZ5OiB3tMDr
UFxJIHsw90BMsSCd4C3ASU5WSVRFTV9Ob/9Pf0TWTCOB8DdhXhHC0EXhf8FQA9AHkFR/VY9Wn0TW
LP9bj0SaU0BooMGRUjECUVIgv7TAU1B7AWRACFFUAERZrx9av12vXN9jf0gDby9G/5qBUiDDQGEf
Yi9lH1erxZBzyhBYj2c/TTBpT0SpV89v8AjQYANT5yBi5tFs/39Lmz2AU5FKUOTgyyBssUm6ZlNQ
b2TAUvBrcXdus79TQOMgUuC5cMOQbws/Ra/fcE9Hx0oUw0A10S51j3af50TXyhA5cGNrZ19oa8DA
/4YR7Ot49TVENg83HzgvOT//uUd8H30vfj9/QoqykSLVkf/KcPqwPYW5UYWfhq0+lohB03p+iEAg
LY2CT/sT3DH+Tf4Rw0BT8I2CDJNNQs3gv4g/iU+KX4tvjH9m0jqIDz+Qv5HPkt+T741RRUMgUtxl
eYCwCNBKUFvtwoKwNDpQm1ZA2NGOsHdhXHlznXDn0PfQLv3BXX8MhI9/ll+Xb5h/mY+NJFN/MwGV
b5/foO+h/6MPmrNXs6uwv7BzZJ1gZMBB/fA5myEwOWTA1ZA8kCA09jrtUMMATZ5fpT+mT6df/6hv
jNlmoKSfrc+u36/vsP/zmrR7pCBMYGCsT7MPtB/3tS+2P6OqdQ9ADEGyb7o/T7tPvF+9b5qzUkVS
0Fv+U/EQnjCbUNXAa9DjMPzA1/EQb9EAkGVTEURZU0yx/wxwYKhoTnj8f3+AjRpgMzJrGmDpsDTM
IjLhYMyTOHv2kRpgM8zwzCILoMwTNesLkM5TN8zzNvaCy+PPo/o5zBM4z3DMIgtgzPMAEb/NYzyA
9pDMI90wzBQy2mB90uQ50VTNsNHUzHHMIzXP4pDU5PxgzCM2NdFU9RDv0dTSQdbkzAU5zHX7gMz0
79HAzWPM0syTMs402jDOov+CdYOvhLS/wzyAwC/CT3pf5UUhQVk1IGlKUO0AMwH3UqD+8AxwYuyA
YBJgpatg7YKwLWchxxNmZuHjQk0g/3ggYIfhMAIQAnBy8OFCD8D0dWYIoGP+8AMQcjJgF/9vde3A
7IBfU2/gUxFx1VIx/w/QX3A68MpwB9DmEN1w5mL77EDmQHDmUuaya3Hn0ghR/1JQ/gDFkG/wWUSd
4MkPyhn/0UKAftsN0UKESb//3j/fT/9Xxb832bDxszxCM0DPADzP//JSQDT2o/Kfwu+Mz43f+8Lz
7V870WktzGPKoNci7t//zEXbDf8zhEa5RvX/9w/4H//5L/o/lKs70IRQL9D1bwO/nwTPBd8G7wf/
OyBwLYLgim014EDmUHRmLlhAvRoAW3wC5lBz0BNCZnPQ/8gBUTAJzwrfC+8M/w4P+s4wSFlQRRcP
+vtSTDFUEEsgIpv1EB9nIv8JvxOfFK8Vv8GPfsInwqqQN4RQEYM70GI14H7AIAAA0Mnqefm6zhEA
jIIAqgBLqQtUAgAlEAMlEeAkHTQBJRFtAGEAaQBsAAB0AG8AOgBz0SbxcAAtJtFkJrEnAChuAEAm
8WUnMWYA4i4nUXIAZyURNTB8Av9z0MgwnCASimwA8bE98R4v/x8/IE8Wzxn/G38QtioEHV//LE8t
Xy5vL3/6+8VAuQozn180rzW/Ns8337d2T+iQQvZla2DlcU9y8DMPOs873/887z3/Pw+4CYeYOc9C
D0Mf/0QvRT+9v6RiCW9JT0pfS29/TH9Nj7ejq0Cq1auDq0A6/9iwR/9QD1EfUi9TP1RPsbr/Tz9Y
b1l/Wo9bn1yvD8YQp/9XH18PYB9hL2I/Y0++L14//2b/aA9pH2ovaz+3o8UPxh//xyns7+3/7w/w
H4Rf8n/zj930mkTsEP2w67E6dpx9D1X0qUnroG3roCDKoHTHeTDoQJ4AbmZ15VD+IP1tMG/bMObD
7AB0T+iQgkD+ZIA/9Kl1iOJZf0393dFC/8qgzAL/j82i2v7MAnrPe9/zfO/0izEubROP5H6S6TCZ
7ABxdfyw6vFcJ9Ew//THkhd48OJQ29DmyODUk2Hb9LiSFyCDEeFlY+mh4pf+d5sRg+KS/5QKg4GP
IehA/m9AwIVRld+W7enY5LbrIb2VEm+XoZn/lHmciz+JH3+KL3i/jK+Nv47Pj9/0mjL9kbRJlRRu
YBJhpWH84OmQzHBom0DokHAu2bDlwZHEsEZDINpANjF/Rv93f6SfeZ+mv/G/yD+AAvTT/6l8kiag
Am1iIXC/r7NvqRb/IXCpvqj2uvHkcOFB7ADHoDfndOwA6gNj/LDmw2V47+FA4bBugODGc+kw6yPi
Uq5v4lGi8LAxdOfwa6+xz+sFsaDhMukhbW/p0euR/+iQvZflUPzAdHHlwuwwEFB/m8KZoW0wyqB0
ob3xgkBu/GV3wnaRsJyRbWK3X7N/X4i8tv/Gn7kfui5X6zJk/m+9JbwIl5LpIbyj6RK9X/3soD/1
QOKVopbIabI/yi/vqP/0i+Rw45BrmdDpcefwXG119FCtEhBQduOQY3vU3/SpZezd2D/0qXQgZ/n+
AXMs2h/bL/TWR0XFoyfS38cPrgR9AOMwHgBCEAEAAABNAAAAPDhCODNCMTU3QzVBRTIyNEU5NUQz
OTBGNjVGRUVBM0VBMDM4QUREQHJ3bWFpbC5pbnRlcm5hbC5yaWRnZXdheXN5c3RlbXMuY29tPgAA
AAADAJIQAAAAAAMA3j+fTgAAAwAJWQMAAAADAEBlAAAAAAsAE4AIIAYAAAAAAMAAAAAAAABGAAAA
AAOFAAAAAAAAAwAVgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADABuACCAGAAAAAADAAAAA
AAAARgAAAABShQAAG5cBAAMAIoAIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAAQAAjgAggBgAA
AAAAwAAAAAAAAEYAAAAAYIUAAADMC/G8//8fCwBCgAggBgAAAAAAwAAAAAAAAEYAAAAAgoUAAAEA
AAAeAEmACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAUAAAAxMC4wAAAAAAsAdYAIIAYAAAAA
AMAAAAAAAABGAAAAAAaFAAAAAAAACwB2gAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADAHeA
CCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAAIB+A8BAAAAEAAAAKSV2XIR9tVEl88kvRUxx58C
AfoPAQAAABAAAACkldlyEfbVRJfPJL0VMcefAgH7DwEAAACWAAAAAAAAADihuxAF5RAaobsIACsq
VsIAAG1zcHN0LmRsbAAAAAAATklUQfm/uAEAqgA32W4AAABDOlxEb2N1bWVudHMgYW5kIFNldHRp
bmdzXHBhdHJpY2tsXExvY2FsIFNldHRpbmdzXEFwcGxpY2F0aW9uIERhdGFcTWljcm9zb2Z0XE91
dGxvb2tcT3V0bG9vay5wc3QAAAADAP4PBQAAAAMADTT9NwIAAgEUNAEAAAAQAAAATklUQfm/uAEA
qgA32W4AAAIBfwABAAAAMQAAADAwMDAwMDAwQTQ5NUQ5NzIxMUY2RDU0NDk3Q0YyNEJEMTUzMUM3
OUYyNERDMjgwMAAAAAADAAYQIULMGAMABxCqBAAAAwAQEAAAAAADABEQAAAAAB4ACBABAAAAZQAA
AFBISUw6VEhBTktTRk9SWU9VUkFOU1dFUkpVU1RBTElUVExFTU9SRVRPQ0xBUklGWTpXSEVOSVNF
TkRBTlJFLUlOVklURUZPUkFQQVJUSUNVTEFSRElBTE9HLElIQVZFVE9VU0UAAAAASEo=

--0__=0ABBE790DFD972CD8f9e8a93df938690918c0ABBE790DFD972CD--

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



From mailnull@www1.ietf.org  Wed Apr  9 10:14:06 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29741
	for <sip-archive@odin.ietf.org>; Wed, 9 Apr 2003 10:14:06 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h39EJJE17080
	for sip-archive@odin.ietf.org; Wed, 9 Apr 2003 10:19:19 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39EIv816908;
	Wed, 9 Apr 2003 10:18:57 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39EDn816550
	for <sip@optimus.ietf.org>; Wed, 9 Apr 2003 10:13:49 -0400
Received: from phoebe.eim.surrey.ac.uk (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28963;
	Wed, 9 Apr 2003 10:08:04 -0400 (EDT)
Received: from ccsrmclt03.ee.surrey.ac.uk
	([131.227.86.163] helo=eim.surrey.ac.uk ident=ees2mg)
	by phoebe.eim.surrey.ac.uk with esmtp (Exim 3.33 #4)
	id 193GHJ-0006fJ-00; Wed, 09 Apr 2003 15:10:17 +0100
Message-ID: <3E9429C8.43E59A7F@eim.surrey.ac.uk>
Date: Wed, 09 Apr 2003 15:10:16 +0100
From: Michael Georgiades <m.georgiades@eim.surrey.ac.uk>
Organization: University of Surrey
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-17.7.x i686)
X-Accept-Language: en, el
MIME-Version: 1.0
To: Vishal Phirke <vishal_phirke@nmss.com>
CC: Patrick Lam <patrickl@astri.org>,
        "'Phil Reynolds'" <PReynolds@ridgewaysystems.com>, sip@ietf.org,
        sip-admin@ietf.org
Subject: Re: [Sip] Relationship between Dialog and Call-ID
References: <OFD8C5A335.B1DD8A8E-ON85256D03.004B32BB-85256D03.004B54B0@nmss.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=-120.6 required=5.5
	tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,
	      REFERENCES,REPLY_WITH_QUOTES,USER_IN_WHITELIST
	autolearn=ham	version=2.50
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
X-Scanner: exiscan *193GHJ-0006fJ-00*IrRg1vRN27U* (SECM, UniS)
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

"Unlike an INVITE, which can fork, a re-INVITE will never fork...."
pg 87 RFC 3261

Vishal Phirke wrote:

> I don't think the re-invite will be forked. The re-invite most likely will
> travel directly end-to-end or using route header. The forking is done only
> for the first invite. Correct me if I am wrong.
> -Vishal
>
>
>                       "Patrick Lam"
>                       <patrickl@astri.o        To:       "'Phil Reynolds'" <PReynolds@ridgewaysystems.com>
>                       rg>                      cc:       <sip@ietf.org>
>                       Sent by:                 Subject:  RE: [Sip] Relationship between Dialog and Call-ID
>                       <sip-admin@ietf.o
>                       rg>
>
>
>                       04/09/2003 05:27
>                       AM
>
>
>
> Phil:
>
> Thanks for your answer.  Just a little more to clarify: when I send an
> re-INVITE for a particular dialog, I have to use the same Call-ID, To/From
> tag for that particular dialog?  Would the re-INVITE be forked as well?  If
> so, what would I do with the re-INVITE?
>
> Thanks again.
>
> Patrick
>
> -----Original Message-----
> From: Phil Reynolds [mailto:PReynolds@ridgewaysystems.com]
> Sent: Wednesday, April 09, 2003 4:52 PM
> To: Patrick Lam
> Subject: RE: [Sip] Relationship between Dialog and Call-ID
>
> A dialog is identified by the Call-ID, to-tag and from-tag. The Call-ID
> itself is insufficient as the same INVITE may have been forked to several
> different recipients that may all create dialogs.
>
>               -----Original Message-----
>              From:             sip-admin@ietf.org
> [mailto:sip-admin@ietf.org]  On Behalf Of
> Patrick Lam
>              Sent:             09 April 2003 09:01
>              To:         sip@ietf.org
>              Subject:          [Sip] Relationship between Dialog and
> Call-ID
>
>              Dear all:
>
>              I am a little confused about the relationship between a dialog
> and
> the Call-ID:
>
>              1.          Do requests "within the same dialog" use identical
> Call-ID,
> while requests "outside of a dialog" use different Call-ID than those
> "within"?
>              2.          In the last paragraph on p.16 in RFC 3261:
>
>              "This re-INVITE references the existing dialog so that the
> other
> party knows that it is to modify an existing session instead of
> establishing
> a new session."
>
>              What does the re-INVITE use to refer to the existing dialog?
> Call-ID?
>
>              Thanks very much in advance.
>
>              Regards,
>
>              Patrick
> (See attached file: winmail.dat)
>
>   ------------------------------------------------------------------------
>                   Name: winmail.dat
>    winmail.dat    Type: unspecified type (application/octet-stream)
>               Encoding: base64

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



From mailnull@www1.ietf.org  Wed Apr  9 12:09:08 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04437
	for <sip-archive@odin.ietf.org>; Wed, 9 Apr 2003 12:09:07 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h39GENs26866
	for sip-archive@odin.ietf.org; Wed, 9 Apr 2003 12:14:23 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39GCB826744;
	Wed, 9 Apr 2003 12:12:13 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39Fwm825133
	for <sip@optimus.ietf.org>; Wed, 9 Apr 2003 11:58:48 -0400
Received: from smtpgw6.sprintspectrum.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03709
	for <sip@ietf.org>; Wed, 9 Apr 2003 11:53:01 -0400 (EDT)
Received: from pkcex004.sprintspectrum.com (pkcex004.sprintspectrum.com [208.10.75.139])
	by smtpgw6.sprintspectrum.com (8.12.9/8.12.8) with ESMTP id h39FtXU0016983;
	Wed, 9 Apr 2003 10:55:33 -0500 (CDT)
Received: by pkcex004.sprintspectrum.com with Internet Mail Service (5.5.2654.89)
	id <2PAFQ5WR>; Wed, 9 Apr 2003 10:55:34 -0500
Message-ID: <28B9108644E492469B911D587AABC97C0169534D@PKDWB01C.ad.sprint.com>
From: "Santharam, Arun [CC]" <asanth01@sprintspectrum.com>
To: Ashish Naik <ashishn@mahindrabt.com>, "Sip@Ietf. Org" <sip@ietf.org>
Subject: RE: [Sip] Session Mobility in SIP
Date: Wed, 9 Apr 2003 10:55:28 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.89)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2FEB0.711B9DD4"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-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_01C2FEB0.711B9DD4
Content-Type: text/plain

Ashish,

 

Please find comments inline.

 

Thank you

arun

 

-----Original Message-----
From: Ashish Naik [mailto:ashishn@mahindrabt.com] 
Sent: Wednesday, April 09, 2003 4:01 AM
To: Sip@Ietf. Org
Subject: [Sip] Session Mobility in SIP

 

How is SIP going to address session mobility ? Is there any initiative taken
up for this ? 

 

> This has been addressed in 3GPP standards. Please refer to the 3GPP All IP
architecture specifications.

 

SIP is said to be a better alternative than Mobile IP. Can I have some
latest development document references ?

 

 

>  SIP is not going to replace Mobile IP. It is going to leverage Mobile IP
for session management in 3G wireless networks.

 

 

Regards,
Ashish Naik
-------------------
CoE Mobile Computing
Phone: 4018100 Ext 3070 

 


*********************************************************
Disclaimer

This message (including any attachments) contains 
confidential information intended for a specific 
individual and purpose, and is protected by law. 
If you are not the intended recipient, you should 
delete this message and are hereby notified that 
any disclosure, copying, or distribution of this
message, or the taking of any action based on it, 
is strictly prohibited.

*********************************************************
Visit us at http://www.mahindrabt.com



------_=_NextPart_001_01C2FEB0.711B9DD4
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* 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:#606420;
	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;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3D"#606420">

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Ashish,</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Please find comments =
inline.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Thank you</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>arun</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Ashish Naik
[mailto:ashishn@mahindrabt.com] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> =
</span></font><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>Wednesday,
 April 09, 2003</span></font><font size=3D2 face=3DTahoma><span =
style=3D'font-size:
10.0pt;font-family:Tahoma'> </span></font><font size=3D2 =
face=3DTahoma><span
 style=3D'font-size:10.0pt;font-family:Tahoma'>4:01 =
AM</span></font><font size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'><br>
<b><span style=3D'font-weight:bold'>To:</span></b> Sip@Ietf. Org<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> [Sip] Session =
Mobility in
SIP</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>How is SIP going to =
address session
mobility ? Is there any initiative taken up for this ? =
</span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
color=3Dnavy
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; This has been addressed in =
3GPP
standards. Please refer to the 3GPP All IP architecture =
specifications.</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>SIP is said to be a better
alternative than Mobile IP. Can I have some latest development document =
references
?</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; &nbsp;SIP is not going to =
replace Mobile
IP. It is going to leverage Mobile IP for session management in 3G =
wireless
networks.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

</div>

<p style=3D'margin-left:.5in'><font size=3D2 face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial'>Regards,<br>
Ashish Naik<br>
-------------------<br>
CoE Mobile Computing<br>
Phone: 4018100 Ext 3070 </span></font></p>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

</div>

</div>

</body>

</html>
<html>
<br>
*********************************************************<br>
Disclaimer<br>
<br>
This message (including any attachments) contains <br>
confidential information intended for a specific <br>
individual and purpose, and is protected by law. <br>
If you are not the intended recipient, you should <br>
delete this message and are hereby notified that <br>
any disclosure, copying, or distribution of this<br>
message, or the taking of any action based on it, <br>
is strictly prohibited.<br>
<br>
*********************************************************<br>
Visit us at http://www.mahindrabt.com<br>
<br>
------_=_NextPart_001_01C2FEB0.711B9DD4--
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Wed Apr  9 18:04:02 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16467
	for <sip-archive@odin.ietf.org>; Wed, 9 Apr 2003 18:04:02 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h39M9PV01298
	for sip-archive@odin.ietf.org; Wed, 9 Apr 2003 18:09:25 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39M8Z801097;
	Wed, 9 Apr 2003 18:08:35 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39M1v832533
	for <sip@optimus.ietf.org>; Wed, 9 Apr 2003 18:01:57 -0400
Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16147
	for <sip@ietf.org>; Wed, 9 Apr 2003 17:56:04 -0400 (EDT)
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 h39Lwc917016
	for <sip@ietf.org>; Wed, 9 Apr 2003 16:58:38 -0500
From: Robert Sparks <rsparks@dynamicsoft.com>
To: sip@ietf.org
Content-Type: text/plain
Message-Id: <1049925449.934.64.camel@RjS.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.3 
Date: 09 Apr 2003 16:57:30 -0500
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] SIMPLEt registration closes April 15
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-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 registration closes April 15

Please register _NOW_ at http:simplet.jasomi.com

If you are planning to attend but need a few more days before
registering, please send me a private note to help me build
a better final attendance estimate.

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 mailnull@www1.ietf.org  Wed Apr  9 21:35:55 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22604
	for <sip-archive@odin.ietf.org>; Wed, 9 Apr 2003 21:35:55 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3A1fMS15092
	for sip-archive@odin.ietf.org; Wed, 9 Apr 2003 21:41:22 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A1f0815053;
	Wed, 9 Apr 2003 21:41:00 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A1YS814004
	for <sip@optimus.ietf.org>; Wed, 9 Apr 2003 21:34:28 -0400
Received: from mail.astri.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22508
	for <sip@ietf.org>; Wed, 9 Apr 2003 21:28:29 -0400 (EDT)
Received: from patrickXP (Firewall [203.198.202.1])
	by mail.astri.org (8.11.6/8.11.2) with ESMTP id h3A1b7Y16947
	for <sip@ietf.org>; Thu, 10 Apr 2003 09:37:07 +0800
From: "Patrick Lam" <patrickl@astri.org>
To: <sip@ietf.org>
Date: Thu, 10 Apr 2003 09:33:26 +0800
Message-ID: <003c01c2ff01$2f272560$2306050a@patrickXP>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_003D_01C2FF44.3D4A6560"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
X-MS-TNEF-Correlator: 00000000A495D97211F6D54497CF24BD1531C79FC4E42800
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Subject: [Sip] Transactions and Dialogs... Don't understand their relationship!
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_003D_01C2FF44.3D4A6560
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear all:

Is transaction related to dialog at all?  Or should they be seen as =
related?

It seems to me that transactions are identified by branch parameter, and
dialogs are identified by Call-ID (plus To/From tags).  But can I say =
that
an INVITE + ACK transactions create a dialog?  And does a dialog end =
with
its associated transaction, and vice versa?

To me, I see that transactions are just logical components of SIP =
elements
(like client transaction and server transaction).  They just have to be
implemented for the SIP elements to work.  However, according to RFC =
3261,
p.24 and 25:

SIP Transaction: A SIP transaction occurs between a client and a server =
and
comprises all messages from the first request sent         from the =
client
to the server up to a final (non-1xx) response sent from the server to =
the
client.  If the request is INVITE         and the final response is a
non-2xx, the transaction also includes an ACK to the response.  The ACK =
for
a 2xx response to an INVITE request is a separate transaction.

It sounds like a transaction is indeed a "physical" relationship between
requests and responses.  Therefore, it sounds quite similar to the =
concept
of dialogs.

What I do not understand is that if we already have a concept of dialog, =
who
do we still need the concept of transaction?

I guess I am seriously misunderstanding the concepts here.  Can someone
please explain to me the relationship and difference between =
transactions
and dialogs?

Thanks very much in advance.

Patrick Lam



------=_NextPart_000_003D_01C2FF44.3D4A6560
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Disposition: attachment;
	filename="winmail.dat"
Content-Transfer-Encoding: base64

eJ8+IhsBAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANMHBAAKAAkAIQAAAAQAFgEB
A5AGAGwUAAAnAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB
AAAAQQAAAFRyYW5zYWN0aW9ucyBhbmQgRGlhbG9ncy4uLiBEb24ndCB1bmRlcnN0YW5kIHRoZWly
IHJlbGF0aW9uc2hpcCEAAAAAAgFxAAEAAAAWAAAAAcL/AS7FWHScQJI/RdSxBfVTTrbuIAAAAgEd
DAEAAAAYAAAAU01UUDpQQVRSSUNLTEBBU1RSSS5PUkcACwABDgAAAABAAAYOAO4AHwH/wgECAQoO
AQAAABgAAAAAAAAApJXZchH21USXzyS9FTHHn8KAAAADABQOAAAAAAsAHw4BAAAAAgEJEAEAAAAQ
EAAADBAAAHAwAABMWkZ1uXyUpIMACgByY3BnOTUBQAx1YwBQAQRzdHNowQVwYmNoMTQO9AkAmw9w
DuVoDeAQRmJpAUOBC2BuZzEwMzMRpuRmZRIgMjgB9wKkA2NHAgAPcArAc2V0AtFwKHJxMgAAKgqh
bm+tFOAgExAWMTYSMDAOMM40FrEB0BagNH0HbQKD7wBQA9QUjxWbYhZxFuAWQm8bhBdgBxMCgzIE
RhlNMfUVjDcWkTkWMxcCFuAXYP8IVQeyAoMSUBQtHOEaDg4wPw4wEwEj4R9QFoAf0jd9Pwa0GHQC
1CH/Iwsn731X6QuAZ2QpIXMYdCFxJer/KfAPoCbPJBIWgCfwFqASIEcs5STgB3BTdW4VgmaDB0AF
QMvOzOV9GHT3KxEUPCnwNisvFjMWoCg8RFBNKSFMaVUt57eAc7LTqfrF6S603zBCL18wbzF/KNJA
MsYhJN43Kh82Dyw/LUJALYQhJC44IY89kjqSIAdtIEN6RSEkOT2/FtA+7z/1edpyAoM0GME0/TYY
wUI/9QOCRwnRa0O0HOFETialnUW/VAhwQ7QhfzE3OVFDSN8DgihIZWIJcHf+KUO0Ly9LwD7fTPYH
EAGgaw3gTdU1Tl84NfVP70L/LjEN4EO0NM9FIEqxUz9NI6JWCJB0bmEHgWVN1d89oRj8PrgHE0BG
NEDRWU33QfdaxUOVNRjPRShaxEbIvjUc4V5+SKZaxEomNUqx7159S9daxE1rNTphY95aTH1Q+zVR
0V59UvdaxFSJNd818V5+VnZlVVgONT2hHR3dPrYxQEAgiEBGNUDRb77/QfVxLUOVRTIdHUUmcSxG
yP9IknXPJqRxLEomVmJ4/kvV+3EsTWs2OmF8D3DPfiJRCr42UdF4/lL1cSxUiTY18f94/1Z0fX1Y
DkvAJb0Z1QYA6S2TIFcHkHQEkS3vGKH+OBQPinYyxotfM9wW4I0v/4p2OGePNkO1iY+SdYr8AoAr
ApEI5jsJbzCXj2Uy/2lwmLqZ0ZmPmpmYpJrCmS//nP+cvZw/mm+YvxLwEyCiiv+joaNfpGmYpKSS
ov+mz6aN96YPpD+oBDl4wKtUrLGk06essAKCDwB5bAeQaAng6nQAAHEDIWwRgQUQAUDDFeAD8GRj
dGwKsQBgHnMKsLAQGXCwUm51bSGMAWF1dG8AYGRqxnUPAAUQZ2h0r1EKAUuvIAoBaQGQcDADsjLn
D6AR5xKoXGsEkSkheMD/EBICshDCAGABMg9htoEPkc5jCcCv0LPjbnC0ObgSwxMgAzBzbmV4GcAH
sM8FsADAAnMVoGNzEiADMHex0ClQVLB2FhAO8Bmgbc5pEMC7AAnwIEQBELGANS5BUArAYQnAs1Bo
IO5GAiG6NA8QMQBQDxADYC53CzCyIAGAcykQZHS8aEISULIgCrC7AGwSIPs9oL+kcsAYEAC/hgGA
wYfKYsGHcr+CY2IKsDowj8NyOoDD0wTwZWxsr8H/v1C+8QFADxC7UAAgLjG+Af9NkMCgxiYJUMZE
DLHGU7BA+cZEZGfHJsigyCa18MZE/nYDMK7qr8+w37HvsvzOUf8R87PFEuOz0bXftu+39M/n/9MU
uUW+MLt8udRW4AGgrlB9ujc1utq8kAjQHNC5QWL/y/AJgAIgurKuIRmQy2APkBA2ODk4XjAgSHne
cASQsuFHA7pzNtcfpRD/2D/ZS71wxOCvsAmA2h9LwP+62gvjxDDOUdDTAFDRRQ6B39Hm3H27qQ7w
2jFzAiBa8bMO8AWgbXAV8t1PRQDA/QMQU64yS8Ct41Lgyo/Ln//Mr82/zs+0SB/RtaZ4wNFF/3jA
0dYSULd/uIbuEtx43SL31HO5MtktUAtiVuC5gbo3/jngDNsi4x/kJ9ktAHAV4HcBkFSwAiAgl6AS
4Jegbv/EwK3jDAHoP+lP6l/rb+x//+2P0P/vr/C/8c+5gQwA90//+F/5ZouQ9MQL8OJAru/77//8
//4P/xhFILPvtP/hn9If/7gvuTIE3tTNBs9Ugd6A+bH/9KS6QwmAriDF8NZB59AYAvsX9LuwcM+A
k6DmQcAgR2DPT2BPYAEBGBFoeU2Q5kDfGJSuULtQxyAbk24dgHCg5xvnocAchWpj/rEddA0S/Rui
Zt5jHdWuIAqQ+XFZAP8OMR9zCoDEwB3V9HC8EZJAfxiRG6IIgiH2GWdpcKUQN0M3YKywDQpcJzug
Lfcpohv0C5Bi5MEpoAEU0ZKfAa970VEwCsCzcmktNeC9/rI34OEdsBgFw3B4KKL7suEooSAkshtv
HH8djx6fHx+m4kAgbyF/Io82Nzbv5qAywOJAJGFvJK8lsO6x/yef4tCRICjbNeOy4TXiKk//K18s
by1/Lo8vnzCvMb8yw+970CRhJFAaAFgzfzSBlEL/J64UwChRKOpDo7LhQ6I3v/84zznfOu87/z0P
Ph8/LzLCe9mwQJZoQS80gSd/Q4E4/40RQ/tRYkUCUWFFf0aPR5//SK9Jv0rPS99M7zLPM98nrv81
gSjMXsOy4V7CUy9UP1VP/1ZfV29Yf1mPWp9AP1x/Ql/5/rI0Myi9bIOy4WyCYJ//Ya9iv2PPZN9l
72b/aA9N/+dqL1AfCXE1MDYNejOy4f96Mm5fb29wf3GPcp9zr3S//3XPW69cv3k/hHB6bYeye5L/
h7F8D30ffi9/P4BPgV+Cb9+Df2kfhV9rP/6yNiAgKMzflWOy4ZViiXblAG32ECWivxjB5kDmoKUg
h6DW8DYXqP5vxcHSka6gGFiZxpgumXt95WB1j/EJcLqgF6SioHZidNZAIHtV2oAKAW7vF5UWAp5y
n5MzUXCgcJjg95+T2Yag5DWSMA6QbIAlsMsKgNoxd9SwOTAOMKKj+mgOIDigcPYgvBDFUNYw45Vy
xVBuYmoKsKjAuwC/ATABYNXBrnDCcJtgaNXAznqlcsig5wByZ/RwpsHOaI7z6ADRsWd2p5mmUfsM
oDdRN5JxqCGpFeags9D/p2KmUI2RqCKq4azAjBDlcf/54LuQCXD5UA5w0pKlcedQg9ow71B2aWV3
a4+xfjWtc8SwCvAPMSZACtBs/Hl0nxD0cJtgpNGvFwzA/+cAC/AK0Nvw5bDGENygipD/CrCKkJ5x
j7EJcK8grnEKUP/WQL6hrxGeccXgyVGKkBrwvGty3ACbYPlQs9F3v7D/nnGtc7RRnVEZ0LlRzuAM
AP/SgvRwxMKxgd6BKBCKILwR7mSxAfugv7BwnWAKUAqx/zTws8cWAr6A+WCiBvYhmjDzrtGdMHRk
CWLUcSZApUH8bmj6EbrDu0LSgjWCutLx5KFjaWbnYOfgpNOeoMcX0QtwutFsdmziQAtx/mOl0L6y
jiK/Qo+0KKILcD8LIA5wvnELcCmAxfAgLv+ZJL7G71C/YsYQCqC/38Dv/cH/bA7AC3CdIcOvxL/F
z3+/IM/wC3CygMN/yE/JVSkfwjyuAMcfzA/JNWIgKP+S8c0/vvOjQcrvz7/Qz9Hf/b8gN9MTv6/U
j9Wfza0PcP/TL9i/2c/a378RdyDXv91f995v33WikXISEBlx9HEJP/8KTwtfDG//BeRi5oDziv+C
/8qwDl8PbyYvEX8SjxOQ+pC3EQH2QQ9wY+2B9HBz6izHEK/rMRA0IERl5oD5IN23ADqS8fDvoFcg
JDHmcT+JcvUv6kn21fKv87lJc/8IcOoAvtCPEAgzrBAZgrsQvefwILZw5uC2MAfAdPSinj/3P/G/
+c/z1yBP9JDPqtG0EPyxu/B5ICVgAdDuZRWR5rD8Rj/21fbf/p///6/6fv2AAtGl4PzCl9EawP8g
AAavAPr7mQmf87msQAwv/wEJDe/zueaApjEP3wEYmhHvsbC9wK2QuxBiAoH7oSaAziDp4pfQkJBy
LAMQj8C//PX7cBFxD6/zqhN8Q7bxOC1JRN7wIyDoUCBUqG8vRrmgbQJAYRYAvCkuBK8FvxafARhC
5+DWIK5wAwBJAdBhAoAJUgMVYftQTlZJVEUg4CsgQUNL+4r7cODw7/RwkJADEPz1PxrvG/8dD18B
JxrfI68kv/PXQRWCb+usICIHIKVBIOYQAlATYPuwsAMRc/PwNPD8k/uoFVTvrYCPIC3Ak7FhIp/4
TwP6/yhv87kZ8AkRFVAfIQigMV//CqsfkiDbFjLoQiZvJ38z///z1/0x7cDm4DdPOF85b/PXD6vS
rICP4ftwb2YgU/xJUDt/PI89n/PXiiB2IP8/kkBfQW9CfwEnRI9Fn0av/fPmKOVw7JAe0OVwj+H7
i9sVcr7gcpnR+4opSj/zuf8awEg/SU9PHzKIAmI3A+cQ94oQ/MICoWl2MUQj/KGlsa8CQkADRAb8
wnelwGtQv3dRz1Lf87lItyCKARVCYw+r0OSQ7NH8wlJGQyD5bJA2MRVQWJ9Zr1q/8+aMcC7rIBVj
MjU6A93/5GtesuU65h/nL+g/6U/qXPdocetsaoA17QeGcO21hnD/7kbrwO7v7/Zror5xXv+hkX/t
0GXgX29svvPkb3BAElQ9+6g6IIBAA/ua8/Bjdb9pgAKRrzAC40xGFXJhkvH/b79x33LsiXJ3/3DP
eQ9y7P9NxRVyq9ObkCqCtwAJEaww+xqAKoFmGjNW8RiQaYD9gPmsEHF1rCAIcrGwfY96Sr+ExoFn
TFb84FbiTcV1gx99cxlw/MLJoBiQl7DlQCjBrHEtMXh4KfxBZiD/IWEzx4ffesKC0oFYTcaGdPtM
VFhhST/wVuKCVpuQH/X/iw+ELyZBFXKBtImiioaQAvvJoInyMopAFVBW4kzLnbD+b3sPfS+RX3r/
fA+Xj5if/xNgtpAZsLeAFhEDACCThnT/ioZYYVSRIINWosmglPGTyP9nUZxfkckf2I+ZyaC+4GlC
/yHh+5nCIJnfmu/46uRf5W//Zd9m72f/aQ/qv+vP7N/t7/9tz/APXq+nf6iOte+bf2B//wf5AgDh
8JAgTAPJoPuakBH/4eIYscmguU+6XbJFu7qy0+H0MVwnOTO/j7pfwa/5YXdoea9QO0HDf8CfxZ/9
wrk0x6/Ej8nPASf8UyFSf7LQiRB2ZoJVnnJ3kIqGc/+mcsvPzN/N7yYF1A9T7CGw/1ahM1GuoL0W
gnCuoAKxVeDeaanwjgg2gC3wcP2AP+H/FbXV71AKA9/ST9Nf28/0E/5XH5IfICpglKH9gL1BLjF/
rrBiUZARH4MYgCtwIfFsfSGxZAKAVTN24dpeFVB3/wHw4iLkAa2A3h/fL+A/F7f/gKE/gPyi2hyV
iS5/L48wn/PpX/sFIGeCgZAhAxAaULdNwfwQrXBsAoDZcHPiqP9dM9oYkCDXshrP6A/v7wEJ/xkQ
AwAsMAkgP3EUsFYQAyD5VwBleKnkCPaPcs95FXT+ZrFAIbDaYQKQ9z9DWnaEvzX8FYgDzf0vU+uw
gGuQILt/cfLhdRSRqhGtQHYUcf+f4N2v9e+4nwYft0/2vwJfDVwgUCHQraBjayBMfxTwCB8Gz91v
De8Jj6iOfQIAE/ADAN4/n04AAAMACVkDAAAAAwBAZQAAAAALABOACCAGAAAAAADAAAAAAAAARgAA
AAADhQAAAAAAAAMAFYAIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwAbgAggBgAAAAAAwAAA
AAAAAEYAAAAAUoUAABuXAQADACKACCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAAAEAAI4AIIAYA
AAAAAMAAAAAAAABGAAAAAGCFAAAAzAvxvP//HwsAQoAIIAYAAAAAAMAAAAAAAABGAAAAAIKFAAAB
AAAAHgBJgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAFAAAAMTAuMAAAAAALAHWACCAGAAAA
AADAAAAAAAAARgAAAAAGhQAAAAAAAAsAdoAIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwB3
gAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAACAfgPAQAAABAAAACkldlyEfbVRJfPJL0VMcef
AgH6DwEAAAAQAAAApJXZchH21USXzyS9FTHHnwIB+w8BAAAAlgAAAAAAAAA4obsQBeUQGqG7CAAr
KlbCAABtc3BzdC5kbGwAAAAAAE5JVEH5v7gBAKoAN9luAAAAQzpcRG9jdW1lbnRzIGFuZCBTZXR0
aW5nc1xwYXRyaWNrbFxMb2NhbCBTZXR0aW5nc1xBcHBsaWNhdGlvbiBEYXRhXE1pY3Jvc29mdFxP
dXRsb29rXE91dGxvb2sucHN0AAAAAwD+DwUAAAADAA00/TcCAAIBFDQBAAAAEAAAAE5JVEH5v7gB
AKoAN9luAAACAX8AAQAAADEAAAAwMDAwMDAwMEE0OTVEOTcyMTFGNkQ1NDQ5N0NGMjRCRDE1MzFD
NzlGQzRFNDI4MDAAAAAAAwAGEI6DQWYDAAcQwAQAAAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAAGUA
AABERUFSQUxMOklTVFJBTlNBQ1RJT05SRUxBVEVEVE9ESUFMT0dBVEFMTD9PUlNIT1VMRFRIRVlC
RVNFRU5BU1JFTEFURUQ/SVRTRUVNU1RPTUVUSEFUVFJBTlNBQ1RJT05TQVJFAAAAAMuJ

------=_NextPart_000_003D_01C2FF44.3D4A6560--

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



From mailnull@www1.ietf.org  Thu Apr 10 01:27:41 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26809
	for <sip-archive@odin.ietf.org>; Thu, 10 Apr 2003 01:27:40 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3A5XDK29588
	for sip-archive@odin.ietf.org; Thu, 10 Apr 2003 01:33:13 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A5WS829545;
	Thu, 10 Apr 2003 01:32:28 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A5N1829227
	for <sip@optimus.ietf.org>; Thu, 10 Apr 2003 01:23:01 -0400
Received: from web14712.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA26535
	for <sip@ietf.org>; Thu, 10 Apr 2003 01:16:58 -0400 (EDT)
Message-ID: <20030410051932.55259.qmail@web14712.mail.yahoo.com>
Received: from [203.215.160.34] by web14712.mail.yahoo.com via HTTP; Wed, 09 Apr 2003 22:19:32 PDT
Date: Wed, 9 Apr 2003 22:19:32 -0700 (PDT)
From: Shazia Irfan <shaziairfan80@yahoo.com>
Subject: Re: [Sip] Transactions and Dialogs... Don't understand their relationship!
To: Patrick Lam <patrickl@astri.org>, sip@ietf.org
In-Reply-To: <003c01c2ff01$2f272560$2306050a@patrickXP>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-582512916-1049951972=:54789"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-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-582512916-1049951972=:54789
Content-Type: text/plain; charset=us-ascii


SIP Transactions are actually composed of request corresponding responses. SIP send request to initiate particular action, i.e. INVITE request send to establish call, REGISTER request is send for registartion purposes.
On other hand Dialog represents a peer-to-peer SIP relationship between two user agents that persists for some time. The dialog facilitates sequencing of
messages between the user agents and proper routing of requests
between both of them.( as mention in RFC 3261).
The concept can be explained as, when UA when to establish call with other UA, it send INVITE request, when it receives response (provisional or final), a dialog establish. Transaction ends after receiving final response e.g. 200 OK, but dialog do not end. All mid session requests (re-INVITES, REFER etc.) are composed with the help of dialog
Now UA wants to terminate call, it send BYE request to other UA and this BYE request and its response terminate dialogs at both end.
Regards,
Shazia
 Patrick Lam <patrickl@astri.org> wrote:Dear all:

Is transaction related to dialog at all? Or should they be seen as related?

It seems to me that transactions are identified by branch parameter, and
dialogs are identified by Call-ID (plus To/From tags). But can I say that
an INVITE + ACK transactions create a dialog? And does a dialog end with
its associated transaction, and vice versa?

To me, I see that transactions are just logical components of SIP elements
(like client transaction and server transaction). They just have to be
implemented for the SIP elements to work. However, according to RFC 3261,
p.24 and 25:

SIP Transaction: A SIP transaction occurs between a client and a server and
comprises all messages from the first request sent from the client
to the server up to a final (non-1xx) response sent from the server to the
client. If the request is INVITE and the final response is a
non-2xx, the transaction also includes an ACK to the response. The ACK for
a 2xx response to an INVITE request is a separate transaction.

It sounds like a transaction is indeed a "physical" relationship between
requests and responses. Therefore, it sounds quite similar to the concept
of dialogs.

What I do not understand is that if we already have a concept of dialog, who
do we still need the concept of transaction?

I guess I am seriously misunderstanding the concepts here. Can someone
please explain to me the relationship and difference between transactions
and dialogs?

Thanks very much in advance.

Patrick Lam


> ATTACHMENT part 2 application/ms-tnef name=winmail.dat 


---------------------------------
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
--0-582512916-1049951972=:54789
Content-Type: text/html; charset=us-ascii

<P>SIP Transactions are actually composed of request corresponding&nbsp;responses. SIP send request to i<SPAN style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">nitiate </SPAN>particular action, i.e. INVITE request send to establish call, REGISTER request is send for registartion purposes.
<P>On other hand Dialog&nbsp;represents a peer-to-peer SIP relationship between two user agents that persists for some time. The dialog facilitates sequencing of<BR>messages between the user agents and proper routing of requests<BR>between both of them.( as mention in RFC 3261).
<P>The concept can be explained as, when UA when to establish call with other UA, it send INVITE request, when it receives&nbsp;response (provisional or final), a dialog establish. Transaction ends after receiving final response e.g. 200 OK, but dialog do not end. All mid session requests (re-INVITES, REFER&nbsp;etc.) are composed with the help of dialog
<P>Now UA wants to terminate call, it send BYE request to other UA and this BYE request and its response terminate dialogs at both end.
<P>Regards,
<P>Shazia
<P>&nbsp;<B><I>Patrick Lam &lt;patrickl@astri.org&gt;</I></B> wrote:
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">Dear all:<BR><BR>Is transaction related to dialog at all? Or should they be seen as related?<BR><BR>It seems to me that transactions are identified by branch parameter, and<BR>dialogs are identified by Call-ID (plus To/From tags). But can I say that<BR>an INVITE + ACK transactions create a dialog? And does a dialog end with<BR>its associated transaction, and vice versa?<BR><BR>To me, I see that transactions are just logical components of SIP elements<BR>(like client transaction and server transaction). They just have to be<BR>implemented for the SIP elements to work. However, according to RFC 3261,<BR>p.24 and 25:<BR><BR>SIP Transaction: A SIP transaction occurs between a client and a server and<BR>comprises all messages from the first request sent from the client<BR>to the server up to a final (non-1xx) response sent from the server to the<BR>client. If the request is INVITE and the fina!
 l response is a<BR>non-2xx, the transaction also includes an ACK to the response. The ACK for<BR>a 2xx response to an INVITE request is a separate transaction.<BR><BR>It sounds like a transaction is indeed a "physical" relationship between<BR>requests and responses. Therefore, it sounds quite similar to the concept<BR>of dialogs.<BR><BR>What I do not understand is that if we already have a concept of dialog, who<BR>do we still need the concept of transaction?<BR><BR>I guess I am seriously misunderstanding the concepts here. Can someone<BR>please explain to me the relationship and difference between transactions<BR>and dialogs?<BR><BR>Thanks very much in advance.<BR><BR>Patrick Lam<BR><BR><BR>&gt; ATTACHMENT part 2 application/ms-tnef name=winmail.dat </BLOCKQUOTE><p><br><hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/finance/mailsig/*http://tax.yahoo.com">Yahoo! Tax Center</a> - File online, calculators, forms, and more
--0-582512916-1049951972=:54789--
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Thu Apr 10 02:34:41 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09447
	for <sip-archive@odin.ietf.org>; Thu, 10 Apr 2003 02:34:41 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3A6eGi13033
	for sip-archive@odin.ietf.org; Thu, 10 Apr 2003 02:40:16 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A6do812919;
	Thu, 10 Apr 2003 02:39:50 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A6Xv811847
	for <sip@optimus.ietf.org>; Thu, 10 Apr 2003 02:33:57 -0400
Received: from mail.astri.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09247
	for <sip@ietf.org>; Thu, 10 Apr 2003 02:27:47 -0400 (EDT)
Received: from patrickXP (Firewall [203.198.202.1])
	by mail.astri.org (8.11.6/8.11.2) with ESMTP id h3A6aeY26974;
	Thu, 10 Apr 2003 14:36:40 +0800
From: "Patrick Lam" <patrickl@astri.org>
To: "'Shazia Irfan'" <shaziairfan80@yahoo.com>, <sip@ietf.org>
Subject: RE: [Sip] Transactions and Dialogs... Don't understand their relationship!
Date: Thu, 10 Apr 2003 14:32:54 +0800
Message-ID: <000a01c2ff2b$04cb3ca0$2306050a@patrickXP>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000B_01C2FF6E.12EE7CA0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
In-Reply-To: <20030410051932.55259.qmail@web14712.mail.yahoo.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_000B_01C2FF6E.12EE7CA0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Shazia:

 

Thanks for your explanation.  However, I still have some further
questions.

 

Now I understand the difference between dialog and transaction (at least
in terms of how they end).  But it seems like the only relationship
between the two is that - transaction creates (as in INVITE) or changes
(as in re-INVITE and REFER) a dialog.  Am I right?

 

Also, according to my understanding, the transaction that you are
talking about (created by INVITE and ended by a final response) is
different than the "Client/Server Transactions" mentioned in Section 17
of RFC 3261 (where I see them as more like logical components inside SIP
elements).  Is this correct?

 

Furthermore, do mid-session requests (re-INVITE, REFER, etc.) create new
transactions (i.e. use a new branch parameter)?

 

In addition, I do not see the clear purpose of the concept of
transaction (vs. the concept of dialog).  To me, dialog is a signaling
relationship between 2 or more SIP UAs.  It already includes the concept
of a transaction, doesn't it?  In terms of describing SIP signaling or
features in general, I do not see the role of transactions in the big
picture.  Am I missing something?

 

Thanks again.

 

Regards,

 

Patrick Lam

 

 

-----Original Message-----
From: Shazia Irfan [mailto:shaziairfan80@yahoo.com] 
Sent: Thursday, April 10, 2003 1:20 PM
To: Patrick Lam; sip@ietf.org
Subject: Re: [Sip] Transactions and Dialogs... Don't understand their
relationship!

 

SIP Transactions are actually composed of request corresponding
responses. SIP send request to initiate particular action, i.e. INVITE
request send to establish call, REGISTER request is send for
registartion purposes. 

On other hand Dialog represents a peer-to-peer SIP relationship between
two user agents that persists for some time. The dialog facilitates
sequencing of
messages between the user agents and proper routing of requests
between both of them.( as mention in RFC 3261). 

The concept can be explained as, when UA when to establish call with
other UA, it send INVITE request, when it receives response (provisional
or final), a dialog establish. Transaction ends after receiving final
response e.g. 200 OK, but dialog do not end. All mid session requests
(re-INVITES, REFER etc.) are composed with the help of dialog 

Now UA wants to terminate call, it send BYE request to other UA and this
BYE request and its response terminate dialogs at both end. 

Regards, 

Shazia 

 Patrick Lam <patrickl@astri.org> wrote: 

Dear all:

Is transaction related to dialog at all? Or should they be seen as
related?

It seems to me that transactions are identified by branch parameter, and
dialogs are identified by Call-ID (plus To/From tags). But can I say
that
an INVITE + ACK transactions create a dialog? And does a dialog end with
its associated transaction, and vice versa?

To me, I see that transactions are just logical components of SIP
elements
(like client transaction and server transaction). They just have to be
implemented for the SIP elements to work. However, according to RFC
3261,
p.24 and 25:

SIP Transaction: A SIP transaction occurs between a client and a server
and
comprises all messages from the first request sent from the client
to the server up to a final (non-1xx) response sent from the server to
the
client. If the request is INVITE and the final response is a
non-2xx, the transaction also includes an ACK to the response. The ACK
for
a 2xx response to an INVITE request is a separate transaction.

It sounds like a transaction is indeed a "physical" relationship between
requests and responses. Therefore, it sounds quite similar to the
concept
of dialogs.

What I do not understand is that if we already have a concept of dialog,
who
do we still need the concept of transaction?

I guess I am seriously misunderstanding the concepts here. Can someone
please explain to me the relationship and difference between
transactions
and dialogs?

Thanks very much in advance.

Patrick Lam


> ATTACHMENT part 2 application/ms-tnef name=winmail.dat 

 

  _____  

Do you Yahoo!?
Yahoo! <http://us.rd.yahoo.com/finance/mailsig/*http:/tax.yahoo.com>
Tax Center - File online, calculators, forms, and more


------=_NextPart_000_000B_01C2FF6E.12EE7CA0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:PMingLiU;
	panose-1:2 2 3 0 0 0 0 0 0 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@PMingLiU";
	panose-1:2 2 3 0 0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	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:0cm;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle18
	{font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DZH-TW link=3Dblue vlink=3Dblue>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D1 color=3Dnavy face=3DArial><span =
lang=3DEN-US
style=3D'font-size:9.0pt;font-family:Arial;color:navy'>Shazia:</span></fo=
nt></p>

<p class=3DMsoNormal><font size=3D1 color=3Dnavy face=3DArial><span =
lang=3DEN-US
style=3D'font-size:9.0pt;font-family:Arial;color:navy'>&nbsp;</span></fon=
t></p>

<p class=3DMsoNormal><font size=3D1 color=3Dnavy face=3DArial><span =
lang=3DEN-US
style=3D'font-size:9.0pt;font-family:Arial;color:navy'>Thanks for your
explanation.&nbsp; However, I still have some further =
questions.</span></font></p>

<p class=3DMsoNormal><font size=3D1 color=3Dnavy face=3DArial><span =
lang=3DEN-US
style=3D'font-size:9.0pt;font-family:Arial;color:navy'>&nbsp;</span></fon=
t></p>

<p class=3DMsoNormal><font size=3D1 color=3Dnavy face=3DArial><span =
lang=3DEN-US
style=3D'font-size:9.0pt;font-family:Arial;color:navy'>Now I understand =
the
difference between dialog and transaction (at least in terms of how they =
end).&nbsp;
But it seems like the only relationship between the two is that &#8211; =
transaction
creates (as in INVITE) or changes (as in re-INVITE and REFER) a =
dialog.&nbsp;
Am I right?</span></font></p>

<p class=3DMsoNormal><font size=3D1 color=3Dnavy face=3DArial><span =
lang=3DEN-US
style=3D'font-size:9.0pt;font-family:Arial;color:navy'>&nbsp;</span></fon=
t></p>

<p class=3DMsoNormal><font size=3D1 color=3Dnavy face=3DArial><span =
lang=3DEN-US
style=3D'font-size:9.0pt;font-family:Arial;color:navy'>Also, according =
to my
understanding, the transaction that you are talking about (created by =
INVITE
and ended by a final response) is different than the =
&#8220;Client/Server
Transactions&#8221; mentioned in Section 17 of RFC 3261 (where I see =
them as
more like logical components inside SIP elements).&nbsp; Is this =
correct?</span></font></p>

<p class=3DMsoNormal><font size=3D1 color=3Dnavy face=3DArial><span =
lang=3DEN-US
style=3D'font-size:9.0pt;font-family:Arial;color:navy'>&nbsp;</span></fon=
t></p>

<p class=3DMsoNormal><font size=3D1 color=3Dnavy face=3DArial><span =
lang=3DEN-US
style=3D'font-size:9.0pt;font-family:Arial;color:navy'>Furthermore, do =
mid-session
requests (re-INVITE, REFER, etc.) create new transactions (i.e. use a =
new
branch parameter)?</span></font></p>

<p class=3DMsoNormal><font size=3D1 color=3Dnavy face=3DArial><span =
lang=3DEN-US
style=3D'font-size:9.0pt;font-family:Arial;color:navy'>&nbsp;</span></fon=
t></p>

<p class=3DMsoNormal><font size=3D1 color=3Dnavy face=3DArial><span =
lang=3DEN-US
style=3D'font-size:9.0pt;font-family:Arial;color:navy'>In addition, I do =
not see
the clear purpose of the concept of transaction (vs. the concept of =
dialog). &nbsp;To
me, dialog is a signaling relationship between 2 or more SIP UAs.&nbsp; =
It
already includes the concept of a transaction, doesn&#8217;t it?&nbsp; =
In terms
of describing SIP signaling or features in general, I do not see the =
role of
transactions in the big picture.&nbsp; Am I missing =
something?</span></font></p>

<p class=3DMsoNormal><font size=3D1 color=3Dnavy face=3DArial><span =
lang=3DEN-US
style=3D'font-size:9.0pt;font-family:Arial;color:navy'>&nbsp;</span></fon=
t></p>

<p class=3DMsoNormal><font size=3D1 color=3Dnavy face=3DArial><span =
lang=3DEN-US
style=3D'font-size:9.0pt;font-family:Arial;color:navy'>Thanks =
again.</span></font></p>

<p class=3DMsoNormal><font size=3D1 color=3Dnavy face=3DArial><span =
lang=3DEN-US
style=3D'font-size:9.0pt;font-family:Arial;color:navy'>&nbsp;</span></fon=
t></p>

<p class=3DMsoNormal><font size=3D1 color=3Dnavy face=3DArial><span =
lang=3DEN-US
style=3D'font-size:9.0pt;font-family:Arial;color:navy'>Regards,</span></f=
ont></p>

<p class=3DMsoNormal><font size=3D1 color=3Dnavy face=3DArial><span =
lang=3DEN-US
style=3D'font-size:9.0pt;font-family:Arial;color:navy'>&nbsp;</span></fon=
t></p>

<p class=3DMsoNormal><font size=3D1 color=3Dnavy face=3DArial><span =
lang=3DEN-US
style=3D'font-size:9.0pt;font-family:Arial;color:navy'>Patrick =
Lam</span></font></p>

<p class=3DMsoNormal><font size=3D1 color=3Dnavy face=3DArial><span =
lang=3DEN-US
style=3D'font-size:9.0pt;font-family:Arial;color:navy'>&nbsp;</span></fon=
t></p>

<p class=3DMsoNormal><font size=3D1 color=3Dnavy face=3DArial><span =
lang=3DEN-US
style=3D'font-size:9.0pt;font-family:Arial;color:navy'>&nbsp;</span></fon=
t></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm =
0cm 4.0pt'>

<p class=3DMsoNormal><font size=3D2 face=3DTahoma><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Tahoma'>-----Original Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Shazia Irfan
[mailto:shaziairfan80@yahoo.com] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, April 10, =
2003
1:20 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Patrick Lam; =
sip@ietf.org<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: [Sip] =
Transactions
and Dialogs... Don't understand their relationship!</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DEN-US
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

<p><font size=3D3 face=3D"Times New Roman"><span lang=3DEN-US =
style=3D'font-size:12.0pt'>SIP
Transactions are actually composed of request =
corresponding&nbsp;responses. SIP
send request to i</span></font><span lang=3DEN-US>nitiate </span><span
lang=3DEN-US>particular action, i.e. INVITE request send to establish =
call,
REGISTER request is send for registartion purposes. </span></p>

<p><font size=3D3 face=3D"Times New Roman"><span lang=3DEN-US =
style=3D'font-size:12.0pt'>On
other hand Dialog&nbsp;represents a peer-to-peer SIP relationship =
between two
user agents that persists for some time. The dialog facilitates =
sequencing of<br>
messages between the user agents and proper routing of requests<br>
between both of them.( as mention in RFC 3261). </span></font></p>

<p><font size=3D3 face=3D"Times New Roman"><span lang=3DEN-US =
style=3D'font-size:12.0pt'>The
concept can be explained as, when UA when to establish call with other =
UA, it
send INVITE request, when it receives&nbsp;response (provisional or =
final), a
dialog establish. Transaction ends after receiving final response e.g. =
200 OK,
but dialog do not end. All mid session requests (re-INVITES, =
REFER&nbsp;etc.)
are composed with the help of dialog </span></font></p>

<p><font size=3D3 face=3D"Times New Roman"><span lang=3DEN-US =
style=3D'font-size:12.0pt'>Now
UA wants to terminate call, it send BYE request to other UA and this BYE =
request
and its response terminate dialogs at both end. </span></font></p>

<p><font size=3D3 face=3D"Times New Roman"><span lang=3DEN-US =
style=3D'font-size:12.0pt'>Regards,
</span></font></p>

<p><font size=3D3 face=3D"Times New Roman"><span lang=3DEN-US =
style=3D'font-size:12.0pt'>Shazia
</span></font></p>

<p><font size=3D3 face=3D"Times New Roman"><span lang=3DEN-US =
style=3D'font-size:12.0pt'>&nbsp;<b><i><span
style=3D'font-weight:bold;font-style:italic'>Patrick Lam
&lt;patrickl@astri.org&gt;</span></i></b> wrote: </span></font></p>

<blockquote style=3D'border:none;border-left:solid #1010FF =
1.5pt;padding:0cm 0cm 0cm 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-bottom:5.0pt'>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DEN-US
style=3D'font-size:12.0pt'>Dear all:<br>
<br>
Is transaction related to dialog at all? Or should they be seen as =
related?<br>
<br>
It seems to me that transactions are identified by branch parameter, =
and<br>
dialogs are identified by Call-ID (plus To/From tags). But can I say =
that<br>
an INVITE + ACK transactions create a dialog? And does a dialog end =
with<br>
its associated transaction, and vice versa?<br>
<br>
To me, I see that transactions are just logical components of SIP =
elements<br>
(like client transaction and server transaction). They just have to =
be<br>
implemented for the SIP elements to work. However, according to RFC =
3261,<br>
p.24 and 25:<br>
<br>
SIP Transaction: A SIP transaction occurs between a client and a server =
and<br>
comprises all messages from the first request sent from the client<br>
to the server up to a final (non-1xx) response sent from the server to =
the<br>
client. If the request is INVITE and the final response is a<br>
non-2xx, the transaction also includes an ACK to the response. The ACK =
for<br>
a 2xx response to an INVITE request is a separate transaction.<br>
<br>
It sounds like a transaction is indeed a &quot;physical&quot; =
relationship
between<br>
requests and responses. Therefore, it sounds quite similar to the =
concept<br>
of dialogs.<br>
<br>
What I do not understand is that if we already have a concept of dialog, =
who<br>
do we still need the concept of transaction?<br>
<br>
I guess I am seriously misunderstanding the concepts here. Can =
someone<br>
please explain to me the relationship and difference between =
transactions<br>
and dialogs?<br>
<br>
Thanks very much in advance.<br>
<br>
Patrick Lam<br>
<br>
<br>
&gt; ATTACHMENT part 2 application/ms-tnef name=3Dwinmail.dat =
</span></font></p>

</blockquote>

<p><font size=3D3 face=3D"Times New Roman"><span lang=3DEN-US =
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span lang=3DEN-US style=3D'font-size:12.0pt'>

<hr size=3D1 width=3D"100%" align=3Dcenter>

</span></font></div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DEN-US
style=3D'font-size:12.0pt'>Do you Yahoo!?<br>
<a =
href=3D"http://us.rd.yahoo.com/finance/mailsig/*http:/tax.yahoo.com">Yaho=
o!
Tax Center</a> - File online, calculators, forms, and =
more</span></font></p>

</div>

</div>

</body>

</html>

------=_NextPart_000_000B_01C2FF6E.12EE7CA0--

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



From mailnull@www1.ietf.org  Thu Apr 10 03:22:51 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10168
	for <sip-archive@odin.ietf.org>; Thu, 10 Apr 2003 03:22:51 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3A7SOd15770
	for sip-archive@odin.ietf.org; Thu, 10 Apr 2003 03:28:24 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A7S3815750;
	Thu, 10 Apr 2003 03:28:03 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33KTsK25753
	for <sip@optimus.ietf.org>; Thu, 3 Apr 2003 15:29:54 -0500
Received: from relay02.valueweb.net (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12025
	for <sip@ietf.org>; Thu, 3 Apr 2003 15:26:58 -0500 (EST)
Received: from thor.valueweb.net ([216.219.254.23]:59871 "EHLO
	thor.valueweb.net") by relay02.valueweb.net with ESMTP
	id <S230256AbTDCU3K>; Thu, 3 Apr 2003 15:29:10 -0500
Received: from [66.180.120.50] ([66.180.120.50]:54023 "HELO frankyuan")
	by thor.valueweb.net with SMTP id <S296966AbTDCU25>;
	Thu, 3 Apr 2003 15:28:57 -0500
Message-ID: <008801c2fa1f$a3bc9310$6500a8c0@frankyuan>
Reply-To: "Frank Yuan" <frankyuan@emergent-netsolutions.com>
From: "Frank Yuan" <frankyuan@emergent-netsolutions.com>
To: <sip@ietf.org>
Date: 	Thu, 3 Apr 2003 14:28:45 -0600
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0085_01C2F9ED.55703EA0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Subject: [Sip] How to send user defined parmameter with INVITE?
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0085_01C2F9ED.55703EA0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

Is there a way to send user defined parameter with INVITE or STATUS msg?
Since H323 uses Q931 as signaling control protocol and Q931 has user =
info element in SETUP msg,=20
H323 can send Setup Msg with user info.

How about SIP?  If SIP can do it, could you let me know how?


Thanx

Frank

------=_NextPart_000_0085_01C2F9ED.55703EA0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4807.2300" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>Hi,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Is there a way to send user defined =
parameter with=20
INVITE or STATUS msg?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Since H323 uses Q931 as signaling =
control protocol=20
and Q931 has user info element in SETUP msg, </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>H323 can send Setup Msg with user=20
info.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>How about SIP?&nbsp; If SIP can do it, =
could you=20
let me know how?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanx</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial =
size=3D2>Frank</FONT></DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_0085_01C2F9ED.55703EA0--

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



From mailnull@www1.ietf.org  Thu Apr 10 03:27:21 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10243
	for <sip-archive@odin.ietf.org>; Thu, 10 Apr 2003 03:27:21 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3A7Wtn16004
	for sip-archive@odin.ietf.org; Thu, 10 Apr 2003 03:32:55 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A7WZ815976;
	Thu, 10 Apr 2003 03:32:35 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h35H0O807720
	for <sip@optimus.ietf.org>; Sat, 5 Apr 2003 12:00:24 -0500
Received: from telesoft.indts.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10840;
	Sat, 5 Apr 2003 11:56:30 -0500 (EST)
Received: from indts_fs.indts.com (indts_fs.indts.com [201.64.64.29])
	by telesoft.indts.com (8.11.6/8.11.6) with ESMTP id h35GlPI06343;
	Sat, 5 Apr 2003 22:17:25 +0530
Received: by INDTS_FS with Internet Mail Service (5.5.2650.21)
	id <H1090J22>; Sat, 5 Apr 2003 22:28:46 +0530
Message-ID: <F73B646FCC01D5118F530002B32C3372010A58E5@INDTS_FS>
From: Nitin Kumar <nitin@indts.com>
Date: Sat, 5 Apr 2003 22:28:43 +0530 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sip] 486/603 Response issue in Proxy server
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

hi Folks,

Would like to get some clue on following issue.

I am using "SIP express Router" as my proxy server to test our SIP user
agents.
Now if one UA(lets say party A) sends INVITE to other UA (lets say party B)
via proxy server, we are finding that any non-2xx response (like 486 busy,
603 decline) received by proxy server from party B is not forwarded to party
A. Moreover proxy server is also sending valid ACK to non-2xx response to
party B. 

	A				PS (SIP express router)
B
	|					|
|
	|----------INVITE------------>|					|
	|
|----------INVITE------------>|	
	|<---------100 trying---------|					|
	|					|<---------100
trying---------|
	|					|
|
	|					|<---------180
trying---------|
	|<---------180 trying---------|					|
	|					|
|
	|					|<---------603
decline--------|
	|	603 not forwarded	      |
|
	|
|------------ACK------------->|
	|					|
|
	|					|
|
	|					|
|

any idea what may be the reason?

In case of successful call everything works fine.

will appreciate some clue from sip experts.

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



From mailnull@www1.ietf.org  Thu Apr 10 03:31:56 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10352
	for <sip-archive@odin.ietf.org>; Thu, 10 Apr 2003 03:31:56 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3A7bUd16793
	for sip-archive@odin.ietf.org; Thu, 10 Apr 2003 03:37:30 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A7bB816381;
	Thu, 10 Apr 2003 03:37:11 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h388nP803928
	for <sip@optimus.ietf.org>; Tue, 8 Apr 2003 04:49:25 -0400
Received: from spf1.us.outblaze.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02643
	for <sip@ietf.org>; Tue, 8 Apr 2003 04:44:12 -0400 (EDT)
Received: (qmail 6880 invoked from network); 8 Apr 2003 08:46:01 -0000
Received: from unknown (205.158.62.146)
  by spf1.us.outblaze.com with QMQP; 8 Apr 2003 08:46:01 -0000
Received: (qmail 29686 invoked from network); 8 Apr 2003 08:42:33 -0000
Received: from unknown (HELO ws3.hk5.outblaze.com) (202.77.181.90)
  by 205-158-62-146.outblaze.com with SMTP; 8 Apr 2003 08:42:33 -0000
Received: (qmail 29021 invoked by uid 1001); 8 Apr 2003 08:44:56 -0000
Message-ID: <20030408084456.29020.qmail@graffiti.net>
Content-Type: text/html; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-Mailer: MIME-tools 5.41 (Entity 5.404)
Received: from [203.200.20.226] by ws3.hk5.outblaze.com with http for
    ranjit1975@graffiti.net; Tue, 08 Apr 2003 16:44:56 +0800
From: "Ranjit Avasarala" <ranjit1975@graffiti.net>
To: "shilpa_ramesh" <shilpa_ramesh@indiatimes.com>, sip@ietf.org
Date: Tue, 08 Apr 2003 16:44:56 +0800
Subject: Re: [Sip] Proxy and redirect server
X-Originating-Ip: 203.200.20.226
X-Originating-Server: ws3.hk5.outblaze.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

<P>Hi</P>
<P>&nbsp;Actually redirect server could be a part of the proxy server itself. So proxy could internally contact redirect server and get the curret location of the user.</P>
<P>Ranjit</P>
<P><BR><BR>----- Original Message -----<BR>From: "shilpa_ramesh" <SHILPA_RAMESH@INDIATIMES.COM><BR>Date: Thu, 10 Oct 2002 10:03:06 +0530<BR>To: <SIP@IETF.ORG><BR>Subject: [Sip] Proxy and redirect server<BR><BR></P>
<P>Hello all,</P>
<P>I came across a paper where in it is given that a user sometimes contacts the proxy server first to connect to another user..but sometimes he contacts the redirect server...</P>
<P>can anyone tell me when r proxy servers used and when r redirect servers used??why can't we use redirect and proxy server as one single server???</P>
<P>thanks,</P>
<P>shilpa</P>
<HR>
<FONT face=Arial size=2><B>Get Your Private, Free E-mail from Indiatimes at </FONT><A href="http://email.indiatimes.com/"><FONT face=Arial size=2>http://email.indiatimes.com</FONT></A></B><BR>Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from <A href="http://www.planetm.co.in/">http://www.planetm.co.in</A> <PRE>Regards
Ranjit</PRE>
-- 
<p>____________________________________________________<br>
Get your free email from <a href="http://www.graffiti.net" target="_blank">http://www.graffiti.net</a></p>

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



From mailnull@www1.ietf.org  Thu Apr 10 03:38:12 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10444
	for <sip-archive@odin.ietf.org>; Thu, 10 Apr 2003 03:38:12 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3A7hk517202
	for sip-archive@odin.ietf.org; Thu, 10 Apr 2003 03:43:46 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A7hP817188;
	Thu, 10 Apr 2003 03:43:25 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39ABI831250
	for <sip@optimus.ietf.org>; Wed, 9 Apr 2003 06:11:18 -0400
Received: from mail.tssg.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19932;
	Wed, 9 Apr 2003 06:04:27 -0400 (EDT)
Received: from boolard (unknown [10.37.1.56])
	by mail.tssg.org (Postfix) with SMTP
	id 93C6818179; Wed,  9 Apr 2003 10:42:51 +0000 (GMT)
From: "Shane McCormack" <smccormack@tssg.org>
To: "Sip@Ietf. Org" <sip@ietf.org>
Cc: "Sipping@Ietf. Org" <sipping@ietf.org>
Date: Wed, 9 Apr 2003 10:55:34 +0100
Message-ID: <HKEILFGJCBMBHOCGMAJNAEHCDCAA.smccormack@tssg.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0085_01C2FE86.8BB0FCA0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Subject: [Sip] Geopriv and SIP current state
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0085_01C2FE86.8BB0FCA0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,
Could somebody please let me know how spatial location information will be
requested and returned using SIP. Will it be a new header in all messages or
can SUBSCRIBE messages request NOTIFY of geo location. Also what format will
this take, will it be similar to the presence XML format? Any help would be
much appreciated.

Regards

Shane McCormack

Research Assistant,
TSSG, Confederation House,
Waterford Business Park, Cork Road,
Waterford, Co. Waterford.

Phone: +353 51 302927     Fax: +353 51 302901
Mobile: +353 87 9955505
http://www.tssg.org
MSN: mccormackshane@hotmail.com





------=_NextPart_000_0085_01C2FE86.8BB0FCA0
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.2715.400" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D506375209-09042003>Hi,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D506375209-09042003>Could =
somebody=20
please let me know how spatial location information will be requested =
and=20
returned using SIP. Will it be a new header in all messages or can =
SUBSCRIBE=20
messages request NOTIFY of geo location. Also what format will this =
take, will=20
it be similar to the presence XML format? Any help would be much=20
appreciated.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D506375209-09042003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D506375209-09042003>Regards</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D506375209-09042003></SPAN></FONT>&nbsp;</DIV><FONT size=3D2>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-IE=20
style=3D"COLOR: black; mso-ansi-language: EN-IE"><FONT size=3D3>Shane=20
McCormack</FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-IE=20
style=3D"COLOR: black; mso-ansi-language: EN-IE"><FONT size=3D3>Research =

Assistant,</FONT></SPAN><FONT size=3D3><SPAN style=3D"COLOR: =
black"><BR></SPAN><SPAN=20
lang=3DEN-IE style=3D"COLOR: black; mso-ansi-language: EN-IE">TSSG, =
Confederation=20
House,</SPAN></FONT><FONT size=3D3><SPAN style=3D"COLOR: black"> =
<BR></SPAN><SPAN=20
lang=3DEN-IE style=3D"COLOR: black; mso-ansi-language: EN-IE">Waterford =
Business=20
Park, Cork Road,</SPAN></FONT><FONT size=3D3><SPAN style=3D"COLOR: =
black">=20
<BR></SPAN><SPAN lang=3DEN-IE=20
style=3D"COLOR: black; mso-ansi-language: EN-IE">Waterford, Co.=20
Waterford.</SPAN><SPAN lang=3DEN-IE style=3D"COLOR: black"> </SPAN><SPAN =

style=3D"COLOR: black; mso-fareast-font-family: 'Arial Unicode MS'; =
mso-color-alt: windowtext"><?xml:namespace=20
prefix =3D o ns =3D "urn:schemas-microsoft-com:office:office"=20
/><o:p></o:p></SPAN></FONT></P>
<P><SPAN lang=3DEN-IE=20
style=3D"FONT-SIZE: 12pt; COLOR: black; FONT-FAMILY: 'Times New Roman'; =
mso-ansi-language: EN-IE; mso-fareast-font-family: 'Times New Roman'; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA">Phone:=20
+353 51 302927&nbsp;&nbsp;&nbsp;&nbsp; Fax: +353 51 302901</SPAN><SPAN=20
style=3D"FONT-SIZE: 12pt; COLOR: black; FONT-FAMILY: 'Times New Roman'; =
mso-ansi-language: EN-GB; mso-fareast-font-family: 'Times New Roman'; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA">=20
<BR></SPAN><SPAN lang=3DEN-IE=20
style=3D"FONT-SIZE: 12pt; COLOR: black; FONT-FAMILY: 'Times New Roman'; =
mso-ansi-language: EN-IE; mso-fareast-font-family: 'Times New Roman'; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA">Mobile:=20
+353 87 9955505</SPAN><SPAN=20
style=3D"FONT-SIZE: 12pt; COLOR: black; FONT-FAMILY: 'Times New Roman'; =
mso-ansi-language: EN-GB; mso-fareast-font-family: 'Times New Roman'; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA">=20
<BR><A href=3D"http://www.tssg.org/"><SPAN lang=3DEN-IE=20
style=3D"mso-ansi-language: EN-IE">http://www.tssg.org</SPAN></A> =
<BR></SPAN><SPAN=20
lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; COLOR: black; FONT-FAMILY: 'Times New Roman'; =
mso-ansi-language: EN-US; mso-fareast-font-family: 'Times New Roman'; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA">MSN:=20
<A=20
href=3D"mailto:mccormackshane@hotmail.com">mccormackshane@hotmail.com</A>=
</SPAN><SPAN=20
lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; COLOR: black; FONT-FAMILY: 'Times New Roman'; =
mso-ansi-language: EN-GB; mso-fareast-font-family: 'Times New Roman'; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA">=20
</SPAN></P>
<P><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; COLOR: black; FONT-FAMILY: 'Times New Roman'; =
mso-ansi-language: EN-GB; mso-fareast-font-family: 'Times New Roman'; =
mso-fareast-language: EN-US; mso-bidi-language: =
AR-SA"></SPAN></FONT>&nbsp;</P>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0085_01C2FE86.8BB0FCA0--

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



From mailnull@www1.ietf.org  Thu Apr 10 03:54:24 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10921
	for <sip-archive@odin.ietf.org>; Thu, 10 Apr 2003 03:54:24 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3A7xtM18170
	for sip-archive@odin.ietf.org; Thu, 10 Apr 2003 03:59:55 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A7xG818151;
	Thu, 10 Apr 2003 03:59:17 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A7qd817938
	for <sip@optimus.ietf.org>; Thu, 10 Apr 2003 03:52:39 -0400
Received: from mail.astri.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10791
	for <sip@ietf.org>; Thu, 10 Apr 2003 03:46:31 -0400 (EDT)
Received: from patrickXP (Firewall [203.198.202.1])
	by mail.astri.org (8.11.6/8.11.2) with ESMTP id h3A7tTY29807;
	Thu, 10 Apr 2003 15:55:29 +0800
From: "Patrick Lam" <patrickl@astri.org>
To: "'Frank Yuan'" <frankyuan@emergent-netsolutions.com>, <sip@ietf.org>
Subject: RE: [Sip] How to send user defined parmameter with INVITE?
Date: Thu, 10 Apr 2003 15:51:42 +0800
Message-ID: <002101c2ff36$06e67a80$2306050a@patrickXP>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0022_01C2FF79.1509BA80"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
In-Reply-To: <008801c2fa1f$a3bc9310$6500a8c0@frankyuan>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0022_01C2FF79.1509BA80
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

May I ask what type of user information you would like to send? 

 

As far as I remember, the user-information message in Q.931 was pretty
much useless as far as providing user information is concerned.

 

In SIP, if you want to provide some 'end-to-end" text-based user
information, I guess you can use the Subject header in INVITE.

 

Regards,

 

Patrick Lam

 

-----Original Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Frank
Yuan
Sent: Friday, April 04, 2003 4:29 AM
To: sip@ietf.org
Subject: [Sip] How to send user defined parmameter with INVITE?

 

Hi,

 

Is there a way to send user defined parameter with INVITE or STATUS msg?

Since H323 uses Q931 as signaling control protocol and Q931 has user
info element in SETUP msg, 

H323 can send Setup Msg with user info.

 

How about SIP?  If SIP can do it, could you let me know how?

 

 

Thanx

 

Frank


------=_NextPart_000_0022_01C2FF79.1509BA80
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:PMingLiU;
	panose-1:2 2 3 0 0 0 0 0 0 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@PMingLiU";
	panose-1:2 2 3 0 0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	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:purple;
	text-decoration:underline;}
span.EmailStyle17
	{font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body bgcolor=3Dwhite lang=3DZH-TW link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D1 color=3Dnavy face=3DArial><span =
lang=3DEN-US
style=3D'font-size:9.0pt;font-family:Arial;color:navy'>May I ask what =
type of
user information you would like to send? </span></font></p>

<p class=3DMsoNormal><font size=3D1 color=3Dnavy face=3DArial><span =
lang=3DEN-US
style=3D'font-size:9.0pt;font-family:Arial;color:navy'>&nbsp;</span></fon=
t></p>

<p class=3DMsoNormal><font size=3D1 color=3Dnavy face=3DArial><span =
lang=3DEN-US
style=3D'font-size:9.0pt;font-family:Arial;color:navy'>As far as I =
remember, the
user-information message in Q.931 was pretty much useless as far as =
providing
user information is concerned.</span></font></p>

<p class=3DMsoNormal><font size=3D1 color=3Dnavy face=3DArial><span =
lang=3DEN-US
style=3D'font-size:9.0pt;font-family:Arial;color:navy'>&nbsp;</span></fon=
t></p>

<p class=3DMsoNormal><font size=3D1 color=3Dnavy face=3DArial><span =
lang=3DEN-US
style=3D'font-size:9.0pt;font-family:Arial;color:navy'>In SIP, if you =
want to
provide some &#8216;end-to-end&#8221; text-based user information, I =
guess you
can use the Subject header in INVITE.</span></font></p>

<p class=3DMsoNormal><font size=3D1 color=3Dnavy face=3DArial><span =
lang=3DEN-US
style=3D'font-size:9.0pt;font-family:Arial;color:navy'>&nbsp;</span></fon=
t></p>

<p class=3DMsoNormal><font size=3D1 color=3Dnavy face=3DArial><span =
lang=3DEN-US
style=3D'font-size:9.0pt;font-family:Arial;color:navy'>Regards,</span></f=
ont></p>

<p class=3DMsoNormal><font size=3D1 color=3Dnavy face=3DArial><span =
lang=3DEN-US
style=3D'font-size:9.0pt;font-family:Arial;color:navy'>&nbsp;</span></fon=
t></p>

<p class=3DMsoNormal><font size=3D1 color=3Dnavy face=3DArial><span =
lang=3DEN-US
style=3D'font-size:9.0pt;font-family:Arial;color:navy'>Patrick =
Lam</span></font></p>

<p class=3DMsoNormal><font size=3D1 color=3Dnavy face=3DArial><span =
lang=3DEN-US
style=3D'font-size:9.0pt;font-family:Arial;color:navy'>&nbsp;</span></fon=
t></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm =
0cm 4.0pt'>

<p class=3DMsoNormal><font size=3D2 face=3DTahoma><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Tahoma'>-----Original Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> sip-admin@ietf.org
[mailto:sip-admin@ietf.org] <b><span style=3D'font-weight:bold'>On =
Behalf Of </span></b>Frank
Yuan<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Friday, April 04, =
2003 4:29
AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> sip@ietf.org<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> [Sip] How to =
send user
defined parmameter with INVITE?</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DEN-US
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

<div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>Hi,</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>&nbsp;</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>Is there a way to send user defined parameter =
with
INVITE or STATUS msg?</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>Since H323 uses Q931 as signaling control =
protocol
and Q931 has user info element in SETUP msg, </span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>H323 can send Setup Msg with user =
info.</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>&nbsp;</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>How about SIP?&nbsp; If SIP can do it, could =
you let
me know how?</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>&nbsp;</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>&nbsp;</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>Thanx</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>&nbsp;</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>Frank</span></font></p>

</div>

</div>

</div>

</div>

</body>

</html>

------=_NextPart_000_0022_01C2FF79.1509BA80--

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



From mailnull@www1.ietf.org  Thu Apr 10 04:29:06 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11765
	for <sip-archive@odin.ietf.org>; Thu, 10 Apr 2003 04:29:06 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3A8YfN20797
	for sip-archive@odin.ietf.org; Thu, 10 Apr 2003 04:34:41 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A8YJ820775;
	Thu, 10 Apr 2003 04:34:19 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A8S5820529
	for <sip@optimus.ietf.org>; Thu, 10 Apr 2003 04:28:05 -0400
Received: from mail.astri.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11637
	for <sip@ietf.org>; Thu, 10 Apr 2003 04:21:57 -0400 (EDT)
Received: from patrickXP (Firewall [203.198.202.1])
	by mail.astri.org (8.11.6/8.11.2) with ESMTP id h3A8UvY31137
	for <sip@ietf.org>; Thu, 10 Apr 2003 16:30:57 +0800
From: "Patrick Lam" <patrickl@astri.org>
To: <sip@ietf.org>
Date: Thu, 10 Apr 2003 16:27:10 +0800
Message-ID: <003001c2ff3a$faedf500$2306050a@patrickXP>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0031_01C2FF7E.09113500"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-MS-TNEF-Correlator: 00000000A495D97211F6D54497CF24BD1531C79F84EB2800
Subject: [Sip] How is the NAT/Firewall solution status right now?
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0031_01C2FF7E.09113500
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear all:

I lost track of this a little while ago.  How is the status for =
NAT/Firewall
solution for SIP currently? =20

Is MIDCOM still the best one right now?

Actually, why does the SIP community not like the idea of opening a
particular public address (at the firewall) for an ALG, and let all the
traffic (heading any port) through to it?  I have asked many security
experts, it seems like as long as I close the corresponding sockets on =
the
ALG after the RTP sessions, allowing traffic to flow through the =
firewall
(toward the closed socket) should not cause much threat. =20

What is the current best solution for the NAT/firewall problem right =
now?

Thanks.

Patrick Lam

------=_NextPart_000_0031_01C2FF7E.09113500
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Disposition: attachment;
	filename="winmail.dat"
Content-Transfer-Encoding: base64

eJ8+IgoIAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANMHBAAKABAAGwAAAAQAFwEB
A5AGAOwNAAAnAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB
AAAAMwAAAEhvdyBpcyB0aGUgTkFUL0ZpcmV3YWxsIHNvbHV0aW9uIHN0YXR1cyByaWdodCBub3c/
AAACAXEAAQAAABYAAAABwv86+jHjp54rD7tOY69mnxKJaWI3AAACAR0MAQAAABgAAABTTVRQOlBB
VFJJQ0tMQEFTVFJJLk9SRwALAAEOAAAAAEAABg4AIsz0Ov/CAQIBCg4BAAAAGAAAAAAAAACkldly
EfbVRJfPJL0VMcefwoAAAAMAFA4AAAAACwAfDgEAAAACAQkQAQAAAJ4JAACaCQAA9hgAAExaRnW7
Y0F9gwAKAHJjcGc5NQFADHVjAFABBHN0c2jBBXBiY2gxNA70CQCbD3AO5WgN4BBGYmkBQ4ELYG5n
MTAzMxGm5GZlEiAyOAH3AqQDY0cCAA9wCsBzZXQC0XAocnEyAAAqCqFub60U4CATEBYxNhIwMA4w
zjQWsQHQFqA0fQdtAoPvAFAD1BSPFZtiFnEW4BZCPxuEF2AHExh0D6AULTEzHjYZ7xYzFqAfq31Q
TaELgGdMaVUVgmYHQAEFQLdzstOp+sX86X0Cgx4SHS8ePx9PIFIeQCCWGHQWoBQeMjM4xSPUIAdt
IENFJsUYwc8nbRbQKH8phXlyJsUSUF0ivjYYwSvfA4JHCdFrtybFHP8u0DIvDymEVAhwZSbFNTFP
NzcyfymEKMhIZWIJcHcpJsUin/81kChvNsYHEAGgDeA3pjWx7SLNOCPFOc9CIWEN4CbFXzlRLf4t
wT0vNvNWCJB09G5hB4FlN6UW4BjeKEh7BxMp1zQYzyuIRNUtNjTfLcEY/C7YRNQweTQxMUiu9zJm
RNQz5zQ0gUitNadE1L03PDQjwU4uRFw63DQ1se9IrTznRNQ+ejQ5UUiuQHZ7T6VCDjIBwBQfQIUg
liA6VweQdASRIR8iJDQ5f1ofWyYmN1wmAoACkQjmO4UJbzBhr2UyNTVi2v9j8WOvZLlixGTiY09n
H2bd/2ZfZI9i3xLwEyBsqm3BbX//bolixG6ybR9w73CtcC9uX/9yJF4hdXReIW7zXiACgg8AVHls
B5BoCeB0AABxfQMhbBGBBRABQBXgA/Bk2GN0bAqxAGBzCrB6MCMZcHpybnVtXNFhdcR0bwBgZGp1
DwAFEHhnaHR5cQoBeUAKAWnpAZBwMAOyMg+gEecSqPxcawSRILEyYBASArIQwt8AYAEyD2GAoQ+R
YwnAefB5fgNucH5ZgjITIAMwc/huZXgZwAewBbAAwAJzuRWgY3MSIAMwe/BkfVCcaXYWEA7wGaBt
aRDAc4UgCfAgRAEQe6BdAVCNCsBhCcB9cGggRgIhu4RUDxAxAFAPEANgdwswE3xAAYBzV3nwdGhC
7xJQfEAKsIUgbBIgOVCJxL5yijgQAImmAYCLp2KLp8ZyiaEE8GVsbHnhiXD/iREBQA8QhXAAIFzx
iCE3YP+KwI8mCVCPRAyxj1N6YI9EfGRnkCaRoJEmgBCPRHb/AzB5Cnnvev98D30cl1ER8/995RLj
ffF//4EPghSY55wU/4NliFCFnIP0QOABoHhwhFe+NYT6hrAI0Fngg2FilPA/CYACIITSeEEZkJRg
NjWFNaAyWfAgSHlwBJD3fQEws4STNqAfbzChP6JK/4eQjeB50AmAow81kIT6C+P/oQCXUZnTAFCa
RQ6BmualbfeFyQ7woyFzAiBFAQ7wBaBsbXAV8qIORQDAAxBTX3hSNZBg0xWgYcB2AlEg/HtVo3B5
wWDEsNGiUbEi57JDKFASMDg3AFCiSbJDzZ/wOSpgFtAzfQqhoyE6d4hQORZwtTQPgDY4PyhQAzAB
ZFbAAtFCMGJq/wBgCfCFIBAgAgGEEA8glmB2ZZowBbB6uBKRoADAcvZnC4GRoGiVAY3APNABQXxn
dro5uPGW0AuANZAw5w6ButC7tTk4D6C6Arjw7ne6pL2BMmBqrkJhwBkh/mwV4BIAgbK4EXhQoyAy
YNJ2CJB3awuAZDSAwCKfBPAHQBLxDuELUHl0scD/C4C40LdxwbeW8ADAliCVAP8MYBmgXQClkL8A
AGC/AAJR/8BxeTDBwMERlIACYIjBwbGfAlEAIJJRvwA3YGtyhrD3uNAV4MZxd4nQCTKDgH1wv5Yw
gaILgI3CxCGnYWYIkDpshjFkw6GUQInQcHV/yGCXAJTwBzDGZ6JCA2BvvyOQtLUDMRmyGaCUgGR5
IveDkQFAt+FueKBhwMyTzRLvgaIjsMyErYFjBpB4YA7wn7dzsVAVkgCABZBsdoog/9CBDmCEENCC
AZAAINESwHH9CfB0AcHQgRlwEgDQQZWg8wzQAZAgLrCU0JYyYNEy/10AlNDRr9K/08+LkZWgBYH/
1X/Wj9ef0PAPoJWgxSDVT/vaH9slKdQMNIDY793f2wX+YjcgApHfD9DDteHcv+GP/+Kf46/Q8DWw
5PLRf+Zf529/3305UOT/6o/rn+yv0OE5/+l/7x/wL/E2CvmTfHnPlU//ll98+QqiGYGiaH2/fs+Z
tP+akppPgX+CjRiVPNCp4wuA/4iQ/Aqqv5mmncCGcArByMHuOhiGAvyzJSAKhQavA4vPCI8JnwQv
BTxJIKdgEHCGIPpAuxBrIG9mD0A//3A6ENtw90DFwHhwIHfH/3AQkYcgby4govC9kH4gEAGJcIWB
DT8FePMhdB3DkCC4URIvBVpOQVT4L0ZpN3HIwRSvBWkT4BthMPmwaYegFFNTSVC8IGMz8GHA9aDB
sD8LP/8MTxdfGGcK1QrVHJ8OOjoQwE1JRENPTRPhr/C79xAR8mJcQQ+gg5Ag+lP6IPfBPxq/Cg8e
rx+/BdJKQfgQdcjBeSwQsXn/Gq8bvyZvBZal0CjfKe8q/98FpToBEfIZw15wbcoQfVD+eSyfLa8u
vxh298BdEPdA339QEeO0gAYgD6Jvv+B/gv8GUDF/Mo8znxh2CwE+oYawvwsfN+84/wV4ygDEcWM7
X/88bz1/BZaKor7BP39Aj0Gf/Rh2KBQQEePJEBbE33BDnz9Er0W/GIUUYl6QT5BMR/8ocF6QzOB4
cF0QyMER4w9RvmbJED9fST9KTwWHKBIA+/nwNrNuKLCucMYASD9PP/9QTxhnUv9UD1UfBaWJcF5g
1nX6cA9AbxGwdFavV7//WM8FpSNvXB9dLxhnDtH44P+FcfiANYDM4K/QUnHMoRoQ+zFBMCB4oyHD
UGCvGDkocP+XwGORhdAQEDVj+IAO8TbC/xAQDuDQ0K6CEfJez1/fZO//BaWuQBoh+JCHoFITrcAP
gP/MYGSfGCsZURHyTGEGUM/wn/5gaq9ZjBIfBUtSVBng966QvtAZQXMocGjfae9y7/9CpqdSNrJN
tlrBi4ARkVpH/3cvGDlHiXcfURv5wBbgkZDvclNoM8zgbVQpE+C48Iaw/8zgNSLBEMORY0DVIFqh
WlD/BiBbD3ZPfb8FlhFRgr8kj/cln4UPBdJX+OAPMBHFGgX/IjQY+3JiFmJ8976gxwBM8F5tIsmI
b4l/BZZU2rFr/HMuj5yGj4PKn8D44Ivgd4PvkN8Fw1AUEPpQD4FMPGFtk4+Un4evk2F9AAGcUAAA
AwDeP59OAAADAAlZAwAAAAMAQGUAAAAACwATgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAAD
ABWACCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMAG4AIIAYAAAAAAMAAAAAAAABGAAAAAFKF
AAAblwEAAwAigAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAABAACOACCAGAAAAAADAAAAAAAAA
RgAAAABghQAAAMwL8bz//x8LAEKACCAGAAAAAADAAAAAAAAARgAAAACChQAAAQAAAB4ASYAIIAYA
AAAAAMAAAAAAAABGAAAAAFSFAAABAAAABQAAADEwLjAAAAAACwB1gAggBgAAAAAAwAAAAAAAAEYA
AAAABoUAAAAAAAALAHaACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMAd4AIIAYAAAAAAMAA
AAAAAABGAAAAABiFAAAAAAAAAgH4DwEAAAAQAAAApJXZchH21USXzyS9FTHHnwIB+g8BAAAAEAAA
AKSV2XIR9tVEl88kvRUxx58CAfsPAQAAAJYAAAAAAAAAOKG7EAXlEBqhuwgAKypWwgAAbXNwc3Qu
ZGxsAAAAAABOSVRB+b+4AQCqADfZbgAAAEM6XERvY3VtZW50cyBhbmQgU2V0dGluZ3NccGF0cmlj
a2xcTG9jYWwgU2V0dGluZ3NcQXBwbGljYXRpb24gRGF0YVxNaWNyb3NvZnRcT3V0bG9va1xPdXRs
b29rLnBzdAAAAAMA/g8FAAAAAwANNP03AgACARQ0AQAAABAAAABOSVRB+b+4AQCqADfZbgAAAgF/
AAEAAAAxAAAAMDAwMDAwMDBBNDk1RDk3MjExRjZENTQ0OTdDRjI0QkQxNTMxQzc5Rjg0RUIyODAw
AAAAAAMABhBM3XqpAwAHEB8CAAADABAQAAAAAAMAERAAAAAAHgAIEAEAAABlAAAAREVBUkFMTDpJ
TE9TVFRSQUNLT0ZUSElTQUxJVFRMRVdISUxFQUdPSE9XSVNUSEVTVEFUVVNGT1JOQVQvRklSRVdB
TExTT0xVVElPTkZPUlNJUENVUlJFTlRMWT9JU01JRENPTQAAAABv9A==

------=_NextPart_000_0031_01C2FF7E.09113500--

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



From mailnull@www1.ietf.org  Thu Apr 10 04:51:02 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12293
	for <sip-archive@odin.ietf.org>; Thu, 10 Apr 2003 04:51:01 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3A8uba23012
	for sip-archive@odin.ietf.org; Thu, 10 Apr 2003 04:56:37 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A8uG822995;
	Thu, 10 Apr 2003 04:56:16 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A8oD822726
	for <sip@optimus.ietf.org>; Thu, 10 Apr 2003 04:50:13 -0400
Received: from shardagate.mahindrabt.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12183
	for <sip@ietf.org>; Thu, 10 Apr 2003 04:44:05 -0400 (EDT)
Received: from thisdomain (mailscan.sharda.mahindrabt.com [10.5.0.97])
	by shardagate.mahindrabt.com (8.12.8/8.12.8) with ESMTP id h3A8kS4L017735
	for <sip@ietf.org>; Thu, 10 Apr 2003 14:16:34 +0530
Received: from intranet.sharda.mahindrabt.com by mahindrabt.com ; Thu, 10 Apr 2003 14:02:48 +0530
Date: Thu, 10 Apr 2003 14:02:48 +0530
X-Originating-IP: 10.5.0.15
X-Auth-User: ashishn@mahindrabt.com
Received: from dscp00212 ([10.5.3.103])
	by intranet.sharda.mahindrabt.com (8.9.3/8.9.3) with SMTP id OAA08926
	for <sip@ietf.org>; Thu, 10 Apr 2003 14:16:15 +0530
From: "Ashish Naik" <ashishn@mahindrabt.com>
To: "Sip@Ietf. Org" <sip@ietf.org>
Date: Thu, 10 Apr 2003 14:19:59 +0530
Message-ID: <NFBBIJAAOFNEMIHBIFPIOEHKDHAA.ashishn@mahindrabt.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0036_01C2FF6C.44BC30D0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Subject: [Sip] Presence and Availibility
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0036_01C2FF6C.44BC30D0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

SIP addresses Presence and Availibility in SIMPLE and OSA/Parlay in PAM
specs. How thes two are interrelated as both SIP and OSA are part of 3GPP
standard.

Regards,
Ashish Naik
-------------------
CoE Mobile Computing
Phone: 4018100 Ext 3070

*********************************************************
Disclaimer

This message (including any attachments) contains 
confidential information intended for a specific 
individual and purpose, and is protected by law. 
If you are not the intended recipient, you should 
delete this message and are hereby notified that 
any disclosure, copying, or distribution of this
message, or the taking of any action based on it, 
is strictly prohibited.

*********************************************************
Visit us at http://www.mahindrabt.com


------=_NextPart_000_0036_01C2FF6C.44BC30D0
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.2800.1106" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D421414808-10042003>SIP =
addresses=20
Presence and Availibility in SIMPLE and OSA/Parlay in PAM specs. How =
thes two=20
are interrelated as both SIP and OSA are part of 3GPP=20
standard.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D421414808-10042003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Regards,<BR>Ashish=20
Naik<BR>-------------------<BR>CoE Mobile Computing<BR>Phone: 4018100 =
Ext 3070=20
</FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

<html>
<br>
*********************************************************<br>
Disclaimer<br>
<br>
This message (including any attachments) contains <br>
confidential information intended for a specific <br>
individual and purpose, and is protected by law. <br>
If you are not the intended recipient, you should <br>
delete this message and are hereby notified that <br>
any disclosure, copying, or distribution of this<br>
message, or the taking of any action based on it, <br>
is strictly prohibited.<br>
<br>
*********************************************************<br>
Visit us at http://www.mahindrabt.com<br>
<br>
</html>

------=_NextPart_000_0036_01C2FF6C.44BC30D0--


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



From mailnull@www1.ietf.org  Thu Apr 10 06:35:31 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14554
	for <sip-archive@odin.ietf.org>; Thu, 10 Apr 2003 06:35:31 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3AAf9I31068
	for sip-archive@odin.ietf.org; Thu, 10 Apr 2003 06:41:09 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AAeU831017;
	Thu, 10 Apr 2003 06:40:30 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AAYk829967
	for <sip@optimus.ietf.org>; Thu, 10 Apr 2003 06:34:46 -0400
Received: from web14706.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA14387
	for <sip@ietf.org>; Thu, 10 Apr 2003 06:28:35 -0400 (EDT)
Message-ID: <20030410103109.55871.qmail@web14706.mail.yahoo.com>
Received: from [203.215.160.34] by web14706.mail.yahoo.com via HTTP; Thu, 10 Apr 2003 03:31:09 PDT
Date: Thu, 10 Apr 2003 03:31:09 -0700 (PDT)
From: Shazia Irfan <shaziairfan80@yahoo.com>
Subject: RE: [Sip] Transactions and Dialogs... Don't understand their relationship!
To: Patrick Lam <patrickl@astri.org>, sip@ietf.org
In-Reply-To: <000a01c2ff2b$04cb3ca0$2306050a@patrickXP>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-986516671-1049970669=:54022"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-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-986516671-1049970669=:54022
Content-Type: text/plain; charset=us-ascii


 

 

>Now I understand the difference between dialog and transaction (at least in terms of >how they end).  But it seems like the only relationship between the two is that – >transaction creates (as in INVITE) or changes (as in re-INVITE and REFER) a dialog.  >Am I right?

 

Transaction creates, terminate dialog + can be used for changing media session information e.g. re-INVITE transaction can be used to hold the call between two calling parties, so this transaction do not change dialog but change session information. As according to RFC 3261 pp71

 

A 2xx response to an INVITE establishes a session, and it also creates a dialog between the UA that issued the INVITE and the UA that generated the 2xx response.

 

So session created by INVITE transaction can be change by further re-INVITE transactions.

 

>Also, according to my understanding, the transaction that you are talking about (created >by INVITE and ended by a final response) is different than the “Client/Server >Transactions” mentioned in Section 17 of RFC 3261 (where I see them as more like >logical components inside SIP elements).  Is this correct?

 

I think transaction are objects within SIP (if talk in OO terms) created by sending/receiving a request. Maintain states and handle retransmission of request or response. They are deleted after going to TERMINATED State.

 

>Furthermore, do mid-session requests (re-INVITE, REFER, etc.) create new transactions >(i.e. use a new branch parameter)?

 

Yes.

 

>In addition, I do not see the clear purpose of the concept of transaction (vs. the concept >of dialog).  To me, dialog is a signaling relationship between 2 or more SIP UAs.  It >already includes the concept of a transaction, doesn’t it?  In terms of describing SIP >signaling or features in general, I do not see the role of transactions in the big picture.  >Am I missing something?

 

No, dialog keep informtion of sequencing of message (through CSeq), and routing of messages (through From, To, Route and Contact fields). They have no link with media sessions, while Transaction have link with session, also Transaction take care of request/reponse retransmissions, timer management. Dialog and Transaction are actually two different entities. May be this explanation works!!. For further explanation pls. read sections 12 & 17.

 

Regards,

Shazia

 

 Patrick Lam <patrickl@astri.org> wrote:
Shazia:

 

Thanks for your explanation.  However, I still have some further questions.

 

Now I understand the difference between dialog and transaction (at least in terms of how they end).  But it seems like the only relationship between the two is that – transaction creates (as in INVITE) or changes (as in re-INVITE and REFER) a dialog.  Am I right?

 

Also, according to my understanding, the transaction that you are talking about (created by INVITE and ended by a final response) is different than the “Client/Server Transactions” mentioned in Section 17 of RFC 3261 (where I see them as more like logical components inside SIP elements).  Is this correct?

 

Furthermore, do mid-session requests (re-INVITE, REFER, etc.) create new transactions (i.e. use a new branch parameter)?

 

In addition, I do not see the clear purpose of the concept of transaction (vs. the concept of dialog).  To me, dialog is a signaling relationship between 2 or more SIP UAs.  It already includes the concept of a transaction, doesn’t it?  In terms of describing SIP signaling or features in general, I do not see the role of transactions in the big picture.  Am I missing something?

 

Thanks again.

 

Regards,

 

Patrick Lam

 

 

-----Original Message-----
From: Shazia Irfan [mailto:shaziairfan80@yahoo.com] 
Sent: Thursday, April 10, 2003 1:20 PM
To: Patrick Lam; sip@ietf.org
Subject: Re: [Sip] Transactions and Dialogs... Don't understand their relationship!

 

SIP Transactions are actually composed of request corresponding responses. SIP send request to initiate particular action, i.e. INVITE request send to establish call, REGISTER request is send for registartion purposes. 

On other hand Dialog represents a peer-to-peer SIP relationship between two user agents that persists for some time. The dialog facilitates sequencing of
messages between the user agents and proper routing of requests
between both of them.( as mention in RFC 3261). 

The concept can be explained as, when UA when to establish call with other UA, it send INVITE request, when it receives response (provisional or final), a dialog establish. Transaction ends after receiving final response e.g. 200 OK, but dialog do not end. All mid session requests (re-INVITES, REFER etc.) are composed with the help of dialog 

Now UA wants to terminate call, it send BYE request to other UA and this BYE request and its response terminate dialogs at both end. 

Regards, 

Shazia 

 Patrick Lam <patrickl@astri.org> wrote: 

Dear all:

Is transaction related to dialog at all? Or should they be seen as related?

It seems to me that transactions are identified by branch parameter, and
dialogs are identified by Call-ID (plus To/From tags). But can I say that
an INVITE + ACK transactions create a dialog? And does a dialog end with
its associated transaction, and vice versa?

To me, I see that transactions are just logical components of SIP elements
(like client transaction and server transaction). They just have to be
implemented for the SIP elements to work. However, according to RFC 3261,
p.24 and 25:

SIP Transaction: A SIP transaction occurs between a client and a server and
comprises all messages from the first request sent from the client
to the server up to a final (non-1xx) response sent from the server to the
client. If the request is INVITE and the final response is a
non-2xx, the transaction also includes an ACK to the response. The ACK for
a 2xx response to an INVITE request is a separate transaction.

It sounds like a transaction is indeed a "physical" relationship between
requests and responses. Therefore, it sounds quite similar to the concept
of dialogs.

What I do not understand is that if we already have a concept of dialog, who
do we still need the concept of transaction?

I guess I am seriously misunderstanding the concepts here. Can someone
please explain to me the relationship and difference between transactions
and dialogs?

Thanks very much in advance.

Patrick Lam


> ATTACHMENT part 2 application/ms-tnef name=winmail.dat 

 

---------------------------------

Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more



---------------------------------
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
--0-986516671-1049970669=:54022
Content-Type: text/html; charset=us-ascii

<P class=MsoNormal><FONT face=Arial color=navy size=1><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial"><EM></EM></SPAN></FONT>&nbsp;</P>
<P class=MsoNormal><FONT face=Arial color=navy size=1><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial"><EM></EM></SPAN></FONT>&nbsp;</P>
<P class=MsoNormal><FONT face=Arial color=navy size=1><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial"><EM>&gt;Now I understand the difference between dialog and transaction (at least in terms of &gt;how they end).&nbsp; But it seems like the only relationship between the two is that – &gt;transaction creates (as in INVITE) or changes (as in re-INVITE and REFER) a dialog.&nbsp; &gt;Am I right?</EM></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=1><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
<P class=MsoNormal><FONT face=Arial color=#111111 size=1><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial">Transaction creates, terminate dialog + can be used for changing media session information e.g. re-INVITE transaction can be used to hold the call between two calling parties, so this transaction do not change dialog but change session information. As according to RFC 3261 pp71</SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=#111111 size=1><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
<P class=MsoNormal><FONT face=Arial color=#111111 size=1><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial"><EM>A 2xx response to an INVITE establishes a session, and it also creates a dialog between the UA that issued the INVITE and the UA that generated the 2xx response.</EM></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=1><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
<P class=MsoNormal><FONT face=Arial color=navy size=1><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial">So session created by INVITE transaction can be change by further re-INVITE transactions.</SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=1><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
<P class=MsoNormal><FONT face=Arial color=navy size=1><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial"><EM>&gt;Also, according to my understanding, the transaction that you are talking about (created &gt;by INVITE and ended by a final response) is different than the “Client/Server &gt;Transactions” mentioned in Section 17 of RFC 3261 (where I see them as more like &gt;logical components inside SIP elements).&nbsp; Is this correct?</EM></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=1><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial"><EM></EM></SPAN></FONT>&nbsp;</P>
<P class=MsoNormal><FONT face=Arial color=navy size=1><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial">I think transaction are objects within SIP (if talk in OO terms) created by sending/receiving a request. Maintain states and handle retransmission of request or response. They are deleted after going to TERMINATED State.</SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=1><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P><FONT face=Arial color=navy size=1><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial">
<P class=MsoNormal><FONT face=Arial color=navy size=1><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial"><EM>&gt;Furthermore, do mid-session requests (re-INVITE, REFER, etc.) create new transactions &gt;(i.e. use a new branch parameter)?</EM></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=1><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial"><EM></EM></SPAN></FONT>&nbsp;</P>
<P class=MsoNormal><FONT face=Arial color=navy size=1><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial">Yes.</SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=1><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
<P class=MsoNormal><FONT face=Arial color=navy size=1><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial"><EM>&gt;In addition, I do not see the clear purpose of the concept of transaction (vs. the concept &gt;of dialog). &nbsp;To me, dialog is a signaling relationship between 2 or more SIP UAs.&nbsp; It &gt;already includes the concept of a transaction, doesn’t it?&nbsp; In terms of describing SIP &gt;signaling or features in general, I do not see the role of transactions in the big picture.&nbsp; &gt;Am I missing something?</EM></SPAN></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=1><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
<P class=MsoNormal><FONT face=Arial color=navy size=1><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial">No, dialog keep informtion of sequencing of message (through CSeq), and routing of messages (through From, To, Route and Contact fields). They have no link with media sessions, while Transaction have link with session, also Transaction take care of request/reponse retransmissions, timer management. Dialog and Transaction are actually two different entities. May be this explanation works!!. For further explanation pls. read sections 12 &amp; 17.</SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=1><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
<P class=MsoNormal><FONT face=Arial color=navy size=1><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial">Regards,</SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=1><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial">Shazia</SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=1><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial"></SPAN></FONT></SPAN></FONT>&nbsp;</P>
<P>&nbsp;<B><I>Patrick Lam &lt;patrickl@astri.org&gt;</I></B> wrote:
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">
<META content="Microsoft Word 10 (filtered)" name=Generator>
<STYLE>
<!--
 /* Font Definitions */
 @font-face
	{font-family:PMingLiU;
	panose-1:2 2 3 0 0 0 0 0 0 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@PMingLiU";
	panose-1:2 2 3 0 0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	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:0cm;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle18
	{font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</STYLE>

<DIV class=Section1>
<P class=MsoNormal><FONT face=Arial color=navy size=1><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial">Shazia:</SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=1><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
<P class=MsoNormal><FONT face=Arial color=navy size=1><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial">Thanks for your explanation.&nbsp; However, I still have some further questions.</SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=1><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
<P class=MsoNormal><FONT face=Arial color=navy size=1><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial">Now I understand the difference between dialog and transaction (at least in terms of how they end).&nbsp; But it seems like the only relationship between the two is that – transaction creates (as in INVITE) or changes (as in re-INVITE and REFER) a dialog.&nbsp; Am I right?</SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=1><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
<P class=MsoNormal><FONT face=Arial color=navy size=1><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial">Also, according to my understanding, the transaction that you are talking about (created by INVITE and ended by a final response) is different than the “Client/Server Transactions” mentioned in Section 17 of RFC 3261 (where I see them as more like logical components inside SIP elements).&nbsp; Is this correct?</SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=1><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
<P class=MsoNormal><FONT face=Arial color=navy size=1><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial">Furthermore, do mid-session requests (re-INVITE, REFER, etc.) create new transactions (i.e. use a new branch parameter)?</SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=1><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
<P class=MsoNormal><FONT face=Arial color=navy size=1><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial">In addition, I do not see the clear purpose of the concept of transaction (vs. the concept of dialog). &nbsp;To me, dialog is a signaling relationship between 2 or more SIP UAs.&nbsp; It already includes the concept of a transaction, doesn’t it?&nbsp; In terms of describing SIP signaling or features in general, I do not see the role of transactions in the big picture.&nbsp; Am I missing something?</SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=1><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
<P class=MsoNormal><FONT face=Arial color=navy size=1><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial">Thanks again.</SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=1><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
<P class=MsoNormal><FONT face=Arial color=navy size=1><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial">Regards,</SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=1><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
<P class=MsoNormal><FONT face=Arial color=navy size=1><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial">Patrick Lam</SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=1><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
<P class=MsoNormal><FONT face=Arial color=navy size=1><SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: navy; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
<DIV style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0cm; BORDER-BOTTOM: medium none">
<P class=MsoNormal><FONT face=Tahoma size=2><SPAN lang=EN-US style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">-----Original Message-----<BR><B><SPAN style="FONT-WEIGHT: bold">From:</SPAN></B> Shazia Irfan [mailto:shaziairfan80@yahoo.com] <BR><B><SPAN style="FONT-WEIGHT: bold">Sent:</SPAN></B> Thursday, April 10, 2003 1:20 PM<BR><B><SPAN style="FONT-WEIGHT: bold">To:</SPAN></B> Patrick Lam; sip@ietf.org<BR><B><SPAN style="FONT-WEIGHT: bold">Subject:</SPAN></B> Re: [Sip] Transactions and Dialogs... Don't understand their relationship!</SPAN></FONT></P>
<P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN lang=EN-US style="FONT-SIZE: 12pt"></SPAN></FONT>&nbsp;</P>
<P><FONT face="Times New Roman" size=3><SPAN lang=EN-US style="FONT-SIZE: 12pt">SIP Transactions are actually composed of request corresponding&nbsp;responses. SIP send request to i</SPAN></FONT><SPAN lang=EN-US>nitiate </SPAN><SPAN lang=EN-US>particular action, i.e. INVITE request send to establish call, REGISTER request is send for registartion purposes. </SPAN></P>
<P><FONT face="Times New Roman" size=3><SPAN lang=EN-US style="FONT-SIZE: 12pt">On other hand Dialog&nbsp;represents a peer-to-peer SIP relationship between two user agents that persists for some time. The dialog facilitates sequencing of<BR>messages between the user agents and proper routing of requests<BR>between both of them.( as mention in RFC 3261). </SPAN></FONT></P>
<P><FONT face="Times New Roman" size=3><SPAN lang=EN-US style="FONT-SIZE: 12pt">The concept can be explained as, when UA when to establish call with other UA, it send INVITE request, when it receives&nbsp;response (provisional or final), a dialog establish. Transaction ends after receiving final response e.g. 200 OK, but dialog do not end. All mid session requests (re-INVITES, REFER&nbsp;etc.) are composed with the help of dialog </SPAN></FONT></P>
<P><FONT face="Times New Roman" size=3><SPAN lang=EN-US style="FONT-SIZE: 12pt">Now UA wants to terminate call, it send BYE request to other UA and this BYE request and its response terminate dialogs at both end. </SPAN></FONT></P>
<P><FONT face="Times New Roman" size=3><SPAN lang=EN-US style="FONT-SIZE: 12pt">Regards, </SPAN></FONT></P>
<P><FONT face="Times New Roman" size=3><SPAN lang=EN-US style="FONT-SIZE: 12pt">Shazia </SPAN></FONT></P>
<P><FONT face="Times New Roman" size=3><SPAN lang=EN-US style="FONT-SIZE: 12pt">&nbsp;<B><I><SPAN style="FONT-WEIGHT: bold; FONT-STYLE: italic">Patrick Lam &lt;patrickl@astri.org&gt;</SPAN></I></B> wrote: </SPAN></FONT></P>
<BLOCKQUOTE style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: medium none; MARGIN-TOP: 5pt; PADDING-LEFT: 4pt; MARGIN-BOTTOM: 5pt; PADDING-BOTTOM: 0cm; MARGIN-LEFT: 3.75pt; BORDER-LEFT: #1010ff 1.5pt solid; PADDING-TOP: 0cm; BORDER-BOTTOM: medium none">
<P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN lang=EN-US style="FONT-SIZE: 12pt">Dear all:<BR><BR>Is transaction related to dialog at all? Or should they be seen as related?<BR><BR>It seems to me that transactions are identified by branch parameter, and<BR>dialogs are identified by Call-ID (plus To/From tags). But can I say that<BR>an INVITE + ACK transactions create a dialog? And does a dialog end with<BR>its associated transaction, and vice versa?<BR><BR>To me, I see that transactions are just logical components of SIP elements<BR>(like client transaction and server transaction). They just have to be<BR>implemented for the SIP elements to work. However, according to RFC 3261,<BR>p.24 and 25:<BR><BR>SIP Transaction: A SIP transaction occurs between a client and a server and<BR>comprises all messages from the first request sent from the client<BR>to the server up to a final (non-1xx) response sent from the server to the<BR>client. If the request is INVITE and !
 the final response is a<BR>non-2xx, the transaction also includes an ACK to the response. The ACK for<BR>a 2xx response to an INVITE request is a separate transaction.<BR><BR>It sounds like a transaction is indeed a "physical" relationship between<BR>requests and responses. Therefore, it sounds quite similar to the concept<BR>of dialogs.<BR><BR>What I do not understand is that if we already have a concept of dialog, who<BR>do we still need the concept of transaction?<BR><BR>I guess I am seriously misunderstanding the concepts here. Can someone<BR>please explain to me the relationship and difference between transactions<BR>and dialogs?<BR><BR>Thanks very much in advance.<BR><BR>Patrick Lam<BR><BR><BR>&gt; ATTACHMENT part 2 application/ms-tnef name=winmail.dat </SPAN></FONT></P></BLOCKQUOTE>
<P><FONT face="Times New Roman" size=3><SPAN lang=EN-US style="FONT-SIZE: 12pt"></SPAN></FONT>&nbsp;</P>
<DIV class=MsoNormal style="TEXT-ALIGN: center" align=center><FONT face="Times New Roman" size=3><SPAN lang=EN-US style="FONT-SIZE: 12pt">
<HR align=center width="100%" SIZE=1>
</SPAN></FONT></DIV>
<P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN lang=EN-US style="FONT-SIZE: 12pt">Do you Yahoo!?<BR><A href="http://us.rd.yahoo.com/finance/mailsig/*http:/tax.yahoo.com">Yahoo! Tax Center</A> - File online, calculators, forms, and more</SPAN></FONT></P></DIV></DIV></BLOCKQUOTE><p><br><hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/finance/mailsig/*http://tax.yahoo.com">Yahoo! Tax Center</a> - File online, calculators, forms, and more
--0-986516671-1049970669=:54022--
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Thu Apr 10 08:59:58 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18589
	for <sip-archive@odin.ietf.org>; Thu, 10 Apr 2003 08:59:57 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3AD5dg07959
	for sip-archive@odin.ietf.org; Thu, 10 Apr 2003 09:05:39 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AD51807929;
	Thu, 10 Apr 2003 09:05:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ACwQ807629
	for <sip@optimus.ietf.org>; Thu, 10 Apr 2003 08:58:26 -0400
Received: from shardagate.mahindrabt.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18469
	for <sip@ietf.org>; Thu, 10 Apr 2003 08:52:11 -0400 (EDT)
Received: from thisdomain (mailscan.sharda.mahindrabt.com [10.5.0.97])
	by shardagate.mahindrabt.com (8.12.8/8.12.8) with ESMTP id h3ACsZ4L019232
	for <sip@ietf.org>; Thu, 10 Apr 2003 18:24:41 +0530
Received: from intranet.sharda.mahindrabt.com by mahindrabt.com ; Thu, 10 Apr 2003 18:10:55 +0530
Date: Thu, 10 Apr 2003 18:10:55 +0530
X-Originating-IP: 10.5.0.15
X-Auth-User: ashishn@mahindrabt.com
Received: from dscp00212 ([10.5.3.103])
	by intranet.sharda.mahindrabt.com (8.9.3/8.9.3) with SMTP id SAA15937
	for <sip@ietf.org>; Thu, 10 Apr 2003 18:23:22 +0530
From: "Ashish Naik" <ashishn@mahindrabt.com>
To: "Sip@Ietf. Org" <sip@ietf.org>
Date: Thu, 10 Apr 2003 18:26:56 +0530
Message-ID: <NFBBIJAAOFNEMIHBIFPIIEIADHAA.ashishn@mahindrabt.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0031_01C2FF8E.C49DA5A0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Subject: [Sip] presence (PAM and SIMPLE)
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0031_01C2FF8E.C49DA5A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

is it correc to say that PAM is used on wireless networks to get,set
presence information and SIMPLE is used in fixed network ?

Ashish

*********************************************************
Disclaimer

This message (including any attachments) contains 
confidential information intended for a specific 
individual and purpose, and is protected by law. 
If you are not the intended recipient, you should 
delete this message and are hereby notified that 
any disclosure, copying, or distribution of this
message, or the taking of any action based on it, 
is strictly prohibited.

*********************************************************
Visit us at http://www.mahindrabt.com


------=_NextPart_000_0031_01C2FF8E.C49DA5A0
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.2800.1106" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D390435412-10042003><FONT face=3DArial size=3D2>is =
it&nbsp;correc to=20
say that PAM is used on wireless networks to get,set presence =
information and=20
SIMPLE is used in fixed network ?</FONT></SPAN></DIV>
<DIV><SPAN class=3D390435412-10042003><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D390435412-10042003></SPAN><FONT face=3DArial><FONT =
size=3D2>A<SPAN=20
class=3D390435412-10042003>shish</SPAN></FONT></FONT></DIV></BODY></HTML>

<html>
<br>
*********************************************************<br>
Disclaimer<br>
<br>
This message (including any attachments) contains <br>
confidential information intended for a specific <br>
individual and purpose, and is protected by law. <br>
If you are not the intended recipient, you should <br>
delete this message and are hereby notified that <br>
any disclosure, copying, or distribution of this<br>
message, or the taking of any action based on it, <br>
is strictly prohibited.<br>
<br>
*********************************************************<br>
Visit us at http://www.mahindrabt.com<br>
<br>
</html>

------=_NextPart_000_0031_01C2FF8E.C49DA5A0--


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



From mailnull@www1.ietf.org  Thu Apr 10 09:19:31 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19268
	for <sip-archive@odin.ietf.org>; Thu, 10 Apr 2003 09:19:30 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3ADPBT09771
	for sip-archive@odin.ietf.org; Thu, 10 Apr 2003 09:25:11 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ADOn809704;
	Thu, 10 Apr 2003 09:24:49 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ADIu809388
	for <sip@optimus.ietf.org>; Thu, 10 Apr 2003 09:18:56 -0400
Received: from il-tlv-smtpout2.icomverse.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19066;
	Thu, 10 Apr 2003 09:12:43 -0400 (EDT)
Received: from il-tlv-mbdg1.comverse.com (localhost.localdomain [127.0.0.1])
	by il-tlv-smtpout2.icomverse.com (8.11.6/8.11.6) with ESMTP id h3ADEuQ26089;
	Thu, 10 Apr 2003 16:14:57 +0300
Received: by il-tlv-mbdg1.comverse.com with Internet Mail Service (5.5.2655.55)
	id <G6A8RFGY>; Thu, 10 Apr 2003 16:15:04 +0300
Message-ID: <32B823C1CD4FD5119C0D0002A560F78E091FF412@ismail3.comverse.com>
From: Fuxbruner Amihay <Amihay_Fuxbruner@icomverse.com>
To: "'sdonovan@dynamicsoft.com'" <sdonovan@dynamicsoft.com>,
        "'jdrosen@dynamicsoft.com'" <jdrosen@dynamicsoft.com>,
        sip-implementors@cs.columbia.edu, sip@ietf.org, sipping@ietf.org
Cc: Isaac Dudy <Dudy_Isaac@icomverse.com>
Date: Thu, 10 Apr 2003 16:15:03 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2FF63.32313108"
Subject: [Sip] Session timer - Supported header 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>

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_01C2FF63.32313108
Content-Type: text/plain;
	charset="windows-1255"

Hello all,

The session timer draft (draft-ietf-sip-session-timer-10.txt) section 7.1
says:

"  A UAC which supports the session timer extension defined here MUST
   include a Supported header field in each request (except ACK),
   listing the option tag "timer" [1]. It MUST do so even if the UAC is
   not requesting usage of the session timer for this session."

Is this requirement reasonable??
Isn't it enough to send Supported header in the initial request??

Thanks for your answer in advance.

Amihay Fuxbruner
Comverse

------_=_NextPart_001_01C2FF63.32313108
Content-Type: text/html;
	charset="windows-1255"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1255">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2655.35">
<TITLE>Session timer - Supported header question</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Hello all,</FONT>
</P>

<P><FONT SIZE=2>The session timer draft (draft-ietf-sip-session-timer-10.txt) section 7.1 says:</FONT>
</P>

<P><FONT SIZE=2>&quot;&nbsp; A UAC which supports the session timer extension defined here MUST</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; include a Supported header field in each request (except ACK),</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; listing the option tag &quot;timer&quot; [1]. It MUST do so even if the UAC is</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; not requesting usage of the session timer for this session.&quot;</FONT>
</P>

<P><FONT SIZE=2>Is this requirement reasonable??</FONT>
<BR><FONT SIZE=2>Isn't it enough to send Supported header in the initial request??</FONT>
</P>

<P><FONT SIZE=2>Thanks for your answer in advance.</FONT>
</P>

<P><FONT SIZE=2>Amihay Fuxbruner</FONT>
<BR><FONT SIZE=2>Comverse</FONT>
</P>

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



From mailnull@www1.ietf.org  Thu Apr 10 09:33:04 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19712
	for <sip-archive@odin.ietf.org>; Thu, 10 Apr 2003 09:33:04 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3ADcju11221
	for sip-archive@odin.ietf.org; Thu, 10 Apr 2003 09:38:45 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ADcD811186;
	Thu, 10 Apr 2003 09:38:13 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ADXA810185
	for <sip@optimus.ietf.org>; Thu, 10 Apr 2003 09:33:10 -0400
Received: from ihemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19485
	for <sip@ietf.org>; Thu, 10 Apr 2003 09:26:58 -0400 (EDT)
Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57])
	by ihemail1.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3ADTUP26967
	for <sip@ietf.org>; Thu, 10 Apr 2003 09:29:31 -0400 (EDT)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19)
	id <XNTD2TLV>; Thu, 10 Apr 2003 14:29:26 +0100
Message-ID: <475FF955A05DD411980D00508B6D5FB00439ECA7@en0033exch001u.uk.lucent.com>
From: "Drage, Keith (Keith)" <drage@lucent.com>
To: "'Ashish Naik'" <ashishn@mahindrabt.com>, "Sip@Ietf. Org" <sip@ietf.org>
Subject: RE: [Sip] Presence and Availibility
Date: Thu, 10 Apr 2003 14:29:24 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2FF65.3382880C"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-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_01C2FF65.3382880C
Content-Type: text/plain;
	charset="iso-8859-1"

3GPP currently addresses a specific set of SIP specifications in release 5 (essentially those that currently exist at as RFCs at this moment in time). The interaction of OSA and SIP is specified in 29.998-04
 
Incorporation of SIMPLE work into the 3GPP support of SIP is part of Release 6, and is work in progress (as it still is in IETF as very few of the specifications have yet reached RFC status). Part of that release 6 work is for 3GPP WG CN5 to look at the interaction of PAM and Presence as provided by SIP. To the best of my knowledge this work is still to be done.
 
Keith
 

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

-----Original Message-----
From: Ashish Naik [mailto:ashishn@mahindrabt.com]
Sent: 10 April 2003 09:50
To: Sip@Ietf. Org
Subject: [Sip] Presence and Availibility


SIP addresses Presence and Availibility in SIMPLE and OSA/Parlay in PAM specs. How thes two are interrelated as both SIP and OSA are part of 3GPP standard.
 
Regards,
Ashish Naik
-------------------
CoE Mobile Computing
Phone: 4018100 Ext 3070 
 

*********************************************************
Disclaimer

This message (including any attachments) contains 
confidential information intended for a specific 
individual and purpose, and is protected by law. 
If you are not the intended recipient, you should 
delete this message and are hereby notified that 
any disclosure, copying, or distribution of this
message, or the taking of any action based on it, 
is strictly prohibited.

*********************************************************
Visit us at http://www.mahindrabt.com




------_=_NextPart_001_01C2FF65.3382880C
Content-Type: text/html;
	charset="iso-8859-1"

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


<META content="MSHTML 5.50.4919.2200" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=679351513-10042003><FONT face=Arial color=#0000ff size=2>3GPP 
currently addresses a specific set of SIP specifications in release 5 
(essentially those that currently exist at as RFCs at this moment in time). The 
interaction of&nbsp;OSA and SIP is specified 
in&nbsp;29.998-04</FONT></SPAN></DIV>
<DIV><SPAN class=679351513-10042003></SPAN>&nbsp;</DIV>
<DIV><SPAN class=679351513-10042003><FONT face=Arial color=#0000ff 
size=2>Incorporation of SIMPLE work into the 3GPP support of SIP is part of 
Release 6, and is work in progress (as it still is in IETF as very few of the 
specifications have yet reached RFC status). Part of that release 6 work 
is&nbsp;for 3GPP WG CN5 to look at the interaction of PAM and Presence as 
provided by SIP. To the best of my knowledge this work is still to be 
done.</FONT></SPAN></DIV>
<DIV><SPAN class=679351513-10042003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=679351513-10042003><FONT face=Arial color=#0000ff 
size=2>Keith</FONT></SPAN></DIV>
<DIV>&nbsp;</DIV>
<P><FONT size=2>Keith Drage<BR>Lucent Technologies<BR>Tel: +44 1793 
776249<BR>Email: drage@lucent.com </FONT></P>
<BLOCKQUOTE 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Ashish Naik 
  [mailto:ashishn@mahindrabt.com]<BR><B>Sent:</B> 10 April 2003 
  09:50<BR><B>To:</B> Sip@Ietf. Org<BR><B>Subject:</B> [Sip] Presence and 
  Availibility<BR><BR></FONT></DIV>
  <DIV><FONT face=Arial size=2><SPAN class=421414808-10042003>SIP addresses 
  Presence and Availibility in SIMPLE and OSA/Parlay in PAM specs. How thes two 
  are interrelated as both SIP and OSA are part of 3GPP 
  standard.</SPAN></FONT></DIV>
  <DIV><FONT face=Arial size=2><SPAN 
  class=421414808-10042003></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>Regards,<BR>Ashish 
  Naik<BR>-------------------<BR>CoE Mobile Computing<BR>Phone: 4018100 Ext 3070 
  </FONT></DIV>
  <DIV>&nbsp;</DIV><BR>*********************************************************<BR>Disclaimer<BR><BR>This 
  message (including any attachments) contains <BR>confidential information 
  intended for a specific <BR>individual and purpose, and is protected by law. 
  <BR>If you are not the intended recipient, you should <BR>delete this message 
  and are hereby notified that <BR>any disclosure, copying, or distribution of 
  this<BR>message, or the taking of any action based on it, <BR>is strictly 
  prohibited.<BR><BR>*********************************************************<BR>Visit 
  us at http://www.mahindrabt.com<BR><BR></BLOCKQUOTE></BODY></HTML>

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



From mailnull@www1.ietf.org  Thu Apr 10 09:49:01 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20065
	for <sip-archive@odin.ietf.org>; Thu, 10 Apr 2003 09:49:01 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3ADsh512104
	for sip-archive@odin.ietf.org; Thu, 10 Apr 2003 09:54:43 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ADsJ812075;
	Thu, 10 Apr 2003 09:54:19 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ADnI811893
	for <sip@optimus.ietf.org>; Thu, 10 Apr 2003 09:49:18 -0400
Received: from smtpgw6.sprintspectrum.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19907
	for <sip@ietf.org>; Thu, 10 Apr 2003 09:43:04 -0400 (EDT)
Received: from pkcex004.sprintspectrum.com (pkcex004.sprintspectrum.com [208.10.75.139])
	by smtpgw6.sprintspectrum.com (8.12.9/8.12.8) with ESMTP id h3ADjbU2020347;
	Thu, 10 Apr 2003 08:45:38 -0500 (CDT)
Received: by pkcex004.sprintspectrum.com with Internet Mail Service (5.5.2654.89)
	id <2PAFVF3Q>; Thu, 10 Apr 2003 08:45:37 -0500
Message-ID: <28B9108644E492469B911D587AABC97C01695B61@PKDWB01C.ad.sprint.com>
From: "Santharam, Arun [CC]" <asanth01@sprintspectrum.com>
To: Ashish Naik <ashishn@mahindrabt.com>, "Sip@Ietf. Org" <sip@ietf.org>
Subject: RE: [Sip] presence (PAM and SIMPLE)
Date: Thu, 10 Apr 2003 08:45:33 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.89)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2FF67.756DA944"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-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_01C2FF67.756DA944
Content-Type: text/plain

SIMPLE is a SIP based Presence and Instant Messaging Protocol. PAM is a set
of APIs to develop Presence based Applications. Both are complimentary and
can work in wire line and wireless networks.

 

-----Original Message-----
From: Ashish Naik [mailto:ashishn@mahindrabt.com] 
Sent: Thursday, April 10, 2003 7:57 AM
To: Sip@Ietf. Org
Subject: [Sip] presence (PAM and SIMPLE)

 

is it correc to say that PAM is used on wireless networks to get,set
presence information and SIMPLE is used in fixed network ?

 

Ashish


*********************************************************
Disclaimer

This message (including any attachments) contains 
confidential information intended for a specific 
individual and purpose, and is protected by law. 
If you are not the intended recipient, you should 
delete this message and are hereby notified that 
any disclosure, copying, or distribution of this
message, or the taking of any action based on it, 
is strictly prohibited.

*********************************************************
Visit us at http://www.mahindrabt.com



------_=_NextPart_001_01C2FF67.756DA944
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)">

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* 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:#606420;
	text-decoration:underline;}
span.EmailStyle17
	{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="#606420">

<div class=Section1>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>SIMPLE is a SIP based Presence and Instant
Messaging Protocol. PAM is a set of APIs to develop Presence based Applications.
Both are complimentary and can work in wire line and wireless networks.</span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>

<p class=MsoNormal><font size=2 face=Tahoma><span style='font-size:10.0pt;
font-family:Tahoma'>-----Original Message-----<br>
<b><span style='font-weight:bold'>From:</span></b> Ashish Naik
[mailto:ashishn@mahindrabt.com] <br>
<b><span style='font-weight:bold'>Sent:</span></b> Thursday, April 10, 2003
7:57 AM<br>
<b><span style='font-weight:bold'>To:</span></b> Sip@Ietf. Org<br>
<b><span style='font-weight:bold'>Subject:</span></b> [Sip] presence (PAM and
SIMPLE)</span></font></p>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>&nbsp;</span></font></p>

<div>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>is it&nbsp;correc to say that PAM is used on wireless
networks to get,set presence information and SIMPLE is used in fixed network ?</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 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Ashish</span></font></p>

</div>

</div>

</div>

</body>

</html>
<html>
<br>
*********************************************************<br>
Disclaimer<br>
<br>
This message (including any attachments) contains <br>
confidential information intended for a specific <br>
individual and purpose, and is protected by law. <br>
If you are not the intended recipient, you should <br>
delete this message and are hereby notified that <br>
any disclosure, copying, or distribution of this<br>
message, or the taking of any action based on it, <br>
is strictly prohibited.<br>
<br>
*********************************************************<br>
Visit us at http://www.mahindrabt.com<br>
<br>
------_=_NextPart_001_01C2FF67.756DA944--
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Thu Apr 10 10:03:49 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20532
	for <sip-archive@odin.ietf.org>; Thu, 10 Apr 2003 10:03:49 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3AE9UP13612
	for sip-archive@odin.ietf.org; Thu, 10 Apr 2003 10:09:30 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AE90813597;
	Thu, 10 Apr 2003 10:09:00 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AE3Z812566
	for <sip@optimus.ietf.org>; Thu, 10 Apr 2003 10:03:35 -0400
Received: from ihemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20293
	for <sip@ietf.org>; Thu, 10 Apr 2003 09:57:22 -0400 (EDT)
Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57])
	by ihemail1.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3ADxtP19683
	for <sip@ietf.org>; Thu, 10 Apr 2003 09:59:55 -0400 (EDT)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19)
	id <XNTD2VD8>; Thu, 10 Apr 2003 14:59:54 +0100
Message-ID: <475FF955A05DD411980D00508B6D5FB00439ECA9@en0033exch001u.uk.lucent.com>
From: "Drage, Keith (Keith)" <drage@lucent.com>
To: "'Ashish Naik'" <ashishn@mahindrabt.com>, "Sip@Ietf. Org" <sip@ietf.org>
Subject: RE: [Sip] presence (PAM and SIMPLE)
Date: Thu, 10 Apr 2003 14:59:52 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2FF69.2E24DA32"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-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_01C2FF69.2E24DA32
Content-Type: text/plain;
	charset="iso-8859-1"

No. 
 
I suggest you look at 3GPP TS 23.141 for a view on how wireless networks propose to gather their presence information.
 
ftp://ftp.3gpp.org/Specs/latest/Rel-6/23_series/23141-620.zip <ftp://ftp.3gpp.org/Specs/latest/Rel-6/23_series/23141-620.zip> 
 
Keith
 

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

-----Original Message-----
From: Ashish Naik [mailto:ashishn@mahindrabt.com]
Sent: 10 April 2003 13:57
To: Sip@Ietf. Org
Subject: [Sip] presence (PAM and SIMPLE)


is it correc to say that PAM is used on wireless networks to get,set presence information and SIMPLE is used in fixed network ?
 
Ashish

*********************************************************
Disclaimer

This message (including any attachments) contains 
confidential information intended for a specific 
individual and purpose, and is protected by law. 
If you are not the intended recipient, you should 
delete this message and are hereby notified that 
any disclosure, copying, or distribution of this
message, or the taking of any action based on it, 
is strictly prohibited.

*********************************************************
Visit us at http://www.mahindrabt.com




------_=_NextPart_001_01C2FF69.2E24DA32
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.4919.2200" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D367525713-10042003><FONT face=3DArial =
color=3D#0000ff size=3D2>No.=20
</FONT></SPAN></DIV>
<DIV><SPAN class=3D367525713-10042003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D367525713-10042003><FONT face=3DArial =
color=3D#0000ff size=3D2>I=20
suggest you look at 3GPP TS 23.141 for a view on how wireless networks =
propose=20
to gather their presence information.</FONT></SPAN></DIV>
<DIV><SPAN class=3D367525713-10042003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D367525713-10042003><FONT face=3DArial =
color=3D#0000ff size=3D2><A=20
href=3D"ftp://ftp.3gpp.org/Specs/latest/Rel-6/23_series/23141-620.zip">f=
tp://ftp.3gpp.org/Specs/latest/Rel-6/23_series/23141-620.zip</A></FONT><=
/SPAN></DIV>
<DIV><SPAN class=3D367525713-10042003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D367525713-10042003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Keith</FONT></SPAN></DIV>
<DIV>&nbsp;</DIV>
<P><FONT size=3D2>Keith Drage<BR>Lucent Technologies<BR>Tel: +44 1793=20
776249<BR>Email: drage@lucent.com </FONT></P>
<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> Ashish Naik=20
  [mailto:ashishn@mahindrabt.com]<BR><B>Sent:</B> 10 April 2003=20
  13:57<BR><B>To:</B> Sip@Ietf. Org<BR><B>Subject:</B> [Sip] presence =
(PAM and=20
  SIMPLE)<BR><BR></FONT></DIV>
  <DIV><SPAN class=3D390435412-10042003><FONT face=3DArial size=3D2>is =
it&nbsp;correc=20
  to say that PAM is used on wireless networks to get,set presence =
information=20
  and SIMPLE is used in fixed network ?</FONT></SPAN></DIV>
  <DIV><SPAN class=3D390435412-10042003><FONT face=3DArial=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D390435412-10042003></SPAN><FONT face=3DArial><FONT =

  size=3D2>A<SPAN=20
  =
class=3D390435412-10042003>shish</SPAN></FONT></FONT></DIV><BR>*********=
************************************************<BR>Disclaimer<BR><BR>Th=
is=20
  message (including any attachments) contains <BR>confidential =
information=20
  intended for a specific <BR>individual and purpose, and is protected =
by law.=20
  <BR>If you are not the intended recipient, you should <BR>delete this =
message=20
  and are hereby notified that <BR>any disclosure, copying, or =
distribution of=20
  this<BR>message, or the taking of any action based on it, <BR>is =
strictly=20
  =
prohibited.<BR><BR>*****************************************************=
****<BR>Visit=20
  us at http://www.mahindrabt.com<BR><BR></BLOCKQUOTE></BODY></HTML>

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



From mailnull@www1.ietf.org  Thu Apr 10 12:30:33 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25838
	for <sip-archive@odin.ietf.org>; Thu, 10 Apr 2003 12:30:33 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3AGaIJ24415
	for sip-archive@odin.ietf.org; Thu, 10 Apr 2003 12:36:18 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AGYW824267;
	Thu, 10 Apr 2003 12:34:32 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AGQk823963
	for <sip@optimus.ietf.org>; Thu, 10 Apr 2003 12:26:46 -0400
Received: from auemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25547
	for <sip@ietf.org>; Thu, 10 Apr 2003 12:20:29 -0400 (EDT)
Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57])
	by auemail1.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3AGN2B16420
	for <sip@ietf.org>; Thu, 10 Apr 2003 12:23:03 -0400 (EDT)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19)
	id <XNTD269F>; Thu, 10 Apr 2003 17:23:02 +0100
Message-ID: <475FF955A05DD411980D00508B6D5FB00439ECAC@en0033exch001u.uk.lucent.com>
From: "Drage, Keith (Keith)" <drage@lucent.com>
To: "'Gonzalo Camarillo'" <Gonzalo.Camarillo@lmf.ericsson.se>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: "Drage, Keith (Keith)" <drage@lucent.com>,
        "'sip@ietf.org'"
	 <sip@ietf.org>,
        "'jari.arkko@ericsson.com'" <jari.arkko@ericsson.com>,
        "'vesa.torvinen@ericsson.fi'" <vesa.torvinen@lmf.ericsson.se>,
        "'Gonzalo.Camarillo@ericsson.com'" <Gonzalo.Camarillo@ericsson.com>,
        "'aki.niemi@nokia.com'" <aki.niemi@nokia.com>,
        "'tao.haukka@nokia.com'"
	 <tao.haukka@nokia.com>
Subject: RE: [Sip] Re: Some comments on RFC 3329 (Security Mechanism Agree
	ment for the S	ession Initiation Protocol)
Date: Thu, 10 Apr 2003 17:22:59 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

For the Require header, I was arguing for nothing more than a general case of that used in sec-agree, i.e. that the proxy must contain the application reflected by the option-tag in the Require header before that specific option-tag can be removed. I would not envisage any removal of any other option-tag.

It may also be possible to argue that for the removal to occur, it should be tested by the presence of the appropriate (i.e. the same) option-tag in a Proxy-Require header.

So I support Gonzalo in saying that this is necessary for sec-agree, but I think it would be useful to clearly state what is allowed in the respect in RFC 3261.

Keith

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

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
> Sent: 03 April 2003 11:02
> To: Jonathan Rosenberg
> Cc: Drage, Keith (Keith); 'sip@ietf.org'; 'jari.arkko@ericsson.com';
> 'vesa.torvinen@ericsson.fi'; 'Gonzalo.Camarillo@ericsson.com';
> 'aki.niemi@nokia.com'; 'tao.haukka@nokia.com'
> Subject: Re: [Sip] Re: Some comments on RFC 3329 (Security Mechanism
> Agreement for the S ession Initiation Protocol)
> 
> 
> Jonathan,
> 
> > Interrestingly, RFC3329 is not the first RFC to have a 
> proxy remove a 
> > proxy-require header. RFC 3323 (Privacy extensions) does 
> the same thing 
> > for much the same reason. As such, I agree that this is 
> probably a bug 
> > in RFC3261, and that evil table 2/3 should be modified to amr, with 
> > explanatory text explaining under what conditions. I don't 
> think proxies 
> > can modify Require, however.
> 
> In general, proxies cannot modify Require. However, sec-agree 
> is a very 
> special mechanism that is inteded to be used *only* with the 
> next hop. 
> That's why the UAC adds both Proxy-Require and Require to the 
> request. 
> To cover the case where the next (first) hop is already the 
> UAS (which 
> would ignore the proxy-require header).
> 
> In any event, sec-agree lets the proxy remove the Require tag because 
> the same tag (sec-agree) appears in the proxy-require, and 
> this ensures 
> that the proxy understands sec-agree and knows what it is 
> doing when is 
> removing the Require tag.
> 
> Of course, Require header removal by proxies in any other 
> scenario would 
> be very bad.
> 
> Gonzalo
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Thu Apr 10 15:52:48 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04415
	for <sip-archive@odin.ietf.org>; Thu, 10 Apr 2003 15:52:48 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3AJwb008164
	for sip-archive@odin.ietf.org; Thu, 10 Apr 2003 15:58:37 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AJw6808141;
	Thu, 10 Apr 2003 15:58:06 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AJpI807886
	for <sip@optimus.ietf.org>; Thu, 10 Apr 2003 15:51: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 PAA04172
	for <sip@ietf.org>; Thu, 10 Apr 2003 15:44:59 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 193hie-0003uA-00
	for sip@ietf.org; Thu, 10 Apr 2003 15:28:20 -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 193hid-0003tp-00
	for sip@ietf.org; Thu, 10 Apr 2003 15:28:19 -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 h3AJjuOg017544
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO);
	Thu, 10 Apr 2003 14:46:53 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: <sip@ietf.org>
Cc: "Rohan Mahy" <rohan@cisco.com>,
        "Jon Peterson \(jon.peterson@NeuStar.com\)" <jon.peterson@neustar.biz>
Date: Thu, 10 Apr 2003 14:45:18 -0500
Message-ID: <000901c2ff99$d8d8c800$ee036e3f@txdwillis>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3AJpI807887
Subject: [Sip] Draft minutes for SIP WG meeting at IETF 56
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit

Draft minutes are posted at:

http://www.softarmor.com/sipwg/meets/ietf56/notes/minutes.html


Please review and send corrections. Thanks.

You might notice that the datail is a little light. This could be because I
seem not to have received a copy of the notes recorded by the official
designated secretary. Oh well, there's less to type this way. So if there
are any conclusions that need to be recorded that I failed to capture in my
notes, please provide details . . .


Text follows:

The SIP Working Group met at IETF 56 on Monday, March 17, 1300-1500,  in
room Continental 6.

The posted agenda:

1300 Agenda Bash
1305 Status -- Chairs
1315 Non-Invite Transaction Issues, Robert Sparks
    draft-sparks-sip-noninvite-00.txt
1330 Referred-By Changes and Open Issues, Robert Sparks
     draft-ietf-sip-referredby-01.txt
1340 Resource Priority, Henning Schulzrinne
     draft-polk-sip-resource-02.txt
1355 Caller Preferences, Jonathan Rosenberg
     draft-ietf-sip-callerprefs-08.txt
1410 Congestion Safety, Dean Willis, Hisham Khartabil
     draft-ietf-sip-congestsafe-01.txt
      draft-khartabil-sip-congestionsafe-ci-02.txt
1430 Authenticated ID Bodies, Jon Peterson
     draft-ietf-sip-authid-body-01.txt
1445 SIPit report on S/MIME and TLS, Rohan Mahy
1455 General Discussion
1500 Break

Scribe: Ramu (notes not receivedby chairs)
Chart Room Coordinator: Not recorded

Topic: Non-invite transactions, Robert Sparks.

The slides presented are included in the proceedings.

Poll == who as read and understands the draft, app. 20%. Discusssion:
Principle problem is the race condition of 64*T1 built into the protocol.
Given non-zero latency, the UAS side has an offset on this time, so the
client may time out before the server completes. Now we just try and
"complete as soon as possible" giving response codes like 408 that make no
sense -- by the time it gets back to the UAC, the UAC is assured of having
timed out, creating a 408 storm. Other problems exist with intermediary
timeouts and with forking convergence.

Two solutions offered: A and B. Rohan argues against proposal B, preferring
the subscribe/notify style of seperate transactions. Point: What if values
of T1 are different? Discussion: If UAS and UAC have different values of T1,
it's all broken anyhow. Extended discussion follows. Two problems: the
infrequent 1 in 10,000 events, and the problem that the 200 has to be
emitted soon enough to have a high probability to make it back to the UAC
before the 408s. Most troubling is when the UAS thinks the situation is
200ok, but the UAC has a different view (which can happen with non-invite
forking). Point that we should lift the constraint on interoperability with
existing proxies. Suggestion we adhoc during this meeting for consensus --
group to email Robert for gathering. Note:  a detailed adhoc on this topic
was held later and the minutes seperately included in the proceeedings.


Topic: Referred-by, Robert Sparks

The slides presented are included in the proceedings.

Complaint: nobody is giving feedback. Are people mostly happy and just
waiting on some of the blocking work to complete? A chairs asks for
volunteers to provide feedback: Brian Rosen, Mary Barnes, Alan Johnston,
Pekka Pessi all volunteer.

Issue: Use of Call-ID seems to be required in auth-ID-body. Is it a leak?
Should we put garbage in, change the AID body format, or what? Jon Peterson
reports that the newest AIB draft relieves this requirement.

Issue: Referred identity binding between REFER and INVITE. Can a referee
assert a different identity on the generated INVITE than was referenced in
the REFER? Can humans make the distinction? No resolution of this issue in
this meeting, but it seems to relate to the URI Leasing work ongoing in
SIPPING.


Topic: Resource-Priority, Henning Schulzrinne

The slides presented ARE NOT currently included in the proceedings but have
been requested and may be received in time.

Goal: Higher priority of emergency call completion during service disruption
of civil emergency, especially in interworking with PSTN. Requirements are
establised in RFC3487.  List discussion reviewd, best option a new header.
Discussion about whether it is "good" to have proxies understand this.
Consensus: Work on this problem, starting from this draft as a baseline, but
address additional opinions and requirements as raised in the WG process.


Topic: Caller Preferences, Jonathan Rosenberg

The slides presented are included in the proceedeings.

Issue: Needs a thorough review of the current draft, which seems pretty much
"done".

Volunteers to review -- Robert Sparks,  Mary Barnes, Pekka Pessi, Bob
Penfield,  Cullen Jennings. The plan is to review, feed back, revise, go to
2 week WGLC.


Topic: Congestion Safety, Dean Willis and Hisham Khartabil

Presentation by Dean Willis. Slides presented included in the proceedings.

General poll indicates that after reading the draft, nobody understands how
it works. People seem to have the vague feeling that the topic is important
but are not cognizant of the implications. Suggestion made that "congestion
safe" is a misnomer, as nothing is "safe".  No consensus reported.

Presentation by Hisham Khartabil. Slides presented included in proceedings.

One point made from audience is that implementors do not see immediate
value. Proposed by one speaker that we should consider response-CI as a
possible alternate mechanism in primary work. No consensus reported.

Topic: Auth-ID Issues, Jon Peterson

Slides presented are currently NOT in the proceedings but have been
requested.

The only new "SIP" function is the new 400-response code. Other functions
are non-normative.   No poll for consensus recorded.

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



From mailnull@www1.ietf.org  Thu Apr 10 20:21:57 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13063
	for <sip-archive@odin.ietf.org>; Thu, 10 Apr 2003 20:21:57 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3B0Rqg28254
	for sip-archive@odin.ietf.org; Thu, 10 Apr 2003 20:27:52 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3B0RQ828216;
	Thu, 10 Apr 2003 20:27:26 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3B0GQ827828
	for <sip@optimus.ietf.org>; Thu, 10 Apr 2003 20:16: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 UAA12726;
	Thu, 10 Apr 2003 20:10:00 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 193lr8-0005Ta-00; Thu, 10 Apr 2003 19:53:22 -0400
Received: from gamma.isi.edu ([128.9.144.145])
	by ietf-mx with esmtp (Exim 4.12)
	id 193lr7-0005TX-00; Thu, 10 Apr 2003 19:53:22 -0400
Received: from ISI.EDU (jet.isi.edu [128.9.160.87])
	by gamma.isi.edu (8.11.6p2/8.11.2) with ESMTP id h3B0CYk20739;
	Thu, 10 Apr 2003 17:12:34 -0700 (PDT)
Message-Id: <200304110012.h3B0CYk20739@gamma.isi.edu>
To: IETF-Announce: ;
Cc: rfc-editor@rfc-editor.org, sip@ietf.org, sipping@ietf.org
From: rfc-editor@rfc-editor.org
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 10 Apr 2003 17:12:28 -0700
Subject: [Sip] RFC 3515 on The Session Initiation Protocol (SIP) Refer Method
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>


--NextPart


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


        RFC 3515

        Title:      The Session Initiation Protocol (SIP) Refer Method
        Author(s):  R. Sparks
        Status:     Standards Track
        Date:       April 2003
        Mailbox:    rsparks@dynamicsoft.com
        Pages:      23
        Characters: 47788
        Updates/Obsoletes/SeeAlso:  None

        I-D Tag:    draft-ietf-sip-refer-07.txt

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


This document defines the REFER method.  This Session Initiation
Protocol (SIP) extension requests that the recipient REFER to a
resource provided in the request.  It provides a mechanism allowing
the party sending the REFER to be notified of the outcome of the
referenced request.  This can be used to enable many applications,
including call transfer.

In addition to the REFER method, this document defines the the refer
event package and the Refer-To request header.

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

RETRIEVE: rfc
DOC-ID: rfc3515

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

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

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



From mailnull@www1.ietf.org  Fri Apr 11 04:16:39 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03445
	for <sip-archive@odin.ietf.org>; Fri, 11 Apr 2003 04:16:39 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3B8Mgr05335
	for sip-archive@odin.ietf.org; Fri, 11 Apr 2003 04:22:42 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3B8MB805313;
	Fri, 11 Apr 2003 04:22:11 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ALbx817116
	for <sip@optimus.ietf.org>; Thu, 10 Apr 2003 17:37: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 RAA07598
	for <sip@ietf.org>; Thu, 10 Apr 2003 17:31:37 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 193jNr-0004bX-00
	for sip@ietf.org; Thu, 10 Apr 2003 17:14:59 -0400
Received: from web10406.mail.yahoo.com ([216.136.130.98])
	by ietf-mx with smtp (Exim 4.12)
	id 193jNq-0004bU-00
	for sip@ietf.org; Thu, 10 Apr 2003 17:14:58 -0400
Message-ID: <20030410213411.54529.qmail@web10406.mail.yahoo.com>
Received: from [200.52.4.2] by web10406.mail.yahoo.com via HTTP; Thu, 10 Apr 2003 14:34:11 PDT
Date: Thu, 10 Apr 2003 14:34:11 -0700 (PDT)
From: Hugo Lara <hugo_e_lara@yahoo.com>
To: sipietf <sip@ietf.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1092664951-1050010451=:53793"
Subject: [Sip] Sip Client Code
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

--0-1092664951-1050010451=:53793
Content-Type: text/plain; charset=us-ascii

Someone know where can I to find a Instant Messaging source code??  (SIP Client) which one allows to establish sessions of voice, text and data (sending files), and it can communicate with SIP server that it has been configured and running rigth now.Regards.Hugo Lara





---------------------------------
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
--0-1092664951-1050010451=:53793
Content-Type: text/html; charset=us-ascii

Someone know where can I to find a Instant Messaging source code??&nbsp; (SIP Client) 
<DIV style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; PADDING-TOP: 10px">which one allows to establish sessions of voice, text and data (sending files), and&nbsp;it can communicate with SIP server that it has been configured and running rigth now.</DIV>
<DIV style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; PADDING-TOP: 10px">Regards.</DIV>
<DIV style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; PADDING-TOP: 10px">Hugo Lara</DIV>
<P><BR></P><p><br><hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/finance/mailsig/*http://tax.yahoo.com">Yahoo! Tax Center</a> - File online, calculators, forms, and more
--0-1092664951-1050010451=:53793--
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Sat Apr 12 08:41:14 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26352
	for <sip-archive@odin.ietf.org>; Sat, 12 Apr 2003 08:41:14 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3CClr828520
	for sip-archive@odin.ietf.org; Sat, 12 Apr 2003 08:47:53 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3CClM828477;
	Sat, 12 Apr 2003 08:47:22 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3CCcf828275
	for <sip@optimus.ietf.org>; Sat, 12 Apr 2003 08:38:41 -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 IAA26279;
	Sat, 12 Apr 2003 08:31:32 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 194KCt-00019v-00; Sat, 12 Apr 2003 08:34:07 -0400
Received: from [194.185.97.41] (helo=gsp01-c07d1.vodafone.it)
	by ietf-mx with esmtp (Exim 4.12)
	id 194KCs-00019s-00; Sat, 12 Apr 2003 08:34:06 -0400
Received: from loretosapc (127.0.0.1) by gsp01-c07d1.vodafone.it (NPlex 5.1.046)
        id 3E6FBCC800004C44; Sat, 12 Apr 2003 14:33:29 +0200
X-CNS-Auth: <username="loretosa", uid="8:18", UMCluster="2", DSUhost="DB">
Message-ID: <000901c300f0$34872910$e46b0b3e@loretosapc>
From: "sal" <loretosa@vodafone.it>
To: "Drage, Keith \(Keith\)" <drage@lucent.com>, <sip@ietf.org>,
        <simple@ietf.org>
References: <475FF955A05DD411980D00508B6D5FB00439ECA7@en0033exch001u.uk.lucent.com>
Date: Sat, 12 Apr 2003 12:31:32 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0036_01C300EF.72DF0CB0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Subject: [Sip] Release 6 ???
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0036_01C300EF.72DF0CB0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Keith,

I hope you can help me.
I'm trying to understand what are the main topics of Release 6
(as for Release 5 was the introduction of IMS and for Release 4 the =
architectural split  in MSC and the HSS).

Can you send me or suggest some link or papers/articles explain this ?


Moreover can you suggest what look in 3GPP for view on how wireless =
network propose to use Instant Messaging ?


best regard
Salvatore Loreto


------=_NextPart_000_0036_01C300EF.72DF0CB0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi Keith,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I hope you can help me.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I'm trying to understand what are the =
main topics=20
of Release 6</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>(as for Release 5 was the introduction =
of IMS and=20
for Release 4 the architectural split&nbsp; in MSC and the =
HSS).</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Can you send me or suggest some link or =

papers/articles explain this ?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Moreover can you suggest what look in =
3GPP for view=20
on how wireless network propose to use Instant Messaging ?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>best regard</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Salvatore Loreto</FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <BLOCKQUOTE=20
  style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; =
PADDING-LEFT: 5px">&nbsp;</BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0036_01C300EF.72DF0CB0--

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



From mailnull@www1.ietf.org  Mon Apr 14 01:13:29 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12766
	for <sip-archive@odin.ietf.org>; Mon, 14 Apr 2003 01:13:29 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3E5KxZ10198
	for sip-archive@odin.ietf.org; Mon, 14 Apr 2003 01:20:59 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E5Jx810134;
	Mon, 14 Apr 2003 01:19:59 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E5CP809860
	for <sip@optimus.ietf.org>; Mon, 14 Apr 2003 01:12: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 BAA12537
	for <sip@ietf.org>; Mon, 14 Apr 2003 01:04:25 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 194wBH-0007PW-00
	for sip@ietf.org; Mon, 14 Apr 2003 01:06:59 -0400
Received: from ipvpn069002.netvigator.com ([203.198.202.2] helo=mail.astri.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 194wBC-0007P3-00
	for sip@ietf.org; Mon, 14 Apr 2003 01:06:55 -0400
Received: from patrickXP (Firewall [203.198.202.1])
	by mail.astri.org (8.11.6/8.11.2) with ESMTP id h3E5EGY11812
	for <sip@ietf.org>; Mon, 14 Apr 2003 13:14:16 +0800
From: "Patrick Lam" <patrickl@astri.org>
To: <sip@ietf.org>
Date: Mon, 14 Apr 2003 13:09:06 +0800
Message-ID: <004f01c30243$f9326640$2306050a@patrickXP>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0050_01C30287.0755A640"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-MS-TNEF-Correlator: 00000000A495D97211F6D54497CF24BD1531C79FC4242A00
Subject: [Sip] Questions regarding Offer/Answer model...
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0050_01C30287.0755A640
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Dear all:

On p.80 of RFC 3261, it states that:

"If the initial offer is in an INVITE, the answer MUST be in a reliable
non-failure message from UAS back to UAC which is correlated to that =
INVITE.
For this specification, that is only the final 2xx response to that =
INVITE.
That same exact answer MAY also be placed in any provisional responses =
sent
prior to the answer.  The UAC MUST treat the first session description =
it
receives as the answer, and MUST ignore any session descriptions in
subsequent responses to the initial INVITE."

My questions are:
1.	Is the answer from 1xx valid then???  If so, why does it state that
the answer can only be present in 2xx on one hand, but on the other hand =
if
the answer is present in 1xx, the answers from 2xx must be ignored???=20
2.	What about the UAS "changes" its mind on the answer after it sends
1xx response (e.g. the callee answers the call from a different UA), and
wants to incorporate the changes into 2xx responses????
3.	Can 100 Trying carry 'answers"?

Thanks very much in advance,

Patrick





------=_NextPart_000_0050_01C30287.0755A640
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Disposition: attachment;
	filename="winmail.dat"
Content-Transfer-Encoding: base64

eJ8+IgYFAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANMHBAAOAA0ACQAAAAEAAwEB
A5AGAEwUAAAnAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB
AAAAKgAAAFF1ZXN0aW9ucyByZWdhcmRpbmcgT2ZmZXIvQW5zd2VyIG1vZGVsLi4uAAAAAgFxAAEA
AAAWAAAAAcMCQ/ifVnzTSAqOQ2K+etgzot1x9wAAAgEdDAEAAAAYAAAAU01UUDpQQVRSSUNLTEBB
U1RSSS5PUkcACwABDgAAAABAAAYOAP5q9UMCwwECAQoOAQAAABgAAAAAAAAApJXZchH21USXzyS9
FTHHn8KAAAADABQOAAAAAAsAHw4BAAAAAgEJEAEAAAAIEAAABBAAABMyAABMWkZ1RO+M2IMACgBy
Y3BnOTUBQAx1YwBQAQRzdHNowQVwYmNoMTQO9AkAmw9wDuVoDeAQRmJpAUOBC2BuZzEwMzMRpuRm
ZRIgMjgB9wKkA2NHAgAPcArAc2V0AtFwKHJxMgAAKgqhbm+tFOAgExAWMTYSMDAOMM40FrEB0Bag
NH0HbQKD7wBQA9QUjxWbYhZxFuAWQm8bhBdgBxMCgzIERhlNMfUVjDcWkTkWMxcCFuAXYP8IVQey
GHQSUALyGUchcA+g/xn/AdASIBaAJBAWoBIgJGVEfVMHcFN1bhWCZoMHQAVAy87M5X0YdPcikRQ8
IXA2Iq8WMxagKVsIfVBNC4BnTGlVCSVnoVAL8E9jdUF+ZSY0J8Im3yfvKP8qAkB7KkYr9Dchny2f
I78kwkBrJQQr9DgUHjI1IjIiINEHbSBDRSv0OTVPFtDTNn83hXlyAoM0GMEsja42GME5zwOCRwnR
aztE3xzhO94c4T0PA4JUCHA7RDshgSyNNzDhQG8DgihI5GViCXB3KTtEJq9DUL82b0SGBxABoA3g
RWU1Re/2OC2FR39CJbEN4DtELF8vPLAhgUrPRLNWCJB0bvphB4FlRWU1MRj8NkgHE3031jQ4YVDd
OYdSVTslNe8Yzzy4UlQ+WDUc4VYOQDb7UlRBtjUhgVYNQ2dSVET73jUx8VtuUdxIizVJYVYN90qH
UlRMGTUtgVYOTgZc5d1PnjU1MR0dNkYxN9AgiP031jU4YWdOOYVovTslPML/HR08tmi8PlhAIm1f
QDRovL9Btk3ycI5DZWi8RPs2MfHvc59oX3WySJo2SWFwjkqF+2i8TBk2LYFwj04EdQ1Pnp9DUALU
GU4GACUTIFcHkO50BJElbxihOBQPggYqRv+C7ytdFuCEv4IGL/eGxjtFv4EfihWCjAKAApEI5jsJ
b/Iwjy9lMmEAkFqRcZEv/5I5kESSYpDPlJ+UXZPfkg//kF8S8BMgmiqbQZr/nAmQRH+cMpqfnm+e
LZ2vm9+fpDl/cFCi9KRRnHOkUAKCDwB5qmwHkGgJ4HQAAHEDIT5sEYEFEAFAFeAD8GRj7HRsCrEA
YHMKsKewGXARp/JudW2DkWF1dGJvAGBkanUPAAUQZ7xodKbxCgGmwAoBaQGQdHAwA7IyD6AR5xKo
XP5rBJEqYXBQEBICshDCAGDvATIPYa4hD5FjCcCncKuDPG5wq9mvshMgAzBzbvxleBnAB7AFsADA
AnMVoFxjcxIgAzCpcGSq0GnOdhYQDvAZoG1pEMCyoLkJ8CBEARCpICXBUArAxmEJwKrwaCBGAiGx
1N0PEDEAUA8QA2B3CzCpwIkBgHNXp3B0aEISUHepwAqwsqBsEiA1MLdEcl+3uBAAtyYBgLknYrkn
cvm3ImNiCrAxwLsSMhC7c/EE8GVsbKdhtvC2kQFA/w8QsvAAICWxtaFFILhAvcY/CVC95AyxvfOn
4L3kZGffvsbAQL/GrZC95HYDMKaK/6dvqH+pj6qcxfER86tlEuP/q3Gtf66Pr5THh8q0sOW10L+z
HLF0TnABoKXwsdc1snrvtDAI0BzQsOFiw5AJgAIgf7JSpcEZkMMAOFBnABbQN/AgSHlwBJCqgT6T
shP+Ns6/nLDP39DqtRC8gKdQ/wmA0a9DULJ6C+O70MXxyHP/AFDI5Q6ByYbUDbNJDvDRwZ5zAiBS
gQ7wBaBtcBXy7dCuRQDAAxBTpdJDUKWD/0pwwi/DP8RPxV/Gb6voH9H/rUZwUMjlcFDJdhJQrx+w
Jr/lgtQI1LLME7DS0MxQC2L3TnCxIbHXOdeM0rLan9unv9DMAHAV4AGQTEACICCPQPsS4I9Abrxg
pYMMAd+v4L//4c/i3+Pv5P/In+cf6C/pP/+xIQHQ7q/vv/DFgyDsJAvw/9nApo/zP/RP9V+qyDyw
q4//rJ/ZH8m/r8+w0vwuzG3Qrv9MEdYA8QHsBthQcFDyTwG//wLPA9+q5L9A9u/3//kPCQ8/+y/U
RP0T/N8M3/Brc3X4YmplEDCOU7WQAMClwL+9kM3h30Ad0h3Es1BwxyC3i0DdwA8QOFXASoAyBXH5
HeFoeUUg3cAeZKXwsvD706AhU26MYPYBIcUEUiFi7moiJiNQItZm1eMiNaXA/xBw8MHZwCUEEGC8
YCI169B/s7GJ4B5hIWL/wid2HzYtLTywNwBQXhA4iMANCsxcJy7AKeEwLoCiIbTtEXBi3EEp4TGA
oBXQSMDjEKCrEmktMzNgALEsklcjUB3VuxB4LJRuLJEg/yqCIS8zoCJIL/YjXyRvJX8PJo8nnx9F
KTA2OTg3hxcRKfTZwCdhMUIqf+8rhSxwUJD2AjktDTpCqoH/OkEunyHjFXEiZj1FMTA99/895jJv
M380jzWfNqpJYCn0/jIqbzlO2lCIwC0rRzOqgf9HMjvvIe8w3zHvQC9BP0JP70NfNzAF4CnlM0Uv
Rj+kUP9HbVRiSJJUYUkPL68wv0wf/00vTj9PT1BfNxurcDgPUy//AMDLwIjRLTph06qBYdJWL/88
/z4PPx9aj1ufXK9dv0Rp9jVST2DfOIShYitvAmMy/28BY69KH1hvWX9n72j/ag/7ax9RiTZs7zlO
BfAtDi32/y5vVw9YH3OvdL91z3bfd+/9Nu43X48rMinDe0wpkS0s/4nCLjIpkX3vZL9lz2bfgk9v
g1+Eb4V/RGk4eg85TjR+M1R9ltOqgZbSi4bcgG3f7XArsR3S3cDfADaW0M6Q+7hwHXhvvWHKMaZA
HiibNveZnprr3OB1keEAsLJAHXSJooB2dM3gIHtV0hD9AUFuHWUNQp/ioQOJsAXg3zcxoZTd9KED
zpA5mkANwK4zK8AQYNHBd8xQOXng9aP0aCkgOImw7YCzsLzw983QOeK88G4dEBCQ8YCyoLcVoBXQ
sYFzEQCcwWixgM56ptLAQN5wcmfr0KghzmiQ499wyVFndqj5p7H/EoBIoVGQ2cGpkKp1NyDHkP+o
wqewj4GpgqxBKhCAgNzx//EwszAAsPCgBbDKMqbR3sCD0cAqEHZpZXdrkaF/RJCu4rxQENAGcRXw
ELBs/Hl0oIDr0JzQpjGwdxKg/95wEdAQsNOA3TC9sNQwceD/EJBx4J/hkaEAsLCAr9EQMP/N4LZB
sHGf4b2AwPFx4CCwvGty05Cc0PCgtTF3ufD/n+HL8QTwEeDKIuvQvGKy4e/WASxgcXDNEWSyYQ/w
ufB+cJ7QEDAQkSwAtScNQnJ/DkDMQKN17YGboLAxHTFkzwCizBEV8KahbmjxYbtTH7vSyiIskrti
3CFjaWZ/3tDfUKYzoBAdoRFQu2Fs7HZs2cARUWOnML9CkBL/v9KRpClAFfARUBEABbC/AecRUC3Q
E4AgLpqUv1YqEL+/8rKAEIDAb8F/wo9sBgD/EVCekcQ/xU/GX7+wCPARUO+z4MQPyN/J5SnCzESQ
x6/jzJ/JxWIgKIehzc+/g/+koct/0E/RX9Jvv7CHMNOy/8A/1R/WL849BrDTv9lP2l/722+/oTnY
P93f3u/f9qPx/nIXgB9B69EAfxAvET8ST//2VeTy5xAbmRPyCPAFnwav/xZiFh8I/woNACAIQQVB
BrD2Y+4B5YBz6rsH7+uxB3S4IERl5xAcMLeQOoeh+/FvoccgKcHnAYuC9Z8bqJf3RfMf9ClPGyBw
LnChgG9mIFJGQyCW4Ng2MSz6D/QpIOoQHODbHIGtgCAggCjAOvdF90b/5Pv4Ig9P5v/oD+kf6i/r
Nv8UPxVIFvAqEO41KhAWr+/f/xjE98+iahYwAvAGm+2l/Yj/7EDuM/ShKiCjgIehDT8OSPcHIDcg
IBA5+fcJ+v5EGQD+SfxQIICnkRPvFPf+wLCw/xygA1D8Meyg9QAekBehHDGBFXBOVklURSwVogkc
MXN3GGFNVVNU/iArMBizEW/yyxZvF3IbH78SfxOPFJ2tcOYAm8IgrdGiLQQgaWx1rXAgmUAprZBh
Z5lQZrowbSBYVUFTGpCRAGv/YG/7JHH8kHfuMhiBIK8W+q0wf5yQcXB4sbugJRH/chkVLv3+sEan
IP9hGJG+FP0geLD+aa3gGYIo0Z0AHk8cLybP/yuPH18gbxSdreCzkBmTRqDjmSDl0DJ4eCJRAzCt
4P+/cCh+Lr8sny2vLq8ODzaf/RSOVCjCI+CZQDsvFvqSkP2RAHQ4zzrfPj8/nznfQL/TFJ0Z5kFZ
9RFzJSBFL/8U2VUgR/8U6JlQeJGRELug/xjDMwCtYJswnQAqwRgBNAb/KgGR0Um/FvqtYCrAKbEo
kv8ZxilhPOCZUCVCGlME4PTg//7gMyQGkP7hrYEqwU4fFvr/uBCvwATwtiAqwf7CrXCREP5pcWD/
UFOPRjpW3xTZ/1L/GcYZgOvgu6AaUwUA5oAjgT9MMVivFvpTFVVKGKNzdfJiv3BxdZHRVs8hrE1W
/1BFF7VCz0TfXT9jv0PfZN9/FJ41Lw6/CdwQpAxwESE032t/+Ur5nWnPFVFNMwBgEfedEV9SAvBl
/7aLpJKD5Qj/u1CYgQdUbwIHvwjI7qgLrM9r3+4/FOb8IDEuipCbwP/k3Qdy5cKJIb2SiZG9oQJM
/4oLvaEDLwQ0nyEEj4sDvaH/Bf8HD3b/7d8KPwtPDFRvD9t6r3u7SVpqJCQxM9CMLzl72SB2gTBn
oBWibj9/kbD+sBWBR7AZgCWAMwBk927fi997jm+tgJLPk9+QD//+0pYfly97jv8SmY+an5g//yiz
Gamv0BjQMtMaoa1iYDL/5YEzwZzvnf+fD1XhreBRYN/JcZK/o7+kz1sgYgRQZt//p5+or16RGaK6
ULyBpk+q3/+r75j0FZMZ1hiRodmPERmK91awjsMzwm2C4RqSrk+vX717jmm1X7Zve45b42SRsf+4
j7mfsG+8P/lKdF91b4Xf33ePeJ95r72Pe8oyfJW/f2/Hb3udEJX8IFcownzAb/+p4RmiJIIRIsxv
J8DjMlag926SmKpWsG3ica0mGeHLP/972UcSiKDBkBhxUvJbUFaww48RM/goZS5nKWAZonuhEPUw
ZbOo1rYkJOSgZK+xcBhRYDIkgClbJHfr4P/RcSUR5YAn0TQwhLDBkNak79AkF6ElETPKc5GxvC/A
b//Bf8KPw5/Er8W/yl/i/3wG3jPJf+Uf5i98M0MY8eHQ8fwgVHJ57VGhASfwMwD/5/8PG+NKzQYB
8GAQraC1P//o7+n/s7bwD+1/7o9ur/Dv+/H//CA/ADt9uAIPgP8EL38FP4SP9w9v+fhfe9k84W5+
a1awVpDsMbTQJbIY0WRzkRDasGUscD8C37DmUP+csP6AJOD2/2/qfP0NAftf//xv/X/+j/+fhV/i
D20jcS//iN+J7wlvaC8Khxb/GQ8XT/8wLQqffZIMKiLwDO8N/w8PXxAfESvQsRIsElAyDABr/7QA
Y1ASMIcf4znQsBUfFib/JjIW4RTQ4PEL8Ru/GC8d1wR9AC4gAwDeP59OAAADAAlZAwAAAAMAQGUA
AAAACwATgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADABWACCAGAAAAAADAAAAAAAAARgAA
AAAQhQAAAAAAAAMAG4AIIAYAAAAAAMAAAAAAAABGAAAAAFKFAAAblwEAAwAigAggBgAAAAAAwAAA
AAAAAEYAAAAAAYUAAAAAAABAACOACCAGAAAAAADAAAAAAAAARgAAAABghQAAAMwL8bz//x8LAEKA
CCAGAAAAAADAAAAAAAAARgAAAACChQAAAQAAAB4ASYAIIAYAAAAAAMAAAAAAAABGAAAAAFSFAAAB
AAAABQAAADEwLjAAAAAACwB1gAggBgAAAAAAwAAAAAAAAEYAAAAABoUAAAAAAAALAHaACCAGAAAA
AADAAAAAAAAARgAAAAAOhQAAAAAAAAMAd4AIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAAAgH4
DwEAAAAQAAAApJXZchH21USXzyS9FTHHnwIB+g8BAAAAEAAAAKSV2XIR9tVEl88kvRUxx58CAfsP
AQAAAJYAAAAAAAAAOKG7EAXlEBqhuwgAKypWwgAAbXNwc3QuZGxsAAAAAABOSVRB+b+4AQCqADfZ
bgAAAEM6XERvY3VtZW50cyBhbmQgU2V0dGluZ3NccGF0cmlja2xcTG9jYWwgU2V0dGluZ3NcQXBw
bGljYXRpb24gRGF0YVxNaWNyb3NvZnRcT3V0bG9va1xPdXRsb29rLnBzdAAAAAMA/g8FAAAAAwAN
NP03AgACARQ0AQAAABAAAABOSVRB+b+4AQCqADfZbgAAAgF/AAEAAAAxAAAAMDAwMDAwMDBBNDk1
RDk3MjExRjZENTQ0OTdDRjI0QkQxNTMxQzc5RkM0MjQyQTAwAAAAAAMABhD6Yh5kAwAHEEcDAAAD
ABAQAAAAAAMAERAAAAAAHgAIEAEAAABlAAAAREVBUkFMTDpPTlA4ME9GUkZDMzI2MSxJVFNUQVRF
U1RIQVQ6IklGVEhFSU5JVElBTE9GRkVSSVNJTkFOSU5WSVRFLFRIRUFOU1dFUk1VU1RCRUlOQVJF
TElBQkxFTk9OLUZBSQAAAADQPA==

------=_NextPart_000_0050_01C30287.0755A640--

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



From mailnull@www1.ietf.org  Mon Apr 14 02:04:47 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18325
	for <sip-archive@odin.ietf.org>; Mon, 14 Apr 2003 02:04:46 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3E6CF622781
	for sip-archive@odin.ietf.org; Mon, 14 Apr 2003 02:12:15 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E6BN821119;
	Mon, 14 Apr 2003 02:11:23 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E66W815409
	for <sip@optimus.ietf.org>; Mon, 14 Apr 2003 02:06: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 BAA13339
	for <sip@ietf.org>; Mon, 14 Apr 2003 01:58:32 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 194x1c-0007aO-00
	for sip@ietf.org; Mon, 14 Apr 2003 02:01:04 -0400
Received: from ipvpn069002.netvigator.com ([203.198.202.2] helo=mail.astri.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 194x1Z-0007aK-00
	for sip@ietf.org; Mon, 14 Apr 2003 02:01:02 -0400
Received: from patrickXP (Firewall [203.198.202.1])
	by mail.astri.org (8.11.6/8.11.2) with ESMTP id h3E68OY13454
	for <sip@ietf.org>; Mon, 14 Apr 2003 14:08:24 +0800
From: "Patrick Lam" <patrickl@astri.org>
To: <sip@ietf.org>
Date: Mon, 14 Apr 2003 14:03:12 +0800
Message-ID: <005d01c3024b$88273720$2306050a@patrickXP>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_005E_01C3028E.964A7720"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-MS-TNEF-Correlator: 00000000A495D97211F6D54497CF24BD1531C79F04262A00
Subject: [Sip] Questions on UAC behavior when the response is unacceptable.
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_005E_01C3028E.964A7720
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Dear all:

On p.89 of RFC3261,

"If, however, it is unacceptable to the UAC, the UAC SHOULD generate an
answer with a valid session description, and then send a BYE to =
terminate
the session."

Questions:
1.	How is the answer carried toward the UAS?  Through ACK?
2.	Why does the UAC have to generate a valid answer, when it is going
to terminate the session right away?  I believe it wants to let the UAS =
know
what it will accept with the hope that the UAS will generate an =
acceptable
response in the next call, right??  However, there is no specification
(unless I missed it) here to state that the UAS has to 'remember" what =
the
UAC does not accept.  It seems to me that generating this valid answer =
is
quite unnecessary.
3.	Can the UAC terminate the session without sending the valid answer?
That is, can the UAC send a BYE without sending the ACK first (assuming =
the
UAS would know what this means)?

Thanks very much in advance,

Patrick Lam


------=_NextPart_000_005E_01C3028E.964A7720
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Disposition: attachment;
	filename="winmail.dat"
Content-Transfer-Encoding: base64

eJ8+IgwGAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANMHBAAOAA4AAwAAAAEA/gAB
A5AGAAwTAAAnAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB
AAAAPQAAAFF1ZXN0aW9ucyBvbiBVQUMgYmVoYXZpb3Igd2hlbiB0aGUgcmVzcG9uc2UgaXMgdW5h
Y2NlcHRhYmxlLgAAAAACAXEAAQAAABYAAAABwwJLh8jLef04d3tFBLXf9DdzzqwbAAACAR0MAQAA
ABgAAABTTVRQOlBBVFJJQ0tMQEFTVFJJLk9SRwALAAEOAAAAAEAABg4AwpuASwLDAQIBCg4BAAAA
GAAAAAAAAACkldlyEfbVRJfPJL0VMcefwoAAAAMAFA4AAAAACwAfDgEAAAACAQkQAQAAALMOAACv
DgAAJSwAAExaRnVPHtgZgwAKAHJjcGc5NQFADHVjAFABBHN0c2jBBXBiY2gxNA70CQCbD3AO5WgN
4BBGYmkBQ4ELYG5nMTAzMxGm5GZlEiAyOAH3AqQDY0cCAA9wCsBzZXQC0XAocnEyAAAqCqFub60U
4CATEBYxNhIwMA4wzjQWsQHQFqA0fQdtAoPvAFAD1BSPFZtiFnEW4BZCbxuEF2AHEwKDMgRGGU0x
9RWMNxaRORYzFwIW4Bdg/whVB7IYdBJQAvIZRyFwD6D/Gf8B0BIgFoAkEBagEiAkZUR9UwdwU3Vu
FYJmgwdABUDLzszlfRh09yKRFDwhcDYirxYzFqApWwh9UE0LgGdMaVUJJWehUAvwT2N1QX5lJjQn
wibfJ+8o/yoCQHsqRiv0NyGfLZ8jvyTCQBslBBh0MjDhFDwyMzjFMgQgB20gQ0U01TZxzzV9FtA2
jzeVeXIhJRQPXDE2GME57wOCRwnRa78hJRjBPA4c4T0/A4JUCHB3ISUc4SyNNzDhQK8DgijISGVi
CXB3KSElIYH/Qs42f0TWBxABoA3gRbYmr+wxOC2FR99CJbEN4CElujVJ7zYhgUs/RQNWCJDodG5h
B4FlRbYw4Rj8/zZYBxM35zZiUW05p1LlO0bfFuAY3jzoUuQ+iTQYz0BY+1LkQfc0HOFWvUO3UuRF
TN40IYFcPlJsSOw0MfFWvfdK91LkTIo0TVFWvk6GXbXdUB80MOEdHTZWMTfgIIj9N+c0R2FoXjml
ac07Rg4x7x0OPOZpzD6JNVlRbo9AdHtpzEH3NRzvQ5dpzEVMNd8hgXTvaW93Akj7NTHxcc73SvVp
zEyKNU1Rcc9OhHZd8WcOMjU5MPwZ1QYAJRN0IFcHkHQEkSVvHME2/4KRFD9OsypGhG8rXWsghj/v
g4Yv94hGifQ5gp+LlYQMVwKAApEI5jsJbzCQr2X9gnA1kdqS8ZKvk7mRxJPi/5JPlh+V3ZVfk4+R
3xLwEyD/m6o4YpyPnZiRxDhinB+f7++frZ8vnV+hJDl0sKR0pdFPnfOl0AKCDwB5bAeQaNUJ4HQA
AHEDIWwRgQUQhwFAFeAD8GRjdGwKsT0AYHMKsKkwGXCpcm51Qm0lkWF1dG8AYGSManUPAAUQZ2h0
qHGXCgGoQAoBaQGQcDADss4yD6AR5xKoXGsEkSph/3SwEBICshDCAGABMg9hr6GdD5FjCcCo8K0D
bnCtWYexMhMgAzBzbmV4GcCfB7AFsADAAnMVoGNzEiDLAzCq8GSsUGl2FhAO8DkZoG1pEMC0IAnw
IETXARCqoCXBUArAYQnArHC4aCBGAiGzVA8QMQBQOw8QA2B3CzCrQAGAc1fxqPB0aEISUKtACrC0
IO5sEiBHYLjEcrk4EAC4pmsBgLqnYrqncrihBPBl/GxsqOG4cLgRAUAPELRw/wAgJbG3IUVwucC+
JglQvkTPDLG+U6lgvkRkZ78mwKD3wCavEL5EdgMwqAqo76n//6sPrBzGURHzrOUS46zxrv//sA+x
FMfnyxSyZbdQtJyy9O9O8AGgp3CzVzWz+rWwCND7HNCyYWLD8AmAAiCz0qdBPxmQw2A/ITZQaBBp
wEh53nAEkKwBPsOzkzbPHzUg/9A/0Uu2kLzgqNAJgNIfQ6D/s/oL49AAxlHI0wBQyUUOgd/J5tR9
tMkO8NIxcwIgUxGzDvAFoG1wFfLVT0UAwP0DEFOnUkOgpwNK4MKPw5//xK/Fv8bPrWgf0a7GdLDJ
Rf90sMnWElCwn7Gm5hLUeNUi98xzslLRLVALYk7wsqGzV/452AzTItsf3CfRLQBwFeB3AZBMsAIg
IJDAEuCQwG7/vMCnAwwB4D/hT+Jf42/kf//lj8j/56/ov+nPsqEB0O9P//Bf8WaEoOzEC/DaQKgP
8+//9P/2D6xIPOCtD64f2Z/KH/+xT7JS/N7Mzf7PTIHWgPGx/+yks2MBgKdAvfDOQd/QEAI7D/S0
0HDHgISg3kAtNz01MDkGkBIQR2AQAmh5f79g3kAQlKdwtHDUEBOTbt8dgPaxFAUFEhOiahRmFZD9
FRZm1mMUdadAApDxcdpA/xdEAoDyUBR17HC1MR3wEJG/E6IAghm2EWdK4DHgOWTQYUrgDQpcJy7A
HBEwbi400hP0A5Bi3MEcETGfNND5YEkgAsCskmktW/Bf9rIewhWQEAW34HgexG79HsEgHLITbzvB
FJciJhWfnxavF78YzxnfEXU2N4YgHjgOoHggHCTaQCdhMa5CHK8dtR6hOPayOTNg/x9bLHKsASxx
IM8UI/kBFKb/L3UjYDAnMBYknyWvJr8nz/co2k1QHCQyHJ8rfmHhH0z/OWOsATliLh8ULyMPJB8y
X78zbzR/NY8pYAagHBUzN1//OG+l0DmdRpI6wkaROz8h3/8i7z5PP19Ab0F/Qo8pS2IA/yo/RV8B
gMwgHHAfW1QDrAH/VAJIXy8vMD8xT0y/Tc9O39tP7zaZNUR/Uw84LCFUW/9hMlViYTFV3zxPSp9L
r1of71svXD9dT0O5Nl8fK34GsP8sjW5DrAFuQmL/SW9Kf2YP32cfaC9pP2pPKUs3Ub8dYvsb8218
ODmNe+NvonvxcB//Vu9X/1kPdH91j3afd682meY4bD8rfjQzHz6JEiBi94kRfbbdAG3uEB3hEALe
QVWJADCl0DgboDAPqG//vcHKkafAEFiNdovPjSvdYD51hBEBcLPAD6SbwHZ0sc5AIHtV0oACAW4P
lf8OApIyk1N74AagKWGTUw5G2ZSkNTnRkFGQMx3wAoC10jF3t1A5bBCWVGgGIH8bcLJRtTC9UM4w
OQK9UG78YmoCsKHgtCD5MPlgswHXp5C7kI8QaLMAepkywKDZ3wByZ+xwmoFogxPgAPnJsWd2m1ma
EQSgOtFDwP/aQZvwnNUSYKzwmyKaEIGx/5vinqGl4HKw3XGhQLSwAXB/8VAGcMqSmTGnUNIwpeB2
8Glld2uD0TbAoUK8sI8C8Acx+YAC0Gx5dJLQ/+xwjxCYkaLXBMDfAAPwAtD/0/DdsL4Q1KBkEAKw
ZBCSMf+D0QFwouCiMQJQzkC3waLRn5IxveDBUWQQv2BrctQA948Q8VCnkXe40JIxsnEFsP8EAKBi
7HC8wqVB1oEekGOg3bUxZKTB86C40HCRIAJQ/wKxHjCnhw4Ct6DxYJXG7iHnjeCikZDwdGQBYrKR
+YD5mQFuaPIRrbOuMqBiblLjrcLcoWNpZt9g3+CYk8+SYLcBA3CtwWx2uSCxofx1Y5mQsaKCQrIy
g9QR8P/5gANwAyAGcLFhA3AgAL3w/CAujNSxthxAslK+EAKg97LPs9+072wGwANwkOG2n/+3r7i/
shDH8ANwpkC2b7s/fbxFKbUsNsC6D77/vCVi/CAoedHAL7HjlwG938Kv/8O/xM+yEHlgxhKyn8d/
yI9/wJ0HcMYfy6/Mv83PsgE538qf0D/RT9JWllFyChARcf/scQE/Ak8DXwRv9wXXUtlw/94694K9
oAZfB2/58vmvCb/fCs3ykAkB7kEHcGPgcexwHnPdHAiv3iEINCBEZXfZcPEgqfA6edHj35QXIP8b
8dlhfbLoH9056cXln+apEk8NoHAujJAgb2YQIFJGQ4kQNjEs/+nF6cbXW+qi8v/ZX9pv23//3I/d
l/VB3lz8YuAGHEDgpf8cQOE23rDh3wrm+HLjr+S7//pw80CO0N0r4BUJGN6w4KP/5yEcUJXgedH9
D/4f5Wn5ysPm1PxASWYsIJ6hY4FsciwD3wTpIPWwCBBz/wFfA38HD32yCK8Cnwm/BLzfkSCDMKmQ
qICOAiD0IBCwYa7gIFVBQwWwEPUgAFNIT1VMRCBnv5kAjsBq4eeQ7mDeUHMF8L/ngPJAEPDnkA4/
B2p28xCt3TAgsdCf8GmgQCCqcP+iIPSwqIAWcQWw3lCuABDxj+5gsdAXkbyQQllFELP9jsBt1+AS
whDxFA8HahY1f7UQC8//C/nKAJT8QAERNJ8cH+vL7C0aTwVhUXWf4PkXInM674V91ISz12jxMv/3
FR+y94/4nyI9+6kf7yiv+QTpMS46QI4A1zXxKDjS/0ezLxLyDIlbRqHy7/P0kXH/9E+KU0ah9b/d
hB+fK28Enn5IqhAIQRDjEzWiMI7RZU8XoaoQLhIQ9FM/CABUKmiskHX00CARQEs//yQ/JU8mXydv
KH8pjyqfN48dBNoyLYRETwTpV2h5/Ragb5/gEXcx8GOQELISeHcVxRM0BbB3F9IIIxJgb7/fwRi/
Fif0s+eQOxB5O9D/H49D70cvUB8E21H/UT9UH/8FNIfA2GBjgQgSOxClcDmh7xDQY3AIMDtlIJKi
VY8E2vdLUGrgV8NpqfDnkBAjE5T/EPKcwJaAEOFbgVjWW+MSe/sQKJ/RcCPxV7HuYBDyrlHbCDCi
MWwFsPSzP06fT6//Wj8Lj2MvZD85Imb/BOkF5PtozwTpLGWPZp9rnxDin9B/OYLY4BYgsIPgsHgg
FnIo75EgfjCf8AWAIBkgn/A6wf00wCkFwHASEMHUQW4vBOn/GWNdqTHwWENsvx0vHj/YUPxxdayw
i4B2z23PdE+f0P+LcIeyen9333jvH097T3xf/wfTW2MRhkhz2OBOMRAjLYD/gx8HeQWACDCx0H3Q
WEOLcf9dgxJ1TCPgoHHwSno5gnoQfzTAEaAP8KMwqZCf8PKwef4uPM893z7vP/9BD0IfQy97gv8E
2jMthYGvlB9SvkP/EwERhkyfFmOYD1q6E7E8MP+IktTgijQRoEp6Yi+Xj5x/94hBPABbgnMFsGFg
megYGXedrxEBPIEgqjD2UAgwKP12YHPzsEwioT90ql3mPDB+bK4AWVOE1TmRfcATMSn/PLYt7vHP
MY/z7/T/NR82L8/rz6fPBSWjAW5riqF+AHlIUG114MBgkq+AisBu31xQ736yX6DvUr5QcTCv4MBj
ayBMYW24jwzM4SCwOTg2Mu6w7//X7//Y/65/r4+wn90/3k/fX+BvP+F/4o/jn7zv/m3pxn0AAc9A
AAMA3j+fTgAAAwAJWQMAAAADAEBlAAAAAAsAE4AIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAA
AwAVgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADABuACCAGAAAAAADAAAAAAAAARgAAAABS
hQAAG5cBAAMAIoAIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAAQAAjgAggBgAAAAAAwAAAAAAA
AEYAAAAAYIUAAADMC/G8//8fCwBCgAggBgAAAAAAwAAAAAAAAEYAAAAAgoUAAAEAAAAeAEmACCAG
AAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAUAAAAxMC4wAAAAAAsAdYAIIAYAAAAAAMAAAAAAAABG
AAAAAAaFAAAAAAAACwB2gAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADAHeACCAGAAAAAADA
AAAAAAAARgAAAAAYhQAAAAAAAAIB+A8BAAAAEAAAAKSV2XIR9tVEl88kvRUxx58CAfoPAQAAABAA
AACkldlyEfbVRJfPJL0VMcefAgH7DwEAAACWAAAAAAAAADihuxAF5RAaobsIACsqVsIAAG1zcHN0
LmRsbAAAAAAATklUQfm/uAEAqgA32W4AAABDOlxEb2N1bWVudHMgYW5kIFNldHRpbmdzXHBhdHJp
Y2tsXExvY2FsIFNldHRpbmdzXEFwcGxpY2F0aW9uIERhdGFcTWljcm9zb2Z0XE91dGxvb2tcT3V0
bG9vay5wc3QAAAADAP4PBQAAAAMADTT9NwIAAgEUNAEAAAAQAAAATklUQfm/uAEAqgA32W4AAAIB
fwABAAAAMQAAADAwMDAwMDAwQTQ5NUQ5NzIxMUY2RDU0NDk3Q0YyNEJEMTUzMUM3OUYwNDI2MkEw
MAAAAAADAAYQO8HVBAMABxD2AgAAAwAQEAAAAAADABEQAAAAAB4ACBABAAAAZQAAAERFQVJBTEw6
T05QODlPRlJGQzMyNjEsIklGLEhPV0VWRVIsSVRJU1VOQUNDRVBUQUJMRVRPVEhFVUFDLFRIRVVB
Q1NIT1VMREdFTkVSQVRFQU5BTlNXRVJXSVRIQVZBTElEU0UAAAAAboU=

------=_NextPart_000_005E_01C3028E.964A7720--

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



From mailnull@www1.ietf.org  Mon Apr 14 02:27:53 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25302
	for <sip-archive@odin.ietf.org>; Mon, 14 Apr 2003 02:27:53 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3E6ZM325369
	for sip-archive@odin.ietf.org; Mon, 14 Apr 2003 02:35:22 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E6Yn825266;
	Mon, 14 Apr 2003 02:34:49 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E6Td824857
	for <sip@optimus.ietf.org>; Mon, 14 Apr 2003 02:29: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 CAA25202
	for <sip@ietf.org>; Mon, 14 Apr 2003 02:21:40 -0400 (EDT)
From: ssundaragopalan@hss.hns.com
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 194xO0-0007eS-00
	for sip@ietf.org; Mon, 14 Apr 2003 02:24:12 -0400
Received: from 210-210-93-19.lan.sify.net ([210.210.93.19] helo=hss.hns.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 194xNy-0007eI-00
	for sip@ietf.org; Mon, 14 Apr 2003 02:24:11 -0400
Received: from sampark.hss.hns.com (sampark [139.85.229.22])
	by hss.hns.com (8.11.6/8.11.2) with SMTP id h3E5jKZ30331;
	Mon, 14 Apr 2003 11:15:23 +0530
Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 65256D08.0022FFA3 ; Mon, 14 Apr 2003 11:52:16 +0530
X-Lotus-FromDomain: HSSBLR
To: "Patrick Lam" <patrickl@astri.org>
cc: sip@ietf.org
Message-ID: <65256D08.0022FE99.00@sampark.hss.hns.com>
Date: Mon, 14 Apr 2003 11:52:13 +0530
Subject: Re: [Sip] Questions regarding Offer/Answer model...
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>



Response inline...

regds,
srikanth
Hughes Software Systems




"Patrick Lam" <patrickl@astri.org> on 04/14/2003 11:39:06 AM

To:   sip@ietf.org
cc:    (bcc: Srikanth Sundaragopalan/HSSBLR)

Subject:  [Sip] Questions regarding Offer/Answer model...




Dear all:

On p.80 of RFC 3261, it states that:

"If the initial offer is in an INVITE, the answer MUST be in a reliable
non-failure message from UAS back to UAC which is correlated to that
INVITE.
For this specification, that is only the final 2xx response to that INVITE.
That same exact answer MAY also be placed in any provisional responses sent
prior to the answer.  The UAC MUST treat the first session description it
receives as the answer, and MUST ignore any session descriptions in
subsequent responses to the initial INVITE."

My questions are:
1.   Is the answer from 1xx valid then???  If so, why does it state that
the answer can only be present in 2xx on one hand, but on the other hand if
the answer is present in 1xx, the answers from 2xx must be ignored???
-> Yes,the answer from 1xx is valid,provided that is transmitted reliably.
-> This talks about 2xx response alone because,the RPR's(Reliable
provisional
-> responses)are not part of RFC 3261 and is part of RFC 3262.
-> An Answer can be sent in any RPR(180,182,183) and the same answer can be
-> echoed back in 2xx responses.
2.   What about the UAS "changes" its mind on the answer after it sends
1xx response (e.g. the callee answers the call from a different UA), and
wants to incorporate the changes into 2xx responses????
->UAS *CANNOT* Change the answer when sending 2xx response.If it decides to
change the media
-> parameters it needs to do so by sending a UPDATE Request.(Refer RFC
3311).
3.   Can 100 Trying carry 'answers"?
-> NO.100 Trying is never transmitted reliably,hence cannot contain SDP.
->Moreover its mostly the proxy which sends 100 trying.

Thanks very much in advance,

Patrick






[Filename: winmail.dat, Content-Type: application/ms-tnef]
The attachment file in the message has been removed as per HSS E-mail
Policy.





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



From mailnull@www1.ietf.org  Mon Apr 14 03:16:05 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26306
	for <sip-archive@odin.ietf.org>; Mon, 14 Apr 2003 03:16:05 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3E7Naa28799
	for sip-archive@odin.ietf.org; Mon, 14 Apr 2003 03:23:36 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E7ND828785;
	Mon, 14 Apr 2003 03:23:13 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E7Gs828572
	for <sip@optimus.ietf.org>; Mon, 14 Apr 2003 03:16: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 DAA26142
	for <sip@ietf.org>; Mon, 14 Apr 2003 03:08:53 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 194y7h-0000HT-00
	for sip@ietf.org; Mon, 14 Apr 2003 03:11:26 -0400
Received: from shardagate.mahindrabt.com ([203.124.158.2])
	by ietf-mx with esmtp (Exim 4.12)
	id 194y7g-0000HQ-00
	for sip@ietf.org; Mon, 14 Apr 2003 03:11:25 -0400
Received: from thisdomain (mailscan.sharda.mahindrabt.com [10.5.0.97])
	by shardagate.mahindrabt.com (8.12.8/8.12.8) with ESMTP id h3E7BJ4L019890
	for <sip@ietf.org>; Mon, 14 Apr 2003 12:41:24 +0530
Received: from intranet.sharda.mahindrabt.com by mahindrabt.com ; Mon, 14 Apr 2003 12:27:29 +0530
Date: Mon, 14 Apr 2003 12:27:29 +0530
X-Originating-IP: 10.5.0.15
X-Auth-User: ashishn@mahindrabt.com
Received: from dscp00212 ([10.5.3.103])
	by intranet.sharda.mahindrabt.com (8.9.3/8.9.3) with SMTP id MAA30220
	for <sip@ietf.org>; Mon, 14 Apr 2003 12:41:14 +0530
From: "Ashish Naik" <ashishn@mahindrabt.com>
To: "Sip@Ietf. Org" <sip@ietf.org>
Date: Mon, 14 Apr 2003 12:45:05 +0530
Message-ID: <NFBBIJAAOFNEMIHBIFPIIEJDDHAA.ashishn@mahindrabt.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000B_01C30283.AC5E5320"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Subject: [Sip] Presence architecture for fixed line network
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_000B_01C30283.AC5E5320
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Can someone point me to an architecture documents of SIP based presence
architecture in fixed line network ?

I want to know which network elements will be part of this as compared to
presence server in 3G networks.
Ashish

*********************************************************
Disclaimer

This message (including any attachments) contains 
confidential information intended for a specific 
individual and purpose, and is protected by law. 
If you are not the intended recipient, you should 
delete this message and are hereby notified that 
any disclosure, copying, or distribution of this
message, or the taking of any action based on it, 
is strictly prohibited.

*********************************************************
Visit us at http://www.mahindrabt.com


------=_NextPart_000_000B_01C30283.AC5E5320
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.2800.1106" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D375281107-14042003><FONT face=3DArial size=3D2>Can =
someone point me=20
to an architecture documents of SIP based presence architecture in fixed =
line=20
network ? </FONT></SPAN></DIV>
<DIV><SPAN class=3D375281107-14042003><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D375281107-14042003><FONT face=3DArial size=3D2>I want =
to=20
know&nbsp;which network elements will be part of this as compared to =
presence=20
server in 3G networks.</FONT></SPAN></DIV>
<P><FONT face=3DArial size=3D2><SPAN=20
class=3D375281107-14042003>Ashish</SPAN></FONT></P></BODY></HTML>

<html>
<br>
*********************************************************<br>
Disclaimer<br>
<br>
This message (including any attachments) contains <br>
confidential information intended for a specific <br>
individual and purpose, and is protected by law. <br>
If you are not the intended recipient, you should <br>
delete this message and are hereby notified that <br>
any disclosure, copying, or distribution of this<br>
message, or the taking of any action based on it, <br>
is strictly prohibited.<br>
<br>
*********************************************************<br>
Visit us at http://www.mahindrabt.com<br>
<br>
</html>

------=_NextPart_000_000B_01C30283.AC5E5320--


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



From mailnull@www1.ietf.org  Mon Apr 14 03:29:38 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26791
	for <sip-archive@odin.ietf.org>; Mon, 14 Apr 2003 03:29:37 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3E7b9K29767
	for sip-archive@odin.ietf.org; Mon, 14 Apr 2003 03:37:09 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E7an829567;
	Mon, 14 Apr 2003 03:36:49 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E7VM829338
	for <sip@optimus.ietf.org>; Mon, 14 Apr 2003 03:31: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 DAA26685
	for <sip@ietf.org>; Mon, 14 Apr 2003 03:23:20 -0400 (EDT)
From: ssundaragopalan@hss.hns.com
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 194yLh-0000Ob-00
	for sip@ietf.org; Mon, 14 Apr 2003 03:25:53 -0400
Received: from 210-210-93-19.lan.sify.net ([210.210.93.19] helo=hss.hns.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 194yLf-0000OX-00
	for sip@ietf.org; Mon, 14 Apr 2003 03:25:52 -0400
Received: from sampark.hss.hns.com (sampark [139.85.229.22])
	by hss.hns.com (8.11.6/8.11.2) with SMTP id h3E6ktZ31241;
	Mon, 14 Apr 2003 12:16:57 +0530
Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 65256D08.0028A4E2 ; Mon, 14 Apr 2003 12:53:56 +0530
X-Lotus-FromDomain: HSSBLR
To: "Patrick Lam" <patrickl@astri.org>
cc: sip@ietf.org
Message-ID: <65256D08.0028A367.00@sampark.hss.hns.com>
Date: Mon, 14 Apr 2003 12:53:52 +0530
Subject: Re: [Sip] Questions on UAC behavior when the response is
	 unacceptable.
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>



Response Inline.

regds,
srikanth
Hughes Software Systems




"Patrick Lam" <patrickl@astri.org> on 04/14/2003 12:33:12 PM

To:   sip@ietf.org
cc:    (bcc: Srikanth Sundaragopalan/HSSBLR)

Subject:  [Sip] Questions on UAC behavior when the response is
      unacceptable.




Dear all:

On p.89 of RFC3261,

"If, however, it is unacceptable to the UAC, the UAC SHOULD generate an
answer with a valid session description, and then send a BYE to terminate
the session."

Questions:
1.   How is the answer carried toward the UAS?  Through ACK?
->Yes.
2.   Why does the UAC have to generate a valid answer, when it is going
to terminate the session right away?  I believe it wants to let the UAS
know
what it will accept with the hope that the UAS will generate an acceptable
response in the next call, right??  However, there is no specification
(unless I missed it) here to state that the UAS has to 'remember" what the
UAC does not accept.  It seems to me that generating this valid answer is
quite unnecessary.

->Here *Valid Answer* means a valid SDP formed according to the
Offer/Answer Model.
-> All streams in the Offer will be rejected by the UAC by setting the port
to 0 in this
-> Valid Answer.

3.   Can the UAC terminate the session without sending the valid answer?
That is, can the UAC send a BYE without sending the ACK first (assuming the
UAS would know what this means)?
-> NO NO.This is Protocol non-conformance.By doing this you will break two
things.
-> One you are NOT generating an ACK,which is mandatory according to RFC
3261
-> and other you are not sending an Answer for an Offer according to RFC
3264.

Thanks very much in advance,

Patrick Lam



[Filename: winmail.dat, Content-Type: application/ms-tnef]
The attachment file in the message has been removed as per HSS E-mail
Policy.





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



From mailnull@www1.ietf.org  Mon Apr 14 14:52:00 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16094
	for <sip-archive@odin.ietf.org>; Mon, 14 Apr 2003 14:52:00 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3EIxjH13912
	for sip-archive@odin.ietf.org; Mon, 14 Apr 2003 14:59:45 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EIx9813890;
	Mon, 14 Apr 2003 14:59:09 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EIqY813695
	for <sip@optimus.ietf.org>; Mon, 14 Apr 2003 14: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 OAA15878
	for <sip@ietf.org>; Mon, 14 Apr 2003 14:44:19 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1958yh-0004E1-00
	for sip@ietf.org; Mon, 14 Apr 2003 14:46:51 -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 1958yg-0004Dr-00
	for sip@ietf.org; Mon, 14 Apr 2003 14:46:50 -0400
Received: from txdwillis ([216.229.166.130])
	(authenticated bits=0)
	by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h3EIjQIH002709
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <sip@ietf.org>; Mon, 14 Apr 2003 13:46:24 -0500
From: "Dean Willis" <dwillis@dynamicsoft.com>
To: <sip@ietf.org>
Date: Mon, 14 Apr 2003 13:44:31 -0500
Message-ID: <003301c302b6$08e9f680$40f30a0a@txdwillis>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Content-Transfer-Encoding: 7bit
Subject: [Sip] Question on Service Route Discovery draft and multiple contacts per AoR
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-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 current text in draft-ietf-sip-scvrtdisco-03.txt says, in "6.3
Procedures at the Registrar":

   A REGISTER operation performing a Fetching Bindings (i.e.  no Contact
   header field is present in the request) SHOULD return the same value
   of Service-Route as returned in the corresponding previous REGISTER
   response for the address-of-record in question.  In some cases, the
   Service-Route may be dynamically calculated by the registrar rather
   than stored, and the decision as to whether this route should be
   recalculated in the event of a Fetching Bindings operation is left to
   the implementation.


Ben Jenkins pointed out to me that this may be unclear in cases where there
are multiple contacts registered for a specific AoR.

We do not state explicitly that the Service Route is common to all contacts
for the AoR. Is it really? Do we need to add anything here for clarity?

--
Dean

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



From mailnull@www1.ietf.org  Mon Apr 14 22:03:12 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00306
	for <sip-archive@odin.ietf.org>; Mon, 14 Apr 2003 22:03:12 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3F2B6f11494
	for sip-archive@odin.ietf.org; Mon, 14 Apr 2003 22:11:06 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F2AS811396;
	Mon, 14 Apr 2003 22:10:28 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F246810375
	for <sip@optimus.ietf.org>; Mon, 14 Apr 2003 22:04: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 VAA00097
	for <sip@ietf.org>; Mon, 14 Apr 2003 21:55:42 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195Fi9-0006oV-00
	for sip@ietf.org; Mon, 14 Apr 2003 21:58:13 -0400
Received: from ipvpn069002.netvigator.com ([203.198.202.2] helo=mail.astri.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 195Fi2-0006oR-00
	for sip@ietf.org; Mon, 14 Apr 2003 21:58:08 -0400
Received: from patrickXP (Firewall [203.198.202.1])
	by mail.astri.org (8.11.6/8.11.2) with ESMTP id h3F20vm09334
	for <sip@ietf.org>; Tue, 15 Apr 2003 10:00:57 +0800
From: "Patrick Lam" <patrickl@astri.org>
To: <sip@ietf.org>
Date: Tue, 15 Apr 2003 10:00:17 +0800
Message-ID: <001901c302f2$c2f6a0f0$2306050a@patrickXP>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_001A_01C30335.D119E0F0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-MS-TNEF-Correlator: 00000000A495D97211F6D54497CF24BD1531C79FC4312A00
Subject: [Sip] Questions about "Check response for forwarding"...
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_001A_01C30335.D119E0F0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear all:

On p.110 of RFC 3261, it states:

"After a final response has been sent on the server transaction, the
following responses MUST be forwarded immediately:
         -  Any 2xx response to an INVITE request"

I am just wondering why the proxy would still forward a 2xx after =
sending
another final response.  Does this mean that after sending, say a 4xx
response upstream, the proxy should still forward a 2xx response =
upstream? =20

I think I am confused about the wording here.  Why the "final response" =
is
*sent*, while the "2xx response" is *forwarded*?  Also, isn't 2xx a =
final
response as well?

At a later paragraph, RFC 3261 states:

"This step, combined with the next, ensures that a stateful proxy will
forward exactly one final response to a non-INVITE         request, and
either exactly one non-2xx response or one or more 2xx responses to an
INVITE request."

I do not see how this conclusion can be drawn.  Nothing about =
"non-INVITE"
request has been mentioned in this section ('Check response for =
forwarding')
at all.  Can someone please spend a little time to explain to me how =
this
conclusion is drawn from the previous paragraphs?

Thanks very much in advance.

Patrick Lam

------=_NextPart_000_001A_01C30335.D119E0F0
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Disposition: attachment;
	filename="winmail.dat"
Content-Transfer-Encoding: base64

eJ8+IhECAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANMHBAAPAAoAAAAAAAIA+QAB
A5AGACQSAAAnAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB
AAAAMwAAAFF1ZXN0aW9ucyBhYm91dCAiQ2hlY2sgcmVzcG9uc2UgZm9yIGZvcndhcmRpbmciLi4u
AAACAXEAAQAAABYAAAABwwLywqpM5yqou3RIPIHwCYNYEXdvAAACAR0MAQAAABgAAABTTVRQOlBB
VFJJQ0tMQEFTVFJJLk9SRwALAAEOAAAAAEAABg4AEKq48gLDAQIBCg4BAAAAGAAAAAAAAACkldly
EfbVRJfPJL0VMcefwoAAAAMAFA4AAAAACwAfDgEAAAACAQkQAQAAANUNAADRDQAAGSsAAExaRnV/
7e/9gwAKAHJjcGc5NQFADHVjAFABBHN0c2jBBXBiY2gxNA70CQCbD3AO5WgN4BBGYmkBQ4ELYG5n
MTAzMxGm5GZlEiAyOAH3AqQDY0cCAA9wCsBzZXQC0XAocnEyAAAqCqFub60U4CATEBYxNhIwMA4w
zjQWsQHQFqA0fQdtAoPvAFAD1BSPFZtiFnEW4BZCbxuEF2AHEwKDMgRGGU0x9RWMNxaRORYzFwIW
4Bdg/whVB7IYdBJQAvIZRyFwD6D/Gf8B0BIgFoAkEBagEiAkZUR9UwdwU3VuFYJmgwdABUDLzszl
fRh09yKRFDwhcDYirxYzFqApWwh9UE0LgGdMaVUBJWe3c7LTqfrFfukmNCfCJt8n7yj/KgJAeypG
K+Q3IZ8tjyO/JMJAiyUEGHQyJq8yMzgx9KIgB20gQ0U0xTU1T+cW0DZ/N4V5cjTFMNEsfa42GME5
3wOCRwnRazTF3zZhO/4c4T0vA4JUCHA0xTo5P083MNFAnwOCKEjkZWIJcHcpISUUD0OQ/zZvRMYH
EAGgDeBFphjBLH32OC11R89CJbEN4CElHOEvO/4hgUsvRPNWCJB0bvphB4FlRaYx4Rj8NkgHE/03
1zM4cVFdOZdS1Ts2MML/GPw82FLUPnk2UlauQGZS1P1B5zNCgVatQ6dS1EU8FuDvXA9HR12lSOs0
GM9K2FLUfUx6NBzhVq5Odl2lUA80dzHhHR02RjE30CCIN9c03zhxaE45lWm9OzY0MNEdHfc81mm8
Pnk0R1Fuf0Bkabz9Qec0QoFxvkOlabxFPA4x73TPR0V2TUjrNWHxcb5K5ftpvEx6NRzvTkd2TWb+
OGCfLXExChnVBgAlEyBXB5DudASRJW8cwTYsT4N2Kkb/hF8rXHFwhi+Ddi/niDaJ1H45go+LdYP8
AoACkQjmO9UJbzCQj2U4YDWRupLR/5KPk5mRpJPCki+V/5W9lT//k2+RvxLwEyCbij8SnG+deP+R
pD8Sm/+fz5+Nnw+dP6EE/jl+0KRUpbGd06WwAoIPAFR5bAeQaAngdAAAcX0DIWwRgQUQAUAV4APw
ZNhjdGwKsQBgcwqwqRAjGXCpUm51bSWRYXXEdG8AYGRqdQ8ABRB4Z2h0qFEKAaggCgFpeQGQcDAD
sjUhEecSqFz+awSRKmF+0BASArIQwgBg7wEyD2GvgQ+RYwnAqNCs4zxucK05sRITIAMwc278ZXgZ
wAewBbAAwAJzFaBcY3MSIAMwqtBkrDBpznYWEA7wGaBtaRDAtAC5CfAgRAEQqoAlwVAKwMZhCcCs
UGggRgIhszTdDxAxAFAPEANgdwswqyCJAYBzV6jQdGhCElB3qyAKsLQAbBIgR1C4pHJfuRgQALiG
AYC6h2K6h3L5uIJjYgqwMbC8cjIAvNPxBPBlbGyowbhQt/EBQP8PELRQACAlsbcBRWC5oL8mPwlQ
v0QMsb9TqUC/RGRn38AmwaDBJq7wv0R2AzCn6v+oz6nfqu+r/MdREfOsxRLj/6zRrt+v77D0yOfM
FLJFtzC/tHyy1E7gAaCnULM3NbPa77WQCNAc0LJBYsTwCYACIB+zsqchGZDEYBbgNjU44YYAIEh5
cASQq+E+s/+zc9Lg0C41ENE/0kq2cL3g/6iwCYDTD0OQs9oL470wx1H/ydMAUMpFDoHK5tVttKkO
8D3TIXMCIFMBDvAFoG1w2xXy0g5FAMADEFOnMkOQ/6bjStDDj8Sfxa/Gv8fPrUj/H9Gupn7QykV+
0MrWElCwf3+xhubi1WjWEs1zsjLSLFDvC2JO4LKBszc52OzUEtv/f90H0iwAcBXgAZBMoAIgIPeQ
oBLgkKBuvcCm4wwB4Q//4h/jL+Q/5U/mX8n/6H/pj//qn7KBAdDwD/Ef8iWEkO2E/wvw2yCn7/Sf
9a/2v6woPND/rO+t/9p/yx+xL7Iy/Y7Nzd/SDkxx12DyYe1qMtVRs/j+YtVv0krgEIpwBxCPsxWg
xZCgdpBRIHtV03ACoX+PpBQR3xEUYhWDNlAHQDjeN9sg0kkVg8/wOUmwbFDsM30eodMhd7cwH5At
cPUYg2g80Dg2UO7gtRC+UM9JAHFweBFQMGJqA1CRIL+0APng+hCy4adwu3Bl+kCdkDB6G1LBoN/Q
cmftMD0coWgDcb3AStDKsWd2/x15HDEFQO0wQ5AzIB3yHvXcOTgx4B1CHDB3HeQgwd1+0GreQpCg
VtFs8gAHEF/LkhtR4CDTIH7QdlAQd/pr7TBkOHAjYr2wA5AH0eN4EANwbHl0FQDtMBwQ/xqxJPcF
YN/QBJADcNTgMtD/hTARwCJAA1AiQJBRI7ECEP8lACRRAvDPQLehJPGQUZBA58JRIkBFYGtytZAc
EPIA/Smxd7iwkFGyUQZQBKAKgq/tML3CJ2HXYWZQEGy1Ee5kJuH0ULiwcDSgAvADUf9gwCmn0kKK
cPIQF+bu4YsyezLQAvBkAgKycXgQGyFu36eAkKAv0zBSCoIzM1Av0/HdgWNpZuAw4LAasxSQZxQB
BBAv4Wx2uQAzwXX+Y7LwM8K+8JBANFIjsZEg/HQ32cEEEG8ABxAzgQQQ4nSykGEgLhPUM9Z+0P80
coUwA0A07zX/Nw+6cQQQ37UQG3A4zznfOu9sUSAEEO8oYDiPPV8+ZSk3TFPAPC/3QR8+RRGAKElh
Qk80Axkh/z//RM9F30bvNDB14EgyNL//SZ9Kr0K9WUBIP03PTt9P7/80IVvwTM9Sb1N/VIUZMcGQ
/xkw7RMB3wLvA/8FD6wVWXL/iwHfKKyfB6/5xMqS+l8KX/8LbWfC7vKhcNny7TC3cF9KfwlPyaZ5
sLVQW5Dx0L3gOkdt42YPFmUgDQpZciBfae9my2vFZ59oqU/dUHC/NzBsT2bfbt9o9LcwMHCfx3Gv
cr9o5SBvZmwvdW/jdn9o1lJGQ3g/eU96X0Vo1jMPMDEsIAYwIHtWYYygc3wvfT9+T2jlOv9rxWvG
WXvgz1s/XE9dX15v/196+H/m6OgC57/7b/x9gM8/XztiJdsoYMBis2khXCf/GACAsZHfBtD6cIeQ
gd+ObbnnNSBBvlBhoPHQICxQL93iIfHecDPhIIggcyD+YqGxgEBXIXgAAQGngJsRb8NQmVGJgC3Q
cx2Q8kIs/5UPlx+YLnwSnU+WT55vmGo/m6IbkNdSrnGZ95qwTVX8U1SawaSRGMBZkdeQgBD8bW3X
kC3AgIAk8IRWoq87n4qp5i138Kg/mHpueXAgMnh4mfiJAPHRIGBJTlZJVKq/mHlF6fKBcXWaEHSg
T5K7jpr3lEQQsZTQNLCPoV9t2bPvf7X92xG277Uvgo+YaGkwScnx0G0giVIgdxIQznBzBZE+IHdo
rJCkYiHgb/54rJC9cNTwMCAOcN/wWlD/uI+5n7qvu7+mVplxrLJjAP+ZQpshK4E+IC3Q8hAxAZmd
Pi6gI7/vwP/CD7vtRG/7pbGkYGmasKcgrbGkYPIw38TcgACckKyQPrA0rMnJ7/G8KSB1cIlxaWCI
oM8P/7w4gAC+WNFPvCkgsb8fx8+/yN/Tz8NfxGaaB9DGP3fwf4Rs2O+8K8vxFMC8xCGwbvZmJtHE
YWLVoJtQpGK9cO9ZoKUCMQLHIVe+JdZf12//kp+Tr5S24w/kH9iv2b6Zu//nb+h/5P/mD7OW7M/t
3+m/r8/OzBHzv7wpKoCxYvFP//Jf82/Uj1ch8S/4v/nP+t//92D+z9JbvhDWEK1h4q/9H//uj++f
5u8Dr/3fAL/056y6/wevCL8FPwZP8N8Nfwl/Co//9Rj3fxIvEz8UT9pppzARTz8XHxgvGT8Af7wL
3JFBbPxzb4ABKvAa7xv/Dt8P7/2L4HKwMC7QAv8ivxzvH89fd9GbUMSjmZ6aoXengGz+PyafJ6+3
ry0/t/8tXygv6yk/vDhBzMEgWeCZQory+49girBogAB74n/CgEVp1f8yDzEfMi8uby9/I6+yT7NW
b5T/O4+iX6t+VMwCvUBl5nCAAOAwbWJaAOCRhyA/pGCbk0XQWQCAAMVQc3XvmgHMhYBE4GBsQL9C
z6j//0h/Qc9Jn5g9vpXWEsQGRrD/nKGnkJthpIGZvK2CRpCbcPotreNFTg+pT6nhsBWAAP9XwFDR
RiGZUVD6UvKsu+Fw+1FjWPFt4XDO51QfqcKsuv9Z35h5y9GtmK/3cIJL3z6fB7LfX59MvDc5ODYy
/jmEz4XThmrF0IcviD+JT1+KX4trd2GMbIyQMoZAa/2b8G6lAY13X+A0RV/ggzj/j1+QZm2ikS85
H91/dyy80P5krZDF0ZsRmnGk4Mvk4DF8Y2xpwJzR4CCtsaYxZHmcYHduxydyfzPPdQ8g/k7F4cWD
4NN5L2Ave04G7/99/3qPe5/LgFL4gY9+v3/P/xCfhi+C/4QPVceaiMxA/BD/nNHgkYmvir+Lz/UF
ZmHL8/OaYJyzICiPD4bfh++A1p5sJjqUH5B/kY8gQ+Ew/mPfwFhnpmGmVqUBl9+Uz7+V3yWvnW+Z
D5of9SMpxHD7zMHWIC6jT4yam2CtsSFQ/8xAUXJmMNxgWMFoMMVRNhL3avBnwAKxacxArXJQ8GY0
/62BqbF2/3gBzBF4o1Gg03Bz4BC+VGV2jqBpwDaYc/4/Oeuhz3OPpc/09kTQbVCaaxWwdr2w06Bt
dSUQ65KSaZB2bVBjxxDczK8P72OPoo+xr/UUUDZQafCboT5MvPC1v7bPsC89MX0AAb6AAAAAAwDe
P59OAAADAAlZAwAAAAMAQGUAAAAACwATgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADABWA
CCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMAG4AIIAYAAAAAAMAAAAAAAABGAAAAAFKFAAAb
lwEAAwAigAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAABAACOACCAGAAAAAADAAAAAAAAARgAA
AABghQAAAMwL8bz//x8LAEKACCAGAAAAAADAAAAAAAAARgAAAACChQAAAQAAAB4ASYAIIAYAAAAA
AMAAAAAAAABGAAAAAFSFAAABAAAABQAAADEwLjAAAAAACwB1gAggBgAAAAAAwAAAAAAAAEYAAAAA
BoUAAAAAAAALAHaACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMAd4AIIAYAAAAAAMAAAAAA
AABGAAAAABiFAAAAAAAAAgH4DwEAAAAQAAAApJXZchH21USXzyS9FTHHnwIB+g8BAAAAEAAAAKSV
2XIR9tVEl88kvRUxx58CAfsPAQAAAJYAAAAAAAAAOKG7EAXlEBqhuwgAKypWwgAAbXNwc3QuZGxs
AAAAAABOSVRB+b+4AQCqADfZbgAAAEM6XERvY3VtZW50cyBhbmQgU2V0dGluZ3NccGF0cmlja2xc
TG9jYWwgU2V0dGluZ3NcQXBwbGljYXRpb24gRGF0YVxNaWNyb3NvZnRcT3V0bG9va1xPdXRsb29r
LnBzdAAAAAMA/g8FAAAAAwANNP03AgACARQ0AQAAABAAAABOSVRB+b+4AQCqADfZbgAAAgF/AAEA
AAAxAAAAMDAwMDAwMDBBNDk1RDk3MjExRjZENTQ0OTdDRjI0QkQxNTMxQzc5RkM0MzEyQTAwAAAA
AAMABhCrXpJPAwAHELwDAAADABAQAAAAAAMAERAAAAAAHgAIEAEAAABlAAAAREVBUkFMTDpPTlAx
MTBPRlJGQzMyNjEsSVRTVEFURVM6IkFGVEVSQUZJTkFMUkVTUE9OU0VIQVNCRUVOU0VOVE9OVEhF
U0VSVkVSVFJBTlNBQ1RJT04sVEhFRk9MTE9XSU5HUgAAAAClVA==

------=_NextPart_000_001A_01C30335.D119E0F0--

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



From mailnull@www1.ietf.org  Mon Apr 14 22:08:44 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00396
	for <sip-archive@odin.ietf.org>; Mon, 14 Apr 2003 22:08:44 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3F2GcX11794
	for sip-archive@odin.ietf.org; Mon, 14 Apr 2003 22:16:38 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F2Ex811655;
	Mon, 14 Apr 2003 22:14:59 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F2A8811388
	for <sip@optimus.ietf.org>; Mon, 14 Apr 2003 22:10: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 WAA00253
	for <sip@ietf.org>; Mon, 14 Apr 2003 22:01:44 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195Fnz-0006py-00
	for sip@ietf.org; Mon, 14 Apr 2003 22:04:15 -0400
Received: from ipvpn069002.netvigator.com ([203.198.202.2] helo=mail.astri.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 195Fnp-0006pL-00
	for sip@ietf.org; Mon, 14 Apr 2003 22:04:07 -0400
Received: from patrickXP (Firewall [203.198.202.1])
	by mail.astri.org (8.11.6/8.11.2) with ESMTP id h3F26bm09533
	for <sip@ietf.org>; Tue, 15 Apr 2003 10:06:37 +0800
From: "Patrick Lam" <patrickl@astri.org>
To: <sip@ietf.org>
Date: Tue, 15 Apr 2003 10:05:57 +0800
Message-ID: <001d01c302f3$8db9d320$2306050a@patrickXP>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_001E_01C30336.9BDD1320"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-MS-TNEF-Correlator: 00000000A495D97211F6D54497CF24BD1531C79F24322A00
Subject: [Sip] What exactly is "response context"?
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_001E_01C30336.9BDD1320
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear all:

What exactly is "response context" being mentioned in RFC 3261 (p.107)?  =
Why
would a response context contain multiple responses (so that a proxy has =
to
choose the best one)?  Should there be only one appropriate response to =
be
forwarded by the proxy at any particular time?  For example, after =
receiving
a response downstream, the proxy would (at least for most cases) forward
this same response upstream, right?

I think I am missing some important concept about response context here.
Can someone please explain?

Thanks very much in advance.

Patrick Lam

------=_NextPart_000_001E_01C30336.9BDD1320
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Disposition: attachment;
	filename="winmail.dat"
Content-Transfer-Encoding: base64

eJ8+IjkCAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANMHBAAPAAoABQAAAAIA/gAB
A5AGAFQNAAAnAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB
AAAAJAAAAFdoYXQgZXhhY3RseSBpcyAicmVzcG9uc2UgY29udGV4dCI/AAIBcQABAAAAFgAAAAHD
AvONU9roaBr4Dk5ptlQP/syR8tsAAAIBHQwBAAAAGAAAAFNNVFA6UEFUUklDS0xAQVNUUkkuT1JH
AAsAAQ4AAAAAQAAGDgBuemvzAsMBAgEKDgEAAAAYAAAAAAAAAKSV2XIR9tVEl88kvRUxx5/CgAAA
AwAUDgAAAAALAB8OAQAAAAIBCRABAAAAFgkAABIJAAAuFgAATFpGdfAMERGDAAoAcmNwZzk1AUAM
dWMAUAEEc3RzaMEFcGJjaDE0DvQJAJsPcA7laA3gEEZiaQFDgQtgbmcxMDMzEabkZmUSIDI4AfcC
pANjRwIAD3AKwHNldALRcChycTIAACoKoW5vrRTgIBMQFjE2EjAwDjDONBaxAdAWoDR9B20Cg+8A
UAPUFI8Vm2IWcRbgFkI/G4QXYAcTGHQPoBQtMTMeNhnvFjMWoB+rfVBNoQuAZ0xpVRWCZgdAAQVA
t3Oy06n6xfzpfQKDHhIdLx4/H08gUhZAIJYYdDIc/zIzOEUj1CAHbSBDRSbFNU8nTxbQKH8phXly
JsU3XSKvNhjBK98DgkcJ0Wu3JsUoYS3+Mi8PKYRUCHB1JsU5MU83LcEynwOCKMhIZWIJcHcpGHQW
oP00nzcobzbGBxABoA3gN6bbGMEizTgjxTnPQiFhDeC/N7UyYS3+ElA9HzbkVgiQ6HRuYQeBZTem
JzEY/PcoSAcTKdczKnFDXSuXRNX9LTYzLcEY/C7YRNQweShS70iuMmZE1DPnMzSBSK01p39E1Dc8
FuBODzlHT6U66zTvGM882ETUPno0MmFIrkB2s0+lQg4yNiKfGdUgIJZ0IFcHkHQEkSEfIiQ0/zzi
Wk9AoyY3XCYCgAKRCOaqOwlvMGGvZSpgNWLa/2PxY69kuWLEZOJjT2cfZt3/Zl9kj2LfEvATIGyq
MRJtj/9umGLEMRJtH3DvcK1wL25f/XIkOTJgdXR20W7zdtACgqkPAHlsB5BoCeB0AAD6cQMhbBGB
BRABQBXgA/CwZGN0bAqxAGBzCrBHejAZcHpybnVtXNFhiHV0bwBgZGp1DwDxBRBnaHR5cQoBeUAK
AfJpAZBwMAOyJyER5xKo/FxrBJEgsTJgEBICshDC3wBgATIPYYChD5FjCcB58Hl+A25wflmCMhMg
AzBz+G5leBnAB7AFsADAAnO5FaBjcxIgAzB78GR9UJxpdhYQDvAZoG1pEMBzhSAJ8CBEARB7oF0B
UI0KwGEJwH1waCBGAiG7hFQPEDEAUA8QA2B3CzATfEABgHNXefB0aELvElB8QAqwhSBsEiA5UInE
vnKKOBAAiaYBgIunYoun8nKJomNiCrAjkI2SI+DjjfME8GVsbHnhiXCJEf8BQA8QhXAAIFzxiCE3
YIrAf5BGCVCQZAyxkHN6YJBkZL5nkUaSwJJGgBCQZHYDMP95Cnnvev98D30cmHER833l/xLjffF/
/4EPghSaB500g2V/iFCFnIP0QOABoHhwhFc134T6hrAI0Fngg2FilhAJgP8CIITSeEEZkJWAQGAo
QC2w8aEgSHlwBJB9ATCzhJP+NqE/JxCiX6Nqh5CPAHnQ/wmApC81kIT6C+OOUJhxmvP/AFCbZQ6B
nAamjYXJDvCkQZ5zAiBFAQ7wBaBtcBXy7aMuRQDAAxBTeFI1kGDTixWgYcB2AlEge1WkkP95wWDE
sfGjcbJCs2MoUBIwvDg3AFCjabNjoRA5O7BZFtAzfQqhpEF3iFA55xZwtlQPgDY4KFADMAFk514Q
AtFCMGJqAGAJ8IUg3xAgAgGEEA8gl4Blm1AFsM56uTKSwADAcmcLgZLAnmiWIY7gPNABQWd2u1nv
uhGX8AuANZAwDoG78LzV3Dk4D6C7IroQd7vEvqHdMmBqr2JhwBkhbBXgEgBfgbK5MXhQpEAyYHYI
kHf6awuAZCpwwUIE8AdAEvHzDuELUHl0suALgLnwuJH/wteYEADAl0CWIAxgGaBdAP+msMAgAGDA
IAJRwZF5MMLg/8IxlaACYIjBwtECUQAgk3HzwCA3YGtyhrC58BXgx5H+d4nQCTKDgH1wl1CBoguA
V47ixUGogWYIkGyGMWTnxMGVYInQcHXJgJgglhDvBzDHh6NiA2BvI5C11QMx9xmyGaCVoGR5IoOR
AUC5Af5ueKBhwM2zzjKBoiOwzaT9rqFjBpB4YA7wuJOycBWS8wCABZBsdoog0aEOYIQQv9GiAZAA
INIywZEJ8HQBwX/RoRlwEgDRYZbADNABkCD+LrG00bYyYNJSXQCV8NLP/9Pf1O+LkZbABYHWn9ev
2L9/0hAPoJbAxkDWb9s/3EUp39UsKnDaD97/3CViNyACkf/gL9HjtwHd3+Kv47/kz9IQ/y3A5hLS
n+d/6I/gnTlQ5h//66/sv+3P0gE0gOqv8E/xX//yZQr5lJx5z5Zvl398+Qqi/xmBo4h9v37PmtSb
sptvgX//go0YlTzQqwMLgIiQ/Sqr39+axp7ghnAKwcnhOhiGBBzRtEUgDQr8wiAHzwSr9wmlBX8G
iVcZcCGAg6C8MPn5QHkgGRAKDwSdAAUM6vMAkwcBXCe14A8vBK8Mr+8Gxb/Rr5DRwSCvYPbAg6Hv
Ew8QPxFPElg0F68UHxUv0QbFIGJlILEgOfD2wB5ph6Bh0A7g9/BSRkP+ID8wLuDx4xu/HM8d3wby
xHAu/nA3KT8fEA4g+Q7Qd2+GsM4A3JAWrhcj9ffSbYaxacLAufEjDx6Y6xamOhAoruAgiXAOQdyQ
+UCgb3gO0EkgOhD64CLf/wZ6ALDMoK+xiXCqkB8weEB+IB/hJPIhDyIfLD8GxVP/uhAlki4hYcAf
IS6hDsEf4f8HcMsQXmBAoFLAXGAl6CvB2zORuXF393EgAWIO0C4i+yskKtJuDtD5YT6hhrAHUf8+
oDnwLy8wPzFPBsUlAYeQ7wdgDnGvgHhwLAdwON857/86/wbF0RBgoCXhjuCFYB9S/9yQP28V/6+x
pvCy4PtRB0D8bSw9jz6fQn8etkcfBonvNtdI7x56JXQoDkF4cPmgP10QuXEfgK+gJuGmwXMpNzX2
KqEO8XNZQSXodXD3RMUl4PuCPwmvRd8Lz0uv/QbySU9ypJBWIVEQH4AO8P/LkNvxruBP8Tigr5CQ
AfbA7xcijuDIgAdwYiWAXRAl//XO4i4fEENekFRvBnpXgn80EifRpsEOYfeyWx8GiW7fUaZUD17P
oDDb0WsroI/h3w7QJ4AAsCAi+xB2y7CO4Ptg7waJLmAMUi9GSoSgK4C/kjBGb2S/BuOG8PthY1aQ
PkxREGcPaB9TT2bhfQABb9AAAAMA3j+fTgAAAwAJWQMAAAADAEBlAAAAAAsAE4AIIAYAAAAAAMAA
AAAAAABGAAAAAAOFAAAAAAAAAwAVgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADABuACCAG
AAAAAADAAAAAAAAARgAAAABShQAAG5cBAAMAIoAIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAA
QAAjgAggBgAAAAAAwAAAAAAAAEYAAAAAYIUAAADMC/G8//8fCwBCgAggBgAAAAAAwAAAAAAAAEYA
AAAAgoUAAAEAAAAeAEmACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAUAAAAxMC4wAAAAAAsA
dYAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAACwB2gAggBgAAAAAAwAAAAAAAAEYAAAAADoUA
AAAAAAADAHeACCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAAIB+A8BAAAAEAAAAKSV2XIR9tVE
l88kvRUxx58CAfoPAQAAABAAAACkldlyEfbVRJfPJL0VMcefAgH7DwEAAACWAAAAAAAAADihuxAF
5RAaobsIACsqVsIAAG1zcHN0LmRsbAAAAAAATklUQfm/uAEAqgA32W4AAABDOlxEb2N1bWVudHMg
YW5kIFNldHRpbmdzXHBhdHJpY2tsXExvY2FsIFNldHRpbmdzXEFwcGxpY2F0aW9uIERhdGFcTWlj
cm9zb2Z0XE91dGxvb2tcT3V0bG9vay5wc3QAAAADAP4PBQAAAAMADTT9NwIAAgEUNAEAAAAQAAAA
TklUQfm/uAEAqgA32W4AAAIBfwABAAAAMQAAADAwMDAwMDAwQTQ5NUQ5NzIxMUY2RDU0NDk3Q0Yy
NEJEMTUzMUM3OUYyNDMyMkEwMAAAAAADAAYQFX1cGQMABxDUAQAAAwAQEAAAAAADABEQAAAAAB4A
CBABAAAAZQAAAERFQVJBTEw6V0hBVEVYQUNUTFlJUyJSRVNQT05TRUNPTlRFWFQiQkVJTkdNRU5U
SU9ORURJTlJGQzMyNjEoUDEwNyk/V0hZV09VTERBUkVTUE9OU0VDT05URVhUQ09OVEFJTk0AAAAA
E7Q=

------=_NextPart_000_001E_01C30336.9BDD1320--

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



From mailnull@www1.ietf.org  Mon Apr 14 22:17:18 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00568
	for <sip-archive@odin.ietf.org>; Mon, 14 Apr 2003 22:17:18 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3F2PCH12123
	for sip-archive@odin.ietf.org; Mon, 14 Apr 2003 22:25:12 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F2N2812037;
	Mon, 14 Apr 2003 22:23:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F2In811876
	for <sip@optimus.ietf.org>; Mon, 14 Apr 2003 22:18: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 WAA00440
	for <sip@ietf.org>; Mon, 14 Apr 2003 22:10:25 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195FwO-0006tF-00
	for sip@ietf.org; Mon, 14 Apr 2003 22:12:56 -0400
Received: from david.siemens.com.cn ([194.138.202.3])
	by ietf-mx with esmtp (Exim 4.12)
	id 195FwN-0006tC-00
	for sip@ietf.org; Mon, 14 Apr 2003 22:12:55 -0400
X-Envelope-Sender-Is: zaifeng.chen@BISC.SIEMENS.COM.CN (at relayer david.siemens.com.cn)
Received: from ns.siemens.com.cn (ns.siemens.com.cn [194.138.237.52])
	by david.siemens.com.cn (8.11.6/8.11.6) with ESMTP id h3F2Cw423615
	for <sip@ietf.org>; Tue, 15 Apr 2003 10:12:59 +0800 (CST)
Received: from pekw096e.cn001.siemens.net ([140.231.51.134])
	by ns.siemens.com.cn (8.11.7/8.11.7) with ESMTP id h3F2Cpm19674
	for <sip@ietf.org>; Tue, 15 Apr 2003 10:12:52 +0800 (CST)
Received: by pekw096e.cn001.siemens.net with Internet Mail Service (5.5.2653.19)
	id <28WXDMJJ>; Tue, 15 Apr 2003 10:12:50 +0800
Message-ID: <23BCA2174A77D111A52D00A0C967A6E204201664@HP5>
From: "Chen Zaifeng,BISC TD DEW5(BJ)" <zaifeng.chen@BISC.SIEMENS.COM.CN>
To: "'Patrick Lam'" <patrickl@astri.org>, sip@ietf.org
Subject: ??: [Sip] Questions regarding Offer/Answer model...
Date: Tue, 15 Apr 2003 09:45:44 +0800
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>

See my understanding inline.

>  -----????-----
> ???: 	Patrick Lam [mailto:patrickl@astri.org] 
> ????:	Monday, April 14, 2003 1:09 PM
> ???:	sip@ietf.org
> ??:	[Sip] Questions regarding Offer/Answer model...
> 
> Dear all:
> 
> On p.80 of RFC 3261, it states that:
> 
> "> If the initial offer is in an INVITE, the answer MUST be in a reliable non-failure message from UAS back to UAC which is correlated to that INVITE.  For this specification, that is only the final 2xx response to that INVITE.  That same exact answer MAY also be placed in any provisional responses sent prior to the answer.  The UAC MUST treat the first session description it receives as the answer, and MUST ignore any session descriptions in subsequent responses to the initial INVITE.> "> 
> 
> My questions are:
> 1.	Is the answer from 1xx valid then???  If so, why does it state that the answer can only be present in 2xx on one hand, but on the other hand if the answer is present in 1xx, the answers from 2xx must be ignored??? 
[Chen Zaifeng,BISC TD DEW5(BJ)]  
1xx is valid, of course, and:
Firstly, the 2xx must contain an answer
Secondly, the 1xx non-reliable may contain an answer, but must be the same as the one in 2xx
Lastly, The UAC will accept the first answer which might in 2xx or 1xx (the same answer)
Therefore, I think the description picked out from rfc3261 has nothing to do with rfc3262 
> 2.	What about the UAS > "> changes> ">  its mind on the answer after it sends 1xx response (e.g. the callee answers the call from a different UA), and wants to incorporate the changes into 2xx responses????
[Chen Zaifeng,BISC TD DEW5(BJ)]
UAS can not changes its mind...
P80 of RFC 3261:
 o  Once the UAS has sent or received an answer to the initial
     offer, it MUST NOT generate subsequent offers in any responses
     to the initial INVITE.  This means that a UAS based on this
     specification alone can never generate subsequent offers until
     completion of the initial transaction.
> 3.	Can 100 Trying carry > '> answers> "> ?
[Chen Zaifeng,BISC TD DEW5(BJ)]  
I think it can not.
100 trying is an unreliable "automatic response" that is generated  by transaction layer,
it might not be aware of session description which provided by TU, check 17.2.1 of rfc3261
for more.
And, P183, 21.1.1 of rfc3261:
The 100 (Trying) response is different from other provisional responses, in that it is never
forwarded upstream by a stateful proxy.
 
> Thanks very much in advance,
> 
> Patrick
> 
> 
> 
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Mon Apr 14 22:45:02 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01101
	for <sip-archive@odin.ietf.org>; Mon, 14 Apr 2003 22:45:02 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3F2qv213927
	for sip-archive@odin.ietf.org; Mon, 14 Apr 2003 22:52:57 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F2qF813891;
	Mon, 14 Apr 2003 22:52:15 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F2lK813738
	for <sip@optimus.ietf.org>; Mon, 14 Apr 2003 22:47:20 -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 WAA00906
	for <sip@ietf.org>; Mon, 14 Apr 2003 22:38:55 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195GNz-0006zp-00
	for sip@ietf.org; Mon, 14 Apr 2003 22:41:27 -0400
Received: from [61.144.161.2] (helo=mta1)
	by ietf-mx with esmtp (Exim 4.12)
	id 195GNw-0006zk-00
	for sip@ietf.org; Mon, 14 Apr 2003 22:41:25 -0400
Received: from Natarajucl1127 (mta1 [172.17.1.60])
 by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26
 2002)) with ESMTPA id <0HDD006MS5WNR1@mta1.huawei.com> for sip@ietf.org; Tue,
 15 Apr 2003 10:36:27 +0800 (CST)
Date: Tue, 15 Apr 2003 08:10:37 +0530
From: "Nataraju A.B." <natarajuab@huawei.com>
Subject: Re: [Sip] Questions regarding Offer/Answer model...
To: "Chen Zaifeng,BISC TD DEW5(BJ)" <zaifeng.chen@BISC.SIEMENS.COM.CN>,
        "'Patrick Lam'" <patrickl@astri.org>, sip@ietf.org
Message-id: <002101c302f8$66819860$5d02120a@in.huawei.com>
Organization: HTIPL
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
Content-type: multipart/alternative;
 boundary="Boundary_(ID_PW0IFqr2uJw08fIbBXt0sA)"
X-Priority: 3
X-MSMail-priority: Normal
References: <23BCA2174A77D111A52D00A0C967A6E204201664@HP5>
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-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_PW0IFqr2uJw08fIbBXt0sA)
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7BIT

The comments inline...
  ----- Original Message ----- 
  From: Chen Zaifeng,BISC TD DEW5(BJ) 
  To: 'Patrick Lam' ; sip@ietf.org 
  Sent: Tuesday, April 15, 2003 7:15 AM
  Subject: ??: [Sip] Questions regarding Offer/Answer model...


  See my understanding inline.

  >  -----????-----
  > ???: Patrick Lam [mailto:patrickl@astri.org] 
  > ????: Monday, April 14, 2003 1:09 PM
  > ???: sip@ietf.org
  > ??: [Sip] Questions regarding Offer/Answer model...
  > 
  > Dear all:
  > 
  > On p.80 of RFC 3261, it states that:
  > 
  > "> If the initial offer is in an INVITE, the answer MUST be in a reliable non-failure message from UAS back to UAC which is correlated to that INVITE.  For this specification, that is only the final 2xx response to that INVITE.  That same exact answer MAY also be placed in any provisional responses sent prior to the answer.  The UAC MUST treat the first session description it receives as the answer, and MUST ignore any session descriptions in subsequent responses to the initial INVITE.> "> 
  > 
  > My questions are:
  > 1. Is the answer from 1xx valid then???  If so, why does it state that the answer can only be present in 2xx on one hand, but on the other hand if the answer is present in 1xx, the answers from 2xx must be ignored??? 
  [Chen Zaifeng,BISC TD DEW5(BJ)]  
  1xx is valid, of course, and:
  Firstly, the 2xx must contain an answer
  Secondly, the 1xx non-reliable may contain an answer, but must be the same as the one in 2xx
  Lastly, The UAC will accept the first answer which might in 2xx or 1xx (the same answer)
  Therefore, I think the description picked out from rfc3261 has nothing to do with rfc3262 

  [Nataraju A.B.]
  The SDP parameters carried in the 1xx response should be same as that could be carried in teh 2xx response. since SDP parameters to be sent back is same in both the states. This also can be justified by the fact that the SDP parameters are all preconfigured one's. The same info is available when UAS is replying back with alerting indication(180 RINGING ) OR connect request(200 OK)


  > 2. What about the UAS > "> changes> ">  its mind on the answer after it sends 1xx response (e.g. the callee answers the call from a different UA), and wants to incorporate the changes into 2xx responses????
  [Chen Zaifeng,BISC TD DEW5(BJ)]
  UAS can not changes its mind...
  P80 of RFC 3261:
   o  Once the UAS has sent or received an answer to the initial
       offer, it MUST NOT generate subsequent offers in any responses
       to the initial INVITE.  This means that a UAS based on this
       specification alone can never generate subsequent offers until
       completion of the initial transaction.

  [Nataraju A.B.]
  Chen Zaifeng's comments are correct, since the information available in TU will be same in both the alerting indication (180 RINGING ) state as well as connect request(200 OK)

  > 3. Can 100 Trying carry > '> answers> "> ?
  [Chen Zaifeng,BISC TD DEW5(BJ)]  
  I think it can not.
  100 trying is an unreliable "automatic response" that is generated  by transaction layer,
  it might not be aware of session description which provided by TU, check 17.2.1 of rfc3261
  for more.
  And, P183, 21.1.1 of rfc3261:
  The 100 (Trying) response is different from other provisional responses, in that it is never
  forwarded upstream by a stateful proxy.
   
  > Thanks very much in advance,
  > 
  > Patrick
  > 
  > 
  > 
  > 
  _______________________________________________
  Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
  This list is for NEW development of the core SIP 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_PW0IFqr2uJw08fIbBXt0sA)
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: #000080; FONT-FAMILY: Times New Roman" bgColor=#ffffff>
<DIV>The comments inline...</DIV>
<BLOCKQUOTE 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000080 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=zaifeng.chen@BISC.SIEMENS.COM.CN 
  href="mailto:zaifeng.chen@BISC.SIEMENS.COM.CN">Chen Zaifeng,BISC TD 
  DEW5(BJ)</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>To:</B> <A title=patrickl@astri.org 
  href="mailto:patrickl@astri.org">'Patrick Lam'</A> ; <A title=sip@ietf.org 
  href="mailto:sip@ietf.org">sip@ietf.org</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Sent:</B> Tuesday, April 15, 2003 7:15 
  AM</DIV>
  <DIV style="FONT: 10pt arial"><B>Subject:</B> ??: [Sip] Questions regarding 
  Offer/Answer model...</DIV>
  <DIV><BR></DIV>
  <DIV>See my understanding inline.<BR><BR>&gt;&nbsp; -----????-----<BR>&gt; 
  ???: Patrick Lam [mailto:patrickl@astri.org] <BR>&gt; ????: Monday, April 14, 
  2003 1:09 PM<BR>&gt; ???: <A 
  href="mailto:sip@ietf.org">sip@ietf.org</A><BR>&gt; ??: [Sip] Questions 
  regarding Offer/Answer model...<BR>&gt; <BR>&gt; Dear all:<BR>&gt; <BR>&gt; On 
  p.80 of RFC 3261, it states that:<BR>&gt; <BR>&gt; "&gt; If the initial offer 
  is in an INVITE, the answer MUST be in a reliable non-failure message from UAS 
  back to UAC which is correlated to that INVITE.&nbsp; For this specification, 
  that is only the final 2xx response to that INVITE.&nbsp; That same exact 
  answer MAY also be placed in any provisional responses sent prior to the 
  answer.&nbsp; The UAC MUST treat the first session description it receives as 
  the answer, and MUST ignore any session descriptions in subsequent responses 
  to the initial INVITE.&gt; "&gt; <BR>&gt; <BR>&gt; My questions are:<BR>&gt; 
  1. Is the answer from 1xx valid then???&nbsp; If so, why does it state that 
  the answer can only be present in 2xx on one hand, but on the other hand if 
  the answer is present in 1xx, the answers from 2xx must be ignored??? 
  <BR>[Chen Zaifeng,BISC TD DEW5(BJ)]&nbsp; <BR>1xx is valid, of course, 
  and:<BR>Firstly, the 2xx must contain an answer<BR>Secondly, the 1xx 
  non-reliable may contain an answer, but must be the same as the one in 
  2xx<BR>Lastly, The UAC will accept the first answer which might in 2xx or 1xx 
  (the same answer)<BR>Therefore, I think the description picked out from 
  rfc3261 has nothing to do with rfc3262 </DIV>
  <DIV>&nbsp;</DIV>
  <DIV>[Nataraju A.B.]</DIV>
  <DIV>The SDP parameters carried in the 1xx response should be same as that 
  could be carried in teh 2xx response. since SDP parameters to be sent back is 
  same in both the states. This also can be justified by the fact that the SDP 
  parameters are all preconfigured one's. The same info is available when UAS is 
  replying back with alerting indication(180 RINGING ) OR connect request(200 
  OK)</DIV>
  <DIV>&nbsp;</DIV>
  <DIV><BR>&gt; 2. What about the UAS &gt; "&gt; changes&gt; "&gt;&nbsp; its 
  mind on the answer after it sends 1xx response (e.g. the callee answers the 
  call from a different UA), and wants to incorporate the changes into 2xx 
  responses????<BR>[Chen Zaifeng,BISC TD DEW5(BJ)]<BR>UAS can not changes its 
  mind...<BR>P80 of RFC 3261:<BR>&nbsp;o&nbsp; Once the UAS has sent or received 
  an answer to the initial<BR>&nbsp;&nbsp;&nbsp;&nbsp; offer, it MUST NOT 
  generate subsequent offers in any responses<BR>&nbsp;&nbsp;&nbsp;&nbsp; to the 
  initial INVITE.&nbsp; This means that a UAS based on 
  this<BR>&nbsp;&nbsp;&nbsp;&nbsp; specification alone can never generate 
  subsequent offers until<BR>&nbsp;&nbsp;&nbsp;&nbsp; completion of the initial 
  transaction.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>[Nataraju A.B.]</DIV>
  <DIV>Chen Zaifeng's comments are correct, since the information available in 
  TU will be same in both the alerting indication (180 RINGING ) state as well 
  as connect request(200 OK)</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&gt; 3. Can 100 Trying carry &gt; '&gt; answers&gt; "&gt; ?<BR>[Chen 
  Zaifeng,BISC TD DEW5(BJ)]&nbsp; <BR>I think it can not.<BR>100 trying is an 
  unreliable "automatic response" that is generated&nbsp; by transaction 
  layer,<BR>it might not be aware of session description which provided by TU, 
  check 17.2.1 of rfc3261<BR>for more.<BR>And, P183, 21.1.1 of rfc3261:<BR>The 
  100 (Trying) response is different from other provisional responses, in that 
  it is never<BR>forwarded upstream by a stateful proxy.<BR>&nbsp;<BR>&gt; 
  Thanks very much in advance,<BR>&gt; <BR>&gt; Patrick<BR>&gt; <BR>&gt; 
  <BR>&gt; <BR>&gt; <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></BODY></HTML>

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



From mailnull@www1.ietf.org  Mon Apr 14 23:13:38 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01550
	for <sip-archive@odin.ietf.org>; Mon, 14 Apr 2003 23:13:38 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3F3LXG15750
	for sip-archive@odin.ietf.org; Mon, 14 Apr 2003 23:21:33 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F3Ku815722;
	Mon, 14 Apr 2003 23:20:56 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F3FF815592
	for <sip@optimus.ietf.org>; Mon, 14 Apr 2003 23:15: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 XAA01515
	for <sip@ietf.org>; Mon, 14 Apr 2003 23:06:49 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195Goz-00078f-00
	for sip@ietf.org; Mon, 14 Apr 2003 23:09:21 -0400
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 195Goy-00078c-00
	for sip@ietf.org; Mon, 14 Apr 2003 23:09:20 -0400
Received: from dynamicsoft.com ([63.113.46.85])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h3F38iBd017581;
	Mon, 14 Apr 2003 23:08:48 -0400 (EDT)
Message-ID: <3E9B77B6.8010807@dynamicsoft.com>
Date: Mon, 14 Apr 2003 23:08:38 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
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: Patrick Lam <patrickl@astri.org>
CC: sip@ietf.org
Subject: Re: [Sip] What exactly is "response context"?
References: <001d01c302f3$8db9d320$2306050a@patrickXP>
In-Reply-To: <001d01c302f3$8db9d320$2306050a@patrickXP>
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

It is defined in section 16.6:

>   A stateful proxy must have a mechanism to maintain the target set as
>    responses are received and associate the responses to each forwarded
>    request with the original request.  For the purposes of this model,
>    this mechanism is a "response context" created by the proxy layer
>    before forwarding the first request.

When a proxy forks, it will get responses for each forked response. 
Those are held in the response context.

-Jonathan R.

Patrick Lam wrote:
> Dear all:
> 
> What exactly is "response context" being mentioned in RFC 3261 (p.107)?
> Why would a response context contain multiple responses (so that a proxy
> has to choose the best one)?  Should there be only one appropriate
> response to be forwarded by the proxy at any particular time?  For
> example, after receiving a response downstream, the proxy would (at
> least for most cases) forward this same response upstream, right?
> 
> I think I am missing some important concept about response context here.
> Can someone please explain?
> 
> Thanks very much in advance.
> 
> Patrick Lam
> 

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             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 mailnull@www1.ietf.org  Mon Apr 14 23:17:41 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01642
	for <sip-archive@odin.ietf.org>; Mon, 14 Apr 2003 23:17:41 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3F3PbQ15904
	for sip-archive@odin.ietf.org; Mon, 14 Apr 2003 23:25:37 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F3P5815894;
	Mon, 14 Apr 2003 23:25:05 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F3Ib815653
	for <sip@optimus.ietf.org>; Mon, 14 Apr 2003 23:18: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 XAA01526
	for <sip@ietf.org>; Mon, 14 Apr 2003 23:10:11 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195GsE-00078u-00
	for sip@ietf.org; Mon, 14 Apr 2003 23:12:42 -0400
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 195GsE-00078r-00
	for sip@ietf.org; Mon, 14 Apr 2003 23:12:42 -0400
Received: from dynamicsoft.com ([63.113.46.85])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h3F3CLBd017584;
	Mon, 14 Apr 2003 23:12:22 -0400 (EDT)
Message-ID: <3E9B788F.2040004@dynamicsoft.com>
Date: Mon, 14 Apr 2003 23:12:15 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
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: Dean Willis <dwillis@dynamicsoft.com>
CC: sip@ietf.org
Subject: Re: [Sip] Question on Service Route Discovery draft and multiple
 contacts per AoR
References: <003301c302b6$08e9f680$40f30a0a@txdwillis>
In-Reply-To: <003301c302b6$08e9f680$40f30a0a@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

inline.

Dean Willis wrote:
> 
> The current text in draft-ietf-sip-scvrtdisco-03.txt says, in "6.3
> Procedures at the Registrar":
> 
>    A REGISTER operation performing a Fetching Bindings (i.e.  no Contact
>    header field is present in the request) SHOULD return the same value
>    of Service-Route as returned in the corresponding previous REGISTER
>    response for the address-of-record in question.  In some cases, the
>    Service-Route may be dynamically calculated by the registrar rather
>    than stored, and the decision as to whether this route should be
>    recalculated in the event of a Fetching Bindings operation is left to
>    the implementation.
> 
> 
> Ben Jenkins pointed out to me that this may be unclear in cases where there
> are multiple contacts registered for a specific AoR.
> 
> We do not state explicitly that the Service Route is common to all contacts
> for the AoR. Is it really? Do we need to add anything here for clarity?

I would be surprised if its the same. After all, the Contacts could have 
been registered from completely different visited networks. Ideally, 
there is one service route per contact, and so the REGISTER response 
would indicate a service route for each contact in the response. That 
would be a big change from whats in the spec now though.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             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 mailnull@www1.ietf.org  Tue Apr 15 00:45:16 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03565
	for <sip-archive@odin.ietf.org>; Tue, 15 Apr 2003 00:45:16 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3F4rEJ21374
	for sip-archive@odin.ietf.org; Tue, 15 Apr 2003 00:53:14 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F4qW821307;
	Tue, 15 Apr 2003 00:52:32 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F4kA821056
	for <sip@optimus.ietf.org>; Tue, 15 Apr 2003 00:46:10 -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 AAA03429
	for <sip@ietf.org>; Tue, 15 Apr 2003 00:37:42 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195IEw-0007XO-00
	for sip@ietf.org; Tue, 15 Apr 2003 00:40:14 -0400
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 195IEv-0007XG-00
	for sip@ietf.org; Tue, 15 Apr 2003 00:40:13 -0400
Received: from dynamicsoft.com ([63.113.46.85])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h3F4dpBd017605;
	Tue, 15 Apr 2003 00:39:51 -0400 (EDT)
Message-ID: <3E9B8D12.6060209@dynamicsoft.com>
Date: Tue, 15 Apr 2003 00:39:46 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
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: "Drage, Keith (Keith)" <drage@lucent.com>
CC: "'Gonzalo Camarillo'" <Gonzalo.Camarillo@lmf.ericsson.se>,
        "'sip@ietf.org'" <sip@ietf.org>,
        "'jari.arkko@ericsson.com'" <jari.arkko@ericsson.com>,
        "'vesa.torvinen@ericsson.fi'" <vesa.torvinen@lmf.ericsson.se>,
        "'Gonzalo.Camarillo@ericsson.com'" <Gonzalo.Camarillo@ericsson.com>,
        "'aki.niemi@nokia.com'" <aki.niemi@nokia.com>,
        "'tao.haukka@nokia.com'" <tao.haukka@nokia.com>
Subject: Re: [Sip] Re: Some comments on RFC 3329 (Security Mechanism Agree
 ment for the S	ession Initiation Protocol)
References: <475FF955A05DD411980D00508B6D5FB00439ECAC@en0033exch001u.uk.lucent.com>
In-Reply-To: <475FF955A05DD411980D00508B6D5FB00439ECAC@en0033exch001u.uk.lucent.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit



Drage, Keith (Keith) wrote:
> For the Require header, I was arguing for nothing more than a general
> case of that used in sec-agree, i.e. that the proxy must contain the
> application reflected by the option-tag in the Require header before
> that specific option-tag can be removed. I would not envisage any
> removal of any other option-tag.

Really, the problem is that sec-agree needs a new type of Require 
header, which is "Next-Hop-Require". It means that the recipient of a 
request with this header must understand the extension, and if it does, 
remove that header, else reject the request. Of course, you can't 
introduce the Next-Hop-Require header field as an extension without 
using Proxy-Require and Require in the request, which sort of brings you 
back to square one.

I must admit I am not fond of the idea of a proxy removing a Require 
header under any circumstances, but I don't see a better solution given 
that this needs to be introduced in a backwards compatible way. In that 
case, Keith's suggested semantics seem right. I'll make a note in 
bugzilla about it.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             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 mailnull@www1.ietf.org  Tue Apr 15 00:49:33 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03612
	for <sip-archive@odin.ietf.org>; Tue, 15 Apr 2003 00:49:33 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3F4vVj21572
	for sip-archive@odin.ietf.org; Tue, 15 Apr 2003 00:57:31 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F4uu821537;
	Tue, 15 Apr 2003 00:56:56 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F4qa821310
	for <sip@optimus.ietf.org>; Tue, 15 Apr 2003 00:52:36 -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 AAA03542
	for <sip@ietf.org>; Tue, 15 Apr 2003 00:44:08 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195ILA-0007Yn-00
	for sip@ietf.org; Tue, 15 Apr 2003 00:46:40 -0400
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 195IL9-0007Yk-00
	for sip@ietf.org; Tue, 15 Apr 2003 00:46:39 -0400
Received: from dynamicsoft.com ([63.113.46.85])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h3F4kGBd017608;
	Tue, 15 Apr 2003 00:46:16 -0400 (EDT)
Message-ID: <3E9B8E93.4010202@dynamicsoft.com>
Date: Tue, 15 Apr 2003 00:46:11 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
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: Patrick Lam <patrickl@astri.org>
CC: sip@ietf.org
Subject: Re: [Sip] How is the NAT/Firewall solution status right now?
References: <003001c2ff3a$faedf500$2306050a@patrickXP>
In-Reply-To: <003001c2ff3a$faedf500$2306050a@patrickXP>
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.

Patrick Lam wrote:
> Dear all:
> 
> I lost track of this a little while ago.  How is the status for
> NAT/Firewall solution for SIP currently?  

There are many solutions. draft-ietf-sipping-nat-scenarios describes 
some of them. The net/net from that draft is that its all a big mess, 
with differing solutions in differing cases. TO deal with that, I have 
recently proposed a unifying mechanism called ICE:

http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-ice-00.txt

> 
> Is MIDCOM still the best one right now?

MIDCOM is still unspecified. But, if/when it arrives, it won't cover 
many cases. It has the fundamental problem that it requires the agent to 
know the precise location of the firewalls/nats on the media path. This 
is pretty much a show-stopper in a lot of topologies. For example, in 
the case where you have a nat in your house, which your PC can control 
with midcom, there still may be a nat on the cable provider network, 
which you will not know about. Protocols like STUN and TURN (both of 
which are used by ICE) don't have this kind of limitation.

The long term right-answer is based on nsis, when all of the 
firewalls/nats support it. But thats a long ways off.

> 
> Actually, why does the SIP community not like the idea of opening a
> particular public address (at the firewall) for an ALG, and let all the
> traffic (heading any port) through to it?  I have asked many security
> experts, it seems like as long as I close the corresponding sockets on
> the ALG after the RTP sessions, allowing traffic to flow through the
> firewall (toward the closed socket) should not cause much threat.  

It is not unreasonable, and there are products on the market that 
basically work like this. This kind of approach has the benefit compared 
to midcom of not requiring firewall changes per se. However, it does 
require the deployment of some kind of box which will act as a media 
relay. That increases overall cost and introduces requirements for more 
bandwidth in the DMZ to handle the relay. This relay can be a b2bua or a 
TURN server or equivalent.

Note that, with ICE, the traffic through this relay can be substantially 
reduced, using it only for calls that actually end up going to endpoints 
outside the firewall.

> 
> What is the current best solution for the NAT/firewall problem right
> now?

Well, if you want my biased opinion, it is STUN and TURN in conjunction 
with ICE. I owe the wg a draft that describes how this optimally handles 
all of the cases in draft-ietf-sipping-nat-scenarios with a single 
client-side mechanism.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             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 mailnull@www1.ietf.org  Tue Apr 15 01:09:21 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03899
	for <sip-archive@odin.ietf.org>; Tue, 15 Apr 2003 01:09:21 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3F5HKG23016
	for sip-archive@odin.ietf.org; Tue, 15 Apr 2003 01:17:20 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F5GF822933;
	Tue, 15 Apr 2003 01:16:15 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F5Bv822820
	for <sip@optimus.ietf.org>; Tue, 15 Apr 2003 01: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 BAA03802
	for <sip@ietf.org>; Tue, 15 Apr 2003 01:03:28 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195Ids-0007cS-00
	for sip@ietf.org; Tue, 15 Apr 2003 01:06:00 -0400
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 195Idr-0007cG-00
	for sip@ietf.org; Tue, 15 Apr 2003 01:05:59 -0400
Received: from dynamicsoft.com ([63.113.46.85])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h3F55dBd017616;
	Tue, 15 Apr 2003 01:05:39 -0400 (EDT)
Message-ID: <3E9B931E.2000704@dynamicsoft.com>
Date: Tue, 15 Apr 2003 01:05:34 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
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: Jay Morris <jay_m_morris@yahoo.com>
CC: sip@ietf.org
Subject: Re: [Sip] day in Date header -  two different definitions in RFC
 3261
References: <20030406092625.80351.qmail@web20511.mail.yahoo.com>
In-Reply-To: <20030406092625.80351.qmail@web20511.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



Jay Morris wrote:
> Hi
> 
> in RFC 3261 I found two different definitions for DATE header, and I 
> don't know which one is the correct one:
> 
> In chapter 25.1 - the DATE header must have the wkday parameter. (e.g. 
> Date: Sat, 13 Nov 2010 23:29:00 GMT)

The BNF is authoritative, so this is correct.

> 
> In chapter 20.17, however, I found that "Unlike HTTP/1.1,   SIP only 
> supports the most recent RFC 1123 [20] format for dates."
> 
> well, according to this definition, the wkday parameter is optional.

I admit this text is confusing. You need to also look at http 1.1, which 
explicitly says it supports a fixed-length subset of the 1123 format. 
What this text was meant to say is that we ONLY use this fixed length 
1123 subset, as opposed to the other date formats supported in HTTP 1.1. 
Anyway, I will log this as a bug to just remove the sentence.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             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 mailnull@www1.ietf.org  Tue Apr 15 01:15:09 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04035
	for <sip-archive@odin.ietf.org>; Tue, 15 Apr 2003 01:15:09 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3F5N8423370
	for sip-archive@odin.ietf.org; Tue, 15 Apr 2003 01:23:08 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F5M8823227;
	Tue, 15 Apr 2003 01:22:08 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F5DB822869
	for <sip@optimus.ietf.org>; Tue, 15 Apr 2003 01:13: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 BAA03850
	for <sip@ietf.org>; Tue, 15 Apr 2003 01:04:42 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195If4-0007dM-00
	for sip@ietf.org; Tue, 15 Apr 2003 01:07:14 -0400
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 195If4-0007dJ-00
	for sip@ietf.org; Tue, 15 Apr 2003 01:07:14 -0400
Received: from dynamicsoft.com ([63.113.46.85])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h3F56hBd017619;
	Tue, 15 Apr 2003 01:06:43 -0400 (EDT)
Message-ID: <3E9B935F.2010308@dynamicsoft.com>
Date: Tue, 15 Apr 2003 01:06:39 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
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: Jay Morris <jay_m_morris@yahoo.com>
CC: vkenneally@cit.ie, sip@ietf.org
Subject: Re: [Sip] Registration Query
References: <20030406071304.28704.qmail@web20510.mail.yahoo.com>
In-Reply-To: <20030406071304.28704.qmail@web20510.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



Jay Morris wrote:
> Hi,
> 
> 1. I am looking at the pdf version and the section numbering is 
> different. I was under the impression I can use the pdf safely. I guess 
> I was wrong. Do you know where I can find a pdf version with the correct 
> numbering.

Don't use the PDF. Its not official. Use the .txt.

> 
> 2. The section still does not say if the from-tag should remain the same 
> or not.
> For dialogs the answer should be yes but I'm not sure about registrations.

Here is the text from 8.1.3.5:

In all of the above cases, the request is retried by creating a new
    request with the appropriate modifications.  This new request
    constitutes a new transaction and SHOULD have the same value of the
    Call-ID, To, and From of the previous request, but the CSeq should
    contain a new sequence number that is one higher than the previous.

Since the tag is part of the value of the From header field, this means 
that the tag remains the same.

-Jonathan R.


> 
> Jay.
> 
>  */Jonathan Rosenberg <jdrosen@dynamicsoft.com>/* wrote:
> 
>     Page 45 of RFC 3261.
> 
>     -Jonathan R.
> 
>     Jay Morris wrote:
>      > Hi,
>      >
>      > I can't find section 8.1.3.5 in the standard. Where is it?
>      >
>      > Thanks,
>      >
>      > Jay.
>      >
>      > */Jonathan Rosenberg /* wrote:
>      >
>      >
>      >
>      > Valerie Kenneally wrote:
>      > > Hi all,
>      > >
>      > > Assume a User Agent is registering with a SIP Server. The SIP
>     Server
>      > > challenges the User Agent with regard to Authorization. The User
>      > Agent
>      > > replies with the appropriate information. My question-when the
>      > User Agent
>      > > responds to the challenge will the Call-ID and From tag or this
>      > message be
>      > > the same as the first REGISTER message sent? All info greatly
>      > accepted!
>      >
>      > Yes. Section 8.1.3.5 addresses this case:
>      >
>      >! > In all of the above cases, the request is retried by creating
>     a new
>      > > request with the appropriate modifications. This new request
>      > > constitutes a new transaction and SHOULD have the same value of the
>      > > Call-ID, To, and From of the previous request, but the CSeq should
>      > > contain a new sequence number that is one higher than the previous.
>      > >
>      > > !
>      > >
>      > > Rosenberg, et. al. Standards Track [Page 45]
>      > >
>      > > RFC 3261 SIP: Session Initiation Protocol June 2002
>      > >
>      > >
>      > > With other 4xx responses, including those yet to be defined, a
>     retry
>      > > may or may not be possible depending on the method and the use
>     case.
>      >
>      >
>      > -Jonathan R.
>      > --
>      > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
>      > Chief Scientist Parsippany, NJ 07054-2711
>      > dynamicsoft
>      > jdrosen@dynamicsoft.com FAX: (973) 952-5050
>     &! gt; 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
>      >
>      >
>      >
>     ------------------------------------------------------------------------
>      > Do you Yahoo!?
>      > Yahoo! Tax Center
>      > - File
>      > online, calculators, forms, and more
> 
>     -- 
>     Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
>     Chief Scientist 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/mai! lman/listinfo/sip
>     This list is for NEW development of the core SIP Protocol
>     Use sip-implementors@cs.columbia.edu for questions on current sip
>     Use sipping@ietf.org for new developments on the application of sip
> 
> 
> ------------------------------------------------------------------------
> Do you Yahoo!?
> Yahoo! Tax Center 
> <http://us.rd.yahoo.com/finance/mailsig/*http://tax.yahoo.com> - File 
> online, calculators, forms, and more

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             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 mailnull@www1.ietf.org  Tue Apr 15 02:01:57 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06193
	for <sip-archive@odin.ietf.org>; Tue, 15 Apr 2003 02:01:57 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3F69vh31390
	for sip-archive@odin.ietf.org; Tue, 15 Apr 2003 02:09:57 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F69P831253;
	Tue, 15 Apr 2003 02:09:25 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F633826255
	for <sip@optimus.ietf.org>; Tue, 15 Apr 2003 02:03: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 BAA04541
	for <sip@ietf.org>; Tue, 15 Apr 2003 01:54:32 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195JRJ-00002R-00
	for sip@ietf.org; Tue, 15 Apr 2003 01:57:05 -0400
Received: from web20511.mail.yahoo.com ([216.136.175.150])
	by ietf-mx with smtp (Exim 4.12)
	id 195JRI-00002O-00
	for sip@ietf.org; Tue, 15 Apr 2003 01:57:04 -0400
Message-ID: <20030415055710.23993.qmail@web20511.mail.yahoo.com>
Received: from [212.143.185.30] by web20511.mail.yahoo.com via HTTP; Mon, 14 Apr 2003 22:57:10 PDT
Date: Mon, 14 Apr 2003 22:57:10 -0700 (PDT)
From: Jay Morris <jay_m_morris@yahoo.com>
Subject: Re: [Sip] Registration Query
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: vkenneally@cit.ie, sip@ietf.org
In-Reply-To: <3E9B935F.2010308@dynamicsoft.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-758496772-1050386230=:23142"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-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-758496772-1050386230=:23142
Content-Type: text/plain; charset=us-ascii

Thanks for your response.I also saw this paragraph but was confused since in the draft-ietf-sipping-basic-call-flows-02.txt the From tags are different.Jay.  Jonathan Rosenberg <jdrosen@dynamicsoft.com> wrote:

Jay Morris wrote:
> Hi,
> 
> 1. I am looking at the pdf version and the section numbering is 
> different. I was under the impression I can use the pdf safely. I guess 
> I was wrong. Do you know where I can find a pdf version with the correct 
> numbering.

Don't use the PDF. Its not official. Use the .txt.

> 
> 2. The section still does not say if the from-tag should remain the same 
> or not.
> For dialogs the answer should be yes but I'm not sure about registrations.

Here is the text from 8.1.3.5:

In all of the above cases, the request is retried by creating a new
request with the appropriate modifications. This new request
constitutes a new transaction and SHOULD have the same value of the
Call-ID, To, and From of the previous request, but the CSeq should
contain a new sequence number that is one higher than the previous.

Since the tag is part of the value of the From header field, this means 
that the tag remains the same.

-Jonathan R.


> 
> Jay.
> 
> */Jonathan Rosenberg /* wrote:
> 
> Page 45 of RFC 3261.
> 
> -Jonathan R.
> 
> Jay Morris wrote:
> > Hi,
> >
> > I can't find section 8.1.3.5 in the standard. Where is it?
> >
> > Thanks,
> >
> > Jay.
> >
> > */Jonathan Rosenberg /* wrote:
> >
> >
> >
> > Valerie Kenneally wrote:
> > > Hi all,
> > >
> > > Assume a User Agent is registering with a SIP Server. The SIP
> Server
> > > challenges the User Agent with regard to Authorization. The User
> > Agent
> > > replies with the appropriate information. My question-when the
> > User Agent
> > > responds to the challenge will the Call-ID and From tag or this
> > message be
> > > the same as the first REGISTER message sent? All info greatly
> > accepted!
> >
> > Yes. Section 8.1.3.5 addresses this case:
> >
> >! > In all of the above cases, the request is retried by creating
> a new
> > > request with the appropriate modifications. This new request
> > > constitutes a new transaction and SHOULD have the same value of the
> > > Call-ID, To, and From of the previous request, but the CSeq should
> > > contain a new sequence number that is one higher than the previous.
> > >
> > > !
> > >
> > > Rosenberg, et. al. Standards Track [Page 45]
> > >
> > > RFC 3261 SIP: Session Initiation Protocol June 2002
> > >
> > >
> > > With other 4xx responses, including those yet to be defined, a
> retry
> > > may or may not be possible depending on the method and the use
> case.
> >
> >
> > -Jonathan R.
> > --
> > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
> > Chief Scientist Parsippany, NJ 07054-2711
> > dynamicsoft
> > jdrosen@dynamicsoft.com FAX: (973) 952-5050
> &! gt; 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
> >
> >
> >
> ------------------------------------------------------------------------
> > Do you Yahoo!?
> > Yahoo! Tax Center
> > - File
> > online, calculators, forms, and more
> 
> -- 
> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
> Chief Scientist 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/mai! lman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 
> 
> ------------------------------------------------------------------------
> Do you Yahoo!?
> Yahoo! Tax Center 
> - File 
> online, calculators, forms, and more

-- 
Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
Chief Scientist Parsippany, NJ 07054-2711
dynamicsoft
jdrosen@dynamicsoft.com FAX: (973) 952-5050
http://www.jdrosen.net PHONE: (973) 952-5000
http://www.dynamicsoft.com



---------------------------------
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
--0-758496772-1050386230=:23142
Content-Type: text/html; charset=us-ascii

<DIV>Thanks for your response.</DIV>
<DIV>I also saw this paragraph but was confused since in the </DIV>
<DIV>draft-ietf-sipping-basic-call-flows-02.txt the From tags are different.</DIV>
<DIV>Jay.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><B><I>Jonathan Rosenberg &lt;jdrosen@dynamicsoft.com&gt;</I></B> wrote:</DIV>
<BLOCKQUOTE style="BORDER-LEFT: #1010ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px"><BR><BR>Jay Morris wrote:<BR>&gt; Hi,<BR>&gt; <BR>&gt; 1. I am looking at the pdf version and the section numbering is <BR>&gt; different. I was under the impression I can use the pdf safely. I guess <BR>&gt; I was wrong. Do you know where I can find a pdf version with the correct <BR>&gt; numbering.<BR><BR>Don't use the PDF. Its not official. Use the .txt.<BR><BR>&gt; <BR>&gt; 2. The section still does not say if the from-tag should remain the same <BR>&gt; or not.<BR>&gt; For dialogs the answer should be yes but I'm not sure about registrations.<BR><BR>Here is the text from 8.1.3.5:<BR><BR>In all of the above cases, the request is retried by creating a new<BR>request with the appropriate modifications. This new request<BR>constitutes a new transaction and SHOULD have the same value of the<BR>Call-ID, To, and From of the previous request, but the CSeq should<BR>contain a new sequence num!
 ber that is one higher than the previous.<BR><BR>Since the tag is part of the value of the From header field, this means <BR>that the tag remains the same.<BR><BR>-Jonathan R.<BR><BR><BR>&gt; <BR>&gt; Jay.<BR>&gt; <BR>&gt; */Jonathan Rosenberg <JDROSEN@DYNAMICSOFT.COM>/* wrote:<BR>&gt; <BR>&gt; Page 45 of RFC 3261.<BR>&gt; <BR>&gt; -Jonathan R.<BR>&gt; <BR>&gt; Jay Morris wrote:<BR>&gt; &gt; Hi,<BR>&gt; &gt;<BR>&gt; &gt; I can't find section 8.1.3.5 in the standard. Where is it?<BR>&gt; &gt;<BR>&gt; &gt; Thanks,<BR>&gt; &gt;<BR>&gt; &gt; Jay.<BR>&gt; &gt;<BR>&gt; &gt; */Jonathan Rosenberg /* wrote:<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt; Valerie Kenneally wrote:<BR>&gt; &gt; &gt; Hi all,<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; Assume a User Agent is registering with a SIP Server. The SIP<BR>&gt; Server<BR>&gt; &gt; &gt; challenges the User Agent with regard to Authorization. The User<BR>&gt; &gt; Agent<BR>&gt; &gt; &gt; replies with the appropriate information. My q!
 uestion-when the<BR>&gt; &gt; User Agent<BR>&gt; &gt; &gt; responds to
 the challenge will the Call-ID and From tag or this<BR>&gt; &gt; message be<BR>&gt; &gt; &gt; the same as the first REGISTER message sent? All info greatly<BR>&gt; &gt; accepted!<BR>&gt; &gt;<BR>&gt; &gt; Yes. Section 8.1.3.5 addresses this case:<BR>&gt; &gt;<BR>&gt; &gt;! &gt; In all of the above cases, the request is retried by creating<BR>&gt; a new<BR>&gt; &gt; &gt; request with the appropriate modifications. This new request<BR>&gt; &gt; &gt; constitutes a new transaction and SHOULD have the same value of the<BR>&gt; &gt; &gt; Call-ID, To, and From of the previous request, but the CSeq should<BR>&gt; &gt; &gt; contain a new sequence number that is one higher than the previous.<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; !<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; Rosenberg, et. al. Standards Track [Page 45]<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; RFC 3261 SIP: Session Initiation Protocol June 2002<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; With other 4xx responses, including !
 those yet to be defined, a<BR>&gt; retry<BR>&gt; &gt; &gt; may or may not be possible depending on the method and the use<BR>&gt; case.<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt; -Jonathan R.<BR>&gt; &gt; --<BR>&gt; &gt; Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza<BR>&gt; &gt; Chief Scientist Parsippany, NJ 07054-2711<BR>&gt; &gt; dynamicsoft<BR>&gt; &gt; jdrosen@dynamicsoft.com FAX: (973) 952-5050<BR>&gt; &amp;! gt; http://www.jdrosen.net PHONE: (973) 952-5000<BR>&gt; &gt; http://www.dynamicsoft.com<BR>&gt; &gt;<BR>&gt; &gt; _______________________________________________<BR>&gt; &gt; Sip mailing list https://www1.ietf.org/mailman/listinfo/sip<BR>&gt; &gt; This list is for NEW development of the core SIP Protocol<BR>&gt; &gt; Use sip-implementors@cs.columbia.edu for questions on current sip<BR>&gt; &gt; Use sipping@ietf.org for new developments on the application of sip<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; ----------------------------------------------------------!
 --------------<BR>&gt; &gt; Do you Yahoo!?<BR>&gt; &gt; Yahoo! Tax Cen
ter<BR>&gt; &gt; - File<BR>&gt; &gt; online, calculators, forms, and more<BR>&gt; <BR>&gt; -- <BR>&gt; Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza<BR>&gt; Chief Scientist Parsippany, NJ 07054-2711<BR>&gt; dynamicsoft<BR>&gt; jdrosen@dynamicsoft.com FAX: (973) 952-5050<BR>&gt; http://www.jdrosen.net PHONE: (973) 952-5000<BR>&gt; http://www.dynamicsoft.com<BR>&gt; <BR>&gt; _______________________________________________<BR>&gt; Sip mailing list https://www1.ietf.org/mai! lman/listinfo/sip<BR>&gt; This list is for NEW development of the core SIP Protocol<BR>&gt; Use sip-implementors@cs.columbia.edu for questions on current sip<BR>&gt; Use sipping@ietf.org for new developments on the application of sip<BR>&gt; <BR>&gt; <BR>&gt; ------------------------------------------------------------------------<BR>&gt; Do you Yahoo!?<BR>&gt; Yahoo! Tax Center <BR>&gt; - File <BR>&gt; online, calculators, forms, and more<BR><BR>-- <BR>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza<BR>Chie!
 f Scientist Parsippany, NJ 07054-2711<BR>dynamicsoft<BR>jdrosen@dynamicsoft.com FAX: (973) 952-5050<BR>http://www.jdrosen.net PHONE: (973) 952-5000<BR>http://www.dynamicsoft.com<BR></BLOCKQUOTE><p><br><hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/search/mailsig/*http://search.yahoo.com">The New Yahoo! Search</a> - Faster. Easier. Bingo.
--0-758496772-1050386230=:23142--
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Tue Apr 15 03:11:54 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17688
	for <sip-archive@odin.ietf.org>; Tue, 15 Apr 2003 03:11:54 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3F7Js110311
	for sip-archive@odin.ietf.org; Tue, 15 Apr 2003 03:19:54 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F7J9810281;
	Tue, 15 Apr 2003 03:19:09 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F7DV810108
	for <sip@optimus.ietf.org>; Tue, 15 Apr 2003 03:13: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 DAA17600
	for <sip@ietf.org>; Tue, 15 Apr 2003 03:05:01 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195KXU-0000el-00
	for sip@ietf.org; Tue, 15 Apr 2003 03:07:32 -0400
Received: from ipvpn069002.netvigator.com ([203.198.202.2] helo=mail.astri.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 195KXT-0000eQ-00
	for sip@ietf.org; Tue, 15 Apr 2003 03:07:31 -0400
Received: from patrickXP (Firewall [203.198.202.1])
	by mail.astri.org (8.11.6/8.11.2) with ESMTP id h3F7AYm20667
	for <sip@ietf.org>; Tue, 15 Apr 2003 15:10:34 +0800
From: "Patrick Lam" <patrickl@astri.org>
To: <sip@ietf.org>
Date: Tue, 15 Apr 2003 15:09:49 +0800
Message-ID: <003201c3031e$0134de10$2306050a@patrickXP>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0033_01C30361.0F581E10"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-MS-TNEF-Correlator: 00000000A495D97211F6D54497CF24BD1531C79FE4382A00
Subject: [Sip] Can a proxy generate CANCEL?
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0033_01C30361.0F581E10
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dear all:

On p.53 of 3261, it states that:

"CANCEL requests can be constructed and sent by both proxies and user agent
clients."

But on p.92 of 3261, it states that:

"The proxy SHOULD NOT initiate a CANCEL request."

In many other places of the spec, proxies are able and required to generate
CANCEL request in some scenarios.  Therefore, is the sentence on p.92 a
typo?  Or am I missing the hidden meaning of it?

Thanks very much in advance.

Patrick Lam

------=_NextPart_000_0033_01C30361.0F581E10
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Disposition: attachment;
	filename="winmail.dat"
Content-Transfer-Encoding: base64

eJ8+IjEHAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANMHBAAPAA8ACQAAAAIABwEB
A5AGAOgMAAAnAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB
AAAAHQAAAENhbiBhIHByb3h5IGdlbmVyYXRlIENBTkNFTD8AAAAAAgFxAAEAAAAWAAAAAcMDHgDr
0Y7D5UH2Tt+GHPcJzeaz1QAAAgEdDAEAAAAYAAAAU01UUDpQQVRSSUNLTEBBU1RSSS5PUkcACwAB
DgAAAABAAAYOAI5d4x0DwwECAQoOAQAAABgAAAAAAAAApJXZchH21USXzyS9FTHHn8KAAAADABQO
AAAAAAsAHw4BAAAAAgEJEAEAAACtCAAAqQgAAFoVAABMWkZ12hwSsYMACgByY3BnOTUBQAx1YwBQ
AQRzdHNowQVwYmNoMTQO9AkAmw9wDuVoDeAQRmJpAUOBC2BuZzEwMzMRpuRmZRIgMjgB9wKkA2NH
AgAPcArAc2V0AtFwKHJxMgAAKgqhbm+tFOAgExAWMTYSMDAOMM40FrEB0BagNH0HbQKD7wBQA9QU
jxWbYhZxFuAWQj8bhBdgBxMYdA+gFC0xMx42Ge8WMxagH6t9UE2hC4BnTGlVFYJmB0ABBUC3c7LT
qfrF/Ol9AoMeEh0vHj8fTyBSFkAglhh0Mhz/MjM4RSPUIAdtIENFJsU1TydPFtAofymFeXImxTdd
Iq82GMEr3wOCRwnRa7cmxShhLf4yLw8phFQIcHUmxTkxTzctwTKfA4IoyEhlYglwdykYdBag/TSf
NyhvNsYHEAGgDeA3ptsYwSLNOCPFOc9CIWEN4L83tTJhLf4SUD0fNuRWCJDodG5hB4FlN6YnMRj8
9yhIBxMp1zMqcUNdK5dE1f0tNjMtwRj8LthE1DB5KFLvSK4yZkTUM+czNIFIrTWnf0TUNzwW4E4P
OUdPpTrrNO8YzzzYRNQ+ejQyYUiuQHazT6VCDjI2Ip8Z1SAglnQgVweQdASRIR8iJDT/POJaT0Cj
JjdcJgKAApEI5qo7CW8wYa9lKmA1Ytr/Y/Fjr2S5YsRk4mNPZx9m3f9mX2SPYt8S8BMgbKoxEm2P
/26YYsQxEm0fcO9wrXAvbl/9ciQ5MmB1dHbRbvN20AKCqQ8AeWwHkGgJ4HQAAPpxAyFsEYEFEAFA
FeAD8LBkY3RsCrEAYHMKsEd6MBlwenJudW1c0WGIdXRvAGBkanUPAPEFEGdodHlxCgF5QAoB8mkB
kHAwA7InIRHnEqj8XGsEkSCxMmAQEgKyEMLfAGABMg9hgKEPkWMJwHnweX4DbnB+WYIyEyADMHP4
bmV4GcAHsAWwAMACc7kVoGNzEiADMHvwZH1QnGl2FhAO8BmgbWkQwHOFIAnwIEQBEHugXQFQjQrA
YQnAfXBoIEYCIbuEVA8QMQBQDxADYHcLMBN8QAGAc1d58HRoQu8SUHxACrCFIGwSIDlQicS+coo4
EACJpgGAi6dii6fycomiY2IKsCOQjZIj4OON8wTwZWxseeGJcIkR/wFADxCFcAAgXPGIITdgisB/
kEYJUJBkDLGQc3pgkGRkvmeRRpLAkkaAEJBkdgMw/3kKee96/3wPfRyYcRHzfeX/EuN98X//gQ+C
FJoHnTSDZX+IUIWcg/RA4AGgeHCEVzXfhPqGsAjQWeCDYWKWEAmAfwIghNJ4QRmQlYCIUEWwOOE8
0SBIeXAEkH0BMLP/hJOkEKFOJxCiX6Nrh5CPAP950AmApD81kIT6C+OOUJhx/5rzAFCbZQ6BnAam
nYXJDvA9pFFzAiBFAQ7wBaBtcNsV8qdvRQDAAxBTeFI1kBdg0xWgYcB2AlEge1X/pKB5wWDEsiGj
cbJys5MoUDkSMDg3AFCjarTkNTmzO7AW0DN9CqGkUXeIUM45FnC2lA+ANjgoUAMwzwFkXhAC0UIw
YmoAYAnwv4UgECACAYQQDyCXgGWbUJ0FsHq5cpLAAMByZwuBPZLAaJYhjuA80AFBZ3bfu5m6UZfw
C4A1kDAOgbwwub0VOTgPoLtiulB3vAS7vuEyYGqvgmHAGSFsFeC/EgCBsrlxeFCkUDJgdgiQ9Hdr
C4BkKnDBggTwB0DnEvEO4QtQeXSzEAuAujD/uNHDF5gQAMCXQJYgDGAZoP9dAKbAwGAAYMBgAlHB
0Xkw/8MgwnGVoAJgiMHDEQJRACDnk3HAYDdga3KGsLowFeD9x9F3idAJMoOAfXCXUIGirwuAjuLF
gaihZgiQbIYxzmTFAZVgidBwdcnAmCDflhAHMMfHo2IDYG8jkLYV7wMxGbIZoJWgZHkig5EBQP25
QW54oGHAzfPOcoGiI7D7zeSuwWMGkHhgDvC407Kg5xWSAIAFkGx2iiDR4Q5gf4QQ0eIBkAAg0nLB
0QnwdP8BwdHhGXASANGhlsAM0AGQ/CAuseTR9jJg0pJdAJXw/9MP1B/VL4uRlsAFgdbf1+//2P/S
UA+glsDGgNav23/chb4p1WwqcNpP3z/cZWI3IP8CkeBv0iO3Qd4f4u/j/+UP/9JQLcDmUtLf57/o
z+DdOVD/5l/r7+z/7g/SQTSA6u/wj//xn/KlCvmUnHnPlm+Xf3z5/wqiGYGjiX2/fs+a1Juym2//
gX+CjRiVPNCrIwuAiJD9a7+r/5rGnuCGcArByiE6GIajBGy0dSANCv0CIAgvLwT8CgUF3wbpT/gw
cC5iNc2Ab2YgPzAu4Cz6IH1QIPSBXGA6EIlwjfD+OgoFCg8LH/3jAFUNWgDj+QdhXCe2IBF/BP8T
nwcWSENBTingTCBhwHHfYqB4QDoQwnD4MGKqsK+A//RxyAD5cGHQB9C5UA/A9UE9GkB5GkDM8Idw
I/BveN9CEDoQG0LE8QfBZxuS0jD/QhD3AEjgF28G+NVQFX8Sn/sTrxS4NCAPC48RPyTPDF/7Hs8J
4EL7EA8AKL8G6Q6i/3bQDw8QHyYPJx8h3xRfL193Fn8xfwcWVHigHEMb4FMgSE9VTEQ6IE9U/y1w
9QA+oC3RB9AZDR//MF//MW8jLzovJ68u7z5/NP8Grf5J+DBegRvgHBEdMffxjuD/HLAs8UThLaDQ
wS1gHFdhwG8H0KBhGzMZgmlhwS4Qb/4gHXFgoDiSGRw4MS2gXnCfRfGO4K8g+7CvwC4gNuL7YcC5
sWUtYS4CRfH1QWJAn47gLOAshdzQwSFvP0sg+k8HwW1EQERwVyFbwUXD/0CvQb9CzwcWhgVZUF6Q
TsJ7LPEtgD8/zFE/NktekGv3HLCP4RvgbdaAh3D4IftQ9nZekI7gLj/PT3+1GV7SH1BvVW8HJYbw
+6FjayA+TE4wWY9an1usWRZ9AAFikAAAAAMA3j+fTgAAAwAJWQMAAAADAEBlAAAAAAsAE4AIIAYA
AAAAAMAAAAAAAABGAAAAAAOFAAAAAAAAAwAVgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAAD
ABuACCAGAAAAAADAAAAAAAAARgAAAABShQAAG5cBAAMAIoAIIAYAAAAAAMAAAAAAAABGAAAAAAGF
AAAAAAAAQAAjgAggBgAAAAAAwAAAAAAAAEYAAAAAYIUAAADMC/G8//8fCwBCgAggBgAAAAAAwAAA
AAAAAEYAAAAAgoUAAAEAAAAeAEmACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAUAAAAxMC4w
AAAAAAsAdYAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAACwB2gAggBgAAAAAAwAAAAAAAAEYA
AAAADoUAAAAAAAADAHeACCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAAIB+A8BAAAAEAAAAKSV
2XIR9tVEl88kvRUxx58CAfoPAQAAABAAAACkldlyEfbVRJfPJL0VMcefAgH7DwEAAACWAAAAAAAA
ADihuxAF5RAaobsIACsqVsIAAG1zcHN0LmRsbAAAAAAATklUQfm/uAEAqgA32W4AAABDOlxEb2N1
bWVudHMgYW5kIFNldHRpbmdzXHBhdHJpY2tsXExvY2FsIFNldHRpbmdzXEFwcGxpY2F0aW9uIERh
dGFcTWljcm9zb2Z0XE91dGxvb2tcT3V0bG9vay5wc3QAAAADAP4PBQAAAAMADTT9NwIAAgEUNAEA
AAAQAAAATklUQfm/uAEAqgA32W4AAAIBfwABAAAAMQAAADAwMDAwMDAwQTQ5NUQ5NzIxMUY2RDU0
NDk3Q0YyNEJEMTUzMUM3OUZFNDM4MkEwMAAAAAADAAYQ/tOR9wMABxBrAQAAAwAQEAAAAAADABEQ
AAAAAB4ACBABAAAAZQAAAERFQVJBTEw6T05QNTNPRjMyNjEsSVRTVEFURVNUSEFUOiJDQU5DRUxS
RVFVRVNUU0NBTkJFQ09OU1RSVUNURURBTkRTRU5UQllCT1RIUFJPWElFU0FORFVTRVJBR0VOVENM
SUUAAAAA2Hc=

------=_NextPart_000_0033_01C30361.0F581E10--

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



From mailnull@www1.ietf.org  Tue Apr 15 05:39:30 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20117
	for <sip-archive@odin.ietf.org>; Tue, 15 Apr 2003 05:39:30 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3F9lXT20792
	for sip-archive@odin.ietf.org; Tue, 15 Apr 2003 05:47:33 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F9l7820774;
	Tue, 15 Apr 2003 05:47:07 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F9fi820624
	for <sip@optimus.ietf.org>; Tue, 15 Apr 2003 05:41:44 -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 FAA20043
	for <sip@ietf.org>; Tue, 15 Apr 2003 05:33:10 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195Mqs-000193-00
	for sip@ietf.org; Tue, 15 Apr 2003 05:35:42 -0400
Received: from ipvpn069002.netvigator.com ([203.198.202.2] helo=mail.astri.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 195Mqr-00018u-00
	for sip@ietf.org; Tue, 15 Apr 2003 05:35:41 -0400
Received: from patrickXP (Firewall [203.198.202.1])
	by mail.astri.org (8.11.6/8.11.2) with ESMTP id h3F9cYm25916;
	Tue, 15 Apr 2003 17:38:34 +0800
From: "Patrick Lam" <patrickl@astri.org>
To: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>
Cc: <sip@ietf.org>
Subject: RE: [Sip] What exactly is "response context"?
Date: Tue, 15 Apr 2003 17:37:46 +0800
Message-ID: <005d01c30332$ac458070$2306050a@patrickXP>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <3E9B77B6.8010807@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

Understood.

But why does the proxy not forward all the responses to the UAC (each of
them will be identified by the dialog ID), and let the UAC handle the
responses separately?  E.g. someone in the conference requiring
authentication may send 401, while the others are all sending 2xx's.  If
the UAC also receives 401 from that particular user, it can follow-up
with appropriate authentication.

From my gut feeling, choosing the *best* response among the response
context is just not a perfect way to handle forking.  

I must be wrong, however.

Patrick Lam

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Tuesday, April 15, 2003 11:09 AM
> To: Patrick Lam
> Cc: sip@ietf.org
> Subject: Re: [Sip] What exactly is "response context"?
> 
> It is defined in section 16.6:
> 
> >   A stateful proxy must have a mechanism to maintain the target set
as
> >    responses are received and associate the responses to each
forwarded
> >    request with the original request.  For the purposes of this
model,
> >    this mechanism is a "response context" created by the proxy layer
> >    before forwarding the first request.
> 
> When a proxy forks, it will get responses for each forked response.
> Those are held in the response context.
> 
> -Jonathan R.
> 
> Patrick Lam wrote:
> > Dear all:
> >
> > What exactly is "response context" being mentioned in RFC 3261
(p.107)?
> > Why would a response context contain multiple responses (so that a
proxy
> > has to choose the best one)?  Should there be only one appropriate
> > response to be forwarded by the proxy at any particular time?  For
> > example, after receiving a response downstream, the proxy would (at
> > least for most cases) forward this same response upstream, right?
> >
> > I think I am missing some important concept about response context
here.
> > Can someone please explain?
> >
> > Thanks very much in advance.
> >
> > Patrick Lam
> >
> 
> --
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Scientist                             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 mailnull@www1.ietf.org  Tue Apr 15 10:04:46 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27857
	for <sip-archive@odin.ietf.org>; Tue, 15 Apr 2003 10:04:46 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3FECsx06520
	for sip-archive@odin.ietf.org; Tue, 15 Apr 2003 10:12:54 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FEC6806506;
	Tue, 15 Apr 2003 10:12:06 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FE6b805464
	for <sip@optimus.ietf.org>; Tue, 15 Apr 2003 10:06: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 JAA27583
	for <sip@ietf.org>; Tue, 15 Apr 2003 09:57:59 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195Qz7-0002fw-00
	for sip@ietf.org; Tue, 15 Apr 2003 10:00:29 -0400
Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 195Qz7-0002fk-00
	for sip@ietf.org; Tue, 15 Apr 2003 10:00:29 -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 h3FDxn905678;
	Tue, 15 Apr 2003 08:59:49 -0500
Subject: Re: [Sip] Can a proxy generate CANCEL?
From: Robert Sparks <rsparks@dynamicsoft.com>
To: Patrick Lam <patrickl@astri.org>
Cc: sip@ietf.org
In-Reply-To: <003201c3031e$0134de10$2306050a@patrickXP>
References: <003201c3031e$0134de10$2306050a@patrickXP>
Content-Type: text/plain
Message-Id: <1050415106.922.14.camel@RjS.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.3 
Date: 15 Apr 2003 08:58:26 -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

Patrick -

You are more likely to get quick answers to these kinds of questions if
you ask them on the sip-implementor's list. See  

http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors



On Tue, 2003-04-15 at 02:09, Patrick Lam wrote:
> Dear all:
> 
> On p.53 of 3261, it states that:
> 
> "CANCEL requests can be constructed and sent by both proxies and user agent
> clients."
> 
> But on p.92 of 3261, it states that:
> 
> "The proxy SHOULD NOT initiate a CANCEL request."
> 
> In many other places of the spec, proxies are able and required to generate
> CANCEL request in some scenarios.  Therefore, is the sentence on p.92 a
> typo?  Or am I missing the hidden meaning of it?

You need to read the sentences that come right before it as well. This
paragraph talks about proxies making a transition between being 
transaction stateful and transaction stateless - a proxy should not
generate a cancel when making that transition.

> 
> Thanks very much in advance.
> 
> Patrick Lam

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



From mailnull@www1.ietf.org  Tue Apr 15 10:31:24 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29548
	for <sip-archive@odin.ietf.org>; Tue, 15 Apr 2003 10:31:24 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3FEdXI08553
	for sip-archive@odin.ietf.org; Tue, 15 Apr 2003 10:39:33 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FEd6808538;
	Tue, 15 Apr 2003 10:39:06 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FEYX807446
	for <sip@optimus.ietf.org>; Tue, 15 Apr 2003 10:34: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 KAA29338;
	Tue, 15 Apr 2003 10:25:54 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195RQ9-0002mU-00; Tue, 15 Apr 2003 10:28:25 -0400
Received: from gateus.nmss.com ([208.236.204.65])
	by ietf-mx with smtp (Exim 4.12)
	id 195RQ8-0002mF-00; Tue, 15 Apr 2003 10:28:24 -0400
Received: from NAMASMTP02 by [208.236.204.65]
          via smtpd (for [132.151.6.1]) with SMTP; 15 Apr 2003 09:23:44 UT
Subject: RE: [Sip] What exactly is "response context"?
To: "Patrick Lam" <patrickl@astri.org>
Cc: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>, sip@ietf.org,
        sip-admin@ietf.org
X-Mailer: Lotus Notes Release 5.0.10  March 22, 2002
Message-ID: <OFD419F8F7.2D4DEFF5-ON85256D09.004EF2B1-85256D09.004F79CF@nmss.com>
From: "Vishal Phirke" <vishal_phirke@nmss.com>
Date: Tue, 15 Apr 2003 10:26:44 -0400
X-MIMETrack: Serialize by Router on NAMASMTP02/NMS Communications(Release 5.0.11  |July
 24, 2002) at 04/15/2003 10:24:23 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>


I doubt this applies to conferencing case. The forking is done by proxy to
reach different contact addresses of the same user as per AOR record.  So,
being stateful, it maintains a response context for the forwarded request
and stores all the incoming responses from various paths and forwards the
best one.
-Vishal
P.S: sip-implementors list is the better place to discuss such issues.


                                                                                                           
                      "Patrick Lam"                                                                        
                      <patrickl@astri.o        To:       "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>  
                      rg>                      cc:       <sip@ietf.org>                                    
                      Sent by:                 Subject:  RE: [Sip] What exactly is "response context"?     
                      sip-admin@ietf.or                                                                    
                      g                                                                                    
                                                                                                           
                                                                                                           
                      04/15/2003 05:37                                                                     
                      AM                                                                                   
                                                                                                           
                                                                                                           




Understood.

But why does the proxy not forward all the responses to the UAC (each of
them will be identified by the dialog ID), and let the UAC handle the
responses separately?  E.g. someone in the conference requiring
authentication may send 401, while the others are all sending 2xx's.  If
the UAC also receives 401 from that particular user, it can follow-up
with appropriate authentication.

From my gut feeling, choosing the *best* response among the response
context is just not a perfect way to handle forking.

I must be wrong, however.

Patrick Lam

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Tuesday, April 15, 2003 11:09 AM
> To: Patrick Lam
> Cc: sip@ietf.org
> Subject: Re: [Sip] What exactly is "response context"?
>
> It is defined in section 16.6:
>
> >   A stateful proxy must have a mechanism to maintain the target set
as
> >    responses are received and associate the responses to each
forwarded
> >    request with the original request.  For the purposes of this
model,
> >    this mechanism is a "response context" created by the proxy layer
> >    before forwarding the first request.
>
> When a proxy forks, it will get responses for each forked response.
> Those are held in the response context.
>
> -Jonathan R.
>
> Patrick Lam wrote:
> > Dear all:
> >
> > What exactly is "response context" being mentioned in RFC 3261
(p.107)?
> > Why would a response context contain multiple responses (so that a
proxy
> > has to choose the best one)?  Should there be only one appropriate
> > response to be forwarded by the proxy at any particular time?  For
> > example, after receiving a response downstream, the proxy would (at
> > least for most cases) forward this same response upstream, right?
> >
> > I think I am missing some important concept about response context
here.
> > Can someone please explain?
> >
> > Thanks very much in advance.
> >
> > Patrick Lam
> >
>
> --
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Scientist                             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 mailnull@www1.ietf.org  Tue Apr 15 10:58:42 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00427
	for <sip-archive@odin.ietf.org>; Tue, 15 Apr 2003 10:58:42 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3FF6pJ09741
	for sip-archive@odin.ietf.org; Tue, 15 Apr 2003 11:06:51 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FF6P809729;
	Tue, 15 Apr 2003 11:06:25 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FF1Q809552
	for <sip@optimus.ietf.org>; Tue, 15 Apr 2003 11:01: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 KAA00310
	for <sip@ietf.org>; Tue, 15 Apr 2003 10:52:46 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195Rq9-0002uY-00
	for sip@ietf.org; Tue, 15 Apr 2003 10:55:17 -0400
Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112])
	by ietf-mx with esmtp (Exim 4.12)
	id 195Rq8-0002uU-00
	for sip@ietf.org; Tue, 15 Apr 2003 10:55:16 -0400
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3FEsdn08604;
	Tue, 15 Apr 2003 09:54:40 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <HNP4476A>; Tue, 15 Apr 2003 09:54:40 -0500
Message-ID: <1B54FA3A2709D51195C800508BF9386A09DABC9F@zrc2c000.us.nortel.com>
From: "Mary Barnes" <mbarnes@nortelnetworks.com>
To: "'rsparks@dynamicsoft.com'" <rsparks@dynamicsoft.com>
Cc: "'sip@ietf.org'" <sip@ietf.org>
Date: Tue, 15 Apr 2003 09:54:38 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Subject: [Sip] Comments/nits on draft-ietf-sip-referredby-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>

Hi Robert,

Based on the action I took in San Francisco, I've recently reviewed the
draft and have the following comments. Some are just editorial nits, others
relate to the discussion in San Francisco (and likely you're already
planning these changes) and a few new items for discussion.  

Editorial Nits:
-------------------
- Abstract:  third sentence: I would propose to reword this and change the
word "reference" to "referenced request"  (it may be just me but I had to
read that several times to convince myself that it said what it should have;
or perhaps you could write the word "reference" as "REFER-ence")

- Section 7.3, second sentence: "choses" -> "chooses" or "chose"

- References: identity, authid-body and cc-transfer need upversioning.

Per discussion in San Francisco:
------------------------------------------------
- Section 4: Call-ID should not be used for the token, thus the open issue
in section 4 & 9 (Issue 2)  is closed, with the 2nd paragraph to be updated
appropriately.  Per the discussion, the most recent Authid-body draft
addresses the REFER as a special case where the Call-ID cannot be used. 

- Section 4.1: 3rd paragraph suggesting that the target verify the identity
in the FROM in the token matches the SubjectAltName from the signing
certificate.  As I recall, it was highlighted during the discussion that the
referrer may not have a certifcate matching that field, thus I think it was
ageed to remove that (but my detailed notes are not conclusive, nor are
those on the SIP webpage).  Thus, the first Open Issue in that section is
closed. This is also listed as Issue 3 in section 9 and I think the
conclusion is that the Referred-by should be the identity reflected in the
Token. 

-Section 4.1: 2nd issue (also listed as Issue 4 in section 9) around
restricting the referree to use the To value from the original dialog as the
From.  There was no conclusion around this issue and I really think you
don't want to do that. I think you could actually use History-Info (for the
Referrer to indicate it's identity).  Refers are identified as a form of
retargeting in the requirements document. Although, I don't think the
current normative text in the solution draft fully takes this into account,
but it should.  Thus, if you have the security around History-Info, then you
can be certain that the referrer did send that refer to this particular
referee (per your Issue 1 in section 9). 

Other items:
--------------------------------------
- Section 2.1: Propose to add a final paragraph (or another sentence to the
current final paragraph) similar to the following to this section to
indicate what the Referrer should do upon receipt of a 429:
"Upon receipt of a 429 response, if the Referrer still wishes to REFER to
the target, a Referred-by token MUST be included in the referenced request."

- Section 2.3: Last paragraph: should this be a MUST (reject an otherwise
well-formed request with an invalid token)?   Reasonably, one should, but
perhaps there are users that would still like to be able to decide
themselves, thus I would suggest this be stated similar to the previous
paragraph as:

"The refer target SHOULD reject an otherwise well-formed request with an
invalid Referred-By token (see Section 4) with a 429 error response. If the
agent chooses to proceed with the request and provides any information from
the Referred-By header to its user as part of processing the request, it
MUST notify the user that the information was determined to be invalid." 

My reasoning is that it just seems that if an optional parm is mucked up (in
general or from a security perspective), then following the adage of being
generous in what you accept ...that whether to accept the request, provided
that it is warned that it's bad,  should still be up to the user.  This also
seems consistent with the MAYs in the previous 2 paragraphs. I do understand
the reasoning that you'd want to let the Referrer know and that by allowing
the request, you're actually bypassing the security put in place to keep the
bad guys from mucking with the messages, but again since it's optional, it
just seems that you can't make it stronger than a SHOULD. 

- Section 4.1:  2nd paragraph suggesting that "A target SHOULD verify the
request...".  I don't think this is useful since retargeting makes this
check not meaningful.  UNLESS, of course, you're using History-Info.  With
History-Info, you could verify that the Refer-To matches one of the
Targeted-to-URIs (and of course, this implies that this information has all
been sent securely, not mucked with by the proxies, etc.).  

Regards,
Mary H. Barnes
mbarnes@nortelnetworks.com
972-684-5432

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



From mailnull@www1.ietf.org  Tue Apr 15 11:36:05 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01628
	for <sip-archive@odin.ietf.org>; Tue, 15 Apr 2003 11:36:05 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3FFiG013036
	for sip-archive@odin.ietf.org; Tue, 15 Apr 2003 11:44:16 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FFhf812985;
	Tue, 15 Apr 2003 11:43:41 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FFcc812799
	for <sip@optimus.ietf.org>; Tue, 15 Apr 2003 11:38: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 LAA01429
	for <sip@ietf.org>; Tue, 15 Apr 2003 11:29:57 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195SQ8-00035a-00
	for sip@ietf.org; Tue, 15 Apr 2003 11:32:28 -0400
Received: from mailserv.intranet.gr ([146.124.14.106])
	by ietf-mx with esmtp (Exim 4.12)
	id 195SQ7-00035L-00
	for sip@ietf.org; Tue, 15 Apr 2003 11:32:28 -0400
Received: from mailserv.intranet.gr (localhost [127.0.0.1])
	by mailserv.intranet.gr (8.11.7/8.11.3) with ESMTP id h3FFYRI06534
	for <sip@ietf.org>; Tue, 15 Apr 2003 18:34:27 +0300 (EEST)
Received: from ifaistos.intranet.gr (ifaistos.intranet.GR [146.124.20.203])
	by mailserv.intranet.gr (8.11.7/8.11.3) with ESMTP id h3FFYQU06528
	for <sip@ietf.org>; Tue, 15 Apr 2003 18:34:26 +0300 (EEST)
Received: from intracom.gr (pcrnd105 [146.124.20.189])
	by ifaistos.intranet.gr (8.9.1b+Sun/8.9.1) with ESMTP id SAA28226
	for <sip@ietf.org>; Tue, 15 Apr 2003 18:28:45 +0300 (EET DST)
Message-ID: <3E9C477D.8030608@intracom.gr>
Date: Tue, 15 Apr 2003 20:55:09 +0300
From: Paraskevopoulos Pavlos <ppar@intracom.gr>
Organization: INTRACOM
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212
X-Accept-Language: el, 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] [Fwd: CSPS v2.0 - Register problem]
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit



Hi all,

I have a problem considering Registration while I' m working with Cisco 
SIP Proxy Server ver.2.0 (CSPS).

My REGISTER message is the following

REGISTER sip:VOICE.SPDOP.RU SIP/2.0
Max-Forwards: 70
Via: SIP/2.0/UDP 10.100.1.165:5060
From: <sip:9505065@VOICE.SPDOP.RU>;tag=14713
To: <sip:9505065@VOICE.SPDOP.RU>
Call-ID: 6948@10.100.1.165
CSeq: 1 REGISTER
Contact: <sip:9505065@10.100.1.165:5060>
Expires: 180
User-Agent: netPhone-010107A
Content-Length: 0

And the Proxy responds the following

SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.100.1.165:5060;received=10.100.1.165
Call-ID: 6948@10.100.1.165
From: <sip:9505065@VOICE.SPDOP.RU>;tag=14713
To: <sip:9505065@VOICE.SPDOP.RU>
CSeq: 1 REGISTER
Content-Length: 0

SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.100.1.165:5060;received=10.100.1.165
Call-ID: 6948@10.100.1.165
From: <sip:9505065@VOICE.SPDOP.RU>;tag=14713
To: <sip:9505065@VOICE.SPDOP.RU>
CSeq: 1 REGISTER
Contact: <sip:9505065@10.100.1.165:5060>;expires="Thu, 10 Apr 2003 
23:53:57 GMT"
Expires: 180
Content-Length: 0

SIP/2.0 400 Error in Headers
Via: SIP/2.0/UDP 10.100.1.165:5060;received=10.100.1.165
Call-ID: 6948@10.100.1.165
From: <sip:9505065@VOICE.SPDOP.RU>;tag=14713
To: <sip:9505065@VOICE.SPDOP.RU>
CSeq: 1 REGISTER
Contact: <sip:9505065@10.100.1.165:5060>;expires="Thu, 10 Apr 2003 
23:53:57 GMT"
Expires: 180
Content-Length: 0


Could anyone help me?
I have used several other proxies including  ser and everything was fine.


Thanks in advance.

Pavlos Paraskevopoulos (www.intracom.gr)



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



From mailnull@www1.ietf.org  Tue Apr 15 13:07:32 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04216
	for <sip-archive@odin.ietf.org>; Tue, 15 Apr 2003 13:07:32 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3FHFj920558
	for sip-archive@odin.ietf.org; Tue, 15 Apr 2003 13:15:45 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FHEv820526;
	Tue, 15 Apr 2003 13:14:58 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FH9R820315
	for <sip@optimus.ietf.org>; Tue, 15 Apr 2003 13:09: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 NAA04049
	for <sip@ietf.org>; Tue, 15 Apr 2003 13:00:44 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195Tpz-0003ZL-00
	for sip@ietf.org; Tue, 15 Apr 2003 13:03: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 195Tpy-0003ZI-00
	for sip@ietf.org; Tue, 15 Apr 2003 13:03:15 -0400
Received: from txdwillis ([216.229.166.130])
	(authenticated bits=0)
	by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h3FH2gsC012487
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO);
	Tue, 15 Apr 2003 12:02:45 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>
Cc: <sip@ietf.org>
Subject: RE: [Sip] Question on Service Route Discovery draft and multiple contacts per AoR
Date: Tue, 15 Apr 2003 12:02:36 -0500
Message-ID: <000001c30370$d5539130$40f30a0a@txdwillis>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
In-Reply-To: <3E9B788F.2040004@dynamicsoft.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3FH9R820316
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit

> I would be surprised if its the same. After all, the Contacts 
> could have 
> been registered from completely different visited networks. 

So? The Service-Route does not contain information about the visited network
-- just information about the home network -- the "specific home proxy or
network of proxies" from which services are being requested.

See the Applicability Statement:

   2.  The registrar has knowledge of a service proxy that should be
       used by the UA when requesting services from the domain of the
       registrar.  This knowledge may be a result of dynamic assignment
       or some other mechanism outside the scope of this document.
   3.  The registrar(s) has/have sufficient knowledge of the network
       topology, policy, and situation such that a reasonable service
       route can be constructed.

Since one can reasonably assume that the registrar has NO explicit knowledge
about the foreign/visited network from which the UA registered, the service
route does not contain data about that network. Clearly the UA and the
visited network have enough routing data to be able to get a REGISTER
request to the edge of the home network (since we're building this route in
the response to that REGISTER request).

> Ideally, 
> there is one service route per contact, and so the REGISTER response 
> would indicate a service route for each contact in the response. That 
> would be a big change from whats in the spec now though.

True. There MIGHT be a difference on the preferred route through the home
network depending on which visited network (and consequently, Contact) is
involved. One can envision using a Service Route-like mechanism to assign a
firewall proxy on a per-contact basis. Such an approach is not supported in
the current draft, which we might point out has completed WGLC and IETF LC
and probably shouldn't be changed (especially substantively) unless there's
a glaring error.

At about this point I should say "Gee, it would have been nice to be able to
use a loose-routing syntax in the actual Contact value (and in fact
everywhere that a URI is given), but that wouldn't have been backward
compatible."


Open Question: Is the additional capability being proposed here important
enough to change the spec at this time, or is it something we should
consider in future work?

--
Dean

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



From mailnull@www1.ietf.org  Tue Apr 15 23:59:29 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21833
	for <sip-archive@odin.ietf.org>; Tue, 15 Apr 2003 23:59:29 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3G47th01449
	for sip-archive@odin.ietf.org; Wed, 16 Apr 2003 00:07:55 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3G40x800302;
	Wed, 16 Apr 2003 00:00:59 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3G3rR832511
	for <sip@optimus.ietf.org>; Tue, 15 Apr 2003 23:53: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 XAA21485
	for <sip@ietf.org>; Tue, 15 Apr 2003 23:44:31 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195dsz-0006KI-00
	for sip@ietf.org; Tue, 15 Apr 2003 23:47:01 -0400
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 195dsz-0006Jp-00
	for sip@ietf.org; Tue, 15 Apr 2003 23:47:01 -0400
Received: from dynamicsoft.com ([63.113.46.67])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h3G3kXBd018000;
	Tue, 15 Apr 2003 23:46:36 -0400 (EDT)
Message-ID: <3E9CD216.8000901@dynamicsoft.com>
Date: Tue, 15 Apr 2003 23:46: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.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Patrick Lam <patrickl@astri.org>
CC: sip@ietf.org
Subject: Re: [Sip] What exactly is "response context"?
References: <005d01c30332$ac458070$2306050a@patrickXP>
In-Reply-To: <005d01c30332$ac458070$2306050a@patrickXP>
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



Patrick Lam wrote:
> Understood.
> 
> But why does the proxy not forward all the responses to the UAC (each of
> them will be identified by the dialog ID), and let the UAC handle the
> responses separately? 

This was a long-time-ago design decision, to avoid a flood of non-200 
responses in cases where there was wide forking. It has been in the 
specs since rfc2543.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             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 mailnull@www1.ietf.org  Wed Apr 16 03:02:50 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20572
	for <sip-archive@odin.ietf.org>; Wed, 16 Apr 2003 03:02:50 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3G7BLI25009
	for sip-archive@odin.ietf.org; Wed, 16 Apr 2003 03:11:21 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3G7Am824967;
	Wed, 16 Apr 2003 03:10:48 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3G74S823848
	for <sip@optimus.ietf.org>; Wed, 16 Apr 2003 03:04: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 CAA20470
	for <sip@ietf.org>; Wed, 16 Apr 2003 02:55:28 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195grn-000792-00
	for sip@ietf.org; Wed, 16 Apr 2003 02:57:59 -0400
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 195grm-00078p-00
	for sip@ietf.org; Wed, 16 Apr 2003 02:57:58 -0400
Received: from dynamicsoft.com ([63.113.46.67])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h3G6veBd018049;
	Wed, 16 Apr 2003 02:57:40 -0400 (EDT)
Message-ID: <3E9CFEE0.60405@dynamicsoft.com>
Date: Wed, 16 Apr 2003 02:57:36 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
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: Dean Willis <dean.willis@softarmor.com>
CC: sip@ietf.org
Subject: Re: [Sip] Question on Service Route Discovery draft and multiple
 contacts per AoR
References: <000001c30370$d5539130$40f30a0a@txdwillis>
In-Reply-To: <000001c30370$d5539130$40f30a0a@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

inline.

Dean Willis wrote:
>>I would be surprised if its the same. After all, the Contacts 
>>could have 
>>been registered from completely different visited networks. 
> 
> 
> So? The Service-Route does not contain information about the visited network
> -- just information about the home network -- the "specific home proxy or
> network of proxies" from which services are being requested.
> 
> See the Applicability Statement:
> 
>    2.  The registrar has knowledge of a service proxy that should be
>        used by the UA when requesting services from the domain of the
>        registrar.  This knowledge may be a result of dynamic assignment
>        or some other mechanism outside the scope of this document.
>    3.  The registrar(s) has/have sufficient knowledge of the network
>        topology, policy, and situation such that a reasonable service
>        route can be constructed.
> 
> Since one can reasonably assume that the registrar has NO explicit knowledge
> about the foreign/visited network from which the UA registered, the service
> route does not contain data about that network. Clearly the UA and the
> visited network have enough routing data to be able to get a REGISTER
> request to the edge of the home network (since we're building this route in
> the response to that REGISTER request).

My bad. You're right. I think I had Path in mind.

> 
> 
>>Ideally, 
>>there is one service route per contact, and so the REGISTER response 
>>would indicate a service route for each contact in the response. That 
>>would be a big change from whats in the spec now though.
> 
> 
> True. There MIGHT be a difference on the preferred route through the home
> network depending on which visited network (and consequently, Contact) is
> involved. One can envision using a Service Route-like mechanism to assign a
> firewall proxy on a per-contact basis. Such an approach is not supported in
> the current draft, which we might point out has completed WGLC and IETF LC
> and probably shouldn't be changed (especially substantively) unless there's
> a glaring error.
> 
> At about this point I should say "Gee, it would have been nice to be able to
> use a loose-routing syntax in the actual Contact value (and in fact
> everywhere that a URI is given), but that wouldn't have been backward
> compatible."
> 
> 
> Open Question: Is the additional capability being proposed here important
> enough to change the spec at this time, or is it something we should
> consider in future work?

I think we can consider it in the future. You just need to be clear in 
the draft that there is ONE service route across all registered contacts.

Thanks,
Jonathan R.


-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             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 mailnull@www1.ietf.org  Wed Apr 16 04:16:21 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22360
	for <sip-archive@odin.ietf.org>; Wed, 16 Apr 2003 04:16:21 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3G8OrN30492
	for sip-archive@odin.ietf.org; Wed, 16 Apr 2003 04:24:53 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3G8Nv830444;
	Wed, 16 Apr 2003 04:23:58 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3G8HM830144
	for <sip@optimus.ietf.org>; Wed, 16 Apr 2003 04:17: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 EAA21944
	for <sip@ietf.org>; Wed, 16 Apr 2003 04:08:20 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195i0J-0007T1-00
	for sip@ietf.org; Wed, 16 Apr 2003 04:10:51 -0400
Received: from alc136.alcatel.be ([195.207.101.136] helo=bt0g2p.god.bel.alcatel.be)
	by ietf-mx with esmtp (Exim 4.12)
	id 195i0I-0007Sf-00
	for sip@ietf.org; Wed, 16 Apr 2003 04:10:50 -0400
Received: from btm16s.se.bel.alcatel.be (relay3 [127.0.0.1])
	by bt0g2p.god.bel.alcatel.be (8.11.0/8.11.4) with ESMTP id h3G8AOI18315;
	Wed, 16 Apr 2003 10:10:24 +0200
Received: from se.bel.alcatel.be (bt0c2v.ngn.bel.alcatel.be [138.203.208.115]) by btm16s.se.bel.alcatel.be (8.8.8+Sun/8.8.8+SUN) with ESMTP id KAA29717; Wed, 16 Apr 2003 10:10:21 +0200 (MET DST)
Message-ID: <3E9D0FC3.1010900@se.bel.alcatel.be>
Date: Wed, 16 Apr 2003 10:09:39 +0200
From: Erkut CULLUOGLU <culluoge@se.bel.alcatel.be>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dean Willis <dean.willis@softarmor.com>
CC: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>, sip@ietf.org
Subject: Re: [Sip] Question on Service Route Discovery draft and multiple
 contacts per AoR
References: <000001c30370$d5539130$40f30a0a@txdwillis>
Content-Type: multipart/alternative;
 boundary="------------090507060105030901020709"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>



--------------090507060105030901020709
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

just an idea  -> inline

Dean Willis wrote:

>>I would be surprised if its the same. After all, the Contacts 
>>could have 
>>been registered from completely different visited networks. 
>>    
>>
>
>So? The Service-Route does not contain information about the visited network
>-- just information about the home network -- the "specific home proxy or
>network of proxies" from which services are being requested.
>
>See the Applicability Statement:
>
>   2.  The registrar has knowledge of a service proxy that should be
>       used by the UA when requesting services from the domain of the
>       registrar.  This knowledge may be a result of dynamic assignment
>       or some other mechanism outside the scope of this document.
>   3.  The registrar(s) has/have sufficient knowledge of the network
>       topology, policy, and situation such that a reasonable service
>       route can be constructed.
>
>Since one can reasonably assume that the registrar has NO explicit knowledge
>about the foreign/visited network from which the UA registered, the service
>route does not contain data about that network. Clearly the UA and the
>visited network have enough routing data to be able to get a REGISTER
>request to the edge of the home network (since we're building this route in
>the response to that REGISTER request).
>
So we can expect that an Invite request will still be able to arrive to 
the edge-proxy. If we keep the edge-proxy out of the service-route, 
wouldn't it  make the service route for a AoR identical for any
number of contacts? Teorethically isn't it correct to claim that for 
each AoR we'll have the same
route within the home network,  if we can just take out the edge-proxy?

>  
>
>>Ideally, 
>>there is one service route per contact, and so the REGISTER response 
>>would indicate a service route for each contact in the response. That 
>>would be a big change from whats in the spec now though.
>>    
>>
>
>True. There MIGHT be a difference on the preferred route through the home
>network depending on which visited network (and consequently, Contact) is
>involved. One can envision using a Service Route-like mechanism to assign a
>firewall proxy on a per-contact basis. Such an approach is not supported in
>the current draft, which we might point out has completed WGLC and IETF LC
>and probably shouldn't be changed (especially substantively) unless there's
>a glaring error.
>
>At about this point I should say "Gee, it would have been nice to be able to
>use a loose-routing syntax in the actual Contact value (and in fact
>everywhere that a URI is given), but that wouldn't have been backward
>compatible."
>
>
>Open Question: Is the additional capability being proposed here important
>enough to change the spec at this time, or is it something we should
>consider in future work?
>
>--
>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
>
>
>  
>


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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
just an idea &nbsp;-&gt; inline<br>
<br>
Dean Willis wrote:<br>
<blockquote type="cite"
 cite="mid000001c30370$d5539130$40f30a0a@txdwillis">
  <blockquote type="cite">
    <pre wrap="">I would be surprised if its the same. After all, the Contacts 
could have 
been registered from completely different visited networks. 
    </pre>
  </blockquote>
  <pre wrap=""><!---->
So? The Service-Route does not contain information about the visited network
-- just information about the home network -- the "specific home proxy or
network of proxies" from which services are being requested.

See the Applicability Statement:

   2.  The registrar has knowledge of a service proxy that should be
       used by the UA when requesting services from the domain of the
       registrar.  This knowledge may be a result of dynamic assignment
       or some other mechanism outside the scope of this document.
   3.  The registrar(s) has/have sufficient knowledge of the network
       topology, policy, and situation such that a reasonable service
       route can be constructed.

Since one can reasonably assume that the registrar has NO explicit knowledge
about the foreign/visited network from which the UA registered, the service
route does not contain data about that network. Clearly the UA and the
visited network have enough routing data to be able to get a REGISTER
request to the edge of the home network (since we're building this route in
the response to that REGISTER request).</pre>
</blockquote>
So we can expect that an Invite request will still be able to arrive to the
edge-proxy. If we keep the edge-proxy out of the service-route, wouldn't
it&nbsp; make the service route for a AoR identical for any <br>
number of contacts? Teorethically isn't it correct to claim that for each
AoR we'll have the same<br>
route within the home network, &nbsp;if we can just take out the edge-proxy?<br>
<blockquote type="cite"
 cite="mid000001c30370$d5539130$40f30a0a@txdwillis">
  <pre wrap="">
  </pre>
  <blockquote type="cite">
    <pre wrap="">Ideally, 
there is one service route per contact, and so the REGISTER response 
would indicate a service route for each contact in the response. That 
would be a big change from whats in the spec now though.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
True. There MIGHT be a difference on the preferred route through the home
network depending on which visited network (and consequently, Contact) is
involved. One can envision using a Service Route-like mechanism to assign a
firewall proxy on a per-contact basis. Such an approach is not supported in
the current draft, which we might point out has completed WGLC and IETF LC
and probably shouldn't be changed (especially substantively) unless there's
a glaring error.

At about this point I should say "Gee, it would have been nice to be able to
use a loose-routing syntax in the actual Contact value (and in fact
everywhere that a URI is given), but that wouldn't have been backward
compatible."


Open Question: Is the additional capability being proposed here important
enough to change the spec at this time, or is it something we should
consider in future work?

--
Dean

_______________________________________________
Sip mailing list  <a class="moz-txt-link-freetext" href="https://www1.ietf.org/mailman/listinfo/sip">https://www1.ietf.org/mailman/listinfo/sip</a>
This list is for NEW development of the core SIP Protocol
Use <a class="moz-txt-link-abbreviated" href="mailto:sip-implementors@cs.columbia.edu">sip-implementors@cs.columbia.edu</a> for questions on current sip
Use <a class="moz-txt-link-abbreviated" href="mailto:sipping@ietf.org">sipping@ietf.org</a> for new developments on the application of sip


  </pre>
</blockquote>
<br>
</body>
</html>

--------------090507060105030901020709--

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



From mailnull@www1.ietf.org  Wed Apr 16 17:26:42 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17438
	for <sip-archive@odin.ietf.org>; Wed, 16 Apr 2003 17:26:42 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3GLZVW25579
	for sip-archive@odin.ietf.org; Wed, 16 Apr 2003 17:35:31 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GLYf825437;
	Wed, 16 Apr 2003 17:34:41 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GLQM825090
	for <sip@optimus.ietf.org>; Wed, 16 Apr 2003 17:26: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 RAA17210
	for <sip@ietf.org>; Wed, 16 Apr 2003 17:17:03 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195uJa-0003ps-00
	for sip@ietf.org; Wed, 16 Apr 2003 17:19:34 -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 195uJZ-0003pX-00
	for sip@ietf.org; Wed, 16 Apr 2003 17:19:33 -0400
Received: from txdwillis ([216.229.166.130])
	(authenticated bits=0)
	by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h3GLI2sC023665
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO);
	Wed, 16 Apr 2003 16:19:05 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: "'Erkut CULLUOGLU'" <culluoge@se.bel.alcatel.be>
Cc: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>, <sip@ietf.org>
Subject: RE: [Sip] Question on Service Route Discovery draft and multiple contacts per AoR
Date: Wed, 16 Apr 2003 16:17:53 -0500
Message-ID: <000401c3045d$cddda330$adf30a0a@txdwillis>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0005_01C30433.E5079B30"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
In-Reply-To: <3E9D0FC3.1010900@se.bel.alcatel.be>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0005_01C30433.E5079B30
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20
Erkut asked:
---------------------
 So we can expect that an Invite request will still be able to arrive to =
the
edge-proxy. If we keep the edge-proxy out of the service-route, wouldn't =
it
make the service route for a AoR identical for any=20
number of contacts? Teorethically isn't it correct to claim that for =
each
AoR we'll have the same
route within the home network,  if we can just take out the edge-proxy?
 ---------------------
=20
Yes, I think that's what I was trying to say.
=20
The question is, is it worth adding this clarification to the current =
draft?
It coulod be done in Auth-48 with AD approval -- it's not really a =
technical
change, I believe, but it is a substantive clarification.
=20
--
Dean

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

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

<META content=3D"MSHTML 6.00.2800.1141" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D384431321-16042003><FONT face=3DArial color=3D#0000ff =

size=3D2>&nbsp;</FONT></SPAN></DIV>
<DIV><SPAN class=3D384431321-16042003><FONT face=3DArial color=3D#0000ff =
size=3D2>Erkut=20
asked:</FONT></SPAN></DIV>
<DIV><SPAN class=3D384431321-16042003><FONT face=3DArial color=3D#0000ff =

size=3D2>---------------------</FONT></SPAN></DIV>
<DIV><SPAN class=3D384431321-16042003>&nbsp;</SPAN>So we can expect that =
an Invite=20
request will still be able to arrive to the edge-proxy. If we keep the=20
edge-proxy out of the service-route, wouldn't it&nbsp; make the service =
route=20
for a AoR identical for any <BR>number of contacts? Teorethically isn't =
it=20
correct to claim that for each AoR we'll have the same<BR>route within =
the home=20
network, &nbsp;if we can just take out the edge-proxy?<BR><SPAN=20
class=3D384431321-16042003><FONT face=3DArial color=3D#0000ff=20
size=3D2>&nbsp;---------------------</FONT></SPAN></DIV>
<DIV><SPAN class=3D384431321-16042003></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D384431321-16042003><FONT face=3DArial color=3D#0000ff =
size=3D2>Yes, I=20
think that's what I was trying to say.</FONT></SPAN></DIV>
<DIV><SPAN class=3D384431321-16042003></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D384431321-16042003><FONT face=3DArial color=3D#0000ff =
size=3D2>The=20
question is, is it worth adding this clarification to the current =
draft?&nbsp;It=20
coulod be done in Auth-48 with AD approval --&nbsp;it's not really a =
technical=20
</FONT></SPAN><SPAN class=3D384431321-16042003>&nbsp;<FONT face=3DArial=20
color=3D#0000ff size=3D2>change, I believe, but it is a substantive=20
clarification.</FONT></SPAN></DIV>
<DIV><SPAN class=3D384431321-16042003><FONT face=3DArial color=3D#0000ff =

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

size=3D2>--<BR>Dean</FONT></SPAN></DIV></BODY></HTML>

------=_NextPart_000_0005_01C30433.E5079B30--

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



From mailnull@www1.ietf.org  Thu Apr 17 16:05:06 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05722
	for <sip-archive@odin.ietf.org>; Thu, 17 Apr 2003 16:05:05 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3HKELe04310
	for sip-archive@odin.ietf.org; Thu, 17 Apr 2003 16:14:21 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HKDk804266;
	Thu, 17 Apr 2003 16:13:46 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HK7v804060
	for <sip@optimus.ietf.org>; Thu, 17 Apr 2003 16:07: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 PAA05547
	for <sip@ietf.org>; Thu, 17 Apr 2003 15:58:12 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196FYk-0002Fg-00
	for sip@ietf.org; Thu, 17 Apr 2003 16:00:39 -0400
Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 196FYk-0002FL-00
	for sip@ietf.org; Thu, 17 Apr 2003 16:00:38 -0400
Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39])
	by ihemail1.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3HK0Lj03563;
	Thu, 17 Apr 2003 16:00:21 -0400 (EDT)
Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id PAA02217; Thu, 17 Apr 2003 15:00:21 -0500 (CDT)
Message-ID: <3E9F0772.7070705@lucent.com>
Date: Thu, 17 Apr 2003 14:58:42 -0500
From: "Vijay K. Gurbani" <vkg@lucent.com>
Organization: Lucent Technologies, Inc./Bell Laboratories
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ashish Naik <ashishn@mahindrabt.com>
CC: "Sip@Ietf. Org" <sip@ietf.org>
Subject: Re: [Sip] Presence architecture for fixed line network
References: <NFBBIJAAOFNEMIHBIFPIIEJDDHAA.ashishn@mahindrabt.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

Ashish Naik wrote:
> Can someone point me to an architecture documents of SIP based presence 
> architecture in fixed line network ?
>  
> I want to know which network elements will be part of this as compared 
> to presence server in 3G networks.

Take a look at some of the work in the SPIRITS WG:

http://www.ietf.org/internet-drafts/draft-gurbani-spirits-implementation-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-spirits-protocol-04.txt

Regards,

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

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



From mailnull@www1.ietf.org  Fri Apr 18 02:21:03 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03665
	for <sip-archive@odin.ietf.org>; Fri, 18 Apr 2003 02:21:03 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3I6UU222024
	for sip-archive@odin.ietf.org; Fri, 18 Apr 2003 02:30:30 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I6U3822004;
	Fri, 18 Apr 2003 02:30:03 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I6M2821564
	for <sip@optimus.ietf.org>; Fri, 18 Apr 2003 02:22: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 CAA02825
	for <sip@ietf.org>; Fri, 18 Apr 2003 02:12:05 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196P8p-0005Af-00
	for sip@ietf.org; Fri, 18 Apr 2003 02:14:31 -0400
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 196P8o-0005AE-00
	for sip@ietf.org; Fri, 18 Apr 2003 02:14:30 -0400
Received: from dynamicsoft.com ([63.113.46.20])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h3I6EFBd019130;
	Fri, 18 Apr 2003 02:14:16 -0400 (EDT)
Message-ID: <3E9F97B2.4050707@dynamicsoft.com>
Date: Fri, 18 Apr 2003 02:14:10 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Vijay K. Gurbani" <vkg@lucent.com>
CC: Ashish Naik <ashishn@mahindrabt.com>, "Sip@Ietf. Org" <sip@ietf.org>
Subject: Re: [Sip] Presence architecture for fixed line network
References: <NFBBIJAAOFNEMIHBIFPIIEJDDHAA.ashishn@mahindrabt.com> <3E9F0772.7070705@lucent.com>
In-Reply-To: <3E9F0772.7070705@lucent.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Vijay, I'm confused.

Last I checked, draft-ietf-simple-presence discussed presence, and to my 
knowledge it wasnt specific to wireline or wireless, but to any network 
that used IP. I am not sure what relation spirits has. I certainly hope 
you are not proposing that spirits represents a presence protocol 
specific for wireline?

-Jonathan R.

Vijay K. Gurbani wrote:
> Ashish Naik wrote:
> 
>> Can someone point me to an architecture documents of SIP based 
>> presence architecture in fixed line network ?
>>  
>> I want to know which network elements will be part of this as compared 
>> to presence server in 3G networks.
> 
> 
> Take a look at some of the work in the SPIRITS WG:
> 
> http://www.ietf.org/internet-drafts/draft-gurbani-spirits-implementation-00.txt 
> 
> http://www.ietf.org/internet-drafts/draft-ietf-spirits-protocol-04.txt
> 
> Regards,
> 
> - vijay

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             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 mailnull@www1.ietf.org  Fri Apr 18 05:42:27 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07050
	for <sip-archive@odin.ietf.org>; Fri, 18 Apr 2003 05:42:27 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3I9px102153
	for sip-archive@odin.ietf.org; Fri, 18 Apr 2003 05:51:59 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I9pL802141;
	Fri, 18 Apr 2003 05:51:21 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I9iG801976
	for <sip@optimus.ietf.org>; Fri, 18 Apr 2003 05:44:16 -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 FAA06925
	for <sip@ietf.org>; Fri, 18 Apr 2003 05:34:13 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196SIS-00066T-00
	for sip@ietf.org; Fri, 18 Apr 2003 05:36:40 -0400
Received: from [61.144.161.2] (helo=mta0)
	by ietf-mx with esmtp (Exim 4.12)
	id 196SIQ-00066Q-00
	for sip@ietf.org; Fri, 18 Apr 2003 05:36:39 -0400
Received: from Natarajucl1127 (mta0 [172.17.1.62])
 by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
 2002)) with ESMTPA id <0HDJ001V28JXWN@mta0.huawei.com> for sip@ietf.org; Fri,
 18 Apr 2003 17:19:11 +0800 (CST)
Date: Fri, 18 Apr 2003 14:50:29 +0530
From: "Nataraju A.B." <natarajuab@huawei.com>
Subject: Re: [Sip] [Fwd: CSPS v2.0 - Register problem]
To: Paraskevopoulos Pavlos <ppar@intracom.gr>, sip@ietf.org
Message-id: <00d501c3058b$c1c82be0$5d02120a@in.huawei.com>
Organization: HTIPL
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
Content-type: multipart/alternative;
 boundary="Boundary_(ID_We70uaVbx9Aa9u3opYqSzQ)"
X-Priority: 3
X-MSMail-priority: Normal
References: <3E9C477D.8030608@intracom.gr>
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-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_We70uaVbx9Aa9u3opYqSzQ)
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7BIT

Can This be possible ???

What I understood is UAS reply back with 200 OK only after all the necessay steps have been taken against that registration request. 

I feel this can happen only when you send a REGISTER request to multicast server (not in case of Unicast servers) . 
In that case the 1st final response will be considered and later ones will be discardeed.

Regards,
-Nataraju A.B.
  ----- Original Message ----- 
  From: Paraskevopoulos Pavlos 
  To: sip@ietf.org 
  Sent: Tuesday, April 15, 2003 11:25 PM
  Subject: [Sip] [Fwd: CSPS v2.0 - Register problem]




  Hi all,

  I have a problem considering Registration while I' m working with Cisco 
  SIP Proxy Server ver.2.0 (CSPS).

  My REGISTER message is the following

  REGISTER sip:VOICE.SPDOP.RU SIP/2.0
  Max-Forwards: 70
  Via: SIP/2.0/UDP 10.100.1.165:5060
  From: <sip:9505065@VOICE.SPDOP.RU>;tag=14713
  To: <sip:9505065@VOICE.SPDOP.RU>
  Call-ID: 6948@10.100.1.165
  CSeq: 1 REGISTER
  Contact: <sip:9505065@10.100.1.165:5060>
  Expires: 180
  User-Agent: netPhone-010107A
  Content-Length: 0

  And the Proxy responds the following

  SIP/2.0 100 Trying
  Via: SIP/2.0/UDP 10.100.1.165:5060;received=10.100.1.165
  Call-ID: 6948@10.100.1.165
  From: <sip:9505065@VOICE.SPDOP.RU>;tag=14713
  To: <sip:9505065@VOICE.SPDOP.RU>
  CSeq: 1 REGISTER
  Content-Length: 0

  SIP/2.0 200 OK
  Via: SIP/2.0/UDP 10.100.1.165:5060;received=10.100.1.165
  Call-ID: 6948@10.100.1.165
  From: <sip:9505065@VOICE.SPDOP.RU>;tag=14713
  To: <sip:9505065@VOICE.SPDOP.RU>
  CSeq: 1 REGISTER
  Contact: <sip:9505065@10.100.1.165:5060>;expires="Thu, 10 Apr 2003 
  23:53:57 GMT"
  Expires: 180
  Content-Length: 0

  SIP/2.0 400 Error in Headers
  Via: SIP/2.0/UDP 10.100.1.165:5060;received=10.100.1.165
  Call-ID: 6948@10.100.1.165
  From: <sip:9505065@VOICE.SPDOP.RU>;tag=14713
  To: <sip:9505065@VOICE.SPDOP.RU>
  CSeq: 1 REGISTER
  Contact: <sip:9505065@10.100.1.165:5060>;expires="Thu, 10 Apr 2003 
  23:53:57 GMT"
  Expires: 180
  Content-Length: 0


  Could anyone help me?
  I have used several other proxies including  ser and everything was fine.


  Thanks in advance.

  Pavlos Paraskevopoulos (www.intracom.gr)



  _______________________________________________
  Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
  This list is for NEW development of the core SIP 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_We70uaVbx9Aa9u3opYqSzQ)
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: #000080; FONT-FAMILY: Times New Roman" bgColor=#ffffff>
<DIV>Can This be possible ???</DIV>
<DIV>&nbsp;</DIV>
<DIV>What&nbsp;I understood is UAS reply back with 200 OK only after all the 
necessay steps have been taken against that registration request. </DIV>
<DIV>&nbsp;</DIV>
<DIV>I feel this can happen only when you send a REGISTER request to multicast 
server (not in case of Unicast servers) . </DIV>
<DIV>In that case the 1st final response will be considered and later ones will 
be discardeed.</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>Regards,<BR>-Nataraju A.B.</FONT></DIV>
<BLOCKQUOTE 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000080 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=ppar@intracom.gr href="mailto:ppar@intracom.gr">Paraskevopoulos 
  Pavlos</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> Tuesday, April 15, 2003 11:25 
  PM</DIV>
  <DIV style="FONT: 10pt arial"><B>Subject:</B> [Sip] [Fwd: CSPS v2.0 - Register 
  problem]</DIV>
  <DIV><BR></DIV><BR><BR>Hi all,<BR><BR>I have a problem considering 
  Registration while I' m working with Cisco <BR>SIP Proxy Server ver.2.0 
  (CSPS).<BR><BR>My REGISTER message is the following<BR><BR>REGISTER 
  sip:VOICE.SPDOP.RU SIP/2.0<BR>Max-Forwards: 70<BR>Via: SIP/2.0/UDP 
  10.100.1.165:5060<BR>From: &lt;sip:9505065@VOICE.SPDOP.RU&gt;;tag=14713<BR>To: 
  &lt;sip:9505065@VOICE.SPDOP.RU&gt;<BR>Call-ID: <A 
  href="mailto:6948@10.100.1.165">6948@10.100.1.165</A><BR>CSeq: 1 
  REGISTER<BR>Contact: &lt;sip:9505065@10.100.1.165:5060&gt;<BR>Expires: 
  180<BR>User-Agent: netPhone-010107A<BR>Content-Length: 0<BR><BR>And the Proxy 
  responds the following<BR><BR>SIP/2.0 100 Trying<BR>Via: SIP/2.0/UDP 
  10.100.1.165:5060;received=10.100.1.165<BR>Call-ID: <A 
  href="mailto:6948@10.100.1.165">6948@10.100.1.165</A><BR>From: 
  &lt;sip:9505065@VOICE.SPDOP.RU&gt;;tag=14713<BR>To: 
  &lt;sip:9505065@VOICE.SPDOP.RU&gt;<BR>CSeq: 1 REGISTER<BR>Content-Length: 
  0<BR><BR>SIP/2.0 200 OK<BR>Via: SIP/2.0/UDP 
  10.100.1.165:5060;received=10.100.1.165<BR>Call-ID: <A 
  href="mailto:6948@10.100.1.165">6948@10.100.1.165</A><BR>From: 
  &lt;sip:9505065@VOICE.SPDOP.RU&gt;;tag=14713<BR>To: 
  &lt;sip:9505065@VOICE.SPDOP.RU&gt;<BR>CSeq: 1 REGISTER<BR>Contact: 
  &lt;sip:9505065@10.100.1.165:5060&gt;;expires="Thu, 10 Apr 2003 <BR>23:53:57 
  GMT"<BR>Expires: 180<BR>Content-Length: 0<BR><BR>SIP/2.0 400 Error in 
  Headers<BR>Via: SIP/2.0/UDP 
  10.100.1.165:5060;received=10.100.1.165<BR>Call-ID: <A 
  href="mailto:6948@10.100.1.165">6948@10.100.1.165</A><BR>From: 
  &lt;sip:9505065@VOICE.SPDOP.RU&gt;;tag=14713<BR>To: 
  &lt;sip:9505065@VOICE.SPDOP.RU&gt;<BR>CSeq: 1 REGISTER<BR>Contact: 
  &lt;sip:9505065@10.100.1.165:5060&gt;;expires="Thu, 10 Apr 2003 <BR>23:53:57 
  GMT"<BR>Expires: 180<BR>Content-Length: 0<BR><BR><BR>Could anyone help 
  me?<BR>I have used several other proxies including&nbsp; ser and everything 
  was fine.<BR><BR><BR>Thanks in advance.<BR><BR>Pavlos Paraskevopoulos (<A 
  href="http://www.intracom.gr">www.intracom.gr</A>)<BR><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</BLOCKQUOTE></BODY></HTML>

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



From mailnull@www1.ietf.org  Fri Apr 18 11:51:34 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17744
	for <sip-archive@odin.ietf.org>; Fri, 18 Apr 2003 11:51:34 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3IG1EZ25305
	for sip-archive@odin.ietf.org; Fri, 18 Apr 2003 12:01:14 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IG0I825155;
	Fri, 18 Apr 2003 12:00:18 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IFnD824523
	for <sip@optimus.ietf.org>; Fri, 18 Apr 2003 11: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 LAA17417
	for <sip@ietf.org>; Fri, 18 Apr 2003 11:39:03 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196XzW-0000Ei-00
	for sip@ietf.org; Fri, 18 Apr 2003 11:41:30 -0400
Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 196XzV-0000EZ-00
	for sip@ietf.org; Fri, 18 Apr 2003 11:41:29 -0400
Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39])
	by hoemail2.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3IFfC214955;
	Fri, 18 Apr 2003 11:41:12 -0400 (EDT)
Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id KAA02684; Fri, 18 Apr 2003 10:41:12 -0500 (CDT)
Message-ID: <3EA01C33.1030008@lucent.com>
Date: Fri, 18 Apr 2003 10:39:31 -0500
From: "Vijay K. Gurbani" <vkg@lucent.com>
Organization: Lucent Technologies, Inc./Bell Laboratories
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: Ashish Naik <ashishn@mahindrabt.com>, "Sip@Ietf. Org" <sip@ietf.org>
Subject: Re: [Sip] Presence architecture for fixed line network
References: <NFBBIJAAOFNEMIHBIFPIIEJDDHAA.ashishn@mahindrabt.com> <3E9F0772.7070705@lucent.com> <3E9F97B2.4050707@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:
> Vijay, I'm confused.
> 
> Last I checked, draft-ietf-simple-presence discussed presence, and to my 
> knowledge it wasnt specific to wireline or wireless, but to any network 
> that used IP. I am not sure what relation spirits has. I certainly hope 
> you are not proposing that spirits represents a presence protocol 
> specific for wireline?

Heavens, no.  The original poster wanted to know which network
elements may contribute to the derivation of presence information
for fixed-line networks; and that's where the tie-in to SPIRITS
comes in.

Rest assured, I am not proposing yet another presence protocol for
wireline networks.  In fact, if you skim over my implementation
I-D, I reuse the application/cpim+pidf MIME type and all the other
work in IMPP and SIMPLE WGs.

Regards,

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

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



From mailnull@www1.ietf.org  Fri Apr 18 18:39:17 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00046
	for <sip-archive@odin.ietf.org>; Fri, 18 Apr 2003 18:39:17 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3IMmC619808
	for sip-archive@odin.ietf.org; Fri, 18 Apr 2003 18:48:12 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IMlR819793;
	Fri, 18 Apr 2003 18:47:27 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IMcw819609
	for <sip@optimus.ietf.org>; Fri, 18 Apr 2003 18:38: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 SAA29825
	for <sip@ietf.org>; Fri, 18 Apr 2003 18:28:39 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196eNu-0001oB-00
	for sip@ietf.org; Fri, 18 Apr 2003 18:31:06 -0400
Received: from mail1.acmepacket.com ([63.67.143.10] helo=acmepacket.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 196eNt-0001o8-00
	for sip@ietf.org; Fri, 18 Apr 2003 18:31:05 -0400
Received: from BPenfield [127.0.0.1] by acmepacket.com
  (SMTPD32-7.14) id ACA664EF03D4; Fri, 18 Apr 2003 18:31:02 -0400
Message-ID: <000701c305fa$292acea0$2300000a@BPenfield>
From: "Bob Penfield" <bpenfield@acmepacket.com>
To: <sip@ietf.org>
Cc: "Henning Schulzrinne" <schulzrinne@cs.columbia.edu>,
        "Paul Kyzivat" <pkyzivat@cisco.com>,
        "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>
Date: Fri, 18 Apr 2003 18:30:48 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2720.3000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Subject: [Sip] review of draft-ietf-sip-caller-prefs-08.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

Here are my comments caller prefs draft. I apologize for their 
tardiness.

The only technical issue is the processing of require and explicit 
tags (see item 12 below). The spec says that the explicit flag is
checked first and then the require flag. It seems to me it should
be the other way around.

The rest of the items are inconsistencies in requirements, some
suggestions for improving the readability/usability of the spec,
and typos.

1) Page 7: Insert "the" or "a" between "describes" and "full" in
the last line of the "Feature Set" definition.

2) The concept of base-tags (and using "+" for other tags) is not
mentioned until section 7.2.1. I think they should be mentioned in 
the overview, or at least the first time the spec talks about what 
feature tags can be used (section 6.1).

3) In section 6.2, it says "Proxy-Require: pref" MAY be included, 
but in the very next sentence it says that it is NOT RECOMMENDED.
This seems to be a conflict as "MAY" is not equivalent to "NOT 
RECOMMENDED". I personally prefer NOT RECOMMENDED. I suggest text 
along the lines of:

    A UAC SHOULD NOT include a Proxy-Require header with a
    value of "pref" unless it is reasonably certain that all
    proxies along the path between the UAC and the proxy
    responsible for the domain of Request-URI support the
    "pref" extension.

4) Section 6.2.2 says "Each feature set MUST follow the 
constraints of section 6.1". However, not all the requirements 
in section 6.1 apply to Feature Set Preferences. I recommend that 
the 3rd and 4th paragraphs on page 12, and the 2nd and 3rd 
paragraph on page 13 be placed in a separate Feature Set 
Constraints section preceding the existing section 6.1, and 
have 6.1 and 6.2.2 refer to the new section. However, the 
requirement in the 2nd paragraph on page 13 for the UA to "list 
all values it supports" does need to be reworded to say that when 
expressing capabilities it must list all values that it supports 
and when expressing preferences it must list all values it 
desires.

5) The last sentence of the 2nd paragraph of section 6.2.2 repeats 
a requirement in 6.1 and can be removed.

6) Suggest including a sample Accept-Contact and/or Reject-Contact 
in section 6.2.2 to help in understanding feature set preferences.

7) Suggest including a reference to sections 8, 8.2 and 10 in 
section 6.2.2 (similar to that in 6.2.1 for Request-Disposition).

8) Should the requirement for using different contact URIs (3rd 
paragraph of section 6.4) be in section 6.1 since it applies to 
expressing capabilities in a registration?

9) The two requirements in the 2nd paragraph of section 7 are 
confusing to me. The first states that a proxy may add a value to 
an existing header field, but the second says that a proxy must 
not modify an existing header field.

10) In section 7.2, it says "SHOULD apply the processing in this 
section" and "MUST do so as described below". When I first read 
it, I interpreted it to mean section 7.2 (which encompasses 7.2.1, 
7.2.2, and 7.2.2.1 too), but clearly section 7.3 and 7.4 also 
apply. You may want to explicitly enumerate the required sections 
or renumber them such that they all fall within 7.2.

11) The last paragraph on page 22 uses the term "contact set" 
rather than "target set". Should it be "target set"?

12) Page 23 & Figure 1: Shouldn't the require tag be checked first 
rather than the explicit flag? On page 15 it says:

    If one of the values contains the "require" parameter,
    it means that the UA must match that value.

In the example in section 7.4.1, u2 is discarded because the first 
predicate has a require tag. However, if you follow the flow 
chart, u2 would get a score of 0. In order to make my test program 
generate the same results as in the example, I had to check the 
require flag first.

13) The tables in section 8 indicates that a proxy may add and/or 
remove Accept_Contact, Reject-Contact, and Request-Disposition 
headers, but the text in section 7 says a proxy MUST NOT remove 
the header values.

14) Section 9 says "new media feature tags MAY be registered with 
IANA". Given the requirements in section 6.1, shouldn't this say 
"New media feature tags MAY be defined and they MUST be registered 
with IANA"?

15) Section 9: For those feature tags whose values are defined in 
an IANA registry, the specific registry should be referenced to 
find the appropriate values for the tag (as suggested by RFC 
2506). Section 9.13 needs to refer to the IANA "SIP Parameters - 
Methods" registry for valid method names. Section 9.14 (SIP 
Extensions) does explicitly mention IANA and section 9.11 (Event 
Package) mentions "event packages that are registered", but does 
not mention IANA.

16) Page 46: Should [/ ""' /] be [/ "'" /] in the BNF for 
"ftag-name"?

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
bpenfield@acmepacket.com



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



From mailnull@www1.ietf.org  Sun Apr 20 01:47:14 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17952
	for <sip-archive@odin.ietf.org>; Sun, 20 Apr 2003 01:47:14 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3K5vel30293
	for sip-archive@odin.ietf.org; Sun, 20 Apr 2003 01:57:40 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3K5v1830281;
	Sun, 20 Apr 2003 01:57:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3K5j7830072
	for <sip@optimus.ietf.org>; Sun, 20 Apr 2003 01:45: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 BAA17693
	for <sip@ietf.org>; Sun, 20 Apr 2003 01:34:01 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1977V3-0001Ez-00
	for sip@ietf.org; Sun, 20 Apr 2003 01:36:25 -0400
Received: from sj-core-2.cisco.com ([171.71.177.254])
	by ietf-mx with esmtp (Exim 4.12)
	id 1977V3-0001Ew-00
	for sip@ietf.org; Sun, 20 Apr 2003 01:36:25 -0400
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.6/8.12.6) with ESMTP id h3K5a1gE009051;
	Sat, 19 Apr 2003 22:36:02 -0700 (PDT)
Received: from cisco.com (sjc-vpn2-492.cisco.com [10.21.113.236])
	by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR)
	with ESMTP id ADJ79458;
	Sat, 19 Apr 2003 22:36:00 -0700 (PDT)
Date: Sat, 19 Apr 2003 22:35:59 -0700
Subject: Re: [Sip] [Fwd: CSPS v2.0 - Register problem]
Content-Type: multipart/alternative; boundary=Apple-Mail-10--504684618
Mime-Version: 1.0 (Apple Message framework v552)
Cc: Cullen Jennings <fluffy@cisco.com>,
        Paraskevopoulos Pavlos <ppar@intracom.gr>, sip@ietf.org
To: "Nataraju A.B." <natarajuab@huawei.com>
From: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <00d501c3058b$c1c82be0$5d02120a@in.huawei.com>
Message-Id: <F761CCF2-72F1-11D7-974A-000A95A0E128@cisco.com>
X-Mailer: Apple Mail (2.552)
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>


--Apple-Mail-10--504684618
Content-Type: text/plain;
	charset=ISO-8859-1;
	format=flowed
Content-Transfer-Encoding: quoted-printable


Nope, sending two final responses for one transaction is definitely=20
wrong. Since it's just a bug in Cisco's proxy, let's move the=20
discussion off this email list.


On Friday, April 18, 2003, at 02:20 AM, Nataraju A.B. wrote:

> Can This be possible ???
> =A0
> What=A0I understood is UAS reply back with 200 OK only after all the=20=

> necessay steps have been taken against that registration request.
> =A0
> I feel this can happen only when you send a REGISTER request to=20
> multicast server (not in case of Unicast servers) .
> In that case the 1st final response will be considered and later ones=20=

> will be discardeed.
> =A0
> Regards,
> -Nataraju A.B.
>
> ----- Original Message -----
> From: Paraskevopoulos Pavlos
> To: sip@ietf.org
> Sent: Tuesday, April 15, 2003 11:25 PM
> Subject: [Sip] [Fwd: CSPS v2.0 - Register problem]
>
>
>
> Hi all,
>
> I have a problem considering Registration while I' m working with =
Cisco
> SIP Proxy Server ver.2.0 (CSPS).
>
> My REGISTER message is the following
>
> REGISTER sip:VOICE.SPDOP.RU SIP/2.0
> Max-Forwards: 70
> Via: SIP/2.0/UDP 10.100.1.165:5060
> From: <sip:9505065@VOICE.SPDOP.RU>;tag=3D14713
> To: <sip:9505065@VOICE.SPDOP.RU>
> Call-ID: 6948@10.100.1.165
> CSeq: 1 REGISTER
> Contact: <sip:9505065@10.100.1.165:5060>
> Expires: 180
> User-Agent: netPhone-010107A
> Content-Length: 0
>
> And the Proxy responds the following
>
> SIP/2.0 100 Trying
> Via: SIP/2.0/UDP 10.100.1.165:5060;received=3D10.100.1.165
> Call-ID: 6948@10.100.1.165
> From: <sip:9505065@VOICE.SPDOP.RU>;tag=3D14713
> To: <sip:9505065@VOICE.SPDOP.RU>
> CSeq: 1 REGISTER
> Content-Length: 0
>
> SIP/2.0 200 OK
> Via: SIP/2.0/UDP 10.100.1.165:5060;received=3D10.100.1.165
> Call-ID: 6948@10.100.1.165
> From: <sip:9505065@VOICE.SPDOP.RU>;tag=3D14713
> To: <sip:9505065@VOICE.SPDOP.RU>
> CSeq: 1 REGISTER
> Contact: <sip:9505065@10.100.1.165:5060>;expires=3D"Thu, 10 Apr 2003
> 23:53:57 GMT"
> Expires: 180
> Content-Length: 0
>
> SIP/2.0 400 Error in Headers
> Via: SIP/2.0/UDP 10.100.1.165:5060;received=3D10.100.1.165
> Call-ID: 6948@10.100.1.165
> From: <sip:9505065@VOICE.SPDOP.RU>;tag=3D14713
> To: <sip:9505065@VOICE.SPDOP.RU>
> CSeq: 1 REGISTER
> Contact: <sip:9505065@10.100.1.165:5060>;expires=3D"Thu, 10 Apr 2003
> 23:53:57 GMT"
> Expires: 180
> Content-Length: 0
>
>
> Could anyone help me?
> I have used several other proxies including=A0 ser and everything was=20=

> fine.
>
>
> Thanks in advance.
>
> Pavlos Paraskevopoulos (www.intracom.gr)
>
>
>
> _______________________________________________
> Sip mailing list=A0 https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>

--Apple-Mail-10--504684618
Content-Type: text/enriched;
	charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Nope, sending two final responses for one transaction is definitely
wrong. Since it's just a bug in Cisco's proxy, let's move the
discussion off this email list.=20



On Friday, April 18, 2003, at 02:20 AM, Nataraju A.B. wrote:


<excerpt>Can This be possible ???

=A0

What=A0I understood is UAS reply back with 200 OK only after all the
necessay steps have been taken against that registration request.

=A0

I feel this can happen only when you send a REGISTER request to
multicast server (not in case of Unicast servers) .

In that case the 1st final response will be considered and later ones
will be discardeed.

=A0

<fontfamily><param>Arial</param><smaller>Regards,

-Nataraju A.B.</smaller></fontfamily>


----- Original Message -----

<bold>From:</bold>
<underline><color><param>1999,1999,FFFF</param>Paraskevopoulos =
Pavlos</color></underline>

<bold>To:</bold>
=
<underline><color><param>1999,1999,FFFF</param>sip@ietf.org</color></under=
line>

<bold>Sent:</bold> Tuesday, April 15, 2003 11:25 PM

<bold>Subject:</bold> [Sip] [Fwd: CSPS v2.0 - Register problem]




Hi all,


I have a problem considering Registration while I' m working with Cisco

SIP Proxy Server ver.2.0 (CSPS).


My REGISTER message is the following


REGISTER sip:VOICE.SPDOP.RU SIP/2.0

Max-Forwards: 70

Via: SIP/2.0/UDP 10.100.1.165:5060

From: <<sip:9505065@VOICE.SPDOP.RU>;tag=3D14713

To: <<sip:9505065@VOICE.SPDOP.RU>

Call-ID:
<underline><color><param>1999,1999,FFFF</param>6948@10.100.1.165

</color></underline>CSeq: 1 REGISTER

Contact: <<sip:9505065@10.100.1.165:5060>

Expires: 180

User-Agent: netPhone-010107A

Content-Length: 0


And the Proxy responds the following


SIP/2.0 100 Trying

Via: SIP/2.0/UDP 10.100.1.165:5060;received=3D10.100.1.165

Call-ID:
<underline><color><param>1999,1999,FFFF</param>6948@10.100.1.165

</color></underline>From: <<sip:9505065@VOICE.SPDOP.RU>;tag=3D14713

To: <<sip:9505065@VOICE.SPDOP.RU>

CSeq: 1 REGISTER

Content-Length: 0


SIP/2.0 200 OK

Via: SIP/2.0/UDP 10.100.1.165:5060;received=3D10.100.1.165

Call-ID:
<underline><color><param>1999,1999,FFFF</param>6948@10.100.1.165

</color></underline>From: <<sip:9505065@VOICE.SPDOP.RU>;tag=3D14713

To: <<sip:9505065@VOICE.SPDOP.RU>

CSeq: 1 REGISTER

Contact: <<sip:9505065@10.100.1.165:5060>;expires=3D"Thu, 10 Apr 2003

23:53:57 GMT"

Expires: 180

Content-Length: 0


SIP/2.0 400 Error in Headers

Via: SIP/2.0/UDP 10.100.1.165:5060;received=3D10.100.1.165

Call-ID:
<underline><color><param>1999,1999,FFFF</param>6948@10.100.1.165

</color></underline>From: <<sip:9505065@VOICE.SPDOP.RU>;tag=3D14713

To: <<sip:9505065@VOICE.SPDOP.RU>

CSeq: 1 REGISTER

Contact: <<sip:9505065@10.100.1.165:5060>;expires=3D"Thu, 10 Apr 2003

23:53:57 GMT"

Expires: 180

Content-Length: 0



Could anyone help me?

I have used several other proxies including=A0 ser and everything was
fine.



Thanks in advance.


Pavlos Paraskevopoulos
=
(<underline><color><param>1999,1999,FFFF</param>www.intracom.gr</color></u=
nderline>)




_______________________________________________

Sip mailing list=A0
=
<underline><color><param>1999,1999,FFFF</param>https://www1.ietf.org/mailm=
an/listinfo/sip

</color></underline>This list is for NEW development of the core SIP
Protocol

Use
=
<underline><color><param>1999,1999,FFFF</param>sip-implementors@cs.columbi=
a.edu</color></underline>
for questions on current sip

Use
=
<underline><color><param>1999,1999,FFFF</param>sipping@ietf.org</color></u=
nderline> for
new developments on the application of sip


</excerpt>=

--Apple-Mail-10--504684618--

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



From mailnull@www1.ietf.org  Mon Apr 21 13:26:32 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23088
	for <sip-archive@odin.ietf.org>; Mon, 21 Apr 2003 13:26:32 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3LHbfW14437
	for sip-archive@odin.ietf.org; Mon, 21 Apr 2003 13:37:41 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LHaf813519;
	Mon, 21 Apr 2003 13:36:41 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LHHh812895
	for <sip@optimus.ietf.org>; Mon, 21 Apr 2003 13:17: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 NAA22497
	for <sip@ietf.org>; Mon, 21 Apr 2003 13:06:04 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 197emI-0001aP-00
	for sip@ietf.org; Mon, 21 Apr 2003 13:08:26 -0400
Received: from rtp-core-2.cisco.com ([64.102.124.13])
	by ietf-mx with esmtp (Exim 4.12)
	id 197emH-0001a6-00
	for sip@ietf.org; Mon, 21 Apr 2003 13:08:25 -0400
Received: from cannon.cisco.com (IDENT:mirapoint@cannon.cisco.com [161.44.118.24])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h3LH7wRP000155;
	Mon, 21 Apr 2003 13:07:58 -0400 (EDT)
Received: from cisco.com ([161.44.79.220])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id ABH66215;
	Mon, 21 Apr 2003 13:16:45 -0400 (EDT)
Message-ID: <3EA4256D.9000405@cisco.com>
Date: Mon, 21 Apr 2003 13:07:57 -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: Bob Penfield <bpenfield@acmepacket.com>
CC: sip@ietf.org, Henning Schulzrinne <schulzrinne@cs.columbia.edu>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>
References: <000701c305fa$292acea0$2300000a@BPenfield>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Re: review of draft-ietf-sip-caller-prefs-08.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



Bob Penfield wrote:
> 
> 14) Section 9 says "new media feature tags MAY be registered with 
> IANA". Given the requirements in section 6.1, shouldn't this say 
> "New media feature tags MAY be defined and they MUST be registered 
> with IANA"?

Bob,

Section 6.1 points out that feature tags from any of the various trees 
defined in RFC 2506 may be used. Some of those require registration, but 
not all of them.

Perhaps section 9 should be saying that new base-tags may be registered 
with IANA. Or maybe this is adequately covered elsewhere and nothing 
need be said about it 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 mailnull@www1.ietf.org  Mon Apr 21 18:25:49 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05945
	for <sip-archive@odin.ietf.org>; Mon, 21 Apr 2003 18:25:49 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3LMb4v01574
	for sip-archive@odin.ietf.org; Mon, 21 Apr 2003 18:37:04 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LMaZ801449;
	Mon, 21 Apr 2003 18:36:35 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LMSu801202
	for <sip@optimus.ietf.org>; Mon, 21 Apr 2003 18:28: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 SAA05871
	for <sip@ietf.org>; Mon, 21 Apr 2003 18:17:11 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 197jdM-0003wu-00
	for sip@ietf.org; Mon, 21 Apr 2003 18:19:32 -0400
Received: from magus.nostrum.com ([208.21.192.130] ident=root)
	by ietf-mx with esmtp (Exim 4.12)
	id 197jdL-0003wr-00
	for sip@ietf.org; Mon, 21 Apr 2003 18:19:32 -0400
Received: from localhost (root@localhost [127.0.0.1])
	by magus.nostrum.com (8.12.8/8.12.8) with ESMTP id h3LMIgS3000736;
	Mon, 21 Apr 2003 17:18:43 -0500 (CDT)
From: Ben Campbell <bcampbell@dynamicsoft.com>
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        Paul Kyzivat <pkyzivat@cisco.com>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Cc: sip <sip@ietf.org>
Content-Type: text/plain
Message-Id: <1050963502.2816.73.camel@verite.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 21 Apr 2003 17:18:22 -0500
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] callerprefs: Various
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-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

Here is the beginning of my review of draft-ietf-sip-callerprefs-08.txt.
Adam and Cullen's approach of separating major issues in SIMPLE seemed
to work well, so I will follow the same approach here. This email talks
about nits and typos. I will send a separate note for each issue that I
think might warrant discussion.

------------------------------------

 
Inclusion of summary of feature tag concepts: While I appreciate this
convenience, it always worries me to copy or summarize
normative text from another document. In the event of a conflict between this summary
and the referenced text, who wins? Surely it is the referenced text--but implementers may
attempt to implement this without reading that text. (It is bad enough when people
try to implement examples rather than specification)

6.1p4: 

6.1 Register Example: The example is inconsistent on whether a boolean tag has an explicit "true/false"
value, or simple exists. I do not understand the semantic difference between the two syntaxes.

7.4p8 - missing word: ...predicate [in] the contact's matching set.

7.4p8&9 (and surrounding) - This is pretty hard to digest. Listing it stepwise might help.

7.4p15 : s/prefentially/preferentially

12p3: So, if I do a query register, would I expect to get back the feature sets contained in any
registered contacts? If so, then worrying about protecting it in the original request does not seem
particularly useful.

16 ref 3: Is this really a normative reference? Also, no author listing.


                                

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



From mailnull@www1.ietf.org  Mon Apr 21 18:32:21 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06218
	for <sip-archive@odin.ietf.org>; Mon, 21 Apr 2003 18:32:21 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3LMhaH02555
	for sip-archive@odin.ietf.org; Mon, 21 Apr 2003 18:43:36 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LMhH802539;
	Mon, 21 Apr 2003 18:43:17 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LMYC801373
	for <sip@optimus.ietf.org>; Mon, 21 Apr 2003 18:34: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 SAA05911
	for <sip@ietf.org>; Mon, 21 Apr 2003 18:22:27 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 197jiS-0003xq-00
	for sip@ietf.org; Mon, 21 Apr 2003 18:24:48 -0400
Received: from magus.nostrum.com ([208.21.192.130] ident=root)
	by ietf-mx with esmtp (Exim 4.12)
	id 197jiS-0003xn-00
	for sip@ietf.org; Mon, 21 Apr 2003 18:24:48 -0400
Received: from localhost (root@localhost [127.0.0.1])
	by magus.nostrum.com (8.12.8/8.12.8) with ESMTP id h3LMP1S3001210;
	Mon, 21 Apr 2003 17:25:02 -0500 (CDT)
From: Ben Campbell <bcampbell@dynamicsoft.com>
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        Paul Kyzivat <pkyzivat@cisco.com>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Cc: sip <sip@ietf.org>
Content-Type: text/plain
Message-Id: <1050963873.2816.87.camel@verite.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 21 Apr 2003 17:24:33 -0500
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Callerprefs: Require header tag
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-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 use of a Require header tag does not seem to buy us much. In a
REGISTER request, the best you can expect is the registrar knows to
store the feature set parameters with the Contact. You cannot assume
that each proxy that uses the registrar's location service knows about
the "prefs" tag just because the registrar did. Also, the registrar
cannot be expected to know the capabilities of every proxy that might
possible use its location service.

I think it would be better to dispense with the Require tag completely,
and just assert that the UA cannot assume that feature parameters will
be honored in any way. This seems to fit with the concept that a proxy
can override any of this due to local policy anyway.

If we do keep the tag, then we need to explicitly document its limited
scope. 

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



From mailnull@www1.ietf.org  Mon Apr 21 18:39:18 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06485
	for <sip-archive@odin.ietf.org>; Mon, 21 Apr 2003 18:39:18 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3LMoXQ02846
	for sip-archive@odin.ietf.org; Mon, 21 Apr 2003 18:50:33 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LMo7802812;
	Mon, 21 Apr 2003 18:50:07 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LMeQ802458
	for <sip@optimus.ietf.org>; Mon, 21 Apr 2003 18:40: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 SAA06027
	for <sip@ietf.org>; Mon, 21 Apr 2003 18:28:41 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 197joU-0003zR-00
	for sip@ietf.org; Mon, 21 Apr 2003 18:31:02 -0400
Received: from magus.nostrum.com ([208.21.192.130] ident=root)
	by ietf-mx with esmtp (Exim 4.12)
	id 197joT-0003zO-00
	for sip@ietf.org; Mon, 21 Apr 2003 18:31:02 -0400
Received: from localhost (root@localhost [127.0.0.1])
	by magus.nostrum.com (8.12.8/8.12.8) with ESMTP id h3LMVAS3001688;
	Mon, 21 Apr 2003 17:31:11 -0500 (CDT)
From: Ben Campbell <bcampbell@dynamicsoft.com>
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        Paul Kyzivat <pkyzivat@cisco.com>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Cc: sip <sip@ietf.org>
Content-Type: text/plain
Message-Id: <1050964235.2808.101.camel@verite.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 21 Apr 2003 17:30:35 -0500
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Callerprefs: Mid-dialog requests
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

The draft does not seem clear on how caller preferences affect
mid-dialog requests. I expected when reading this that caller
preferences would only apply to requests outside an existing dialog, and
that normal dialog routing would prevail for mid-dialog requests.

However, the statements about putting feature set parameters into the
Contact header when a mid-dialog request retargets the remote Contact
confuses that point for me. I am uncertain what use cases there might be
for that feature. The only thing I can think of is to convey information
to the opposite UA that it might use when re-inviting or establishing a
new dialog. But I don't think that usage really fits the scope or
purpose of this draft.

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



From mailnull@www1.ietf.org  Mon Apr 21 18:46:31 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06655
	for <sip-archive@odin.ietf.org>; Mon, 21 Apr 2003 18:46:30 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3LMvkW03058
	for sip-archive@odin.ietf.org; Mon, 21 Apr 2003 18:57:46 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LMvF803046;
	Mon, 21 Apr 2003 18:57:15 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LMmf802783
	for <sip@optimus.ietf.org>; Mon, 21 Apr 2003 18:48:41 -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 SAA06453
	for <sip@ietf.org>; Mon, 21 Apr 2003 18:36:56 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 197jwU-00047E-00
	for sip@ietf.org; Mon, 21 Apr 2003 18:39:18 -0400
Received: from magus.nostrum.com ([208.21.192.130] ident=root)
	by ietf-mx with esmtp (Exim 4.12)
	id 197jwT-000476-00
	for sip@ietf.org; Mon, 21 Apr 2003 18:39:17 -0400
Received: from localhost (root@localhost [127.0.0.1])
	by magus.nostrum.com (8.12.8/8.12.8) with ESMTP id h3LMdPS3002410;
	Mon, 21 Apr 2003 17:39:26 -0500 (CDT)
From: Ben Campbell <bcampbell@dynamicsoft.com>
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        Paul Kyzivat <pkyzivat@cisco.com>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Cc: sip <sip@ietf.org>
Content-Type: text/plain
Message-Id: <1050964719.2816.119.camel@verite.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 21 Apr 2003 17:38:40 -0500
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Callerprefs: Implicit preferences
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-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 treatment of implicit vs. explicit preferences worries me. If I
understand correctly, if an Accept-Contact header field exists, then
implicit preferences are ignored. Further, the header field should
contain entries matching the implicit preferences.

It seems dangerously error prone to have this sort of information appear
in two different places in a request. To use the method as an example, I
can game the system by putting methods values that do not match the
actual method of my request.

My first inclination was to say that things like methods and events
should not show up at _all_ in Accept-Contacts. But I realize there may
be cases where I want to send an INVITE request to a UA that also
accepts SUBSCRIBE, so I would put both INVITE and SUBSCRIBE in a methods
parameter in Accept-Contacts.

I think the correct answer, at least for methods and event tags, is to
have the actual method or event tag treated by proxies as if it were
explicitly added to the Accept-Contacts header even if it were not. I
suspect this is true for _any_ parameter that can conflict with
information elsewhere in the request.

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



From mailnull@www1.ietf.org  Tue Apr 22 10:17:44 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11279
	for <sip-archive@odin.ietf.org>; Tue, 22 Apr 2003 10:17:44 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3METJR08717
	for sip-archive@odin.ietf.org; Tue, 22 Apr 2003 10:29:19 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MESk808668;
	Tue, 22 Apr 2003 10:28:46 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MEQ5808573
	for <sip@optimus.ietf.org>; Tue, 22 Apr 2003 10:26: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 KAA10942
	for <sip@ietf.org>; Tue, 22 Apr 2003 10:13:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 197yZJ-00021b-00
	for sip@ietf.org; Tue, 22 Apr 2003 10:16:21 -0400
Received: from rtp-core-1.cisco.com ([64.102.124.12])
	by ietf-mx with esmtp (Exim 4.12)
	id 197yZI-00021M-00
	for sip@ietf.org; Tue, 22 Apr 2003 10:16:20 -0400
Received: from cannon.cisco.com (IDENT:mirapoint@cannon.cisco.com [161.44.118.24])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3MEFv4W021781;
	Tue, 22 Apr 2003 10:15:57 -0400 (EDT)
Received: from cisco.com ([161.44.79.220])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id ABH71857;
	Tue, 22 Apr 2003 10:24:44 -0400 (EDT)
Message-ID: <3EA54E9C.9010605@cisco.com>
Date: Tue, 22 Apr 2003 10:15:56 -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: Ben Campbell <bcampbell@dynamicsoft.com>
CC: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>, sip <sip@ietf.org>
References: <1050963502.2816.73.camel@verite.localdomain>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Re: callerprefs: Various
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-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



Ben Campbell wrote:
> 
> 6.1 Register Example: The example is inconsistent on whether a boolean tag has an explicit "true/false"
> value, or simple exists. I do not understand the semantic difference between the two syntaxes.

It is simply that '="TRUE"' is the default value if none is provided. It 
provides a bit of conciseness for a common case. Maybe some explanatory 
text is in order, somewhere.

> 12p3: So, if I do a query register, would I expect to get back the feature sets contained in any
> registered contacts? If so, then worrying about protecting it in the original request does not seem
> particularly useful.

Even query registers can (and probably should) be access controlled. So 
protecting still makes sense 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 mailnull@www1.ietf.org  Tue Apr 22 10:28:34 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11565
	for <sip-archive@odin.ietf.org>; Tue, 22 Apr 2003 10:28:34 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3MEe9O10121
	for sip-archive@odin.ietf.org; Tue, 22 Apr 2003 10:40:09 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MEdd810055;
	Tue, 22 Apr 2003 10:39:39 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MEa6809019
	for <sip@optimus.ietf.org>; Tue, 22 Apr 2003 10:36: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 KAA11465
	for <sip@ietf.org>; Tue, 22 Apr 2003 10:24:01 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 197yj0-00025o-00
	for sip@ietf.org; Tue, 22 Apr 2003 10:26:23 -0400
Received: from rtp-core-2.cisco.com ([64.102.124.13])
	by ietf-mx with esmtp (Exim 4.12)
	id 197yj0-00025W-00
	for sip@ietf.org; Tue, 22 Apr 2003 10:26:22 -0400
Received: from cannon.cisco.com (IDENT:mirapoint@cannon.cisco.com [161.44.118.24])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h3MEQ0hB005632;
	Tue, 22 Apr 2003 10:26:02 -0400 (EDT)
Received: from cisco.com ([161.44.79.220])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id ABH71959;
	Tue, 22 Apr 2003 10:34:48 -0400 (EDT)
Message-ID: <3EA550F7.4020800@cisco.com>
Date: Tue, 22 Apr 2003 10:25:59 -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: Ben Campbell <bcampbell@dynamicsoft.com>
CC: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>, sip <sip@ietf.org>
References: <1050964719.2816.119.camel@verite.localdomain>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Re: Callerprefs: Implicit preferences
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-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



Ben Campbell wrote:
> The treatment of implicit vs. explicit preferences worries me. If I
> understand correctly, if an Accept-Contact header field exists, then
> implicit preferences are ignored. Further, the header field should
> contain entries matching the implicit preferences.

I don't think this is the intended interpretation. If an a-c exists but 
doesn't contain a feature tag for th implicit feature, then one gets 
added. If a feature tag already exists for that feature, then it gets 
left along.

Of couse that still makes it possible to do something dumb, but you have 
to be pretty overt about it. For instance, you could send an INVITE, but 
accept contacts that support only SUBSCRIBE. In that case I think you 
get what you deserve.

> I think the correct answer, at least for methods and event tags, is to
> have the actual method or event tag treated by proxies as if it were
> explicitly added to the Accept-Contacts header even if it were not. I
> suspect this is true for _any_ parameter that can conflict with
> information elsewhere in the request.

Need to look at the mechanics of forming the proper expression to do 
this. The explanation might be pretty ugly.

	Paul

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



From mailnull@www1.ietf.org  Tue Apr 22 10:35:04 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11851
	for <sip-archive@odin.ietf.org>; Tue, 22 Apr 2003 10:35:03 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3MEkdY10601
	for sip-archive@odin.ietf.org; Tue, 22 Apr 2003 10:46:39 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MEkD810552;
	Tue, 22 Apr 2003 10:46:13 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MEi4810455
	for <sip@optimus.ietf.org>; Tue, 22 Apr 2003 10:44: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 KAA11728
	for <sip@ietf.org>; Tue, 22 Apr 2003 10:31:58 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 197yqi-000290-00
	for sip@ietf.org; Tue, 22 Apr 2003 10:34:20 -0400
Received: from magus.nostrum.com ([208.21.192.130] ident=root)
	by ietf-mx with esmtp (Exim 4.12)
	id 197yqh-00028x-00
	for sip@ietf.org; Tue, 22 Apr 2003 10:34:20 -0400
Received: from localhost (root@localhost [127.0.0.1])
	by magus.nostrum.com (8.12.8/8.12.8) with ESMTP id h3MEY3S3077970;
	Tue, 22 Apr 2003 09:34:03 -0500 (CDT)
From: Ben Campbell <bcampbell@dynamicsoft.com>
To: Paul Kyzivat <pkyzivat@cisco.com>
Cc: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>, sip <sip@ietf.org>
In-Reply-To: <3EA550F7.4020800@cisco.com>
References: <1050964719.2816.119.camel@verite.localdomain>
	 <3EA550F7.4020800@cisco.com>
Content-Type: text/plain
Message-Id: <1051022003.2816.144.camel@verite.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 22 Apr 2003 09:33:24 -0500
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Re: Callerprefs: Implicit preferences
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-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-04-22 at 09:25, Paul Kyzivat wrote:
> Ben Campbell wrote:
> > The treatment of implicit vs. explicit preferences worries me. If I
> > understand correctly, if an Accept-Contact header field exists, then
> > implicit preferences are ignored. Further, the header field should
> > contain entries matching the implicit preferences.
> 
> I don't think this is the intended interpretation. If an a-c exists but 
> doesn't contain a feature tag for th implicit feature, then one gets 
> added. If a feature tag already exists for that feature, then it gets 
> left along.

>From 7.2.2:

"If, and only if, the proxy did not find any explicit preferences in the
request (because there was no Accept-Contact or Reject-Contact header
field), the proxy extracts implicit preferences."

This wording seems pretty all or nothing.


> 
> Of couse that still makes it possible to do something dumb, but you have 
> to be pretty overt about it. For instance, you could send an INVITE, but 
> accept contacts that support only SUBSCRIBE. In that case I think you 
> get what you deserve.

I can imagine the caller doing this on purpose as an intentional
circumvention of callee policy.


> 
> > I think the correct answer, at least for methods and event tags, is to
> > have the actual method or event tag treated by proxies as if it were
> > explicitly added to the Accept-Contacts header even if it were not. I
> > suspect this is true for _any_ parameter that can conflict with
> > information elsewhere in the request.
> 
> Need to look at the mechanics of forming the proper expression to do 
> this. The explanation might be pretty ugly.
> 
> 	Paul

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



From mailnull@www1.ietf.org  Tue Apr 22 10:37:54 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12003
	for <sip-archive@odin.ietf.org>; Tue, 22 Apr 2003 10:37:54 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3MEnRQ10806
	for sip-archive@odin.ietf.org; Tue, 22 Apr 2003 10:49:27 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MEn9810791;
	Tue, 22 Apr 2003 10:49:09 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MEmw810763
	for <sip@optimus.ietf.org>; Tue, 22 Apr 2003 10:48: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 KAA11959
	for <sip@ietf.org>; Tue, 22 Apr 2003 10:36:51 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 197yvR-0002Bl-00
	for sip@ietf.org; Tue, 22 Apr 2003 10:39:13 -0400
Received: from magus.nostrum.com ([208.21.192.130] ident=root)
	by ietf-mx with esmtp (Exim 4.12)
	id 197yvR-0002Bi-00
	for sip@ietf.org; Tue, 22 Apr 2003 10:39:13 -0400
Received: from localhost (root@localhost [127.0.0.1])
	by magus.nostrum.com (8.12.8/8.12.8) with ESMTP id h3MEdTS3078415;
	Tue, 22 Apr 2003 09:39:29 -0500 (CDT)
From: Ben Campbell <bcampbell@dynamicsoft.com>
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        Paul Kyzivat <pkyzivat@cisco.com>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Cc: sip <sip@ietf.org>
Content-Type: text/plain
Message-Id: <1051022322.2808.151.camel@verite.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 22 Apr 2003 09:38:43 -0500
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Callerprefs: UAS processing of misrouted requests
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

The draft states that if a UAS has registered multiple contacts with
different feature sets, and receives a request to one of those contacts
where the preferences do not match, it should either internally retarget
the request to a contact that _does_ match, or reject the request.

I don't think the _standard_ should make the UAS into a caller prefs
enforcement point. UAS normally should simply handle the request as
normal, without regard to any caller preferences related header. If the
UAS is happy with the nature of the request, then so be it. If not, it
should reject the request based on the normal SIP mechanism for the
particular problem. At most, I would say the UAS MAY enforce caller
prefs, as a matter of local policy.

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



From mailnull@www1.ietf.org  Tue Apr 22 13:52:19 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18241
	for <sip-archive@odin.ietf.org>; Tue, 22 Apr 2003 13:52:19 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3MI3vd26202
	for sip-archive@odin.ietf.org; Tue, 22 Apr 2003 14:03:57 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MI2r826159;
	Tue, 22 Apr 2003 14:02:53 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MI0N825913
	for <sip@optimus.ietf.org>; Tue, 22 Apr 2003 14:00: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 NAA18046
	for <sip@ietf.org>; Tue, 22 Apr 2003 13:48:14 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1981uc-0003YH-00
	for sip@ietf.org; Tue, 22 Apr 2003 13:50:34 -0400
Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112])
	by ietf-mx with esmtp (Exim 4.12)
	id 1981uc-0003Xt-00
	for sip@ietf.org; Tue, 22 Apr 2003 13:50:34 -0400
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3MHnhR24183;
	Tue, 22 Apr 2003 12:49:43 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <HNP4X5XT>; Tue, 22 Apr 2003 12:49:43 -0500
Message-ID: <1B54FA3A2709D51195C800508BF9386A09DABCE5@zrc2c000.us.nortel.com>
From: "Mary Barnes" <mbarnes@nortelnetworks.com>
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>,
        Paul Kyzivat
	 <pkyzivat@cisco.com>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: "'sip@ietf.org'" <sip@ietf.org>
Date: Tue, 22 Apr 2003 12:49:40 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Subject: [Sip] Callerprefs: Additional Nit/editorial comments
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-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 also did a detailed review of draft-ietf-sip-callerprefs-08.txt and beyond
some of the points already made by Ben and Bob, I had the following
additional minor NITs/Editorial comments.  There also a couple of  points
that I'll put in separate threads as they could invoke some additional
discussion.  Also, I did try to avoid duplicating comments made by Ben and
Bob and apologize if I have inadvertently duplicated anything.

Footing: 
- there is no "." in the "et" of the phrase "et al."

Section 3, page 7: 
- Feature Preferences: "described" -> "describe" 
- Target Set: "URI" -> "URI(s)"

Section 5: 
- Para 5: "instant of time" -> "instance of time"

Section 7.3:
- Last para: "featuer" -> "feature"

Section 7.4:
- Para 5: I know you have an example further down in section 7.4.1, but I'm
thinking an example after this paragraph might be useful.  I had to read the
last few sentences many several times and I'm still not absolutely certain I
understand it given that the example in 7.4.1 has the "require" flag set.
So, I think another example here (or forward referenced to one in 7.4.1)
would be extremely helpful.  

Section 9.6 Automata: 
- Would IVR be considered here as well?  

Section 9.12 Priority:
- I would suggest changing the definition of "emergency" to "The device
supports calls in the case of an emergency situation" as I think the phrase
"emergency calls" tends to so closely associated with an E911 type of call,
whereas I think this is meant to be in terms of the device being one that
user wants to be the primary contact for personal emergency situations.

Section 9.15 Schemes:
- Example of typical use: "Choosing get" -> "Choosing to get"

Section 9.17 Message Server:
- Is this category intended to also apply to IVR? Or, would IVR just be
considered automata?   

Section 9.18 Is Focus:
- this is just a consistency thing, but it seems that this should just be
"Focus" rather than "isfocus" or 9.17 should be "ismsgserver". 

Section 17 Informative References:
- [27] needs to be updated with the RFC number: RFC 3515

Regards,
Mary H. Barnes
mbarnes@nortelnetworks.com

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



From mailnull@www1.ietf.org  Tue Apr 22 14:00:12 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18669
	for <sip-archive@odin.ietf.org>; Tue, 22 Apr 2003 14:00:12 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3MIBpR27488
	for sip-archive@odin.ietf.org; Tue, 22 Apr 2003 14:11:51 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MIBR827463;
	Tue, 22 Apr 2003 14:11:27 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MI22826052
	for <sip@optimus.ietf.org>; Tue, 22 Apr 2003 14:02: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 NAA18091
	for <sip@ietf.org>; Tue, 22 Apr 2003 13:49:53 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1981wD-0003Z9-00
	for sip@ietf.org; Tue, 22 Apr 2003 13:52:13 -0400
Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112])
	by ietf-mx with esmtp (Exim 4.12)
	id 1981wD-0003Yq-00
	for sip@ietf.org; Tue, 22 Apr 2003 13:52:13 -0400
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3MHpZR24429;
	Tue, 22 Apr 2003 12:51:35 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <HNP4X5YZ>; Tue, 22 Apr 2003 12:51:35 -0500
Message-ID: <1B54FA3A2709D51195C800508BF9386A09DABCE7@zrc2c000.us.nortel.com>
From: "Mary Barnes" <mbarnes@nortelnetworks.com>
To: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>,
        "'Henning Schulzrinne'"
	 <schulzrinne@cs.columbia.edu>,
        "'Paul Kyzivat'" <pkyzivat@cisco.com>
Cc: "'sip@ietf.org'" <sip@ietf.org>
Date: Tue, 22 Apr 2003 12:51:28 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Subject: [Sip] Callerprefs: Proxy-Require
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

Similar to Ben's comment on the Require header and Bob also raised an issue
on this in his comments, I'm really wondering if Proxy-Require should be
used at all.  Bob suggested the following:
   "A UAC SHOULD NOT include a Proxy-Require header with a
    value of "pref" unless it is reasonably certain that all
    proxies along the path between the UAC and the proxy
    responsible for the domain of Request-URI support the
    "pref" extension."

But, my view is that if the UAC is reasonably certain that all proxies
support the extension, why bother with the Proxy-Require?  As the text
currently in the draft suggests, using Proxy-Require introduces
interoperability problems.  Since this is optional functionality, it just
doesn't seem reasonable that a Proxy-Require be used at all. 

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



From mailnull@www1.ietf.org  Tue Apr 22 14:00:15 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18683
	for <sip-archive@odin.ietf.org>; Tue, 22 Apr 2003 14:00:15 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3MIBsQ27501
	for sip-archive@odin.ietf.org; Tue, 22 Apr 2003 14:11:54 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MIAp827415;
	Tue, 22 Apr 2003 14:10:51 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MI15825983
	for <sip@optimus.ietf.org>; Tue, 22 Apr 2003 14:01: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 NAA18067
	for <sip@ietf.org>; Tue, 22 Apr 2003 13:48:56 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1981vI-0003Ye-00
	for sip@ietf.org; Tue, 22 Apr 2003 13:51:16 -0400
Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112])
	by ietf-mx with esmtp (Exim 4.12)
	id 1981vI-0003YP-00
	for sip@ietf.org; Tue, 22 Apr 2003 13:51:16 -0400
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3MHoeR24337;
	Tue, 22 Apr 2003 12:50:40 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <HNP4X5Y1>; Tue, 22 Apr 2003 12:50:40 -0500
Message-ID: <1B54FA3A2709D51195C800508BF9386A09DABCE6@zrc2c000.us.nortel.com>
From: "Mary Barnes" <mbarnes@nortelnetworks.com>
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        Henning Schulzrinne
	 <schulzrinne@cs.columbia.edu>,
        Paul Kyzivat <pkyzivat@cisco.com>
Cc: "'sip@ietf.org'" <sip@ietf.org>
Date: Tue, 22 Apr 2003 12:50:40 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Subject: [Sip] Callerprefs: Mobility tag
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-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 9.9, the mobility tag is described as "indicates whether the
device is fixed, wireless or somewhere in-between", however, there is no
definition for the somewhere in-between.  

So, my initial reaction would be to reword this as "indicates whether the
device is fixed or wireless", but then I got to thinking about what could
have been meant by some in-between and I think there might be some value in
defining some of those now.  

One term I had considered was "nomadic" as the "in-between".  But, then I
also got to thinking that perhaps "WiFi" is a good example of the
"in-between".  The usefulness of these really depends upon how they
would/could be used.  The one example I saw in the usecases draft was around
wanting to contact someone only on their mobile phone.  The inverse of this
could be that you absolutely don't want to contact them on their mobile
phone, but would want to contact them on anything else or perhaps only if
they're "fixed" or "WiFi". "Nomadic" might be useful for scenarios whereby
one's network connectivity is via tunneling, thus it's indicative not being
reachable at the "fixed" device (eg. the hard SIP client), but you are
available on your soft SIP client working from home.   I haven't thought
this all the way through, but I do think additional terms could be extremely
useful.

Mary H. Barnes
mbarnes@nortelnetworks.com

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



From mailnull@www1.ietf.org  Tue Apr 22 15:17:43 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22416
	for <sip-archive@odin.ietf.org>; Tue, 22 Apr 2003 15:17:43 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3MJTOg00363
	for sip-archive@odin.ietf.org; Tue, 22 Apr 2003 15:29:24 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MJT2800349;
	Tue, 22 Apr 2003 15:29:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MJR4832760
	for <sip@optimus.ietf.org>; Tue, 22 Apr 2003 15:27: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 PAA22251
	for <sip@ietf.org>; Tue, 22 Apr 2003 15:14:53 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1983GU-0004LH-00
	for sip@ietf.org; Tue, 22 Apr 2003 15:17:14 -0400
Received: from rtp-core-1.cisco.com ([64.102.124.12])
	by ietf-mx with esmtp (Exim 4.12)
	id 1983GU-0004LE-00
	for sip@ietf.org; Tue, 22 Apr 2003 15:17:14 -0400
Received: from cannon.cisco.com (IDENT:mirapoint@cannon.cisco.com [161.44.118.24])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3MJGr4W028325;
	Tue, 22 Apr 2003 15:16:54 -0400 (EDT)
Received: from cisco.com ([161.44.79.220])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id ABH74967;
	Tue, 22 Apr 2003 15:25:41 -0400 (EDT)
Message-ID: <3EA59525.2050308@cisco.com>
Date: Tue, 22 Apr 2003 15:16: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: Ben Campbell <bcampbell@dynamicsoft.com>
CC: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>, sip <sip@ietf.org>
References: <1050964719.2816.119.camel@verite.localdomain>	 <3EA550F7.4020800@cisco.com> <1051022003.2816.144.camel@verite.localdomain>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Re: Callerprefs: Implicit preferences
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-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



Ben Campbell wrote:
> 
>>I don't think this is the intended interpretation. If an a-c exists but 
>>doesn't contain a feature tag for th implicit feature, then one gets 
>>added. If a feature tag already exists for that feature, then it gets 
>>left along.
> 
> 
>>From 7.2.2:
> 
> "If, and only if, the proxy did not find any explicit preferences in the
> request (because there was no Accept-Contact or Reject-Contact header
> field), the proxy extracts implicit preferences."
> 
> This wording seems pretty all or nothing.

My brain is getting fuzzy on this. I'm pretty sure it used to be the 
other way. I have a vague recollection of discussing this with Jonathan, 
but don't recall why this change was made. We'll have to wait for an 
explanation from him.

>>Of couse that still makes it possible to do something dumb, but you have 
>>to be pretty overt about it. For instance, you could send an INVITE, but 
>>accept contacts that support only SUBSCRIBE. In that case I think you 
>>get what you deserve.
> 
> I can imagine the caller doing this on purpose as an intentional
> circumvention of callee policy.

Callerprefs  aren't a good way for the callee to impose mandatory 
policies - they are a way for a callee to facilitate a caller guiding a 
choice. If the callee wants to enforce this, then he should use some 
other mechanism, like CPL.

	Paul

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



From mailnull@www1.ietf.org  Tue Apr 22 17:52:29 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28074
	for <sip-archive@odin.ietf.org>; Tue, 22 Apr 2003 17:52:29 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3MM4CH14213
	for sip-archive@odin.ietf.org; Tue, 22 Apr 2003 18:04:12 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MM3O814147;
	Tue, 22 Apr 2003 18:03:24 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MLtU813823
	for <sip@optimus.ietf.org>; Tue, 22 Apr 2003 17:55: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 RAA27890
	for <sip@ietf.org>; Tue, 22 Apr 2003 17:43:17 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1985a5-0005ha-00
	for sip@ietf.org; Tue, 22 Apr 2003 17:45:37 -0400
Received: from rtp-core-1.cisco.com ([64.102.124.12])
	by ietf-mx with esmtp (Exim 4.12)
	id 1985a4-0005h7-00
	for sip@ietf.org; Tue, 22 Apr 2003 17:45:37 -0400
Received: from cannon.cisco.com (IDENT:mirapoint@cannon.cisco.com [161.44.118.24])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3MLjF4W014097;
	Tue, 22 Apr 2003 17:45:15 -0400 (EDT)
Received: from cisco.com ([161.44.79.220])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id ABH76414;
	Tue, 22 Apr 2003 17:54:03 -0400 (EDT)
Message-ID: <3EA5B7EA.2010002@cisco.com>
Date: Tue, 22 Apr 2003 17:45:14 -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: Mary Barnes <mbarnes@nortelnetworks.com>
CC: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>,
        "'sip@ietf.org'" <sip@ietf.org>
References: <1B54FA3A2709D51195C800508BF9386A09DABCE6@zrc2c000.us.nortel.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Re: Callerprefs: Mobility tag
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

I've always had trouble with the semantics of this feature. All the 
examples I can think of for using it really depend of coincidental 
association between mobility and other features.

For instance, *why* would I prefer to call someone on their fixed phone 
rather than their mobile phone?

- because use of the mobile phone is expensive?

- because I know the fixed phone is in a particular location
   and I only want to reach them if they are there.

Neither of these are really directly related to the fixed nature of the 
phone.

I think I asked Jonathan about this and he felt it should be kept 
because it had been around for a long time and we didn't have 
justification for removing it. Personally I think it could just go away.

	Paul

Mary Barnes wrote:
> In section 9.9, the mobility tag is described as "indicates whether the
> device is fixed, wireless or somewhere in-between", however, there is no
> definition for the somewhere in-between.  
> 
> So, my initial reaction would be to reword this as "indicates whether the
> device is fixed or wireless", but then I got to thinking about what could
> have been meant by some in-between and I think there might be some value in
> defining some of those now.  
> 
> One term I had considered was "nomadic" as the "in-between".  But, then I
> also got to thinking that perhaps "WiFi" is a good example of the
> "in-between".  The usefulness of these really depends upon how they
> would/could be used.  The one example I saw in the usecases draft was around
> wanting to contact someone only on their mobile phone.  The inverse of this
> could be that you absolutely don't want to contact them on their mobile
> phone, but would want to contact them on anything else or perhaps only if
> they're "fixed" or "WiFi". "Nomadic" might be useful for scenarios whereby
> one's network connectivity is via tunneling, thus it's indicative not being
> reachable at the "fixed" device (eg. the hard SIP client), but you are
> available on your soft SIP client working from home.   I haven't thought
> this all the way through, but I do think additional terms could be extremely
> useful.
> 
> Mary H. Barnes
> mbarnes@nortelnetworks.com
> 
> 

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



From mailnull@www1.ietf.org  Tue Apr 22 21:52:45 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04056
	for <sip-archive@odin.ietf.org>; Tue, 22 Apr 2003 21:52:45 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3N24Y029847
	for sip-archive@odin.ietf.org; Tue, 22 Apr 2003 22:04:34 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N246829836;
	Tue, 22 Apr 2003 22:04:06 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N20f829662
	for <sip@optimus.ietf.org>; Tue, 22 Apr 2003 22:00:41 -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 VAA03958
	for <sip@ietf.org>; Tue, 22 Apr 2003 21:48:22 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1989PH-0006vv-00
	for sip@ietf.org; Tue, 22 Apr 2003 21:50:43 -0400
Received: from cs.columbia.edu ([128.59.16.20])
	by ietf-mx with esmtp (Exim 4.12)
	id 1989PG-0006vs-00
	for sip@ietf.org; Tue, 22 Apr 2003 21:50:42 -0400
Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h3N1p33o016280
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT);
	Tue, 22 Apr 2003 21:51:04 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1])
	by bart.cs.columbia.edu (8.12.9/8.12.6) with ESMTP id h3N1p2qY007673;
	Tue, 22 Apr 2003 21:51:02 -0400 (EDT)
Message-ID: <3EA5F173.3060500@cs.columbia.edu>
Date: Tue, 22 Apr 2003 21:50:43 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@cisco.com>
CC: Mary Barnes <mbarnes@nortelnetworks.com>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "'sip@ietf.org'" <sip@ietf.org>
References: <1B54FA3A2709D51195C800508BF9386A09DABCE6@zrc2c000.us.nortel.com> <3EA5B7EA.2010002@cisco.com>
In-Reply-To: <3EA5B7EA.2010002@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Re: Callerprefs: Mobility tag
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-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 think this is useful. Yes, having something like "don't call if it 
costs extra" or "don't call if the person is in a car or meeting" would 
be better, but until everybody uses RPIDS, 'no mobile phone' is a pretty 
good approximation and actually implementable. (In European countries, 
the *caller* pays more for mobile calls, so this is a real concern. And 
mobile is indeed the distinction that matters, not something else.)

Paul Kyzivat wrote:

> I've always had trouble with the semantics of this feature. All the 
> examples I can think of for using it really depend of coincidental 
> association between mobility and other features.
> 
> For instance, *why* would I prefer to call someone on their fixed phone 
> rather than their mobile phone?
> 
> - because use of the mobile phone is expensive?
> 
> - because I know the fixed phone is in a particular location
>   and I only want to reach them if they are there.
> 
> Neither of these are really directly related to the fixed nature of the 
> phone.
> 
> I think I asked Jonathan about this and he felt it should be kept 
> because it had been around for a long time and we didn't have 
> justification for removing it. Personally I think it could just go away.
> 
>     Paul
> 
> Mary Barnes wrote:
> 
>> In section 9.9, the mobility tag is described as "indicates whether the
>> device is fixed, wireless or somewhere in-between", however, there is no
>> definition for the somewhere in-between. 
>> So, my initial reaction would be to reword this as "indicates whether the
>> device is fixed or wireless", but then I got to thinking about what could
>> have been meant by some in-between and I think there might be some 
>> value in
>> defining some of those now. 
>> One term I had considered was "nomadic" as the "in-between".  But, then I
>> also got to thinking that perhaps "WiFi" is a good example of the
>> "in-between".  The usefulness of these really depends upon how they
>> would/could be used.  The one example I saw in the usecases draft was 
>> around
>> wanting to contact someone only on their mobile phone.  The inverse of 
>> this
>> could be that you absolutely don't want to contact them on their mobile
>> phone, but would want to contact them on anything else or perhaps only if
>> they're "fixed" or "WiFi". "Nomadic" might be useful for scenarios 
>> whereby
>> one's network connectivity is via tunneling, thus it's indicative not 
>> being
>> reachable at the "fixed" device (eg. the hard SIP client), but you are
>> available on your soft SIP client working from home.   I haven't thought
>> this all the way through, but I do think additional terms could be 
>> extremely
>> useful.
>>
>> Mary H. Barnes
>> mbarnes@nortelnetworks.com
>>
>>

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



From mailnull@www1.ietf.org  Wed Apr 23 01:59:43 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08857
	for <sip-archive@odin.ietf.org>; Wed, 23 Apr 2003 01:59:43 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3N6Bbj19504
	for sip-archive@odin.ietf.org; Wed, 23 Apr 2003 02:11:37 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N6B2819298;
	Wed, 23 Apr 2003 02:11:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N69f818456
	for <sip@optimus.ietf.org>; Wed, 23 Apr 2003 02:09:41 -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 BAA08801
	for <sip@ietf.org>; Wed, 23 Apr 2003 01:57:17 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198DI9-0000D0-00
	for sip@ietf.org; Wed, 23 Apr 2003 01:59:37 -0400
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 198DI9-0000Cs-00
	for sip@ietf.org; Wed, 23 Apr 2003 01:59:37 -0400
Received: from dynamicsoft.com ([63.113.46.12])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h3N5x7dh000761;
	Wed, 23 Apr 2003 01:59:08 -0400 (EDT)
Message-ID: <3EA62BA3.7050706@dynamicsoft.com>
Date: Wed, 23 Apr 2003 01:58:59 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
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: Bob Penfield <bpenfield@acmepacket.com>
CC: sip@ietf.org, Henning Schulzrinne <schulzrinne@cs.columbia.edu>,
        Paul Kyzivat <pkyzivat@cisco.com>
References: <000701c305fa$292acea0$2300000a@BPenfield>
In-Reply-To: <000701c305fa$292acea0$2300000a@BPenfield>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Re: review of draft-ietf-sip-caller-prefs-08.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

Bob,

Thanks for the comments. Responses inline.

Bob Penfield wrote:
> Here are my comments caller prefs draft. I apologize for their 
> tardiness.
> 
> The only technical issue is the processing of require and explicit 
> tags (see item 12 below). The spec says that the explicit flag is
> checked first and then the require flag. It seems to me it should
> be the other way around.
> 
> The rest of the items are inconsistencies in requirements, some
> suggestions for improving the readability/usability of the spec,
> and typos.
> 
> 1) Page 7: Insert "the" or "a" between "describes" and "full" in
> the last line of the "Feature Set" definition.

Inserted "a".

> 
> 2) The concept of base-tags (and using "+" for other tags) is not
> mentioned until section 7.2.1. I think they should be mentioned in 
> the overview, or at least the first time the spec talks about what 
> feature tags can be used (section 6.1).

OK. I added a discussion of this in Section 6.1. Here is the paragraph 
(apologies for the embedded latex commands):

A UA MAY use any feature tags that are registered through IANA in the
IETF or global trees \citenorm{rfc2506}; this document registers
several that are appropriate for SIP. The feature tags discussed in
this specification are referred to as base tags. While other tags can
be used, in order to identify them as feature parameters (as opposed
to parameters for another SIP extension) they are encoded with a
leading ``+'' sign in the Contact header field. See Section
\ref{sec:mapping} for details. It is also permissible to use
the URI tree
\citenorm{rfc2506} for expressing vendor-specific feature
tags. Feature tags in any other trees created through IANA MAY also be
used.


> 
> 3) In section 6.2, it says "Proxy-Require: pref" MAY be included, 
> but in the very next sentence it says that it is NOT RECOMMENDED.
> This seems to be a conflict as "MAY" is not equivalent to "NOT 
> RECOMMENDED". I personally prefer NOT RECOMMENDED. I suggest text 
> along the lines of:
> 
>     A UAC SHOULD NOT include a Proxy-Require header with a
>     value of "pref" unless it is reasonably certain that all
>     proxies along the path between the UAC and the proxy
>     responsible for the domain of Request-URI support the
>     "pref" extension.

I agree that the current wording is inconsistent, but your proposed 
text, as Mary points out in her email, defeats the purpose of 
Proxy-Require.

I think its reasonable to continue to allow PRoxy-Require. The nice 
thing abuot caller preferences is that, should the request fail becuase 
its not supported somewhere along the path, the fallback is really easy 
- just remove the Proxy-Require. So, it can basically serve as a way for 
a UA to determine whether or not its request will be processed.

I can also imagine applications where a user will want to be certain its 
call routing request will be honored, and if not, attempt to do 
something else. As an example, if I want to make sure a call is routed 
to a user's business line at 3am (to leave a message), and NOT to his 
home line, I might want to use Proxy-Require in this case.

So, I suggest this wording:

> If the UAC wants to be sure that servers understand the header fields
> described in this specification, it includes a Proxy-Require header
> field with a value of ``pref''. However, this is NOT RECOMMENDED, as
> it leads to interoperability problems. In any case, caller preferences
> can only be considered preferences - there is no guarantee that the
> requested service is executed. As such, inclusion of a
> Proxy-Require header field does not mean the preferences will be
> executed, just that the caller preferences extension is understood by
> the proxies.

this eliminates the strength ambiguity.


> 
> 4) Section 6.2.2 says "Each feature set MUST follow the 
> constraints of section 6.1". However, not all the requirements 
> in section 6.1 apply to Feature Set Preferences. I recommend that 
> the 3rd and 4th paragraphs on page 12, and the 2nd and 3rd 
> paragraph on page 13 be placed in a separate Feature Set 
> Constraints section preceding the existing section 6.1, and 
> have 6.1 and 6.2.2 refer to the new section. However, the 
> requirement in the 2nd paragraph on page 13 for the UA to "list 
> all values it supports" does need to be reworded to say that when 
> expressing capabilities it must list all values that it supports 
> and when expressing preferences it must list all values it 
> desires.

Good point.

Moving the constraints text prior to 6.1 will disrupt the flow of the 
section, I think. I prefer to put that text as section 6.6, and include 
a forward reference. Also, I do not believe that the 3rd paragraph on 
page 13 is a shared constraint. It is specific to registrations.

Also, I found four references to the constraints of 6.1. All have been 
changed to reference the new 6.6.


> 
> 5) The last sentence of the 2nd paragraph of section 6.2.2 repeats 
> a requirement in 6.1 and can be removed.

Removed.

> 
> 6) Suggest including a sample Accept-Contact and/or Reject-Contact 
> in section 6.2.2 to help in understanding feature set preferences.

I added an Accept-Contact example.

> 
> 7) Suggest including a reference to sections 8, 8.2 and 10 in 
> section 6.2.2 (similar to that in 6.2.1 for Request-Disposition).

Added a reference in the first paragraph to 8.2 and 10.

> 
> 8) Should the requirement for using different contact URIs (3rd 
> paragraph of section 6.4) be in section 6.1 since it applies to 
> expressing capabilities in a registration?

Yes. Moved.

> 
> 9) The two requirements in the 2nd paragraph of section 7 are 
> confusing to me. The first states that a proxy may add a value to 
> an existing header field, but the second says that a proxy must 
> not modify an existing header field.

It means, its not supposed to muck with things that are already there. 
Is this clearer:

> In addition to processing these headers, a proxy MAY add one if not
> present, or add a value to an existing header field, as if it were a
> UAC. This is useful for a proxy to request processing in downstream
> proxies in the implementation of a feature. However a proxy MUST NOT
> modify or remove an existing header field value. This


> 
> 10) In section 7.2, it says "SHOULD apply the processing in this 
> section" and "MUST do so as described below". When I first read 
> it, I interpreted it to mean section 7.2 (which encompasses 7.2.1, 
> 7.2.2, and 7.2.2.1 too), but clearly section 7.3 and 7.4 also 
> apply. You may want to explicitly enumerate the required sections 
> or renumber them such that they all fall within 7.2.

Its a section numbering problem. They should all fall within 7.2. Good 
catch.


> 
> 11) The last paragraph on page 22 uses the term "contact set" 
> rather than "target set". Should it be "target set"?

Yes. Fixed.

> 
> 12) Page 23 & Figure 1: Shouldn't the require tag be checked first 
> rather than the explicit flag? On page 15 it says:
> 
>     If one of the values contains the "require" parameter,
>     it means that the UA must match that value.
> 
> In the example in section 7.4.1, u2 is discarded because the first 
> predicate has a require tag. However, if you follow the flow 
> chart, u2 would get a score of 0. In order to make my test program 
> generate the same results as in the example, I had to check the 
> require flag first.

The require flag is used twice. If a contact doesnt match, and there was 
a require tag, the contact is dropped. Then, if it does match, as part 
of the score computation, its looked at again.

> 
> 13) The tables in section 8 indicates that a proxy may add and/or 
> remove Accept_Contact, Reject-Contact, and Request-Disposition 
> headers, but the text in section 7 says a proxy MUST NOT remove 
> the header values.

Careful here. "r" means read, not remove. From RFC 3261:

The "proxy" column describes the operations a proxy may perform on a
    header field:

       a: A proxy can add or concatenate the header field if not present.

       m: A proxy can modify an existing header field value.

       d: A proxy can delete a header field value.

       r: A proxy must be able to read the header field, and thus this
            header field cannot be encrypted.

So, "ar" means that the proxy needs to be able to read it, and can add a 
value.

> 
> 14) Section 9 says "new media feature tags MAY be registered with 
> IANA". Given the requirements in section 6.1, shouldn't this say 
> "New media feature tags MAY be defined and they MUST be registered 
> with IANA"?

As Paul points out, IANA registration is not required for media feature 
tags in the URI tree. I suspect SHOULD is the appropriate term above. 
Interoperability requires a registration, but there are cases, such as 
lab, where its not needed.

> 
> 15) Section 9: For those feature tags whose values are defined in 
> an IANA registry, the specific registry should be referenced to 
> find the appropriate values for the tag (as suggested by RFC 
> 2506). Section 9.13 needs to refer to the IANA "SIP Parameters - 
> Methods" registry for valid method names. Section 9.14 (SIP 
> Extensions) does explicitly mention IANA and section 9.11 (Event 
> Package) mentions "event packages that are registered", but does 
> not mention IANA.

Wow, good catch. Thats a very subtle point in RFC2506 that I had missed. 
You've clearly been reading closely. Note also that 9.15 should 
reference the IANA schemes registry. This allows me to remove the 
enumerated listing of the current methods, event types, extensions, and 
schemes, which will always be out of date. Nice.

> 
> 16) Page 46: Should [/ ""' /] be [/ "'" /] in the BNF for 
> "ftag-name"?

Yes. This appears to be a bug in my latex converter (my new I-Ds since 
Dec 02 have been using xml2rfc, which I highly recommend).

Thanks for your careful review and comments,

Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             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 mailnull@www1.ietf.org  Wed Apr 23 02:24:45 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29939
	for <sip-archive@odin.ietf.org>; Wed, 23 Apr 2003 02:24:44 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3N6acI26479
	for sip-archive@odin.ietf.org; Wed, 23 Apr 2003 02:36:38 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N6aK826420;
	Wed, 23 Apr 2003 02:36:20 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N6ZD826347
	for <sip@optimus.ietf.org>; Wed, 23 Apr 2003 02: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 CAA27643
	for <sip@ietf.org>; Wed, 23 Apr 2003 02:22:49 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198Dgr-0000Lr-00
	for sip@ietf.org; Wed, 23 Apr 2003 02:25:09 -0400
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 198Dgq-0000Lk-00
	for sip@ietf.org; Wed, 23 Apr 2003 02:25:08 -0400
Received: from dynamicsoft.com ([63.113.46.12])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h3N6Ordh000775;
	Wed, 23 Apr 2003 02:24:53 -0400 (EDT)
Message-ID: <3EA631AD.20406@dynamicsoft.com>
Date: Wed, 23 Apr 2003 02:24:45 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
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: Ben Campbell <bcampbell@dynamicsoft.com>
CC: Paul Kyzivat <pkyzivat@cisco.com>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>, sip <sip@ietf.org>
References: <1050963502.2816.73.camel@verite.localdomain>
In-Reply-To: <1050963502.2816.73.camel@verite.localdomain>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Re: callerprefs: Various
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-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

Ben,

Thanks for the comments. Responses inline.

Ben Campbell wrote:
> Here is the beginning of my review of
> draft-ietf-sip-callerprefs-08.txt. Adam and Cullen's approach of
> separating major issues in SIMPLE seemed to work well, so I will
> follow the same approach here. This email talks about nits and typos.
> I will send a separate note for each issue that I think might warrant
> discussion.
> 
> ------------------------------------
> 
> 
> Inclusion of summary of feature tag concepts: While I appreciate this
>  convenience, it always worries me to copy or summarize normative
> text from another document. In the event of a conflict between this
> summary and the referenced text, who wins? Surely it is the
> referenced text--but implementers may attempt to implement this
> without reading that text. (It is bad enough when people try to
> implement examples rather than specification)

On the other hand, people have complained to me that the spec is
incomprehensible without some kind of background, and rfc2533 itself is
too long and complex, and too far outside of the sip universe, to be
easily digestable by a sip implementor. I would rather that the caller
prefs spec be understandable. I'll add a note that says in the event of
conflict, rfc2533 wins of course. The intro to the tutorial now reads:

> This section provides a brief overview of RFC 2533 and related 
> specifications that form the content negotiation framework. This 
> section does not represent normative behavior. In the event of any 
> conflict between the tutorial material here and the normative text in
>  RFC 2533, RFC 2533 takes precedence.




> 
> 6.1p4:
> 
> 6.1 Register Example: The example is inconsistent on whether a
> boolean tag has an explicit "true/false" value, or simple exists. I
> do not understand the semantic difference between the two syntaxes.

I'm confused. Section 6.1 paragraph 4 has nothing to do with boolean 
tags. Its talking about the absence of feature tags entirely, not the 
absence of a VALUE for a feature tag.

> 
> 7.4p8 - missing word: ...predicate [in] the contact's matching set.

Fixed.

> 
> 7.4p8&9 (and surrounding) - This is pretty hard to digest. Listing it
> stepwise might help.

Its the standard issue of writing text which is effectively trying to 
convey what is ideally described using code. I don't think listing the 
steps in a bullet form as opposed to sentences will really help.

> 
> 7.4p15 : s/prefentially/preferentially

Fixed.

> 
> 12p3: So, if I do a query register, would I expect to get back the
> feature sets contained in any registered contacts? If so, then
> worrying about protecting it in the original request does not seem 
> particularly useful.

Paul replied to this:
> Even query registers can (and probably should) be access controlled. So protecting still makes sense to me. 

I agree with him. I dont see why protecting it is useless. Sure, you 
need to protect the writes too, but just because someone else does the 
writes doesnt mean you shouldnt protect the reads.

> 
> 16 ref 3: Is this really a normative reference? Also, no author
> listing.

It was part of the registry listing for methods. Per Bob P.'s comments, 
I was able to remove the listing of existing methods and instead 
reference the IANA registry. Thus, the referece to the MESSAGE spec is gone.

Thanks for the comments!

-Jonathan R.


-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             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 mailnull@www1.ietf.org  Wed Apr 23 02:33:34 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05354
	for <sip-archive@odin.ietf.org>; Wed, 23 Apr 2003 02:33:34 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3N6jSY28022
	for sip-archive@odin.ietf.org; Wed, 23 Apr 2003 02:45:28 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N6j9827971;
	Wed, 23 Apr 2003 02:45:09 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N6iZ827923
	for <sip@optimus.ietf.org>; Wed, 23 Apr 2003 02:44: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 CAA05328
	for <sip@ietf.org>; Wed, 23 Apr 2003 02:32:11 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198Dpv-0000h9-00
	for sip@ietf.org; Wed, 23 Apr 2003 02:34:31 -0400
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 198Dpu-0000gz-00
	for sip@ietf.org; Wed, 23 Apr 2003 02:34:31 -0400
Received: from dynamicsoft.com ([63.113.46.12])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h3N6YEdh000778;
	Wed, 23 Apr 2003 02:34:14 -0400 (EDT)
Message-ID: <3EA633DD.1020800@dynamicsoft.com>
Date: Wed, 23 Apr 2003 02:34:05 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
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: Paul Kyzivat <pkyzivat@cisco.com>
CC: Ben Campbell <bcampbell@dynamicsoft.com>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>, sip <sip@ietf.org>
References: <1050964719.2816.119.camel@verite.localdomain>	 <3EA550F7.4020800@cisco.com> <1051022003.2816.144.camel@verite.localdomain> <3EA59525.2050308@cisco.com>
In-Reply-To: <3EA59525.2050308@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Re: Callerprefs: Implicit preferences
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-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:
> 
> 
> Ben Campbell wrote:
> 
>>
>>> I don't think this is the intended interpretation. If an a-c exists 
>>> but doesn't contain a feature tag for th implicit feature, then one 
>>> gets added. If a feature tag already exists for that feature, then it 
>>> gets left along.
>>
>>
>>
>>> From 7.2.2:
>>
>>
>> "If, and only if, the proxy did not find any explicit preferences in the
>> request (because there was no Accept-Contact or Reject-Contact header
>> field), the proxy extracts implicit preferences."
>>
>> This wording seems pretty all or nothing.
> 
> 
> My brain is getting fuzzy on this. I'm pretty sure it used to be the 
> other way. I have a vague recollection of discussing this with Jonathan, 
> but don't recall why this change was made. We'll have to wait for an 
> explanation from him.

Yes, this did change during the evolution of the draft.

We even had a thread on the sip list on this, as I recall. The problem 
was that the network simply cannot accurately determine the user intent 
when the user includes caller preferences. There are several ways one 
might attempt to include implicit preferences into a request that 
already has explicit preferences. You could add a new term in each 
existing conjunction, or you can add a new predicate entirely. What I 
found was that sometimes one was the right thing, and other times, the 
other. It depended on what the user was trying to accomplish. But, the 
proxy cant know what the user was trying to accomplish.

Since implicit preferences were really meant to cover the case where the 
caller didnt support them, I changed the spec to only have proxies 
compute implicit preferences when there were no explicit ones. I then 
added text recommending that a UAC place explicit prefrences for methods 
and event packages.

So, I feel that the current behavior is the right thing.

> 
>>> Of couse that still makes it possible to do something dumb, but you 
>>> have to be pretty overt about it. For instance, you could send an 
>>> INVITE, but accept contacts that support only SUBSCRIBE. In that case 
>>> I think you get what you deserve.
>>
>>
>> I can imagine the caller doing this on purpose as an intentional
>> circumvention of callee policy.

I don't really see the danger here. It definitely makes sense for the 
Accept-Contact to list methods beyond the one for the request iself, so 
we've already decoupled the two. The spec recommends that you do include 
the method of the request in the listing:

> A UAC can express explicit preferences for the methods and event
>    packages supported by a UA. It is RECOMMENDED that a UA include a
>    term in an Accept-Contact feature set with the "methods" feature tag,
>    whose value includes the method of the request.


This is at SHOULD/RECOMMENDED strength. I think thats right. Nothing 
breaks if you don't include it. You just may get a 405. Maybe that was 
the intent, in which case, your request was properly formulated. So, 
SHOULD is the right strength - do this unless you have a compelling 
reason otherwise.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             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 mailnull@www1.ietf.org  Wed Apr 23 02:37:33 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05541
	for <sip-archive@odin.ietf.org>; Wed, 23 Apr 2003 02:37:33 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3N6nRJ28202
	for sip-archive@odin.ietf.org; Wed, 23 Apr 2003 02:49:27 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N6nC828194;
	Wed, 23 Apr 2003 02:49:12 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N6mt828165
	for <sip@optimus.ietf.org>; Wed, 23 Apr 2003 02:48: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 CAA05468
	for <sip@ietf.org>; Wed, 23 Apr 2003 02:36:31 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198Du7-0000iu-00
	for sip@ietf.org; Wed, 23 Apr 2003 02:38:51 -0400
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 198Du6-0000il-00
	for sip@ietf.org; Wed, 23 Apr 2003 02:38:51 -0400
Received: from dynamicsoft.com ([63.113.46.12])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h3N6cZdh000782;
	Wed, 23 Apr 2003 02:38:35 -0400 (EDT)
Message-ID: <3EA634E2.7030009@dynamicsoft.com>
Date: Wed, 23 Apr 2003 02:38:26 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
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: Ben Campbell <bcampbell@dynamicsoft.com>
CC: Paul Kyzivat <pkyzivat@cisco.com>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>, sip <sip@ietf.org>
References: <1050964235.2808.101.camel@verite.localdomain>
In-Reply-To: <1050964235.2808.101.camel@verite.localdomain>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Re: Callerprefs: Mid-dialog requests
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit



Ben Campbell wrote:
> The draft does not seem clear on how caller preferences affect
> mid-dialog requests. I expected when reading this that caller
> preferences would only apply to requests outside an existing dialog, and
> that normal dialog routing would prevail for mid-dialog requests.

Right. Section 4 says this:

    Both request handling and feature preferences can appear in any
    request, not just INVITE. However, they are only useful in requests
    where proxies need to determine a request target. If the domain in
    the request URI is not owned by any proxies along the request path,
    those proxies will never access a location service, and therefore,
    never have the opportunity to apply the caller preferences. This
    makes sense; typically, the request URI will identify a UAS for mid-
    dialog requests. In those cases, the routing decisions were already
    made on the initial request, and it makes no sense to redo them for
    subsequent requests in the dialog.

This is repeated in the section on proxy processing, which says that you 
only use caller prefs when you are the owner of the domain in the r-uri, 
and therefore, accessing a location service. That rules out mid-dialog 
requests.

> 
> However, the statements about putting feature set parameters into the
> Contact header when a mid-dialog request retargets the remote Contact
> confuses that point for me. 

Thats a different application of the parameters. Thats a declaration of 
capabilities, not a request for routing preferences.

> I am uncertain what use cases there might be
> for that feature. The only thing I can think of is to convey information
> to the opposite UA that it might use when re-inviting or establishing a
> new dialog. But I don't think that usage really fits the scope or
> purpose of this draft.

One important use case is conferencing. When you end up in an ad-hoc 
conference, the UA becomes a focus, and thus needs to do a re-invite to 
update its contact to include the isfocus parameter.

-Jonathan R.


-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             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 mailnull@www1.ietf.org  Wed Apr 23 02:48:41 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05783
	for <sip-archive@odin.ietf.org>; Wed, 23 Apr 2003 02:48:41 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3N70ZP28728
	for sip-archive@odin.ietf.org; Wed, 23 Apr 2003 03:00:35 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N70F828710;
	Wed, 23 Apr 2003 03:00:15 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N6xa828645
	for <sip@optimus.ietf.org>; Wed, 23 Apr 2003 02:59:36 -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 CAA05764
	for <sip@ietf.org>; Wed, 23 Apr 2003 02:47:11 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198E4R-0000nd-00
	for sip@ietf.org; Wed, 23 Apr 2003 02:49:32 -0400
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 198E4R-0000nM-00
	for sip@ietf.org; Wed, 23 Apr 2003 02:49:31 -0400
Received: from dynamicsoft.com ([63.113.46.12])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h3N6nGdh000788;
	Wed, 23 Apr 2003 02:49:16 -0400 (EDT)
Message-ID: <3EA63764.5020500@dynamicsoft.com>
Date: Wed, 23 Apr 2003 02:49:08 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
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: Ben Campbell <bcampbell@dynamicsoft.com>
CC: Paul Kyzivat <pkyzivat@cisco.com>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>, sip <sip@ietf.org>
References: <1050963873.2816.87.camel@verite.localdomain>
In-Reply-To: <1050963873.2816.87.camel@verite.localdomain>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Re: Callerprefs: Require header tag
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-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



Ben Campbell wrote:
> The use of a Require header tag does not seem to buy us much. In a
> REGISTER request, the best you can expect is the registrar knows to
> store the feature set parameters with the Contact. You cannot assume
> that each proxy that uses the registrar's location service knows about
> the "prefs" tag just because the registrar did. Also, the registrar
> cannot be expected to know the capabilities of every proxy that might
> possible use its location service.

Thats a good point. The model I had in my head was of the registrar and 
proxy being co-located, but you are right that need not be the case. 
However, practically speaking, I would expect these to be either the 
same, or made by the same vendor, in which case the assumption usually 
will hold.

> 
> I think it would be better to dispense with the Require tag completely,
> and just assert that the UA cannot assume that feature parameters will
> be honored in any way. This seems to fit with the concept that a proxy
> can override any of this due to local policy anyway.

There is a difference between not understanding the request, and 
understadning it, but denying it because of policy reasons.

> 
> If we do keep the tag, then we need to explicitly document its limited
> scope. 
> 

My inclination is to keep it, and document the scope. The text now reads:

The REGISTER request MAY contain a Require
header field with the value  ``pref'' if the client wants to be sure
that the registrar understands the extensions
defined in this specification. This means that the registrar will
store the caller preferences parameters, and make them available to
proxies accessing the location service within the domain. In absence of
the Require header field, a registrar that does not understand this 
extension
will simply ignore the Contact header field parameters. Note that even
if the registrar supports caller preferences, it does not mean that
all proxies in the domain which access the location service will
understand caller preferences. Therefore, the client cannot obtain a
guarantee that its preferences are taken into account.


Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             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 mailnull@www1.ietf.org  Wed Apr 23 02:51:24 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05828
	for <sip-archive@odin.ietf.org>; Wed, 23 Apr 2003 02:51:24 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3N73JV28850
	for sip-archive@odin.ietf.org; Wed, 23 Apr 2003 03:03:19 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N734828842;
	Wed, 23 Apr 2003 03:03:04 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N729828806
	for <sip@optimus.ietf.org>; Wed, 23 Apr 2003 03:02: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 CAA05809
	for <sip@ietf.org>; Wed, 23 Apr 2003 02:49:43 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198E6u-0000oS-00
	for sip@ietf.org; Wed, 23 Apr 2003 02:52:04 -0400
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 198E6t-0000oF-00
	for sip@ietf.org; Wed, 23 Apr 2003 02:52:03 -0400
Received: from dynamicsoft.com ([63.113.46.12])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h3N6pmdh000792;
	Wed, 23 Apr 2003 02:51:48 -0400 (EDT)
Message-ID: <3EA637FB.5020806@dynamicsoft.com>
Date: Wed, 23 Apr 2003 02:51:39 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
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: Ben Campbell <bcampbell@dynamicsoft.com>
CC: Paul Kyzivat <pkyzivat@cisco.com>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>, sip <sip@ietf.org>
References: <1051022322.2808.151.camel@verite.localdomain>
In-Reply-To: <1051022322.2808.151.camel@verite.localdomain>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Re: Callerprefs: UAS processing of misrouted requests
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit



Ben Campbell wrote:
> The draft states that if a UAS has registered multiple contacts with
> different feature sets, and receives a request to one of those contacts
> where the preferences do not match, it should either internally retarget
> the request to a contact that _does_ match, or reject the request.
> 
> I don't think the _standard_ should make the UAS into a caller prefs
> enforcement point. 

The problem is that we NEED this capability for some of the assisted 
transfer cases to work. Thats why the UA processing was added in the 
first place.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             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 mailnull@www1.ietf.org  Wed Apr 23 02:58:42 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05926
	for <sip-archive@odin.ietf.org>; Wed, 23 Apr 2003 02:58:41 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3N7AaI29993
	for sip-archive@odin.ietf.org; Wed, 23 Apr 2003 03:10:36 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N7AB829977;
	Wed, 23 Apr 2003 03:10:11 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N79w829946
	for <sip@optimus.ietf.org>; Wed, 23 Apr 2003 03:09: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 CAA05907
	for <sip@ietf.org>; Wed, 23 Apr 2003 02:57:33 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198EEU-0000qo-00
	for sip@ietf.org; Wed, 23 Apr 2003 02:59:54 -0400
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 198EET-0000qk-00
	for sip@ietf.org; Wed, 23 Apr 2003 02:59:53 -0400
Received: from dynamicsoft.com ([63.113.46.12])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h3N6xQdh000795;
	Wed, 23 Apr 2003 02:59:26 -0400 (EDT)
Message-ID: <3EA639C5.6030203@dynamicsoft.com>
Date: Wed, 23 Apr 2003 02:59:17 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
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: Henning Schulzrinne <hgs@cs.columbia.edu>
CC: Paul Kyzivat <pkyzivat@cisco.com>,
        Mary Barnes <mbarnes@nortelnetworks.com>,
        "'sip@ietf.org'" <sip@ietf.org>
References: <1B54FA3A2709D51195C800508BF9386A09DABCE6@zrc2c000.us.nortel.com> <3EA5B7EA.2010002@cisco.com> <3EA5F173.3060500@cs.columbia.edu>
In-Reply-To: <3EA5F173.3060500@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Re: Callerprefs: Mobility tag
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Well, practically speaking, people tell me all the time to "call me on 
my mobile". Caller preferences would allow me to do that without needing 
to have two numbers for that person.

Now, addressing Mary's main point, about adding other definitions for 
mobility. I don't want this to be a technology definition - i.e., 3g 
being different than 2g being different that WiFi. I think the essential 
aspect of it is whether there is a fixed poitn of attachment to the 
network or not As such, it is my preference to just remove the "in 
between" bit. Here is the new text:

\item[Summary of the media feature indicated by this tag:] The
mobility feature tag indicates whether the device is fixed (meaning
that it is associated with a fixed point of contact with the network),
or mobile (meaning that it is not associated with a fixed point of
contact). Note that cordless phones are fixed, not mobile, based on
this definition.


-Jonathan R.

Henning Schulzrinne wrote:
> I think this is useful. Yes, having something like "don't call if it 
> costs extra" or "don't call if the person is in a car or meeting" would 
> be better, but until everybody uses RPIDS, 'no mobile phone' is a pretty 
> good approximation and actually implementable. (In European countries, 
> the *caller* pays more for mobile calls, so this is a real concern. And 
> mobile is indeed the distinction that matters, not something else.)
> 
> Paul Kyzivat wrote:
> 
>> I've always had trouble with the semantics of this feature. All the 
>> examples I can think of for using it really depend of coincidental 
>> association between mobility and other features.
>>
>> For instance, *why* would I prefer to call someone on their fixed 
>> phone rather than their mobile phone?
>>
>> - because use of the mobile phone is expensive?
>>
>> - because I know the fixed phone is in a particular location
>>   and I only want to reach them if they are there.
>>
>> Neither of these are really directly related to the fixed nature of 
>> the phone.
>>
>> I think I asked Jonathan about this and he felt it should be kept 
>> because it had been around for a long time and we didn't have 
>> justification for removing it. Personally I think it could just go away.
>>
>>     Paul
>>
>> Mary Barnes wrote:
>>
>>> In section 9.9, the mobility tag is described as "indicates whether the
>>> device is fixed, wireless or somewhere in-between", however, there is no
>>> definition for the somewhere in-between. So, my initial reaction 
>>> would be to reword this as "indicates whether the
>>> device is fixed or wireless", but then I got to thinking about what 
>>> could
>>> have been meant by some in-between and I think there might be some 
>>> value in
>>> defining some of those now. One term I had considered was "nomadic" 
>>> as the "in-between".  But, then I
>>> also got to thinking that perhaps "WiFi" is a good example of the
>>> "in-between".  The usefulness of these really depends upon how they
>>> would/could be used.  The one example I saw in the usecases draft was 
>>> around
>>> wanting to contact someone only on their mobile phone.  The inverse 
>>> of this
>>> could be that you absolutely don't want to contact them on their mobile
>>> phone, but would want to contact them on anything else or perhaps 
>>> only if
>>> they're "fixed" or "WiFi". "Nomadic" might be useful for scenarios 
>>> whereby
>>> one's network connectivity is via tunneling, thus it's indicative not 
>>> being
>>> reachable at the "fixed" device (eg. the hard SIP client), but you are
>>> available on your soft SIP client working from home.   I haven't thought
>>> this all the way through, but I do think additional terms could be 
>>> extremely
>>> useful.
>>>
>>> Mary H. Barnes
>>> mbarnes@nortelnetworks.com
>>>
>>>
> 

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             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 mailnull@www1.ietf.org  Wed Apr 23 06:34:07 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10424
	for <sip-archive@odin.ietf.org>; Wed, 23 Apr 2003 06:34:07 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3NAk5H12636
	for sip-archive@odin.ietf.org; Wed, 23 Apr 2003 06:46:05 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NAjc812621;
	Wed, 23 Apr 2003 06:45:39 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NAhH812551
	for <sip@optimus.ietf.org>; Wed, 23 Apr 2003 06:43: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 GAA10289
	for <sip@ietf.org>; Wed, 23 Apr 2003 06:30:48 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198HYp-0001t2-00
	for sip@ietf.org; Wed, 23 Apr 2003 06:33:07 -0400
Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 198HYp-0001sz-00
	for sip@ietf.org; Wed, 23 Apr 2003 06:33:07 -0400
Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57])
	by hoemail2.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NAX0F06711
	for <sip@ietf.org>; Wed, 23 Apr 2003 06:33:00 -0400 (EDT)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19)
	id <XNTDR6K4>; Wed, 23 Apr 2003 11:32:59 +0100
Message-ID: <475FF955A05DD411980D00508B6D5FB00439ECDD@en0033exch001u.uk.lucent.com>
From: "Drage, Keith (Keith)" <drage@lucent.com>
To: "'Henning Schulzrinne'" <hgs@cs.columbia.edu>,
        Paul Kyzivat
	 <pkyzivat@cisco.com>
Cc: Mary Barnes <mbarnes@nortelnetworks.com>,
        Jonathan Rosenberg
	 <jdrosen@dynamicsoft.com>,
        "'sip@ietf.org'" <sip@ietf.org>
Subject: RE: [Sip] Re: Callerprefs: Mobility tag
Date: Wed, 23 Apr 2003 11:32:57 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

I think I agree with Paul on this one.

Unless someone comes up with a single set of semantics of what it means, it should go away.

What makes it useless is that the explanation below gives two, possibly mutually incompatible, semantics for the same parameter.

I would also point out that the charging characteristics (in Europe) for mobile and fixed line calls are so completely different that it is difficult to conclude on the basis of a single call whether one is cheaper or not. Yes, roaming will maked the roaming user (who could either be calling or called) incur call charges, but the roaming user makes a personal choice to turn their phone on when they are roaming. And the bulk of subscribers making lots of calls are not roaming.

Keith

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

> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: 23 April 2003 02:51
> To: Paul Kyzivat
> Cc: Mary Barnes; Jonathan Rosenberg; 'sip@ietf.org'
> Subject: [Sip] Re: Callerprefs: Mobility tag
> 
> 
> I think this is useful. Yes, having something like "don't call if it 
> costs extra" or "don't call if the person is in a car or 
> meeting" would 
> be better, but until everybody uses RPIDS, 'no mobile phone' 
> is a pretty 
> good approximation and actually implementable. (In European 
> countries, 
> the *caller* pays more for mobile calls, so this is a real 
> concern. And 
> mobile is indeed the distinction that matters, not something else.)
> 
> Paul Kyzivat wrote:
> 
> > I've always had trouble with the semantics of this feature. All the 
> > examples I can think of for using it really depend of coincidental 
> > association between mobility and other features.
> > 
> > For instance, *why* would I prefer to call someone on their 
> fixed phone 
> > rather than their mobile phone?
> > 
> > - because use of the mobile phone is expensive?
> > 
> > - because I know the fixed phone is in a particular location
> >   and I only want to reach them if they are there.
> > 
> > Neither of these are really directly related to the fixed 
> nature of the 
> > phone.
> > 
> > I think I asked Jonathan about this and he felt it should be kept 
> > because it had been around for a long time and we didn't have 
> > justification for removing it. Personally I think it could 
> just go away.
> > 
> >     Paul
> > 
> > Mary Barnes wrote:
> > 
> >> In section 9.9, the mobility tag is described as 
> "indicates whether the
> >> device is fixed, wireless or somewhere in-between", 
> however, there is no
> >> definition for the somewhere in-between. 
> >> So, my initial reaction would be to reword this as 
> "indicates whether the
> >> device is fixed or wireless", but then I got to thinking 
> about what could
> >> have been meant by some in-between and I think there might be some 
> >> value in
> >> defining some of those now. 
> >> One term I had considered was "nomadic" as the 
> "in-between".  But, then I
> >> also got to thinking that perhaps "WiFi" is a good example of the
> >> "in-between".  The usefulness of these really depends upon how they
> >> would/could be used.  The one example I saw in the 
> usecases draft was 
> >> around
> >> wanting to contact someone only on their mobile phone.  
> The inverse of 
> >> this
> >> could be that you absolutely don't want to contact them on 
> their mobile
> >> phone, but would want to contact them on anything else or 
> perhaps only if
> >> they're "fixed" or "WiFi". "Nomadic" might be useful for scenarios 
> >> whereby
> >> one's network connectivity is via tunneling, thus it's 
> indicative not 
> >> being
> >> reachable at the "fixed" device (eg. the hard SIP client), 
> but you are
> >> available on your soft SIP client working from home.   I 
> haven't thought
> >> this all the way through, but I do think additional terms could be 
> >> extremely
> >> useful.
> >>
> >> Mary H. Barnes
> >> mbarnes@nortelnetworks.com
> >>
> >>
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Wed Apr 23 07:36:32 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13799
	for <sip-archive@odin.ietf.org>; Wed, 23 Apr 2003 07:36:32 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3NBmWI17008
	for sip-archive@odin.ietf.org; Wed, 23 Apr 2003 07:48:32 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NBlL816936;
	Wed, 23 Apr 2003 07:47:21 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NBiH816775
	for <sip@optimus.ietf.org>; Wed, 23 Apr 2003 07:44: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 HAA13384
	for <sip@ietf.org>; Wed, 23 Apr 2003 07:31:47 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198IVq-0002hb-00
	for sip@ietf.org; Wed, 23 Apr 2003 07:34:06 -0400
Received: from [61.144.161.2] (helo=mta0)
	by ietf-mx with esmtp (Exim 4.12)
	id 198IVp-0002f8-00
	for sip@ietf.org; Wed, 23 Apr 2003 07:34:06 -0400
Received: from Natarajucl1127 (mta0 [172.17.1.62])
 by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
 2002)) with ESMTPA id <0HDS0049QNHKO8@mta0.huawei.com> for sip@ietf.org; Wed,
 23 Apr 2003 19:20:10 +0800 (CST)
Date: Wed, 23 Apr 2003 16:51:36 +0530
From: "Nataraju A.B." <natarajuab@huawei.com>
To: sip@ietf.org
Message-id: <001101c3098a$81785670$5d02120a@in.huawei.com>
Organization: HTIPL
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
Content-type: multipart/alternative;
 boundary="Boundary_(ID_U6HMomc8+Q3TxhXsBfcR5A)"
X-Priority: 3
X-MSMail-priority: Normal
Subject: [Sip] A doubt about Request-URI modification in 3261 compliant proxies.
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

--Boundary_(ID_U6HMomc8+Q3TxhXsBfcR5A)
Content-type: text/plain; charset=Windows-1252
Content-Transfer-Encoding: 7BIT

Hi, 

I have a query about request forwarding in proxies...

16.6 Request Forwarding
      2. Request-URI

         The Request-URI in the copy's start line MUST be replaced with
         the URI for this target.  If the URI contains any parameters
         not allowed in a Request-URI, they MUST be removed.

This section says the request URI will be updated fir each request sent out by the proxy. 

What I understood is that it must be same if it is 3261 compliant proxy and the route set received has teh lr parameter also. The statement is correct with respect to strict routing( rfc2543 ) where as rfc3261 make use the loose routing...

Regards,
-Nataraju A.B.


--------------------------------------------------------------------------------
 

--Boundary_(ID_U6HMomc8+Q3TxhXsBfcR5A)
Content-type: text/html; charset=Windows-1252
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=windows-1252"><BASE 
href="file://C:\Program Files\Common Files\Microsoft Shared\Stationery\">
<META content="MSHTML 5.50.4134.600" name=GENERATOR></HEAD>
<BODY 
style="BACKGROUND-POSITION: right bottom; FONT-WEIGHT: normal; FONT-SIZE: 10pt; BACKGROUND-IMAGE: url(http://skins.hotbar.com/skins/mailskins/st/112601/112601bird2_1.jpg); MARGIN: 3px 160px 50px 5px; COLOR: #000000; BACKGROUND-REPEAT: no-repeat; FONT-FAMILY: Courier New; BACKGROUND-COLOR: #dceff6" 
vLink=#06ff00 aLink=#06ff00 link=#06ff00 bgColor=#dceff6 stationery_tag_mark 
hbtype="st" hmark="hotbar_element">
<DIV>Hi, </DIV>
<DIV>&nbsp;</DIV>
<DIV>I have a query about request forwarding in proxies...</DIV>
<DIV>&nbsp;</DIV>
<DIV>16.6 Request Forwarding<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2. 
Request-URI</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The Request-URI in the 
copy's start line MUST be replaced 
with<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the URI for this 
target.&nbsp; If the URI contains any 
parameters<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; not allowed in a 
Request-URI, they MUST be removed.</DIV>
<DIV>&nbsp;</DIV>
<DIV>This section says the request URI will be updated fir each request sent out 
by the proxy. </DIV>
<DIV>&nbsp;</DIV>
<DIV>What I understood is that it must be same if it is 3261 compliant proxy and 
the route set received has teh lr parameter also. The statement is correct with 
respect to strict routing( rfc2543 )&nbsp;where as rfc3261 make use the loose 
routing...</DIV>
<DIV>&nbsp;</DIV>
<DIV>Regards,<BR>-Nataraju A.B.</DIV><!--mail_content--><SPAN 
id=hotbar_element_used stationery_tag_mark></SPAN>
<DIV id=hotbar_promo><BR>
<HR align=left width="100%" color=gray noShade SIZE=1>
<A 
href="http://promos.hotbar.com/promos/promodll.dll?RunPromo&amp;El=hotbar%5felement%3bst%3b&amp;SG=&amp;RAND=49365"><IMG 
title="" alt="Upgrade Your Email - Click here!" 
src='http://promos.hotbar.com/promos/promodll.dll?GetPromo&amp;El=hotbar%5felement%3bst%3b&amp;SG=&amp;RAND=49365"' 
border=0></A> </DIV></BODY></HTML>

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



From mailnull@www1.ietf.org  Wed Apr 23 09:34:07 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17678
	for <sip-archive@odin.ietf.org>; Wed, 23 Apr 2003 09:34:07 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3NDkA925759
	for sip-archive@odin.ietf.org; Wed, 23 Apr 2003 09:46:10 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NDjJ825699;
	Wed, 23 Apr 2003 09:45:22 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NDh3825575
	for <sip@optimus.ietf.org>; Wed, 23 Apr 2003 09:43: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 JAA17557
	for <sip@ietf.org>; Wed, 23 Apr 2003 09:30:29 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198KMj-0003kU-00
	for sip@ietf.org; Wed, 23 Apr 2003 09:32:49 -0400
Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112])
	by ietf-mx with esmtp (Exim 4.12)
	id 198KMj-0003jE-00
	for sip@ietf.org; Wed, 23 Apr 2003 09:32:49 -0400
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NDVcR29169;
	Wed, 23 Apr 2003 08:31:38 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <HNP4YFA3>; Wed, 23 Apr 2003 08:31:38 -0500
Message-ID: <1B54FA3A2709D51195C800508BF9386A09DABCEC@zrc2c000.us.nortel.com>
From: "Mary Barnes" <mbarnes@nortelnetworks.com>
To: "'Drage, Keith (Keith)'" <drage@lucent.com>,
        "'Henning Schulzrinne'"
	 <hgs@cs.columbia.edu>,
        Paul Kyzivat <pkyzivat@cisco.com>
Cc: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "'sip@ietf.org'"
	 <sip@ietf.org>
Subject: RE: [Sip] Re: Callerprefs: Mobility tag
Date: Wed, 23 Apr 2003 08:31:38 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

I think there is still some value in just keeping it at "Fixed" and "Mobile"
(per my initial reaction that the "or somewhere in between" needed to be
deleted).  My original posting had been to perhaps expand, but I've been
thinking about that further and clearly there is no compelling reason.  

I think it is still useful for the specific context whereby I as a caller
don't want my calls to go to people's mobiles (even if they do want them to)
OR I only want to go to their mobile or fixed contacts.  Given the current
24/7 reachability empowered by SIP, I think this is useful functionality.  I
also think this is useful given that it's difficult to attach a "personal"
vs. "business" association to mobiles, since most folks use them for both.
Now, this is all predicated on folks registering their contacts with these
tags, but I know that for our system we have implemented the "mobile" tag
and do find it useful. 

Mary.

-----Original Message-----
From: Drage, Keith (Keith) [mailto:drage@lucent.com]
Sent: Wednesday, April 23, 2003 5:33 AM
To: 'Henning Schulzrinne'; Paul Kyzivat
Cc: Barnes, Mary [NGC:B602:EXCH]; Jonathan Rosenberg; 'sip@ietf.org'
Subject: RE: [Sip] Re: Callerprefs: Mobility tag


I think I agree with Paul on this one.

Unless someone comes up with a single set of semantics of what it means, it
should go away.

What makes it useless is that the explanation below gives two, possibly
mutually incompatible, semantics for the same parameter.

I would also point out that the charging characteristics (in Europe) for
mobile and fixed line calls are so completely different that it is difficult
to conclude on the basis of a single call whether one is cheaper or not.
Yes, roaming will maked the roaming user (who could either be calling or
called) incur call charges, but the roaming user makes a personal choice to
turn their phone on when they are roaming. And the bulk of subscribers
making lots of calls are not roaming.

Keith

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

> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: 23 April 2003 02:51
> To: Paul Kyzivat
> Cc: Mary Barnes; Jonathan Rosenberg; 'sip@ietf.org'
> Subject: [Sip] Re: Callerprefs: Mobility tag
> 
> 
> I think this is useful. Yes, having something like "don't call if it 
> costs extra" or "don't call if the person is in a car or 
> meeting" would 
> be better, but until everybody uses RPIDS, 'no mobile phone' 
> is a pretty 
> good approximation and actually implementable. (In European 
> countries, 
> the *caller* pays more for mobile calls, so this is a real 
> concern. And 
> mobile is indeed the distinction that matters, not something else.)
> 
> Paul Kyzivat wrote:
> 
> > I've always had trouble with the semantics of this feature. All the 
> > examples I can think of for using it really depend of coincidental 
> > association between mobility and other features.
> > 
> > For instance, *why* would I prefer to call someone on their 
> fixed phone 
> > rather than their mobile phone?
> > 
> > - because use of the mobile phone is expensive?
> > 
> > - because I know the fixed phone is in a particular location
> >   and I only want to reach them if they are there.
> > 
> > Neither of these are really directly related to the fixed 
> nature of the 
> > phone.
> > 
> > I think I asked Jonathan about this and he felt it should be kept 
> > because it had been around for a long time and we didn't have 
> > justification for removing it. Personally I think it could 
> just go away.
> > 
> >     Paul
> > 
> > Mary Barnes wrote:
> > 
> >> In section 9.9, the mobility tag is described as 
> "indicates whether the
> >> device is fixed, wireless or somewhere in-between", 
> however, there is no
> >> definition for the somewhere in-between. 
> >> So, my initial reaction would be to reword this as 
> "indicates whether the
> >> device is fixed or wireless", but then I got to thinking 
> about what could
> >> have been meant by some in-between and I think there might be some 
> >> value in
> >> defining some of those now. 
> >> One term I had considered was "nomadic" as the 
> "in-between".  But, then I
> >> also got to thinking that perhaps "WiFi" is a good example of the
> >> "in-between".  The usefulness of these really depends upon how they
> >> would/could be used.  The one example I saw in the 
> usecases draft was 
> >> around
> >> wanting to contact someone only on their mobile phone.  
> The inverse of 
> >> this
> >> could be that you absolutely don't want to contact them on 
> their mobile
> >> phone, but would want to contact them on anything else or 
> perhaps only if
> >> they're "fixed" or "WiFi". "Nomadic" might be useful for scenarios 
> >> whereby
> >> one's network connectivity is via tunneling, thus it's 
> indicative not 
> >> being
> >> reachable at the "fixed" device (eg. the hard SIP client), 
> but you are
> >> available on your soft SIP client working from home.   I 
> haven't thought
> >> this all the way through, but I do think additional terms could be 
> >> extremely
> >> useful.
> >>
> >> Mary H. Barnes
> >> mbarnes@nortelnetworks.com
> >>
> >>
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Wed Apr 23 09:36:32 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17780
	for <sip-archive@odin.ietf.org>; Wed, 23 Apr 2003 09:36:32 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3NDmZd25964
	for sip-archive@odin.ietf.org; Wed, 23 Apr 2003 09:48:35 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NDmF825940;
	Wed, 23 Apr 2003 09:48:15 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NDlr825900
	for <sip@optimus.ietf.org>; Wed, 23 Apr 2003 09:47: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 JAA17732
	for <sip@ietf.org>; Wed, 23 Apr 2003 09:35:19 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198KRP-0003nJ-00
	for sip@ietf.org; Wed, 23 Apr 2003 09:37:39 -0400
Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112])
	by ietf-mx with esmtp (Exim 4.12)
	id 198KRP-0003mo-00
	for sip@ietf.org; Wed, 23 Apr 2003 09:37:39 -0400
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NDbBR29972;
	Wed, 23 Apr 2003 08:37:11 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <HNP4YF1Q>; Wed, 23 Apr 2003 08:37:11 -0500
Message-ID: <1B54FA3A2709D51195C800508BF9386A09DABCED@zrc2c000.us.nortel.com>
From: "Mary Barnes" <mbarnes@nortelnetworks.com>
To: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>,
        Henning Schulzrinne
	 <hgs@cs.columbia.edu>
Cc: Paul Kyzivat <pkyzivat@cisco.com>, "'sip@ietf.org'" <sip@ietf.org>
Date: Wed, 23 Apr 2003 08:37:08 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Subject: [Sip] RE: Callerprefs: Mobility tag
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

Per my response to Keith's posting, I agree with this proposal (retracting
my suggestion to add other definitions). 

Mary.

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Wednesday, April 23, 2003 1:59 AM
To: Henning Schulzrinne
Cc: Paul Kyzivat; Barnes, Mary [NGC:B602:EXCH]; 'sip@ietf.org'
Subject: Re: Callerprefs: Mobility tag


Well, practically speaking, people tell me all the time to "call me on 
my mobile". Caller preferences would allow me to do that without needing 
to have two numbers for that person.

Now, addressing Mary's main point, about adding other definitions for 
mobility. I don't want this to be a technology definition - i.e., 3g 
being different than 2g being different that WiFi. I think the essential 
aspect of it is whether there is a fixed poitn of attachment to the 
network or not As such, it is my preference to just remove the "in 
between" bit. Here is the new text:

\item[Summary of the media feature indicated by this tag:] The
mobility feature tag indicates whether the device is fixed (meaning
that it is associated with a fixed point of contact with the network),
or mobile (meaning that it is not associated with a fixed point of
contact). Note that cordless phones are fixed, not mobile, based on
this definition.


-Jonathan R.

Henning Schulzrinne wrote:
> I think this is useful. Yes, having something like "don't call if it 
> costs extra" or "don't call if the person is in a car or meeting" would 
> be better, but until everybody uses RPIDS, 'no mobile phone' is a pretty 
> good approximation and actually implementable. (In European countries, 
> the *caller* pays more for mobile calls, so this is a real concern. And 
> mobile is indeed the distinction that matters, not something else.)
> 
> Paul Kyzivat wrote:
> 
>> I've always had trouble with the semantics of this feature. All the 
>> examples I can think of for using it really depend of coincidental 
>> association between mobility and other features.
>>
>> For instance, *why* would I prefer to call someone on their fixed 
>> phone rather than their mobile phone?
>>
>> - because use of the mobile phone is expensive?
>>
>> - because I know the fixed phone is in a particular location
>>   and I only want to reach them if they are there.
>>
>> Neither of these are really directly related to the fixed nature of 
>> the phone.
>>
>> I think I asked Jonathan about this and he felt it should be kept 
>> because it had been around for a long time and we didn't have 
>> justification for removing it. Personally I think it could just go away.
>>
>>     Paul
>>
>> Mary Barnes wrote:
>>
>>> In section 9.9, the mobility tag is described as "indicates whether the
>>> device is fixed, wireless or somewhere in-between", however, there is no
>>> definition for the somewhere in-between. So, my initial reaction 
>>> would be to reword this as "indicates whether the
>>> device is fixed or wireless", but then I got to thinking about what 
>>> could
>>> have been meant by some in-between and I think there might be some 
>>> value in
>>> defining some of those now. One term I had considered was "nomadic" 
>>> as the "in-between".  But, then I
>>> also got to thinking that perhaps "WiFi" is a good example of the
>>> "in-between".  The usefulness of these really depends upon how they
>>> would/could be used.  The one example I saw in the usecases draft was 
>>> around
>>> wanting to contact someone only on their mobile phone.  The inverse 
>>> of this
>>> could be that you absolutely don't want to contact them on their mobile
>>> phone, but would want to contact them on anything else or perhaps 
>>> only if
>>> they're "fixed" or "WiFi". "Nomadic" might be useful for scenarios 
>>> whereby
>>> one's network connectivity is via tunneling, thus it's indicative not 
>>> being
>>> reachable at the "fixed" device (eg. the hard SIP client), but you are
>>> available on your soft SIP client working from home.   I haven't thought
>>> this all the way through, but I do think additional terms could be 
>>> extremely
>>> useful.
>>>
>>> Mary H. Barnes
>>> mbarnes@nortelnetworks.com
>>>
>>>
> 

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             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 mailnull@www1.ietf.org  Wed Apr 23 10:25:00 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20699
	for <sip-archive@odin.ietf.org>; Wed, 23 Apr 2003 10:25:00 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3NEb4N29501
	for sip-archive@odin.ietf.org; Wed, 23 Apr 2003 10:37:04 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NEaW829385;
	Wed, 23 Apr 2003 10:36:32 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NEZ3829328
	for <sip@optimus.ietf.org>; Wed, 23 Apr 2003 10:35: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 KAA20617
	for <sip@ietf.org>; Wed, 23 Apr 2003 10:22:28 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198LB2-0004Ek-00
	for sip@ietf.org; Wed, 23 Apr 2003 10:24:48 -0400
Received: from magus.nostrum.com ([208.21.192.130] ident=root)
	by ietf-mx with esmtp (Exim 4.12)
	id 198LB2-0004Ef-00
	for sip@ietf.org; Wed, 23 Apr 2003 10:24:48 -0400
Received: from localhost (root@localhost [127.0.0.1])
	by magus.nostrum.com (8.12.8/8.12.8) with ESMTP id h3NEOGS3095577;
	Wed, 23 Apr 2003 09:24:17 -0500 (CDT)
From: Ben Campbell <bcampbell@dynamicsoft.com>
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: Paul Kyzivat <pkyzivat@cisco.com>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>, sip <sip@ietf.org>
In-Reply-To: <3EA631AD.20406@dynamicsoft.com>
References: <1050963502.2816.73.camel@verite.localdomain>
	 <3EA631AD.20406@dynamicsoft.com>
Content-Type: text/plain
Message-Id: <1051107774.1531.18.camel@verite.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 23 Apr 2003 09:22:54 -0500
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Re: callerprefs: Various
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-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-04-23 at 01:24, Jonathan Rosenberg wrote:

[...]

> >6.1p4:
> > 
> > 6.1 Register Example: The example is inconsistent on whether a
> > boolean tag has an explicit "true/false" value, or simple exists. I
> > do not understand the semantic difference between the two syntaxes.
> 
> I'm confused. Section 6.1 paragraph 4 has nothing to do with boolean 
> tags. Its talking about the absence of feature tags entirely, not the 
> absence of a VALUE for a feature tag.
> 

Oops, sorry. The 6.1p4 reference was spurious. I was refering to the
register example at the end of 6.1. 

[...]

> Its the standard issue of writing text which is effectively trying to 
> convey what is ideally described using code. I don't think listing the 
> steps in a bullet form as opposed to sentences will really help.
> 

Is a C code fragment acceptable?




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



From mailnull@www1.ietf.org  Wed Apr 23 11:57:17 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24398
	for <sip-archive@odin.ietf.org>; Wed, 23 Apr 2003 11:57:17 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3NG9ME05679
	for sip-archive@odin.ietf.org; Wed, 23 Apr 2003 12:09:22 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NG8n805627;
	Wed, 23 Apr 2003 12:08:49 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NG2J804055
	for <sip@optimus.ietf.org>; Wed, 23 Apr 2003 12:02: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 LAA24077
	for <sip@ietf.org>; Wed, 23 Apr 2003 11:49:44 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198MXS-00050x-00
	for sip@ietf.org; Wed, 23 Apr 2003 11:52:02 -0400
Received: from mail.cit.ie ([157.190.14.15])
	by ietf-mx with esmtp (Exim 4.12)
	id 198MXS-00050n-00
	for sip@ietf.org; Wed, 23 Apr 2003 11:52:02 -0400
Received: from EEB174W2Kvk (unverified [157.190.81.172]) by cit.ie
 (Rockliffe SMTPRA 5.3.4) with SMTP id <B0000490138@mail.cit.ie> for <sip@ietf.org>;
 Wed, 23 Apr 2003 16:50:41 +0100
Reply-To: <vkenneally@cit.ie>
From: "Valerie Kenneally" <vkenneally@cit.ie>
To: <sip@ietf.org>
Date: Wed, 23 Apr 2003 16:51:47 +0100
Message-ID: <NIEFLFDIBJCPCKAMIGBPIEEMCGAA.vkenneally@cit.ie>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Subject: [Sip] SIP History trace doc
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-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,

	Just wondering if anyone knows of a document/s which trace the development
of SIP from its initial conception to its current state of
development-including first authors, dates etc..  Any input would be greatly
appreciated!

Cheers,
Valerie Kenneally

------------------------
Val Kenneally,
Post-Graduate,
Electronic Eng. Dept.,
CIT,
Rossa Ave.,
Bishopstown,
Cork,
Ireland.
------------------------
Tel: +353 87 2273668
Fax: +353 21 4326625


-------------------Legal  Disclaimer---------------------------------------

The above electronic mail transmission is confidential and intended only for the person to whom it is addressed. Its contents may be protected by legal and/or professional privilege. Should it be received by you in error please contact the sender at the above quoted email address. Any unauthorised form of reproduction of this message is strictly prohibited. The Institute does not guarantee the security of any information electronically transmitted and is not liable if the information contained in this communication is not a proper and complete record of the message as transmitted by the sender nor for any delay in its receipt.

----------------------------------------------------------------------------------------

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



From mailnull@www1.ietf.org  Wed Apr 23 12:46:15 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25613
	for <sip-archive@odin.ietf.org>; Wed, 23 Apr 2003 12:46:15 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3NGwLX08972
	for sip-archive@odin.ietf.org; Wed, 23 Apr 2003 12:58:21 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NGvn808933;
	Wed, 23 Apr 2003 12:57:49 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NGug808862
	for <sip@optimus.ietf.org>; Wed, 23 Apr 2003 12:56: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 MAA25585;
	Wed, 23 Apr 2003 12:44:06 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198NO5-0005OV-00; Wed, 23 Apr 2003 12:46:25 -0400
Received: from gateway.hns.com ([208.236.67.13])
	by ietf-mx with esmtp (Exim 4.12)
	id 198NO4-0005OS-00; Wed, 23 Apr 2003 12:46:24 -0400
Received: from excore8.hns.com (excore8.hns.com [139.85.52.126])
	by gateway.hns.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h3NGkhUk007926;
	Wed, 23 Apr 2003 12:46:43 -0400 (EDT)
Received: from atlas (atlas.hns.com [139.85.177.110])
	by excore8.hns.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h3NGkbGM025975;
	Wed, 23 Apr 2003 12:46:37 -0400 (EDT)
To: <vkenneally@cit.ie>
Cc: sip@ietf.org, sip-admin@ietf.org
Subject: Re: [Sip] SIP History trace doc
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF9EA8EB61.9E71E66E-ON85256D11.005BECBC@LocalDomain>
From: "Arjun Roychowdhury" <aroychow@hns.com>
Date: Wed, 23 Apr 2003 12:46:36 -0400
X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.12  |February 13, 2003) at 04/23/2003
 12:44:39 PM,
	Serialize complete at 04/23/2003 12:44:39 PM
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>

http://www1.cs.columbia.edu/sip/history.html
may be of help

regds
arjun

(ofcourse, it only reflects the mainstream draft evolution, not the 
million other drafts that go along with this :-)

--
Arjun Roychowdhury @ Hughes Software Systems
11717 Exploration Lane, Germantown MD 20876
(O): 301 212 7860 




"Valerie Kenneally" <vkenneally@cit.ie>
Sent by: sip-admin@ietf.org
04/23/2003 11:51 AM
Please respond to vkenneally

 
        To:     <sip@ietf.org>
        cc: 
        Subject:        [Sip] SIP History trace doc


Hi all,

                 Just wondering if anyone knows of a document/s which 
trace the development
of SIP from its initial conception to its current state of
development-including first authors, dates etc..  Any input would be 
greatly
appreciated!

Cheers,
Valerie Kenneally

------------------------
Val Kenneally,
Post-Graduate,
Electronic Eng. Dept.,
CIT,
Rossa Ave.,
Bishopstown,
Cork,
Ireland.
------------------------
Tel: +353 87 2273668
Fax: +353 21 4326625


-------------------Legal Disclaimer---------------------------------------

The above electronic mail transmission is confidential and intended only 
for the person to whom it is addressed. Its contents may be protected by 
legal and/or professional privilege. Should it be received by you in error 
please contact the sender at the above quoted email address. Any 
unauthorised form of reproduction of this message is strictly prohibited. 
The Institute does not guarantee the security of any information 
electronically transmitted and is not liable if the information contained 
in this communication is not a proper and complete record of the message 
as transmitted by the sender nor for any delay in its receipt.

----------------------------------------------------------------------------------------

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



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



From mailnull@www1.ietf.org  Wed Apr 23 12:55:38 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25930
	for <sip-archive@odin.ietf.org>; Wed, 23 Apr 2003 12:55:38 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3NH7iG10416
	for sip-archive@odin.ietf.org; Wed, 23 Apr 2003 13:07:44 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NH7G810001;
	Wed, 23 Apr 2003 13:07:16 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NH6m809517
	for <sip@optimus.ietf.org>; Wed, 23 Apr 2003 13:06: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 MAA25909;
	Wed, 23 Apr 2003 12:54:11 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198NXq-0005T6-00; Wed, 23 Apr 2003 12:56:30 -0400
Received: from uni01du.unity.ncsu.edu ([152.1.13.101])
	by ietf-mx with esmtp (Exim 4.12)
	id 198NXq-0005T3-00; Wed, 23 Apr 2003 12:56:30 -0400
Received: (from prsinha@localhost)
          by uni01du.unity.ncsu.edu (8.8.4/EC02Jan97)
	  id MAA23052; Wed, 23 Apr 2003 12:56:49 -0400 (EDT)
Date: Wed, 23 Apr 2003 12:56:49 -0400 (EDT)
From: Prabhas Ranjan Sinha <prsinha@unity.ncsu.edu>
To: Arjun Roychowdhury <aroychow@hns.com>
cc: vkenneally@cit.ie, sip@ietf.org, sip-admin@ietf.org
Subject: Re: [Sip] SIP History trace doc
In-Reply-To: <OF9EA8EB61.9E71E66E-ON85256D11.005BECBC@LocalDomain>
Message-ID: <Pine.GSO.4.53.0304231254120.22687@uni01du.unity.ncsu.edu>
References: <OF9EA8EB61.9E71E66E-ON85256D11.005BECBC@LocalDomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>


I think Alan Johnston has talked about it in his book "Understanding SIP",
if you can borrow it from someone :-)

- Prabhas
London Business School
London, UK


On Wed, 23 Apr 2003, Arjun Roychowdhury wrote:

> http://www1.cs.columbia.edu/sip/history.html
> may be of help
>
> regds
> arjun
>
> (ofcourse, it only reflects the mainstream draft evolution, not the
> million other drafts that go along with this :-)
>
> --
> Arjun Roychowdhury @ Hughes Software Systems
> 11717 Exploration Lane, Germantown MD 20876
> (O): 301 212 7860
>
>
>
>
> "Valerie Kenneally" <vkenneally@cit.ie>
> Sent by: sip-admin@ietf.org
> 04/23/2003 11:51 AM
> Please respond to vkenneally
>
>
>         To:     <sip@ietf.org>
>         cc:
>         Subject:        [Sip] SIP History trace doc
>
>
> Hi all,
>
>                  Just wondering if anyone knows of a document/s which
> trace the development
> of SIP from its initial conception to its current state of
> development-including first authors, dates etc..  Any input would be
> greatly
> appreciated!
>
> Cheers,
> Valerie Kenneally
>
> ------------------------
> Val Kenneally,
> Post-Graduate,
> Electronic Eng. Dept.,
> CIT,
> Rossa Ave.,
> Bishopstown,
> Cork,
> Ireland.
> ------------------------
> Tel: +353 87 2273668
> Fax: +353 21 4326625
>
>
> -------------------Legal Disclaimer---------------------------------------
>
> The above electronic mail transmission is confidential and intended only
> for the person to whom it is addressed. Its contents may be protected by
> legal and/or professional privilege. Should it be received by you in error
> please contact the sender at the above quoted email address. Any
> unauthorised form of reproduction of this message is strictly prohibited.
> The Institute does not guarantee the security of any information
> electronically transmitted and is not liable if the information contained
> in this communication is not a proper and complete record of the message
> as transmitted by the sender nor for any delay in its receipt.
>
> ----------------------------------------------------------------------------------------
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>
>

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



From mailnull@www1.ietf.org  Wed Apr 23 16:27:27 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05343
	for <sip-archive@odin.ietf.org>; Wed, 23 Apr 2003 16:27:27 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3NKTiq27997
	for sip-archive@odin.ietf.org; Wed, 23 Apr 2003 16:29:44 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NKTA827942;
	Wed, 23 Apr 2003 16:29:10 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NKOk827748
	for <sip@optimus.ietf.org>; Wed, 23 Apr 2003 16:24: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 QAA05145
	for <sip@ietf.org>; Wed, 23 Apr 2003 16:21:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198Qmw-00079E-00
	for sip@ietf.org; Wed, 23 Apr 2003 16:24:18 -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 198Qmv-000794-00
	for sip@ietf.org; Wed, 23 Apr 2003 16:24:17 -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 h3NKOBsC004834
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO);
	Wed, 23 Apr 2003 15:24:12 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: <alan.johnston@mci.com>, <sip@ietf.org>
Date: Wed, 23 Apr 2003 15:24:10 -0500
Message-ID: <002d01c309d6$4d709120$ee036e3f@txdwillis>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3NKOl827749
Subject: [Sip] Ongoing Expert Review: Comments on draft-johnston-sip-osp-token-04.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: 8bit


Ok, here are my comments on the P-header for osp-tokens. If anybody else has
something to say, please say it soon.



Draft Section 1, P4 says:
-------
   We propose to use existing IETF protocols and proposals in Internet 
   Drafts for interdomain IP telephony calls with QoS as a first step 
   toward a uniform AAA approach. The approach outlined here may be 
   useful later for developing a uniform AAA architecture and protocols 
   for other application layer services. 
---------

<dean> Don't "propose", document  . . . . Perhaps "This draft documents a
propietary SIP extension header field that may be used to exchange open
settlement protocol [4] information in the context of a SIP session
establishment." </dean> 
    



Draft, Figure 1 says:
----------------------    
                              Clearinghouse             
             +------+------+     +------+     +------+------+ 
             |Policy|  OSP | OSP | OSP  | OSP | OSP  |Policy| 
             |Server|Client|<--->|Server|<--->|Client|Server| 
             +------+------+     +------+     +------+------+ 
                | |                                   |  | 
    Domain 1    | +-----+                        +----+  |    Domain 2 
                |       |                        |       | 
            +-----+     |                        |    +-----+ 
            | PEP |     |                        |    | PEP | 
 +-----+    +-----+     |                        |    +-----+    +-----+ 
 | SIP |SIP | SIP |     |                        |    | SIP |SIP | SIP | 
 | UAC |<-->|Proxy|-------SIP INVITE with OSP Token-->|Proxy|<-->| UAS | 
 +-----+    +-----+     |                        |    +-----+    +--+--+ 
                        |                        |                  | 
                        |                        |                  | 
   SIP                  |                        |                  | 
  Phone            +------+                  +------+            +--+--+ 
 +------+          | Edge |       RSVP       | Edge |            |     | 
 | RSVP |    RSVP  |Router|      tunnel      |Router|     RSVP   | MG  | 
 | Host |<-------->|      |<---------------->|      |<---------->|     | 
 +------+          +------+   Transit Nets   +------+            +-----+ 
 
    
                  Figure 1:   Model for interdomain QoS phone call 
------------------

<dean> What the heck is an "RSVP tunnel"? Is this something like a GRE
tunnel between two edge routers which run RSVP such that it doesn't require
RSVP support in the routers traversed by that tunnel? Is this usage
documented somewhere, and if so, can you please give a reference in the
references section? Speaking of which, do we need to informatively reference
RSVP in this spec?</dean>

    
Draft, Section 3, Para 3 says:
------------------------------
   For these reasons, a new SIP header is proposed instead of a new MIME 
   type for OSP authorization tokens. 
------------------------------
<dean>  s/header/header field/ -- repeat in several places throughout doc
</dean>


Draft, Section 4, P 3 says:
---------------------------
   which the header filed can be used
---------------------------
<dean> s/filed/field/ </dean>


Draft, Section 5 says:
----------------------
5.   Protocol Semantics 
    
   The OSP Token is always encoded per base64 and only allowed in INVITE 
   requests and 200 OK responses to INVITEs. 
----------------------

<dean> Is there any implication for early media?  Oh no, I said Early Media!
Make the Pain Stop!</dean>


Draft Section 5.1 says:
-----------------------
5.1    User Agents 
    
   A UAC MAY include the header an INVITE requesting QoS using AAA. 
-----------------------
<dean> s/header/header field/ </dean>

Draft, Section 6 says:
----------------------
6.   Example Message 
    
   This SIP INVITE message is an example exchange between the two 
   domains as shown in Figure 1: 
    
   INVITE sips:+1-972-555-5555@domain2.com;user=phone SIP/2.0 
   Via: SIP/2.0/TLS proxy.domain1.com:5061;branch=z9hG4bK3a56d3.1 
   Via: SIP/2.0/TLS phone1.domain1.com:5061;branch=z9hG4bK3a5654 
    ;received=192.0.2.1 
   Max-Forward: 69 
   From: Alice <sips:alice@phone1.domain1.com>;tag=3 
   To: <sips:+1-972-555-5555@domain2.com;user=phone> 
   Call-ID: 123456@domain1.com 
   CSeq: 1 INVITE 
   Contact: <sips:alice@phone1.domain1.com> 
   Record-Route: <sips:proxy.domain1.com;lr> 
   P-OSP-Auth-Token: "YT64VqpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756t 
   HGTrfvbnjn8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfH 
   6ghyHhHUujpfyF47GhIGfHfYT64VQbnj" 
   Content-Type: application/sdp 
   Content-Length: 184 
    
   v=0 
   o=alice 9735285123 9721273312 IN IP4 phone1.domain1.com 
   s=-   
   c=IN IP4 phone1.domain1.com    
   t=0 0 
   m=audio 9876 RTP/AVP 0  
   a=rtpmap: 0 PCMU/8000  
------------------------------

<dean? The domain usage should align with RFC26206, aka "example.com"
</dean>


The draft's IANA considerations section says:
---------------------------------------------
IANA Considerations 
    
   Registration of "P-OSP-Auth-Token" SIP header field 
    
   This document defines a new private SIP header field, "P-OSP-Auth-
   Token".  As recommended by the policy of the Transport Area [3], this 
   header should be registered by the IANA in the SIP header registry, 
   using the RFC number of this document as its reference. 
    
    Name of Header:          P-OSP-Auth-Token 
    
    Short form:              None 
    
    Registrant:              Alan Johnston

                             alan.johnston@wcom.com 
    
    Normative description:   This document 
---------------------------------------------

<dean> The reference given, [3], is a reference to Cryptographic Message
Syntax. I think this is not what you want to point to. You probably need a
reference to RFC3427, the SIP Change Process, which augments the RFC361 IANA
process to account for P-headers.  Editorially, it would be nice to see the
IANA Considerations section numbered and listed in the ToC.</dean>


The draft's security considerations section says:
-------------------------------------------------
Security Considerations 
    
   The security and handling of OSP tokens is covered in [4] which 
   includes encryption and the use of IPSec.  
    
   The P-OSP-Auth-Token header field may be protected using standard SIP 
   mechanisms such as TLS transport and/or S/MIME encryption as detailed 
   in [1]. 
--------------------------------------------------

<dean> This is, well, a little light. It would be nice to see some
discussion of exactly how the threat model in [4] is exposed by carrying OSP
in SIP, and have a little more discussion of how the referenced security
mechanisms protect from those exposures. </dean>

--
Dean

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



From mailnull@www1.ietf.org  Thu Apr 24 02:33:57 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06427
	for <sip-archive@odin.ietf.org>; Thu, 24 Apr 2003 02:33:57 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3O6aPt13838
	for sip-archive@odin.ietf.org; Thu, 24 Apr 2003 02:36:25 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3O6Zf813781;
	Thu, 24 Apr 2003 02:35:41 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3O6W0813557
	for <sip@optimus.ietf.org>; Thu, 24 Apr 2003 02:32: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 CAA06324
	for <sip@ietf.org>; Thu, 24 Apr 2003 02:29:01 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198aGN-0003PQ-00
	for sip@ietf.org; Thu, 24 Apr 2003 02:31:19 -0400
Received: from [61.144.161.2] (helo=mta0)
	by ietf-mx with esmtp (Exim 4.12)
	id 198aGN-0003PL-00
	for sip@ietf.org; Thu, 24 Apr 2003 02:31:19 -0400
Received: from w07087a (mta0 [172.17.1.62])
 by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
 2002)) with ESMTPA id <0HDU00G0L4P3MK@mta0.huawei.com> for sip@ietf.org; Thu,
 24 Apr 2003 14:29:29 +0800 (CST)
Date: Thu, 24 Apr 2003 14:33:27 +0800
From: wenkai <wkai@huawei.com>
To: sip@ietf.org
Message-id: <00b001c30a2b$6a1db870$af064d0a@w07087a>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
Content-type: multipart/alternative;
 boundary="Boundary_(ID_TT1w+wWpRjsKCS8hNyfECg)"
X-Priority: 3
X-MSMail-priority: Normal
Subject: [Sip] can i change my own dialog info  in mid-dialog?
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-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_TT1w+wWpRjsKCS8hNyfECg)
Content-type: text/plain; charset=gb2312
Content-Transfer-Encoding: 7BIT

Hi,
According to RFC3261, the dialog ID just include Call-id, remote tag and local tag. So, the local uri, remote uri and remote target uri are not used for dialog matching. 
After one dialog established, can a UA change his own local uri, remote uri and remote target uri?  Or, can the UA send a re-INVITE with different From-URI, To-URI and Request-URI as original INVITE's ?
I think it is permitted in RFC3261. But i am not sure.

Thanks
Kevin


--Boundary_(ID_TT1w+wWpRjsKCS8hNyfECg)
Content-type: text/html; charset=gb2312
Content-Transfer-Encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=gb2312" http-equiv=Content-Type>
<META content="MSHTML 5.00.3315.2870" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial>Hi,</FONT></DIV>
<DIV><FONT face=Arial>According to RFC3261, the dialog ID just include Call-id, 
remote tag and local tag. So, the local uri, remote uri and remote target uri 
are not used for dialog matching. </FONT></DIV>
<DIV><FONT face=Arial>After one dialog established, can a UA change&nbsp;his own 
local uri, remote uri and remote target uri?&nbsp; Or, can the UA send a 
re-INVITE with different From-URI, To-URI and Request-URI as original INVITE's 
?</FONT></DIV>
<DIV><FONT face=Arial>I think&nbsp;it is permitted in RFC3261. But i am not 
sure.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial>Thanks</FONT></DIV>
<DIV><FONT face=Arial>Kevin</FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

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



From mailnull@www1.ietf.org  Thu Apr 24 02:53:28 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06693
	for <sip-archive@odin.ietf.org>; Thu, 24 Apr 2003 02:53:27 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3O6tvH15538
	for sip-archive@odin.ietf.org; Thu, 24 Apr 2003 02:55:57 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3O6tb815527;
	Thu, 24 Apr 2003 02:55:37 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3O6sx815480
	for <sip@optimus.ietf.org>; Thu, 24 Apr 2003 02:54: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 CAA06668
	for <sip@ietf.org>; Thu, 24 Apr 2003 02:52:00 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198acd-0003V0-00
	for sip@ietf.org; Thu, 24 Apr 2003 02:54:19 -0400
Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se)
	by ietf-mx with esmtp (Exim 4.12)
	id 198acc-0003Ux-00
	for sip@ietf.org; Thu, 24 Apr 2003 02:54:18 -0400
Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121])
	by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3O6sZRs000673;
	Thu, 24 Apr 2003 08:54:35 +0200 (MEST)
Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55)
	id JQAF53PM; Thu, 24 Apr 2003 08:54:37 +0200
Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.31.77])
	by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h3O6sbR6009386;
	Thu, 24 Apr 2003 09:54:37 +0300 (EET DST)
Message-ID: <3EA78A6F.1C67E563@lmf.ericsson.se>
Date: Thu, 24 Apr 2003 09:55:43 +0300
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: wenkai <wkai@huawei.com>
CC: sip@ietf.org
Subject: Re: [Sip] can i change my own dialog info  in mid-dialog?
References: <00b001c30a2b$6a1db870$af064d0a@w07087a>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit


Hi,

You must not change the To-URI and From-URI. It is true that in RFC3261
they aren't used for the dialog id, and not for the transaction id, but
in RFC2543 they WERE used for this kind of purpose, so at least for
backward compability (I guess there may be other reasons too...) you
shall not change them.

Regards,

Christer Holmberg
Ericsson Finland


wenkai wrote:

> Hi,According to RFC3261, the dialog ID just include Call-id, remote
> tag and local tag. So, the local uri, remote uri and remote target uri
> are not used for dialog matching.After one dialog established, can a
> UA change his own local uri, remote uri and remote target uri?  Or,
> can the UA send a re-INVITE with different From-URI, To-URI and
> Request-URI as original INVITE's ?I think it is permitted in RFC3261.
> But i am not sure. ThanksKevin

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



From mailnull@www1.ietf.org  Thu Apr 24 03:36:50 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07241
	for <sip-archive@odin.ietf.org>; Thu, 24 Apr 2003 03:36:50 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3O7dK518920
	for sip-archive@odin.ietf.org; Thu, 24 Apr 2003 03:39:20 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3O7cw818908;
	Thu, 24 Apr 2003 03:38:58 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3O7bO818425
	for <sip@optimus.ietf.org>; Thu, 24 Apr 2003 03:37: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 DAA07210
	for <sip@ietf.org>; Thu, 24 Apr 2003 03:34:23 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198bHe-0003de-00
	for sip@ietf.org; Thu, 24 Apr 2003 03:36:42 -0400
Received: from [61.144.161.2] (helo=mta1)
	by ietf-mx with esmtp (Exim 4.12)
	id 198bHZ-0003db-00
	for sip@ietf.org; Thu, 24 Apr 2003 03:36:38 -0400
Received: from w07087a (mta1 [172.17.1.60])
 by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26
 2002)) with ESMTPA id <0HDU000EU7LCJ8@mta1.huawei.com> for sip@ietf.org; Thu,
 24 Apr 2003 15:32:01 +0800 (CST)
Date: Thu, 24 Apr 2003 15:38:56 +0800
From: wenkai <wkai@huawei.com>
Subject: Re: [Sip] can i change my own dialog info  in mid-dialog?
To: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
Cc: sip@ietf.org
Message-id: <000c01c30a34$90589f10$af064d0a@w07087a>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <00b001c30a2b$6a1db870$af064d0a@w07087a>
 <3EA78A6F.1C67E563@lmf.ericsson.se>
Content-Transfer-Encoding: 7BIT
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7BIT

Thanks, 

But what is the "other reasons" besides backward compatibility? 


----- Original Message ----- 
From: "Christer Holmberg" <christer.holmberg@lmf.ericsson.se>
To: "wenkai" <wkai@huawei.com>
Cc: <sip@ietf.org>
Sent: Thursday, April 24, 2003 2:55 PM
Subject: Re: [Sip] can i change my own dialog info in mid-dialog?


> 
> Hi,
> 
> You must not change the To-URI and From-URI. It is true that in RFC3261
> they aren't used for the dialog id, and not for the transaction id, but
> in RFC2543 they WERE used for this kind of purpose, so at least for
> backward compability (I guess there may be other reasons too...) you
> shall not change them.
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> 
> wenkai wrote:
> 
> > Hi,According to RFC3261, the dialog ID just include Call-id, remote
> > tag and local tag. So, the local uri, remote uri and remote target uri
> > are not used for dialog matching.After one dialog established, can a
> > UA change his own local uri, remote uri and remote target uri?  Or,
> > can the UA send a re-INVITE with different From-URI, To-URI and
> > Request-URI as original INVITE's ?I think it is permitted in RFC3261.
> > But i am not sure. ThanksKevin
> 

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



From mailnull@www1.ietf.org  Fri Apr 25 04:41:04 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00667
	for <sip-archive@odin.ietf.org>; Fri, 25 Apr 2003 04:41:04 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3P8i5C06018
	for sip-archive@odin.ietf.org; Fri, 25 Apr 2003 04:44:05 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P8gb805935;
	Fri, 25 Apr 2003 04:42:37 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P8dk805789
	for <sip@optimus.ietf.org>; Fri, 25 Apr 2003 04:39: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 EAA00581
	for <sip@ietf.org>; Fri, 25 Apr 2003 04:36:15 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198yj3-000662-00
	for sip@ietf.org; Fri, 25 Apr 2003 04:38:33 -0400
Received: from [202.54.124.130] (helo=rediffmail.com)
	by ietf-mx with smtp (Exim 4.12)
	id 198yj2-00065j-00
	for sip@ietf.org; Fri, 25 Apr 2003 04:38:33 -0400
Received: (qmail 29889 invoked by uid 510); 25 Apr 2003 08:43:49 -0000
Date: 25 Apr 2003 08:43:49 -0000
Message-ID: <20030425084349.29888.qmail@webmail31.rediffmail.com>
Received: from unknown (203.129.242.66) by rediffmail.com via HTTP; 25 apr 2003 08:43:49 -0000
MIME-Version: 1.0
From: "nageshwar reddy m n" <mnnr@rediffmail.com>
Reply-To: "nageshwar reddy m n" <mnnr@rediffmail.com>
To: sip@ietf.org
Content-type: text/plain;
	format=flowed
Content-Disposition: inline
Subject: [Sip] implementation
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

Is there a separate mailing list for SIP implementors.
please do let me know.
thanks in advance.

regards
reddy


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



From mailnull@www1.ietf.org  Fri Apr 25 17:50:46 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24460
	for <sip-archive@odin.ietf.org>; Fri, 25 Apr 2003 17:50:46 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3PLs3a32541
	for sip-archive@odin.ietf.org; Fri, 25 Apr 2003 17:54:03 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PLrb832507;
	Fri, 25 Apr 2003 17:53:37 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PLp5832385
	for <sip@optimus.ietf.org>; Fri, 25 Apr 2003 17:51: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 RAA24420
	for <sip@ietf.org>; Fri, 25 Apr 2003 17:47:17 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 199B4Z-0003sT-00
	for sip@ietf.org; Fri, 25 Apr 2003 17:49:35 -0400
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 199B4Y-0003sO-00
	for sip@ietf.org; Fri, 25 Apr 2003 17:49:34 -0400
Received: from dynamicsoft.com ([63.113.46.26])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h3PLnXdh002353
	for <sip@ietf.org>; Fri, 25 Apr 2003 17:49:33 -0400 (EDT)
Message-ID: <3EA9AD68.3020406@dynamicsoft.com>
Date: Fri, 25 Apr 2003 17:49:28 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
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@ietf.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Splitting caller preferences in half
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-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,

Despite the great feedback we've gotten from the group on the caller 
preferences draft lately, there appear to still be some pretty 
fundamental issues that have come up in discussions with some of our 
area directors. In particular, our q-value arithmetic operations have 
serious issues. Since q-values are meant to be ordinal in nature, not 
cardinal, any kind of arithmetic you might perform on them won't work. 
You also can't compare q-values received from disparate sources, which 
is another thing the draft is sort-of doing (it actually punts this to 
domain policy, but there is no policy that will work properly).

The authors of the draft have some ideas on how to fix this. Our current 
thinking is to eliminate the caller q-values (i.e., no q-values in the 
Accept-Contact header field), and use the score as a way to order the 
contacts ONLY for those contacts whose q-value (specified by the callee) 
is identical. Its not clear that this will work well enough for us, or 
whether there are more q-value issues lurking there. As such, it looks 
like there will be significant additional delays as we work these issues 
and discuss them with ADs.

The problem is that there are now several drafts with normative 
dependencies on caller preferences, including the SIMPLE specification. 
As it turns out, nearly all of these only need the registration piece of 
caller preferences, not the call routing and proxy matching pieces. In 
order to avoid dragging all of those specifications down by caller 
preferences, our proposal is to split caller preferences in half. One 
draft will focus only on capabilities. It will define the contact 
parameters, show how to use them in REGISTER (and also in the INVITE/200 
OK contact and OPTIONS), and describe the rfc2533 mapping. This draft is 
uncontroversial and can proceed immmediately. The other draft will allow 
for caller preferences. It will define the Accept-Contact and 
Reject-Contact header fields, and will describe the proxy matching 
algorithm. We will need to continue to think about how to make that work 
in a reasonable fashion.

The chairs and spec co-authors believe this is the best course of 
action. So, please speak up if you have problems with this tactic, since 
we will move in this direction unless we hear otherwise.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             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 mailnull@www1.ietf.org  Fri Apr 25 22:46:03 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00484
	for <sip-archive@odin.ietf.org>; Fri, 25 Apr 2003 22:46:03 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3Q2nQ818013
	for sip-archive@odin.ietf.org; Fri, 25 Apr 2003 22:49:26 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3Q2mr817989;
	Fri, 25 Apr 2003 22:48:53 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3Q2k5817920
	for <sip@optimus.ietf.org>; Fri, 25 Apr 2003 22:46: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 WAA00368
	for <sip@ietf.org>; Fri, 25 Apr 2003 22:42:12 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 199Ffx-00057V-00
	for sip@ietf.org; Fri, 25 Apr 2003 22:44:29 -0400
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 199Ffw-00057S-00
	for sip@ietf.org; Fri, 25 Apr 2003 22:44:28 -0400
Received: from dynamicsoft.com ([63.113.46.26])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h3Q2iKdh002385;
	Fri, 25 Apr 2003 22:44:23 -0400 (EDT)
Message-ID: <3EA9F280.8010800@dynamicsoft.com>
Date: Fri, 25 Apr 2003 22:44:16 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
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: wenkai <wkai@huawei.com>
CC: Christer Holmberg <christer.holmberg@lmf.ericsson.se>, sip@ietf.org
Subject: Re: [Sip] can i change my own dialog info  in mid-dialog?
References: <00b001c30a2b$6a1db870$af064d0a@w07087a> <3EA78A6F.1C67E563@lmf.ericsson.se> <000c01c30a34$90589f10$af064d0a@w07087a>
In-Reply-To: <000c01c30a34$90589f10$af064d0a@w07087a>
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

That is the only reason.

-Jonathan R.

wenkai wrote:
> Thanks, 
> 
> But what is the "other reasons" besides backward compatibility? 
> 
> 
> ----- Original Message ----- 
> From: "Christer Holmberg" <christer.holmberg@lmf.ericsson.se>
> To: "wenkai" <wkai@huawei.com>
> Cc: <sip@ietf.org>
> Sent: Thursday, April 24, 2003 2:55 PM
> Subject: Re: [Sip] can i change my own dialog info in mid-dialog?
> 
> 
> 
>>Hi,
>>
>>You must not change the To-URI and From-URI. It is true that in RFC3261
>>they aren't used for the dialog id, and not for the transaction id, but
>>in RFC2543 they WERE used for this kind of purpose, so at least for
>>backward compability (I guess there may be other reasons too...) you
>>shall not change them.
>>
>>Regards,
>>
>>Christer Holmberg
>>Ericsson Finland
>>
>>
>>wenkai wrote:
>>
>>
>>>Hi,According to RFC3261, the dialog ID just include Call-id, remote
>>>tag and local tag. So, the local uri, remote uri and remote target uri
>>>are not used for dialog matching.After one dialog established, can a
>>>UA change his own local uri, remote uri and remote target uri?  Or,
>>>can the UA send a re-INVITE with different From-URI, To-URI and
>>>Request-URI as original INVITE's ?I think it is permitted in RFC3261.
>>>But i am not sure. ThanksKevin
>>
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP 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 Scientist                             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 mailnull@www1.ietf.org  Sat Apr 26 10:11:43 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20941
	for <sip-archive@odin.ietf.org>; Sat, 26 Apr 2003 10:11:43 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3QEFJk03033
	for sip-archive@odin.ietf.org; Sat, 26 Apr 2003 10:15:19 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3QEEQ802985;
	Sat, 26 Apr 2003 10:14:26 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3QEAq802875
	for <sip@optimus.ietf.org>; Sat, 26 Apr 2003 10:10: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 KAA20862
	for <sip@ietf.org>; Sat, 26 Apr 2003 10:06:46 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 199QMP-0007dl-00
	for sip@ietf.org; Sat, 26 Apr 2003 10:09:01 -0400
Received: from em.njupt.edu.cn ([202.119.230.11])
	by ietf-mx with smtp (Exim 4.12)
	id 199QMO-0007di-00
	for sip@ietf.org; Sat, 26 Apr 2003 10:09:00 -0400
Received: (qmail 16614 invoked by uid 1008); 26 Apr 2003 14:56:00 -0000
Message-ID: <20030426145600.16613.qmail@em.njupt.edu.cn>
From: Y01317@njupt.edu.cn
To: sip@ietf.org
Date: Sat, 26 Apr 2003 14:56:00 GMT
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset="gb2312"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Call Hold : which SDP is right?
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi, all 

  I have a question about SIP service : HOLD

  In draft sipping-service-examples-04, the example "Call Hold" in P9, I 
think the "hold" infomation is expressed in SDP (Message F10):
  <quote>
  v=0
  o=bob 2890844527 2890844528 IN IP4 client.biloxi.example.com
  s=Session SDP
  c=IN IP4 client.biloxi.example.com
  t=3034423619 0
  m=audio 3456 RTP/AVP 0
  a=rtpmap:0 PCMU/8000
  a=sendonly
  ~~~~~~~~~~ <----- here I think express the infomation : " HOLD "
  </quote>
 

  In our lab, there is a Cisco SIP phone - 7940G.
  I catch the messages from Cisco's SIP phone when press "Hold" key , it 
fullfils "Call Hold" like this way:
  <quote_cisco>
  v=0
  o=Cisco-SIPUA 7825 13012 IN IP4 10.10.3.117
  s=SIP Call
  c=IN IP4 0.0.0.0
           ~~~~~~~ <---- here, Cisco using "0.0.0.0" to express "HOLD"
  t=0 0
  m=audio 28036 RTP/AVP 18 0 8 96
  a=rtpmap:18 G729/8000
  a=rtpmap:0 PCMU/8000
  a=rtpmap:8 PCMA/8000
  a=rtpmap:96 telephone-event/8000
  a=fmtp:96 0-15
 </quote_cisco> 

 First, I do not find any statements about "0.0.0.0" can express "HOLD" in 
RFC2327(SDP). Who can tell me where can I find the relative drafts talking 
about "0.0.0.0" ?
 Second, I really do not know which is the criteria ? Cisco's SIP phone is 
right or I do according to sipping-service-example-04 ? 

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



From mailnull@www1.ietf.org  Sat Apr 26 10:48:24 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21596
	for <sip-archive@odin.ietf.org>; Sat, 26 Apr 2003 10:48:24 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3QEq1E05122
	for sip-archive@odin.ietf.org; Sat, 26 Apr 2003 10:52:01 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3QEpV805104;
	Sat, 26 Apr 2003 10:51:31 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3QEou805084
	for <sip@optimus.ietf.org>; Sat, 26 Apr 2003 10:50: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 KAA21584
	for <sip@ietf.org>; Sat, 26 Apr 2003 10:46:48 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 199QzA-0007mr-00
	for sip@ietf.org; Sat, 26 Apr 2003 10:49:04 -0400
Received: from em.njupt.edu.cn ([202.119.230.11])
	by ietf-mx with smtp (Exim 4.12)
	id 199Qz9-0007mo-00
	for sip@ietf.org; Sat, 26 Apr 2003 10:49:03 -0400
Received: (qmail 17520 invoked by uid 1008); 26 Apr 2003 15:36:04 -0000
Message-ID: <20030426153604.17519.qmail@em.njupt.edu.cn>
References: <65256D14.004FC84E.00@sampark.hss.hns.com>
In-Reply-To: <65256D14.004FC84E.00@sampark.hss.hns.com> 
From: Y01317@njupt.edu.cn
To: akchaudhury@hss.hns.com, sip@ietf.org
Cc: Y01317@njupt.edu.cn
Date: Sat, 26 Apr 2003 15:36:04 GMT
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset="gb2312"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Re: Call Hold : which SDP is right?
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-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 akchaudhury, 

 Thank you very much! I now understand :) 


akchaudhury@hss.hns.com writes: 

>  
> 
> 
> Hello Y01317 
> 
> RFC 2543 mentions about setting the connection address to 0.0.0.0 to put a
> user on hold. 
> 
> But this method of putting a user on hold is no longer recommended as
> mentioned in RFC 3264 -
> "An Offer/Answer Model with the Session Description Protocol (SDP)". Please
> refer to section
> 8.4 of RFC 3264 which says that - 
> 
> "RFC 2543 [10] specified that placing a user on hold was accomplished by
> setting the connection
> address to 0.0.0.0.  Its usage for putting a call on hold is no longer
> recommended, since it doesn't
> allow for RTCP to be used with held streams, doesn't work with IPv6, and
> breaks with connection
> oriented media.  However, it can be useful in an initial offer when the
> offerer knows it wants to use
> a particular set of media streams and formats, but doesn't know the
> addresses and ports at the
> time of the offer.  Of course, when used, the port number MUST NOT be zero,
> which would specify
> that the stream has been disabled.  An agent MUST be capable of receiving
> SDP with a connection
> address of 0.0.0.0, in which case it means that neither RTP nor RTCP should
> be sent to the peer." 
> 
> Therefore, although a user agent should not use this method to put a user
> on hold, it should be capable
> of receiving SDP with address of c-line set to 0.0.0.0. 
> 
> I hope both of your questions have got answered here. 
> 
> regards,
> -anil- 
> 
>  
> 
>  
> 
> 
> Y01317@njupt.edu.cn on 04/26/2003 03:56:00 PM 
> 
> To:   sip@ietf.org
> cc:    (bcc: Anil K Chaudhary/HSSBLR) 
> 
> Subject:  [Sip] Call Hold : which SDP is right? 
> 
>  
> 
> 
> Hi, all 
> 
>   I have a question about SIP service : HOLD 
> 
>   In draft sipping-service-examples-04, the example "Call Hold" in P9, I
> think the "hold" infomation is expressed in SDP (Message F10):
>   <quote>
>   v=0
>   o=bob 2890844527 2890844528 IN IP4 client.biloxi.example.com
>   s=Session SDP
>   c=IN IP4 client.biloxi.example.com
>   t=3034423619 0
>   m=audio 3456 RTP/AVP 0
>   a=rtpmap:0 PCMU/8000
>   a=sendonly
>   ~~~~~~~~~~ <----- here I think express the infomation : " HOLD "
>   </quote> 
> 
> 
>   In our lab, there is a Cisco SIP phone - 7940G.
>   I catch the messages from Cisco's SIP phone when press "Hold" key , it
> fullfils "Call Hold" like this way:
>   <quote_cisco>
>   v=0
>   o=Cisco-SIPUA 7825 13012 IN IP4 10.10.3.117
>   s=SIP Call
>   c=IN IP4 0.0.0.0
>            ~~~~~~~ <---- here, Cisco using "0.0.0.0" to express "HOLD"
>   t=0 0
>   m=audio 28036 RTP/AVP 18 0 8 96
>   a=rtpmap:18 G729/8000
>   a=rtpmap:0 PCMU/8000
>   a=rtpmap:8 PCMA/8000
>   a=rtpmap:96 telephone-event/8000
>   a=fmtp:96 0-15
>  </quote_cisco> 
> 
>  First, I do not find any statements about "0.0.0.0" can express "HOLD" in
> RFC2327(SDP). Who can tell me where can I find the relative drafts talking
> about "0.0.0.0" ?
>  Second, I really do not know which is the criteria ? Cisco's SIP phone is
> right or I do according to sipping-service-example-04 ? 
> 
>  Thanks a lot to give some advice ;)
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip 
> 
>  
> 
> 
 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Sun Apr 27 06:48:09 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22077
	for <sip-archive@odin.ietf.org>; Sun, 27 Apr 2003 06:48:08 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3RAqBv27273
	for sip-archive@odin.ietf.org; Sun, 27 Apr 2003 06:52:11 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3RAoI827219;
	Sun, 27 Apr 2003 06:50:18 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3RAl6827162
	for <sip@optimus.ietf.org>; Sun, 27 Apr 2003 06:47: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 GAA22031
	for <sip@ietf.org>; Sun, 27 Apr 2003 06:42:33 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 199jeK-0004P3-00
	for sip@ietf.org; Sun, 27 Apr 2003 06:44:48 -0400
Received: from ierw.net.avaya.com ([198.152.13.101])
	by ietf-mx with esmtp (Exim 4.12)
	id 199jeK-0004P0-00
	for sip@ietf.org; Sun, 27 Apr 2003 06:44:48 -0400
Received: from ierw.net.avaya.com (localhost [127.0.0.1])
	by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id GAA09964
	for <sip@ietf.org>; Sun, 27 Apr 2003 06:42:37 -0400 (EDT)
Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51])
	by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id GAA09946
	for <sip@ietf.org>; Sun, 27 Apr 2003 06:42:36 -0400 (EDT)
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_01C30CAA.156EF144"
Date: Sun, 27 Apr 2003 13:45:14 +0300
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2F038A9914@is0004avexu1.global.avaya.com>
Thread-Topic: Comments to draft-ietf-sip-mib-05.txt
Thread-Index: AcMMqhWKF5NV/0B5SEyfgPmtv+G3og==
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: "Kevin Lingle" <klingle@cisco.com>,
        "Jean-Francois Mule" <jf.mule@cablelabs.com>, <jmaeng@ipdialog.com>,
        <drwalker@ss8.com>
Cc: <bwijnewn@lucent.com>, <mankin@psg.com>, <sip@ietf.org>
Subject: [Sip] Comments to draft-ietf-sip-mib-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>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C30CAA.156EF144
Content-Type: text/plain;
	charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

Here are my comments to the latest SIP MIB I-D. I have divided them into =
three categories - design and architecture, MIB and SMI, and editorials =
and formatting. Concerning the latest category, I did not go yet into a =
detailed search for all editorial nits, as the current version has more =
important issue to solve and will need more iterations anyway.

Regards,

Dan

-------------------------------------------------------------

A - Design and Architecture Issues

A1 - Although the declared goal of this version was to align the MIB =
with the evolution of SIP from RFC 2543 to RFC 3261, this evolution was =
not completed. A large part of the MIB is still referring to RFC 2543. =
Moreover, in the absence of an explicit note in the text, the =
implementer of the current version of this MIB risks to work with a =
hybrid that may cause problems.
A2 - One of the issues future implementers of this MIB will deal with is =
the issue of extensibility. How new methods that may be added to SIP in =
the future will be accommodated. The authors chose the path to support =
RFC 3261 and the INFO method defined in RFC 2976, as a basic common =
package, and defined an extensibility mechanism for the rest. This can =
work - with some problems defined later - but there is a need to explain =
this and maybe provide some examples in the introductory sessions.
A3 - Section 4, page 4, last paragraph. As far as I understand the =
position this document takes is that' if a device has more than one SIP =
entity, or multiple instances of the same entity, it MUST implement =
multiple SIP modules' - so MUST and not SHOULD.
A4 - Section 4.2, page 4 - need to define the way sipServiceOperStatus =
maps into applOperStatus
A5 - sipFtrSupportedtable - I am questioning if these table design is =
correct. Are the features similar (identically supported) for a multiple =
entity (like a proxy and a registrar) which would generate just one row =
in this table
A6 - sipExtMethodSupportedTable - It is not clear why this table is not =
the common key for all ExtMethod tables in the MIB. =
sipExtmethodSupportedIndex could be index for =
sipCommonCfgTimerExtMethodTable, sipCommonCfgRetryExtnMethodTable, =
sipStatsExtMethodTable, sipCommonStatsRetryExtMethodTable. Beyond =
providing a common index for extended methods to be used by =
applications, this would avoid defining again name objects in each of =
these tables
A7 - it is not clear why sipCommonStatusCodeNotifyTable is defined as a =
separate table, and not part of sipCommonStatusCideTable? Was the =
intention to say that if the table (which is optional) is not =
implemented, there are no notifications at all? If this is the case, =
this should be explicitly described
A8 - if the result of setting sipCommonStatusCodeNotifEmitMode to =
'normal' is one notification for each SIP response message, is not it =
more safe to define the DEFVAL for this object something else than =
'normal'?
A9 - How does an application receiving a =
sipStatusCodeThreshExceededNotif know that the notification applies for =
codeIns or for codeOuts? Maybe it's better to define two distinct =
notifications
A10 - Implementing this MIB has strong security implications. This MIB =
has a large number of read-write objects, including the servers, =
presents security mode objects, and transaction tables with client =
information. All this needs to be detailed in the Security =
Considerations section, including the explicit lists of all read-write =
and security sensitive objects (even if not read-write), and the =
specific security risks that derive from having this objects exposed =
through a MIB interface



B - MIB and SMI Issues

B1 - There is no reference in the document to the persistence properties =
of the defined objects. It is RECOMMENDED that the DESCRIPTION clauses =
specify what happens to the value after an agent reboot. Among the =
possibilities are that the value remains unchanged, that it reverts to a =
well-defined default value, or that the result is =
implementation-dependent
B2 - sipServiceOperStatus - it would be better to define unknown as the =
first value in the enumeration
B3 - same - a REFERENCE clause for the operStatus values would help
B4 - sipExtMethodName - need to define rules for the method names - e.g. =
string 'REFER' for the REFER method, etc.
B5 - sipCfgRetryExtMethodStatus - what does the last phrase in the =
DESCRIPTION clause mean ('If that method already exists for a particular =
applIndex, the row create operation will fail'). How are values in a row =
changed?=20
B6 - The behavior of the counters in the tables sipStatsExtMethodTable =
and sipCommonStatusCodeTable are inconsistent. For the later, if the =
RowStatus object is set to 'notInService' counters MAY be reset, while =
for the former they interrupt counts and re-start from the same place. =
Ambiguous behavior is strongly discouraged, and in any case a counter =
discontinuity object must be added to mark the timestamp of the last =
reset of the counters in the row
B7 - from the semantics of sipCommonStatusCodeNotifEmitMode, one derives =
that sipCommonStatusCodeNotifSend needs to be true at the time this =
object is set. Does this mean that a typical sequence of row creation in =
this table involves needs to be a two step process?
B8 - There is no reason to define sipTransActivityInfo as a =
concatenation of two objects, each with a different semantics. I suggest =
braking this object into two objects with direction and request/response =
semantics
B9 - If only a subset of the values of a TC is supported, like in the =
case of sipUACfgSipServerAddrStatus, this needs to be reflected in the =
compliance clauses. See Section 4.8 of =
http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-=
01.txt for an example
B10 - why the requirement to provide a varbind for sipUACfgSipServerAddr =
object in the same set operation that sets a sipUACfgSipServerAddrStatus =
to 'createAndGo'? Cannot the object have been set previously?=20
B11 - sipServerHostAddress - as a subset of InetAddress TC is used, this =
needs to be reflected in the compliance clauses. What is the reason to =
limit the size to 254, while the InetAddress TC in RFC 3291 allows for a =
size of 255?
B12 - why is sipContactPreference coded as a string, and not as a sized =
integer? I actually do not see preference in section 6.13 of RFC 2543 as =
indicated by the REFERENCE clause, but from the DESCRIPTION it looks =
like it could be coded as number 1 to 99.

C - Editorial and formatting issues

C1 - Proxy Servers, Redirect Servers, etc. are capitalized in an =
inconsistent manner, starting with the very visible Abstract section
C2 - The key words rule - though mentioned in the Introduction section =
is not followed in much of the document. I strongly suggest that the =
authors make a search through the document for all key words, and use =
capitals wherever it applies, including the DESCRIPTION clauses of the =
MIB objects
C3 - RFC 2119 should be in the normative references category
C4 - Section 4 - Structure of the MIB should list the MIB groups, and =
not the conformance groups. I strongly recommend to add a short =
explanation for each one of the MIB groups functionality
C5 - SIP is inconsistently spelled in the document. While in the =
majority of places it is "SIP", in a few you may find "sip" (e.g. =
Section 4, page 4, last paragraph, where both variants may be found in =
the same phrase)
C6 - Section 4.2 should rather be named 'Relationship to the Network =
Services MIB'.
C7 - Section 4.2, page 4 - applVersion - why the if here? Can something =
else than SIP version be used? I think not
C8 - Replace in the CONTACT-INFO clauses 'SIP MIB email' by SIP WG =
e-mail
C9 - Insert notes to the RFC editor after the DESCRIPTION clauses of the =
MIB to remind that RFC number and OID assignment need to be provided, =
and the notes removed prior to publication
C10 - page 11 - It would help if a short commented explanation would be =
added for each MIB group like sipCommionCfgBase, sipCommonCfgTimer, etc=20
C11 - DESCRIPTION clause of sipOrganization - typo it is probably =
'string' and not 'sting'
C12 - DESCRIPTION clause of sipPortStatus - I am not sure what is the =
intent of the word 'remotely'. I suggest to take it out from here and =
other similar RowStatus objects definition
C13 - same - It should be 'The rows associated...' (plural) as there =
might be one row for each applIndex value
C14 - RFC 2396 and RFC 2368 mentioned in the DESCRIPTION clause of =
sipUriSupportedTable need to be added to the reference clauses
C15 - sipCfgTimerC - delete the last phrase in the DESCRIPTION clause - =
this is redundant as it can be deduced from the syntax
C16 - add more detailed DESCRIPTION clauses for sipCfgTimerT2, =
sipCfgTimerT4 - consistent with the rest of the DESCRIPTION clauses in =
the same table
C17 - DESCRIPTION clause for sipMethodStatsTable - delete the word =
'per'. This table does not include per method statistics, but method =
statistics per entity
C18 - provide more details in the DESCRIPTION clauses of =
sipStatsRedirCalssIns and sipStatsRedirClassOuts, consistent with other =
DESCRIPTION clauses in the same table
C19 - append at the end of the DESCRIPTION clause of =
sipCurrentTransactions '... corresponding to the entity identified by =
applIndex.'
C20 - delete the last phrase in the DESCRIPTION clause of =
sipStatsRetryExtMethodName
C21 - DESCRIPTION of sipNotifApplIndex - explain that this object (which =
is a duplication of applIndex) is created in order to allow an =
accessible-to-notify object included in the notifications varbind
C22 - change names of sipUACfgSipServerAddrIndex to =
sipUACfgSipServerIndex, and sipUACfgSipServerAddrStatus to =
sipUACfgSipServerStatus
C23 - Section 5.4 seems to have formatting problems related tot he =
number of allowed characters in a row
C24 - DESCRIPTION clause of sipProxyAuthMethod - more than one method =
may be used, change the clause to reflect this
C25 - sipRegMaxContactExpiryDate - calling this object ...Date is =
mis-leading. I suggest to rename it to ...Duration or something else.
C26 - The Normative References section is inconsistent, and does not =
comply with the format recommended in =
http://www.ops.ietf.org/mib-boilerplate.html
C27 - RFC 3291 (INET-MIB) needs to be added to the Normative References =
list













=20

------_=_NextPart_001_01C30CAA.156EF144
Content-Type: text/html;
	charset="windows-1255"
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=3Dwindows-1255">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.6388.0">
<TITLE>Comments to draft-ietf-sip-mib-05.txt</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P DIR=3DLTR><FONT SIZE=3D2 FACE=3D"Arial">Here are my comments to the =
latest SIP MIB I-D. I have divided them into three categories - design =
and architecture, MIB and SMI, and editorials and formatting. Concerning =
the latest category, I did not go yet into a detailed search for all =
editorial nits, as the current version has more important issue to solve =
and will need more iterations anyway.</FONT></P>

<P DIR=3DLTR><FONT SIZE=3D2 FACE=3D"Arial">Regards,</FONT></P>

<P DIR=3DLTR><FONT SIZE=3D2 FACE=3D"Arial">Dan</FONT></P>

<P DIR=3DLTR><FONT SIZE=3D2 =
FACE=3D"Arial">----------------------------------------------------------=
---</FONT></P>

<P DIR=3DLTR><FONT SIZE=3D2 FACE=3D"Arial">A - Design and Architecture =
Issues</FONT></P>

<P DIR=3DLTR><FONT SIZE=3D2 FACE=3D"Arial">A1 - Although the declared =
goal of this version was to align the MIB with the evolution of SIP from =
RFC 2543 to RFC 3261, this evolution was not completed. A large part of =
the MIB is still referring to RFC 2543. Moreover, in the absence of an =
explicit note in the text, the implementer of the current version of =
this MIB risks to work with a hybrid that may cause problems.</FONT></P>

<P DIR=3DLTR><FONT SIZE=3D2 FACE=3D"Arial">A2 - One of the issues future =
implementers of this MIB will deal with is the issue of extensibility. =
How new methods that may be added to SIP in the future will be =
accommodated. The authors chose the path to support RFC 3261 and the =
INFO method defined in RFC 2976, as a basic common package, and defined =
an extensibility mechanism for the rest. This can work - with some =
problems defined later - but there is a need to explain this and maybe =
provide some examples in the introductory sessions.</FONT></P>

<P DIR=3DLTR><FONT SIZE=3D2 FACE=3D"Arial">A3 - Section 4, page 4, last =
paragraph. As far as I understand the position this document takes is =
that' if a device has more than one SIP entity, or multiple instances of =
the same entity, it MUST implement multiple SIP modules' - so MUST and =
not SHOULD.</FONT></P>

<P DIR=3DLTR><FONT SIZE=3D2 FACE=3D"Arial">A4 - Section 4.2, page 4 - =
need to define the way sipServiceOperStatus maps into =
applOperStatus</FONT></P>

<P DIR=3DLTR><FONT SIZE=3D2 FACE=3D"Arial">A5 - sipFtrSupportedtable - I =
am questioning if these table design is correct. Are the features =
similar (identically supported) for a multiple entity (like a proxy and =
a registrar) which would generate just one row in this table</FONT></P>

<P DIR=3DLTR><FONT SIZE=3D2 FACE=3D"Arial">A6 - =
sipExtMethodSupportedTable - It is not clear why this table is not the =
common key for all ExtMethod tables in the MIB. =
sipExtmethodSupportedIndex could be index for =
sipCommonCfgTimerExtMethodTable, sipCommonCfgRetryExtnMethodTable, =
sipStatsExtMethodTable, sipCommonStatsRetryExtMethodTable. Beyond =
providing a common index for extended methods to be used by =
applications, this would avoid defining again name objects in each of =
these tables</FONT></P>

<P DIR=3DLTR><FONT SIZE=3D2 FACE=3D"Arial">A7 - it is not clear why =
sipCommonStatusCodeNotifyTable is defined as a separate table, and not =
part of sipCommonStatusCideTable? Was the intention to say that if the =
table (which is optional) is not implemented, there are no notifications =
at all? If this is the case, this should be explicitly =
described</FONT></P>

<P DIR=3DLTR><FONT SIZE=3D2 FACE=3D"Arial">A8 - if the result of setting =
sipCommonStatusCodeNotifEmitMode to 'normal' is one notification for =
each SIP response message, is not it more safe to define the DEFVAL for =
this object something else than 'normal'?</FONT></P>

<P DIR=3DLTR><FONT SIZE=3D2 FACE=3D"Arial">A9 - How does an application =
receiving a sipStatusCodeThreshExceededNotif know that the notification =
applies for codeIns or for codeOuts? Maybe it's better to define two =
distinct notifications</FONT></P>

<P DIR=3DLTR><FONT SIZE=3D2 FACE=3D"Arial">A10 - Implementing this MIB =
has strong security implications. This MIB has a large number of =
read-write objects, including the servers, presents security mode =
objects, and transaction tables with client information. All this needs =
to be detailed in the Security Considerations section, including the =
explicit lists of all read-write and security sensitive objects (even if =
not read-write), and the specific security risks that derive from having =
this objects exposed through a MIB interface</FONT></P>
<BR>
<BR>

<P DIR=3DLTR><FONT SIZE=3D2 FACE=3D"Arial">B - MIB and SMI =
Issues</FONT></P>

<P DIR=3DLTR><FONT SIZE=3D2 FACE=3D"Arial">B1 - There is no reference in =
the document to the persistence properties of the defined objects.<SPAN =
LANG=3D"en-us"></SPAN></FONT><SPAN LANG=3D"en-us"> <FONT SIZE=3D2 =
FACE=3D"Arial">It is RECOMMENDED that the DESCRIPTION clauses specify =
what happens to the value after an agent reboot. Among the possibilities =
are that the value remains unchanged, that it reverts to a well-defined =
default value, or that the result is =
implementation-dependent</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">B2 - =
sipServiceOperStatus - it would be better to define unknown as the first =
value in the enumeration</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">B3 - =
same - a REFERENCE clause for the operStatus values would =
help</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">B4 - =
sipExtMethodName - need to define rules for the method names - e.g. =
string 'REFER' for the REFER method, etc.</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">B5 - =
sipCfgRetryExtMethodStatus - what does the last phrase in the =
DESCRIPTION clause mean ('If that method already exists for a particular =
applIndex, the row create operation will fail'). How are values in a row =
changed? </FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">B6 - The =
behavior of the counters in the tables sipStatsExtMethodTable and =
sipCommonStatusCodeTable are inconsistent. For the later, if the =
RowStatus object is set to 'notInService' counters MAY be reset, while =
for the former they interrupt counts and re-start from the same place. =
Ambiguous behavior is strongly discouraged, and in any case a counter =
discontinuity object must be added to mark the timestamp of the last =
reset of the counters in the row</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">B7 - =
from the semantics of sipCommonStatusCodeNotifEmitMode, one derives that =
sipCommonStatusCodeNotifSend needs to be true at the time this object is =
set. Does this mean that a typical sequence of row creation in this =
table involves needs to be a two step process?</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">B8 - =
There is no reason to define sipTransActivityInfo as a concatenation of =
two objects, each with a different semantics. I suggest braking this =
object into two objects with direction and request/response =
semantics</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">B9 - If =
only a subset of the values of a TC is supported, like in the case of =
sipUACfgSipServerAddrStatus, this needs to be reflected in the =
compliance clauses. See Section 4.8 of <A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-gui=
delines-01.txt">http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-re=
view-guidelines-01.txt</A> for an example</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">B10 - =
why the requirement to provide a varbind for sipUACfgSipServerAddr =
object in the same set operation that sets a sipUACfgSipServerAddrStatus =
to 'createAndGo'? Cannot the object have been set previously? =
</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">B11 - =
sipServerHostAddress - as a subset of InetAddress TC is used, this needs =
to be reflected in the compliance clauses. What is the reason to limit =
the size to 254, while the InetAddress TC in RFC 3291 allows for a size =
of 255?</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">B12 - =
why is sipContactPreference coded as a string, and not as a sized =
integer? I actually do not see preference in section 6.13 of RFC 2543 as =
indicated by the REFERENCE clause, but from the DESCRIPTION it looks =
like it could be coded as number 1 to 99.</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"he"><FONT SIZE=3D2 FACE=3D"Arial">C - =
Editorial and formatting issues</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"he"><FONT SIZE=3D2 FACE=3D"Arial">C1 - Proxy =
Servers, Redirect Servers, etc. are capitalized in an inconsistent =
manner, starting with the very visible Abstract =
section</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"he"><FONT SIZE=3D2 FACE=3D"Arial">C2 - The =
key words rule - though mentioned in the Introduction section is not =
followed in much of the document. I strongly suggest that the authors =
make a search through the document for all key words, and use capitals =
wherever it applies, including the DESCRIPTION clauses of the MIB =
objects</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"he"><FONT SIZE=3D2 FACE=3D"Arial">C3 - RFC =
2119 should be in the normative references category</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"he"><FONT SIZE=3D2 FACE=3D"Arial">C4 - =
Section 4 - Structure of the MIB should list the MIB groups, and not the =
conformance groups. I strongly recommend to add a short explanation for =
each one of the MIB groups functionality</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"he"><FONT SIZE=3D2 FACE=3D"Arial">C5 - SIP is =
inconsistently spelled in the document. While in the majority of places =
it is &quot;SIP&quot;, in a few you may find &quot;sip&quot; (e.g. =
Section 4, page 4, last paragraph, where both variants may be found in =
the same phrase)</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"he"><FONT SIZE=3D2 FACE=3D"Arial">C6 - =
Section 4.2 should rather be named 'Relationship to the Network Services =
MIB'.</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"he"><FONT SIZE=3D2 FACE=3D"Arial">C7 - =
Section 4.2, page 4 - applVersion - why the if here? Can something else =
than SIP version be used? I think not</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"he"><FONT SIZE=3D2 FACE=3D"Arial">C8 - =
Replace in the CONTACT-INFO clauses 'SIP MIB email' by SIP WG =
e-mail</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"he"><FONT SIZE=3D2 FACE=3D"Arial">C9 - Insert =
notes to the RFC editor after the DESCRIPTION clauses of the MIB to =
remind that RFC number and OID assignment need to be provided, and the =
notes removed prior to publication</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"he"><FONT SIZE=3D2 FACE=3D"Arial">C10 - page =
11 - It would help if a short commented explanation would be added for =
each MIB group like sipCommionCfgBase, sipCommonCfgTimer, etc =
</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"he"><FONT SIZE=3D2 FACE=3D"Arial">C11 - =
DESCRIPTION clause of sipOrganization - typo it is probably 'string' and =
not 'sting'</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"he"><FONT SIZE=3D2 FACE=3D"Arial">C12 - =
DESCRIPTION clause of sipPortStatus - I am not sure what is the intent =
of the word 'remotely'. I suggest to take it out from here and other =
similar RowStatus objects definition</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"he"><FONT SIZE=3D2 FACE=3D"Arial">C13 - same =
- It should be 'The rows associated...' (plural) as there might be one =
row for each applIndex value</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"he"><FONT SIZE=3D2 FACE=3D"Arial">C14 - RFC =
2396 and RFC 2368 mentioned in the DESCRIPTION clause of =
sipUriSupportedTable need to be added to the reference =
clauses</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"he"><FONT SIZE=3D2 FACE=3D"Arial">C15 - =
sipCfgTimerC - delete the last phrase in the DESCRIPTION clause - this =
is redundant as it can be deduced from the syntax</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"he"><FONT SIZE=3D2 FACE=3D"Arial">C16 - add =
more detailed DESCRIPTION clauses for sipCfgTimerT2, sipCfgTimerT4 - =
consistent with the rest of the DESCRIPTION clauses in the same =
table</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"he"><FONT SIZE=3D2 FACE=3D"Arial">C17 - =
DESCRIPTION clause for sipMethodStatsTable - delete the word 'per'. This =
table does not include per method statistics, but method statistics per =
entity</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"he"><FONT SIZE=3D2 FACE=3D"Arial">C18 - =
provide more details in the DESCRIPTION clauses of sipStatsRedirCalssIns =
and sipStatsRedirClassOuts, consistent with other DESCRIPTION clauses in =
the same table</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"he"><FONT SIZE=3D2 FACE=3D"Arial">C19 - =
append at the end of the DESCRIPTION clause of sipCurrentTransactions =
'... corresponding to the entity identified by =
applIndex.'</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"he"><FONT SIZE=3D2 FACE=3D"Arial">C20 - =
delete the last phrase in the DESCRIPTION clause of =
sipStatsRetryExtMethodName</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"he"><FONT SIZE=3D2 FACE=3D"Arial">C21 - =
DESCRIPTION of sipNotifApplIndex - explain that this object (which is a =
duplication of applIndex) is created in order to allow an =
accessible-to-notify object included in the notifications =
varbind</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"he"><FONT SIZE=3D2 FACE=3D"Arial">C22 - =
change names of sipUACfgSipServerAddrIndex to sipUACfgSipServerIndex, =
and sipUACfgSipServerAddrStatus to =
sipUACfgSipServerStatus</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"he"><FONT SIZE=3D2 FACE=3D"Arial">C23 - =
Section 5.4 seems to have formatting problems related tot he number of =
allowed characters in a row</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"he"><FONT SIZE=3D2 FACE=3D"Arial">C24 - =
DESCRIPTION clause of sipProxyAuthMethod - more than one method may be =
used, change the clause to reflect this</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"he"><FONT SIZE=3D2 FACE=3D"Arial">C25 - =
sipRegMaxContactExpiryDate - calling this object ...Date is mis-leading. =
I suggest to rename it to ...Duration or something =
else.</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"he"><FONT SIZE=3D2 FACE=3D"Arial">C26 - The =
Normative References section is inconsistent, and does not comply with =
the format recommended in <A =
HREF=3D"http://www.ops.ietf.org/mib-boilerplate.html">http://www.ops.ietf=
.org/mib-boilerplate.html</A></FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"he"><FONT SIZE=3D2 FACE=3D"Arial">C27 - RFC =
3291 (INET-MIB) needs to be added to the Normative References =
list</FONT></SPAN></P>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>

<P DIR=3DLTR><SPAN LANG=3D"he"><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;</FONT></SPAN></P>

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



From mailnull@www1.ietf.org  Mon Apr 28 06:37:27 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25933
	for <sip-archive@odin.ietf.org>; Mon, 28 Apr 2003 06:37:27 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3SAfwC29848
	for sip-archive@odin.ietf.org; Mon, 28 Apr 2003 06:41:58 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SAdT829743;
	Mon, 28 Apr 2003 06:39:29 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SAaE828816
	for <sip@optimus.ietf.org>; Mon, 28 Apr 2003 06:36:14 -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 GAA25830
	for <sip@ietf.org>; Mon, 28 Apr 2003 06:31:13 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19A5wt-0001so-00
	for sip@ietf.org; Mon, 28 Apr 2003 06:33:27 -0400
Received: from [61.144.161.2] (helo=mta0)
	by ietf-mx with esmtp (Exim 4.12)
	id 19A5ws-0001sR-00
	for sip@ietf.org; Mon, 28 Apr 2003 06:33:26 -0400
Received: from w07087a (mta0 [172.17.1.62])
 by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
 2002)) with ESMTPA id <0HE1008A5UL63F@mta0.huawei.com> for sip@ietf.org; Mon,
 28 Apr 2003 18:31:55 +0800 (CST)
Date: Mon, 28 Apr 2003 18:35:58 +0800
From: wenkai <wkai@huawei.com>
Subject: Re: [Sip] can i change my own dialog info  in mid-dialog?
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: Christer Holmberg <christer.holmberg@lmf.ericsson.se>, sip@ietf.org
Message-id: <000701c30d71$f4ac3d60$af064d0a@w07087a>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <00b001c30a2b$6a1db870$af064d0a@w07087a>
 <3EA78A6F.1C67E563@lmf.ericsson.se> <000c01c30a34$90589f10$af064d0a@w07087a>
 <3EA9F280.8010800@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


I would like make my original question more clear by dividing it into two
parts.

The first part:
"UA can change his local uri and remote uri by himself in mid-dialog.", i
think it is correct in RFC3261.

The second part:
"UA can change his request-uri by himself in mid-dialog."  Maybe we can not
do it.
RFC3261 said,  in mid-dialog, "The UAC uses the remote target and route set
to build the Request-URI".  UA can not change "remote target" and "route
set" by himself in mid-dialog.  So, UA can not change his request-uri by
himself in mid-dialog. The UA can change his request-uri by opposite UA's
instruction.

I ask this question because request-uri can be used as service
identification. If UA can change the request-uri by itself, so UA can use
request-uri to carry different service request during mid-dialog. Maybe we
can use parameters to achieve this target.


----- Original Message -----
From: "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>
To: "wenkai" <wkai@huawei.com>
Cc: "Christer Holmberg" <christer.holmberg@lmf.ericsson.se>; <sip@ietf.org>
Sent: Saturday, April 26, 2003 10:44 AM
Subject: Re: [Sip] can i change my own dialog info in mid-dialog?


> That is the only reason.
>
> -Jonathan R.
>
> wenkai wrote:
> > Thanks,
> >
> > But what is the "other reasons" besides backward compatibility?
> >
> >
> > ----- Original Message -----
> > From: "Christer Holmberg" <christer.holmberg@lmf.ericsson.se>
> > To: "wenkai" <wkai@huawei.com>
> > Cc: <sip@ietf.org>
> > Sent: Thursday, April 24, 2003 2:55 PM
> > Subject: Re: [Sip] can i change my own dialog info in mid-dialog?
> >
> >
> >
> >>Hi,
> >>
> >>You must not change the To-URI and From-URI. It is true that in RFC3261
> >>they aren't used for the dialog id, and not for the transaction id, but
> >>in RFC2543 they WERE used for this kind of purpose, so at least for
> >>backward compability (I guess there may be other reasons too...) you
> >>shall not change them.
> >>
> >>Regards,
> >>
> >>Christer Holmberg
> >>Ericsson Finland
> >>
> >>
> >>wenkai wrote:
> >>
> >>
> >>>Hi,According to RFC3261, the dialog ID just include Call-id, remote
> >>>tag and local tag. So, the local uri, remote uri and remote target uri
> >>>are not used for dialog matching.After one dialog established, can a
> >>>UA change his own local uri, remote uri and remote target uri?  Or,
> >>>can the UA send a re-INVITE with different From-URI, To-URI and
> >>>Request-URI as original INVITE's ?I think it is permitted in RFC3261.
> >>>But i am not sure. ThanksKevin
> >>
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP 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 Scientist                             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 mailnull@www1.ietf.org  Mon Apr 28 07:40:21 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27402
	for <sip-archive@odin.ietf.org>; Mon, 28 Apr 2003 07:40:21 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3SBirO01935
	for sip-archive@odin.ietf.org; Mon, 28 Apr 2003 07:44:53 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SBgJ801855;
	Mon, 28 Apr 2003 07:42:19 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SBcA801674
	for <sip@optimus.ietf.org>; Mon, 28 Apr 2003 07:38:10 -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 HAA27275
	for <sip@ietf.org>; Mon, 28 Apr 2003 07:33:07 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19A6un-0002F7-00
	for sip@ietf.org; Mon, 28 Apr 2003 07:35:21 -0400
Received: from mail.cit.ie ([157.190.14.15])
	by ietf-mx with esmtp (Exim 4.12)
	id 19A6un-0002Es-00
	for sip@ietf.org; Mon, 28 Apr 2003 07:35:21 -0400
Received: from EEB174W2Kvk (unverified [157.190.81.172]) by cit.ie
 (Rockliffe SMTPRA 5.3.4) with SMTP id <B0000506852@mail.cit.ie> for <sip@ietf.org>;
 Mon, 28 Apr 2003 12:33:41 +0100
Reply-To: <vkenneally@cit.ie>
From: "Valerie Kenneally" <vkenneally@cit.ie>
To: <sip@ietf.org>
Date: Mon, 28 Apr 2003 12:35:05 +0100
Message-ID: <NIEFLFDIBJCPCKAMIGBPIEFJCGAA.vkenneally@cit.ie>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Content-Transfer-Encoding: 7bit
Subject: [Sip] Complete list of transport protocols upon which SIP can run!
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-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,

	Just wondering if anyone knows where I might find a complete list of the
transport protocols upon which SIP can run?

Cheers,
Val


-------------------Legal  Disclaimer---------------------------------------

The above electronic mail transmission is confidential and intended only for the person to whom it is addressed. Its contents may be protected by legal and/or professional privilege. Should it be received by you in error please contact the sender at the above quoted email address. Any unauthorised form of reproduction of this message is strictly prohibited. The Institute does not guarantee the security of any information electronically transmitted and is not liable if the information contained in this communication is not a proper and complete record of the message as transmitted by the sender nor for any delay in its receipt.

----------------------------------------------------------------------------------------

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



From mailnull@www1.ietf.org  Mon Apr 28 18:10:08 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16569
	for <sip-archive@odin.ietf.org>; Mon, 28 Apr 2003 18:10:07 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3SMEqE19510
	for sip-archive@odin.ietf.org; Mon, 28 Apr 2003 18:14:52 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SMEL819491;
	Mon, 28 Apr 2003 18:14:21 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SMCb819439
	for <sip@optimus.ietf.org>; Mon, 28 Apr 2003 18:12: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 SAA16309
	for <sip@ietf.org>; Mon, 28 Apr 2003 18:07:22 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19AGoZ-0005k6-00
	for sip@ietf.org; Mon, 28 Apr 2003 18:09:35 -0400
Received: from rtp-core-1.cisco.com ([64.102.124.12])
	by ietf-mx with esmtp (Exim 4.12)
	id 19AGoY-0005ju-00
	for sip@ietf.org; Mon, 28 Apr 2003 18:09:34 -0400
Received: from cisco.com (dhcp-64-102-92-121.cisco.com [64.102.92.121])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3SM9blY028651
	for <sip@ietf.org>; Mon, 28 Apr 2003 18:09:39 -0400 (EDT)
Message-ID: <3EADA6A1.5010302@cisco.com>
Date: Mon, 28 Apr 2003 18:09:37 -0400
From: Sanjay Sinha <sanjsinh@cisco.com>
Organization: Cisco Systems
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
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] Question on RFC 3263
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-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 refer to the following statement in Sec. 4.2 of RFC 3263.

<snip>

If the TARGET was not a numeric IP address, but a port is present in
the URI, the client performs an A or AAAA record lookup of the domain
name.  The result will be a list of IP addresses, each of which can
be contacted at the specific port from the URI and transport protocol
determined previously.  The client SHOULD try the first record.  If
an attempt should fail, based on the definition of failure in Section
4.3, the next SHOULD be tried, and if that should fail, the next
SHOULD be tried, and so on.


Definition of failure according to Sec. 4.3 is:

For SIP requests, failure occurs if the transaction layer reports a
503 error response or a transport failure of some sort (generally,
due to fatal ICMP errors in UDP or connection failures in TCP).
Failure also occurs if the transaction layer times out without ever
having received any response, provisional or final (i.e., timer B or
timer F in RFC 3261 [1] fires).


I have following questions:

1) Since ACK for 200 response indicates a new transaction and follows 
rules of sec. 4.2 to find out the ip address of next hop element to send 
ACK to, how does the client transaction detect failure for ACK and move 
to next record in the list if used with UDP and the next hop does not 
generate transport errors.

2) For PRACK, if the client transaction layer times out waiting for 200 
OK to PRACK before moving to the next record, the server transaction may 
run out of 18x retries waiting for PRACK and disconnect the call, if the 
next record happens to be the one that sent 18x.

TIA,
Sanjay.





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



From mailnull@www1.ietf.org  Mon Apr 28 23:55:18 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23923
	for <sip-archive@odin.ietf.org>; Mon, 28 Apr 2003 23:55:17 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3T409a13244
	for sip-archive@odin.ietf.org; Tue, 29 Apr 2003 00:00:09 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3T3vq813152;
	Mon, 28 Apr 2003 23:57:52 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NH0V809201
	for <sip@optimus.ietf.org>; Wed, 23 Apr 2003 13:00: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 MAA25716
	for <sip@ietf.org>; Wed, 23 Apr 2003 12:47:55 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198NRm-0005Qa-00
	for sip@ietf.org; Wed, 23 Apr 2003 12:50:14 -0400
Received: from nmh.informatik.uni-bremen.de ([134.102.224.3] ident=root)
	by ietf-mx with esmtp (Exim 4.12)
	id 198NRl-0005QU-00
	for sip@ietf.org; Wed, 23 Apr 2003 12:50:13 -0400
Received: from nmh.informatik.uni-bremen.de (smmsp@localhost [127.0.0.1])
	by nmh.informatik.uni-bremen.de (8.12.9/8.10.1) with ESMTP id h3NGoLrA000124;
	Wed, 23 Apr 2003 18:50:21 +0200 (MEST)
Received: (from jo@localhost)
	by nmh.informatik.uni-bremen.de (8.12.9/8.12.8/Submit) id h3NGoIb2000120;
	Wed, 23 Apr 2003 18:50:18 +0200 (MEST)
From: Joerg Ott <jo@Informatik.Uni-Bremen.DE>
Message-Id: <200304231650.h3NGoIb2000120@nmh.informatik.uni-bremen.de>
Subject: Re: [Sip] SIP History trace doc
To: vkenneally@cit.ie
Date: Wed, 23 Apr 2003 18:50:18 +0200 (MEST)
Cc: sip@ietf.org
In-Reply-To: <NIEFLFDIBJCPCKAMIGBPIEEMCGAA.vkenneally@cit.ie> from "Valerie Kenneally" at Apr 23, 2003 04:51:47 PM
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-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 an obviously by now outdated piece of history in 
http://www.informatik.uni-bremen.de/~jo/presentations/2001-me-sip-short-history.pdf

I also maintain an updated one which I use in seminars but which is not
yet published anywhere (and needs some updating, too).

You will also find a lot of information (presumably including a repository
of SIP drafts) at http://www.cs.columbia.edu/~hgs/sip

Joerg

> 
> Hi all,
> 
> 	Just wondering if anyone knows of a document/s which trace the development
> of SIP from its initial conception to its current state of
> development-including first authors, dates etc..  Any input would be greatly
> appreciated!
> 
> Cheers,
> Valerie Kenneally
> 
> ------------------------
> Val Kenneally,
> Post-Graduate,
> Electronic Eng. Dept.,
> CIT,
> Rossa Ave.,
> Bishopstown,
> Cork,
> Ireland.
> ------------------------
> Tel: +353 87 2273668
> Fax: +353 21 4326625
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Mon Apr 28 23:57:28 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23974
	for <sip-archive@odin.ietf.org>; Mon, 28 Apr 2003 23:57:28 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3T42J913915
	for sip-archive@odin.ietf.org; Tue, 29 Apr 2003 00:02:19 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3T402813232;
	Tue, 29 Apr 2003 00:00:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PEAr829739
	for <sip@optimus.ietf.org>; Fri, 25 Apr 2003 10:10: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 KAA09567
	for <sip@ietf.org>; Fri, 25 Apr 2003 10:07:16 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1993tN-0000wZ-00
	for sip@ietf.org; Fri, 25 Apr 2003 10:09:33 -0400
Received: from rhenium.btinternet.com ([194.73.73.93])
	by ietf-mx with esmtp (Exim 4.12)
	id 1993tL-0000wW-00
	for sip@ietf.org; Fri, 25 Apr 2003 10:09:31 -0400
Received: from host81-134-165-65.in-addr.btopenworld.com ([81.134.165.65] helo=Gordon)
	by rhenium.btinternet.com with esmtp (Exim 3.22 #23)
	id 1993tn-0005V4-00
	for sip@ietf.org; Fri, 25 Apr 2003 15:09:59 +0100
From: "Gordon Parker \(IT-EM\)" <gparker@it-em.com>
To: <sip@ietf.org>
Date: Fri, 25 Apr 2003 15:09:56 +0100
Message-ID: <NOEALICCKDDCKEEFGBLNKEAGCBAA.gparker@it-em.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0050_01C30B3C.BB7F20C0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Subject: [Sip] Basic POT's handsets for use VOIP compatible SIP/H323
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0050_01C30B3C.BB7F20C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Good afternoon
Are you able to advise on cost for the supply of basic VOIP POT handsets
please
Suppliers, availability and cost information would be helpful
many thanks,
Gordon.
Gordon Parker
IT-EM (UK) Ltd
DDI: 01992 785224
Main:01992 642257
Fax: 01992 785239

Email: Gparker@it-em.com <mailto:Gparker@it-em.com>
The opinions expressed within this Email represent those of the author. The
information in this Email is confidential and may be legally privileged. It
is intended solely for the addressee/s.  Access to this Email by anyone
other than the addressee/s is unauthorised.  If you are not the intended
recipient/s any disclosure, copying, distribution or any action taken, is
prohibited and may be unlawful. Although this e-mail and any attachments are
believed to be free of any virus or any defect which might affect any
computer or IT system into which they are received and opened, it is the
responsibility of the recipient/s to ensure that they are virus free and no
responsibility is accepted by IT-EM (UK) Ltd for any loss or damage arising
in any way from receipt or use thereof. If you receive this email and you
are not the intended recipient please contact IT-EM(UK)Ltd on +44 (0)1992
642257


------=_NextPart_000_0050_01C30B3C.BB7F20C0
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.2800.1141" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D500355213-25042003>Good=20
afternoon</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D500355213-25042003>Are =
you able to=20
advise on cost for the supply of basic VOIP POT handsets=20
please</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D500355213-25042003>Suppliers,=20
availability and cost information would be helpful</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D500355213-25042003>many=20
thanks,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D500355213-25042003>Gordon.</SPAN></FONT></DIV></FONT></DIV>
<P><FONT color=3D#800080><FONT face=3D"Courier New" size=3D2>Gordon =
Parker</FONT>=20
<BR><FONT face=3D"Courier New">IT-EM (UK) Ltd</FONT> <BR><FONT =
face=3D"Courier New"=20
size=3D2>DDI: 01992 785224</FONT> <BR><FONT face=3D"Courier New" =
size=3D2>Main:01992=20
642257</FONT> <BR><FONT face=3D"Courier New" size=3D2>Fax: 01992 =
785239</FONT>=20
<BR><FONT face=3D"Courier New" size=3D2>&nbsp;</FONT> <BR><FONT =
face=3D"Courier New"=20
size=3D2>Email: Gparker@it-em.com &lt;<A=20
href=3D"mailto:Gparker@it-em.com">mailto:Gparker@it-em.com</A>&gt;</FONT>=
=20
<BR><FONT face=3D"Courier New" size=3D2>The opinions expressed within =
this Email=20
represent those of the author. The information in this Email is =
confidential and=20
may be legally privileged. It is intended solely for the =
addressee/s.&nbsp;=20
Access to this Email by anyone other than the addressee/s is =
unauthorised.&nbsp;=20
If you are not the intended recipient/s any disclosure, copying, =
distribution or=20
any action taken, is prohibited and may be unlawful. Although this =
e-mail and=20
any attachments are believed to be free of any virus or any defect which =
might=20
affect any computer or IT system into which they are received and =
opened, it is=20
the responsibility of the recipient/s to ensure that they are virus free =
and no=20
responsibility is accepted by IT-EM (UK) Ltd for any loss or damage =
arising in=20
any way from receipt or use thereof. If you receive this email and you =
are not=20
the intended recipient please contact IT-EM(UK)Ltd on +44 (0)1992=20
642257</FONT></FONT></P>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0050_01C30B3C.BB7F20C0--


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



From mailnull@www1.ietf.org  Mon Apr 28 23:59:47 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24000
	for <sip-archive@odin.ietf.org>; Mon, 28 Apr 2003 23:59:47 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3T44dC13982
	for sip-archive@odin.ietf.org; Tue, 29 Apr 2003 00:04:39 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3T42E813913;
	Tue, 29 Apr 2003 00:02:14 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3S9TA824156
	for <sip@optimus.ietf.org>; Mon, 28 Apr 2003 05:29:10 -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 FAA24983
	for <sip@ietf.org>; Mon, 28 Apr 2003 05:24:11 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19A4u0-0001dT-00
	for sip@ietf.org; Mon, 28 Apr 2003 05:26:24 -0400
Received: from [207.44.196.29] (helo=bharatmail.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19A4u0-0001dQ-00
	for sip@ietf.org; Mon, 28 Apr 2003 05:26:24 -0400
Received: from server1.bharatmart.com (ensim.rackshack.net [207.44.196.29])
	by bharatmail.com (8.11.6/8.11.6) with ESMTP id h3SC35V31829
	for sip@ietf.org; Mon, 28 Apr 2003 07:03:06 -0500
Message-Id: <200304281203.h3SC35V31829@bharatmail.com>
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.411 (Entity 5.404)
From: murali <muraliv@bharatmail.com>
To: sip@ietf.org
Date: Mon Apr 28 14:56:52  2003
Content-Transfer-Encoding: binary
Subject: [Sip] Backward compatibility of expires 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: binary

In RFC 2543 Expires header is defined as "Expires" ":" ( SIP-date | delta-seconds ), whereas in RFC 3261 it is only "Expires" HCOLON delta-seconds.

Will it not create backward compatibility issues if somebody is using SIP-date to specify the expires duration?

Rgds,
Murali

-------
Murali Voleti,
#503,Maheswari complex,
Masab Tank,
Hyderabad
Tele:(040) 6502272 ext:211

_____________________________________________________________
Get Your Free ScanMail and Email At http://mail.ttkbharatplanet.com
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From mailnull@www1.ietf.org  Tue Apr 29 00:01:54 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24058
	for <sip-archive@odin.ietf.org>; Tue, 29 Apr 2003 00:01:54 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3T46jU14023
	for sip-archive@odin.ietf.org; Tue, 29 Apr 2003 00:06:45 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3T44S813979;
	Tue, 29 Apr 2003 00:04:28 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SETF814103
	for <sip@optimus.ietf.org>; Mon, 28 Apr 2003 10:29: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 KAA02750
	for <sip@ietf.org>; Mon, 28 Apr 2003 10:24:08 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19A9aJ-0003Cr-00
	for sip@ietf.org; Mon, 28 Apr 2003 10:26:23 -0400
Received: from pmesmtp02.wcom.com ([199.249.20.2])
	by ietf-mx with esmtp (Exim 4.12)
	id 19A9aI-0003Ci-00
	for sip@ietf.org; Mon, 28 Apr 2003 10:26:22 -0400
Received: from pmismtp02.wcomnet.com ([166.38.62.37])
 by firewall.wcom.com (Iplanet MTA )
 with ESMTP id <0HE2004395DHW8@firewall.wcom.com> for sip@ietf.org; Mon,
 28 Apr 2003 14:24:53 +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 <0HE200A015DGCJ@pmismtp02.wcomnet.com>; Mon,
 28 Apr 2003 14:24:53 +0000 (GMT)
Received: from xs578v3521.mci.com ([166.36.196.55])
 by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7
 2002)) with ESMTP id <0HE20092O5DFJM@pmismtp02.wcomnet.com>; Mon,
 28 Apr 2003 14:24:52 +0000 (GMT)
Date: Mon, 28 Apr 2003 09:24:45 -0500
From: Alan Johnston <alan.johnston@mci.com>
Subject: Re: [Sip] Ongoing Expert Review: Comments on
 draft-johnston-sip-osp-token-04.txt
In-reply-to: <002d01c309d6$4d709120$ee036e3f@txdwillis>
X-Sender: Alan.Johnston@pop.mcit.com
To: Dean Willis <dean.willis@softarmor.com>, sip@ietf.org
Message-id: <5.1.1.6.0.20030428092347.01f0b1b0@pop.mcit.com>
MIME-version: 1.0
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Content-type: text/plain; charset=us-ascii; format=flowed
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-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,

Thanks for your comments - I'll make the changes suggested.  I'll 
investigate the RSVP issue you mention.

Thanks,
Alan Johnston
MCI


At 03:24 PM 4/23/2003 -0500, Dean Willis wrote:

>Ok, here are my comments on the P-header for osp-tokens. If anybody else has
>something to say, please say it soon.
>
>
>
>Draft Section 1, P4 says:
>-------
>    We propose to use existing IETF protocols and proposals in Internet
>    Drafts for interdomain IP telephony calls with QoS as a first step
>    toward a uniform AAA approach. The approach outlined here may be
>    useful later for developing a uniform AAA architecture and protocols
>    for other application layer services.
>---------
>
><dean> Don't "propose", document  . . . . Perhaps "This draft documents a
>propietary SIP extension header field that may be used to exchange open
>settlement protocol [4] information in the context of a SIP session
>establishment." </dean>
>
>
>
>
>Draft, Figure 1 says:
>----------------------
>                               Clearinghouse
>              +------+------+     +------+     +------+------+
>              |Policy|  OSP | OSP | OSP  | OSP | OSP  |Policy|
>              |Server|Client|<--->|Server|<--->|Client|Server|
>              +------+------+     +------+     +------+------+
>                 | |                                   |  |
>     Domain 1    | +-----+                        +----+  |    Domain 2
>                 |       |                        |       |
>             +-----+     |                        |    +-----+
>             | PEP |     |                        |    | PEP |
>  +-----+    +-----+     |                        |    +-----+    +-----+
>  | SIP |SIP | SIP |     |                        |    | SIP |SIP | SIP |
>  | UAC |<-->|Proxy|-------SIP INVITE with OSP Token-->|Proxy|<-->| UAS |
>  +-----+    +-----+     |                        |    +-----+    +--+--+
>                         |                        |                  |
>                         |                        |                  |
>    SIP                  |                        |                  |
>   Phone            +------+                  +------+            +--+--+
>  +------+          | Edge |       RSVP       | Edge |            |     |
>  | RSVP |    RSVP  |Router|      tunnel      |Router|     RSVP   | MG  |
>  | Host |<-------->|      |<---------------->|      |<---------->|     |
>  +------+          +------+   Transit Nets   +------+            +-----+
>
>
>                   Figure 1:   Model for interdomain QoS phone call
>------------------
>
><dean> What the heck is an "RSVP tunnel"? Is this something like a GRE
>tunnel between two edge routers which run RSVP such that it doesn't require
>RSVP support in the routers traversed by that tunnel? Is this usage
>documented somewhere, and if so, can you please give a reference in the
>references section? Speaking of which, do we need to informatively reference
>RSVP in this spec?</dean>
>
>
>Draft, Section 3, Para 3 says:
>------------------------------
>    For these reasons, a new SIP header is proposed instead of a new MIME
>    type for OSP authorization tokens.
>------------------------------
><dean>  s/header/header field/ -- repeat in several places throughout doc
></dean>
>
>
>Draft, Section 4, P 3 says:
>---------------------------
>    which the header filed can be used
>---------------------------
><dean> s/filed/field/ </dean>
>
>
>Draft, Section 5 says:
>----------------------
>5.   Protocol Semantics
>
>    The OSP Token is always encoded per base64 and only allowed in INVITE
>    requests and 200 OK responses to INVITEs.
>----------------------
>
><dean> Is there any implication for early media?  Oh no, I said Early Media!
>Make the Pain Stop!</dean>
>
>
>Draft Section 5.1 says:
>-----------------------
>5.1    User Agents
>
>    A UAC MAY include the header an INVITE requesting QoS using AAA.
>-----------------------
><dean> s/header/header field/ </dean>
>
>Draft, Section 6 says:
>----------------------
>6.   Example Message
>
>    This SIP INVITE message is an example exchange between the two
>    domains as shown in Figure 1:
>
>    INVITE sips:+1-972-555-5555@domain2.com;user=phone SIP/2.0
>    Via: SIP/2.0/TLS proxy.domain1.com:5061;branch=z9hG4bK3a56d3.1
>    Via: SIP/2.0/TLS phone1.domain1.com:5061;branch=z9hG4bK3a5654
>     ;received=192.0.2.1
>    Max-Forward: 69
>    From: Alice <sips:alice@phone1.domain1.com>;tag=3
>    To: <sips:+1-972-555-5555@domain2.com;user=phone>
>    Call-ID: 123456@domain1.com
>    CSeq: 1 INVITE
>    Contact: <sips:alice@phone1.domain1.com>
>    Record-Route: <sips:proxy.domain1.com;lr>
>    P-OSP-Auth-Token: "YT64VqpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756t
>    HGTrfvbnjn8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfH
>    6ghyHhHUujpfyF47GhIGfHfYT64VQbnj"
>    Content-Type: application/sdp
>    Content-Length: 184
>
>    v=0
>    o=alice 9735285123 9721273312 IN IP4 phone1.domain1.com
>    s=-
>    c=IN IP4 phone1.domain1.com
>    t=0 0
>    m=audio 9876 RTP/AVP 0
>    a=rtpmap: 0 PCMU/8000
>------------------------------
>
><dean? The domain usage should align with RFC26206, aka "example.com"
></dean>
>
>
>The draft's IANA considerations section says:
>---------------------------------------------
>IANA Considerations
>
>    Registration of "P-OSP-Auth-Token" SIP header field
>
>    This document defines a new private SIP header field, "P-OSP-Auth-
>    Token".  As recommended by the policy of the Transport Area [3], this
>    header should be registered by the IANA in the SIP header registry,
>    using the RFC number of this document as its reference.
>
>     Name of Header:          P-OSP-Auth-Token
>
>     Short form:              None
>
>     Registrant:              Alan Johnston
>
>                              alan.johnston@wcom.com
>
>     Normative description:   This document
>---------------------------------------------
>
><dean> The reference given, [3], is a reference to Cryptographic Message
>Syntax. I think this is not what you want to point to. You probably need a
>reference to RFC3427, the SIP Change Process, which augments the RFC361 IANA
>process to account for P-headers.  Editorially, it would be nice to see the
>IANA Considerations section numbered and listed in the ToC.</dean>
>
>
>The draft's security considerations section says:
>-------------------------------------------------
>Security Considerations
>
>    The security and handling of OSP tokens is covered in [4] which
>    includes encryption and the use of IPSec.
>
>    The P-OSP-Auth-Token header field may be protected using standard SIP
>    mechanisms such as TLS transport and/or S/MIME encryption as detailed
>    in [1].
>--------------------------------------------------
>
><dean> This is, well, a little light. It would be nice to see some
>discussion of exactly how the threat model in [4] is exposed by carrying OSP
>in SIP, and have a little more discussion of how the referenced security
>mechanisms protect from those exposures. </dean>
>
>--
>Dean
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip

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



From mailnull@www1.ietf.org  Tue Apr 29 10:46:35 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25509
	for <sip-archive@odin.ietf.org>; Tue, 29 Apr 2003 10:46:35 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3TEpfl18068
	for sip-archive@odin.ietf.org; Tue, 29 Apr 2003 10:51:41 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TEog818022;
	Tue, 29 Apr 2003 10:50:42 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TEjj817771
	for <sip@optimus.ietf.org>; Tue, 29 Apr 2003 10:45:45 -0400
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24930
	for <sip@ietf.org>; Tue, 29 Apr 2003 10:40:08 -0400 (EDT)
Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118])
	by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3TEerRs019776;
	Tue, 29 Apr 2003 16:40:53 +0200 (MEST)
Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55)
	id J71ZTGZ4; Tue, 29 Apr 2003 16:40:53 +0200
Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.31.77])
	by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h3TEer2b004844;
	Tue, 29 Apr 2003 17:40:53 +0300 (EET DST)
Message-ID: <3EAE8F5D.C3C1FE84@lmf.ericsson.se>
Date: Tue, 29 Apr 2003 17:42:37 +0300
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Sanjay Sinha <sanjsinh@cisco.com>
CC: sip@ietf.org
Subject: Re: [Sip] Question on RFC 3263
References: <3EADA6A1.5010302@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit


Hi,

> Please refer to the following statement in Sec. 4.2 of RFC 3263.
>
> <snip>
>
> If the TARGET was not a numeric IP address, but a port is present in
> the URI, the client performs an A or AAAA record lookup of the domain
> name.  The result will be a list of IP addresses, each of which can
> be contacted at the specific port from the URI and transport protocol
> determined previously.  The client SHOULD try the first record.  If
> an attempt should fail, based on the definition of failure in Section
> 4.3, the next SHOULD be tried, and if that should fail, the next
> SHOULD be tried, and so on.
>
> Definition of failure according to Sec. 4.3 is:
>
> For SIP requests, failure occurs if the transaction layer reports a
> 503 error response or a transport failure of some sort (generally,
> due to fatal ICMP errors in UDP or connection failures in TCP).
> Failure also occurs if the transaction layer times out without ever
> having received any response, provisional or final (i.e., timer B or
> timer F in RFC 3261 [1] fires).
>
> I have following questions:
>
> 1) Since ACK for 200 response indicates a new transaction and follows
> rules of sec. 4.2 to find out the ip address of next hop element to send
> ACK to, how does the client transaction detect failure for ACK and move
> to next record in the list if used with UDP and the next hop does not
> generate transport errors.

[CHH] It is true that the remote server will not be able to send eg a 503
response for an ACK, but if the failure occurs on the transport level you
will be notified it the same way as you would for any other request (ICMP
errors etc). These are sent independently on if the remote server generates
SIP responses or not.

> 2) For PRACK, if the client transaction layer times out waiting for 200
> OK to PRACK before moving to the next record, the server transaction may
> run out of 18x retries waiting for PRACK and disconnect the call, if the
> next record happens to be the one that sent 18x.

[CHH] In theory, yes. Normally, however, I would say that PRACKs are sent to
the same IP address as the INVITE, so if you don't get a reply (even if you
get replies to the INVITE) something is probably wrong on the remote side
anway...

Also, I would assume that in most cases the remote party either answers the
call, or the client terminates the call setup, before these timeouts
occur...

Regards,

Christer Holmberg
Ericsson Finland


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



From mailnull@www1.ietf.org  Tue Apr 29 11:10:06 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26982
	for <sip-archive@odin.ietf.org>; Tue, 29 Apr 2003 11:10:06 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3TFFDg21019
	for sip-archive@odin.ietf.org; Tue, 29 Apr 2003 11:15:13 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TFEc820963;
	Tue, 29 Apr 2003 11:14:38 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TFDo820934
	for <sip@optimus.ietf.org>; Tue, 29 Apr 2003 11:13: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 LAA26945
	for <sip@ietf.org>; Tue, 29 Apr 2003 11:08:13 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19AWkV-0005B6-00
	for sip@ietf.org; Tue, 29 Apr 2003 11:10:27 -0400
Received: from rtp-core-1.cisco.com ([64.102.124.12])
	by ietf-mx with esmtp (Exim 4.12)
	id 19AWkU-0005Aw-00
	for sip@ietf.org; Tue, 29 Apr 2003 11:10:26 -0400
Received: from cisco.com (dhcp-64-102-92-121.cisco.com [64.102.92.121])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3TFAPYg009705;
	Tue, 29 Apr 2003 11:10:26 -0400 (EDT)
Message-ID: <3EAE95E3.5000906@cisco.com>
Date: Tue, 29 Apr 2003 11:10:27 -0400
From: Sanjay Sinha <sanjsinh@cisco.com>
Organization: Cisco Systems
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
CC: sip@ietf.org
Subject: Re: [Sip] Question on RFC 3263
References: <3EADA6A1.5010302@cisco.com> <3EAE8F5D.C3C1FE84@lmf.ericsson.se>
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

Hi Christer,

Thanks for the response, pl. see inline.

Sanjay.

Christer Holmberg wrote:

>Hi,
>
>  
>
>>Please refer to the following statement in Sec. 4.2 of RFC 3263.
>>
>><snip>
>>
>>If the TARGET was not a numeric IP address, but a port is present in the URI, the client performs an A or AAAA record lookup of the domain name.  The result will be a list of IP addresses, each of which can be contacted at the specific port from the URI and transport protocol determined previously.  The client SHOULD try the first record.  If an attempt should fail, based on the definition of failure in Section 4.3, the next SHOULD be tried, and if that should fail, the next SHOULD be tried, and so on.
>>
>>Definition of failure according to Sec. 4.3 is:
>>
>>For SIP requests, failure occurs if the transaction layer reports a
>>503 error response or a transport failure of some sort (generally,
>>due to fatal ICMP errors in UDP or connection failures in TCP).
>>Failure also occurs if the transaction layer times out without ever
>>having received any response, provisional or final (i.e., timer B or
>>timer F in RFC 3261 [1] fires).
>>
>>I have following questions:
>>
>>1) Since ACK for 200 response indicates a new transaction and follows
>>rules of sec. 4.2 to find out the ip address of next hop element to send
>>ACK to, how does the client transaction detect failure for ACK and move
>>to next record in the list if used with UDP and the next hop does not generate transport errors.
>>    
>>
>
>[CHH] It is true that the remote server will not be able to send eg a 503 response for an ACK, but if the failure occurs on the transport level you will be notified it the same way as you would for any other request (ICMP errors etc). These are sent independently on if the remote server generates SIP responses or not.
>
[SS] But the client transport layer will not get ICMP errors if the 
first record from the list has crashed or has it's interface shutdown.

>
>2) For PRACK, if the client transaction layer times out waiting for 200
>OK to PRACK before moving to the next record, the server transaction may
>run out of 18x retries waiting for PRACK and disconnect the call, if the
>next record happens to be the one that sent 18x.
>  
>
>
>[CHH] In theory, yes. Normally, however, I would say that PRACKs are sent to the same IP address as the INVITE, so if you don't get a reply (even if you get replies to the INVITE) something is probably wrong on the remote side anway...
>
[SS] I do not think that's true. If the proxy in-between did  not 
record-route, PRACK will be sent to Contact of 18x and not where the 
Invite was sent.

>
>Also, I would assume that in most cases the remote party either answers the call, or the client terminates the call setup, before these timeouts occur...
>
>Regards,
>
>Christer Holmberg
>Ericsson Finland
>
>
>  
>


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



From mailnull@www1.ietf.org  Tue Apr 29 11:21:57 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27450
	for <sip-archive@odin.ietf.org>; Tue, 29 Apr 2003 11:21:57 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3TFR4K21705
	for sip-archive@odin.ietf.org; Tue, 29 Apr 2003 11:27:04 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TFQX821667;
	Tue, 29 Apr 2003 11:26:33 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TFPP821622
	for <sip@optimus.ietf.org>; Tue, 29 Apr 2003 11:25: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 LAA27304
	for <sip@ietf.org>; Tue, 29 Apr 2003 11:19:48 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19AWvh-0005Ge-00
	for sip@ietf.org; Tue, 29 Apr 2003 11:22:01 -0400
Received: from broadsoft.com ([198.104.184.110])
	by ietf-mx with esmtp (Exim 4.12)
	id 19AWvg-0005GZ-00
	for sip@ietf.org; Tue, 29 Apr 2003 11:22:00 -0400
Received: from tate (host4.brodsoft.com [66.160.10.4] (may be forged)) by broadsoft.com (8.12.9) id h3TFMb31043775; Tue, 29 Apr 2003 11:22:37 -0400 (EDT)
Reply-To: <brett@broadsoft.com>
From: "Brett Tate" <brett@broadsoft.com>
To: <sip@ietf.org>
Subject: RE: [Sip] Backward compatibility of expires header
Date: Tue, 29 Apr 2003 11:26:31 -0400
Message-ID: <000401c30e63$b68b00a0$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: <200304281203.h3SC35V31829@bharatmail.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

> In RFC 2543 Expires header is defined as 
> "Expires" ":" ( SIP-date | delta-seconds ), 
> whereas in RFC 3261 it is only 
> "Expires" HCOLON delta-seconds.
> 
> Will it not create backward compatibility 
> issues if somebody is using SIP-date to 
> specify the expires duration?

Polls and comments were taken prior to
removing the backward compatibility.

If I recall correctly, the Contact expires 
parameter of a 200 response to a REGISTER was 
the only location that vendors had previously 
chose to send SIP-date instead of delta-seconds.

Those using SIP-date within Expires and
and various other headers agreed to change
their implementations start sending delta-seconds.

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



From mailnull@www1.ietf.org  Wed Apr 30 06:20:43 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27300
	for <sip-archive@odin.ietf.org>; Wed, 30 Apr 2003 06:20:43 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3UAQD032191
	for sip-archive@odin.ietf.org; Wed, 30 Apr 2003 06:26:13 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UAOC832106;
	Wed, 30 Apr 2003 06:24:12 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UAJZ831929
	for <sip@optimus.ietf.org>; Wed, 30 Apr 2003 06:19: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 GAA27202
	for <sip@ietf.org>; Wed, 30 Apr 2003 06:13:35 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Aoct-0005jU-00
	for sip@ietf.org; Wed, 30 Apr 2003 06:15:47 -0400
Received: from gate.ikr.uni-stuttgart.de ([129.69.170.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Aoct-0005jK-00
	for sip@ietf.org; Wed, 30 Apr 2003 06:15:47 -0400
Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12])
	by gate.ikr.uni-stuttgart.de (Postfix) with ESMTP
	id 037D12AE25; Wed, 30 Apr 2003 12:15:54 +0200 (CEST)
Received: from there (lnc2 [10.21.12.22])
	by netsrv1.ikr.uni-stuttgart.de (Postfix) with SMTP
	id 09CE08D790; Wed, 30 Apr 2003 12:15:54 +0200 (CEST)
Content-Type: text/plain;
  charset="iso-8859-1"
From: Roland Gloeckler <gloeckle@ikr.uni-stuttgart.de>
Organization: University of Stuttgart, IKR
To: mwatson@nortelnetworks.com, Jon.Peterson@NeuStar.biz, fluffy@cisco.com
Date: Wed, 30 Apr 2003 12:15:53 +0200
X-Mailer: KMail [version 1.3.1]
Cc: sip@ietf.org
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <20030430101554.09CE08D790@netsrv1.ikr.uni-stuttgart.de>
Content-Transfer-Encoding: 8bit
Subject: [Sip] Motivation for RFC 3325
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit

Dear Sirs,

I would like to know which Scenarios you had in mind for the usage of RFC 3325. 

In chapter 1 you state the following:
"An example deployment would be a closed network which emulates a traditional circuit switched telephone network."

Is this the Scenario that motivated you or are the others?

Regards

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



From mailnull@www1.ietf.org  Wed Apr 30 06:21:58 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27332
	for <sip-archive@odin.ietf.org>; Wed, 30 Apr 2003 06:21:58 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3UARSX32256
	for sip-archive@odin.ietf.org; Wed, 30 Apr 2003 06:27:28 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UAR5832239;
	Wed, 30 Apr 2003 06:27:05 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UALf832006
	for <sip@optimus.ietf.org>; Wed, 30 Apr 2003 06:21:41 -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 GAA27214
	for <sip@ietf.org>; Wed, 30 Apr 2003 06:15:41 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Aoew-0005jp-00
	for sip@ietf.org; Wed, 30 Apr 2003 06:17:54 -0400
Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.wise.edt.ericsson.se)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Aoev-0005jm-00
	for sip@ietf.org; Wed, 30 Apr 2003 06:17:53 -0400
Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120])
	by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3UAISI3010900;
	Wed, 30 Apr 2003 12:18:28 +0200 (MEST)
Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55)
	id J71VP0WJ; Wed, 30 Apr 2003 12:18:27 +0200
Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.31.77])
	by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h3UAIR2b004801;
	Wed, 30 Apr 2003 13:18:27 +0300 (EET DST)
Message-ID: <3EAFA36A.5492523C@lmf.ericsson.se>
Date: Wed, 30 Apr 2003 13:20:26 +0300
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Sanjay Sinha <sanjsinh@cisco.com>
CC: sip@ietf.org
Subject: Re: [Sip] Question on RFC 3263
References: <3EADA6A1.5010302@cisco.com> <3EAE8F5D.C3C1FE84@lmf.ericsson.se> <3EAE95E3.5000906@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit


Hi,

> >>1) Since ACK for 200 response indicates a new transaction and follows
> >>rules of sec. 4.2 to find out the ip address of next hop element to send
> >>ACK to, how does the client transaction detect failure for ACK and move
> >>to next record in the list if used with UDP and the next hop does not generate transport errors.
> >>
> >>
> >
> >[CHH] It is true that the remote server will not be able to send eg a 503 response for an ACK, but if the failure occurs on the transport level you will be notified >it the same way as you would for any other request (ICMP errors etc). These are sent independently on if the remote server generates SIP responses or not.
> >
> [SS] But the client transport layer will not get ICMP errors if the
> first record from the list has crashed or has it's interface shutdown.

[CHH] Well, if the ACK doesn't reach the server you will get retransmits of the 200 OK (unless they are supposed to be sent from the same interface which has crashed, of course)..

> >2) For PRACK, if the client transaction layer times out waiting for 200
> >OK to PRACK before moving to the next record, the server transaction may
> >run out of 18x retries waiting for PRACK and disconnect the call, if the
> >next record happens to be the one that sent 18x.
> >
> >
> >
> >[CHH] In theory, yes. Normally, however, I would say that PRACKs are sent to the same IP address as the INVITE, so if you don't get a reply (even if you get >replies to the INVITE) something is probably wrong on the remote side anway...
> >
> [SS] I do not think that's true. If the proxy in-between did  not
> record-route, PRACK will be sent to Contact of 18x and not where the
> Invite was sent.

[CHH] True, but what I meant is that the remote UAS (ie the one generating and sending the 18x messages, and that will eventually receive the PRACK) is the same.

UAC             PROXY             UAS

--- INVITE --->   --->INVITE--->
<--18x----------  <---18x----------
----PRACK----------------------->


Regards,

Christer Holmberg
Ericsson Finland


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



From mailnull@www1.ietf.org  Wed Apr 30 10:01:01 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03864
	for <sip-archive@odin.ietf.org>; Wed, 30 Apr 2003 10:01:00 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3UE6YU13647
	for sip-archive@odin.ietf.org; Wed, 30 Apr 2003 10:06:34 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UE64813598;
	Wed, 30 Apr 2003 10:06:04 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UE2m813268
	for <sip@optimus.ietf.org>; Wed, 30 Apr 2003 10:02: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 JAA03538
	for <sip@ietf.org>; Wed, 30 Apr 2003 09:56:44 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19As6p-0007HA-00
	for sip@ietf.org; Wed, 30 Apr 2003 09:58:55 -0400
Received: from h3s128a211n47.user.nortelnetworks.com ([47.211.128.3] helo=znsgs01r.nortelnetworks.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19As6o-0007GH-00
	for sip@ietf.org; Wed, 30 Apr 2003 09:58:54 -0400
Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124])
	by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3UDwaN15899;
	Wed, 30 Apr 2003 14:58:37 +0100 (BST)
Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19)
	id <JN3DCZCG>; Wed, 30 Apr 2003 14:58:22 +0100
Message-ID: <A3C2399B2FACD411A54200508BE39C740A461939@zwcwd00r.europe.nortel.com>
From: "Mark Watson" <mwatson@nortelnetworks.com>
To: "'Roland Gloeckler'" <gloeckle@ikr.uni-stuttgart.de>,
        Jon.Peterson@NeuStar.biz, fluffy@cisco.com
Cc: sip@ietf.org
Date: Wed, 30 Apr 2003 14:58:13 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C30F20.5D2786EC"
Subject: [Sip] RE: Motivation for RFC 3325
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-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_01C30F20.5D2786EC
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Roland,=20

Another example would be the IP Multimedia Subsystem defined by 3GPP. =
See
for example 3GPP TS 23.228, 24.228, 24.229 available at www.3gpp.org.

Regards,

Mark Watson

> -----Original Message-----
> From: Roland Gloeckler [mailto:gloeckle@ikr.uni-stuttgart.de]
> Sent: 30 April 2003 12:16
> To: Watson, Mark [MOP:EP10:EXCH]; Jon.Peterson@NeuStar.biz;
> fluffy@cisco.com
> Cc: sip@ietf.org
> Subject: Motivation for RFC 3325
>=20
>=20
> Dear Sirs,
>=20
> I would like to know which Scenarios you had in mind for the=20
> usage of RFC 3325.=20
>=20
> In chapter 1 you state the following:
> "An example deployment would be a closed network which=20
> emulates a traditional circuit switched telephone network."
>=20
> Is this the Scenario that motivated you or are the others?
>=20
> Regards
>=20
> Roland Gl=F6ckler
>=20

------_=_NextPart_001_01C30F20.5D2786EC
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>RE: Motivation for RFC 3325</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Roland, </FONT>
</P>

<P><FONT SIZE=3D2>Another example would be the IP Multimedia Subsystem =
defined by 3GPP. See for example 3GPP TS 23.228, 24.228, 24.229 =
available at www.3gpp.org.</FONT></P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>Mark Watson</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Roland Gloeckler [<A =
HREF=3D"mailto:gloeckle@ikr.uni-stuttgart.de">mailto:gloeckle@ikr.uni-st=
uttgart.de</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: 30 April 2003 12:16</FONT>
<BR><FONT SIZE=3D2>&gt; To: Watson, Mark [MOP:EP10:EXCH]; =
Jon.Peterson@NeuStar.biz;</FONT>
<BR><FONT SIZE=3D2>&gt; fluffy@cisco.com</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: sip@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Motivation for RFC 3325</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Dear Sirs,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I would like to know which Scenarios you had in =
mind for the </FONT>
<BR><FONT SIZE=3D2>&gt; usage of RFC 3325. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; In chapter 1 you state the following:</FONT>
<BR><FONT SIZE=3D2>&gt; &quot;An example deployment would be a closed =
network which </FONT>
<BR><FONT SIZE=3D2>&gt; emulates a traditional circuit switched =
telephone network.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Is this the Scenario that motivated you or are =
the others?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Regards</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Roland Gl=F6ckler</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

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



From mailnull@www1.ietf.org  Wed Apr 30 10:02:32 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03930
	for <sip-archive@odin.ietf.org>; Wed, 30 Apr 2003 10:02:32 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3UE86S14673
	for sip-archive@odin.ietf.org; Wed, 30 Apr 2003 10:08:06 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UE7j814627;
	Wed, 30 Apr 2003 10:07:45 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UE6t813672
	for <sip@optimus.ietf.org>; Wed, 30 Apr 2003 10:06: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 KAA03846
	for <sip@ietf.org>; Wed, 30 Apr 2003 10:00:51 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19AsAo-0007NE-00
	for sip@ietf.org; Wed, 30 Apr 2003 10:03:02 -0400
Received: from rtp-core-1.cisco.com ([64.102.124.12])
	by ietf-mx with esmtp (Exim 4.12)
	id 19AsAo-0007Mt-00
	for sip@ietf.org; Wed, 30 Apr 2003 10:03:02 -0400
Received: from cisco.com (dhcp-64-102-92-121.cisco.com [64.102.92.121])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3UE39DP020199;
	Wed, 30 Apr 2003 10:03:09 -0400 (EDT)
Message-ID: <3EAFD79D.7070302@cisco.com>
Date: Wed, 30 Apr 2003 10:03:09 -0400
From: Sanjay Sinha <sanjsinh@cisco.com>
Organization: Cisco Systems
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
CC: sip@ietf.org
Subject: Re: [Sip] Question on RFC 3263
References: <3EADA6A1.5010302@cisco.com> <3EAE8F5D.C3C1FE84@lmf.ericsson.se> <3EAE95E3.5000906@cisco.com> <3EAFA36A.5492523C@lmf.ericsson.se>
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

Hi Christer,

Pl. see inline.

thanks,
Sanjay.

Christer Holmberg wrote:

>Hi,
>
>  
>
>>>>1) Since ACK for 200 response indicates a new transaction and follows
>>>>rules of sec. 4.2 to find out the ip address of next hop element to send
>>>>ACK to, how does the client transaction detect failure for ACK and move
>>>>to next record in the list if used with UDP and the next hop does not generate transport errors.
>>>>
>>>>
>>>>        
>>>>
>>>[CHH] It is true that the remote server will not be able to send eg a 503 response for an ACK, but if the failure occurs on the transport level you will be notified >it the same way as you would for any other request (ICMP errors etc). These are sent independently on if the remote server generates SIP responses or not.
>>>
>>>      
>>>
>>[SS] But the client transport layer will not get ICMP errors if the
>>first record from the list has crashed or has it's interface shutdown.
>>    
>>
>
>[CHH] Well, if the ACK doesn't reach the server you will get retransmits of the 200 OK (unless they are supposed to be sent from the same interface which has crashed, of course)..
>
[SS] Right, but how does the client's transaction figure out that 200  
retransmissions are because of Ack going to the wrong interface from the 
list  vs. Ack being lost in the network/network delay and whether it 
should cycle to the next record or not.

>
>  
>
>>>2) For PRACK, if the client transaction layer times out waiting for 200
>>>OK to PRACK before moving to the next record, the server transaction may
>>>run out of 18x retries waiting for PRACK and disconnect the call, if the
>>>next record happens to be the one that sent 18x.
>>>
>>>
>>>
>>>[CHH] In theory, yes. Normally, however, I would say that PRACKs are sent to the same IP address as the INVITE, so if you don't get a reply (even if you get >replies to the INVITE) something is probably wrong on the remote side anway...
>>>
>>>      
>>>
>>[SS] I do not think that's true. If the proxy in-between did  not
>>record-route, PRACK will be sent to Contact of 18x and not where the
>>Invite was sent.
>>    
>>
>
>[CHH] True, but what I meant is that the remote UAS (ie the one generating and sending the 18x messages, and that will eventually receive the PRACK) is the same.
>
>UAC             PROXY             UAS
>
>--- INVITE --->   --->INVITE--->
><--18x----------  <---18x----------
>----PRACK----------------------->
>
[SS] Not neccesarily, if the UAS has dual interface (for redundancy 
etc.) and uses fqdn in contact of 18x with one interface having higher 
priority than the other one and the high priority interface down for 
some reason. UAC, after dns resolution of contact's fqdn, will use it 
for sending Prack and will keep  retransmitting till it gets 200 OK and 
will cycle to the next record when it runs out of retries. But the UAS 
is also retransmitting 18x waiting for Prack since the interface it's 
getting Prack on is down and when it runs out of retries will disconnect 
the call.

>
>
>Regards,
>
>Christer Holmberg
>Ericsson Finland
>
>
>  
>


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