From sip-bounces@ietf.org Mon May 02 14:17:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSfUD-0002Er-2A; Mon, 02 May 2005 14:17:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSfUB-0002Eb-0s; Mon, 02 May 2005 14:17:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11384; Mon, 2 May 2005 14:17:37 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSfhu-0001Ar-6P; Mon, 02 May 2005 14:31:50 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j42IFa602703; Mon, 2 May 2005 11:15:36 -0700 (PDT) Message-Id: <200505021815.j42IFa602703@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Mon, 02 May 2005 11:15:36 -0700 X-ISI-4-39-6-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: sip@ietf.org, rfc-editor@rfc-editor.org Subject: [Sip] RFC 4028 on Session Timers in the Session Initiation Protocol (SIP) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4028 Title: Session Timers in the Session Initiation Protocol (SIP) Author(s): S. Donovan, J. Rosenberg Status: Standards Track Date: April 2005 Mailbox: srd@cisco.com, jdrosen@cisco.com Pages: 27 Characters: 65363 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sip-session-timer-15.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4028.txt This document defines an extension to the Session Initiation Protocol (SIP). This extension allows for a periodic refresh of SIP sessions through a re-INVITE or UPDATE request. The refresh allows both user agents and proxies to determine whether the SIP session is still active. The extension defines two new header fields: Session-Expires, which conveys the lifetime of the session, and Min-SE, which conveys the minimum allowed value for the session timer. 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. 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: <050502111426.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4028 --OtherAccess Content-Type: Message/External-body; name="rfc4028.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <050502111426.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Mon May 02 15:30:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSgd7-000244-Gv; Mon, 02 May 2005 15:30:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSgd5-00023y-5A for sip@megatron.ietf.org; Mon, 02 May 2005 15:30:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23402 for ; Mon, 2 May 2005 15:30:53 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSgqo-0004Ac-0x for sip@ietf.org; Mon, 02 May 2005 15:45:07 -0400 Received: from [64.101.149.196] (adahmed-w2k02-1.cisco.com [64.101.149.196] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j42JWg7I008806 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 2 May 2005 14:32:43 -0500 In-Reply-To: <200505021815.j42IFa602703@boreas.isi.edu> References: <200505021815.j42IFa602703@boreas.isi.edu> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <468b6b034cd2c13d6e61206effaa8540@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] RFC 4028 on Session Timers in the Session Initiation Protocol (SIP) Date: Mon, 2 May 2005 14:30:26 -0500 To: sip@ietf.org X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On May 2, 2005, at 1:15 PM, rfc-editor@rfc-editor.org wrote: > > A new Request for Comments is now available in online RFC libraries. > > > RFC 4028 > > Title: Session Timers in the Session Initiation Protocol > (SIP) > Author(s): S. Donovan, J. Rosenberg > Status: Standards Track > Date: April 2005 > Mailbox: srd@cisco.com, jdrosen@cisco.com I'd like to take a moment to congratulate Steve and Jonathan as well as the rest of the SIP working group on the birth of their new RFC, which was somewhat over five years in the making. We started working on this draft before the y2k "crisis", before the forming of the SIP working group (we were still in MMUSIC), and before the big migration of sip-heads to dynamicsoft. This work went 15 revs as a working group draft, several more as an individual, and I think it endured seven editors over its lifetime. That's approximately 3 months per page of text, including the boilerplate (and the boilerplate was revised several times during the life of the draft). Congratulations, everyone. Personally, I believe this marks a high point in my professional career, and I'm pleased to have been part of this heroic effort. I'm sure that now that it's done, I'm ready for downsizing and replacement by an offshore help desk professional. Note that we've already started accumulating errata and clarifications, and expect to revise the draft somewhere around 2010. -- 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 sip-bounces@ietf.org Mon May 02 20:17:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSl64-0005bh-Cn; Mon, 02 May 2005 20:17:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSl62-0005aO-LF for sip@megatron.ietf.org; Mon, 02 May 2005 20:17:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03824 for ; Mon, 2 May 2005 20:17:05 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSlJn-0006Xg-II for sip@ietf.org; Mon, 02 May 2005 20:31:20 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 02 May 2005 17:16:56 -0700 Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j430GqpR014214; Mon, 2 May 2005 17:16:53 -0700 (PDT) Received: from [45.14.5.4] (sjc-vpn5-632.cisco.com [10.21.90.120]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AJQ75700; Mon, 2 May 2005 17:16:51 -0700 (PDT) Message-ID: <4276C2F3.6030102@cisco.com> Date: Mon, 02 May 2005 20:16:51 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] RFC 4028 on Session Timers in the Session Initiation Protocol (SIP) References: <200505021815.j42IFa602703@boreas.isi.edu> <468b6b034cd2c13d6e61206effaa8540@softarmor.com> In-Reply-To: <468b6b034cd2c13d6e61206effaa8540@softarmor.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Actually, I was considering writing, "Session Timers Considered Harmful" now that we've gotten the RFC published ;) -Jonathan R. Dean Willis wrote: > Note that we've already started accumulating errata and clarifications, > and expect to revise the draft somewhere around 2010. > > -- > Dean > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.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 sip-bounces@ietf.org Mon May 02 20:20:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSl8q-0007F1-2p; Mon, 02 May 2005 20:20:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSl8o-0007Er-Dz for sip@megatron.ietf.org; Mon, 02 May 2005 20:19:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04078 for ; Mon, 2 May 2005 20:19:57 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSlMZ-0006cR-RN for sip@ietf.org; Mon, 02 May 2005 20:34:13 -0400 Received: from [64.101.149.196] ([64.101.149.196]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j430Ljau009815 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 2 May 2005 19:22:43 -0500 In-Reply-To: <4276C2F3.6030102@cisco.com> References: <200505021815.j42IFa602703@boreas.isi.edu> <468b6b034cd2c13d6e61206effaa8540@softarmor.com> <4276C2F3.6030102@cisco.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <99aae4b9d1759b9c8225646101080845@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] RFC 4028 on Session Timers in the Session Initiation Protocol (SIP) Date: Mon, 2 May 2005 19:20:28 -0500 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org oh man! I sprayed diet Dr. Pepper onto my CRT when I read this! -- Dean On May 2, 2005, at 7:16 PM, Jonathan Rosenberg wrote: > Actually, I was considering writing, "Session Timers Considered > Harmful" now that we've gotten the RFC published ;) > > -Jonathan R. > > Dean Willis wrote: > > >> Note that we've already started accumulating errata and >> clarifications, and expect to revise the draft somewhere around 2010. >> -- >> Dean > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.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 sip-bounces@ietf.org Tue May 03 02:57:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSrLK-00054h-VF; Tue, 03 May 2005 02:57:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSrLJ-00051T-1N for sip@megatron.ietf.org; Tue, 03 May 2005 02:57:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05574 for ; Tue, 3 May 2005 02:57:15 -0400 (EDT) Received: from rissala175.outgw.tn ([193.95.17.175] helo=rissala173.outgw.tn) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSrZ7-0008Gm-QV for sip@ietf.org; Tue, 03 May 2005 03:11:35 -0400 Received: from smtp.rnu.tn (smtp.rnu.tn [193.95.32.173]) Received: from localhost (smtp.rnu.tn [127.0.0.1]) by smtp.rnu.tn (Postfix) with ESMTP id 31AAB61C09E for ; Tue, 3 May 2005 08:59:53 +0200 (MEST) Received: from smtp.rnu.tn ([127.0.0.1]) by localhost (smtp.rnu.tn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02482-10 for ; Tue, 3 May 2005 08:59:53 +0200 (MEST) Received: by smtp.rnu.tn (Postfix, from userid 100) id 1B0C361C0B9; Tue, 3 May 2005 08:59:53 +0200 (MEST) Received: from hsgammar (unknown [193.95.31.45]) by smtp.rnu.tn (Postfix) with SMTP id B77BC61C09E for ; Tue, 3 May 2005 08:59:41 +0200 (MEST) Message-ID: <001701c54fb5$7a288d40$2d1f5fc1@hsgammar> From: "Sonia METTALI GAMMAR" To: Date: Tue, 3 May 2005 08:55:19 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Virus-Scanned: amavisd-new at rnu.tn X-Spam-Score: 3.0 (+++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Sip] unsubscibe X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0951243063==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0951243063== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01C54FBD.D541F510" This is a multi-part message in MIME format. ------=_NextPart_000_0012_01C54FBD.D541F510 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable please unsubscribe me from your list ------=_NextPart_000_0012_01C54FBD.D541F510 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
please unsubscribe me from your=20 list
------=_NextPart_000_0012_01C54FBD.D541F510-- --===============0951243063== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0951243063==-- From sip-bounces@ietf.org Tue May 03 12:34:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT0M5-0000LA-Lm; Tue, 03 May 2005 12:34:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT0M3-0000L1-8f for sip@megatron.ietf.org; Tue, 03 May 2005 12:34:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07109 for ; Tue, 3 May 2005 12:34:36 -0400 (EDT) Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DT0Zx-0005vo-79 for sip@ietf.org; Tue, 03 May 2005 12:49:02 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j43GYST9270444 for ; Tue, 3 May 2005 12:34:28 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j43GYRxQ368434 for ; Tue, 3 May 2005 10:34:27 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j43GYR1b018507 for ; Tue, 3 May 2005 10:34:27 -0600 Received: from [9.1.115.65] (bartonjj.almaden.ibm.com [9.1.115.65]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j43GYRE0018129 for ; Tue, 3 May 2005 10:34:27 -0600 Message-ID: <4277A80E.4070606@us.ibm.com> Date: Tue, 03 May 2005 09:34:22 -0700 From: "JOHN J. BARTON" User-Agent: Mozilla Thunderbird 0.9 (X11/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Subject: [Sip] RFC 3261 From and To header tags: how globally unique? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi. I am trying to get a better understanding of SIP design. RFC 3261, 19.3 Tags says: When a tag is generated by a UA for insertion into a request or response, it MUST be globally unique and cryptographically random with at least 32 bits of randomness. It also says: It serves as a general mechanism to identify a dialog, which is the combination of the Call-ID along with two tags, one from each participant in the dialog. Which "globe" is meant here? Two choices seem likely: 1) All space and time. 2) All SIP UAs in a call. I have seen the second interpretation in SIP UA code, meaning a 32bit random string is used for the tag. When discussing Call-ID, RFC3261 calls out a globally unique identifier over space and time then points to RFC1750 for cryptographic randomness, but the degree of randomness is not specified. Should both the Call-ID and tag be unique across Internet and time and further more contain 32 bits of randomness? Why both requirements? If we have a globally unique identifier for the call and for each party in it, what does randomness add? If we are counting on randomness to minimize collision, what does uniqueness add? Thanks! -- John J. Barton IBM Almaden Research Center http://www.almaden.ibm.com/cs/people/bartonjj/index.htm _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 03 22:24:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT9Yq-0006uS-CR; Tue, 03 May 2005 22:24:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT9Yl-0006qR-6Q for sip@megatron.ietf.org; Tue, 03 May 2005 22:24:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04263 for ; Tue, 3 May 2005 22:24:20 -0400 (EDT) From: Udit_Goyal@3com.com Received: from ahmler4.mail.eds.com ([192.85.154.77]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DT9mk-0006ea-En for sip@ietf.org; Tue, 03 May 2005 22:38:51 -0400 Received: from ahmlir5.mail.eds.com (ahmlir5-2.mail.eds.com [192.85.154.135]) by ahmler4.mail.eds.com (8.13.2/8.12.10) with ESMTP id j442O2wN010925; Tue, 3 May 2005 22:24:03 -0400 Received: from ahmlir5.mail.eds.com (localhost [127.0.0.1]) by ahmlir5.mail.eds.com (8.13.2/8.12.10) with ESMTP id j442NtwR023768; Tue, 3 May 2005 22:23:55 -0400 Received: from usut001.3com.com ([205.142.126.149]) by ahmlir5.mail.eds.com (8.13.2/8.12.10) with ESMTP id j442NsAn023757; Tue, 3 May 2005 22:23:55 -0400 To: "SIP Implementors" , "SIP IETF" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: Date: Tue, 3 May 2005 22:29:49 -0400 X-MIMETrack: Serialize by Router on USUT001/US/3Com(Release 6.0.3|September 26, 2003) at 05/03/2005 07:23:55 PM, Serialize complete at 05/03/2005 07:23:55 PM X-Spam-Score: 0.8 (/) X-Scan-Signature: 9ba883ba659fcd62a05a0ed0aea6f612 Cc: Subject: [Sip] Fw: [Sip-implementors] Fw: Via header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1401016948==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============1401016948== Content-Type: multipart/alternative; boundary="=_alternative 000D1B7C85256FF7_=" This is a multipart message in MIME format. --=_alternative 000D1B7C85256FF7_= Content-Type: text/plain; charset="US-ASCII" Can someone clarify my doubt regarding this.. ----- Forwarded by Udit Goyal/C/US/3Com on 05/03/2005 10:21 PM ----- Udit Goyal/C/US/3Com 05/02/2005 03:00 PM To Venkatesh cc SIP Implementors , sip-implementors-bounces@cs.columbia.edu Subject Re: [Sip-implementors] Fw: Via header I got your point, but just want to know, is there any standard way for NAT to behave when i create bindings, because when the INVITE request having different UDP source port than the sent-by field port arrives at NAT, it change the IP address and port of the request and send it to proxy. While creating that binding, which port it uses, the one present in sent-by field or the source UDP port.. because it had to send the response back to UA usign the same binding. If it uses sent-by field port, it will work fine othwerwise it will not work if UAC is not listening on ephemeral UDP port.. I feel it uses the sent-by field for this purpose, I am not sure if it is implementation specific ? Even in given example of RFC 3581, .... A client sends an INVITE to a proxy server which looks like, in part: INVITE sip:user@example.com SIP/2.0 Via: SIP/2.0/UDP 10.1.1.1:4540;rport;branch=z9hG4bKkjshdyff This INVITE is sent with a source port of 4540 and a source IP address of 10.1.1.1. The proxy is at 192.0.2.2 (proxy.example.com), listening on both port 5060 and 5070. The client sends the request to port 5060. The request passes through a NAT on the way to the proxy, so that the source IP address appears as 192.0.2.1 and the source port as 9988. The proxy forwards the request, but not before appending a value to the "rport" parameter in the proxied request:. .... ..... SIP/2.0 200 OK Via: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988 ;branch=z9hG4bKkjshdyff This packet matches the binding created by the initial request. Therefore, the NAT rewrites the destination address of this packet back to 10.1.1.1, and the destination port back to 4540. It forwards this response to the client, which is listening for the response on that address and port. The client properly receives the response. Thanks, Udit Venkatesh Sent by: sip-implementors-bounces@cs.columbia.edu 05/02/2005 02:05 PM Please respond to Venkatesh To Udit Goyal/C/US/3Com@3Com cc sip-implementors-bounces@cs.columbia.edu, SIP Implementors Subject Re: [Sip-implementors] Fw: Via header It is the clients responsibility to determine if it is behind a NAT/Firewall before sending out the INVITE (not the Proxy based on IP/port comparison). If the client figures it is behind a NAT/Firewall that requires symmetic response traversal (think STUN lets you figure this out), you include the "rport" parameter in the Via header using the procedures outlined in RFC 3581. Should the proxy that receive this message 'understand' the rport extension, it will add the port information from which request originated against the 'rport' header. When responses are forwarded, it will send it to the IP in the Via (received/maddr et al) and the port in the "rport" value. Venkatesh On 5/2/05, Udit_Goyal@3com.com wrote: > > > But from proxy side, how will it know if firewall is there, so that it can > add rport parameter to that, > to know if firewall is there, it needs to compare the IP address and port > in sent-by field with the source UDP port and and address, > > adn if it does nto match, then this means firewall is there, and it can > add rport paramter with the port address and received parameter. > > My query was to determine that firewall is there, do you need both IP > address and port to be different ?? > because in case of ephemeral port, only ports are different, IP addresses > are same.. > > I am not able figure it out in RFC, if anybody can point me to that... > > Thanks, > Udit > > > > *Venkatesh * > Sent by: sip-implementors-bounces@cs.columbia.edu > > 05/02/2005 12:50 PM Please respond to > Venkatesh > > To > Udit Goyal/C/US/3Com@3Com cc > SIP Implementors , > sip-implementors-bounces@cs.columbia.edu > Subject > Re: [Sip-implementors] Fw: Via header > > > > > > I dont believe that is true. You can use an ephermel port while sending > messages on UDP and can expect responses to arrive on the default > port/port > on which you are listening. You only need to listen on the default ports. > The above holds true > * as long as you dont include an "rport" parameter (that tells the proxy > to > record the port on which you sent the request for response routing). > * specify a port number other than the default port where you want your > response sent. > Responses are sent to the IP address/port in the Via header to the default > port (so for UDP, responses will be sent to 5060). > > Venkatesh > > On 5/2/05, Udit_Goyal@3com.com wrote: > > > > Hi, > > > > Yaah even I perceive the same behaviour from the RFC pint of view. > > > > So basically it boils down to either use the same socket for sending and > > listening i.e. 5060 port > > > > becoz if you are using ephemeral UDP port, then you have to listen for > > reponses on same port, which is not what an applciation desired for the > > usage of ephemeral port.. because you can use multiple socket for > sendign > > the request and hence creating multiple ephemeral port which server > would > > not like to listen to.. > > > > Cant we have some paramter in Via header, may be "sender-port" which > > application set it to ephemeral port, > > so that if proxy receives this request, it checks if "sender-port" is > > present, it matches it with the UDP source port for firewall related > > checks, > > otherwise it checks with the sent-by filed. > > > > For sending responses, behaviour can be same as it is now.. > > > > Regards, > > Udit > > > > Wayne.Davies@mmv.vic.gov.au > > Sent by: sip-implementors-bounces@cs.columbia.edu > > 05/02/2005 03:09 AM > > > > To > > Udit Goyal/C/US/3Com@3Com > > cc > > sip-implementors-bounces@cs.columbia.edu, SIP Implementors > > > > Subject > > Re: [Sip-implementors] Fw: Via header > > > > > > Udit, > > I was waiting for someone more savvy than me to answer this one but I > > will just have to dissapoint. I had a read of relevant section in 3261 > and > > 3263. > > > > If the UAC populated the sent-by field with IP address and not a port > > that this will result in the UAS processing this to use the default port > > for the transport - so for your example over UDP = 5060. The UAC could > > have > > included the ephemeral port in the sent-by field and regardless - yes, > it > > needs to listen on it. > > > > I hope the above is accurate, Wayne. > > > > Query from Udit: > > **************************************** > > > > Can anybody please comment on this query.. > > ----- Forwarded by Udit Goyal/C/US/3Com on 05/01/2005 10:05 PM ----- > > > > Udit Goyal/C/US/3Com > > 04/28/2005 12:15 PM > > > > To > > SIP Implementors, SIP IETF > > cc > > > > Subject > > Via header > > > > Hi, > > > > Conside a case where UAC uses different UDP sockets for listening and > > sending SIP requests, > > i.e it is listening on port 5060, but when it sends request, it uses > > ephemeral UDP port. > > > > When this UAC sends INVITE request, it will contain Via header > containing > > the IP address and port number 5060 in sent-by field > > But the UDP source port number will be different (IP address will be > same) > > as it had used UDP ephemeral port for sending that request. > > > > Now when proxy receives this request, it will check for IP address, > since > > it is same it will not add "received" parameter. However, port numbers > are > > different, should it add "rport" parameter ?? but this is not case of > > firewall.. > > or proxy only check for port when the IP addresses are different ?? > > > > Also, it seems that is it necessary for UA to listen on the same socket > > from which requests sent ?? > > > > Regards, > > Udit > > _______________________________________________ > > Sip-implementors mailing list > > Sip-implementors@cs.columbia.edu > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > ********************************************************************** > > Any personal or sensitive information contained in this email and > > attachments must be handled in accordance with the Victorian Information > > Privacy Act 2000, the Health Records Act 2001 or the Privacy Act 1988 > > (Commonwealth), as applicable. > > > > This email, including all attachments, is confidential. If you are not > > the > > intended recipient, you must not disclose, distribute, copy or use the > > information contained in this email or attachments. Any confidentiality > > or > > privilege is not waived or lost because this email has been sent to you > in > > error. If you have received it in error, please let us know by reply > > email, delete it from your system and destroy any copies. > > ********************************************************************** > > > > _______________________________________________ > > Sip-implementors mailing list > > Sip-implementors@cs.columbia.edu > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > _______________________________________________ > > Sip-implementors mailing list > > Sip-implementors@cs.columbia.edu > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors --=_alternative 000D1B7C85256FF7_= Content-Type: text/html; charset="US-ASCII"
Can someone clarify my doubt regarding this..

----- Forwarded by Udit Goyal/C/US/3Com on 05/03/2005 10:21 PM -----
Udit Goyal/C/US/3Com

05/02/2005 03:00 PM

To
Venkatesh <vvenkatar@gmail.com>
cc
SIP Implementors <sip-implementors@cs.columbia.edu>, sip-implementors-bounces@cs.columbia.edu
Subject
Re: [Sip-implementors] Fw: Via headerLink




I got your point,
but just want to know,

is there any standard way for NAT to behave when i create bindings,

because when the INVITE request having different UDP source port than the sent-by field port arrives at NAT, it change the IP address and port of the request and send it to proxy. While creating that binding, which port it uses, the one present in sent-by field or the source UDP port.. because it had to send the response back to UA usign the same binding.
If it uses sent-by field port, it will work fine othwerwise it will not work if UAC is not listening on ephemeral UDP port..

I feel it uses the sent-by field for this purpose, I am not sure if it is implementation specific ?


Even in given example of  RFC 3581,

....
 A client sends an INVITE to a proxy server which looks like, in part:

   INVITE sip:user@example.com SIP/2.0
   Via: SIP/2.0/UDP 10.1.1.1:4540;rport;branch=z9hG4bKkjshdyff

   This INVITE is sent with a source port of 4540 and a source IP
   address of 10.1.1.1.  The proxy is at 192.0.2.2 (proxy.example.com),
   listening on both port 5060 and 5070.  The client sends the request
   to port 5060.  The request passes through a NAT on the way to the
   proxy, so that the source IP address appears as 192.0.2.1 and the
   source port as 9988.  The proxy forwards the request, but not before
   appending a value to the "rport" parameter in the proxied request:.
....
.....
   SIP/2.0 200 OK
   Via: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988
    ;branch=z9hG4bKkjshdyff

   This packet matches the binding created by the initial request.
   Therefore, the NAT rewrites the destination address of this packet
   back to 10.1.1.1, and the destination port back to 4540.  It forwards
   this response to the client, which is listening for the response on
   that address and port.  The client properly receives the response.

Thanks,
Udit




Venkatesh <vvenkatar@gmail.com>
Sent by: sip-implementors-bounces@cs.columbia.edu

05/02/2005 02:05 PM
Please respond to
Venkatesh <vvenkatar@gmail.com>
To
Udit Goyal/C/US/3Com@3Com
cc
sip-implementors-bounces@cs.columbia.edu, SIP Implementors <sip-implementors@cs.columbia.edu>
Subject
Re: [Sip-implementors] Fw: Via header





It is the clients responsibility to determine if it is behind a NAT/Firewall
before sending out the INVITE (not the Proxy based on IP/port comparison).
If the client figures it is behind a NAT/Firewall that requires symmetic
response traversal (think STUN lets you figure this out), you include the
"rport" parameter in the Via header using the procedures outlined in RFC
3581. Should the proxy that receive this message 'understand' the rport
extension, it will add the port information from which request originated
against the 'rport' header. When responses are forwarded, it will send it to
the IP in the Via (received/maddr et al) and the port in the "rport" value.
Venkatesh
On 5/2/05, Udit_Goyal@3com.com <Udit_Goyal@3com.com> wrote:
>
>
> But from proxy side, how will it know if firewall is there, so that it can
> add rport parameter to that,
> to know if firewall is there, it needs to compare the IP address and port
> in sent-by field with the source UDP port and and address,
>
> adn if it does nto match, then this means firewall is there, and it can
> add rport paramter with the port address and received parameter.
>
> My query was to determine that firewall is there, do you need both IP
> address and port to be different ??
> because in case of ephemeral port, only ports are different, IP addresses
> are same..
>
> I am not able figure it out in RFC, if anybody can point me to that...
>
> Thanks,
> Udit
>
>
>
>   *Venkatesh <vvenkatar@gmail.com>*
> Sent by: sip-implementors-bounces@cs.columbia.edu
>
> 05/02/2005 12:50 PM   Please respond to
> Venkatesh <vvenkatar@gmail.com>
>
>    To
> Udit Goyal/C/US/3Com@3Com  cc
> SIP Implementors <sip-implementors@cs.columbia.edu>,
> sip-implementors-bounces@cs.columbia.edu
>  Subject
> Re: [Sip-implementors] Fw: Via header
>
>
>
>
>
> I dont believe that is true. You can use an ephermel port while sending
> messages on UDP and can expect responses to arrive on the default
> port/port
> on which you are listening. You only need to listen on the default ports.
> The above holds true
> * as long as you dont include an "rport" parameter (that tells the proxy
> to
> record the port on which you sent the request for response routing).
> * specify a port number other than the default port where you want your
> response sent.
> Responses are sent to the IP address/port in the Via header to the default
> port (so for UDP, responses will be sent to 5060).
>
> Venkatesh
>
> On 5/2/05, Udit_Goyal@3com.com <Udit_Goyal@3com.com> wrote:
> >
> > Hi,
> >
> > Yaah even I perceive the same behaviour from the RFC pint of view.
> >
> > So basically it boils down to either use the same socket for sending and
> > listening i.e. 5060 port
> >
> > becoz if you are using ephemeral UDP port, then you have to listen for
> > reponses on same port, which is not what an applciation desired for the
> > usage of ephemeral port.. because you can use multiple socket for
> sendign
> > the request and hence creating multiple ephemeral port which server
> would
> > not like to listen to..
> >
> > Cant we have some paramter in Via header, may be "sender-port" which
> > application set it to ephemeral port,
> > so that if proxy receives this request, it checks if "sender-port" is
> > present, it matches it with the UDP source port for firewall related
> > checks,
> > otherwise it checks with the sent-by filed.
> >
> > For sending responses, behaviour can be same as it is now..
> >
> > Regards,
> > Udit
> >
> > Wayne.Davies@mmv.vic.gov.au
> > Sent by: sip-implementors-bounces@cs.columbia.edu
> > 05/02/2005 03:09 AM
> >
> > To
> > Udit Goyal/C/US/3Com@3Com
> > cc
> > sip-implementors-bounces@cs.columbia.edu, SIP Implementors
> > <sip-implementors@cs.columbia.edu>
> > Subject
> > Re: [Sip-implementors] Fw: Via header
> >
> >
> > Udit,
> > I was waiting for someone more savvy than me to answer this one but I
> > will just have to dissapoint. I had a read of relevant section in 3261
> and
> > 3263.
> >
> > If the UAC populated the sent-by field with IP address and not a port
> > that this will result in the UAS processing this to use the default port
> > for the transport - so for your example over UDP = 5060. The UAC could
> > have
> > included the ephemeral port in the sent-by field and regardless - yes,
> it
> > needs to listen on it.
> >
> > I hope the above is accurate, Wayne.
> >
> > Query from Udit:
> > ****************************************
> >
> > Can anybody please comment on this query..
> > ----- Forwarded by Udit Goyal/C/US/3Com on 05/01/2005 10:05 PM -----
> >
> > Udit Goyal/C/US/3Com
> > 04/28/2005 12:15 PM
> >
> > To
> > SIP Implementors, SIP IETF
> > cc
> >
> > Subject
> > Via header
> >
> > Hi,
> >
> > Conside a case where UAC uses different UDP sockets for listening and
> > sending SIP requests,
> > i.e it is listening on port 5060, but when it sends request, it uses
> > ephemeral UDP port.
> >
> > When this UAC sends INVITE request, it will contain Via header
> containing
> > the IP address and port number 5060 in sent-by field
> > But the UDP source port number will be different (IP address will be
> same)
> > as it had used UDP ephemeral port for sending that request.
> >
> > Now when proxy receives this request, it will check for IP address,
> since
> > it is same it will not add "received" parameter. However, port numbers
> are
> > different, should it add "rport" parameter ?? but this is not case of
> > firewall..
> > or proxy only check for port when the IP addresses are different ??
> >
> > Also, it seems that is it necessary for UA to listen on the same socket
> > from which requests sent ??
> >
> > Regards,
> > Udit
> > _______________________________________________
> > Sip-implementors mailing list
> > Sip-implementors@cs.columbia.edu
> > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> >
> > **********************************************************************
> > Any personal or sensitive information contained in this email and
> > attachments must be handled in accordance with the Victorian Information
> > Privacy Act 2000, the Health Records Act 2001 or the Privacy Act 1988
> > (Commonwealth), as applicable.
> >
> > This email, including all attachments, is confidential. If you are not
> > the
> > intended recipient, you must not disclose, distribute, copy or use the
> > information contained in this email or attachments. Any confidentiality
> > or
> > privilege is not waived or lost because this email has been sent to you
> in
> > error. If you have received it in error, please let us know by reply
> > email, delete it from your system and destroy any copies.
> > **********************************************************************
> >
> > _______________________________________________
> > Sip-implementors mailing list
> > Sip-implementors@cs.columbia.edu
> > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> > _______________________________________________
> > Sip-implementors mailing list
> > Sip-implementors@cs.columbia.edu
> > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> >
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@cs.columbia.edu
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
--=_alternative 000D1B7C85256FF7_=-- --===============1401016948== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1401016948==-- From sip-bounces@ietf.org Wed May 04 09:10:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTJe1-0006ql-FH; Wed, 04 May 2005 09:10:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTJdz-0006pp-Qm for sip@megatron.ietf.org; Wed, 04 May 2005 09:10:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04116 for ; Wed, 4 May 2005 09:10:25 -0400 (EDT) Received: from inno-exchange.innovaphone.com ([145.253.157.4] helo=innovaphone.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTJs4-0005fd-5Q for sip@ietf.org; Wed, 04 May 2005 09:25:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [Sip] Xiao Peng Chen is out of the office. Date: Wed, 4 May 2005 15:11:37 +0200 Message-ID: <0E6CC1D4D38A5742930CE896A653477AB6ADAB@inno-exchange.innovaphone.sifi> Thread-Topic: [Sip] Xiao Peng Chen is out of the office. Thread-Index: AcVQqqJAj+Q2ofcdRv6jdJRH4jpqGg== From: "Thomas Ackermann" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Content-Transfer-Encoding: quoted-printable X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Have a nice holiday! (;-) Thomas _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 04 09:11:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTJek-0006wI-2e; Wed, 04 May 2005 09:11:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTJei-0006wC-Gi for sip@megatron.ietf.org; Wed, 04 May 2005 09:11:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04233 for ; Wed, 4 May 2005 09:11:10 -0400 (EDT) Received: from inno-exchange.innovaphone.com ([145.253.157.4] helo=innovaphone.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTJso-0005iR-D1 for sip@ietf.org; Wed, 04 May 2005 09:25:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [Sip] Event Package for Registrations (RFC-3680) Date: Wed, 4 May 2005 15:12:24 +0200 Message-ID: <0E6CC1D4D38A5742930CE896A653477AE1AA5B@inno-exchange.innovaphone.sifi> Thread-Topic: [Sip] Event Package for Registrations (RFC-3680) Thread-Index: AcVQqr4PcoX030jLRviCYLt/UW7Avw== From: "Thomas Ackermann" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi together, I looked for a way to notify a SIP client about its unregistration before the expire time elapsed. Now I found "Event Package for Registrations" (RFC-3680). OK, fine, this is what I needed. But what the hell is XML doing there? SIP is a simple text based protocol (inherited from HTTP). The SDP for session negotiation as well. Everything was perfectly straight in the early days. And now with every little extension there comes another way of content encoding. Why do you have to have an XML engine everywhere you stand? Especially for things that really do NOT need XML due to very non-complexity? Why not simply defining it this way: #NOTIFY ... #Event: reg #Content-Type: application/reginfo #Content-Length: xxx # #state=3Dregistered|unregistered|etc. just like outband DTMF transmission: #INFO ... #Content-Type: application/dtmf-relay #Content-Length: xxx # #Signal=3D1 #Duration=3D160 or like session negotiation: #INVITE ... #Content-Type: application/sdp #Content-Length: xxx # #v=3D0 #... Best regards, Thomas _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 04 10:20:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTKjp-0003UZ-LE; Wed, 04 May 2005 10:20:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTKjn-0003UU-U6 for sip@megatron.ietf.org; Wed, 04 May 2005 10:20:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13325 for ; Wed, 4 May 2005 10:20:29 -0400 (EDT) Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTKxt-0007wF-RR for sip@ietf.org; Wed, 04 May 2005 10:35:06 -0400 Received: from keywest (hide.pingtel.com [65.220.123.2]) by mail.pingtel.com (Postfix) with SMTP id E703D6C01D for ; Wed, 4 May 2005 10:20:28 -0400 (EDT) From: "Dale Worley" To: Subject: RE: [Sip] Event Package for Registrations (RFC-3680) Date: Wed, 4 May 2005 10:16:38 -0400 Message-ID: <005101c550b3$e35d5580$6a01010a@keywest> 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.2910.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal In-Reply-To: <0E6CC1D4D38A5742930CE896A653477AE1AA5B@inno-exchange.innovaphone.sifi> X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > From: Thomas Ackermann > > I looked for a way to notify a SIP client > about its unregistration before the expire time elapsed. > Now I found "Event Package for Registrations" (RFC-3680). > > OK, fine, this is what I needed. > But what the hell is XML doing there? > SIP is a simple text based protocol (inherited from HTTP). > The SDP for session negotiation as well. > Everything was perfectly straight in the early days. > And now with every little extension there comes another way > of content encoding. > > Why do you have to have an XML engine everywhere you stand? > Especially for things that really do NOT need XML > due to very non-complexity? First, remember that if all you need to do is *generate* registration/unregistration NOTIFYs, then you can *write* the needed XML quite easily, it's just a text string with a number of substitutions. As to why XML is used, there are several reasons: - XML is well-understood and there are many parsers in existence. Thus, there is less work involved in creating a new XML-based format than would seem. - XML allows "structured" data. In this case, a notice consists of a list of registration notices, which each contain a number of contacts. A simple text-based format for such data quickly becomes much less simple when it tries to capture such information. - XML is extensible. It is understood how to add elements to XML structures in ways that are upward-compatible with processors of the old format. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 04 21:24:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTV6F-0005oA-TD; Wed, 04 May 2005 21:24:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTV6D-0005nv-P6 for sip@megatron.ietf.org; Wed, 04 May 2005 21:24:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05881 for ; Wed, 4 May 2005 21:24:17 -0400 (EDT) Received: from nyx.cair.du.edu ([130.253.1.60] helo=smtpout.cair.du.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTVKL-0001Pk-TI for sip@ietf.org; Wed, 04 May 2005 21:39:00 -0400 Received: from conversion-daemon.smtpout.cair.du.edu by smtpout.cair.du.edu (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) id <0IFZ00J01SE9K0@smtpout.cair.du.edu> for sip@ietf.org; Wed, 04 May 2005 19:24:05 -0600 (MDT) Received: from du.edu (hope.cair.du.edu [130.253.1.58]) by smtpout.cair.du.edu (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0IFZ00IM9T85U0@smtpout.cair.du.edu> for sip@ietf.org; Wed, 04 May 2005 19:24:05 -0600 (MDT) Received: from [130.253.1.60] by mailstore0.cair.du.edu (mshttpd); Wed, 04 May 2005 19:24:05 -0600 Date: Wed, 04 May 2005 19:24:05 -0600 From: "Jan A. Borrego" Subject: [Sip] SIP 3261 Standard Track Status To: sip@ietf.org Message-id: <11ceed411cc614.11cc61411ceed4@du.edu> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.14 (built Mar 18 2003) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Content-Transfer-Encoding: 7BIT X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hello, I am a student at University of Denver doing research on SIP. I was wondering if anyone knows when SIP RFC 3261 (core spec)is up for review to move from the 'proposed' state to a 'draft' state. I see that 3261 is dated June 2002, and that a review may have been scheduled in Sept 2004, but I haven't found information beyond that. Since I would like to reference this in a paper, if you have a web link providing the status, that would be great. Thanks! Note: I am aware of the IETF 'newtrk' working group created to deal with disparity between the standards process and what is happening in the real world. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 05 09:58:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTgrp-0001Qp-Me; Thu, 05 May 2005 09:58:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTgro-0001OZ-Bc for sip@megatron.ietf.org; Thu, 05 May 2005 09:58:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28406 for ; Thu, 5 May 2005 09:58:13 -0400 (EDT) Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTh65-0003RZ-CJ for sip@ietf.org; Thu, 05 May 2005 10:13:03 -0400 Received: from keywest (hide.pingtel.com [65.220.123.2]) by mail.pingtel.com (Postfix) with SMTP id 274306C02C for ; Thu, 5 May 2005 09:58:07 -0400 (EDT) From: "Dale Worley" To: Subject: RE: [Sip] SIP 3261 Standard Track Status Date: Thu, 5 May 2005 09:54:12 -0400 Message-ID: <001e01c55179$ebe05f10$6a01010a@keywest> 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 CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <11ceed411cc614.11cc61411ceed4@du.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > From: Jan A. Borrego > > Hello, I am a student at University of Denver doing research > on SIP. I was wondering if anyone knows when SIP RFC 3261 > (core spec)is up for review to move from the 'proposed' state > to a 'draft' state. Well, the current statuses are listed in http://www.rfc-editor.org/rfcxx00.html, and it still lists RFC 3261 as "proposed standard". Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 05 19:05:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTpPY-0001cH-2N; Thu, 05 May 2005 19:05:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTpPV-0001cC-W1 for sip@megatron.ietf.org; Thu, 05 May 2005 19:05:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05101 for ; Thu, 5 May 2005 19:05:34 -0400 (EDT) From: Pierre.Lacour@alcatel.fr Received: from smail.alcatel.fr ([64.208.49.165]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTpds-0008EB-Pl for sip@ietf.org; Thu, 05 May 2005 19:20:30 -0400 Received: from frmail15.netfr.alcatel.fr (frmail15.netfr.alcatel.fr [155.132.251.15]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id j45N0XLg004236 for ; Fri, 6 May 2005 01:05:25 +0200 To: sip@ietf.org Message-ID: Date: Fri, 6 May 2005 01:01:50 +0200 X-MIMETrack: Serialize by Router on FRMAIL15/FR/ALCATEL(Release 5.0.12HF788 | September 23, 2004) at 05/06/2005 01:05:25 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 0.3 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [Sip] Pierre LACOUR/FR/ALCATEL is out of the office. X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I will be out of the office starting 05/05/2005 and will not return until 09/05/2005. I will respond to your message when I return _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 06 11:14:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU4XH-0004mI-CL; Fri, 06 May 2005 11:14:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU4XC-0004l5-Or; Fri, 06 May 2005 11:14:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25295; Fri, 6 May 2005 11:14:32 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DU4lj-0002nX-3l; Fri, 06 May 2005 11:29:35 -0400 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1DU4XB-00061e-Kc; Fri, 06 May 2005 11:14:33 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Fri, 06 May 2005 11:14:33 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: sip@ietf.org Subject: [Sip] Last Call: 'Communications Resource Priority for the Session Initiation Protocol (SIP)' to Proposed Standard X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org The IESG has received a request from the Session Initiation Protocol WG to consider the following documents: - 'Communications Resource Priority for the Session Initiation Protocol (SIP) ' as a Proposed Standard - 'Extending the Session Initiation Protocol Reason Header for Preemption Events ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-05-20. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-resource-priority-08.txt http://www.ietf.org/internet-drafts/draft-ietf-sipping-reason-header-for-preemption-02.txt _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 06 15:44:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU8kU-0003QQ-Q9; Fri, 06 May 2005 15:44:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU8kQ-0003Pe-MT; Fri, 06 May 2005 15:44:30 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29078; Fri, 6 May 2005 15:44:28 -0400 (EDT) Message-Id: <200505061944.PAA29078@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 06 May 2005 15:44:28 -0400 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-identity-05.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP) Author(s) : J. Peterson, C. Jennings Filename : draft-ietf-sip-identity-05.txt Pages : 40 Date : 2005-5-6 The existing security mechanisms in the Session Initiation Protocol are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP messages. It does so by defining two new SIP header fields, Identity, for conveying a signature used for validating the identity, and Identity-Info, for conveying a reference to the certificate of the signer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-identity-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-identity-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-identity-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-6153250.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-identity-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-identity-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-6153250.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Tue May 10 04:36:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVQDl-0002FA-Np; Tue, 10 May 2005 04:36:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTJR6-0002wv-CU for sip@megatron.ietf.org; Wed, 04 May 2005 08:57:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02783 for ; Wed, 4 May 2005 08:57:06 -0400 (EDT) Received: from inno-exchange.innovaphone.com ([145.253.157.4] helo=innovaphone.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTJfB-0005J3-8h for sip@ietf.org; Wed, 04 May 2005 09:11:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [Sip] Event Package for Registrations (RFC-3680) Date: Wed, 4 May 2005 14:58:19 +0200 Message-ID: <0E6CC1D4D38A5742930CE896A653477AB6ADAA@inno-exchange.innovaphone.sifi> Thread-Topic: [Sip] Event Package for Registrations (RFC-3680) Thread-Index: AcVQqMaIbSAa207SSgqjyO2GYggaPA== From: "Thomas Ackermann" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 10 May 2005 04:36:04 -0400 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi together, I looked for a way to notify a SIP client about its unregistration before the expire time elapsed. Now I found "Event Package for Registrations" (RFC-3680). OK, fine, this is what I needed. But what the hell is XML doing there? SIP is a simple text based protocol (inherited from HTTP). The SDP for session negotiation as well. Everything was perfectly straight in the early days. And now with every little extension there comes another way of content encoding. Why do you have to have an XML engine everywhere you stand? Especially for things that really do NOT need XML due to very non-complexity? Why not simply defining it this way: #NOTIFY ... #Event: reg #Content-Type: application/reginfo #Content-Length: xxx # #state=3Dregistered|unregistered|etc. just like outband DTMF transmission: #INFO ... #Content-Type: application/dtmf-relay #Content-Length: xxx # #Signal=3D1 #Duration=3D160 or like session negotiation: #INVITE ... #Content-Type: application/sdp #Content-Length: xxx # #v=3D0 #... Best regards, Thomas _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 10 11:55:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVX54-0005qg-QH; Tue, 10 May 2005 11:55:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVX53-0005qH-Hh for sip@megatron.ietf.org; Tue, 10 May 2005 11:55:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07798 for ; Tue, 10 May 2005 11:55:31 -0400 (EDT) Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVXKN-0001A7-U6 for sip@ietf.org; Tue, 10 May 2005 12:11:25 -0400 Received: from keywest (hide.pingtel.com [65.220.123.2]) by mail.pingtel.com (Postfix) with SMTP id 061056C01E for ; Tue, 10 May 2005 11:55:31 -0400 (EDT) From: "Dale Worley" To: "Sip (E-mail)" Date: Tue, 10 May 2005 11:55:14 -0400 Message-ID: <007c01c55578$ab800ee0$6a01010a@keywest> 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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Subject: [Sip] RFC 3840 "feature tags" as URI parameters X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I get the feeling from RFC 3840 that the feature tags should be removed from any URI before it is used for routing requests. Do you think that is correct? Is the presence of these parameters why the dialog event package goes to the trouble of splitting URI parameters from the userinfo/hostport part of the URI? (See section 4.1.6.2 of draft-ietf-sipping-dialog-package-06 regarding the element.) Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 10 15:18:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVaFI-0008FI-E1; Tue, 10 May 2005 15:18:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVaFG-0008F9-Cz for sip@megatron.ietf.org; Tue, 10 May 2005 15:18:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04929 for ; Tue, 10 May 2005 15:18:16 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVaUc-00088B-94 for sip@ietf.org; Tue, 10 May 2005 15:34:11 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 10 May 2005 12:18:08 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j4AJHvrG029955; Tue, 10 May 2005 12:18:05 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 10 May 2005 15:17:57 -0400 Received: from cisco.com ([10.21.90.47]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 10 May 2005 15:17:54 -0400 Message-ID: <428108E3.8020703@cisco.com> Date: Tue, 10 May 2005 15:17:55 -0400 From: Paul Kyzivat 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: Dale Worley Subject: Re: [Sip] RFC 3840 "feature tags" as URI parameters References: <007c01c55578$ab800ee0$6a01010a@keywest> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 May 2005 19:17:54.0458 (UTC) FILETIME=[F76D3FA0:01C55594] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: "Sip \(E-mail\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dale Worley wrote: > I get the feeling from RFC 3840 that the feature tags should be removed from > any URI before it is used for routing requests. Do you think that is > correct? I just responded to you on sip-implementors about this same question. I don't think this is either expected or forbidden. IMO the least surprising behavior would be to leave them in. > Is the presence of these parameters why the dialog event package goes to the > trouble of splitting URI parameters from the userinfo/hostport part of the > URI? (See section 4.1.6.2 of draft-ietf-sipping-dialog-package-06 regarding > the element.) Don't know. Paul > Dale > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 sip-bounces@ietf.org Wed May 11 17:37:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVyt3-0001T5-FV; Wed, 11 May 2005 17:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVyt1-0001Ss-Pp for sip@megatron.ietf.org; Wed, 11 May 2005 17:36:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28513 for ; Wed, 11 May 2005 17:36:56 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVz8c-0002HM-Jl for sip@ietf.org; Wed, 11 May 2005 17:53:07 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j4BLahq24761 for ; Wed, 11 May 2005 17:36:43 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 11 May 2005 17:36:44 -0400 Message-ID: <62100BCDC5B04C4C84C2F95AD22E03A974E67E@ztcfhxm0.corp.nortel.com> From: "Tao Wan" To: "'sip@ietf.org'" Date: Wed, 11 May 2005 17:36:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.5 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Subject: [Sip] Minor comments on "draft-ietf-sip-identity-05" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0238600616==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org 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. --===============0238600616== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55671.54673FB2" 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_01C55671.54673FB2 Content-Type: text/plain > I quickly went through the nice draft titled "Enhancements for > Authenticated Identity Management in the Session Initiation Protocol > (SIP)" dated March ? 2005 (expires September 2, 2005). Here are some minor > editorial comments and questions which may or may not have been addressed. > > > Thanks, > > Tao Wan > > page 4, para 2, line 4: "if you are can prove ..." ==> "If you can prove" > page 6, para 5, line 1: "as the holder the private key" ==> "as the holder > of the private key" > page 13, last para, second last line: "The result in placed int the > Identity ..." ==> "The result is placed in the identity ..." > page 14, para 1, line 1: "Note on the use of 'rsa-sha1' ..." ==> "Note on > the use of 'rsa-sha1' with 1024-bit RSA signing key..." ??? > page 17, para 1, line 1: "in authenticates Alice ..." ==> "it > authenticates Alice" > page 18, para 1, line 3: "the URL the Identitiy-Info..." ==> "the URL > carried in the Identity-Info..." > page 23, para 1, line 9: "This result of this is..." ==> "The result of > this is..." > page 24, para 3, line 5: "men-in-the-middle is ..." ==> "man-in-the-middle > is ..." (unless you mean there are more than one man in the middle :) > > Section 4 (Requirements) > > bullet 2: What exactly does network lookup mean here? Dereference of an > Identity-Info may involve DNS lookups. Is that considered as network > lookup? If yes, this requirement is actually not met. > > bullet 3: "User agents that hold certificates on behalf of their user > ...". Do you mean "User agents that hold private keys on behalf of their > user .."? There are several places where a certificate may mean a private > key, e.g., > page 13, last para, line 1-2: "it MUST be hashed and signed with the > certificate for the domain". > > Section 10 (Header Syntax) > > page 14, para 2, line 2: "either an HTTP or HTTPS URI which ...". > Since a public key certificate is self integrity protected and does not > need confidentiality, is there any reason (other than flexibility) why > HTTPS will be needed? Since all examples given in section 11 use https, it > makes me wonder there may be some reason I am not aware of. ------_=_NextPart_001_01C55671.54673FB2 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Minor comments on = "draft-ietf-sip-identity-05"

I quickly went through the nice draft = titled "Enhancements for Authenticated Identity Management in the = Session Initiation Protocol (SIP)" dated March ? 2005 (expires = September 2, 2005). Here are some minor editorial comments and = questions which may or may not have been addressed.

Thanks,

Tao Wan

page 4, para 2, line 4: "if you = are can prove ..." =3D=3D> "If you can prove"
page 6, para 5, line 1: "as the = holder the private key" =3D=3D> "as the holder of the = private key"
page 13, last para, second last line: = "The result in placed int the Identity ..." =3D=3D> = "The result is placed in the identity ..."

page 14, para 1, line 1: "Note on = the use of 'rsa-sha1' ..." =3D=3D> "Note on the use of = 'rsa-sha1' with 1024-bit RSA signing key..." ???

page 17, para 1, line 1: "in = authenticates Alice ..." =3D=3D> "it authenticates = Alice"
page 18, para 1, line 3: "the = URL the Identitiy-Info..." =3D=3D> "the URL carried in the = Identity-Info..."
page 23, para 1, line 9: "This = result of this is..." =3D=3D> "The result of this = is..."
page 24, para 3, line 5: = "men-in-the-middle is ..." =3D=3D> "man-in-the-middle = is ..." (unless you mean there are more than one man in the middle = :)

Section 4 (Requirements)

bullet 2: What exactly does network = lookup mean here?  Dereference of an Identity-Info may involve DNS = lookups. Is that considered as   network lookup? If yes, this = requirement is actually not met.

bullet 3: "User agents that hold = certificates on behalf of their user ...". Do you mean "User = agents that hold private keys on behalf of their user  .."? = There are several places where a certificate may mean a private key, = e.g.,

page 13, last para, line 1-2: "it = MUST be hashed and signed with the certificate for the = domain".

Section 10 (Header Syntax)

page 14, para 2, line 2: "either = an HTTP or HTTPS URI which ...".
Since a public key certificate is = self integrity protected and does not need confidentiality, is there = any reason (other than flexibility) why  HTTPS will be needed? = Since all examples given in section 11 use https, it makes me wonder = there may be some reason I am not aware of.

------_=_NextPart_001_01C55671.54673FB2-- --===============0238600616== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0238600616==-- From sip-bounces@ietf.org Wed May 11 19:10:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW0Lf-0001SE-4c; Wed, 11 May 2005 19:10:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW0Ld-0001Rt-63 for sip@megatron.ietf.org; Wed, 11 May 2005 19:10:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07932 for ; Wed, 11 May 2005 19:10:33 -0400 (EDT) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW0bE-0008B0-Ia for sip@ietf.org; Wed, 11 May 2005 19:26:45 -0400 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id j4BN9AKD009665; Wed, 11 May 2005 23:09:10 GMT Received: from stntexch03.cis.neustar.com ([10.31.13.45]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 May 2005 19:09:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 11 May 2005 19:09:09 -0400 Message-ID: <24EAE5D4448B9D4592C6D234CBEBD59701502E9F@stntexch03.cis.neustar.com> Thread-Topic: Minor comments on "draft-ietf-sip-identity-05" Thread-Index: AcVWboNBDc746hJRRRO3D7FEex3mxgADv+dw From: "Peterson, Jon" To: "Tao Wan" , X-OriginalArrivalTime: 11 May 2005 23:09:09.0913 (UTC) FILETIME=[70416890:01C5567E] X-Spam-Score: 0.6 (/) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f Cc: sip@ietf.org Subject: [Sip] RE: Minor comments on "draft-ietf-sip-identity-05" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0661585750==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0661585750== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5567E.6FF0E6C3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5567E.6FF0E6C3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Thanks for your reading of this document. The nits you've caught are = certainly very welcome. =20 Regarding the requirement concerning network lookups, it is true of = course that dereferencing the Identity-Info may entail a DNS lookup, or = it may not, if the verifier already holds the corresponding certificate. = The intent behind this requirement was to express something more along = the lines that a 'dialback' verificiation system was not a requirement = (where the verifier sends some SIP-layer message in the backwards = direction to which the caller would respond). Probably should be = clarified. =20 User agents that hold certificates on behalf of their users refers to = user agents that instantiate the authentication service role, and thus = hold a private/public key pair associated with a certificate. =20 Regarding the use of HTTPS, it is included just for flexibility - you = are correct that since the certificate is self-verifying, there is no = intrinsic need for HTTPS security properties when fetching a cert. =20 Jon Peterson NeuStar, Inc. -----Original Message----- From: Tao Wan [mailto:taowa@nortel.com] Sent: Wednesday, May 11, 2005 2:15 PM To: Peterson, Jon; 'fluffy@cisco.com' Cc: 'sip@ietf.org' Subject: Minor comments on "draft-ietf-sip-identity-05" I quickly went through the nice draft titled "Enhancements for = Authenticated Identity Management in the Session Initiation Protocol = (SIP)" dated March ? 2005 (expires September 2, 2005). Here are some = minor editorial comments and questions which may or may not have been = addressed.=20 Thanks,=20 Tao Wan=20 page 4, para 2, line 4: "if you are can prove ..." =3D=3D> "If you can = prove"=20 page 6, para 5, line 1: "as the holder the private key" =3D=3D> "as the = holder of the private key"=20 page 13, last para, second last line: "The result in placed int the = Identity ..." =3D=3D> "The result is placed in the identity ..." page 14, para 1, line 1: "Note on the use of 'rsa-sha1' ..." =3D=3D> = "Note on the use of 'rsa-sha1' with 1024-bit RSA signing key..." ??? page 17, para 1, line 1: "in authenticates Alice ..." =3D=3D> "it = authenticates Alice"=20 page 18, para 1, line 3: "the URL the Identitiy-Info..." =3D=3D> "the = URL carried in the Identity-Info..."=20 page 23, para 1, line 9: "This result of this is..." =3D=3D> "The result = of this is..."=20 page 24, para 3, line 5: "men-in-the-middle is ..." =3D=3D> = "man-in-the-middle is ..." (unless you mean there are more than one man = in the middle :) Section 4 (Requirements)=20 bullet 2: What exactly does network lookup mean here? Dereference of an = Identity-Info may involve DNS lookups. Is that considered as network = lookup? If yes, this requirement is actually not met.=20 bullet 3: "User agents that hold certificates on behalf of their user = ...". Do you mean "User agents that hold private keys on behalf of their = user .."? There are several places where a certificate may mean a = private key, e.g., page 13, last para, line 1-2: "it MUST be hashed and signed with the = certificate for the domain".=20 Section 10 (Header Syntax)=20 page 14, para 2, line 2: "either an HTTP or HTTPS URI which ...".=20 Since a public key certificate is self integrity protected and does not = need confidentiality, is there any reason (other than flexibility) why = HTTPS will be needed? Since all examples given in section 11 use https, = it makes me wonder there may be some reason I am not aware of. ------_=_NextPart_001_01C5567E.6FF0E6C3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Minor comments on "draft-ietf-sip-identity-05"
 
Thanks=20 for your reading of this document. The nits you've caught are certainly = very=20 welcome.
 
Regarding the requirement concerning network = lookups,=20 it is true of course that dereferencing the Identity-Info may entail a = DNS=20 lookup, or it may not, if the verifier already holds the corresponding=20 certificate. The intent behind this requirement was to express something = more=20 along the lines that a 'dialback' verificiation system was not a = requirement=20 (where the verifier sends some SIP-layer message in the backwards = direction to=20 which the caller would respond). Probably should be=20 clarified.
 
User=20 agents that hold certificates on behalf of their users refers to user = agents=20 that instantiate the authentication service role, and thus hold a = private/public=20 key pair associated with a certificate.
 
Regarding the use of HTTPS, it is included = just for=20 flexibility - you are correct that since the certificate is = self-verifying,=20 there is no intrinsic need for HTTPS security properties when = fetching=20 a cert.
 
Jon=20 Peterson
NeuStar, Inc.
-----Original Message-----
From: Tao Wan=20 [mailto:taowa@nortel.com]
Sent: Wednesday, May 11, 2005 2:15 = PM
To: Peterson, Jon; 'fluffy@cisco.com'
Cc:=20 'sip@ietf.org'
Subject: Minor comments on=20 "draft-ietf-sip-identity-05"


I quickly went through the nice draft = titled=20 "Enhancements for Authenticated Identity Management in the Session = Initiation=20 Protocol (SIP)" dated March ? 2005 (expires September 2, 2005). Here = are some=20 minor editorial comments and questions which may or may not have been=20 addressed.

Thanks,

Tao Wan

page 4, para 2, line 4: "if you are can = prove ..."=20 =3D=3D> "If you can prove"
page 6, para 5,=20 line 1: "as the holder the private key" =3D=3D> "as the holder of = the private=20 key"
page 13, last para, second = last line:=20 "The result in placed int the Identity ..." =3D=3D> "The result is = placed in=20 the identity ..."

page 14, para 1, line 1: "Note on the = use of=20 'rsa-sha1' ..." =3D=3D> "Note on the use of 'rsa-sha1' with = 1024-bit RSA=20 signing key..." ???

page 17, para 1, line 1: "in = authenticates Alice=20 ..." =3D=3D> "it authenticates Alice"
page=20 18, para 1, line 3: "the URL the Identitiy-Info..." =3D=3D> "the = URL carried in=20 the Identity-Info..."
page 23, = para 1, line=20 9: "This result of this is..." =3D=3D> "The result of this = is..."=20
page 24, para 3, line 5: = "men-in-the-middle is=20 ..." =3D=3D> "man-in-the-middle is ..." (unless you mean there are = more than=20 one man in the middle :)

Section 4 (Requirements)

bullet 2: What exactly does network = lookup mean=20 here?  Dereference of an Identity-Info may involve DNS lookups. = Is that=20 considered as   network lookup? If yes, this requirement is = actually=20 not met.

bullet 3: "User agents that hold = certificates on=20 behalf of their user ...". Do you mean "User agents that hold private = keys on=20 behalf of their user  .."? There are several places where a = certificate=20 may mean a private key, e.g.,

page 13, last para, line 1-2: "it MUST = be hashed=20 and signed with the certificate for the domain".

Section 10 (Header Syntax)

page 14, para 2, line 2: "either an = HTTP or HTTPS=20 URI which ...".
Since a public = key=20 certificate is self integrity protected and does not need = confidentiality, is=20 there any reason (other than flexibility) why  HTTPS will be = needed?=20 Since all examples given in section 11 use https, it makes me wonder = there may=20 be some reason I am not aware = of.

------_=_NextPart_001_01C5567E.6FF0E6C3-- --===============0661585750== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0661585750==-- From sip-bounces@ietf.org Thu May 12 01:58:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW6iR-0007Mr-EU; Thu, 12 May 2005 01:58:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW6iP-0007Mh-Ls for sip@megatron.ietf.org; Thu, 12 May 2005 01:58:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04719 for ; Thu, 12 May 2005 01:58:32 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW6y4-0004NB-6L for sip@ietf.org; Thu, 12 May 2005 02:14:45 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 11 May 2005 22:58:24 -0700 X-IronPort-AV: i="3.93,97,1115017200"; d="scan'208"; a="635787513:sNHT28205934" Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4C5wKPo012364; Wed, 11 May 2005 22:58:20 -0700 (PDT) Received: from [192.168.1.100] (che-vpn-cluster-1-210.cisco.com [10.86.240.210]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AJT18020; Wed, 11 May 2005 22:58:18 -0700 (PDT) Message-ID: <4282F07B.2060509@cisco.com> Date: Thu, 12 May 2005 01:58:19 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] RFC 3840 "feature tags" as URI parameters References: <007c01c55578$ab800ee0$6a01010a@keywest> <428108E3.8020703@cisco.com> In-Reply-To: <428108E3.8020703@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: "Sip \(E-mail\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Paul Kyzivat wrote: > > > Dale Worley wrote: > >> I get the feeling from RFC 3840 that the feature tags should be >> removed from >> any URI before it is used for routing requests. Do you think that is >> correct? > > > I just responded to you on sip-implementors about this same question. I > don't think this is either expected or forbidden. IMO the least > surprising behavior would be to leave them in. Perhaps I am missing some context here, but the rfc3840 feature tags are not URI parameters, they are contact header field parameters. Thus, they would never be part of a URI and thus never show up in either request URI or contact. Since routing happens on reuqest URI and contact, I dont understand the issue. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.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 sip-bounces@ietf.org Thu May 12 02:13:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW6wI-0002S5-6F; Thu, 12 May 2005 02:12:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW6wE-0002Qm-Ab for sip@megatron.ietf.org; Thu, 12 May 2005 02:12:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17608 for ; Thu, 12 May 2005 02:12:49 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW7Bs-0004ka-U2 for sip@ietf.org; Thu, 12 May 2005 02:29:02 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 11 May 2005 23:00:05 -0700 X-IronPort-AV: i="3.93,97,1115017200"; d="scan'208"; a="264144101:sNHT1737108182" Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4C603Po013210; Wed, 11 May 2005 23:00:04 -0700 (PDT) Received: from [192.168.1.100] (che-vpn-cluster-1-210.cisco.com [10.86.240.210]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AJT18036; Wed, 11 May 2005 23:00:02 -0700 (PDT) Message-ID: <4282F0E2.2040005@cisco.com> Date: Thu, 12 May 2005 02:00:02 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dale Worley Subject: Re: [Sip] SIP 3261 Standard Track Status References: <001e01c55179$ebe05f10$6a01010a@keywest> In-Reply-To: <001e01c55179$ebe05f10$6a01010a@keywest> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org There is no current plan to advance this to draft standard. -Jonathan R. Dale Worley wrote: >>From: Jan A. Borrego >> >>Hello, I am a student at University of Denver doing research >>on SIP. I was wondering if anyone knows when SIP RFC 3261 >>(core spec)is up for review to move from the 'proposed' state >>to a 'draft' state. > > > Well, the current statuses are listed in > http://www.rfc-editor.org/rfcxx00.html, and it still lists RFC 3261 as > "proposed standard". > > Dale > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.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 sip-bounces@ietf.org Thu May 12 13:49:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWHor-0002AM-Rm; Thu, 12 May 2005 13:49:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWHop-0002AG-OV for sip@megatron.ietf.org; Thu, 12 May 2005 13:49:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15485 for ; Thu, 12 May 2005 13:49:54 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWI4Y-0007yq-Gt for sip@ietf.org; Thu, 12 May 2005 14:06:13 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 12 May 2005 14:04:44 -0400 X-IronPort-AV: i="3.93,100,1115006400"; d="scan'208"; a="49058320:sNHT28594036" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4CHnEni024846; Thu, 12 May 2005 13:49:41 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 May 2005 13:49:39 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 May 2005 13:49:32 -0400 Message-ID: <42839733.2080801@cisco.com> Date: Thu, 12 May 2005 13:49:39 -0400 From: Paul Kyzivat 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 Subject: Re: [Sip] RFC 3840 "feature tags" as URI parameters References: <007c01c55578$ab800ee0$6a01010a@keywest> <428108E3.8020703@cisco.com> <4282F07B.2060509@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 May 2005 17:49:32.0052 (UTC) FILETIME=[F3C5CD40:01C5571A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: "Sip \(E-mail\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Johnathan, Yeah, duh. You are right. Can't really carry over contact header parameters to the R-URI. Paul Jonathan Rosenberg wrote: > > > Paul Kyzivat wrote: > >> >> >> Dale Worley wrote: >> >>> I get the feeling from RFC 3840 that the feature tags should be >>> removed from >>> any URI before it is used for routing requests. Do you think that is >>> correct? >> >> >> >> I just responded to you on sip-implementors about this same question. >> I don't think this is either expected or forbidden. IMO the least >> surprising behavior would be to leave them in. > > > Perhaps I am missing some context here, but the rfc3840 feature tags are > not URI parameters, they are contact header field parameters. Thus, they > would never be part of a URI and thus never show up in either request > URI or contact. Since routing happens on reuqest URI and contact, I dont > understand the issue. > > Thanks, > Jonathan R. > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 12 17:40:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWLQ6-000194-Qp; Thu, 12 May 2005 17:40:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWLQ4-000183-Lx for sip@megatron.ietf.org; Thu, 12 May 2005 17:40:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11848 for ; Thu, 12 May 2005 17:40:33 -0400 (EDT) Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWLfq-0006yG-SG for sip@ietf.org; Thu, 12 May 2005 17:56:56 -0400 Received: from keywest (hide.pingtel.com [65.220.123.2]) by mail.pingtel.com (Postfix) with SMTP id 631096C017 for ; Thu, 12 May 2005 17:40:28 -0400 (EDT) From: "Dale Worley" To: "'Sip (E-mail)'" Subject: RE: [Sip] RFC 3840 "feature tags" as URI parameters Date: Thu, 12 May 2005 17:40:09 -0400 Message-ID: <00b401c5573b$2be74170$6a01010a@keywest> 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 CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4282F07B.2060509@cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > > Perhaps I am missing some context here, but the rfc3840 feature tags are > not URI parameters, they are contact header field parameters. Thus, they > would never be part of a URI and thus never show up in either request > URI or contact. Since routing happens on reuqest URI and contact, I dont > understand the issue. You are correct. In my defense, 3840 doesn't point that fact out very clearly, but the (sole?) example at the bottom of page 9 clearly shows these as field parameters, not URI parameters. Thanks for straightening this out, Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 13 11:12:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWbpn-0003nn-Hp; Fri, 13 May 2005 11:12:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWbpm-0003n3-0m for sip@megatron.ietf.org; Fri, 13 May 2005 11:12:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23606 for ; Fri, 13 May 2005 11:12:11 -0400 (EDT) Received: from natnoddy.rzone.de ([81.169.145.166]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWc5c-00030h-3R for sip@ietf.org; Fri, 13 May 2005 11:28:40 -0400 Received: from snom.de ([195.2.174.186]) by post.webmailer.de (8.13.1/8.13.1) with ESMTP id j4DFC1AJ003757 for ; Fri, 13 May 2005 17:12:01 +0200 (MEST) Received: from quickstep.intern.snom.de ([192.168.0.56]) by snom.de with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 May 2005 17:16:26 +0200 From: Nils Ohlmeier Organization: snom technology AG To: sip@ietf.org Date: Fri, 13 May 2005 17:11:57 +0200 User-Agent: KMail/1.8 X-Face: $bH@U>Mk-Y, <=?utf-8?q?R=60=27!8yXtr=5C/+=3B=5Do=3D=7BX5e4Zg=5DCU=25yS3aY=0A=09b=23X?= =?utf-8?q?=5D2KSW!b+?=(Q'%8w!#x^tS7ScTxwC@4mS}C%:j*s)Z_:Ry-m("k`elxv}tM" =?utf-8?q?M8=27=5EM8N=7CC=0A=09=25fYIY=3DskM=3A=60THz-l7=24c/iKcjtk=60?=, $Kzs}n:rD`Mh9Q]naI7)"uq}8N6f~!Aj>SaO, n2< =?utf-8?q?rZ=0A=09?= X-OriginalArrivalTime: 13 May 2005 15:16:26.0734 (UTC) FILETIME=[BB4F40E0:01C557CE] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Subject: [Sip] Doubts about 305 Use Proxy? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hello, I think the definition for the 305 response in RFC3261 may be wrong or is at least unclear. Example call flow: Alice atlanta.com biloxi.com Carol INV bob@atlanta ------------------> INV carol@biloxi ---------------------> INV carol@UA-IP --------------------> 305 Use Proxy m: sip:chicago.com <-------------------- Alice tries to call bob@atlanta.com. His proxy forwards the call to carol@biloxi.com. And her UA replies with 305 Use Proxy. The call flow does not make too much sence, it is just for illustration. According to page 184 of RFC3261 Carol should send the contact of the proxy which should be used. (Maybe I miss-interpret the words "URI of the proxy", but for 30[12] the term "new address" is being used.) The problem is: which username the receiver of the 305 should use? If biloxi.com takes care of the redirection, it would probably try carol@chicago.com. No problem. But if the 305 travels back to Alice, what should be the new request URI? bob@chicago.com? I think Carol should not provide the URI of the proxy in the Contact of the 305, but her complete AOR like carol@chicago.com. Although then there is no real difference between 302 and 305 any more. What do you think? Regards Nils Ohlmeier -- snom technology AG Gradestr. 46 D-12347 Berlin Nils Ohlmeier mailto:nils.ohlmeier@snom.de http://www.snom.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 sip-bounces@ietf.org Fri May 13 13:41:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWeAT-000596-Qp; Fri, 13 May 2005 13:41:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWeAS-000591-5L for sip@megatron.ietf.org; Fri, 13 May 2005 13:41:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08571 for ; Fri, 13 May 2005 13:41:40 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWeQQ-0000vH-Dj for sip@ietf.org; Fri, 13 May 2005 13:58:14 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 13 May 2005 13:41:35 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4DHfKnU006413; Fri, 13 May 2005 13:41:33 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 May 2005 13:40:44 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 May 2005 13:40:51 -0400 Message-ID: <4284E69B.3060806@cisco.com> Date: Fri, 13 May 2005 13:40:43 -0400 From: Paul Kyzivat 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: Nils Ohlmeier Subject: Re: [Sip] Doubts about 305 Use Proxy? References: <200505131711.57480.Nils.Ohlmeier@snom.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 May 2005 17:40:51.0285 (UTC) FILETIME=[E7C8D050:01C557E2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Nils, I too have felt that the description of 305 was incomplete. More below. Paul Nils Ohlmeier wrote: > Hello, > > I think the definition for the 305 response in RFC3261 may be wrong or is at > least unclear. > > Example call flow > Alice atlanta.com biloxi.com Carol > INV > bob@atlanta > ------------------> INV > carol@biloxi > ---------------------> INV > carol@UA-IP > --------------------> > 305 Use Proxy > m: sip:chicago.com > <-------------------- This is an interesting use case. > Alice tries to call bob@atlanta.com. His proxy forwards the call to > carol@biloxi.com. And her UA replies with 305 Use Proxy. The call flow does > not make too much sence, it is just for illustration. > > According to page 184 of RFC3261 Carol should send the contact of the proxy > which should be used. (Maybe I miss-interpret the words "URI of the proxy", > but for 30[12] the term "new address" is being used.) > The problem is: which username the receiver of the 305 should use? IMO this says to include a proxy, but does not say to change the R-URI at all, so there is no question about what username to use. > If biloxi.com takes care of the redirection, it would probably try > carol@chicago.com. No problem. I don't think so. If biloxy recurses on the 305, then I would expect it to send an invite something like: INVITE sip:carol@UA-IP Route: sip:chicago.com ... and then as result of the newly added route header, deliver the request to chicago.com. Then Chicago.com would forward it to Carol. > But if the 305 travels back to Alice, what should be the new request URI? > bob@chicago.com? This is a bit tricky, and I'm not sure it can work right. Presumably for the original part of the flow to work, the original invite from Alice must have looked something like: INVITE sip:bob@atlanta.com ... It may or may not have had a Route header for atlanta.com. Lets assume not. So then after receiving the 305, alice would IMO need to try: INVITE sip:bob@atlanta.com Route: sip:chicago.com ... And then because of the route header, this would be delivered directly to chicago.com, bypassing atlanta.com. Of course, chicago.com isn't responsible for uris at atlanta.com, and doesn't know this is intended for bob. So it will likely do one of two things: - refuse the request outright, causing the call to fail. - act as a transit node: Remove the route header, and then forward the request according to normal sip routing rules, to atlanta.com. This would then proceed just as in your call flow, and fail with another 305 response. The only way I can see to make this work if biloxy doesn't want to recurse is for biloxy to capture the 305 error and generate its own 302 error with a contact like: Contact: (excaping omitted to preserve readability) With that response, alice would generate a new invite like INVITE sip:carol@UA-IP Route: sip:chicago.com ... and then the right thing will happen. > I think Carol should not provide the URI of the proxy in the Contact of the > 305, but her complete AOR like carol@chicago.com. Although then there is no > real difference between 302 and 305 any more. What do you think? I think the point of 305 is to provide a way for a UA to ensure that all incoming requests are screened by a proxy the UA trusts. What you suggest (using 302) would work if there is exactly one registration to carol@chicago.com, but it won't work in general. The GRUU mechanism provides another way to accomplish this - respond with a 302 containing a GRUU issued by the proxy the UA trusts. I would be interested in hearing from one of the 3261 authors about how they thought 305 was supposed to work in this case. Paul > Regards > Nils Ohlmeier _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat May 14 01:19:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWp3h-0002gA-Ja; Sat, 14 May 2005 01:19:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWp3e-0002fs-Mp for sip@megatron.ietf.org; Sat, 14 May 2005 01:19:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13393 for ; Sat, 14 May 2005 01:19:25 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWpJg-0006Kz-0F for sip@ietf.org; Sat, 14 May 2005 01:36:03 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 13 May 2005 22:19:14 -0700 Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j4E5JBrA000288; Fri, 13 May 2005 22:19:12 -0700 (PDT) Received: from [192.168.1.100] (che-vpn-cluster-2-192.cisco.com [10.86.242.192]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AJT69241; Fri, 13 May 2005 22:19:10 -0700 (PDT) Message-ID: <42858A4D.2090708@cisco.com> Date: Sat, 14 May 2005 01:19:09 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] Doubts about 305 Use Proxy? References: <200505131711.57480.Nils.Ohlmeier@snom.de> <4284E69B.3060806@cisco.com> In-Reply-To: <4284E69B.3060806@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Nils Ohlmeier X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I've been thinking about exactly this issue recently. More inline. Paul Kyzivat wrote: >> According to page 184 of RFC3261 Carol should send the contact of the >> proxy which should be used. (Maybe I miss-interpret the words "URI of >> the proxy", but for 30[12] the term "new address" is being used.) >> The problem is: which username the receiver of the 305 should use? > > > IMO this says to include a proxy, but does not say to change the R-URI > at all, so there is no question about what username to use. Right. The URI should be used as is. > >> If biloxi.com takes care of the redirection, it would probably try >> carol@chicago.com. No problem. > > > I don't think so. If biloxy recurses on the 305, then I would expect it > to send an invite something like: > > INVITE sip:carol@UA-IP > Route: sip:chicago.com > ... Right. I don't think the spec is clear on this at all, in fact. It doesnt say anywhere to populate the Contact header field of the redirect into a Route header field, but I think this makes a lot of sense for the meaning of 305. > >> But if the 305 travels back to Alice, what should be the new request >> URI? bob@chicago.com? > > > This is a bit tricky, and I'm not sure it can work right. > > Presumably for the original part of the flow to work, the original > invite from Alice must have looked something like: > > INVITE sip:bob@atlanta.com > ... > > It may or may not have had a Route header for atlanta.com. Lets assume not. > > So then after receiving the 305, alice would IMO need to try: > > INVITE sip:bob@atlanta.com > Route: sip:chicago.com > ... > > And then because of the route header, this would be delivered directly > to chicago.com, bypassing atlanta.com. Of course, chicago.com isn't > responsible for uris at atlanta.com, and doesn't know this is intended > for bob. So it will likely do one of two things: > - refuse the request outright, causing the call to fail. > > - act as a transit node: Remove the route header, and then forward > the request according to normal sip routing rules, to atlanta.com. > This would then proceed just as in your call flow, and fail with > another 305 response. Yes, this is problematic. > > The only way I can see to make this work if biloxy doesn't want to > recurse is for biloxy to capture the 305 error and generate its own 302 > error with a contact like: > > Contact: > > (excaping omitted to preserve readability) > > With that response, alice would generate a new invite like > > INVITE sip:carol@UA-IP > Route: sip:chicago.com > ... > > and then the right thing will happen. Thats one possible solution, but I don't think its what a proxy should normally do. The first point to make on 305 is that I think its much like a 503. A 503 response is always consumed by the previous hop and never forwarded upstream. It has only local significance. I think the 305 is the same. It is meant to tell the previous element that it ought to forward the request to this server instead. By "instead", that means replacing the Route header it may have just used to get to that redirect server with this new one instead. By limiting it to the previous hop, you ensure that the r-uri is the same as before and thus these loops don't happen. So, when a proxy receives a 305, it can do one of several things: 1. recurse on it, by populating the Contact from the 305 into the topmost Route of a new request (replacing the one that got us to the redirect server previously), with the same request URI 2. forward a 4xx upstream 3. do the odd-but-allowed 302 Paul describes above No doubt there are other choices. However I think the first is almost always the right one. > I would be interested in hearing from one of the 3261 authors about how > they thought 305 was supposed to work in this case. I don't recall lots of discussions on 305 handling. There is nothing in the spec at all on using the Contact to populate a Route header field. Loose routing came fairly late in the development of 3261, and its interactions with the 305 response were simply not considered. I've been considering the 305 response recently since its come up as a potential solution to some other problems. Namely, cases where, within a domain, you have multiple proxies running (for example an IMS) and you want to use redirect instead of proxying to get from one to another. We don't want to modify the request URI here; just get the request sent elsewhere. In this usage, 305 is generated by a proxy, NOT a UAS. 3261 currently forbids proxies from generating 305. The reason we put that restriction in was to avoid cases where we saw loops when an outbound proxy generated a redirect. Since the initial thinking was that the Contact replaced the r-uri as always, this would just cause the new request to come to the same outbound proxy again anyway and cause a loop. The algorithm I suggest above avoids this loop but has the benefit of working when the redirect is generated by any element, not just a UAS. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.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 sip-bounces@ietf.org Sat May 14 01:46:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWpTw-00086S-2x; Sat, 14 May 2005 01:46:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWpTs-00086M-2Y for sip@megatron.ietf.org; Sat, 14 May 2005 01:46:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15163 for ; Sat, 14 May 2005 01:46:25 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWpjq-0007MB-H9 for sip@ietf.org; Sat, 14 May 2005 02:03:03 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate7) with ESMTP id j4E5rxrT012185 for ; Fri, 13 May 2005 22:53:59 -0700 (MST) Received: from zin24exm01.ap.mot.com (zin24exm01.ap.mot.com [10.232.25.1]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id j4E5nVpV025039 for ; Sat, 14 May 2005 00:49:32 -0500 (CDT) Received: by zin24exm01.ap.mot.com with Internet Mail Service (5.5.2657.72) id ; Sat, 14 May 2005 11:16:16 +0530 Message-ID: <772BCEF88A1DD91191F80011856715F30307D219@zin24exm01.ap.mot.com> From: Chadha Retesh-A19894 To: sip-implementors@cs.columbia.edu, sip@ietf.org Date: Sat, 14 May 2005 11:16:10 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 1.9 (+) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: Subject: [Sip] sdp in 1xx/2xx for different offer-answer scenarios X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1779390175==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org 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. --===============1779390175== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55848.3B618F8A" 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_01C55848.3B618F8A Content-Type: text/plain I have certain doubts regarding sending of sdp in 1xx/2xx in some scenarios. Scenario 1. PRACK and 1xx (with answer) <---- INVITE(with offer1) 1xx (with answer1) ---> <---- PRACK 200 ok (for PRACK) ---> Qs -- Now in the subsequent 1xx and 2xx responses, is it ok if no sdp is sent? And if sdp has to be sent then can it be a new answer?? Scenario 2. PRACK and 1xx (with offer) <---- INVITE(with no sdp) 1xx (with offer1) ---> <---- PRACK(with answer1) 200 ok (for PRACK) ---> Qs -- Now in the subsequent 1xx and 2xx responses, is it ok if no sdp is sent? And if sdp has to be sent, then can it be a new offer?? RFC 3261 mandates same sdp to be sent in subsequent 1xx and 2xx, but that's only if ealier sdp was sent in non-reliable responses. So, what should be the case when PRACK is there? Scenario 3. UPDATE and 1xx (non-reliable) <---- INVITE(with no sdp) 1xx (with offer1)(not reliable) ---> UPDATE ---> Qs -- Now the above UPDATE has to have a new offer or same offer1? Thanks in advance Rgds Retesh ------_=_NextPart_001_01C55848.3B618F8A Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KPFRJVExFPk1lc3NhZ2U8L1RJVExF Pg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yODAwLjE0NzkiIG5hbWU9R0VORVJBVE9S PjwvSEVBRD4NCjxCT0RZPg0KPERJVj48U1BBTiBjbGFzcz03ODczMzM3MDctMTMwNTIwMDU+PEZP TlQgZmFjZT1BcmlhbCBzaXplPTI+SSBoYXZlIGNlcnRhaW4gDQpkb3VidHMgcmVnYXJkaW5nIHNl bmRpbmcgb2Ygc2RwIGluIDF4eC8yeHggaW4gc29tZSBzY2VuYXJpb3MuIA0KPC9GT05UPjwvU1BB Tj48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCBzaXplPTI+PFNQQU4gY2xhc3M9 Nzg3MzMzNzA3LTEzMDUyMDA1PjwvU1BBTj48U1BBTiANCmNsYXNzPTc4NzMzMzcwNy0xMzA1MjAw NT48L1NQQU4+PC9GT05UPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9Nzg3 MzMzNzA3LTEzMDUyMDA1PjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgDQpzaXplPTI+PFNUUk9ORz5T Y2VuYXJpbyAxPC9TVFJPTkc+LiZuYnNwOyBQUkFDSyBhbmQgMXh4ICh3aXRoIA0KYW5zd2VyKTwv Rk9OVD48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBjbGFzcz03ODczMzM3MDctMTMw NTIwMDU+PC9TUEFOPjxTUEFOIGNsYXNzPTc4NzMzMzcwNy0xMzA1MjAwNT48Rk9OVCANCmZhY2U9 QXJpYWwgDQpzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IA0KJmx0Oy0tLS0mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgSU5WSVRFKHdpdGggDQpvZmZlcjEpPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQ QU4gY2xhc3M9Nzg3MzMzNzA3LTEzMDUyMDA1PjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPiZuYnNw OyZuYnNwOyZuYnNwOyANCjF4eCAod2l0aCBhbnN3ZXIxKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Oy0tLSZndDsmbmJzcDsgPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9Nzg3 MzMzNzA3LTEzMDUyMDA1PjxGT05UIGZhY2U9QXJpYWwgDQpzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KJmx0Oy0tLS0mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUFJBQ0s8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJ Vj48U1BBTiBjbGFzcz03ODczMzM3MDctMTMwNTIwMDU+PEZPTlQgZmFjZT1BcmlhbCANCnNpemU9 Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsyMDAgb2smbmJzcDsoZm9yIFBSQUNLKSZuYnNwOy0t LSZndDsmbmJzcDsgDQo8L0ZPTlQ+DQo8RElWPjxTUEFOIGNsYXNzPTc4NzMzMzcwNy0xMzA1MjAw NT48Rk9OVCBmYWNlPUFyaWFsIA0Kc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1FzIC0t IE5vdyBpbiB0aGUgc3Vic2VxdWVudCAxeHggYW5kIDJ4eCANCnJlc3BvbnNlcywgaXMgaXQgb2sg aWYgbm8gc2RwIGlzIHNlbnQ/IEFuZCBpZiBzZHAgaGFzIHRvIGJlIHNlbnQgdGhlbiBjYW4gaXQg YmUgDQphIG5ldyBhbnN3ZXI/PzwvRk9OVD48L1NQQU4+PC9ESVY+PC9TUEFOPjwvRElWPg0KPERJ Vj48U1BBTiBjbGFzcz03ODczMzM3MDctMTMwNTIwMDU+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xh c3M9Nzg3MzMzNzA3LTEzMDUyMDA1PjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgDQpzaXplPTI+PFNU Uk9ORz5TY2VuYXJpbyAyPC9TVFJPTkc+LiBQUkFDSyBhbmQgMXh4ICh3aXRoIA0Kb2ZmZXIpPC9G T05UPjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTc4NzMzMzcwNy0xMzA1 MjAwNT4NCjxESVY+PFNQQU4gY2xhc3M9Nzg3MzMzNzA3LTEzMDUyMDA1PjwvU1BBTj48U1BBTiBj bGFzcz03ODczMzM3MDctMTMwNTIwMDU+PEZPTlQgDQpmYWNlPUFyaWFsIA0Kc2l6ZT0yPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiZsdDstLS0tJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElOVklURSh3aXRoIG5v IA0Kc2RwKTwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTc4NzMzMzcwNy0x MzA1MjAwNT48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsgDQoxeHgg KHdpdGggb2ZmZXIxKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy0tLSZndDsmbmJzcDsgPC9GT05U PjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9Nzg3MzMzNzA3LTEzMDUyMDA1PjxGT05U IGZhY2U9QXJpYWwgDQpzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IA0KJmx0Oy0tLS0mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgUFJBQ0sod2l0aCANCmFuc3dlcjEpPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQ QU4gY2xhc3M9Nzg3MzMzNzA3LTEzMDUyMDA1PjxGT05UIGZhY2U9QXJpYWwgDQpzaXplPTI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7MjAwIG9rJm5ic3A7KGZvciBQUkFDSykmbmJzcDstLS0mZ3Q7 Jm5ic3A7IA0KPC9GT05UPjwvU1BBTj48L0RJVj48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNs YXNzPTc4NzMzMzcwNy0xMzA1MjAwNT4NCjxESVY+PFNQQU4gY2xhc3M9Nzg3MzMzNzA3LTEzMDUy MDA1PjxGT05UIGZhY2U9QXJpYWwgDQpzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7UXMg LS0gTm93IGluIHRoZSBzdWJzZXF1ZW50IDF4eCBhbmQgMnh4IA0KcmVzcG9uc2VzLCBpcyBpdCBv ayBpZiBubyBzZHAgaXMgc2VudD8gQW5kIGlmIHNkcCBoYXMgdG8gYmUgc2VudCwgdGhlbiZuYnNw O2NhbiANCml0IGJlIGEmbmJzcDtuZXcgb2ZmZXI/PyA8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJ Vj48U1BBTiBjbGFzcz03ODczMzM3MDctMTMwNTIwMDU+PEZPTlQgZmFjZT1BcmlhbCANCnNpemU9 Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJVj48U1BBTiBjbGFzcz03ODczMzM3MDct MTMwNTIwMDU+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+UkZDIDMyNjEgbWFuZGF0ZXMgDQpzYW1l IHNkcCB0byBiZSBzZW50IGluIHN1YnNlcXVlbnQgMXh4IGFuZCAyeHgsIGJ1dCB0aGF0J3Mgb25s eSBpZiBlYWxpZXIgc2RwIHdhcyANCnNlbnQgaW4gbm9uLXJlbGlhYmxlIHJlc3BvbnNlcy4mbmJz cDtTbywgd2hhdCBzaG91bGQgYmUgdGhlIGNhc2Ugd2hlbiBQUkFDSyBpcyANCnRoZXJlPzwvRk9O VD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTc4NzMzMzcwNy0xMzA1MjAwNT48Rk9O VCBmYWNlPUFyaWFsIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPjxGT05UIA0KZmFjZT1BcmlhbCBzaXpl PTI+PC9GT05UPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjwvRk9OVD48Rk9OVCBmYWNlPUFyaWFs IA0Kc2l6ZT0yPjwvRk9OVD48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48L0ZPTlQ+PEZPTlQgZmFj ZT1BcmlhbCANCnNpemU9Mj48L0ZPTlQ+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PC9GT05UPjwv U1BBTj48U1BBTiANCmNsYXNzPTc4NzMzMzcwNy0xMzA1MjAwNT48Rk9OVCBmYWNlPUFyaWFsIA0K c2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNz PTc4NzMzMzcwNy0xMzA1MjAwNT48Rk9OVCBmYWNlPUFyaWFsPjxGT05UIA0Kc2l6ZT0yPjxTVFJP Tkc+U2NlbmFyaW8gMzwvU1RST05HPi4gVVBEQVRFIGFuZCAxeHggDQoobm9uLXJlbGlhYmxlKTwv Rk9OVD48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBjbGFzcz03ODczMzM3MDctMTMw NTIwMDU+DQo8RElWPjxTUEFOIGNsYXNzPTc4NzMzMzcwNy0xMzA1MjAwNT4NCjxESVY+PFNQQU4g Y2xhc3M9Nzg3MzMzNzA3LTEzMDUyMDA1PjwvU1BBTj48U1BBTiBjbGFzcz03ODczMzM3MDctMTMw NTIwMDU+PEZPTlQgDQpmYWNlPUFyaWFsIA0Kc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiZsdDstLS0tJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElOVklURSh3aXRoIG5vIA0K c2RwKTwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTc4NzMzMzcwNy0xMzA1 MjAwNT4NCjxESVY+PFNQQU4gY2xhc3M9Nzg3MzMzNzA3LTEzMDUyMDA1PjxGT05UIGZhY2U9QXJp YWwgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyANCjF4eCAod2l0aCBvZmZlcjEpKG5vdCByZWxp YWJsZSkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDstLS0mZ3Q7Jm5ic3A7IA0KPC9GT05U Pg0KPERJVj48U1BBTiBjbGFzcz03ODczMzM3MDctMTMwNTIwMDU+PEZPTlQgZmFjZT1BcmlhbCAN CnNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtVUERBVEUmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDstLS0mZ3Q7Jm5ic3A7IA0KPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQ QU4gY2xhc3M9Nzg3MzMzNzA3LTEzMDUyMDA1PjxGT05UIGZhY2U9QXJpYWwgDQpzaXplPTI+PC9G T05UPjwvU1BBTj4mbmJzcDs8L0RJVj48L1NQQU4+PC9ESVY+PC9TUEFOPjxTUEFOIA0KY2xhc3M9 Nzg3MzMzNzA3LTEzMDUyMDA1PjwvU1BBTj48L0RJVj48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFO IGNsYXNzPTc4NzMzMzcwNy0xMzA1MjAwNT4NCjxESVY+PFNQQU4gY2xhc3M9Nzg3MzMzNzA3LTEz MDUyMDA1PjxGT05UIGZhY2U9QXJpYWwgDQpzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 UXMgLS0gTm93IHRoZSBhYm92ZSBVUERBVEUgaGFzIHRvIGhhdmUgYSBuZXcgDQpvZmZlciBvciBz YW1lIG9mZmVyMT8gPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9Nzg3MzMz NzA3LTEzMDUyMDA1PjxGT05UIGZhY2U9QXJpYWwgDQpzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJz cDs8L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9Nzg3MzMzNzA3LTEzMDUyMDA1PjxGT05UIGZhY2U9 QXJpYWwgc2l6ZT0yPlRoYW5rcyBpbiANCmFkdmFuY2U8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJ Vj48U1BBTiBjbGFzcz03ODczMzM3MDctMTMwNTIwMDU+PEZPTlQgZmFjZT1BcmlhbCANCnNpemU9 Mj5SZ2RzPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9Nzg3MzMzNzA3LTEz MDUyMDA1PjxGT05UIGZhY2U9QXJpYWwgDQpzaXplPTI+UmV0ZXNoPC9GT05UPjwvU1BBTj48L0RJ Vj48L1NQQU4+PC9ESVY+PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBjbGFzcz03ODczMzM3MDct MTMwNTIwMDU+PEZPTlQgZmFjZT1BcmlhbCANCnNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwv RElWPjwvQk9EWT48L0hUTUw+DQo= ------_=_NextPart_001_01C55848.3B618F8A-- --===============1779390175== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1779390175==-- From sip-bounces@ietf.org Sat May 14 08:54:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWwAH-0000p1-9s; Sat, 14 May 2005 08:54:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWwAE-0000ok-Ce for sip@megatron.ietf.org; Sat, 14 May 2005 08:54:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29373 for ; Sat, 14 May 2005 08:54:40 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWwQM-00064p-OG for sip@ietf.org; Sat, 14 May 2005 09:11:23 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 14 May 2005 08:54:34 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4ECsUdw002314; Sat, 14 May 2005 08:54:31 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 14 May 2005 08:54:30 -0400 Received: from cisco.com ([10.86.240.28]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 14 May 2005 08:54:29 -0400 Message-ID: <4285F505.8050205@cisco.com> Date: Sat, 14 May 2005 08:54:29 -0400 From: Paul Kyzivat 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 Subject: Re: [Sip] Doubts about 305 Use Proxy? References: <200505131711.57480.Nils.Ohlmeier@snom.de> <4284E69B.3060806@cisco.com> <42858A4D.2090708@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 May 2005 12:54:30.0039 (UTC) FILETIME=[11607A70:01C55884] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Nils Ohlmeier X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Jonathan, Thanks for the perspective of an author. The intended meaning of 305 has been a question to me for a long time. It seems like there is at least one action item out of this - some kind of clarification of 305 handling to at least remove the bug that results in failure or looping if the 305 is relayed back to the caller. IMO the minimal requirement is that a proxy that translated the R-URI MUST NOT forward the 305 response on upstream. Instead, it must consume and act on it in some way - recursing or returning some other response. BTW, I agree that my suggestion of turning the 305 into a 302 with Route header embedded in the Contact is not a great solution. I was just grasping at straws. Paul Jonathan Rosenberg wrote: > I've been thinking about exactly this issue recently. More inline. > > Paul Kyzivat wrote: > > >>> According to page 184 of RFC3261 Carol should send the contact of the >>> proxy which should be used. (Maybe I miss-interpret the words "URI of >>> the proxy", but for 30[12] the term "new address" is being used.) >>> The problem is: which username the receiver of the 305 should use? >> >> >> >> IMO this says to include a proxy, but does not say to change the R-URI >> at all, so there is no question about what username to use. > > > Right. The URI should be used as is. > >> >>> If biloxi.com takes care of the redirection, it would probably try >>> carol@chicago.com. No problem. >> >> >> >> I don't think so. If biloxy recurses on the 305, then I would expect >> it to send an invite something like: >> >> INVITE sip:carol@UA-IP >> Route: sip:chicago.com >> ... > > > Right. I don't think the spec is clear on this at all, in fact. It > doesnt say anywhere to populate the Contact header field of the redirect > into a Route header field, but I think this makes a lot of sense for the > meaning of 305. > >> >>> But if the 305 travels back to Alice, what should be the new request >>> URI? bob@chicago.com? >> >> >> >> This is a bit tricky, and I'm not sure it can work right. >> >> Presumably for the original part of the flow to work, the original >> invite from Alice must have looked something like: >> >> INVITE sip:bob@atlanta.com >> ... >> >> It may or may not have had a Route header for atlanta.com. Lets assume >> not. >> >> So then after receiving the 305, alice would IMO need to try: >> >> INVITE sip:bob@atlanta.com >> Route: sip:chicago.com >> ... >> >> And then because of the route header, this would be delivered directly >> to chicago.com, bypassing atlanta.com. Of course, chicago.com isn't >> responsible for uris at atlanta.com, and doesn't know this is intended >> for bob. So it will likely do one of two things: >> - refuse the request outright, causing the call to fail. >> >> - act as a transit node: Remove the route header, and then forward >> the request according to normal sip routing rules, to atlanta.com. >> This would then proceed just as in your call flow, and fail with >> another 305 response. > > > Yes, this is problematic. > > >> >> The only way I can see to make this work if biloxy doesn't want to >> recurse is for biloxy to capture the 305 error and generate its own >> 302 error with a contact like: >> >> Contact: >> >> (excaping omitted to preserve readability) >> >> With that response, alice would generate a new invite like >> >> INVITE sip:carol@UA-IP >> Route: sip:chicago.com >> ... >> >> and then the right thing will happen. > > > Thats one possible solution, but I don't think its what a proxy should > normally do. > > The first point to make on 305 is that I think its much like a 503. A > 503 response is always consumed by the previous hop and never forwarded > upstream. It has only local significance. I think the 305 is the same. > It is meant to tell the previous element that it ought to forward the > request to this server instead. By "instead", that means replacing the > Route header it may have just used to get to that redirect server with > this new one instead. By limiting it to the previous hop, you ensure > that the r-uri is the same as before and thus these loops don't happen. > > So, when a proxy receives a 305, it can do one of several things: > > 1. recurse on it, by populating the Contact from the 305 into the > topmost Route of a new request (replacing the one that got us to the > redirect server previously), with the same request URI > > 2. forward a 4xx upstream > > 3. do the odd-but-allowed 302 Paul describes above > > No doubt there are other choices. However I think the first is almost > always the right one. > > >> I would be interested in hearing from one of the 3261 authors about >> how they thought 305 was supposed to work in this case. > > > I don't recall lots of discussions on 305 handling. There is nothing in > the spec at all on using the Contact to populate a Route header field. > Loose routing came fairly late in the development of 3261, and its > interactions with the 305 response were simply not considered. > > I've been considering the 305 response recently since its come up as a > potential solution to some other problems. Namely, cases where, within a > domain, you have multiple proxies running (for example an IMS) and you > want to use redirect instead of proxying to get from one to another. We > don't want to modify the request URI here; just get the request sent > elsewhere. > > In this usage, 305 is generated by a proxy, NOT a UAS. 3261 currently > forbids proxies from generating 305. The reason we put that restriction > in was to avoid cases where we saw loops when an outbound proxy > generated a redirect. Since the initial thinking was that the Contact > replaced the r-uri as always, this would just cause the new request to > come to the same outbound proxy again anyway and cause a loop. > > The algorithm I suggest above avoids this loop but has the benefit of > working when the redirect is generated by any element, not just a UAS. > > -Jonathan R. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 16 01:35:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXYG6-0002n0-Px; Mon, 16 May 2005 01:35:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXYG4-0002ln-Tk for sip@megatron.ietf.org; Mon, 16 May 2005 01:35:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03597 for ; Mon, 16 May 2005 01:35:15 -0400 (EDT) From: tony88.wu@msa.hinet.net Received: from msr51.hinet.net ([168.95.4.151]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXYWX-0000sj-R8 for sip@ietf.org; Mon, 16 May 2005 01:52:18 -0400 Received: from tony88nb (61-220-20-199.HINET-IP.hinet.net [61.220.20.199]) by msr51.hinet.net (8.9.3/8.9.3) with SMTP id NAA14501 for ; Mon, 16 May 2005 13:35:08 +0800 (CST) Message-ID: <002601c559d9$06736bd0$6c02a8c0@tony88nb> To: Date: Mon, 16 May 2005 13:35:08 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.3 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Subject: [Sip] Fw: Welcome to the "Sip" mailing list (Digest mode) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org ----- Original Message ----- From: To: Sent: Monday, May 16, 2005 1:28 PM Subject: Welcome to the "Sip" mailing list (Digest mode) > Welcome to the Sip@ietf.org mailing list! > > To post to this list, send your email to: > > sip@ietf.org > > General information about the mailing list is at: > > https://www1.ietf.org/mailman/listinfo/sip > > ********************************************************************** > > Note Well > > Any submission to the IETF intended by the Contributor for publication > as all or part of an IETF Internet-Draft or RFC and any statement made > within the context of an IETF activity is considered an "IETF > Contribution". Such statements include oral statements in IETF > sessions, as well as written and electronic communications made at any > time or place, which are addressed to: > > * the IETF plenary session, > * any IETF working group or portion thereof, > * the IESG, or any member thereof on behalf of the IESG, > * the IAB or any member thereof on behalf of the IAB, > * any IETF mailing list, including the IETF list itself, any > working group or design team list, or any other list > functioning under IETF auspices, > * the RFC Editor or the Internet-Drafts function > > All IETF Contributions are subject to the rules of RFC 3667 and RFC > 3668. > > Statements made outside of an IETF session, mailing list or other > function, that are clearly not intended to be input to an IETF > activity, group or function, are not IETF Contributions in the context > of this notice. > > Please consult RFC 3667 for details. > > ******************************************************************************* > > > If you ever want to unsubscribe or change your options (eg, switch to > or from digest mode, change your password, etc.), visit your > subscription page at: > > https://www1.ietf.org/mailman/options/sip/tony88.wu%40msa.hinet.net > > You can also make such adjustments via email by sending a message to: > > Sip-request@ietf.org > > with the word `help' in the subject or body (don't include the > quotes), and you will get back a message with instructions. > > You must know your password to change your options (including changing > the password, itself) or to unsubscribe. It is: > > m1731 > > Normally, Mailman will remind you of your ietf.org mailing list > passwords once every month, although you can disable this if you > prefer. This reminder will also include instructions on how to > unsubscribe or change your account options. There is also a button on > your options page that will email your current password to you. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 16 08:21:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXebZ-00062j-4A; Mon, 16 May 2005 08:21:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXebW-00061B-KV for sip@megatron.ietf.org; Mon, 16 May 2005 08:21:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03350 for ; Mon, 16 May 2005 08:21:49 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXes3-00021u-Si for sip@ietf.org; Mon, 16 May 2005 08:38:56 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-4.cisco.com with ESMTP; 16 May 2005 05:21:40 -0700 Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4GCLXO3011718; Mon, 16 May 2005 05:21:34 -0700 (PDT) Received: from [192.168.1.104] (che-vpn-cluster-1-71.cisco.com [10.86.240.71]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AJT87481; Mon, 16 May 2005 05:21:37 -0700 (PDT) Message-ID: <42889051.8070607@cisco.com> Date: Mon, 16 May 2005 08:21:37 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] Doubts about 305 Use Proxy? References: <200505131711.57480.Nils.Ohlmeier@snom.de> <4284E69B.3060806@cisco.com> <42858A4D.2090708@cisco.com> <4285F505.8050205@cisco.com> In-Reply-To: <4285F505.8050205@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Nils Ohlmeier X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org If folks think this is a reasonable path, I can enter a bug report into bugs.sipit.net. I don't know where else such a clarification would go, unless we want to write an I-D and publish an RFC just for this topic... Chairs? -Jonathan R. Paul Kyzivat wrote: > Jonathan, > > Thanks for the perspective of an author. The intended meaning of 305 has > been a question to me for a long time. > > It seems like there is at least one action item out of this - some kind > of clarification of 305 handling to at least remove the bug that results > in failure or looping if the 305 is relayed back to the caller. > > IMO the minimal requirement is that a proxy that translated the R-URI > MUST NOT forward the 305 response on upstream. Instead, it must consume > and act on it in some way - recursing or returning some other response. > > BTW, I agree that my suggestion of turning the 305 into a 302 with Route > header embedded in the Contact is not a great solution. I was just > grasping at straws. > > Paul > > Jonathan Rosenberg wrote: > >> I've been thinking about exactly this issue recently. More inline. >> >> Paul Kyzivat wrote: >> >> >>>> According to page 184 of RFC3261 Carol should send the contact of >>>> the proxy which should be used. (Maybe I miss-interpret the words >>>> "URI of the proxy", but for 30[12] the term "new address" is being >>>> used.) >>>> The problem is: which username the receiver of the 305 should use? >>> >>> >>> >>> >>> IMO this says to include a proxy, but does not say to change the >>> R-URI at all, so there is no question about what username to use. >> >> >> >> Right. The URI should be used as is. >> >>> >>>> If biloxi.com takes care of the redirection, it would probably try >>>> carol@chicago.com. No problem. >>> >>> >>> >>> >>> I don't think so. If biloxy recurses on the 305, then I would expect >>> it to send an invite something like: >>> >>> INVITE sip:carol@UA-IP >>> Route: sip:chicago.com >>> ... >> >> >> >> Right. I don't think the spec is clear on this at all, in fact. It >> doesnt say anywhere to populate the Contact header field of the >> redirect into a Route header field, but I think this makes a lot of >> sense for the meaning of 305. >> >>> >>>> But if the 305 travels back to Alice, what should be the new request >>>> URI? bob@chicago.com? >>> >>> >>> >>> >>> This is a bit tricky, and I'm not sure it can work right. >>> >>> Presumably for the original part of the flow to work, the original >>> invite from Alice must have looked something like: >>> >>> INVITE sip:bob@atlanta.com >>> ... >>> >>> It may or may not have had a Route header for atlanta.com. Lets >>> assume not. >>> >>> So then after receiving the 305, alice would IMO need to try: >>> >>> INVITE sip:bob@atlanta.com >>> Route: sip:chicago.com >>> ... >>> >>> And then because of the route header, this would be delivered >>> directly to chicago.com, bypassing atlanta.com. Of course, >>> chicago.com isn't responsible for uris at atlanta.com, and doesn't >>> know this is intended for bob. So it will likely do one of two things: >>> - refuse the request outright, causing the call to fail. >>> >>> - act as a transit node: Remove the route header, and then forward >>> the request according to normal sip routing rules, to atlanta.com. >>> This would then proceed just as in your call flow, and fail with >>> another 305 response. >> >> >> >> Yes, this is problematic. >> >> >>> >>> The only way I can see to make this work if biloxy doesn't want to >>> recurse is for biloxy to capture the 305 error and generate its own >>> 302 error with a contact like: >>> >>> Contact: >>> >>> (excaping omitted to preserve readability) >>> >>> With that response, alice would generate a new invite like >>> >>> INVITE sip:carol@UA-IP >>> Route: sip:chicago.com >>> ... >>> >>> and then the right thing will happen. >> >> >> >> Thats one possible solution, but I don't think its what a proxy should >> normally do. >> >> The first point to make on 305 is that I think its much like a 503. A >> 503 response is always consumed by the previous hop and never >> forwarded upstream. It has only local significance. I think the 305 is >> the same. It is meant to tell the previous element that it ought to >> forward the request to this server instead. By "instead", that means >> replacing the Route header it may have just used to get to that >> redirect server with this new one instead. By limiting it to the >> previous hop, you ensure that the r-uri is the same as before and thus >> these loops don't happen. >> >> So, when a proxy receives a 305, it can do one of several things: >> >> 1. recurse on it, by populating the Contact from the 305 into the >> topmost Route of a new request (replacing the one that got us to the >> redirect server previously), with the same request URI >> >> 2. forward a 4xx upstream >> >> 3. do the odd-but-allowed 302 Paul describes above >> >> No doubt there are other choices. However I think the first is almost >> always the right one. >> >> >>> I would be interested in hearing from one of the 3261 authors about >>> how they thought 305 was supposed to work in this case. >> >> >> >> I don't recall lots of discussions on 305 handling. There is nothing >> in the spec at all on using the Contact to populate a Route header >> field. Loose routing came fairly late in the development of 3261, and >> its interactions with the 305 response were simply not considered. >> >> I've been considering the 305 response recently since its come up as a >> potential solution to some other problems. Namely, cases where, within >> a domain, you have multiple proxies running (for example an IMS) and >> you want to use redirect instead of proxying to get from one to >> another. We don't want to modify the request URI here; just get the >> request sent elsewhere. >> >> In this usage, 305 is generated by a proxy, NOT a UAS. 3261 currently >> forbids proxies from generating 305. The reason we put that >> restriction in was to avoid cases where we saw loops when an outbound >> proxy generated a redirect. Since the initial thinking was that the >> Contact replaced the r-uri as always, this would just cause the new >> request to come to the same outbound proxy again anyway and cause a loop. >> >> The algorithm I suggest above avoids this loop but has the benefit of >> working when the redirect is generated by any element, not just a UAS. >> >> -Jonathan R. > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.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 sip-bounces@ietf.org Mon May 16 11:11:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXhFk-0003Ct-OI; Mon, 16 May 2005 11:11:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXhFi-0003C2-WC for sip@megatron.ietf.org; Mon, 16 May 2005 11:11:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23882 for ; Mon, 16 May 2005 11:11:28 -0400 (EDT) Received: from h66-59-156-142.gtconnect.net ([66.59.156.142] helo=server2.computertalktech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXhWG-0006bf-Ss for sip@ietf.org; Mon, 16 May 2005 11:28:38 -0400 Received: by SERVER2 with Internet Mail Service (5.5.2657.72) id <2B6NA0FX>; Mon, 16 May 2005 11:11:08 -0400 Message-ID: <015C32DAF4DED2118B3F00016F02060E0407A71C@SERVER2> From: Scott Godin To: "'Jonathan Rosenberg'" , sip@ietf.org Date: Mon, 16 May 2005 11:11:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Cc: Subject: [Sip] RFC4028 - Session Timer Clarification X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0283415352==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org 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. --===============0283415352== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55A29.7BC871A0" 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_01C55A29.7BC871A0 Content-Type: text/plain The refresher parameter is used to indicate if the UAS or UAC is to perform the session refreshes. Do the terms UAS and UAC refer to the Invite Session or to the particular transaction? Consider the following scenario 1. Alice Invites Bob 2. Bob's 200 contains a refresher parameter specifying UAS (himself) as the refresher. 3. When Bob sends his session refresh message should it contain a refresher parameter of UAS or UAC - assuming he wishes to continue being the refresher? The RFC seems to indicate he should send UAC (2nd last paragraph in section 7.4). Thanks, Scott ------_=_NextPart_001_01C55A29.7BC871A0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

The refresher parameter is used to indicate if the = UAS or UAC is to perform the session refreshes.

 

Do the terms UAS and UAC refer to the Invite Session = or to the particular transaction?

 

Consider the following = scenario

  1. Alice Invites Bob
  2. Bob's 200 contains a = refresher parameter specifying UAS (himself) as the = refresher.
  3. When Bob sends his = session refresh message should it contain a refresher parameter of UAS or = UAC - assuming he wishes to continue being the = refresher?

 

The RFC seems to indicate he should send UAC = (2nd last paragraph in section 7.4).

 

Thanks,

 

Scott

------_=_NextPart_001_01C55A29.7BC871A0-- --===============0283415352== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0283415352==-- From sip-bounces@ietf.org Mon May 16 11:53:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXhui-0004ND-2L; Mon, 16 May 2005 11:53:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXhug-0004N7-3X for sip@megatron.ietf.org; Mon, 16 May 2005 11:53:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28490 for ; Mon, 16 May 2005 11:53:47 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXiBD-0007lE-L2 for sip@ietf.org; Mon, 16 May 2005 12:10:57 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 16 May 2005 12:09:22 -0400 X-IronPort-AV: i="3.93,111,1115006400"; d="scan'208"; a="49599815:sNHT27284124" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4GFranI003335; Mon, 16 May 2005 11:53:37 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 May 2005 11:53:34 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 May 2005 11:53:34 -0400 Message-ID: <4288C1FE.9040609@cisco.com> Date: Mon, 16 May 2005 11:53:34 -0400 From: Paul Kyzivat 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: Scott Godin Subject: Re: [Sip] RFC4028 - Session Timer Clarification References: <015C32DAF4DED2118B3F00016F02060E0407A71C@SERVER2> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2005 15:53:34.0748 (UTC) FILETIME=[6A8C75C0:01C55A2F] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Scott Godin wrote: > The refresher parameter is used to indicate if the UAS or UAC is to > perform the session refreshes. > > Do the terms UAS and UAC refer to the Invite Session or to the > particular transaction? The terminogy is indeed confusing here. > Consider the following scenario > > 1. Alice Invites Bob > 2. Bob's 200 contains a refresher parameter specifying UAS (himself) > as the refresher. > 3. When Bob sends his session refresh message should it contain a > refresher parameter of UAS or UAC - assuming he wishes to continue > being the refresher? > > The RFC seems to indicate he should send UAC (2^nd last paragraph in > section 7.4). I agree that Bob should specify UAC to remain the refresher. IMO the right way to think about session-timer is that every request that could be a session-refresh-request terminates the old session timer. Then it may or may not set up a new session timer. When doing so, the refreshed is determined relative to the current request. 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 sip-bounces@ietf.org Mon May 16 15:37:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXlPQ-0006ab-9Y; Mon, 16 May 2005 15:37:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXlPM-0006Zr-4R; Mon, 16 May 2005 15:37:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29465; Mon, 16 May 2005 15:37:42 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXlfx-00025O-Kd; Mon, 16 May 2005 15:54:53 -0400 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1DXlPK-0007ID-D5; Mon, 16 May 2005 15:37:42 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 16 May 2005 15:37:42 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: sip mailing list , sip chair , Internet Architecture Board , sip chair , RFC Editor Subject: [Sip] Protocol Action: 'An Extension to the Session Initiation Protocol for Request History Information' to Proposed Standard X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org The IESG has approved the following document: - 'An Extension to the Session Initiation Protocol for Request History Information ' as a Proposed Standard This document is the product of the Session Initiation Protocol Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. Technical Summary This document defines a standard mechanism for capturing the history information associated with a SIP request. This capability enables many enhanced services by providing the information as to how and why a call arrives at a specific application or user. This document defines a new optional SIP header, History-Info, for capturing the history information in requests. WG Summary There was extended working group review, including a requirements document, which was absorbed eventually into this specification, and a lengthy debate to obtain methods for provision of privacy. The working group reached a good consensus to advance this solution. Protocol Quality Some implementation and testing have been discussed. The WG Chair shepherd for this document was Rohan Mahy. Notes to the RFC Editor Section 1, 2nd to last paragraph OLD: o Some diagnostic information for debugging SIP requests. NEW: o Some diagnostic information for debugging SIP requests. (Note that the diagnostic utility of this mechanism is limited by the fact that its use by entities which retarget is optional.) Section 2.1, insert after 3rd para NEW: 3) A rogue application could delete some or all of the Request History information. Section 2.1, 3rd para from the end OLD: 3) SEC-req-3: The entity receiving the information conveyed by the Request History must be able to authenticate the source of the information. NEW: 3) SEC-req-3: The entity receiving the information conveyed by the Request History must be able to authenticate the entity providing the request. Section 3.2: Insert immediately after last paragraph NEW: Note that while using the SIPS scheme protects History-Info from tampering by arbitrary parties outside the SIP message path, all the intermediaries on the path are trusted implicitly. A malicious intermediary could arbitrarily delete, rewrite, or modify History-Info. This specification does not attempt to prevent or detect attacks by malicious intermediaries. Section 4.1: Please delete the blank line indicated below with --> OLD: History-Info = "History-Info" HCOLON --> hi-entry *(COMMA hi-entry) NEW: History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry) Section 4.3.1, 1st paragraph OLD: The UAC SHOULD include the "histinfo" option tag in the Supported header in any request not associated with an established dialog for which the UAC would like the History-Info header in the Response. In addition, the UAC SHOULD initiate the capturing of the History Information by adding a History-Info header, using the Request-URI of the request as the hi-targeted-to-uri and initializing the index to the RECOMMENDED value of 1 in the hi-entry. NEW: The UAC SHOULD include the "histinfo" option tag in the Supported header in any request not associated with an established dialog for which the UAC would like the History-Info header in the response. In addition, the UAC MAY improve the diagnostic utility of its request by adding a History-Info header, using the Request-URI of the request as the hi-target-to-uri and initializing the index to the RECOMMENDED value of 1 in the hi-entry. As a result, intermediaries and the UAS will know at least the original Request-URI, and if the Request-URI was modified by a previous hop. Appendix A OLD: UA 1sends NEW: UA1 sends _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 16 23:22:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXsfV-0006yR-0x; Mon, 16 May 2005 23:22:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXsfQ-0006wx-Lu for sip@megatron.ietf.org; Mon, 16 May 2005 23:22:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06156 for ; Mon, 16 May 2005 23:22:45 -0400 (EDT) Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXsw4-0007VH-Vp for sip@ietf.org; Mon, 16 May 2005 23:40:02 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id j4H3Mjcf025018 for ; Mon, 16 May 2005 20:22:45 -0700 (MST) Received: from zin24exm01.ap.mot.com (zin24exm01.ap.mot.com [10.232.25.1]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id j4H3LpmL010446 for ; Mon, 16 May 2005 22:21:52 -0500 (CDT) Received: by zin24exm01.ap.mot.com with Internet Mail Service (5.5.2657.72) id ; Tue, 17 May 2005 08:48:52 +0530 Message-ID: <772BCEF88A1DD91191F80011856715F30313C649@zin24exm01.ap.mot.com> From: Chadha Retesh-A19894 To: sip-implementors@cs.columbia.edu, sip@ietf.org Date: Tue, 17 May 2005 08:48:51 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 2.4 (++) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: Subject: [Sip] RE: sdp in 1xx/2xx for different offer-answer scenarios X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2091883448==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org 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. --===============2091883448== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55A8F.26240488" 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_01C55A8F.26240488 Content-Type: text/plain Resending, in case it was missed on the weekend. Any comments on this?? -----Original Message----- From: Chadha Retesh-A19894 Sent: Saturday, May 14, 2005 11:16 AM To: 'sip-implementors@cs.columbia.edu'; sip@ietf.org Subject: sdp in 1xx/2xx for different offer-answer scenarios I have certain doubts regarding sending of sdp in 1xx/2xx in some scenarios. Scenario 1. PRACK and 1xx (with answer) <---- INVITE(with offer1) 1xx (with answer1) ---> <---- PRACK 200 ok (for PRACK) ---> Qs -- Now in the subsequent 1xx and 2xx responses, is it ok if no sdp is sent? And if sdp has to be sent then can it be a new answer?? Scenario 2. PRACK and 1xx (with offer) <---- INVITE(with no sdp) 1xx (with offer1) ---> <---- PRACK(with answer1) 200 ok (for PRACK) ---> Qs -- Now in the subsequent 1xx and 2xx responses, is it ok if no sdp is sent? And if sdp has to be sent, then can it be a new offer?? RFC 3261 mandates same sdp to be sent in subsequent 1xx and 2xx, but that's only if ealier sdp was sent in non-reliable responses. So, what should be the case when PRACK is there? Scenario 3. UPDATE and 1xx (non-reliable) <---- INVITE(with no sdp) 1xx (with offer1)(not reliable) ---> UPDATE ---> Qs -- Now the above UPDATE has to have a new offer or same offer1? Thanks in advance Rgds Retesh ------_=_NextPart_001_01C55A8F.26240488 Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KPFRJVExFPk1lc3NhZ2U8L1RJVExF Pg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yODAwLjE0NzkiIG5hbWU9R0VORVJBVE9S PjwvSEVBRD4NCjxCT0RZPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6 ZT0yPjxTUEFOIA0KY2xhc3M9MDA1MDQxODAzLTE3MDUyMDA1PlJlc2VuZGluZywgaW4gY2FzZSBp dCB3YXMgbWlzc2VkIG9uIHRoZSB3ZWVrZW5kLiBBbnkgDQpjb21tZW50cyBvbiB0aGlzPz88L1NQ QU4+PC9GT05UPjwvRElWPg0KPEJMT0NLUVVPVEUgZGlyPWx0ciBzdHlsZT0iTUFSR0lOLVJJR0hU OiAwcHgiPg0KICA8RElWPjwvRElWPg0KICA8RElWIGNsYXNzPU91dGxvb2tNZXNzYWdlSGVhZGVy IGxhbmc9ZW4tdXMgZGlyPWx0ciBhbGlnbj1sZWZ0PjxGT05UIA0KICBmYWNlPVRhaG9tYSBzaXpl PTI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+PEI+RnJvbTo8L0I+IENoYWRoYSANCiAg UmV0ZXNoLUExOTg5NCA8QlI+PEI+U2VudDo8L0I+IFNhdHVyZGF5LCBNYXkgMTQsIDIwMDUgMTE6 MTYgQU08QlI+PEI+VG86PC9CPiANCiAgJ3NpcC1pbXBsZW1lbnRvcnNAY3MuY29sdW1iaWEuZWR1 Jzsgc2lwQGlldGYub3JnPEJSPjxCPlN1YmplY3Q6PC9CPiBzZHAgaW4gDQogIDF4eC8yeHggZm9y IGRpZmZlcmVudCBvZmZlci1hbnN3ZXIgc2NlbmFyaW9zPEJSPjxCUj48L0ZPTlQ+PC9ESVY+DQog IDxESVY+PFNQQU4gY2xhc3M9Nzg3MzMzNzA3LTEzMDUyMDA1PjxGT05UIGZhY2U9QXJpYWwgc2l6 ZT0yPkkgaGF2ZSBjZXJ0YWluIA0KICBkb3VidHMgcmVnYXJkaW5nIHNlbmRpbmcgb2Ygc2RwIGlu IDF4eC8yeHggaW4gc29tZSBzY2VuYXJpb3MuIA0KICA8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICA8 RElWPjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgc2l6ZT0yPjxTUEFOIGNsYXNzPTc4NzMzMzcwNy0x MzA1MjAwNT48L1NQQU4+PFNQQU4gDQogIGNsYXNzPTc4NzMzMzcwNy0xMzA1MjAwNT48L1NQQU4+ PC9GT05UPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgPERJVj48U1BBTiBjbGFzcz03ODczMzM3MDct MTMwNTIwMDU+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCANCiAgc2l6ZT0yPjxTVFJPTkc+U2NlbmFy aW8gMTwvU1RST05HPi4mbmJzcDsgUFJBQ0sgYW5kIDF4eCAod2l0aCANCiAgYW5zd2VyKTwvRk9O VD48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTc4NzMzMzcwNy0xMzA1 MjAwNT48L1NQQU4+PFNQQU4gDQogIGNsYXNzPTc4NzMzMzcwNy0xMzA1MjAwNT48Rk9OVCBmYWNl PUFyaWFsIA0KICBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IA0KICAmbHQ7LS0tLSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBJTlZJVEUod2l0aCANCiAgb2ZmZXIxKTwvRk9OVD48L1NQQU4+PC9ESVY+DQog IDxESVY+PFNQQU4gY2xhc3M9Nzg3MzMzNzA3LTEzMDUyMDA1PjxGT05UIGZhY2U9QXJpYWwgc2l6 ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyANCiAgMXh4ICh3aXRoIGFuc3dlcjEpJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7LS0tJmd0OyZuYnNwOyA8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICA8RElWPjxT UEFOIGNsYXNzPTc4NzMzMzcwNy0xMzA1MjAwNT48Rk9OVCBmYWNlPUFyaWFsIA0KICBzaXplPTI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICAmbHQ7LS0t LSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBQUkFDSzwvRk9OVD48 L1NQQU4+PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9Nzg3MzMzNzA3LTEzMDUyMDA1PjxGT05U IGZhY2U9QXJpYWwgDQogIHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsyMDAgb2smbmJz cDsoZm9yIFBSQUNLKSZuYnNwOy0tLSZndDsmbmJzcDsgDQogIDwvRk9OVD4NCiAgPERJVj48U1BB TiBjbGFzcz03ODczMzM3MDctMTMwNTIwMDU+PEZPTlQgZmFjZT1BcmlhbCANCiAgc2l6ZT0yPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO1FzIC0tIE5vdyBpbiB0aGUgc3Vic2VxdWVudCAxeHggYW5k IDJ4eCANCiAgcmVzcG9uc2VzLCBpcyBpdCBvayBpZiBubyBzZHAgaXMgc2VudD8gQW5kIGlmIHNk cCBoYXMgdG8gYmUgc2VudCB0aGVuIGNhbiBpdCANCiAgYmUgYSBuZXcgYW5zd2VyPz88L0ZPTlQ+ PC9TUEFOPjwvRElWPjwvU1BBTj48L0RJVj4NCiAgPERJVj48U1BBTiBjbGFzcz03ODczMzM3MDct MTMwNTIwMDU+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8 L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTc4NzMzMzcwNy0xMzA1MjAw NT48Rk9OVCBmYWNlPUFyaWFsPjxGT05UIA0KICBzaXplPTI+PFNUUk9ORz5TY2VuYXJpbyAyPC9T VFJPTkc+LiBQUkFDSyBhbmQgMXh4ICh3aXRoIA0KICBvZmZlcik8L0ZPTlQ+PC9GT05UPjwvU1BB Tj48L0RJVj4NCiAgPERJVj48U1BBTiBjbGFzcz03ODczMzM3MDctMTMwNTIwMDU+DQogIDxESVY+ PFNQQU4gY2xhc3M9Nzg3MzMzNzA3LTEzMDUyMDA1PjwvU1BBTj48U1BBTiANCiAgY2xhc3M9Nzg3 MzMzNzA3LTEzMDUyMDA1PjxGT05UIGZhY2U9QXJpYWwgDQogIHNpemU9Mj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogICZsdDstLS0tJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElOVklURSh3aXRoIG5vIA0KICBz ZHApPC9GT05UPjwvU1BBTj48L0RJVj4NCiAgPERJVj48U1BBTiBjbGFzcz03ODczMzM3MDctMTMw NTIwMDU+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICAxeHgg KHdpdGggb2ZmZXIxKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy0tLSZndDsmbmJzcDsgPC9GT05U PjwvU1BBTj48L0RJVj4NCiAgPERJVj48U1BBTiBjbGFzcz03ODczMzM3MDctMTMwNTIwMDU+PEZP TlQgZmFjZT1BcmlhbCANCiAgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyANCiAgJmx0Oy0tLS0mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgUFJBQ0sod2l0aCANCiAgYW5zd2VyMSk8L0ZPTlQ+PC9TUEFOPjwvRElWPg0K ICA8RElWPjxTUEFOIGNsYXNzPTc4NzMzMzcwNy0xMzA1MjAwNT48Rk9OVCBmYWNlPUFyaWFsIA0K ICBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7MjAwIG9rJm5ic3A7KGZvciBQUkFDSykm bmJzcDstLS0mZ3Q7Jm5ic3A7IA0KICA8L0ZPTlQ+PC9TUEFOPjwvRElWPjwvU1BBTj48L0RJVj4N CiAgPERJVj48U1BBTiBjbGFzcz03ODczMzM3MDctMTMwNTIwMDU+DQogIDxESVY+PFNQQU4gY2xh c3M9Nzg3MzMzNzA3LTEzMDUyMDA1PjxGT05UIGZhY2U9QXJpYWwgDQogIHNpemU9Mj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDtRcyAtLSBOb3cgaW4gdGhlIHN1YnNlcXVlbnQgMXh4IGFuZCAyeHgg DQogIHJlc3BvbnNlcywgaXMgaXQgb2sgaWYgbm8gc2RwIGlzIHNlbnQ/IEFuZCBpZiBzZHAgaGFz IHRvIGJlIHNlbnQsIA0KICB0aGVuJm5ic3A7Y2FuIGl0IGJlIGEmbmJzcDtuZXcgb2ZmZXI/PyA8 L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTc4NzMzMzcwNy0xMzA1MjAw NT48Rk9OVCBmYWNlPUFyaWFsIA0KICBzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4N CiAgPERJVj48U1BBTiBjbGFzcz03ODczMzM3MDctMTMwNTIwMDU+PEZPTlQgZmFjZT1BcmlhbCBz aXplPTI+UkZDIDMyNjEgbWFuZGF0ZXMgDQogIHNhbWUgc2RwIHRvIGJlIHNlbnQgaW4gc3Vic2Vx dWVudCAxeHggYW5kIDJ4eCwgYnV0IHRoYXQncyBvbmx5IGlmIGVhbGllciBzZHAgDQogIHdhcyBz ZW50IGluIG5vbi1yZWxpYWJsZSByZXNwb25zZXMuJm5ic3A7U28sIHdoYXQgc2hvdWxkIGJlIHRo ZSBjYXNlIHdoZW4gDQogIFBSQUNLIGlzIHRoZXJlPzwvRk9OVD48L1NQQU4+PC9ESVY+DQogIDxE SVY+PFNQQU4gY2xhc3M9Nzg3MzMzNzA3LTEzMDUyMDA1PjxGT05UIGZhY2U9QXJpYWwgDQogIHNp emU9Mj48L0ZPTlQ+PC9TUEFOPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjwvRk9OVD48Rk9OVCBm YWNlPUFyaWFsIA0KICBzaXplPTI+PC9GT05UPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjwvRk9O VD48Rk9OVCBmYWNlPUFyaWFsIA0KICBzaXplPTI+PC9GT05UPjxGT05UIGZhY2U9QXJpYWwgc2l6 ZT0yPjwvRk9OVD48Rk9OVCBmYWNlPUFyaWFsIA0KICBzaXplPTI+PC9GT05UPjwvU1BBTj48U1BB TiBjbGFzcz03ODczMzM3MDctMTMwNTIwMDU+PEZPTlQgZmFjZT1BcmlhbCANCiAgc2l6ZT0yPjwv Rk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9Nzg3MzMz NzA3LTEzMDUyMDA1PjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgDQogIHNpemU9Mj48U1RST05HPlNj ZW5hcmlvIDM8L1NUUk9ORz4uIFVQREFURSBhbmQgMXh4IA0KICAobm9uLXJlbGlhYmxlKTwvRk9O VD48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTc4NzMzMzcwNy0xMzA1 MjAwNT4NCiAgPERJVj48U1BBTiBjbGFzcz03ODczMzM3MDctMTMwNTIwMDU+DQogIDxESVY+PFNQ QU4gY2xhc3M9Nzg3MzMzNzA3LTEzMDUyMDA1PjwvU1BBTj48U1BBTiANCiAgY2xhc3M9Nzg3MzMz NzA3LTEzMDUyMDA1PjxGT05UIGZhY2U9QXJpYWwgDQogIHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogICZsdDstLS0t Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElOVklURSh3 aXRoIG5vIA0KICBzZHApPC9GT05UPjwvU1BBTj48L0RJVj4NCiAgPERJVj48U1BBTiBjbGFzcz03 ODczMzM3MDctMTMwNTIwMDU+DQogIDxESVY+PFNQQU4gY2xhc3M9Nzg3MzMzNzA3LTEzMDUyMDA1 PjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyANCiAgMXh4ICh3aXRo IG9mZmVyMSkobm90IHJlbGlhYmxlKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy0tLSZn dDsmbmJzcDsgDQogIDwvRk9OVD4NCiAgPERJVj48U1BBTiBjbGFzcz03ODczMzM3MDctMTMwNTIw MDU+PEZPTlQgZmFjZT1BcmlhbCANCiAgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1VQ REFURSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy0tLSZndDsmbmJzcDsgDQogIDwvRk9O VD48L1NQQU4+PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9Nzg3MzMzNzA3LTEzMDUyMDA1PjxG T05UIGZhY2U9QXJpYWwgDQogIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPjwvU1BB Tj48L0RJVj48L1NQQU4+PFNQQU4gDQogIGNsYXNzPTc4NzMzMzcwNy0xMzA1MjAwNT48L1NQQU4+ PC9ESVY+PC9TUEFOPjwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTc4NzMzMzcwNy0xMzA1MjAw NT4NCiAgPERJVj48U1BBTiBjbGFzcz03ODczMzM3MDctMTMwNTIwMDU+PEZPTlQgZmFjZT1Bcmlh bCANCiAgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1FzIC0tIE5vdyB0aGUgYWJvdmUg VVBEQVRFIGhhcyB0byBoYXZlIGEgbmV3IA0KICBvZmZlciBvciBzYW1lIG9mZmVyMT8gPC9GT05U PjwvU1BBTj48L0RJVj4NCiAgPERJVj48U1BBTiBjbGFzcz03ODczMzM3MDctMTMwNTIwMDU+PEZP TlQgZmFjZT1BcmlhbCANCiAgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogIDxE SVY+PFNQQU4gY2xhc3M9Nzg3MzMzNzA3LTEzMDUyMDA1PjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0y PlRoYW5rcyBpbiANCiAgYWR2YW5jZTwvRk9OVD48L1NQQU4+PC9ESVY+DQogIDxESVY+PFNQQU4g Y2xhc3M9Nzg3MzMzNzA3LTEzMDUyMDA1PjxGT05UIGZhY2U9QXJpYWwgDQogIHNpemU9Mj5SZ2Rz PC9GT05UPjwvU1BBTj48L0RJVj4NCiAgPERJVj48U1BBTiBjbGFzcz03ODczMzM3MDctMTMwNTIw MDU+PEZPTlQgZmFjZT1BcmlhbCANCiAgc2l6ZT0yPlJldGVzaDwvRk9OVD48L1NQQU4+PC9ESVY+ PC9TUEFOPjwvRElWPjwvU1BBTj48L0RJVj4NCiAgPERJVj48U1BBTiBjbGFzcz03ODczMzM3MDct MTMwNTIwMDU+PEZPTlQgZmFjZT1BcmlhbCANCiAgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7 PC9ESVY+PC9CTE9DS1FVT1RFPjwvQk9EWT48L0hUTUw+DQo= ------_=_NextPart_001_01C55A8F.26240488-- --===============2091883448== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2091883448==-- From sip-bounces@ietf.org Tue May 17 10:27:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY32z-0006Pf-Nx; Tue, 17 May 2005 10:27:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY32x-0006OQ-Pg for sip@megatron.ietf.org; Tue, 17 May 2005 10:27:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29837 for ; Tue, 17 May 2005 10:27:45 -0400 (EDT) Received: from natfrord.rzone.de ([81.169.145.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY3JT-0001yQ-Bs for sip@ietf.org; Tue, 17 May 2005 10:44:55 -0400 Received: from snom.de ([195.2.174.186]) by post.webmailer.de (8.13.1/8.13.1) with ESMTP id j4HERLTX026816; Tue, 17 May 2005 16:27:22 +0200 (MEST) Received: from quickstep.intern.snom.de ([192.168.0.56]) by snom.de with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 May 2005 16:31:29 +0200 From: Nils Ohlmeier Organization: snom technology AG To: sip@ietf.org Subject: Re: [Sip] Doubts about 305 Use Proxy? Date: Tue, 17 May 2005 16:26:49 +0200 User-Agent: KMail/1.8 References: <200505131711.57480.Nils.Ohlmeier@snom.de> <4285F505.8050205@cisco.com> <42889051.8070607@cisco.com> In-Reply-To: <42889051.8070607@cisco.com> X-Face: $bH@U>Mk-Y, <=?utf-8?q?R=60=27!8yXtr=5C/+=3B=5Do=3D=7BX5e4Zg=5DCU=25yS3aY=0A=09b=23X?= =?utf-8?q?=5D2KSW!b+?=(Q'%8w!#x^tS7ScTxwC@4mS}C%:j*s)Z_:Ry-m("k`elxv}tM" =?utf-8?q?M8=27=5EM8N=7CC=0A=09=25fYIY=3DskM=3A=60THz-l7=24c/iKcjtk=60?=, $Kzs}n:rD`Mh9Q]naI7)"uq}8N6f~!Aj>SaO, n2< =?utf-8?q?rZ=0A=09?= X-OriginalArrivalTime: 17 May 2005 14:31:29.0750 (UTC) FILETIME=[1D6F2760:01C55AED] X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Content-Transfer-Encoding: 7bit Cc: Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org An new RFC just for one reply (which I never saw up to now in real life) sounds a little bit too much to me :-) An entry in bugs.sipit.net sounds fair to me. Allthough the recommendation for now probably should be to avoid 305, as the essential consuming of this reply at a proxy is not specified yet. But to be honest I never came to idea of taking the Contact from the 305 as the first hop in the Route. I guess a lot of people are going to implement the handling of 305 as similar as possible to 30[12]. That was the reason why I asked for the username. The 302 solution with the Route sounds very dangerous to me. If I remember correct it is somewhere mentioned that you should expand headers with caution. And as implementor without having thought too much about it, I would drop such a Route header from a header expansion. Then this reply would not help much any more. Thanks for the clarification Nils Ohlmeier On Monday 16 May 2005 14:21, Jonathan Rosenberg wrote: > If folks think this is a reasonable path, I can enter a bug report into > bugs.sipit.net. I don't know where else such a clarification would go, > unless we want to write an I-D and publish an RFC just for this topic... > > Chairs? > > -Jonathan R. > > Paul Kyzivat wrote: > > Jonathan, > > > > Thanks for the perspective of an author. The intended meaning of 305 has > > been a question to me for a long time. > > > > It seems like there is at least one action item out of this - some kind > > of clarification of 305 handling to at least remove the bug that results > > in failure or looping if the 305 is relayed back to the caller. > > > > IMO the minimal requirement is that a proxy that translated the R-URI > > MUST NOT forward the 305 response on upstream. Instead, it must consume > > and act on it in some way - recursing or returning some other response. > > > > BTW, I agree that my suggestion of turning the 305 into a 302 with Route > > header embedded in the Contact is not a great solution. I was just > > grasping at straws. > > > > Paul > > > > Jonathan Rosenberg wrote: > >> I've been thinking about exactly this issue recently. More inline. > >> > >> Paul Kyzivat wrote: > >>>> According to page 184 of RFC3261 Carol should send the contact of > >>>> the proxy which should be used. (Maybe I miss-interpret the words > >>>> "URI of the proxy", but for 30[12] the term "new address" is being > >>>> used.) > >>>> The problem is: which username the receiver of the 305 should use? > >>> > >>> IMO this says to include a proxy, but does not say to change the > >>> R-URI at all, so there is no question about what username to use. > >> > >> Right. The URI should be used as is. > >> > >>>> If biloxi.com takes care of the redirection, it would probably try > >>>> carol@chicago.com. No problem. > >>> > >>> I don't think so. If biloxy recurses on the 305, then I would expect > >>> it to send an invite something like: > >>> > >>> INVITE sip:carol@UA-IP > >>> Route: sip:chicago.com > >>> ... > >> > >> Right. I don't think the spec is clear on this at all, in fact. It > >> doesnt say anywhere to populate the Contact header field of the > >> redirect into a Route header field, but I think this makes a lot of > >> sense for the meaning of 305. > >> > >>>> But if the 305 travels back to Alice, what should be the new request > >>>> URI? bob@chicago.com? > >>> > >>> This is a bit tricky, and I'm not sure it can work right. > >>> > >>> Presumably for the original part of the flow to work, the original > >>> invite from Alice must have looked something like: > >>> > >>> INVITE sip:bob@atlanta.com > >>> ... > >>> > >>> It may or may not have had a Route header for atlanta.com. Lets > >>> assume not. > >>> > >>> So then after receiving the 305, alice would IMO need to try: > >>> > >>> INVITE sip:bob@atlanta.com > >>> Route: sip:chicago.com > >>> ... > >>> > >>> And then because of the route header, this would be delivered > >>> directly to chicago.com, bypassing atlanta.com. Of course, > >>> chicago.com isn't responsible for uris at atlanta.com, and doesn't > >>> know this is intended for bob. So it will likely do one of two things: > >>> - refuse the request outright, causing the call to fail. > >>> > >>> - act as a transit node: Remove the route header, and then forward > >>> the request according to normal sip routing rules, to atlanta.com. > >>> This would then proceed just as in your call flow, and fail with > >>> another 305 response. > >> > >> Yes, this is problematic. > >> > >>> The only way I can see to make this work if biloxy doesn't want to > >>> recurse is for biloxy to capture the 305 error and generate its own > >>> 302 error with a contact like: > >>> > >>> Contact: > >>> > >>> (excaping omitted to preserve readability) > >>> > >>> With that response, alice would generate a new invite like > >>> > >>> INVITE sip:carol@UA-IP > >>> Route: sip:chicago.com > >>> ... > >>> > >>> and then the right thing will happen. > >> > >> Thats one possible solution, but I don't think its what a proxy should > >> normally do. > >> > >> The first point to make on 305 is that I think its much like a 503. A > >> 503 response is always consumed by the previous hop and never > >> forwarded upstream. It has only local significance. I think the 305 is > >> the same. It is meant to tell the previous element that it ought to > >> forward the request to this server instead. By "instead", that means > >> replacing the Route header it may have just used to get to that > >> redirect server with this new one instead. By limiting it to the > >> previous hop, you ensure that the r-uri is the same as before and thus > >> these loops don't happen. > >> > >> So, when a proxy receives a 305, it can do one of several things: > >> > >> 1. recurse on it, by populating the Contact from the 305 into the > >> topmost Route of a new request (replacing the one that got us to the > >> redirect server previously), with the same request URI > >> > >> 2. forward a 4xx upstream > >> > >> 3. do the odd-but-allowed 302 Paul describes above > >> > >> No doubt there are other choices. However I think the first is almost > >> always the right one. > >> > >>> I would be interested in hearing from one of the 3261 authors about > >>> how they thought 305 was supposed to work in this case. > >> > >> I don't recall lots of discussions on 305 handling. There is nothing > >> in the spec at all on using the Contact to populate a Route header > >> field. Loose routing came fairly late in the development of 3261, and > >> its interactions with the 305 response were simply not considered. > >> > >> I've been considering the 305 response recently since its come up as a > >> potential solution to some other problems. Namely, cases where, within > >> a domain, you have multiple proxies running (for example an IMS) and > >> you want to use redirect instead of proxying to get from one to > >> another. We don't want to modify the request URI here; just get the > >> request sent elsewhere. > >> > >> In this usage, 305 is generated by a proxy, NOT a UAS. 3261 currently > >> forbids proxies from generating 305. The reason we put that > >> restriction in was to avoid cases where we saw loops when an outbound > >> proxy generated a redirect. Since the initial thinking was that the > >> Contact replaced the r-uri as always, this would just cause the new > >> request to come to the same outbound proxy again anyway and cause a > >> loop. > >> > >> The algorithm I suggest above avoids this loop but has the benefit of > >> working when the redirect is generated by any element, not just a UAS. > >> > >> -Jonathan R. -- snom technology AG Gradestr. 46 D-12347 Berlin Nils Ohlmeier mailto:nils.ohlmeier@snom.de http://www.snom.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 sip-bounces@ietf.org Wed May 18 01:05:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYGk8-0001cZ-I1; Wed, 18 May 2005 01:05:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYGk2-0001bb-9c; Wed, 18 May 2005 01:05:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26968; Wed, 18 May 2005 01:05:09 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYH0v-0002sL-49; Wed, 18 May 2005 01:22:37 -0400 Received: from esealmw128.eemea.ericsson.se ([153.88.254.121]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j4I558h5027198; Wed, 18 May 2005 07:05:08 +0200 (MEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 May 2005 07:05:07 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 May 2005 07:05:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 May 2005 07:05:06 +0200 Message-ID: Thread-Topic: New SDP session within old SIP session? Thread-Index: AcVbZyiGRP+/0encT6SXOzc5g9Wb5A== From: "Christer Holmberg \(JO/LMF\)" To: X-OriginalArrivalTime: 18 May 2005 05:05:07.0574 (UTC) FILETIME=[28E45960:01C55B67] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org Subject: [Sip] New SDP session within old SIP session? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, Chapter 8 (Modifying the session) in RFC3264 says the following: =20 "When issuing an offer that modifies the session, the "o=3D" line of the = new SDP MUST be identical to that in the previous SDP, except that the version in the origin field MUST increment = by one from the previous SDP. If the version in the origin line does = not increment, the SDP MUST be identical to the SDP with that version = number. The answerer MUST be prepared to receive an offer that contains = SDP with a version that has not changed; this is effectively a no-op. = However, the answerer MUST generate a valid answer (which MAY be the = same as the previous SDP from the answerer, or MAY be different), = according to the procedures defined in Section 6." My questions are: 1. The text says that when the session (I assume the text talks about an = SDP session, not a SIP session) is modified, the o=3D line must be = identical, except for the version part. But, is it allowed, within the = SAME SIP session, to offer a NEW SDP session, ie change the session-id = part of the o=3D line? The RFC doesn't describe it, but it doesn't seem = to forbid it either... 2. If the answer to the first question is "yes", how does it affect the = rules about matching m=3D lines etc? If I offer a new SDP session, does = the offer still have to contain the same number (or more) of m=3D lines = as the previous offer, which was for the old SDP session? Regards, Christer Holmberg LM Ericsson _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 18 04:45:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYKB3-00055G-W7; Wed, 18 May 2005 04:45:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYKB1-00054S-Ta for sip@megatron.ietf.org; Wed, 18 May 2005 04:45:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19196 for ; Wed, 18 May 2005 04:45:13 -0400 (EDT) Received: from smtp13.clb.oleane.net ([213.56.31.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYKRw-0005o4-81 for sip@ietf.org; Wed, 18 May 2005 05:02:44 -0400 Received: from Pavillonquatre (upperside.rain.fr [194.206.151.59] (may be forged)) (authenticated) by smtp13.clb.oleane.net with ESMTP id j4I8j0WW002160 for ; Wed, 18 May 2005 10:45:02 +0200 Message-Id: <200505180845.j4I8j0WW002160@smtp13.clb.oleane.net> From: "Chantal Ladouce" To: Date: Wed, 18 May 2005 10:45:00 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVbheBg4YRDSiY+RBGZqGx1XWbBVw== X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Subject: [Sip] International SIP - Paris - France X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1944180849==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1944180849== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01C55B96.A42271F0" This is a multi-part message in MIME format. ------=_NextPart_000_0021_01C55B96.A42271F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The 7th edition of International SIP will stand in Paris next 21-24 February 2006. A call for proposal has been launched at: http://www.upperside.fr/sip2006/sip2006cfp.htm Proposals will be reviewed by the conference scientific committee. ------=_NextPart_000_0021_01C55B96.A42271F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The 7th edition of International SIP will = stand in Paris next = 21-24 February 2006.

A call for proposal has been launched = at:

http://www.upperside.fr/sip2006/sip2006cfp.htm

Proposals will be reviewed by the conference scientific committee.

 

------=_NextPart_000_0021_01C55B96.A42271F0-- --===============1944180849== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1944180849==-- From sip-bounces@ietf.org Wed May 18 08:56:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYO68-0005wO-Ve; Wed, 18 May 2005 08:56:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYO64-0005rx-GZ; Wed, 18 May 2005 08:56:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15121; Wed, 18 May 2005 08:56:22 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYOMz-00046X-L7; Wed, 18 May 2005 09:13:56 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 18 May 2005 09:12:16 -0400 X-IronPort-AV: i="3.93,118,1115006400"; d="scan'208"; a="49931733:sNHT27981160" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4ICtXnm004169; Wed, 18 May 2005 08:56:10 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 May 2005 08:55:44 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 May 2005 08:55:44 -0400 Message-ID: <428B3B4E.40205@cisco.com> Date: Wed, 18 May 2005 08:55:42 -0400 From: Paul Kyzivat 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: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] New SDP session within old SIP session? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 May 2005 12:55:44.0505 (UTC) FILETIME=[E76A1690:01C55BA8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, mmusic@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Christer Holmberg (JO/LMF) wrote: > Hi, > > Chapter 8 (Modifying the session) in RFC3264 says the following: > > "When issuing an offer that modifies the session, the "o=" line of the new SDP MUST be identical to that in the > previous SDP, except that the version in the origin field MUST increment by one from the previous SDP. If the version in the origin line does not increment, the SDP MUST be identical to the SDP with that version number. The answerer MUST be prepared to receive an offer that contains SDP with a version that has not changed; this is effectively a no-op. However, the answerer MUST generate a valid answer (which MAY be the same as the previous SDP from the answerer, or MAY be different), according to the procedures defined in Section 6." > > My questions are: > > 1. The text says that when the session (I assume the text talks about an SDP session, not a SIP session) is modified, the o= line must be identical, except for the version part. But, is it allowed, within the SAME SIP session, to offer a NEW SDP session, ie change the session-id part of the o= line? The RFC doesn't describe it, but it doesn't seem to forbid it either... I have always assumed that you may only modify the existing session. (If you want to establish a new one you can use INVITE/Replaces.) It might be interesting to consider relaxing this, but I think it would open Pandora's Box. Note that it is the *offerer* that modifies an existing session. The answerer isn't constrained this way. It is only constrained by offer/answer to provide an answer consistent with the offer. Without this it would be more difficult to make 3pcc work. So, by sending offers in opposite directions it is possible to fully change the O-lines on both ends. Paul > 2. If the answer to the first question is "yes", how does it affect the rules about matching m= lines etc? If I offer a new SDP session, does the offer still have to contain the same number (or more) of m= lines as the previous offer, which was for the old SDP session? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 18 10:04:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYPA5-0004N1-EE; Wed, 18 May 2005 10:04:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYPA2-0004Ms-CQ; Wed, 18 May 2005 10:04:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22774; Wed, 18 May 2005 10:04:31 -0400 (EDT) Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYPQy-0008NO-GZ; Wed, 18 May 2005 10:22:05 -0400 Received: from keywest (hide.pingtel.com [65.220.123.2]) by mail.pingtel.com (Postfix) with SMTP id BE6E46C019; Wed, 18 May 2005 10:04:29 -0400 (EDT) From: "Dale Worley" To: , Subject: RE: [Sip] New SDP session within old SIP session? Date: Wed, 18 May 2005 10:03:46 -0400 Message-ID: <005001c55bb2$6a585f90$6a01010a@keywest> 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.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > From: Christer Holmberg (JO/LMF) > > My questions are: > > 1. The text says that when the session (I assume the text > talks about an SDP session, not a SIP session) is modified, > the o= line must be identical, except for the version part. > But, is it allowed, within the SAME SIP session, to offer a > NEW SDP session, ie change the session-id part of the o= > line? The RFC doesn't describe it, but it doesn't seem to > forbid it either... I've been assuming that the section in question would be better phrased: "When issuing an offer that modifies the SDP of the SIP session, the "o=" line of the new SDP MUST be identical to that in the previous SDP, except that the version in the origin field MUST increment by one from the previous SDP. Alternatively, the version in the origin line is not incremented and the SDP MUST be identical to the SDP with that version number. ..." So I would say that it is assumed that you cannot start a different SDP session within the SIP session. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 18 12:44:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYRer-0007ul-Dg; Wed, 18 May 2005 12:44:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYRep-0007ud-O0; Wed, 18 May 2005 12:44:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11022; Wed, 18 May 2005 12:44:26 -0400 (EDT) Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYRvi-0000ol-DG; Wed, 18 May 2005 13:02:03 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4IGi90c382920; Wed, 18 May 2005 12:44:11 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4IGi9rR237892; Wed, 18 May 2005 10:44:09 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4IGi8Ho006028; Wed, 18 May 2005 10:44:09 -0600 Received: from [9.1.115.65] ([9.1.115.65]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4IGi8Nv005956; Wed, 18 May 2005 10:44:08 -0600 Message-ID: <428B70D6.8030501@us.ibm.com> Date: Wed, 18 May 2005 09:44:06 -0700 From: "JOHN J. BARTON" User-Agent: Mozilla Thunderbird 0.9 (X11/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dale Worley Subject: Re: [Sip] New SDP session within old SIP session? References: <005001c55bb2$6a585f90$6a01010a@keywest> In-Reply-To: <005001c55bb2$6a585f90$6a01010a@keywest> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, mmusic@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Is there really two different things, one a "SIP-session" and the other an "SDP-session"? I thought not: there is just a session, initiated by SIP and described by SDP. So my version would be: "When issuing an offer that modifies the SDP of the session, the "o=" line of the new SDP MUST be identical to that in the previous SDP, except that the version in the origin field MUST increment by one from the previous SDP. Alternatively, the version in the origin line is not incremented and the SDP MUST be identical to the SDP with that version number. " Then I would say that the concept of "a different SDP session" is meaningless. There is only a session. An offer that modifies the SDP offers a modification of that session. The purpose of incrementing the version is to signal the modification. No increment means no modification. Are there really two different sessions, an inner and outer kind? John. Dale Worley wrote: >>From: Christer Holmberg (JO/LMF) >> >>My questions are: >> >>1. The text says that when the session (I assume the text >>talks about an SDP session, not a SIP session) is modified, >>the o= line must be identical, except for the version part. >>But, is it allowed, within the SAME SIP session, to offer a >>NEW SDP session, ie change the session-id part of the o= >>line? The RFC doesn't describe it, but it doesn't seem to >>forbid it either... > > > I've been assuming that the section in question would be better phrased: > > "When issuing an offer that modifies the SDP of the SIP session, the "o=" > line of the new SDP MUST be identical to that in the > previous SDP, except that the version in the origin field > MUST increment by one from the previous SDP. Alternatively, the version > in the origin line is not incremented and the SDP MUST be > identical to the SDP with that version number. ..." > > So I would say that it is assumed that you cannot start a different SDP > session within the SIP session. > > Dale > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- John J. Barton IBM Almaden Research Center http://www.almaden.ibm.com/cs/people/bartonjj/index.htm _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 18 13:39:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYSW6-00071b-BU; Wed, 18 May 2005 13:39:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYSW1-0006zz-6B; Wed, 18 May 2005 13:39:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16414; Wed, 18 May 2005 13:39:27 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYSmz-00037E-RH; Wed, 18 May 2005 13:57:03 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 18 May 2005 13:55:23 -0400 X-IronPort-AV: i="3.93,118,1115006400"; d="scan'208"; a="49989101:sNHT30343942" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4IHcVeM022897; Wed, 18 May 2005 13:39:15 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 May 2005 13:39:15 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 May 2005 13:39:14 -0400 Message-ID: <428B7DC2.7010500@cisco.com> Date: Wed, 18 May 2005 13:39:14 -0400 From: Paul Kyzivat 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: "JOHN J. BARTON" Subject: Re: [Sip] New SDP session within old SIP session? References: <005001c55bb2$6a585f90$6a01010a@keywest> <428B70D6.8030501@us.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 May 2005 17:39:14.0890 (UTC) FILETIME=[8264DAA0:01C55BD0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, mmusic@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org JOHN J. BARTON wrote: > Is there really two different things, one a "SIP-session" and the other > an "SDP-session"? I thought not: there is just a session, initiated by > SIP and described by SDP. So my version would be: > > > "When issuing an offer that modifies the SDP of the session, the "o=" > line of the new SDP MUST be identical to that in the > previous SDP, except that the version in the origin field > MUST increment by one from the previous SDP. Alternatively, the version > in the origin line is not incremented and the SDP MUST be > identical to the SDP with that version number. " > > Then I would say that the concept of "a different SDP session" is > meaningless. There is only a session. An offer that modifies the SDP > offers a modification of that session. The purpose of incrementing the > version is to signal the modification. No increment means no modification. > > Are there really two different sessions, an inner and outer kind? I think there is a difference here, although we may not have the terminology to discuss it concisely. As with most things having to do with offer/answer, 3pcc brings out the corner cases. Consider: |---------------C | A------------B | |---------------D where A,C,D are UAs and B is a B2BUA 3pcc controller. Initially B sets up a call between A and C. From a SIP signaling perspective there are two sessions: A-B and B-C. But if B did the 3pcc in the conventional way, relaying offers and answers, then there is a single media session A-C. Now consider what happens when B decides to transfer the call. It first sends an offerless reinvite to A, causing A to return an offer. A may choose to return an offer unchanged from before, or it may choose to include a change in the offer. B then decides not to relay that on to C, but instead to initiate a new session with D and send the offer there. Note that in this case the *answer* will have an o-line unrelated to the prior one. We end up with a different media session A-D. We continue to have the sip session A-B and a new one B-D. The old sip session B-C and media session A-C go away. 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 sip-bounces@ietf.org Wed May 18 14:09:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYSys-0007mL-0w; Wed, 18 May 2005 14:09:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYSyp-0007lw-O3; Wed, 18 May 2005 14:09:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19378; Wed, 18 May 2005 14:09:12 -0400 (EDT) Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYTFm-0004S4-19; Wed, 18 May 2005 14:26:48 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4II8vcu390800; Wed, 18 May 2005 14:08:57 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4II8urR245846; Wed, 18 May 2005 12:08:57 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4II8uNA006927; Wed, 18 May 2005 12:08:56 -0600 Received: from [9.1.115.65] ([9.1.115.65]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4II8u2X006901; Wed, 18 May 2005 12:08:56 -0600 Message-ID: <428B84B6.4020309@us.ibm.com> Date: Wed, 18 May 2005 11:08:54 -0700 From: "JOHN J. BARTON" User-Agent: Mozilla Thunderbird 0.9 (X11/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] New SDP session within old SIP session? References: <005001c55bb2$6a585f90$6a01010a@keywest> <428B70D6.8030501@us.ibm.com> <428B7DC2.7010500@cisco.com> In-Reply-To: <428B7DC2.7010500@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, mmusic@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org reply inline below... Paul Kyzivat wrote: > > > JOHN J. BARTON wrote: > >> Is there really two different things, one a "SIP-session" and the >> other an "SDP-session"? I thought not: there is just a session, >> initiated by SIP and described by SDP. So my version would be: >> >> >> "When issuing an offer that modifies the SDP of the session, the "o=" >> line of the new SDP MUST be identical to that in the >> previous SDP, except that the version in the origin field >> MUST increment by one from the previous SDP. Alternatively, the version >> in the origin line is not incremented and the SDP MUST be >> identical to the SDP with that version number. " >> >> Then I would say that the concept of "a different SDP session" is >> meaningless. There is only a session. An offer that modifies the SDP >> offers a modification of that session. The purpose of incrementing >> the version is to signal the modification. No increment means no >> modification. >> >> Are there really two different sessions, an inner and outer kind? > > > I think there is a difference here, although we may not have the > terminology to discuss it concisely. As with most things having to do > with offer/answer, 3pcc brings out the corner cases. Consider: > > |---------------C > | > A------------B > | > |---------------D > > where A,C,D are UAs and B is a B2BUA 3pcc controller. > > Initially B sets up a call between A and C. From a SIP signaling > perspective there are two sessions: A-B and B-C. But if B did the 3pcc > in the conventional way, relaying offers and answers, then there is a > single media session A-C. > > Now consider what happens when B decides to transfer the call. It first > sends an offerless reinvite to A, causing A to return an offer. A may > choose to return an offer unchanged from before, or it may choose to > include a change in the offer. B then decides not to relay that on to C, > but instead to initiate a new session with D and send the offer there. > > Note that in this case the *answer* will have an o-line unrelated to the > prior one. We end up with a different media session A-D. We continue to > have the sip session A-B and a new one B-D. The old sip session B-C and > media session A-C go away. I notice that you didn't need to say "SDP session" in your explanation. I see three sessions, AB BC and BD. During the transfer, the description of the AB session changes from the one BC negotiated to the one BD negotiated. So I believe that B is obligated by the standard to answer A's offer with an SDP containing A's o= line with an incremented version. This is B's answer to A's offer. It happens that B computed its answer by offering to D, but that does not matter to A. For A it's an AB session, not a BD or AD session. The AC and AD media sessions are no more of an issue than media sessions in conventional SIP. Whether RTP packets flow to C or B or D doesn't matter to SIP. Doesn't that sound right? > > Paul -- John J. Barton IBM Almaden Research Center http://www.almaden.ibm.com/cs/people/bartonjj/index.htm _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 18 15:43:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYURo-0002tS-IY; Wed, 18 May 2005 15:43:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYURj-0002sx-Hp; Wed, 18 May 2005 15:43:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29212; Wed, 18 May 2005 15:43:09 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYUih-00005X-LK; Wed, 18 May 2005 16:00:46 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 18 May 2005 15:59:01 -0400 X-IronPort-AV: i="3.93,118,1115006400"; d="scan'208"; a="50016605:sNHT30742924" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4IJgPng018272; Wed, 18 May 2005 15:42:52 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 May 2005 15:42:40 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 May 2005 15:42:39 -0400 Message-ID: <428B9AAF.40807@cisco.com> Date: Wed, 18 May 2005 15:42:39 -0400 From: Paul Kyzivat 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: "JOHN J. BARTON" Subject: Re: [Sip] New SDP session within old SIP session? References: <005001c55bb2$6a585f90$6a01010a@keywest> <428B70D6.8030501@us.ibm.com> <428B7DC2.7010500@cisco.com> <428B84B6.4020309@us.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 May 2005 19:42:39.0838 (UTC) FILETIME=[C0163FE0:01C55BE1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, mmusic@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org JOHN J. BARTON wrote: > reply inline below... > > Paul Kyzivat wrote: > >> >> >> JOHN J. BARTON wrote: >> >>> Is there really two different things, one a "SIP-session" and the >>> other an "SDP-session"? I thought not: there is just a session, >>> initiated by SIP and described by SDP. So my version would be: >>> >>> >>> "When issuing an offer that modifies the SDP of the session, the "o=" >>> line of the new SDP MUST be identical to that in the >>> previous SDP, except that the version in the origin field >>> MUST increment by one from the previous SDP. Alternatively, the version >>> in the origin line is not incremented and the SDP MUST be >>> identical to the SDP with that version number. " >>> >>> Then I would say that the concept of "a different SDP session" is >>> meaningless. There is only a session. An offer that modifies the >>> SDP offers a modification of that session. The purpose of >>> incrementing the version is to signal the modification. No increment >>> means no modification. >>> >>> Are there really two different sessions, an inner and outer kind? >> >> >> >> I think there is a difference here, although we may not have the >> terminology to discuss it concisely. As with most things having to do >> with offer/answer, 3pcc brings out the corner cases. Consider: >> >> |---------------C >> | >> A------------B >> | >> |---------------D >> >> where A,C,D are UAs and B is a B2BUA 3pcc controller. >> >> Initially B sets up a call between A and C. From a SIP signaling >> perspective there are two sessions: A-B and B-C. But if B did the 3pcc >> in the conventional way, relaying offers and answers, then there is a >> single media session A-C. >> >> Now consider what happens when B decides to transfer the call. It >> first sends an offerless reinvite to A, causing A to return an offer. >> A may choose to return an offer unchanged from before, or it may >> choose to include a change in the offer. B then decides not to relay >> that on to C, but instead to initiate a new session with D and send >> the offer there. >> >> Note that in this case the *answer* will have an o-line unrelated to >> the prior one. We end up with a different media session A-D. We >> continue to have the sip session A-B and a new one B-D. The old sip >> session B-C and media session A-C go away. > > > I notice that you didn't need to say "SDP session" in your explanation. > I see three sessions, AB BC and BD. Maybe I didn't say it, but I meant it. AB, BC, and BD are sip sessions. Those pairs have sip signaling relationships with one another. But there is no sip signaling relationship between AC or AD. However I can, arguably, make the case that there are SDP sessions AC and AD, and none involving B. This is because B is simply acting as a signaling relay. While A is aware of B and not C or D from a sip perspective, A is aware first of C and later of D from a media perspective, and is never involved with B for media. > During the transfer, the > description of the AB session changes from the one BC negotiated to the > one BD negotiated. So I believe that B is obligated by the standard to > answer A's offer with an SDP containing A's o= line with an incremented > version. This is B's answer to A's offer. It happens that B computed > its answer by offering to D, but that does not matter to A. For A it's > an AB session, not a BD or AD session. I will disagree with you there. That is certainly not the way 3pcc is usually implemented (though it could be), and it is not required by 3264. While there is a requirement on the offerer to use the old o-line, and increment the version if it changes, there is no corresponding requirement on the answerer. The answer can have any o-line as long as the answer is consistent with the offer. I agree there are some interesting applications where B manipulates the SDP, but there are many common cases where that is not required and the B2BUA can be simpler. > The AC and AD media sessions are no more of an issue than media sessions > in conventional SIP. Whether RTP packets flow to C or B or D doesn't > matter to SIP. > > Doesn't that sound right? I agree that you can choose to view it that way. But viewing B as uninvolved in the offer/answer is also a useful viewpoint. 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 sip-bounces@ietf.org Wed May 18 18:34:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYX7G-0002AU-JX; Wed, 18 May 2005 18:34:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYX7F-0002AM-35 for sip@megatron.ietf.org; Wed, 18 May 2005 18:34:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00293 for ; Wed, 18 May 2005 18:34:09 -0400 (EDT) Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYXOH-0003q5-8s for sip@ietf.org; Wed, 18 May 2005 18:51:49 -0400 Received: from unknown (HELO alpha.jnpr.net) (172.24.18.126) by kremlin.juniper.net with ESMTP; 18 May 2005 15:34:03 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,119,1115017200"; d="scan'208,217"; a="333629191:sNHT39293832" Received: from hadron.jnpr.net ([172.24.15.25]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 May 2005 15:34:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 18 May 2005 15:34:02 -0700 Message-ID: Thread-Topic: About Non-Invite Server Transaction Thread-Index: AcVb+bCqPoq7yVFuTcWU6GffA+Z/eQ== From: "Anil Bollineni" To: , X-OriginalArrivalTime: 18 May 2005 22:34:02.0657 (UTC) FILETIME=[B11FE910:01C55BF9] X-Spam-Score: 0.5 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Cc: Subject: [Sip] About Non-Invite Server Transaction X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0964610415==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0964610415== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55BF9.B0C45590" This is a multi-part message in MIME format. ------_=_NextPart_001_01C55BF9.B0C45590 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Assume a gateway sends two INVITE's say to two different UAS's with the same Via branch parameter to two different users at the same time. Here in this case the gateway adds one Via with its own address in sent-by field of Via.=20 Assume INVITE 1, is retransmitted, in this case the matching of requests at UAS, can result to the server transaction of INVITE 2. (Via branch, sent-by field, Request method, per 17.2.3 is same). How I should solve this scenario., branch parameter can be same by chance.=20 =20 Another question is, for non-INVITE server transaction, the server transaction is timeout until J timer fires. What is the purpose behind that. I understand for retransmitted non-INVITE requests it MUST result sending same response by UAS, or it is like that to reduce processing retransmitted request AGAIN by UAS. I have a doubt on two call flows with non-INVITE server transactions. a. Assume 200 response to BYE sent by server transaction, and 200 response is lost before it reaches UAC. If it send BYE again, does UAS has to retransmit 200 response? b. During transfer if a REFER is sent to UAS and say server transaction say transmit 503 (Declined), due to some temporary failures (e.g. user can't accept more calls), and assume this 503 is delayed. Aftr this failure cleared out, and REFER is retransmitted, and in this case the server transaction sends same error message, even though the user is not busy. First of all, am I mentioning the correct scenario.? If yes, what could be solution. =20 Thanks very much,=20 Anil =20 =20 =20 ------_=_NextPart_001_01C55BF9.B0C45590 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

         =    Assume a gateway sends two INVITE’s say to two different UAS’s with = the same Via branch parameter to two different users at the same time. Here = in this case the gateway adds one Via with its own address in sent-by field of = Via.

Assume INVITE 1, is retransmitted, in this case the = matching of requests at UAS, can result to the server transaction of INVITE 2. = (Via branch, sent-by field, Request method, per 17.2.3 is same). How I should = solve this scenario., branch parameter can be same by chance. =

 

Another question is, for non-INVITE server = transaction, the server transaction is timeout until J timer fires. What is the purpose = behind that. I understand for retransmitted non-INVITE requests it MUST result = sending same response by UAS, or it is like that to reduce processing retransmitted = request AGAIN by UAS. I have a doubt on two call flows with non-INVITE server = transactions.

a.       Assume 200 response to BYE sent by server = transaction, and 200 response is lost before it reaches UAC. If it send BYE again, = does UAS has to retransmit 200 =         response?

b.       During transfer if a REFER is sent to UAS and = say server transaction say transmit 503 (Declined), due to some temporary = failures (e.g. user can’t accept more calls), and assume this 503 is = delayed. Aftr this failure cleared out, and REFER is retransmitted, and in this case = the server transaction sends same error message, even though the user is not = busy. First of all, am I mentioning the correct scenario.? If yes, what could be = solution.

 

Thanks very much,

Anil

 

 

 

=00 ------_=_NextPart_001_01C55BF9.B0C45590-- --===============0964610415== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0964610415==-- From sip-bounces@ietf.org Wed May 18 20:32:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYYxl-0005ai-Mp; Wed, 18 May 2005 20:32:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYYxj-0005aa-Jt for sip@megatron.ietf.org; Wed, 18 May 2005 20:32:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10443 for ; Wed, 18 May 2005 20:32:27 -0400 (EDT) Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYZEj-0007Dp-NJ for sip@ietf.org; Wed, 18 May 2005 20:50:07 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id j4J0WHqF191628 for ; Thu, 19 May 2005 00:32:17 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4J0WH1P091064 for ; Thu, 19 May 2005 02:32:17 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j4J0WHxJ026047 for ; Thu, 19 May 2005 02:32:17 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j4J0WHDm026044 for ; Thu, 19 May 2005 02:32:17 +0200 MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_M4_01112005 Beta 3NP January 11, 2005 To: Message-ID: From: Avshalom Houri Date: Thu, 19 May 2005 03:32:15 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(V70_M4_01112005 Sidepack 2802|March 1, 2005) at 19/05/2005 03:32:16, Serialize complete at 19/05/2005 03:32:16 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Subject: [Sip] Preventing replay in ACK X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0313013961==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============0313013961== Content-Type: multipart/alternative; boundary="=_alternative 0002CAC4C2257006_=" This is a multipart message in MIME format. --=_alternative 0002CAC4C2257006_= Content-Type: text/plain; charset="US-ASCII" RFC 3261 22.1 While a server can legitimately challenge most SIP requests, there are two requests defined by this document that require special handling for authentication: ACK and CANCEL. Under an authentication scheme that uses responses to carry values used to compute nonces (such as Digest), some problems come up for any requests that take no response, including ACK. For this reason, any credentials in the INVITE that were accepted by a server MUST be accepted by that server for the ACK. UACs creating an ACK message will duplicate all of the Authorization and Proxy-Authorization header field values that appeared in the INVITE to which the ACK corresponds. Servers MUST NOT attempt to challenge an ACK. Logic says the UA should recalculate the authorization headers (using ACK as method) in order to prevent someone to send an ACK using the INVITE credentials. However text says duplicate. What is the right interpretation? Avshalom --=_alternative 0002CAC4C2257006_= Content-Type: text/html; charset="US-ASCII"
RFC 3261 22.1

While a server can legitimately challenge most SIP requests, there
  are two requests defined by this document that require special
  handling for authentication: ACK and CANCEL.
  Under an authentication scheme that uses responses to carry values
  used to compute nonces (such as Digest), some problems come up for
  any requests that take no response, including ACK.  For this reason,
  any credentials in the INVITE that were accepted by a server MUST be
  accepted by that server for the ACK.  UACs creating an ACK message
  will duplicate all of the Authorization and Proxy-Authorization
  header field values that appeared in the INVITE to which the ACK
  corresponds.  Servers MUST NOT attempt to challenge an ACK.

Logic says the UA should recalculate the authorization headers (using ACK as method)
in order to prevent someone to send an ACK using the INVITE credentials.
However text says duplicate.

What is the right interpretation?

Avshalom
--=_alternative 0002CAC4C2257006_=-- --===============0313013961== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0313013961==-- From sip-bounces@ietf.org Thu May 19 01:01:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYdA0-00017j-UP; Thu, 19 May 2005 01:01:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYd9s-00014Y-Ud for sip@megatron.ietf.org; Thu, 19 May 2005 01:01:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29623 for ; Thu, 19 May 2005 01:01:20 -0400 (EDT) Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYdQx-0005H0-7b for sip@ietf.org; Thu, 19 May 2005 01:19:00 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id j4J51GEN018197 for ; Wed, 18 May 2005 22:01:16 -0700 (MST) Received: from zin24exm01.ap.mot.com (zin24exm01.ap.mot.com [10.232.25.1]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id j4J53SvN013508 for ; Thu, 19 May 2005 00:03:29 -0500 (CDT) Received: by zin24exm01.ap.mot.com with Internet Mail Service (5.5.2657.72) id ; Thu, 19 May 2005 10:31:09 +0530 Message-ID: <772BCEF88A1DD91191F80011856715F3031F72FD@zin24exm01.ap.mot.com> From: Chadha Retesh-A19894 To: Avshalom Houri , sip@ietf.org Subject: RE: [Sip] Preventing replay in ACK Date: Thu, 19 May 2005 10:31:08 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 2.4 (++) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1228809434==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org 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. --===============1228809434== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55C2F.C48EC97C" 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_01C55C2F.C48EC97C Content-Type: text/plain I dont think UA should re-calculate the authorization header, for ACK. This is because ACK can not be challenged. Need of authorization header is only to make sure, that the ACK is coming from already authenticated UAC. Correct interpretation is to duplicate all of the Authorization and Proxy-Authorization header field values that appeared in the INVITE to which the ACK corresponds. Regards Retesh -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Avshalom Houri Sent: Thursday, May 19, 2005 6:02 AM To: sip@ietf.org Subject: [Sip] Preventing replay in ACK RFC 3261 22.1 While a server can legitimately challenge most SIP requests, there are two requests defined by this document that require special handling for authentication: ACK and CANCEL. Under an authentication scheme that uses responses to carry values used to compute nonces (such as Digest), some problems come up for any requests that take no response, including ACK. For this reason, any credentials in the INVITE that were accepted by a server MUST be accepted by that server for the ACK. UACs creating an ACK message will duplicate all of the Authorization and Proxy-Authorization header field values that appeared in the INVITE to which the ACK corresponds. Servers MUST NOT attempt to challenge an ACK. Logic says the UA should recalculate the authorization headers (using ACK as method) in order to prevent someone to send an ACK using the INVITE credentials. However text says duplicate. What is the right interpretation? Avshalom ------_=_NextPart_001_01C55C2F.C48EC97C Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KPFRJVExFPk1lc3NhZ2U8L1RJVExF Pg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yODAwLjE0NzkiIG5hbWU9R0VORVJBVE9S PjwvSEVBRD4NCjxCT0RZPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6 ZT0yPjxTUEFOIGNsYXNzPTI4OTUyNTcwNC0xOTA1MjAwNT5JIGRvbnQgDQp0aGluayBVQSBzaG91 bGQgcmUtY2FsY3VsYXRlIHRoZSBhdXRob3JpemF0aW9uIGhlYWRlciwgZm9yIEFDSy4gVGhpcyBp cyBiZWNhdXNlIA0KQUNLIGNhbiBub3QgYmUgY2hhbGxlbmdlZC4gTmVlZCBvZiBhdXRob3JpemF0 aW9uIGhlYWRlciBpcyBvbmx5IHRvIG1ha2Ugc3VyZSwgDQp0aGF0IHRoZSBBQ0sgaXMgY29taW5n IGZyb20gYWxyZWFkeSBhdXRoZW50aWNhdGVkIFVBQy48L1NQQU4+PC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9Mjg5 NTI1NzA0LTE5MDUyMDA1PjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gDQpjbGFzcz0yODk1MjU3MDQtMTkw NTIwMDU+Q29ycmVjdCBpbnRlcnByZXRhdGlvbiBpcyB0byA8Rk9OVCBmYWNlPSJDb3VyaWVyIE5l dyIgDQpjb2xvcj0jMDAwMDAwIHNpemU9Mz5kdXBsaWNhdGUgYWxsIG9mIHRoZSBBdXRob3JpemF0 aW9uIGFuZCANClByb3h5LUF1dGhvcml6YXRpb248QlI+Jm5ic3A7IGhlYWRlciBmaWVsZCB2YWx1 ZXMgdGhhdCBhcHBlYXJlZCBpbiB0aGUgSU5WSVRFIHRvIA0Kd2hpY2ggdGhlIEFDSzxCUj4mbmJz cDsgY29ycmVzcG9uZHMuPC9GT05UPjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9IkNvdXJpZXIgTmV3IiBjb2xvcj0jMDAwMDAwIHNpemU9Mz48U1BBTiANCmNsYXNzPTI4OTUy NTcwNC0xOTA1MjAwNT48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNl PUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIGNsYXNzPTI4OTUyNTcwNC0xOTA1MjAw NT48U1BBTiANCmNsYXNzPTI4OTUyNTcwNC0xOTA1MjAwNT5SZWdhcmRzPC9TUEFOPjwvU1BBTj48 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+ PFNQQU4gY2xhc3M9Mjg5NTI1NzA0LTE5MDUyMDA1PjxTUEFOIA0KY2xhc3M9Mjg5NTI1NzA0LTE5 MDUyMDA1PlJldGVzaDwvU1BBTj48L1NQQU4+PC9GT05UPjwvRElWPg0KPEJMT0NLUVVPVEUgc3R5 bGU9Ik1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgPERJVj48L0RJVj4NCiAgPERJViBjbGFzcz1PdXRs b29rTWVzc2FnZUhlYWRlciBsYW5nPWVuLXVzIGRpcj1sdHIgYWxpZ249bGVmdD48Rk9OVCANCiAg ZmFjZT1UYWhvbWEgc2l6ZT0yPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPEJSPjxCPkZyb206 PC9CPiANCiAgc2lwLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzaXAtYm91bmNlc0BpZXRmLm9y Z10gPEI+T24gQmVoYWxmIE9mIA0KICA8L0I+QXZzaGFsb20gSG91cmk8QlI+PEI+U2VudDo8L0I+ IFRodXJzZGF5LCBNYXkgMTksIDIwMDUgNjowMiANCiAgQU08QlI+PEI+VG86PC9CPiBzaXBAaWV0 Zi5vcmc8QlI+PEI+U3ViamVjdDo8L0I+IFtTaXBdIFByZXZlbnRpbmcgcmVwbGF5IGluIA0KICBB Q0s8QlI+PEJSPjwvRk9OVD48L0RJVj48QlI+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj5S RkMgMzI2MSAyMi4xPC9GT05UPiANCiAgPEJSPjxCUj48Rk9OVCBzaXplPTM+PFRUPldoaWxlIGEg c2VydmVyIGNhbiBsZWdpdGltYXRlbHkgY2hhbGxlbmdlIG1vc3QgU0lQIA0KICByZXF1ZXN0cywg dGhlcmU8QlI+Jm5ic3A7IGFyZSB0d28gcmVxdWVzdHMgZGVmaW5lZCBieSB0aGlzIGRvY3VtZW50 IHRoYXQgDQogIHJlcXVpcmUgc3BlY2lhbDxCUj4mbmJzcDsgaGFuZGxpbmcgZm9yIGF1dGhlbnRp Y2F0aW9uOiBBQ0sgYW5kIA0KICBDQU5DRUwuPEJSPiZuYnNwOyBVbmRlciBhbiBhdXRoZW50aWNh dGlvbiBzY2hlbWUgdGhhdCB1c2VzIHJlc3BvbnNlcyB0byBjYXJyeSANCiAgdmFsdWVzPEJSPiZu YnNwOyB1c2VkIHRvIGNvbXB1dGUgbm9uY2VzIChzdWNoIGFzIERpZ2VzdCksIHNvbWUgcHJvYmxl bXMgY29tZSANCiAgdXAgZm9yPEJSPiZuYnNwOyBhbnkgcmVxdWVzdHMgdGhhdCB0YWtlIG5vIHJl c3BvbnNlLCBpbmNsdWRpbmcgQUNLLiAmbmJzcDtGb3IgDQogIHRoaXMgcmVhc29uLDxCUj4mbmJz cDsgYW55IGNyZWRlbnRpYWxzIGluIHRoZSBJTlZJVEUgdGhhdCB3ZXJlIGFjY2VwdGVkIGJ5IGEg DQogIHNlcnZlciBNVVNUIGJlPEJSPiZuYnNwOyBhY2NlcHRlZCBieSB0aGF0IHNlcnZlciBmb3Ig dGhlIEFDSy4gJm5ic3A7VUFDcyANCiAgY3JlYXRpbmcgYW4gQUNLIG1lc3NhZ2U8QlI+Jm5ic3A7 IHdpbGwgZHVwbGljYXRlIGFsbCBvZiB0aGUgQXV0aG9yaXphdGlvbiBhbmQgDQogIFByb3h5LUF1 dGhvcml6YXRpb248QlI+Jm5ic3A7IGhlYWRlciBmaWVsZCB2YWx1ZXMgdGhhdCBhcHBlYXJlZCBp biB0aGUgSU5WSVRFIA0KICB0byB3aGljaCB0aGUgQUNLPEJSPiZuYnNwOyBjb3JyZXNwb25kcy4g Jm5ic3A7U2VydmVycyBNVVNUIE5PVCBhdHRlbXB0IHRvIA0KICBjaGFsbGVuZ2UgYW4gQUNLLjwv VFQ+PC9GT05UPiA8QlI+PEJSPjxGT05UIGZhY2U9Q291cmllciBzaXplPTM+TG9naWMgc2F5cyB0 aGUgDQogIFVBIHNob3VsZCByZWNhbGN1bGF0ZSB0aGUgYXV0aG9yaXphdGlvbiBoZWFkZXJzICh1 c2luZyBBQ0sgYXMgbWV0aG9kKTwvRk9OVD4gDQogIDxCUj48Rk9OVCBmYWNlPUNvdXJpZXIgc2l6 ZT0zPmluIG9yZGVyIHRvIHByZXZlbnQgc29tZW9uZSB0byBzZW5kIGFuIEFDSyB1c2luZyANCiAg dGhlIElOVklURSBjcmVkZW50aWFscy48L0ZPTlQ+IDxCUj48Rk9OVCBmYWNlPUNvdXJpZXIgc2l6 ZT0zPkhvd2V2ZXIgdGV4dCBzYXlzIA0KICBkdXBsaWNhdGUuPC9GT05UPiA8QlI+PEJSPjxGT05U IGZhY2U9Q291cmllciBzaXplPTM+V2hhdCBpcyB0aGUgcmlnaHQgDQogIGludGVycHJldGF0aW9u PzwvRk9OVD4gPEJSPjxCUj48Rk9OVCBmYWNlPUNvdXJpZXIgc2l6ZT0zPkF2c2hhbG9tPC9GT05U PiANCjxCUj48L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRNTD4NCg== ------_=_NextPart_001_01C55C2F.C48EC97C-- --===============1228809434== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1228809434==-- From sip-bounces@ietf.org Thu May 19 04:37:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYgX4-0007HC-SC; Thu, 19 May 2005 04:37:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYgX2-0007Gx-47 for sip@megatron.ietf.org; Thu, 19 May 2005 04:37:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05583 for ; Thu, 19 May 2005 04:37:26 -0400 (EDT) Received: from [151.39.82.129] (helo=mail.abbeynet.it) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYgo8-0001ng-K1 for sip@ietf.org; Thu, 19 May 2005 04:55:10 -0400 Received: from admin.abbeynet.it (localhost.localdomain [127.0.0.1]) by mail.abbeynet.it (Postfix) with SMTP id C893B332767 for ; Thu, 19 May 2005 10:37:15 +0200 (CEST) Received: from mail.abbeynet.it ([127.0.0.1]) by admin.abbeynet.it ([151.39.82.129]) with SMTP (gateway) id A02D1C8638D; Thu, 19 May 2005 10:37:15 +0200 Received: from gia (giacomo.localnet [192.168.0.158]) by mail.abbeynet.it (Postfix) with ESMTP id 43E3F332767 for ; Thu, 19 May 2005 10:37:15 +0200 (CEST) From: "Giacomo Vacca" To: Subject: [SIP] Multiple instances of same UA: How to distinguish them? Date: Thu, 19 May 2005 10:37:14 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVcTfVIOUW5+zQIQHOFf6pQOQTv+g== Message-Id: <20050519083715.43E3F332767@mail.abbeynet.it> X-Spam-Score: 0.5 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0878547058==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0878547058== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01C55C5E.B9168830" This is a multi-part message in MIME format. ------=_NextPart_000_0028_01C55C5E.B9168830 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi All, Take this scenario: I have a SIP Phone in my office, and I use my account: UserID: giacomo, Password: ****, registering to "myregistrar.domain". Now, in order to use the same service I want to use the same account at home. So I register mysoftphone with same UserID, password and in the same registrar "myregistrar.domain" from home. Suppose that the registrar allows this multiple registration for the same UserID, adding the home contact to the previous office contact. The question is: "Is there a way for the Proxy/Registrar (myregistrar.domain) to distinguish which entity (office or home) is trying to invite someone, if the registrar receives an INVITE from the office SIP Phone or from the home softphone?" Thank you in advance! Giacomo ------=_NextPart_000_0028_01C55C5E.B9168830 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 All,
Take = this scenario:=20 I have a SIP Phone in my office, and I use my account: UserID: giacomo,=20 Password: ****, registering to "myregistrar.domain".
Now, = in order to use=20 the same service I want to use the same account at home. So I register=20 mysoftphone with same UserID, password and in the same registrar=20 "myregistrar.domain" from home.
 
Suppose that the=20 registrar allows this multiple registration for the same UserID, adding = the home=20 contact to the previous office contact.
 
The = question is: "Is=20 there a way for the Proxy/Registrar (myregistrar.domain) to distinguish = which=20 entity (office or home) is trying to invite someone, if the registrar = receives=20 an INVITE from the office SIP Phone or from the home=20 softphone?"
 
Thank = you in=20 advance!
Giacomo
 
 
------=_NextPart_000_0028_01C55C5E.B9168830-- --===============0878547058== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0878547058==-- From sip-bounces@ietf.org Thu May 19 05:39:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYhVW-0007ce-AO; Thu, 19 May 2005 05:39:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYhVU-0007cX-4O for sip@megatron.ietf.org; Thu, 19 May 2005 05:39:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10408 for ; Thu, 19 May 2005 05:39:53 -0400 (EDT) Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYhma-0003Ld-GD for sip@ietf.org; Thu, 19 May 2005 05:57:38 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id j4J9o3OT003487 for ; Thu, 19 May 2005 02:50:03 -0700 (MST) Received: from zin24exm01.ap.mot.com (zin24exm01.ap.mot.com [10.232.25.1]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id j4J9g2F8009060 for ; Thu, 19 May 2005 04:42:03 -0500 (CDT) Received: by zin24exm01.ap.mot.com with Internet Mail Service (5.5.2657.72) id ; Thu, 19 May 2005 15:09:42 +0530 Message-ID: <772BCEF88A1DD91191F80011856715F3022356FA@zin24exm01.ap.mot.com> From: Chauhan Bhavik-A20762 To: sip@ietf.org, sip-implementors@cs.columbia.edu Date: Thu, 19 May 2005 15:09:39 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 2.1 (++) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: Subject: [Sip] UPDATE with ANSWER? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1822059940==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org 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. --===============1822059940== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55C53.C32A6F4A" 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_01C55C53.C32A6F4A Content-Type: text/plain Hi all, I was exploring the possibility for the UPDATE to send the Answer, As I haven't found any explicit restriction in RFC 3311. I went through the older Thread http://lists.cs.columbia.edu/pipermail/sip-implementors/2004-January/006017. html and came across following Qs which I found not clarified though. 1. Can UPDATE be used to send an answer SDP ? Consider the following scenario: - INVITE was sent without SDP - 18x is received with Offer SDP - There is no PRACK exchange because 18x does not contain a Require:100rel header Now can UPDATE be used to send answer SDP?? 2. As per RFC 3311, UPDATE method should be used only if dialog is established. If INVITE/18x exchange happened without PRACK, can both ends treat this as early dialog and feel free to use UPDATE ? 3. Is 18x send/recv over TCP considered reliable ? In the following scenario: - INVITE with offer sdp sent - 18x over TCP with answer sdp recvd (No PRACK exchange happened) Now can the caller/calleee use UPDATE ? Can any body clarify the same? Thanks in advance, Bhavik Chauhan ------_=_NextPart_001_01C55C53.C32A6F4A Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KPFRJVExFPk1lc3NhZ2U8L1RJVExF Pg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yODAwLjE0OTEiIG5hbWU9R0VORVJBVE9S PjwvSEVBRD4NCjxCT0RZPg0KPERJVj48U1BBTiBjbGFzcz05OTIzODE4MDktMTkwNTIwMDU+PEZP TlQgZmFjZT1BcmlhbCBjb2xvcj0jMDA4MDgwIHNpemU9Mj5IaSANCmFsbCw8L0ZPTlQ+PC9TUEFO PjwvRElWPg0KPERJVj48U1BBTiBjbGFzcz05OTIzODE4MDktMTkwNTIwMDU+PEZPTlQgZmFjZT1B cmlhbCBjb2xvcj0jMDA4MDgwIA0Kc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8 RElWPjxTUEFOIGNsYXNzPTk5MjM4MTgwOS0xOTA1MjAwNT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9y PSMwMDgwODAgc2l6ZT0yPkkgDQp3YXMmbmJzcDtleHBsb3JpbmcgdGhlIHBvc3NpYmlsaXR5IGZv ciB0aGUgVVBEQVRFIHRvIHNlbmQgdGhlIA0KQW5zd2VyLDwvRk9OVD48L1NQQU4+PC9ESVY+DQo8 RElWPjxTUEFOIGNsYXNzPTk5MjM4MTgwOS0xOTA1MjAwNT4NCjxESVY+PFNQQU4gY2xhc3M9OTky MzgxODA5LTE5MDUyMDA1PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwODA4MCBzaXplPTI+QXMg DQpJJm5ic3A7aGF2ZW4ndCZuYnNwO2ZvdW5kIGFueSBleHBsaWNpdCByZXN0cmljdGlvbiBpbiBS RkMgDQozMzExLjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTk5MjM4MTgw OS0xOTA1MjAwNT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDgwODAgDQpzaXplPTI+PC9GT05U PjwvU1BBTj4mbmJzcDs8L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9OTkyMzgxODA5LTE5MDUyMDA1 PjxTUEFOIGNsYXNzPTk5MjM4MTgwOS0xOTA1MjAwNT48Rk9OVCANCmZhY2U9QXJpYWwgY29sb3I9 IzAwODA4MCBzaXplPTI+SSB3ZW50IHRocm91Z2ggdGhlIG9sZGVyIFRocmVhZCA8QSANCmhyZWY9 Imh0dHA6Ly9saXN0cy5jcy5jb2x1bWJpYS5lZHUvcGlwZXJtYWlsL3NpcC1pbXBsZW1lbnRvcnMv MjAwNC1KYW51YXJ5LzAwNjAxNy5odG1sIj5odHRwOi8vbGlzdHMuY3MuY29sdW1iaWEuZWR1L3Bp cGVybWFpbC9zaXAtaW1wbGVtZW50b3JzLzIwMDQtSmFudWFyeS8wMDYwMTcuaHRtbDwvQT48L0ZP TlQ+PC9TUEFOPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9OTkyMzgxODA5LTE5MDUy MDA1PjxTUEFOIGNsYXNzPTk5MjM4MTgwOS0xOTA1MjAwNT48Rk9OVCANCmZhY2U9QXJpYWwgY29s b3I9IzAwODA4MCBzaXplPTI+YW5kIGNhbWUgYWNyb3NzIGZvbGxvd2luZyBRcyZuYnNwO3doaWNo Jm5ic3A7SSANCmZvdW5kJm5ic3A7bm90IGNsYXJpZmllZCB0aG91Z2guPC9GT05UPjwvU1BBTj48 L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTk5MjM4MTgwOS0xOTA1MjAwNT48U1BBTiBj bGFzcz05OTIzODE4MDktMTkwNTIwMDU+PEZPTlQgDQpmYWNlPUFyaWFsIGNvbG9yPSMwMDgwODAg c2l6ZT0yPjwvRk9OVD48L1NQQU4+PC9TUEFOPjwvU1BBTj4mbmJzcDs8L0RJVj48L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDA4MDgwIHNpemU9Mj4xLiBDYW4gVVBEQVRFIGJl IHVzZWQgdG8gc2VuZCBhbiANCmFuc3dlciBTRFAgPzxCUj4mbmJzcDsmbmJzcDsmbmJzcDsgQ29u c2lkZXIgdGhlIGZvbGxvd2luZyANCnNjZW5hcmlvOjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsgLSZu YnNwOyBJTlZJVEUgd2FzIHNlbnQgd2l0aG91dCANClNEUDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsg LSAxOHggaXMgcmVjZWl2ZWQgd2l0aCBPZmZlciBTRFA8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0K LSBUaGVyZSBpcyBubyBQUkFDSyBleGNoYW5nZSBiZWNhdXNlIDE4eCBkb2VzIG5vdCBjb250YWlu IGE8QlI+UmVxdWlyZToxMDByZWwgDQpoZWFkZXI8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5vdyBj YW4gVVBEQVRFIGJlIHVzZWQgdG8gc2VuZCBhbnN3ZXIgDQpTRFA/PzwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDA4MDgwIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwODA4MCBzaXplPTI+Mi4gQXMgcGVy IFJGQyAzMzExLCBVUERBVEUgbWV0aG9kIA0Kc2hvdWxkIGJlIHVzZWQgb25seSBpZiBkaWFsb2cg aXM8QlI+ZXN0YWJsaXNoZWQuPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyBJZiANCklOVklURS8xOHgg ZXhjaGFuZ2UgaGFwcGVuZWQgd2l0aG91dCBQUkFDSywgY2FuIGJvdGggZW5kcyB0cmVhdDxCUj50 aGlzIGFzIGVhcmx5IA0KZGlhbG9nIGFuZCBmZWVsIGZyZWUgdG8gdXNlIFVQREFURSA/PC9GT05U PjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDgwODAgc2l6ZT0yPjwvRk9O VD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDA4MDgwIHNpemU9 Mj4zLiBJcyAxOHggc2VuZC9yZWN2IG92ZXIgVENQIA0KY29uc2lkZXJlZCByZWxpYWJsZSA/PEJS PiZuYnNwOyZuYnNwOyZuYnNwOyBJbiB0aGUgZm9sbG93aW5nIA0Kc2NlbmFyaW86PEJSPiZuYnNw OyZuYnNwOyZuYnNwOyAtIElOVklURSB3aXRoIG9mZmVyIHNkcCANCnNlbnQ8QlI+Jm5ic3A7Jm5i c3A7Jm5ic3A7IC0gMTh4IG92ZXIgVENQIHdpdGggYW5zd2VyIHNkcCByZWN2ZCAoTm8gUFJBQ0sg DQpleGNoYW5nZSBoYXBwZW5lZCk8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5vdyBjYW4gdGhlIGNh bGxlci9jYWxsZWVlIHVzZSBVUERBVEUgDQo/PEJSPjwvRk9OVD48L0RJVj4NCjxESVY+PFNQQU4g Y2xhc3M9OTkyMzgxODA5LTE5MDUyMDA1PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwODA4MCBz aXplPTI+Q2FuIA0KYW55IGJvZHkgY2xhcmlmeSB0aGUgc2FtZT88L0ZPTlQ+PC9TUEFOPjwvRElW Pg0KPERJVj48U1BBTiBjbGFzcz05OTIzODE4MDktMTkwNTIwMDU+PEZPTlQgZmFjZT1BcmlhbCBj b2xvcj0jMDA4MDgwIA0Kc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWPg0K PERJViBhbGlnbj1sZWZ0Pg0KPERJViBhbGlnbj1sZWZ0PjxTVFJPTkc+PEZPTlQgZmFjZT1Bcmlh bD48Rk9OVCBjb2xvcj0jMzg3MjcyPjxGT05UIHNpemU9Mj48U1BBTiANCmNsYXNzPTk5MjM4MTgw OS0xOTA1MjAwNT5UaGFua3MgaW4gDQphZHZhbmNlPC9TUEFOPiw8L0ZPTlQ+PC9GT05UPjwvRk9O VD48L1NUUk9ORz48L0RJVj4NCjxESVYgYWxpZ249bGVmdD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9y PSMzODcyNzIgc2l6ZT0yPjxTVFJPTkc+QmhhdmlrIA0KQ2hhdWhhbjwvU1RST05HPjwvRk9OVD48 L0RJVj4NCjxESVYgYWxpZ249bGVmdD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMzODcyNzIgDQpz aXplPTI+PFNUUk9ORz48L1NUUk9ORz48L0ZPTlQ+Jm5ic3A7PC9ESVY+PC9ESVY+PC9ESVY+PC9C T0RZPjwvSFRNTD4NCg== ------_=_NextPart_001_01C55C53.C32A6F4A-- --===============1822059940== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1822059940==-- From sip-bounces@ietf.org Thu May 19 05:51:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYhge-0002fU-KA; Thu, 19 May 2005 05:51:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYhgc-0002fF-12 for sip@megatron.ietf.org; Thu, 19 May 2005 05:51:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11494 for ; Thu, 19 May 2005 05:51:21 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYhxi-0003e6-2t for sip@ietf.org; Thu, 19 May 2005 06:09:06 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate7) with ESMTP id j4J9x6GT000697 for ; Thu, 19 May 2005 02:59:06 -0700 (MST) Received: from zin24exm02.corp.mot.com (zin24exm02.ap.mot.com [10.232.26.1]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id j4J9sw2W017527 for ; Thu, 19 May 2005 04:54:59 -0500 (CDT) Received: by zin24exm02.ap.mot.com with Internet Mail Service (5.5.2657.72) id ; Thu, 19 May 2005 15:21:17 +0530 Message-ID: <19B94C8C331A7546A88C88502083353BB2284E@zin24exm02.ap.mot.com> From: Avasarala Ranjit-A20990 To: Chauhan Bhavik-A20762 , sip@ietf.org, sip-implementors@cs.columbia.edu Subject: RE: [Sip] UPDATE with ANSWER? Date: Thu, 19 May 2005 15:21:08 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 2.2 (++) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1738370537==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org 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. --===============1738370537== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55C58.47F34F54" 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_01C55C58.47F34F54 Content-Type: text/plain Hi No UPDATE cannot be used to send answer, since UPDATE can be used only after a dialog is established. Regards Ranjit -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Chauhan Bhavik-A20762 Sent: Thursday, May 19, 2005 3:10 PM To: sip@ietf.org; sip-implementors@cs.columbia.edu Subject: [Sip] UPDATE with ANSWER? Hi all, I was exploring the possibility for the UPDATE to send the Answer, As I haven't found any explicit restriction in RFC 3311. I went through the older Thread http://lists.cs.columbia.edu/pipermail/sip-implementors/2004-January/006017. html and came across following Qs which I found not clarified though. 1. Can UPDATE be used to send an answer SDP ? Consider the following scenario: - INVITE was sent without SDP - 18x is received with Offer SDP - There is no PRACK exchange because 18x does not contain a Require:100rel header Now can UPDATE be used to send answer SDP?? 2. As per RFC 3311, UPDATE method should be used only if dialog is established. If INVITE/18x exchange happened without PRACK, can both ends treat this as early dialog and feel free to use UPDATE ? 3. Is 18x send/recv over TCP considered reliable ? In the following scenario: - INVITE with offer sdp sent - 18x over TCP with answer sdp recvd (No PRACK exchange happened) Now can the caller/calleee use UPDATE ? Can any body clarify the same? Thanks in advance, Bhavik Chauhan ------_=_NextPart_001_01C55C58.47F34F54 Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KPFRJVExFPk1lc3NhZ2U8L1RJVExF Pg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yODAwLjE0NzkiIG5hbWU9R0VORVJBVE9S PjwvSEVBRD4NCjxCT0RZPg0KPERJVj48U1BBTiBjbGFzcz01NTgzNDUwMDktMTkwNTIwMDU+PEZP TlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0Kc2l6ZT0yPkhpPC9GT05UPjwvU1BBTj48L0RJ Vj4NCjxESVY+PFNQQU4gY2xhc3M9NTU4MzQ1MDA5LTE5MDUyMDA1PjxGT05UIGZhY2U9QXJpYWwg Y29sb3I9IzAwMDBmZiANCnNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsgTm8gVVBEQVRFIGNhbm5v dCBiZSB1c2VkIHRvIHNlbmQgYW5zd2VyLCBzaW5jZSBVUERBVEUgDQpjYW4gYmUgdXNlZCBvbmx5 IGFmdGVyIGEgZGlhbG9nIGlzIGVzdGFibGlzaGVkLiA8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJ Vj48U1BBTiBjbGFzcz01NTgzNDUwMDktMTkwNTIwMDU+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJ Vj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+PCEtLSBDb252ZXJ0ZWQgZnJvbSB0ZXh0 L3J0ZiBmb3JtYXQgLS0+DQo8UD48U1BBTiBsYW5nPWVuLXVzPjxCPjxJPjxGT05UIGZhY2U9QXJp YWwgY29sb3I9IzAwODA4MCANCnNpemU9Mj5SZWdhcmRzPC9GT05UPjwvST48L0I+PC9TUEFOPiA8 QlI+PFNQQU4gbGFuZz1lbi11cz48Qj48ST48Rk9OVCBmYWNlPUFyaWFsIA0KY29sb3I9IzAwODA4 MCBzaXplPTI+UmFuaml0PC9GT05UPjwvST48L0I+PC9TUEFOPiA8L1A+PEJSPjxCUj4NCjxESVY+ PC9ESVY+DQo8RElWIGNsYXNzPU91dGxvb2tNZXNzYWdlSGVhZGVyIGxhbmc9ZW4tdXMgZGlyPWx0 ciBhbGlnbj1sZWZ0PjxGT05UIGZhY2U9VGFob21hIA0Kc2l6ZT0yPi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tPEJSPjxCPkZyb206PC9CPiBzaXAtYm91bmNlc0BpZXRmLm9yZyANClttYWlsdG86 c2lwLWJvdW5jZXNAaWV0Zi5vcmddIDxCPk9uIEJlaGFsZiBPZiA8L0I+Q2hhdWhhbiANCkJoYXZp ay1BMjA3NjI8QlI+PEI+U2VudDo8L0I+IFRodXJzZGF5LCBNYXkgMTksIDIwMDUgMzoxMCBQTTxC Uj48Qj5Ubzo8L0I+IA0Kc2lwQGlldGYub3JnOyBzaXAtaW1wbGVtZW50b3JzQGNzLmNvbHVtYmlh LmVkdTxCUj48Qj5TdWJqZWN0OjwvQj4gW1NpcF0gVVBEQVRFIA0Kd2l0aCBBTlNXRVI/PEJSPjxC Uj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTk5MjM4MTgwOS0xOTA1MjAwNT48Rk9O VCBmYWNlPUFyaWFsIGNvbG9yPSMwMDgwODAgc2l6ZT0yPkhpIA0KYWxsLDwvRk9OVD48L1NQQU4+ PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTk5MjM4MTgwOS0xOTA1MjAwNT48Rk9OVCBmYWNlPUFy aWFsIGNvbG9yPSMwMDgwODAgDQpzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCjxE SVY+PFNQQU4gY2xhc3M9OTkyMzgxODA5LTE5MDUyMDA1PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9 IzAwODA4MCBzaXplPTI+SSANCndhcyZuYnNwO2V4cGxvcmluZyB0aGUgcG9zc2liaWxpdHkgZm9y IHRoZSBVUERBVEUgdG8gc2VuZCB0aGUgDQpBbnN3ZXIsPC9GT05UPjwvU1BBTj48L0RJVj4NCjxE SVY+PFNQQU4gY2xhc3M9OTkyMzgxODA5LTE5MDUyMDA1Pg0KPERJVj48U1BBTiBjbGFzcz05OTIz ODE4MDktMTkwNTIwMDU+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDA4MDgwIHNpemU9Mj5BcyAN CkkmbmJzcDtoYXZlbid0Jm5ic3A7Zm91bmQgYW55IGV4cGxpY2l0IHJlc3RyaWN0aW9uIGluIFJG QyANCjMzMTEuPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9OTkyMzgxODA5 LTE5MDUyMDA1PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwODA4MCANCnNpemU9Mj48L0ZPTlQ+ PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJVj48U1BBTiBjbGFzcz05OTIzODE4MDktMTkwNTIwMDU+ PFNQQU4gY2xhc3M9OTkyMzgxODA5LTE5MDUyMDA1PjxGT05UIA0KZmFjZT1BcmlhbCBjb2xvcj0j MDA4MDgwIHNpemU9Mj5JIHdlbnQgdGhyb3VnaCB0aGUgb2xkZXIgVGhyZWFkIDxBIA0KaHJlZj0i aHR0cDovL2xpc3RzLmNzLmNvbHVtYmlhLmVkdS9waXBlcm1haWwvc2lwLWltcGxlbWVudG9ycy8y MDA0LUphbnVhcnkvMDA2MDE3Lmh0bWwiPmh0dHA6Ly9saXN0cy5jcy5jb2x1bWJpYS5lZHUvcGlw ZXJtYWlsL3NpcC1pbXBsZW1lbnRvcnMvMjAwNC1KYW51YXJ5LzAwNjAxNy5odG1sPC9BPjwvRk9O VD48L1NQQU4+PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBjbGFzcz05OTIzODE4MDktMTkwNTIw MDU+PFNQQU4gY2xhc3M9OTkyMzgxODA5LTE5MDUyMDA1PjxGT05UIA0KZmFjZT1BcmlhbCBjb2xv cj0jMDA4MDgwIHNpemU9Mj5hbmQgY2FtZSBhY3Jvc3MgZm9sbG93aW5nIFFzJm5ic3A7d2hpY2gm bmJzcDtJIA0KZm91bmQmbmJzcDtub3QgY2xhcmlmaWVkIHRob3VnaC48L0ZPTlQ+PC9TUEFOPjwv U1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9OTkyMzgxODA5LTE5MDUyMDA1PjxTUEFOIGNs YXNzPTk5MjM4MTgwOS0xOTA1MjAwNT48Rk9OVCANCmZhY2U9QXJpYWwgY29sb3I9IzAwODA4MCBz aXplPTI+PC9GT05UPjwvU1BBTj48L1NQQU4+PC9TUEFOPiZuYnNwOzwvRElWPjwvRElWPg0KPERJ Vj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDgwODAgc2l6ZT0yPjEuIENhbiBVUERBVEUgYmUg dXNlZCB0byBzZW5kIGFuIA0KYW5zd2VyIFNEUCA/PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyBDb25z aWRlciB0aGUgZm9sbG93aW5nIA0Kc2NlbmFyaW86PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyAtJm5i c3A7IElOVklURSB3YXMgc2VudCB3aXRob3V0IA0KU0RQPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyAt IDE4eCBpcyByZWNlaXZlZCB3aXRoIE9mZmVyIFNEUDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsgDQot IFRoZXJlIGlzIG5vIFBSQUNLIGV4Y2hhbmdlIGJlY2F1c2UgMTh4IGRvZXMgbm90IGNvbnRhaW4g YTxCUj5SZXF1aXJlOjEwMHJlbCANCmhlYWRlcjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsgTm93IGNh biBVUERBVEUgYmUgdXNlZCB0byBzZW5kIGFuc3dlciANClNEUD8/PC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDgwODAgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDA4MDgwIHNpemU9Mj4yLiBBcyBwZXIg UkZDIDMzMTEsIFVQREFURSBtZXRob2QgDQpzaG91bGQgYmUgdXNlZCBvbmx5IGlmIGRpYWxvZyBp czxCUj5lc3RhYmxpc2hlZC48QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IElmIA0KSU5WSVRFLzE4eCBl eGNoYW5nZSBoYXBwZW5lZCB3aXRob3V0IFBSQUNLLCBjYW4gYm90aCBlbmRzIHRyZWF0PEJSPnRo aXMgYXMgZWFybHkgDQpkaWFsb2cgYW5kIGZlZWwgZnJlZSB0byB1c2UgVVBEQVRFID88L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwODA4MCBzaXplPTI+PC9GT05U PiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDgwODAgc2l6ZT0y PjMuIElzIDE4eCBzZW5kL3JlY3Ygb3ZlciBUQ1AgDQpjb25zaWRlcmVkIHJlbGlhYmxlID88QlI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7IEluIHRoZSBmb2xsb3dpbmcgDQpzY2VuYXJpbzo8QlI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7IC0gSU5WSVRFIHdpdGggb2ZmZXIgc2RwIA0Kc2VudDxCUj4mbmJzcDsmbmJz cDsmbmJzcDsgLSAxOHggb3ZlciBUQ1Agd2l0aCBhbnN3ZXIgc2RwIHJlY3ZkIChObyBQUkFDSyAN CmV4Y2hhbmdlIGhhcHBlbmVkKTxCUj4mbmJzcDsmbmJzcDsmbmJzcDsgTm93IGNhbiB0aGUgY2Fs bGVyL2NhbGxlZWUgdXNlIFVQREFURSANCj88QlI+PC9GT05UPjwvRElWPg0KPERJVj48U1BBTiBj bGFzcz05OTIzODE4MDktMTkwNTIwMDU+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDA4MDgwIHNp emU9Mj5DYW4gDQphbnkgYm9keSBjbGFyaWZ5IHRoZSBzYW1lPzwvRk9OVD48L1NQQU4+PC9ESVY+ DQo8RElWPjxTUEFOIGNsYXNzPTk5MjM4MTgwOS0xOTA1MjAwNT48Rk9OVCBmYWNlPUFyaWFsIGNv bG9yPSMwMDgwODAgDQpzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCjxESVY+DQo8 RElWIGFsaWduPWxlZnQ+DQo8RElWIGFsaWduPWxlZnQ+PFNUUk9ORz48Rk9OVCBmYWNlPUFyaWFs PjxGT05UIGNvbG9yPSMzODcyNzI+PEZPTlQgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9OTkyMzgxODA5 LTE5MDUyMDA1PlRoYW5rcyBpbiANCmFkdmFuY2U8L1NQQU4+LDwvRk9OVD48L0ZPTlQ+PC9GT05U PjwvU1RST05HPjwvRElWPg0KPERJViBhbGlnbj1sZWZ0PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9 IzM4NzI3MiBzaXplPTI+PFNUUk9ORz5CaGF2aWsgDQpDaGF1aGFuPC9TVFJPTkc+PC9GT05UPjwv RElWPg0KPERJViBhbGlnbj1sZWZ0PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzM4NzI3MiANCnNp emU9Mj48U1RST05HPjwvU1RST05HPjwvRk9OVD4mbmJzcDs8L0RJVj48L0RJVj48L0RJVj48L0JP RFk+PC9IVE1MPg0K ------_=_NextPart_001_01C55C58.47F34F54-- --===============1738370537== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1738370537==-- From sip-bounces@ietf.org Thu May 19 07:26:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYjAO-0002n7-RH; Thu, 19 May 2005 07:26:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYjAM-0002kv-9x for sip@megatron.ietf.org; Thu, 19 May 2005 07:26:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23475 for ; Thu, 19 May 2005 07:26:13 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYjRU-0006OJ-1o for sip@ietf.org; Thu, 19 May 2005 07:43:57 -0400 Received: from esealmw129.eemea.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j4JBPUOi004510; Thu, 19 May 2005 13:25:48 +0200 Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 May 2005 13:25:35 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 May 2005 13:25:35 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Sip] UPDATE with ANSWER? Date: Thu, 19 May 2005 13:25:35 +0200 Message-ID: Thread-Topic: [Sip] UPDATE with ANSWER? Thread-Index: AcVcV2YJ8ttTdXg4RtmgpaNGc5/MQAADfPKg From: "Christer Holmberg \(JO/LMF\)" To: "Chauhan Bhavik-A20762" , , X-OriginalArrivalTime: 19 May 2005 11:25:35.0424 (UTC) FILETIME=[79C39400:01C55C65] X-Spam-Score: 0.4 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1754854586==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1754854586== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55C65.798A186F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C55C65.798A186F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 If you don't use PRACK you can't send a valid offer in a 18x. An offer = (and an answer) has to be sent reliably. =20 Regards, =20 Christer Holmberg LM Ericsson =20 =20 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of = Chauhan Bhavik-A20762 Sent: 19. toukokuuta 2005 12:40 To: sip@ietf.org; sip-implementors@cs.columbia.edu Subject: [Sip] UPDATE with ANSWER? Hi all, =20 I was exploring the possibility for the UPDATE to send the Answer, As I haven't found any explicit restriction in RFC 3311. =20 I went through the older Thread = http://lists.cs.columbia.edu/pipermail/sip-implementors/2004-January/0060= 17.html and came across following Qs which I found not clarified though. =20 1. Can UPDATE be used to send an answer SDP ? Consider the following scenario: - INVITE was sent without SDP - 18x is received with Offer SDP - There is no PRACK exchange because 18x does not contain a Require:100rel header Now can UPDATE be used to send answer SDP?? =20 2. As per RFC 3311, UPDATE method should be used only if dialog is established. If INVITE/18x exchange happened without PRACK, can both ends treat this as early dialog and feel free to use UPDATE ? =20 3. Is 18x send/recv over TCP considered reliable ? In the following scenario: - INVITE with offer sdp sent - 18x over TCP with answer sdp recvd (No PRACK exchange happened) Now can the caller/calleee use UPDATE ? Can any body clarify the same? =20 Thanks in advance, Bhavik Chauhan =20 ------_=_NextPart_001_01C55C65.798A186F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Hi,
 
If you=20 don't use PRACK you can't send a valid offer in a 18x. An offer (and an = answer)=20 has to be sent reliably.
 
Regards,
 
Christer Holmberg
LM=20 Ericsson
 
 
-----Original Message-----
From: = sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org]On Behalf Of Chauhan=20 Bhavik-A20762
Sent: 19. toukokuuta 2005 12:40
To:=20 sip@ietf.org; sip-implementors@cs.columbia.edu
Subject: = [Sip] UPDATE=20 with ANSWER?

Hi=20 all,
 
I=20 was exploring the possibility for the UPDATE to send the=20 Answer,
As=20 I haven't found any explicit restriction in RFC=20 3311.
 
I went through the older Thread = http://lists.cs.columbia.edu/pipermail/sip-implementors/= 2004-January/006017.html
and came across following = Qs which I=20 found not clarified though.
 
1. Can UPDATE be used = to send an=20 answer SDP ?
    Consider the following=20 scenario:
    -  INVITE was sent without=20 SDP
    - 18x is received with Offer=20 SDP
    - There is no PRACK exchange because 18x = does not=20 contain a
Require:100rel header
    Now can = UPDATE be=20 used to send answer SDP??
 
2. As per RFC 3311, = UPDATE method=20 should be used only if dialog is
established.
    = If=20 INVITE/18x exchange happened without PRACK, can both ends = treat
this as=20 early dialog and feel free to use UPDATE ?
 
3. Is 18x send/recv = over TCP=20 considered reliable ?
    In the following=20 scenario:
    - INVITE with offer sdp=20 sent
    - 18x over TCP with answer sdp recvd (No = PRACK=20 exchange happened)
    Now can the caller/calleee = use UPDATE=20 ?
Can=20 any body clarify the same?
 
Thanks in=20 advance,
Bhavik=20 Chauhan
 
------_=_NextPart_001_01C55C65.798A186F-- --===============1754854586== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1754854586==-- From sip-bounces@ietf.org Thu May 19 08:44:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYkO3-0000sF-5P; Thu, 19 May 2005 08:44:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYkNz-0000s2-69 for sip@megatron.ietf.org; Thu, 19 May 2005 08:44:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00129 for ; Thu, 19 May 2005 08:44:21 -0400 (EDT) Received: from [151.39.82.129] (helo=mail.abbeynet.it) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYkf6-0000Na-7w for sip@ietf.org; Thu, 19 May 2005 09:02:07 -0400 Received: from admin.abbeynet.it (localhost.localdomain [127.0.0.1]) by mail.abbeynet.it (Postfix) with SMTP id 8CE8C332767 for ; Thu, 19 May 2005 14:44:09 +0200 (CEST) Received: from mail.abbeynet.it ([127.0.0.1]) by admin.abbeynet.it ([151.39.82.129]) with SMTP (gateway) id A06B972FA05; Thu, 19 May 2005 14:44:09 +0200 Received: from gia (giacomo.localnet [192.168.0.158]) by mail.abbeynet.it (Postfix) with ESMTP id 01006332767 for ; Thu, 19 May 2005 14:44:09 +0200 (CEST) From: "Giacomo Vacca" To: Subject: R: [SIP] Multiple instances of same UA: How to distinguish them? Date: Thu, 19 May 2005 14:44:08 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <0966EC230D8BDA4EB06F57075C4DBF8FFDEFDD@blr-k1-msg.wipro.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVcTfVIOUW5+zQIQHOFf6pQOQTv+gAGEnAQAAJO09A= Message-Id: <20050519124409.01006332767@mail.abbeynet.it> X-Spam-Score: 1.0 (+) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2034890128==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============2034890128== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0068_01C55C81.36AB26D0" This is a multi-part message in MIME format. ------=_NextPart_000_0068_01C55C81.36AB26D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you for your reply: I agree with you. But let's consider a case where the Contact stored after the = registration differs from that carried by the INVITE. Perhaps this is not a "ideal" = case, but I'm confident it can happen. I think that the only way to distinguish them is to store IP address and port from which the requests arrived. What do you think about? =20 Thanks Giacomo _____ =20 Da: innovation.interops@wipro.com [mailto:innovation.interops@wipro.com] = Inviato: gioved=EC 19 maggio 2005 13.31 A: giacomo.vacca@abbeynet.it Oggetto: RE: [SIP] Multiple instances of same UA: How to distinguish = them? Normally proxy would not require to know who is calling except for authentication purpose.All it does is to check if it can locate the = person mentioned in the Request URI in the Location Information. =20 But if u need a way to really distinguish at proxy which instance is = sending the INVITE.Contact header In INVITE can be compared with the contact = header value already existing in the Location Information. =20 _____ =20 From: sip-bounces@ietf.org on behalf of Giacomo Vacca Sent: Thu 5/19/2005 2:07 PM To: sip@ietf.org Subject: [SIP] Multiple instances of same UA: How to distinguish them? Hi All, Take this scenario: I have a SIP Phone in my office, and I use my = account: UserID: giacomo, Password: ****, registering to "myregistrar.domain". Now, in order to use the same service I want to use the same account at home. So I register mysoftphone with same UserID, password and in the = same registrar "myregistrar.domain" from home. =20 Suppose that the registrar allows this multiple registration for the = same UserID, adding the home contact to the previous office contact. =20 The question is: "Is there a way for the Proxy/Registrar (myregistrar.domain) to distinguish which entity (office or home) is = trying to invite someone, if the registrar receives an INVITE from the office = SIP Phone or from the home softphone?" =20 Thank you in advance! Giacomo =20 =20 Confidentiality Notice=20 The information contained in this electronic message and any attachments = to this message are intended for the exclusive use of the addressee(s) and may contain confidential = or privileged information. If you are not the intended recipient, please notify the sender at Wipro or Mailadmin@wipro.com immediately and destroy all copies of this message and any attachments. =09 ------=_NextPart_000_0068_01C55C81.36AB26D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thank you for your reply: I agree with=20 you.
But let's consider a case where the Contact = stored after=20 the registration differs from that carried by the INVITE. Perhaps this = is not a=20 "ideal" case, but I'm confident it can happen.
I=20 think that the only way to distinguish them is to store IP address and = port from=20 which the requests arrived. What do you think=20 about?
 
Thanks
Giacomo

Da: innovation.interops@wipro.com=20 [mailto:innovation.interops@wipro.com]
Inviato: gioved=EC = 19 maggio=20 2005 13.31
A: giacomo.vacca@abbeynet.it
Oggetto: = RE: [SIP]=20 Multiple instances of same UA: How to distinguish = them?

Normally = proxy would not=20 require to know who is calling except for authentication purpose.All = it does=20 is to check if it can locate the person mentioned in the Request URI = in the=20 Location Information.
 
But if u need a way to = really distinguish=20 at proxy which instance is sending the INVITE.Contact header In INVITE = can=20 be compared with the contact header value already existing in the = Location Information.
 

From: sip-bounces@ietf.org on = behalf of=20 Giacomo Vacca
Sent: Thu 5/19/2005 2:07 PM
To:=20 sip@ietf.org
Subject: [SIP] Multiple instances of same UA: = How to=20 distinguish them?

Hi=20 All,
Take = this=20 scenario: I have a SIP Phone in my office, and I use my account: = UserID:=20 giacomo, Password: ****, registering to=20 "myregistrar.domain".
Now, = in order to=20 use the same service I want to use the same account at home. So I = register=20 mysoftphone with same UserID, password and in the same registrar=20 "myregistrar.domain" from home.
 
Suppose that the=20 registrar allows this multiple registration for the same UserID, = adding the=20 home contact to the previous office contact.
 
The = question is:=20 "Is there a way for the Proxy/Registrar (myregistrar.domain) to = distinguish=20 which entity (office or home) is trying to invite someone, if the = registrar=20 receives an INVITE from the office SIP Phone or from the home=20 softphone?"
 
Thank you in=20 advance!
Giacomo
 
 


Confidentiality Notice=20

The information contained in this electronic message and = any=20 attachments to this message are intended
for the exclusive = use of the=20 addressee(s) and may contain confidential or privileged = information.=20 If
you are not the intended recipient, please notify the = sender at=20 Wipro or Mailadmin@wipro.com immediately
and destroy all = copies of=20 this message and any=20 attachments.
------=_NextPart_000_0068_01C55C81.36AB26D0-- --===============2034890128== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2034890128==-- From sip-bounces@ietf.org Thu May 19 09:40:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYlFx-0001Ju-Ur; Thu, 19 May 2005 09:40:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYlFv-0001IU-Qv for sip@megatron.ietf.org; Thu, 19 May 2005 09:40:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05205 for ; Thu, 19 May 2005 09:40:06 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYlX5-0001zm-8I for sip@ietf.org; Thu, 19 May 2005 09:57:52 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 19 May 2005 09:39:58 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4JDdsnI005326; Thu, 19 May 2005 09:39:55 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 May 2005 09:39:51 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 May 2005 09:39:50 -0400 Message-ID: <428C9725.6080907@cisco.com> Date: Thu, 19 May 2005 09:39:49 -0400 From: Paul Kyzivat 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: Chauhan Bhavik-A20762 References: <772BCEF88A1DD91191F80011856715F3022356FA@zin24exm01.ap.mot.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 May 2005 13:39:50.0874 (UTC) FILETIME=[3B2FB3A0:01C55C78] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, sip-implementors@cs.columbia.edu Subject: [Sip] Re: [Sip-implementors] UPDATE with ANSWER? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org We really need to create an FAQ about this. A long time ago, probably in the thread you cite, we debated this extensively. It is true that the RFCs are not entirely clear on this, and reasonable people can differ in interpretation of them. But we finally came to some agreement on it. I am quite sure we agreed that UPDATE could *not* be used to send an answer. We ended up with a quite restrictive list of cases for how INVITE, UPDATE, PRACK, and their responses and ACK can be used to convey offer/answer. I was one who originally argued for fewer restrictions. But there were issues with that, and the restrictive approach won out. In practice I don't think the restrictions impose any great burden. Paul Chauhan Bhavik-A20762 wrote: > Hi all, > > I was exploring the possibility for the UPDATE to send the Answer, > As I haven't found any explicit restriction in RFC 3311. > > I went through the older Thread > http://lists.cs.columbia.edu/pipermail/sip-implementors/2004-January/006017. > html > .html> > and came across following Qs which I found not clarified though. > > 1. Can UPDATE be used to send an answer SDP ? > Consider the following scenario: > - INVITE was sent without SDP > - 18x is received with Offer SDP > - There is no PRACK exchange because 18x does not contain a > Require:100rel header > Now can UPDATE be used to send answer SDP?? > > 2. As per RFC 3311, UPDATE method should be used only if dialog is > established. > If INVITE/18x exchange happened without PRACK, can both ends treat > this as early dialog and feel free to use UPDATE ? > > 3. Is 18x send/recv over TCP considered reliable ? > In the following scenario: > - INVITE with offer sdp sent > - 18x over TCP with answer sdp recvd (No PRACK exchange happened) > Now can the caller/calleee use UPDATE ? > > Can any body clarify the same? > > Thanks in advance, > Bhavik Chauhan > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 19 09:46:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYlMU-0002iR-Nu; Thu, 19 May 2005 09:46:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYlMS-0002iM-BA for sip@megatron.ietf.org; Thu, 19 May 2005 09:46:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05943 for ; Thu, 19 May 2005 09:46:50 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYldY-0002Dt-91 for sip@ietf.org; Thu, 19 May 2005 10:04:37 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 19 May 2005 09:57:15 -0400 X-IronPort-AV: i="3.93,121,1115006400"; d="scan'208"; a="50141353:sNHT29402880" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4JDkQe6019387; Thu, 19 May 2005 09:46:35 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 May 2005 09:46:25 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 May 2005 09:46:25 -0400 Message-ID: <428C98AF.9060308@cisco.com> Date: Thu, 19 May 2005 09:46:23 -0400 From: Paul Kyzivat 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: Giacomo Vacca Subject: Re: R: [SIP] Multiple instances of same UA: How to distinguish them? References: <20050519124409.01006332767@mail.abbeynet.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 19 May 2005 13:46:25.0217 (UTC) FILETIME=[263BAB10:01C55C79] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA05943 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org The significant point here is that sip does not require a sender to=20 first register. A sender is a sender and should be judged by any server=20 along the path by what information is contained in the request. If the sender and the proxy want to make a side agreement that the proxy=20 will correlate an outgoing message with a registration, and provide some=20 services based on that correlation, then they can do so. But sip isn't=20 going to tell them how to do it. Paul Giacomo Vacca wrote: > Thank you for your reply: I agree with you. > But let's consider a case where the Contact stored after the=20 > registration differs from that carried by the INVITE. Perhaps this is=20 > not a "ideal" case, but I'm confident it can happen. > I think that the only way to distinguish them is to store IP address an= d=20 > port from which the requests arrived. What do you think about? > =20 > Thanks > Giacomo >=20 > -------------------------------------------------------------------= ----- > *Da:* innovation.interops@wipro.com > [mailto:innovation.interops@wipro.com] > *Inviato:* gioved=EC 19 maggio 2005 13.31 > *A:* giacomo.vacca@abbeynet.it > *Oggetto:* RE: [SIP] Multiple instances of same UA: How to > distinguish them? >=20 > Normally proxy would not require to know who is calling except for > authentication purpose.All it does is to check if it can locate the > person mentioned in the Request URI in the Location Information. > =20 > But if u need a way to really distinguish at proxy which instance i= s > sending the INVITE.Contact header In INVITE can be compared with th= e > contact header value already existing in the Location Information. > =20 >=20 > -------------------------------------------------------------------= ----- > *From:* sip-bounces@ietf.org on behalf of Giacomo Vacca > *Sent:* Thu 5/19/2005 2:07 PM > *To:* sip@ietf.org > *Subject:* [SIP] Multiple instances of same UA: How to distinguish = them? >=20 > Hi All, > Take this scenario: I have a SIP Phone in my office, and I use my > account: UserID: giacomo, Password: ****, registering to > "myregistrar.domain". > Now, in order to use the same service I want to use the same accoun= t > at home. So I register mysoftphone with same UserID, password and i= n > the same registrar "myregistrar.domain" from home. > =20 > Suppose that the registrar allows this multiple registration for th= e > same UserID, adding the home contact to the previous office contact. > =20 > The question is: "Is there a way for the Proxy/Registrar > (myregistrar.domain) to distinguish which entity (office or home) i= s > trying to invite someone, if the registrar receives an INVITE from > the office SIP Phone or from the home softphone?" > =20 > Thank you in advance! > Giacomo > =20 > =20 >=20 >=20 > Confidentiality Notice >=20 > The information contained in this electronic message and any > attachments to this message are intended > for the exclusive use of the addressee(s) and may contain > confidential or privileged information. If > you are not the intended recipient, please notify the sender at > Wipro or Mailadmin@wipro.com immediately > and destroy all copies of this message and any attachments. >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 19 10:51:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYmMp-00060c-D7; Thu, 19 May 2005 10:51:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYmMm-00060E-Rl; Thu, 19 May 2005 10:51:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12355; Thu, 19 May 2005 10:51:14 -0400 (EDT) From: Mpierce1@aol.com Received: from imo-d03.mx.aol.com ([205.188.157.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYmdv-000424-3n; Thu, 19 May 2005 11:09:01 -0400 Received: from Mpierce1@aol.com by imo-d03.mx.aol.com (mail_out_v38_r1.7.) id l.143.454b8510 (4214); Thu, 19 May 2005 10:50:54 -0400 (EDT) Message-ID: <143.454b8510.2fbe01cd@aol.com> Date: Thu, 19 May 2005 10:50:53 EDT To: iesg@ietf.org, sip@ietf.org, sipping@ieft.org MIME-Version: 1.0 X-Mailer: 7.0 for Windows sub 10689 X-Spam-Score: 0.7 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: Subject: [Sip] Comments on Last Call of "Extending Reason-header for Preemption Events" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1184434547==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1184434547== Content-Type: multipart/alternative; boundary="part1_143.454b8510.2fbe01cd_boundary" --part1_143.454b8510.2fbe01cd_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit The following comments are submitted on draft-ietf-sipping-reason-header-for-preemption-02. Section 5 The second reason listed should be for a general network preemption, no matter what technique is used to cause it. RSVP is only one possible way. The reason should not be named "RSVP". In fact, it appears that the important part of the defined protocol is the cause value (2" for this case) to mean "network preemption". The following "default" text is optional, only used for those cases in which a human user might read this for more information concerning the reasons for preemption. Since it is referred to as "default text", there should be no reason that it could not be anything else an implementation wanted to use. The formal definition of the syntax in RFC 3326 makes the text part optional. However, this draft appears to require that both the cause value and the text are always present and with the exact text string given (mistakenly described in the "IANA Considerations" section.) This needs to be corrected to be consistent with RFC 3326. Section 5.2 This needs to be reworded so it is not RSVP-specific. Any mention of RSVP should only be as an example of how network preemption might be controlled. Section 7 IANA Considerations As noted above, this section contains an erroneous statement about what "syntax shall be used". At the same time, it is unclear what the IANA registration requirements are. For example, this part implies that IANA needs to register the text strings, when there is clearly no need for that. Section 10 Normative References RFC 2205, RSVP, should not be listed as Normative. Mike Pierce Artel, Inc. --part1_143.454b8510.2fbe01cd_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable The fol= lowing comments are submitted on draft-ietf-sipping-reason-header-for-preemp= tion-02.

Section 5
The second reason listed should be for a general network preemption, no matt= er what technique is used to cause it. RSVP is only one possible way. The re= ason should not be named "RSVP".

In fact, it appears that the important part of the defined protocol is the c= ause value (2" for this case) to mean "network preemption". The following "d= efault" text is optional, only used for those cases in which a human user mi= ght read this for more information concerning the reasons for preemption. Si= nce it is referred to as "default text", there should be no reason that it c= ould not be anything else an implementation wanted to use. The formal defini= tion of the syntax in RFC 3326 makes the text part optional. However, this d= raft appears to require that both the cause value and the text are always pr= esent and with the exact text string given (mistakenly described in the "IAN= A Considerations" section.) This needs to be corrected to be consistent with= RFC 3326.

Section 5.2
This needs to be reworded so it is not RSVP-specific. Any mention of RSVP sh= ould only be as an example of how network preemption might be controlled.
Section 7 IANA Considerations
As noted above, this section contains an erroneous statement about what "syn= tax shall be used". At the same time, it is unclear what the IANA registrati= on requirements are. For example, this part implies that IANA needs to regis= ter the text strings, when there is clearly no need for that.

Section 10 Normative References
RFC 2205, RSVP, should not be listed as Normative.

Mike Pierce
Artel, Inc. --part1_143.454b8510.2fbe01cd_boundary-- --===============1184434547== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1184434547==-- From sip-bounces@ietf.org Thu May 19 11:45:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYnD9-0006QF-Gj; Thu, 19 May 2005 11:45:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYnD7-0006P3-2H for sip@megatron.ietf.org; Thu, 19 May 2005 11:45:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17656 for ; Thu, 19 May 2005 11:45:18 -0400 (EDT) Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYnUG-0005kX-Rj for sip@ietf.org; Thu, 19 May 2005 12:03:06 -0400 Received: from keywest (hide.pingtel.com [65.220.123.2]) by mail.pingtel.com (Postfix) with SMTP id 0E8726C02A; Thu, 19 May 2005 11:45:09 -0400 (EDT) From: "Dale Worley" To: , Subject: Re: [Sip] About Non-Invite Server Transaction Date: Thu, 19 May 2005 11:44:24 -0400 Message-ID: <00cc01c55c89$a2c14fe0$6a01010a@keywest> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > From: Anil Bollineni [ABollineni@juniper.net] > > Assume a gateway sends two INVITE=92s say to two different UAS=92s with= the same > Via branch parameter to two different users at the same time. It must not do that. See section 8.1.1.7 of RFC 3261: "The branch parameter value MUST be unique across space and time for all requests sen= t by the UA." > I understand for retransmitted non-INVITE requests it MUST result sendi= ng same > response by UAS > Assume 200 response to BYE sent by server transaction, and 200 response= is lost > before it reaches UAC. If it send BYE again, does UAS has to retransmit 200 > response? If the second BYE is a retransmission of the first BYE, as you have noted= , the UAS is required to send the same 200 response. > During transfer if a REFER is sent to UAS and say server transaction sa= y > transmit 503 (Declined), due to some temporary failures (e.g. user can=92= t accept > more calls), and assume this 503 is delayed. Aftr this failure cleared out, and > REFER is retransmitted, and in this case the server transaction sends s= ame error > message, even though the user is not busy. First of all, am I mentionin= g the > correct scenario.? If yes, what could be solution. If the second REFER is a retransmission of the first REFER, as you have noted, the UAS is required to send the same 503 response. If the second REFER is a *new* request (which can be determined by the increased CSeq number and the different Via branch parameter), the UAS may examine its situation and return a different response if it chooses. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 19 11:47:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYnFS-00073y-Qj; Thu, 19 May 2005 11:47:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYnFR-00073m-3f; Thu, 19 May 2005 11:47:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17861; Thu, 19 May 2005 11:47:42 -0400 (EDT) From: Mpierce1@aol.com Received: from imo-d20.mx.aol.com ([205.188.139.136]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYnWc-0005pa-74; Thu, 19 May 2005 12:05:30 -0400 Received: from Mpierce1@aol.com by imo-d20.mx.aol.com (mail_out_v38_r1.7.) id l.bb.57be0b98 (3850); Thu, 19 May 2005 11:47:30 -0400 (EDT) Message-ID: Date: Thu, 19 May 2005 11:47:30 EDT To: iesg@ietf.org, sip@ietf.org MIME-Version: 1.0 X-Mailer: 7.0 for Windows sub 10689 X-Spam-Score: 0.7 (/) X-Scan-Signature: 578c2c9d0cb01ffe6e1ca36540edd070 Cc: Subject: [Sip] Comments on Resource Priority -08 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0749265106==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============0749265106== Content-Type: multipart/alternative; boundary="part1_bb.57be0b98.2fbe0f12_boundary" --part1_bb.57be0b98.2fbe0f12_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit The following comments are submitted on draft-ietf-sip-resource-priority-08: 1 NITS Section 1, 7th paragraph (beginning "This document defines...") needs to be rewritten to refer to the two headers which this document defines. Section 4.6.5 wording of 2nd sentence is incomplete. I don't know what was intended, so I can not suggest new wording. Section 10.4 reference to "multi-layer priority preemption" needs to be changed to "Multi-Level Precedence and Preemption". 2 Major problems Section 4.2, rule 1 indicates that, if there is no resource shortage at the moment, the RP actor omits the following steps. However, the following steps are the authorization/authentication steps which must always be done first, since one of the results of requesting a priority level, even when there is no resource shortage at the moment, is to use the priority level during the remainder of the call and to provide it to the destination user. For example, the level requested may prevent a later preemption after a shortage of resources occurs. Rule 1 should simply be the final sentence in Rule 1. This rule was not in version -05 of this draft, and I am unaware of any e-mail or meeting discussion to add such a rule. Any attempt to explain or justify this rule as it is currently written will only add confusion. Section 4.7.1 2nd paragraph states that "Upon receiving a 417, the UAC MAY attempt a subsequent request with the same or different resource value." This is contrary to the policies for using priority values and should not be mentioned. The user (human) is supposed to select the correct value before requested a call setup. A UAC must never automatically attempt another request using a different resource value upon receipt of a 417. Of course, a human user may choose to do whatever they are authorized to do when trying a new call, but no device can be allowed to do this automatically, since it would be violating the policies for the use of priority levels. Section 10.2 states in the last sentence that the DSN (incorrectly written as "DRSN") uses preemption. This is misleading, since it may use other preferential treatment procedures as well. It is unnecessary for this document to state the algorithms/procedures used in each domain. Any mention of algorithms or procedures should only be as examples of what might occur in a domain. Sections 10.2 and 10.3 Security concerns make it appear that the variable length priority names will be a problem. When individual SIP packets are encrypted for confidentiality, the lengths of signaling messages will be a function of the priority level, thereby letting an attacker know when the volume of high priority calls increases. It appears now that it would be preferable to use same-length names for all priority levels. Section 12.1 2nd paragraph forbids adding a new priority value to a namespace (MUST NOT). Previous versions of this draft (-06 and before) allowed it, while advising against it (SHOULD NOT). For example, there is no reason why another value cannot be added to DSN later, if the operator of the DSN wishes to. If added, it is the responsibility of the operator of the DSN domain to figure out how to do it to avoid interoperability problems. For example, there is a possibility that the DSN will need to add a new level below Routine. The RFC can not forbid this. 3 Other problems Section 1, paragraph beginning "Since calls may traverse..." states that "it is important that all such domains and elements apply the same algorithms for the same namespace as otherwise the end-to-end experience of privileged users may be compromised." While this may be true for some combinations of preemption followed by queuing, it is not necessarily true for all combinations and for any algorithm that might be added later. Suggest that this sentence be reworded to say: "It is important that careful consideration be made before different algorithms are used at different places within a single call." Although section 7 only gives "examples", the use of "DSN" causes confusion since it shows an operation which would not be used in the DSN domain. Specifically, the inclusion of the R-P header in the 180 and 200 in 7.1 and the list of accepted values in the 417 in 7.2 would not be used in the DSN since this causes a security problem by telling the originator what precedence level call the called party is involved in. The example should use a domain that might use these techniques. Since there is none that is known to work this way, the examples should use "Foo" and "Bar" as in Section 8.2. Section 8.1 causes confusion since it implies the existence of a relative order between different namespaces. It should instead say that there is no defined relationship between the values of different namespaces and that RP actors may apply whatever algorithms or procedures they wish when dealing with multiple namespaces, as long as the relative levels within each namespace are maintained. Section 10.3 The final paragraph should be deleted, since it is not the responsibility of this document to describe the detailed operation within the DRSN, which could change at any time. Section 11.3 The association of the requirement for confidentiality and integrity of the user's data with the Resource-Priority header leads to confusion. They are unrelated requirements. Other policies and requirements dictate whether there is a need for confidentiality and integrity of the user's data independently from the need for precedence levels. The first paragraph should be deleted so that this section only addresses the security of the R-P header itself, since that is the subject of this document. Security of the user's data is not the subject of this document. Section 11.4 No system that allows the use of the R-P header should allow anonymity. In any case, the issue of anonymity is independent from the use of R-P header and should not be mentioned in this document. Section 12.1 The purpose of IANA registration is to prevent conflicts in assignment of names and numbers, such as the namespace, and to ensure compatibility for things like the priority values. There is no need to include the "operation" (preemption or preferential queuing) in the IANA registration. It is described sufficiently in this document. In fact, the DSN uses other techniques besides preemption, such as exemption from network management controls, as described in draft-pierce-tsvwg-pref-treat-example, so it is wrong to register it as just "preemption". Likewise, ETS may use other techniques besides "queue", such as exemption from control restrictions and enhanced routing (See explanation at www.ncs.gov/docs/GETS overview brief). Mike Pierce Artel --part1_bb.57be0b98.2fbe0f12_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable The fol= lowing comments are submitted on draft-ietf-sip-resource-priority-08:

1 NITS

Section 1, 7th paragraph (beginning "This document defines...") needs to be=20= rewritten to refer to the two headers which this document defines.

Section 4.6.5 wording of 2nd sentence is incomplete. I don't know what was i= ntended, so I can not suggest new wording.

Section 10.4 reference to "multi-layer priority preemption" needs to be chan= ged to "Multi-Level Precedence and Preemption".


2 Major problems

Section 4.2, rule 1 indicates that, if there is no resource shortage at the=20= moment, the RP actor omits the following steps. However, the following steps= are the authorization/authentication steps which must always be done first,= since one of the results of requesting a priority level, even when there is= no resource shortage at the moment, is to use the priority level during the= remainder of the call and to provide it to the destination user. For exampl= e, the level requested may prevent a later preemption after a shortage of re= sources occurs. Rule 1 should simply be the final sentence in Rule 1. This r= ule was not in version -05 of this draft, and I am unaware of any e-mail or=20= meeting discussion to add such a rule. Any attempt to explain or justify thi= s rule as it is currently written will only add confusion.

Section 4.7.1 2nd paragraph states that "Upon receiving a 417, the UAC MAY a= ttempt a subsequent request with the same or different resource value." This= is contrary to the policies for using priority values and should not be men= tioned. The user (human) is supposed to select the correct value before requ= ested a call setup. A UAC must never automatically attempt another request u= sing a different resource value upon receipt of a 417. Of course, a human us= er may choose to do whatever they are authorized to do when trying a new cal= l, but no device can be allowed to do this automatically, since it would be=20= violating the policies for the use of priority levels.

Section 10.2 states in the last sentence that the DSN (incorrectly written a= s "DRSN") uses preemption. This is misleading, since it may use other prefer= ential treatment procedures as well. It is unnecessary for this document to=20= state the algorithms/procedures used in each domain. Any mention of algorith= ms or procedures should only be as examples of what might occur in a domain.=

Sections 10.2 and 10.3
Security concerns make it appear that the variable length priority names wil= l be a problem. When individual SIP packets are encrypted for confidentialit= y, the lengths of signaling messages will be a function of the priority leve= l, thereby letting an attacker know when the volume of high priority calls i= ncreases. It appears now that it would be preferable to use same-length name= s for all priority levels.

Section 12.1 2nd paragraph forbids adding a new priority value to a namespac= e (MUST NOT). Previous versions of this draft (-06 and before) allowed it, w= hile advising against it (SHOULD NOT). For example, there is no reason why a= nother value cannot be added to DSN later, if the operator of the DSN wishes= to. If added, it is the responsibility of the operator of the DSN domain to= figure out how to do it to avoid interoperability problems. For example, th= ere is a possibility that the DSN will need to add a new level below Routine= . The RFC can not forbid this.


3 Other problems

Section 1, paragraph beginning "Since calls may traverse..." states that "it= is important that all such domains and elements apply the same algorithms f= or the same namespace as otherwise the end-to-end experience of privileged u= sers may be compromised." While this may be true for some combinations of pr= eemption followed by queuing, it is not necessarily true for all combination= s and for any algorithm that might be added later. Suggest that this sentenc= e be reworded to say: "It is important that careful consideration be made be= fore different algorithms are used at different places within a single call.= "

Although section 7 only gives "examples", the use of "DSN" causes confusion=20= since it shows an operation which would not be used in the DSN domain. Speci= fically, the inclusion of the R-P header in the 180 and 200 in 7.1 and the l= ist of accepted values in the 417 in 7.2 would not be used in the DSN since=20= this causes a security problem by telling the originator what precedence lev= el call the called party is involved in. The example should use a domain tha= t might use these techniques. Since there is none that is known to work this= way, the examples should use "Foo" and "Bar" as in Section 8.2.

Section 8.1 causes confusion since it implies the existence of a relative or= der between different namespaces. It should instead say that there is no def= ined relationship between the values of different namespaces and that RP act= ors may apply whatever algorithms or procedures they wish when dealing with=20= multiple namespaces, as long as the relative levels within each namespace ar= e maintained.

Section 10.3
The final paragraph should be deleted, since it is not the responsibility of= this document to describe the detailed operation within the DRSN, which cou= ld change at any time.

Section 11.3
The association of the requirement for confidentiality and integrity of the=20= user's data with the Resource-Priority header leads to confusion. They are u= nrelated requirements. Other policies and requirements dictate whether there= is a need for confidentiality and integrity of the user's data independentl= y from the need for precedence levels. The first paragraph should be deleted= so that this section only addresses the security of the R-P header itself,=20= since that is the subject of this document. Security of the user's data is n= ot the subject of this document.

Section 11.4
No system that allows the use of the R-P header should allow anonymity. In a= ny case, the issue of anonymity is independent from the use of R-P header an= d should not be mentioned in this document.

Section 12.1
The purpose of IANA registration is to prevent conflicts in assignment of na= mes and numbers, such as the namespace, and to ensure compatibility for thin= gs like the priority values. There is no need to include the "operation" (pr= eemption or preferential queuing) in the IANA registration. It is described=20= sufficiently in this document. In fact, the DSN uses other techniques beside= s preemption, such as exemption from network management controls, as describ= ed in draft-pierce-tsvwg-pref-treat-example, so it is wrong to register it a= s just "preemption". Likewise, ETS may use other techniques besides "queue",= such as exemption from control restrictions and enhanced routing (See expla= nation at www.ncs.gov/docs/GETS overview brief).


Mike Pierce
Artel

 --part1_bb.57be0b98.2fbe0f12_boundary-- --===============0749265106== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0749265106==-- From sip-bounces@ietf.org Thu May 19 12:09:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYna9-0004sn-SJ; Thu, 19 May 2005 12:09:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYna7-0004sX-HH for sip@megatron.ietf.org; Thu, 19 May 2005 12:09:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20155 for ; Thu, 19 May 2005 12:09:04 -0400 (EDT) Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYnrI-0006Ts-00 for sip@ietf.org; Thu, 19 May 2005 12:26:53 -0400 Received: from keywest (hide.pingtel.com [65.220.123.2]) by mail.pingtel.com (Postfix) with SMTP id 4835C6C02A for ; Thu, 19 May 2005 12:09:03 -0400 (EDT) From: "Dale Worley" To: Subject: Re: [Sip] Preventing replay in ACK Date: Thu, 19 May 2005 12:08:18 -0400 Message-ID: <00e301c55c8c$f94a2550$6a01010a@keywest> 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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > From: Avshalom Houri [AVSHALOM@il.ibm.com] > > > While a server can legitimately challenge most SIP requests, there > > are two requests defined by this document that require special > > handling for authentication: ACK and CANCEL. > > Under an authentication scheme that uses responses to carry values > > used to compute nonces (such as Digest), some problems come up for > > any requests that take no response, including ACK. For this reason, > > any credentials in the INVITE that were accepted by a server MUST be > > accepted by that server for the ACK. UACs creating an ACK message > > will duplicate all of the Authorization and Proxy-Authorization > > header field values that appeared in the INVITE to which the ACK > > corresponds. Servers MUST NOT attempt to challenge an ACK. > Logic says the UA should recalculate the authorization headers (using ACK as > method) in order to prevent someone to send an ACK using the INVITE credentials. > However text says duplicate. > > What is the right interpretation? I believe that what the text means is "UACs creating an ACK message will generate Authorization and Proxy-Authorization header field values for all of the credentials that were used to generate those header field values in the INVITE." Otherwise, SIP would require a modified digest authentication verification that would replace "ACK" methods with "INVITE" when calculating the hash values. A complication arises from nonce values, which a UAS may accept for only a limited time. Since the UAS cannot supply a new nonce value to the UAC for it to recalculate the headers, it must accept any nonce in the ACK that it accepted in the INVITE. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 19 13:45:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYp5Q-00017T-HA; Thu, 19 May 2005 13:45:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYp5M-00017A-Aa for sip@megatron.ietf.org; Thu, 19 May 2005 13:45:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28665 for ; Thu, 19 May 2005 13:45:26 -0400 (EDT) Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYpMW-0000l9-RN for sip@ietf.org; Thu, 19 May 2005 14:03:14 -0400 Received: from unknown (HELO alpha.jnpr.net) (172.24.18.126) by kremlin.juniper.net with ESMTP; 19 May 2005 10:45:15 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,121,1115017200"; d="scan'208,217"; a="333749920:sNHT1603290646" Received: from hadron.jnpr.net ([172.24.15.25]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 May 2005 10:45:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip-implementors] Re: [Sip] About Non-Invite Server Transaction Date: Thu, 19 May 2005 10:45:14 -0700 Message-ID: Thread-Topic: [Sip-implementors] Re: [Sip] About Non-Invite Server Transaction Thread-Index: AcVcidCQrXLYChT7SHuQWPbZFiZCUgADrXeQ From: "Anil Bollineni" To: "Dale Worley" , , X-OriginalArrivalTime: 19 May 2005 17:45:15.0079 (UTC) FILETIME=[837F1570:01C55C9A] X-Spam-Score: 0.3 (/) X-Scan-Signature: a630332fa112280ecc4c4186b5c9ea83 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1533106996==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1533106996== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55C9A.831BF29C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C55C9A.831BF29C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please see my answers below. Thanks, Anil -----Original Message----- From: sip-implementors-bounces@cs.columbia.edu [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of Dale Worley Sent: Thursday, May 19, 2005 8:44 AM To: sip-implementors@cs.columbia.edu; sip@ietf.org Subject: [Sip-implementors] Re: [Sip] About Non-Invite Server Transaction > From: Anil Bollineni [ABollineni@juniper.net] > > Assume a gateway sends two INVITE's say to two different UAS's with the same > Via branch parameter to two different users at the same time. It must not do that. See section 8.1.1.7 of RFC 3261: "The branch parameter value MUST be unique across space and time for all requests sent by the UA."=20 "The sent-by value is used as part of the matching process because there could be accidental or malicious duplication of branch parameters from different clients." I want to talk about NAT firewall. If two UA's behind NAT firewall generate same branch, and NAT ALG will change the VIA sent-by field to same value. In this case it could result matching same transaction. > I understand for retransmitted non-INVITE requests it MUST result sending same > response by UAS What is the purpose behind that.=20 i. I understand for retransmitted non-INVITE requests it MUST result sending same response by UAS. ii. It is like that to reduce processing retransmitted request AGAIN by UAS. I have a doubt on two call flows with non-INVITE server transactions.=20 I want to clear on this. Which one is true on the above for putting 'J' timers. Why can't retransmitted request non-INVITE request should be processed by UAS..=20 > Assume 200 response to BYE sent by server transaction, and 200 response is lost > before it reaches UAC. If it send BYE again, does UAS has to retransmit 200 > response? If the second BYE is a retransmission of the first BYE, as you have noted, the UAS is required to send the same 200 response. > During transfer if a REFER is sent to UAS and say server transaction say > transmit 503 (Declined), due to some temporary failures (e.g. user can't accept > more calls), and assume this 503 is delayed. Aftr this failure cleared out, and > REFER is retransmitted, and in this case the server transaction sends same error > message, even though the user is not busy. First of all, am I mentioning the > correct scenario.? If yes, what could be solution. If the second REFER is a retransmission of the first REFER, as you have noted, the UAS is required to send the same 503 response. If the second REFER is a *new* request (which can be determined by the increased CSeq number and the different Via branch parameter), the UAS may examine its situation and return a different response if it chooses. Dale _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors ------_=_NextPart_001_01C55C9A.831BF29C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Sip-implementors] Re: [Sip] About Non-Invite Server = Transaction

Please see my answers below.

Thanks,

Anil

-----Original Message-----
From: sip-implementors-bounces@cs.columbia.edu [mailto:sip-imple= mentors-bounces@cs.columbia.edu] On Behalf Of Dale Worley
Sent: Thursday, May 19, 2005 8:44 AM
To: sip-implementors@cs.columbia.edu; sip@ietf.org
Subject: [Sip-implementors] Re: [Sip] About Non-Invite Server = Transaction

> From: Anil Bollineni = [ABollineni@juniper.net]

>

> Assume a gateway sends two INVITE’s say to two different = UAS’s with the

same

> Via branch parameter to two different users at the same = time.

It must not do that.  See section 8.1.1.7 of RFC 3261:  = "The branch

parameter value MUST be unique across space and time for all = requests sent

by the UA."

      "The sent-by value is = used as part of the matching process because

      there could be = accidental or malicious duplication of branch

      parameters from = different clients."

I want to talk about NAT firewall. If two UA's behind NAT firewall generate same = branch, and NAT ALG will change the VIA sent-by field to same value. In = this case it could result matching same transaction.

> I understand for retransmitted non-INVITE requests it MUST = result sending

same

> response by UAS

What is the purpose behind that.

        i. I understand for retransmitted non-INVITE = requests it MUST result sending same response =      by = UAS.

        ii. It is like that to reduce processing retransmitted = request AGAIN by UAS. I have a doubt on  two call   flows with non-INVITE server = transactions.

I want to clear on this.  Which one is = true on = the above for putting 'J' timers. Why can't retransmitted request = non-INVITE request should be processed by UAS..

> Assume 200 response to BYE sent by server transaction, and 200 = response is

lost

> before it reaches UAC. If it send BYE again, does UAS has to = retransmit

200

> response?

If the second BYE is a retransmission of the first BYE, as you have = noted,

the UAS is required to send the same 200 = response.

> During transfer if a REFER is sent to UAS and say server = transaction say

> transmit 503 (Declined), due to some temporary failures (e.g. = user can’t

accept

> more calls), and assume this 503 is delayed. Aftr this failure = cleared

out, and

> REFER is retransmitted, and in this case the server = transaction sends same

error

> message, even though the user is not busy. First of all, am I = mentioning

the

> correct scenario.? If yes, what could be = solution.

If the second REFER is a retransmission of the first REFER, as you = have

noted, the UAS is required to send the same 503 response.  If = the second

REFER is a *new* request (which can be determined by the increased = CSeq

number and the different Via branch parameter), the UAS may examine = its

situation and return a different response if it = chooses.

Dale

_______________________________________________

Sip-implementors mailing list

Sip-implementors@cs.columbia.edu

h= ttp://lists.cs.columbia.edu/mailman/listinfo/sip-implementors<= /SPAN>

------_=_NextPart_001_01C55C9A.831BF29C-- --===============1533106996== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1533106996==-- From sip-bounces@ietf.org Thu May 19 14:00:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYpJj-0005dz-4k; Thu, 19 May 2005 14:00:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYpJh-0005de-UG for sip@megatron.ietf.org; Thu, 19 May 2005 14:00:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00077 for ; Thu, 19 May 2005 14:00:16 -0400 (EDT) Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYpas-0001DH-8Q for sip@ietf.org; Thu, 19 May 2005 14:18:04 -0400 Received: from keywest (hide.pingtel.com [65.220.123.2]) by mail.pingtel.com (Postfix) with SMTP id 79E3D6C02A; Thu, 19 May 2005 14:00:14 -0400 (EDT) From: "Dale Worley" To: , Subject: RE: [Sip-implementors] Re: [Sip] About Non-Invite Server Transaction Date: Thu, 19 May 2005 13:59:22 -0400 Message-ID: <010c01c55c9c$814edd10$6a01010a@keywest> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_010D_01C55C7A.FA3D3D10" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-MS-TNEF-Correlator: 0000000086BE11490398134F8F750E4364F87F8264983800 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_010D_01C55C7A.FA3D3D10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > From: Anil Bollineni [ABollineni@juniper.net] > I want to talk about NAT firewall. If two UA's behind NAT firewall generate same > branch, and NAT ALG will change the VIA sent-by field to same value. In this > case it could result matching same transaction. True. Which is why UAs should generate branch parameters that are unique over all space and time, that is, include some identifier of the UA itself to ensure that no other UA will generate the same branch parameter. > I understand for retransmitted non-INVITE requests it MUST result sending same > response by UAS > What is the purpose behind that. It is to ensure that the retransmission of the request provokes a "pure retransmission" of the response. In particular (1) the UAC does not attempt to re-execute the request if it receives it twice (which might cause erroneous operation), and (2) if the response to the first request is only delayed, and the UAC receives both the first response and the second response, both responses are identical (otherwise, how would you process them both?). Dale ------=_NextPart_000_010D_01C55C7A.FA3D3D10 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+Ih4RAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANUHBQATAA0AOwAAAAQAQAEB A5AGABgIAAAnAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAARQAAAFJFOiBbU2lwLWltcGxlbWVudG9yc10gUmU6IFtTaXBdIEFib3V0IE5vbi1JbnZpdGUg U2VydmVyIFRyYW5zYWN0aW9uAAAAAAIBcQABAAAAFgAAAAHFXJx8dMr2cnzCvUvJkINKvgj7ssgA AAIBHQwBAAAAGQAAAFNNVFA6RFdPUkxFWUBQSU5HVEVMLkNPTQAAAAALAAEOAAAAAEAABg4ACjBv nFzFAQIBCg4BAAAAGAAAAAAAAACGvhFJA5gTT491DkNk+H+CwoAAAAMAFA4BAAAACwAfDgEAAAAC AQkQAQAAAIUDAACBAwAAgAUAAExaRnXr0VpEAwAKAHJjcGcxMjXiMgNDdGV4BUEBAwH3/wqAAqQD 5AcTAoAP8wBQBFY/CFUHshElDlEDAQIAY2jhCsBzZXQyBgAGwxEl9jMERhO3MBIsETMI7wn3tjsY Hw4wNREiDGBjAFAzCwkBZDM2FlALpiA+tCBGA2E6EMADAkIG8IZsC4AJ8GkgW0Edx6hAanUDAHAE kC4eEDx0XQqiCoQKgBzwSSBmdwBwBUB0byEgB0BrDiABoAhgBUBOQVQgXGZpGCAg4B3gLiCwZkUh IHchQFVBJwQgYpRlaAuAZCILIGcJ8MUEkGEOsCBzYQeAIEZqYiUwbhPQLCGgI/VBvExHINADEAMg E9FuJPDFISBoJWBWSUElcAnwkHQtYnkiQWVsJADzITElgiB2B0AKUCLRA6AnKEAEACBGY2EUECBp 2wVABaB1KXEYIHMsIAVArQDAdBPQC4BnKcR0JlFRJYBjdGkCIC4f6lTycipSIFcj0BPQK8AEIJx3 aCkgI2AEIHNoLBP7JPcmRCAKsSWRDrAUACgxVyVAIaAYICAfMXEKUCCsb3YSgSSycwqwYyVg/ybC LiAHgCagMtMEACagC4D+YwpAAQAlcANwK7EBAAIw+waQEnJvIwEoUSNgK8EUEH5sIwEhQAnwLIAz MTLTbv0hQG8oQQXAN+EngyT3KEK/KdMxvi5rIKIfMASBcwGQ3yPxAhAFwBggLbNtK9AOsEMkADlw bi1JTiiAVD5FLFEzkT4ABCAr0U1V7lMiMCxlKMFkLSYgRixh3nACICuhKREjYFMf7C+g+zWDKDNw CHBDIENSI8Qy0vsi0B/qSUT0OJwoQj6nBBAfLjE3ZkA1MhADYHZva7EHkWEgIkWBSQ4iSgjfQxQv cSqRCrEuIGMsIArBCCgxKTeVQyBkb+8HkTlwMwE/MW0FMSExGCD+LQ7ABZAh4CgkSoYGkCvC+xgg NJBpM+BAoyMgDeAlYE4oMDAvwj8QZ2gr4WF+dSuhBJADYB4QCGAEIG+XH2ElQC4xKSakKDJPMP9S gU1KISMoUSJRStFSB1Wx3G5sKSABAAtgeQmAJqT/T1ZS5wbgKEBYO0MVWnYUEP8FoCPxQvYmoFvD QvZLcTMx9zbEK4ADICg5owPxNTEwwPcH4CMwLCJ5CGBK8jSQBBGlKEFtW7M/KS5rRAdABSW1fWTw AAAAAwAJWQEAAAADAAFuIAAAAAsAAIAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAAAwACgAgg BgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADAAeACCAGAAAAAADAAAAAAAAARgAAAABShQAAJ2oB AB4ACYAIIAYAAAAAAMAAAAAAAABGAAAAAFSFAAABAAAABAAAADkuMAAeAAqACCAGAAAAAADAAAAA AAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgALgAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAAB AAAAAAAAAB4ADIAIIAYAAAAAAMAAAAAAAABGAAAAADiFAAABAAAAAQAAAAAAAAALABGACCAGAAAA AADAAAAAAAAARgAAAAAGhQAAAAAAAAMAEoAIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAACwAb gAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADAByACCAGAAAAAADAAAAAAAAARgAAAAARhQAA AAAAAAMAHoAIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAAAgH4DwEAAAAQAAAAhr4RSQOYE0+P dQ5DZPh/ggIB+g8BAAAAEAAAAIa+EUkDmBNPj3UOQ2T4f4ICAfsPAQAAAJUAAAAAAAAAOKG7EAXl EBqhuwgAKypWwgAAbXNwc3QuZGxsAAAAAABOSVRB+b+4AQCqADfZbgAAAEM6XERvY3VtZW50cyBh bmQgU2V0dGluZ3NcZHdvcmxleVxMb2NhbCBTZXR0aW5nc1xBcHBsaWNhdGlvbiBEYXRhXE1pY3Jv c29mdFxPdXRsb29rXG1haWxib3gucHN0AAAAAAMA/g8FAAAAAwANNP03AAACAX8AAQAAADEAAAAw MDAwMDAwMDg2QkUxMTQ5MDM5ODEzNEY4Rjc1MEU0MzY0Rjg3RjgyNjQ5ODM4MDAAAAAAAwAGEGEv 7JUDAAcQXgMAAAMAEBABAAAAAwAREAAAAAAeAAgQAQAAAGUAAABGUk9NOkFOSUxCT0xMSU5FTklB Qk9MTElORU5JQEpVTklQRVJORVRJV0FOVFRPVEFMS0FCT1VUTkFURklSRVdBTExJRlRXT1VBU0JF SElORE5BVEZJUkVXQUxMR0VORVJBVEVTAAAAAP3n ------=_NextPart_000_010D_01C55C7A.FA3D3D10 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------=_NextPart_000_010D_01C55C7A.FA3D3D10-- From sip-bounces@ietf.org Thu May 19 16:32:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYrgo-0003JG-3y; Thu, 19 May 2005 16:32:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYrgn-0003JB-8N for sip@megatron.ietf.org; Thu, 19 May 2005 16:32:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28064 for ; Thu, 19 May 2005 16:32:14 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYry0-0001Pc-42 for sip@ietf.org; Thu, 19 May 2005 16:50:05 -0400 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j4JKVOD00396; Thu, 19 May 2005 16:31:24 -0400 (EDT) Received: from [127.0.0.1] (acart197.ca.nortel.com [47.130.17.76]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 29WLYRPG; Thu, 19 May 2005 16:31:58 -0400 Message-ID: <428CF7BB.5070302@nortel.com> Date: Thu, 19 May 2005 16:31:55 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] updated GRUU spec References: <421D6223.5050607@cisco.com> In-Reply-To: <421D6223.5050607@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Minor comment on the GRUU spec. At the beginning of section 8.4.1, the procedure reads: "... the proxy MUST check if the Request URI is a GRUU created by that domain. "If the GRUU does not exist within the domain, the proxy MUST generate a 404 (Not Found) response to the request." I'd suggest that "GRUU" in that last paragraph be changed to "Request URI", since the proxy doesn't, absent a GRID parameter, know that it is dealing with a GRUU. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 20 01:39:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ0E4-0004NJ-Ea; Fri, 20 May 2005 01:39:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ0E2-0004NB-RL for sip@megatron.ietf.org; Fri, 20 May 2005 01:39:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16215 for ; Fri, 20 May 2005 01:39:09 -0400 (EDT) Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZ0VL-0006yP-Go for sip@ietf.org; Fri, 20 May 2005 01:57:03 -0400 Received: from az33exr04.mot.com ([10.64.251.234]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id j4K5sOrd015127 for ; Thu, 19 May 2005 22:54:24 -0700 (MST) Received: from zin24exm01.ap.mot.com (zin24exm01.ap.mot.com [10.232.25.1]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id j4K5fXOR011360 for ; Fri, 20 May 2005 00:41:34 -0500 (CDT) Received: by zin24exm01.ap.mot.com with Internet Mail Service (5.5.2657.72) id ; Fri, 20 May 2005 11:09:00 +0530 Message-ID: <772BCEF88A1DD91191F80011856715F3022356FD@zin24exm01.ap.mot.com> From: Chauhan Bhavik-A20762 To: "'Paul Kyzivat'" Date: Fri, 20 May 2005 11:09:00 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: sip@ietf.org, sip-implementors@cs.columbia.edu Subject: [Sip] RE: [Sip-implementors] UPDATE with ANSWER? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Yes Agree, The FAQ creation afford would be appreciated and this will reduce exploration through threads which can be like debate than conclusion and in fact this is quite natural. Also I would be thankful if we maintain "agreed upon" things which are not cited in RFCs to ascertain the unanimity of all UACs/UASs implementation. Thanks, Bhavik -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Thursday, May 19, 2005 7:10 PM To: Chauhan Bhavik-A20762 Cc: sip@ietf.org; sip-implementors@cs.columbia.edu Subject: Re: [Sip-implementors] UPDATE with ANSWER? We really need to create an FAQ about this. A long time ago, probably in the thread you cite, we debated this extensively. It is true that the RFCs are not entirely clear on this, and reasonable people can differ in interpretation of them. But we finally came to some agreement on it. I am quite sure we agreed that UPDATE could *not* be used to send an answer. We ended up with a quite restrictive list of cases for how INVITE, UPDATE, PRACK, and their responses and ACK can be used to convey offer/answer. I was one who originally argued for fewer restrictions. But there were issues with that, and the restrictive approach won out. In practice I don't think the restrictions impose any great burden. Paul Chauhan Bhavik-A20762 wrote: > Hi all, > > I was exploring the possibility for the UPDATE to send the Answer, As > I haven't found any explicit restriction in RFC 3311. > > I went through the older Thread > http://lists.cs.columbia.edu/pipermail/sip-implementors/2004-January/0 > 06017. > html > .html> > and came across following Qs which I found not clarified though. > > 1. Can UPDATE be used to send an answer SDP ? > Consider the following scenario: > - INVITE was sent without SDP > - 18x is received with Offer SDP > - There is no PRACK exchange because 18x does not contain a > Require:100rel header > Now can UPDATE be used to send answer SDP?? > > 2. As per RFC 3311, UPDATE method should be used only if dialog is > established. > If INVITE/18x exchange happened without PRACK, can both ends treat > this as early dialog and feel free to use UPDATE ? > > 3. Is 18x send/recv over TCP considered reliable ? > In the following scenario: > - INVITE with offer sdp sent > - 18x over TCP with answer sdp recvd (No PRACK exchange happened) > Now can the caller/calleee use UPDATE ? > > Can any body clarify the same? > > Thanks in advance, > Bhavik Chauhan > > _______________________________________________ > Sip-implementors mailing list Sip-implementors@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 20 06:31:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ4ma-0005w1-Nx; Fri, 20 May 2005 06:31:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ4mY-0005vv-B0 for sip@megatron.ietf.org; Fri, 20 May 2005 06:31:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28207 for ; Fri, 20 May 2005 06:31:01 -0400 (EDT) Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZ53p-0005Sw-Jb for sip@ietf.org; Fri, 20 May 2005 06:48:59 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id j4KAUpqF186068 for ; Fri, 20 May 2005 10:30:51 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4KAUpqt092850 for ; Fri, 20 May 2005 12:30:51 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j4KAUpEe021347 for ; Fri, 20 May 2005 12:30:51 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j4KAUpC3021341; Fri, 20 May 2005 12:30:51 +0200 In-Reply-To: <00e301c55c8c$f94a2550$6a01010a@keywest> To: "Dale Worley" , Chadha Retesh-A19894 Subject: Re: [Sip] Preventing replay in ACK MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_M4_01112005 Beta 3NP January 11, 2005 Message-ID: From: Avshalom Houri Date: Fri, 20 May 2005 13:30:49 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(V70_M4_01112005 Sidepack 2802|March 1, 2005) at 20/05/2005 13:30:51, Serialize complete at 20/05/2005 13:30:51 X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1911672374==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============1911672374== Content-Type: multipart/alternative; boundary="=_alternative 0039C108C2257007_=" This is a multipart message in MIME format. --=_alternative 0039C108C2257007_= Content-Type: text/plain; charset="US-ASCII" Dale and Retesh, Thanks for replying. I may be missing something but how we do prevent someone to listen on the line and send an ACK containing different ports etc. using the INVITE credentials? Thanks Avshalom "Dale Worley" Sent by: sip-bounces@ietf.org 19/05/2005 07:08 PM To cc Subject Re: [Sip] Preventing replay in ACK > From: Avshalom Houri [AVSHALOM@il.ibm.com] > > > While a server can legitimately challenge most SIP requests, there > > are two requests defined by this document that require special > > handling for authentication: ACK and CANCEL. > > Under an authentication scheme that uses responses to carry values > > used to compute nonces (such as Digest), some problems come up for > > any requests that take no response, including ACK. For this reason, > > any credentials in the INVITE that were accepted by a server MUST be > > accepted by that server for the ACK. UACs creating an ACK message > > will duplicate all of the Authorization and Proxy-Authorization > > header field values that appeared in the INVITE to which the ACK > > corresponds. Servers MUST NOT attempt to challenge an ACK. > Logic says the UA should recalculate the authorization headers (using ACK as > method) in order to prevent someone to send an ACK using the INVITE credentials. > However text says duplicate. > > What is the right interpretation? I believe that what the text means is "UACs creating an ACK message will generate Authorization and Proxy-Authorization header field values for all of the credentials that were used to generate those header field values in the INVITE." Otherwise, SIP would require a modified digest authentication verification that would replace "ACK" methods with "INVITE" when calculating the hash values. A complication arises from nonce values, which a UAS may accept for only a limited time. Since the UAS cannot supply a new nonce value to the UAC for it to recalculate the headers, it must accept any nonce in the ACK that it accepted in the INVITE. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --=_alternative 0039C108C2257007_= Content-Type: text/html; charset="US-ASCII"
Dale and Retesh,

Thanks for replying.

I may be missing something but how we do prevent someone to listen on the line and send an ACK containing different ports etc. using the INVITE credentials?

Thanks
Avshalom



"Dale Worley" <dworley@pingtel.com>
Sent by: sip-bounces@ietf.org

19/05/2005 07:08 PM

To
<sip@ietf.org>
cc
Subject
Re: [Sip] Preventing replay in ACK





> From: Avshalom Houri [AVSHALOM@il.ibm.com]
>
> > While a server can legitimately challenge most SIP requests, there
> > are two requests defined by this document that require special
> > handling for authentication: ACK and CANCEL.
> > Under an authentication scheme that uses responses to carry values
> > used to compute nonces (such as Digest), some problems come up for
> > any requests that take no response, including ACK.  For this reason,
> > any credentials in the INVITE that were accepted by a server MUST be
> > accepted by that server for the ACK.  UACs creating an ACK message
> > will duplicate all of the Authorization and Proxy-Authorization
> > header field values that appeared in the INVITE to which the ACK
> > corresponds.  Servers MUST NOT attempt to challenge an ACK.

> Logic says the UA should recalculate the authorization headers (using ACK
as
> method) in order to prevent someone to send an ACK using the INVITE
credentials.
> However text says duplicate.
>
> What is the right interpretation?

I believe that what the text means is "UACs creating an ACK message will
generate Authorization and Proxy-Authorization header field values for all
of the credentials that were used to generate those header field values in
the INVITE."  Otherwise, SIP would require a modified digest authentication
verification that would replace "ACK" methods with "INVITE" when calculating
the hash values.

A complication arises from nonce values, which a UAS may accept for only a
limited time.  Since the UAS cannot supply a new nonce value to the UAC for
it to recalculate the headers, it must accept any nonce in the ACK that it
accepted in the INVITE.

Dale


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--=_alternative 0039C108C2257007_=-- --===============1911672374== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1911672374==-- From sip-bounces@ietf.org Fri May 20 11:12:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ9Az-0000EF-My; Fri, 20 May 2005 11:12:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ9Ax-0000Dg-4G for sip@megatron.ietf.org; Fri, 20 May 2005 11:12:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26828 for ; Fri, 20 May 2005 11:12:32 -0400 (EDT) Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZ9SJ-0004cE-KI for sip@ietf.org; Fri, 20 May 2005 11:30:32 -0400 Received: from keywest (hide.pingtel.com [65.220.123.2]) by mail.pingtel.com (Postfix) with SMTP id 769876C02F for ; Fri, 20 May 2005 11:12:28 -0400 (EDT) From: "Dale Worley" To: Subject: Re: [Sip] Preventing replay in ACK Date: Fri, 20 May 2005 11:11:39 -0400 Message-ID: <003801c55d4e$39ff6bc0$6a01010a@keywest> 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > From: Avshalom Houri [AVSHALOM@il.ibm.com] > > I may be missing something but how we do prevent someone to listen on the line > and send an ACK containing different ports etc. using the INVITE credentials? Presumably those port numbers are covered by the digest authentication hash, and so cannot be forged. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 20 12:03:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ9xl-0003T1-6I; Fri, 20 May 2005 12:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ9xj-0003R2-Al for sip@megatron.ietf.org; Fri, 20 May 2005 12:02:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01491 for ; Fri, 20 May 2005 12:02:56 -0400 (EDT) Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZAF6-0005us-BV for sip@ietf.org; Fri, 20 May 2005 12:20:58 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id j4KG2mJl147972 for ; Fri, 20 May 2005 16:02:48 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4KG2mqt108566 for ; Fri, 20 May 2005 18:02:48 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j4KG2mfJ005651 for ; Fri, 20 May 2005 18:02:48 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j4KG2mWK005648 for ; Fri, 20 May 2005 18:02:48 +0200 In-Reply-To: <003801c55d4e$39ff6bc0$6a01010a@keywest> To: sip@ietf.org Subject: Re: [Sip] Preventing replay in ACK MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_M4_01112005 Beta 3NP January 11, 2005 Message-ID: From: Avshalom Houri Date: Fri, 20 May 2005 19:02:39 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(V70_M4_01112005 Sidepack 2802|March 1, 2005) at 20/05/2005 19:02:48, Serialize complete at 20/05/2005 19:02:48 X-Spam-Score: 0.8 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1452218728==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============1452218728== Content-Type: multipart/alternative; boundary="=_alternative 005821E0C2257007_=" This is a multipart message in MIME format. --=_alternative 005821E0C2257007_= Content-Type: text/plain; charset="US-ASCII" I mean send different ports in the SDP. How we can prevent this? These ports are not part of the digest. Avshalom "Dale Worley" Sent by: sip-bounces@ietf.org 20/05/2005 06:11 PM To cc Subject Re: [Sip] Preventing replay in ACK > From: Avshalom Houri [AVSHALOM@il.ibm.com] > > I may be missing something but how we do prevent someone to listen on the line > and send an ACK containing different ports etc. using the INVITE credentials? Presumably those port numbers are covered by the digest authentication hash, and so cannot be forged. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --=_alternative 005821E0C2257007_= Content-Type: text/html; charset="US-ASCII"
I mean send different ports in the SDP. How we can prevent this? These ports are not part of the digest.

Avshalom



"Dale Worley" <dworley@pingtel.com>
Sent by: sip-bounces@ietf.org

20/05/2005 06:11 PM

To
<sip@ietf.org>
cc
Subject
Re: [Sip] Preventing replay in ACK





> From: Avshalom Houri [AVSHALOM@il.ibm.com]
>
> I may be missing something but how we do prevent someone to listen on the
line
> and send an ACK containing different ports etc. using the INVITE
credentials?

Presumably those port numbers are covered by the digest authentication hash,
and so cannot be forged.

Dale



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--=_alternative 005821E0C2257007_=-- --===============1452218728== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1452218728==-- From sip-bounces@ietf.org Fri May 20 14:35:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCKz-00057f-8N; Fri, 20 May 2005 14:35:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCKx-00057H-4g for sip@megatron.ietf.org; Fri, 20 May 2005 14:35:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21311 for ; Fri, 20 May 2005 14:35:05 -0400 (EDT) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZCcK-0002aI-2f for sip@ietf.org; Fri, 20 May 2005 14:53:06 -0400 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id j4KIYrHP030010; Fri, 20 May 2005 18:34:53 GMT Received: from stntexch03.cis.neustar.com ([10.31.13.45]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 May 2005 14:34:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Preventing replay in ACK Date: Fri, 20 May 2005 14:34:52 -0400 Message-ID: <24EAE5D4448B9D4592C6D234CBEBD59701502EC4@stntexch03.cis.neustar.com> Thread-Topic: [Sip] Preventing replay in ACK Thread-Index: AcVdVm4i4fpRnVwUTSiyG7Wy5zrbAgADV1WQ From: "Peterson, Jon" To: "Avshalom Houri" , X-OriginalArrivalTime: 20 May 2005 18:34:52.0870 (UTC) FILETIME=[9CCFAE60:01C55D6A] X-Spam-Score: 0.7 (/) X-Scan-Signature: 850245b51c39701e2700a112f3032caa Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1549863935==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1549863935== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55D6A.9C8BF6C0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C55D6A.9C8BF6C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 The inability to challenge ACK and CANCEL is, in my mind, a pretty = serious defect in the current SIP security situation. CANCEL's = predicament is, ultimately, a lot worse than ACK's, though, since CANCEL = is consumed hop-by-hop - at least one can have a reasonable expectation = that an ACK request will arrive at its destination in roughly the same = form that it was sent. =20 ACK's problem is simply that one cannot send a response to ACK. So = firstly, this means a UAS or proxy could not challenge a request that = does not contain an ACK - of course, ACKs could contain Digest headers = even though it was not challenged in the first place (thanks to cached = nonces and so on). More seriously, if a UAS receives an ACK that was, = for some reason, invalid, they couldn't reject the message in any way = that would be intelligbile to the UAC (the UAS could just tear down the = dialog, but the UAC wouldn't really know why). So it's not clear that it = does a whole lot of good in terms of enabling UAS policies to secure the = ACK. =20 That much said, Mr. Worley is quite correct that if Digest 'auth-int' is = used, the body of the ACK request will be covered by the Digest = signature. It is also worth noting that sip-identity-05 allows the = Identity header and surrounding apparatus to appear in ACK, which = provides another avenue to body security. If the ACK were sent over a = TLS connection that was established at the time that the initial INVITE = was sent, then even if no Digest headers appeared in the ACK, the = authentication service would be within its rights to apply Identity = headers to the ACK request. =20 Jon Peterson NeuStar, Inc. -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of = Avshalom Houri Sent: Friday, May 20, 2005 9:03 AM To: sip@ietf.org Subject: Re: [Sip] Preventing replay in ACK I mean send different ports in the SDP. How we can prevent this? These = ports are not part of the digest.=20 Avshalom=20 "Dale Worley" =20 Sent by: sip-bounces@ietf.org=20 20/05/2005 06:11 PM=20 To =20 cc Subject Re: [Sip] Preventing replay in ACK =09 > From: Avshalom Houri [AVSHALOM@il.ibm.com] > > I may be missing something but how we do prevent someone to listen on = the line > and send an ACK containing different ports etc. using the INVITE credentials? Presumably those port numbers are covered by the digest authentication = hash, and so cannot be forged. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_001_01C55D6A.9C8BF6C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
The=20 inability to challenge ACK and CANCEL is, in my mind, a pretty serious = defect in=20 the current SIP security situation. CANCEL's predicament is, ultimately, = a lot=20 worse than ACK's, though, since CANCEL is consumed hop-by-hop - at least = one can=20 have a reasonable expectation that an ACK request will arrive at its = destination=20 in roughly the same form that it was sent.
 
ACK's=20 problem is simply that one cannot send a response to ACK. So firstly, = this means=20 a UAS or proxy could not challenge a request that does not contain an = ACK - of=20 course, ACKs could contain Digest headers even though it was not = challenged in=20 the first place (thanks to cached nonces and so on). More seriously, if = a UAS=20 receives an ACK that was, for some reason, invalid, they couldn't reject = the=20 message in any way that would be intelligbile to the UAC (the UAS could = just=20 tear down the dialog, but the UAC wouldn't really know why). So it's not = clear=20 that it does a whole lot of good in terms of enabling UAS policies to = secure the=20 ACK.
 
That=20 much said, Mr. Worley is quite correct that if Digest 'auth-int' is = used, the=20 body of the ACK request will be covered by the Digest signature.=20 It is also worth noting that sip-identity-05 allows the = Identity header=20 and surrounding apparatus to appear in ACK, which provides another = avenue to=20 body security. If the ACK were sent over a TLS connection that was = established=20 at the time that the initial INVITE was sent, then even if no Digest = headers=20 appeared in the ACK, the authentication service would be within its = rights to=20 apply Identity headers to the ACK request.
 
Jon=20 Peterson
NeuStar, Inc.
-----Original Message-----
From: = sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org]On Behalf Of Avshalom=20 Houri
Sent: Friday, May 20, 2005 9:03 AM
To:=20 sip@ietf.org
Subject: Re: [Sip] Preventing replay in=20 ACK


I mean = send different=20 ports in the SDP. How we can prevent this? These ports are not part of = the=20 digest.

Avshalom=20



"Dale = Worley"=20 <dworley@pingtel.com>
Sent by: sip-bounces@ietf.org=20

20/05/2005 06:11 PM =

To
<sip@ietf.org>=20
cc
Subject
Re: [Sip] Preventing = replay in=20 ACK

=




> From: Avshalom Houri = [AVSHALOM@il.ibm.com]
>
> I=20 may be missing something but how we do prevent someone to listen on=20 the
line
> and send an ACK containing different ports etc. = using the=20 INVITE
credentials?

Presumably those port numbers are = covered by the=20 digest authentication hash,
and so cannot be=20 = forged.

Dale



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

------_=_NextPart_001_01C55D6A.9C8BF6C0-- --===============1549863935== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1549863935==-- From sip-bounces@ietf.org Sun May 22 15:44:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZwMx-0008Cb-9Y; Sun, 22 May 2005 15:44:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZwMv-0008AB-Bo for sip@megatron.ietf.org; Sun, 22 May 2005 15:44:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19478 for ; Sun, 22 May 2005 15:44:11 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZwek-0007l8-QZ for sip@ietf.org; Sun, 22 May 2005 16:02:39 -0400 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j4MJi1NM022638 for ; Sun, 22 May 2005 14:44:01 -0500 (CDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sun, 22 May 2005 14:43:51 -0500 Message-ID: <17D8724A2A8D9542B2B8AE546B9E5BBC045FB737@az4315exch001u.phx.lucent.com> From: "GOLDMAN, STUART O (STUART)" To: sip@ietf.org Date: Sun, 22 May 2005 14:43:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.5 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: Subject: [Sip] comments on draft-ietf-sip-resource-priority-08 and draft-ietf-s ipping-reason-header-for-preemption-02 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1389967108==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org 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. --===============1389967108== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55F06.93EC9E8C" 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_01C55F06.93EC9E8C Content-Type: text/plain; charset="iso-8859-1" ---------------------------------------------------------------------------- The following comments are submitted on draft-ietf-sip-resource-priority-08: Section 4.2 Rule 1 says "... If there are sufficient resources, treat the request like a regular SIP request and skip the remaining steps. (This does not cause removal of the header fields.)" Is authorization to be repeated at each node even within a given network or is it sufficient that the first node in the network perform it? If the first node is following rule 1, how would the subsequent node know if authorization had been performed or if the prior node had sufficient resources and skipped that step? Section 4.3 says "Following standard SIP behavior, if a SIP request contains the 'Require' header field with the 'resource-priority' option tag, a SIP element MUST respond with a 420 (Bad Extension) if it does not support the SIP extensions described in this document. It then lists "resource-priority" in the 'Unsupported' header field included in the response." If a SIP request contains the 'Require' header field with multiple proxies along the path and one of the proxies is not supported, is the 'resource-priority' header still applied to the remaining proxies? In section 4.5.2, the process is defined for an RP actor to handle the priority request. Depending on implementations, some real-time services may be in weighted queues rather than priority queues and these CoS also may require multi-level priority handling. Shouldn't a similar process be applicable to weighted queuing also? Shouldn't priority signaling and processing be independent of how the routers handle the session packets in their queuing and scheduling mechanism?" Section 4.7.1 paragraph 2 says "Upon receiving a 417 (Unknown Resource-Priority) response, the UAC MAY attempt a subsequent request with the same or different resource value. If available, it SHOULD choose authorized resource values from the set of values returned in the 'Accept-Resource-Priority'." It would be useful to understand the criteria used by the UAC to request a different resource value from the set returned. It is not clear if an interoperability problem might exist in the absence of such criteria. Section 4.7.3 para 3: Why does it say "SHOULD"? Intermediate elements cannot process the RPH unless the RPH is in the "outer" header. Is it correct that the RPH "MUST" be in the "outer" header if RPH is used? Section 4.7.3 para 5: Perhaps this paragraph could be reworded to more clearly state its purpose. Is it correct that once an element sets or receives a RPH with a given r-value, it MUST NOT send a RPH with a different r-value for the same call?- it shouldn't matter how the proxy is implemented. If it is illegal for the UA to change the value, is the proxy then free to drop the message if it detects the change? Must it check for a change? Section 12.1 Says that "New priority-values MUST NOT be added to existing namespace registries. The registration MUST describe, in the registration itself, how SIP elements should treat requests from that namespace in 'operation', e.g., whether preemption or only preferential queuing are allowed. " This seems to prohibit the later addition of a new priority value to a namespace. If this is because of potential Interoperability problems, would it be possible to explain them? Is this wise given the possibility of the need for an addition should unforeseen event occur, and that the addition may need to occur rapidly? Is it wise to explicitly specify operations in the IANA registration as these may not be complete and may be modified/expanded in the future? ----------------------------------------------------------------------------- The following comments are submitted on draft-ietf-sipping-reason-header-for-preemption-02. Section 5 Perhaps this section could be reworded to better express that network preemption is a generic function that can be accomplished by various technical procedures rather than to presume it is only "text="RSVP Preemption"." Stu Goldman Bell Labs - Lucent Technologies 5531 E. Kelton LN Scottsdale,AZ 85254 623-582-7136 voicemail 602 493 8438 home office ------_=_NextPart_001_01C55F06.93EC9E8C Content-Type: text/html; charset="iso-8859-1"
----------------------------------------------------------------------------
The following comments are submitted on draft-ietf-sip-resource-priority-08:

Section 4.2 Rule 1 says "... If there are sufficient resources, treat the request like a regular SIP request and skip the remaining steps.  (This does not cause removal of the header fields.)"   Is authorization to be repeated at each node even within a given network or is it sufficient that the first node in the network perform it? If the first node is following rule 1, how would the subsequent node know if authorization had been performed or if the prior node had sufficient resources and skipped that step?

Section 4.3 says "Following standard SIP behavior, if a SIP request contains the  'Require' header field with the 'resource-priority' option tag, a SIP element MUST respond with a 420 (Bad Extension) if it does not support the SIP extensions described in this document.  It then lists  "resource-priority" in the 'Unsupported' header field included in the response."  If a SIP request contains the 'Require' header field with multiple proxies along the path and one of the proxies is not supported, is the 'resource-priority' header still applied to the remaining proxies?

In section 4.5.2, the process is defined for an RP actor to handle the priority request. Depending on implementations, some real-time services may be in weighted queues rather than priority queues and these CoS also may require multi-level priority handling. Shouldn't a similar process be applicable to weighted queuing also? Shouldn't priority signaling and processing be independent of how the routers handle the session packets in their queuing and scheduling mechanism?"

Section 4.7.1  paragraph 2 says "Upon receiving a 417 (Unknown Resource-Priority) response, the UAC MAY attempt a subsequent request with the same or different resource value.  If available, it SHOULD choose authorized resource values from the set of values returned in the 'Accept-Resource-Priority'." It would be useful to understand the criteria used by the UAC to request a different resource value from the set returned. It is not clear if an interoperability problem might exist in the absence of such criteria.
 
Section 4.7.3 para 3: Why does it say "SHOULD"? Intermediate elements cannot process the RPH unless the RPH is in the "outer" header. Is it correct that the RPH "MUST" be in the "outer" header if RPH is used?

Section 4.7.3 para 5: Perhaps this paragraph could be reworded to more clearly state its purpose. Is it correct that once an element sets or receives a RPH with a given r-value, it MUST NOT send a RPH with a different r-value for the same call?- it shouldn't matter how the proxy is implemented. If it is illegal for the UA to change the value, is the proxy then free to drop the message if it detects the change? Must it check for a change?

Section 12.1  Says that "New priority-values MUST NOT be added to existing namespace registries. The registration MUST describe, in the registration itself, how SIP elements should treat requests from that namespace in 'operation',   e.g., whether preemption or only preferential queuing are allowed. "   This seems to prohibit the later addition of  a new priority value to a namespace. If this is because of potential Interoperability problems, would it be possible to explain them? Is this wise given the possibility of the need for an addition should unforeseen event occur, and that the addition may need to occur rapidly? Is it wise to explicitly specify operations in the IANA registration as these may not be complete and may be modified/expanded in the future?



-----------------------------------------------------------------------------
The following comments are submitted on draft-ietf-sipping-reason-header-for-preemption-02.

Section 5

Perhaps this section could be reworded to better express that network preemption is a generic function that can be accomplished by various technical procedures rather than to presume it is  only  "text="RSVP Preemption"."

Stu Goldman

Bell Labs   -  Lucent Technologies

5531 E. Kelton LN

Scottsdale,AZ 85254

623-582-7136 voicemail  602 493 8438 home office

 
------_=_NextPart_001_01C55F06.93EC9E8C-- --===============1389967108== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1389967108==-- From sip-bounces@ietf.org Mon May 23 07:14:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaAt4-0007OR-BX; Mon, 23 May 2005 07:14:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYifk-0002y8-Tv for sip@megatron.ietf.org; Thu, 19 May 2005 06:54:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19131 for ; Thu, 19 May 2005 06:54:33 -0400 (EDT) Received: from [217.205.209.100] (helo=vegastream.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYiws-0005Rr-BX for sip@ietf.org; Thu, 19 May 2005 07:12:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip-implementors] RE: [Sip] UPDATE with ANSWER? (18x using TCP) Date: Thu, 19 May 2005 11:54:15 +0100 Message-ID: <8F1F2062CA7D754A838F0E66097D23A0741EBD@veg-brk-svr-pri.vegastream> Thread-Topic: [Sip-implementors] RE: [Sip] UPDATE with ANSWER? Thread-Index: AcVcX4Z+9MsReTYTTHmPFhWfVcyM6gAAUPjQ From: "Attila Sipos" To: "Avasarala Ranjit-A20990" , "Chauhan Bhavik-A20762" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 23 May 2005 07:14:20 -0400 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, I just thought I'd try to clarify something: =20 >>3. Is 18x send/recv over TCP considered reliable ? >> In the following scenario: >> - INVITE with offer sdp sent >> - 18x over TCP with answer sdp recvd (No PRACK exchange happened) >> Now can the caller/calleee use UPDATE ? >> >>Can any body clarify the same? In SIP, TCP is not considered to be any more reliable than UDP. In other words - whether you use TCP or UDP: 1. you have to do retransmissions of SIP messages for TCP (in the same way that you do for UDP) 2. As far as SIP is concerned, PRACK is the only reliable way to transport 18x messages (using TCP or UDP) Regards, Attila Attila Sipos http://www.vegastream.com >> -----Original Message----- >> From: sip-implementors-bounces@cs.columbia.edu >> [mailto:sip-implementors-bounces@cs.columbia.edu]On Behalf=20 >> Of Avasarala >> Ranjit-A20990 >> Sent: 19 May 2005 10:51 >> To: Chauhan Bhavik-A20762; sip@ietf.org; >> sip-implementors@cs.columbia.edu >> Subject: [Sip-implementors] RE: [Sip] UPDATE with ANSWER? >>=20 >>=20 >> Hi >> No UPDATE cannot be used to send answer, since UPDATE=20 >> can be used only >> after a dialog is established.=20 >> =20 >> =20 >> =20 >>=20 >> Regards=20 >> Ranjit=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of >> Chauhan Bhavik-A20762 >> Sent: Thursday, May 19, 2005 3:10 PM >> To: sip@ietf.org; sip-implementors@cs.columbia.edu >> Subject: [Sip] UPDATE with ANSWER? >>=20 >>=20 >> Hi all, >> =20 >> I was exploring the possibility for the UPDATE to send the Answer, >> As I haven't found any explicit restriction in RFC 3311. >> =20 >> I went through the older Thread >> http://lists.cs.columbia.edu/pipermail/sip-implementors/2004- January/006017. html =20 and came across following Qs which I found not clarified though. =20 1. Can UPDATE be used to send an answer SDP ? Consider the following scenario: - INVITE was sent without SDP - 18x is received with Offer SDP - There is no PRACK exchange because 18x does not contain a Require:100rel header Now can UPDATE be used to send answer SDP?? =20 2. As per RFC 3311, UPDATE method should be used only if dialog is established. If INVITE/18x exchange happened without PRACK, can both ends treat this as early dialog and feel free to use UPDATE ? =20 3. Is 18x send/recv over TCP considered reliable ? In the following scenario: - INVITE with offer sdp sent - 18x over TCP with answer sdp recvd (No PRACK exchange happened) Now can the caller/calleee use UPDATE ? Can any body clarify the same? =20 Thanks in advance, Bhavik Chauhan =20 _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 23 10:20:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaDnF-0002IJ-T8; Mon, 23 May 2005 10:20:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaDnE-0002IE-Ni for sip@megatron.ietf.org; Mon, 23 May 2005 10:20:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28516 for ; Mon, 23 May 2005 10:20:31 -0400 (EDT) Received: from inno-exchange.innovaphone.com ([145.253.157.4] helo=innovaphone.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaE5D-0005E7-8m for sip@ietf.org; Mon, 23 May 2005 10:39:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [Sip] Diversion interrogation Date: Mon, 23 May 2005 16:21:36 +0200 Message-ID: <0E6CC1D4D38A5742930CE896A653477AE1AAAD@inno-exchange.innovaphone.sifi> Thread-Topic: [Sip] Event Package for Registrations (RFC-3680) Thread-Index: AcVQqr4PcoX030jLRviCYLt/UW7AvwO9yQdA From: "Thomas Ackermann" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: quoted-printable X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi together, I would like to display active call diversions on the phone's display. To achieve that I must do what H323 calls 'interrogation'. Is there an idea how to implement that with SIP? Is there a dedicated RFC addressing that issue? Is anybody already doing this? Best regards, Thomas _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 23 10:52:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaEHj-0005se-0h; Mon, 23 May 2005 10:52:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaEHg-0005rf-Bx for sip@megatron.ietf.org; Mon, 23 May 2005 10:52:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02504 for ; Mon, 23 May 2005 10:51:58 -0400 (EDT) Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaEZd-0006Xi-R0 for sip@ietf.org; Mon, 23 May 2005 11:10:36 -0400 Received: from [192.168.0.102] (c-24-1-149-120.hsd1.tx.comcast.net [24.1.149.120]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id j4NEpUww059224 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 23 May 2005 09:51:31 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v622) Content-Transfer-Encoding: 7bit Message-Id: <9243ca70d038309e63bd0bff4cfe960b@nostrum.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: sip-implementors@cs.columbia.edu, "sip@ietf.org WG" From: Robert Sparks Date: Mon, 23 May 2005 09:52:00 -0500 X-Mailer: Apple Mail (2.622) Received-SPF: pass (nostrum.com: 24.1.149.120 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: Subject: [Sip] Registration for SIPIT 17 is open X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org SIPIT 17 will be in Stockholm, Sweden September 12-16. Hotsip is hosting this event. Registration opens today. See http://sipit17.hotsip.com and http://www.sipit.net for more information. 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 sip-bounces@ietf.org Mon May 23 12:39:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaFxR-0002EM-0I; Mon, 23 May 2005 12:39:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaFxO-0002EG-Vs for sip@megatron.ietf.org; Mon, 23 May 2005 12:39:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12101 for ; Mon, 23 May 2005 12:39:08 -0400 (EDT) Received: from mxout1.netvision.net.il ([194.90.9.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaGFM-0002px-G1 for sip@ietf.org; Mon, 23 May 2005 12:57:48 -0400 Received: from [127.0.0.1] ([212.143.127.195]) by mxout1.netvision.net.il (Sun Java System Messaging Server 6.1 HotFix 0.11 (built Jan 28 2005)) with ESMTPA id <0IGY00HCUBKUVK70@mxout1.netvision.net.il> for sip@ietf.org; Mon, 23 May 2005 19:38:56 +0300 (IDT) Date: Mon, 23 May 2005 18:39:36 +0200 From: Diego B To: sip ietf Message-id: <42920748.5000706@mailvision.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Content-Transfer-Encoding: 7BIT Cc: rohan@cisco.com Subject: [Sip] RFC 3842 Cantact header missing in some examples X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi; Checking the examples of RFC 3842 I found out that some of the SIP messages ( actually responses ) includes a Contact header and some not OK from page 10 doesn't include Contact OK from page 12 and 13 does contain contain Contact for example: Page 10 SUBSCRIBE sip:alice@vmail.example.com SIP/2.0 To: From: ;tag=78923 Date: Mon, 10 Jul 2000 03:55:06 GMT Call-Id: 1349882@alice-phone.example.com CSeq: 4 SUBSCRIBE Contact: Event: message-summary Expires: 86400 Accept: application/simple-message-summary Content-Length: 0 A2: Notifier -> Subscriber SIP/2.0 200 OK To: ;tag=4442 From: ;tag=78923 Date: Mon, 10 Jul 2000 03:55:07 GMT Call-Id: 1349882@alice-phone.example.com CSeq: 4 SUBSCRIBE Expires: 86400 Content-Length: 0 the OK doesn't includes a contact Header Also from Page 10 A3: Notifier -> Subscriber (immediate synchronization of current state: 2 new and 8 old [2 urgent] messages) NOTIFY sip:alice@alice-phone.example.com SIP/2.0 To: ;tag=78923 From: ;tag=4442 Date: Mon, 10 Jul 2000 03:55:07 GMT Call-Id: 1349882@alice-phone.example.com CSeq: 20 NOTIFY Contact: Event: message-summary Subscription-State: active Content-Type: application/simple-message-summary Content-Length: 99 Messages-Waiting: yes Message-Account: sip:alice@vmail.example.com Voice-Message: 2/8 (0/2) A4: Subscriber -> Notifier SIP/2.0 200 OK To: ;tag=78923 From: ;tag=4442 Date: Mon, 10 Jul 2000 03:55:08 GMT Call-Id: 1349882@alice-phone.example.com CSeq: 20 NOTIFY Content-Length: 0 The OK doesn't contain a Contact Header but examples from Page 12 and 13 do have a Contact header A9: Notifier -> Subscriber (immediate synchronization of current state) NOTIFY sip:alice@alice-phone.example.com SIP/2.0 To: ;tag=78923 From: ;tag=4442 Date: Mon, 10 Jul 2000 15:55:07 GMT Call-Id: 1349882@alice-phone.example.com CSeq: 47 NOTIFY Contact: Event: message-summary Subscription-State: active Content-Type: application/simple-message-summary Content-Length: 99 Messages-Waiting: yes Message-Account: sip:alice@vmail.example.com Voice-Message: 4/8 (1/2) A10: Subscriber -> Notifier SIP/2.0 200 OK To: ;tag=78923 From: ;tag=4442 Date: Mon, 10 Jul 2000 15:55:08 GMT Call-Id: 1349882@alice-phone.example.com CSeq: 47 NOTIFY Contact: <======= A11: Subscriber -> Notifier Un-subscribe after "alice" logs out. SUBSCRIBE sip:alice@vmail.example.com SIP/2.0 To: ;tag=4442 From: ;tag=78923 Date: Mon, 10 Jul 2000 19:35:06 GMT Call-Id: 1349882@alice-phone.example.com CSeq: 17 SUBSCRIBE Contact: Event: message-summary Expires: 0 Accept: application/simple-message-summary Content-Length: 0 A12: Notifier -> Subscriber SIP/2.0 200 OK To: ;tag=4442 From: ;tag=78923 Date: Mon, 10 Jul 2000 19:35:07 GMT Call-Id: 1349882@alice-phone.example.com CSeq: 17 SUBSCRIBE Contact: <===== Expires: 0 Content-Length: 0 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 23 13:42:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaGwk-0001Ju-Qo; Mon, 23 May 2005 13:42:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaGwi-0001Iz-UI for sip@megatron.ietf.org; Mon, 23 May 2005 13:42:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18105 for ; Mon, 23 May 2005 13:42:31 -0400 (EDT) Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaHEi-0005bL-SI for sip@ietf.org; Mon, 23 May 2005 14:01:10 -0400 Received: from keywest (hide.pingtel.com [65.220.123.2]) by mail.pingtel.com (Postfix) with SMTP id 0757E6C017 for ; Mon, 23 May 2005 13:42:28 -0400 (EDT) From: "Dale Worley" To: Subject: RE: [Sip] Diversion interrogation Date: Mon, 23 May 2005 13:41:27 -0400 Message-ID: <00ca01c55fbe$a645bba0$6a01010a@keywest> 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.2910.0) In-Reply-To: <0E6CC1D4D38A5742930CE896A653477AE1AAAD@inno-exchange.innovaphone.sifi> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > From: Thomas Ackermann > > I would like to display active call diversions on the phone's display. > To achieve that I must do what H323 calls 'interrogation'. > Is there an idea how to implement that with SIP? > Is there a dedicated RFC addressing that issue? > Is anybody already doing this? There are at least two ways that a call could be diverted to another target -- during call setup, the phone could return a 302 response, or later, the phone could send a REFER to the remote end. In the latter case, monitoring the diversion is simple, as the remote end will send refer event information telling the dialog identification of the call from the remote end to the new recipient. The phone could then do a dialog event SUBSCRIBE to the new recipient and follow the progress of the new dialog. In the first case, it looks messier to monitor the dialog. But the phone knows the addresses it provided in the 302, and can do dialog event SUBSCRIBEs to them. It already knows the Call-Id to watch for, since it is the same as in the INVITE that it responded 302 to. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 24 01:22:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaRsV-0003wY-Go; Tue, 24 May 2005 01:22:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaRsS-0003vD-V2 for sip@megatron.ietf.org; Tue, 24 May 2005 01:22:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04201 for ; Tue, 24 May 2005 01:22:51 -0400 (EDT) Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaSAY-00045o-B5 for sip@ietf.org; Tue, 24 May 2005 01:41:35 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id j4O5X6xA013066 for ; Mon, 23 May 2005 22:33:06 -0700 (MST) Received: from zin24exm01.ap.mot.com (zin24exm01.ap.mot.com [10.232.25.1]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id j4O5PcVK021194 for ; Tue, 24 May 2005 00:25:40 -0500 (CDT) Received: by zin24exm01.ap.mot.com with Internet Mail Service (5.5.2657.72) id ; Tue, 24 May 2005 10:52:35 +0530 Message-ID: <772BCEF88A1DD91191F80011856715F302235716@zin24exm01.ap.mot.com> From: Chauhan Bhavik-A20762 To: sip@ietf.org Date: Tue, 24 May 2005 10:52:35 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 2.1 (++) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Subject: [Sip] 100rel and early-session option tags (RFC 3959) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1059871762==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org 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. --===============1059871762== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C56020.97B044FE" 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_01C56020.97B044FE Content-Type: text/plain Hi, With Reference to RFC 3959 section 6, I think "early-session" option tag must be accompanied "100rel" if it is in "Require" header to indicate "Reliability of Provisional Response" support as I didn't find any relationship cited in RFCs. Does "early-session" implicitly indicate that? If not then, 1. A B ---INVITE(Require: early-session) ----> (INVITE is without 100rel option) As 100rel is not there what will be response from B? 2. A B ----INVITE(Supported: early-session) with OFFER ----> <---- 180 Reliable with early-offer & ANSWER---- (INVITE is without 100rel option ) What will be response from A as no 100rel supported? Regards, Bhavik Chauhan Motorola India Eletronics Pvt Ltd. ------_=_NextPart_001_01C56020.97B044FE Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KPFRJVExFPk1lc3NhZ2U8L1RJVExF Pg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yODAwLjE0OTEiIG5hbWU9R0VORVJBVE9S PjwvSEVBRD4NCjxCT0RZPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6 ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDA4 MDgwIHNpemU9Mj48U1BBTiANCmNsYXNzPTQ4MzA2MzAxNS0yMzA1MjAwNT5IaSw8L1NQQU4+PC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDgwODAgc2l6ZT0yPjxT UEFOIA0KY2xhc3M9NDgzMDYzMDE1LTIzMDUyMDA1PjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+ DQo8RElWPjxTUEFOIGNsYXNzPTQ4MzA2MzAxNS0yMzA1MjAwNT48Rk9OVCBmYWNlPUFyaWFsIGNv bG9yPSMwMDgwODAgc2l6ZT0yPjxGT05UIA0KY29sb3I9IzAwMDBmZj48U1BBTiBjbGFzcz03NzQy MjIxMDUtMjQwNTIwMDU+PEZPTlQgY29sb3I9IzAwODA4MD5XaXRoIA0KUmVmZXJlbmNlPC9GT05U PjwvU1BBTj48L0ZPTlQ+IHRvJm5ic3A7UkZDIDM5NTkgc2VjdGlvbiA2LDwvRk9OVD48L1NQQU4+ PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTQ4MzA2MzAxNS0yMzA1MjAwNT48Rk9OVCBmYWNlPUFy aWFsIGNvbG9yPSMwMDgwODAgDQpzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCjxE SVY+PFNQQU4gY2xhc3M9NDgzMDYzMDE1LTIzMDUyMDA1PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9 IzAwODA4MCBzaXplPTI+PFNQQU4gDQpjbGFzcz00ODMwNjMwMTUtMjMwNTIwMDU+PEZPTlQgZmFj ZT1BcmlhbCBjb2xvcj0jMDA4MDgwIHNpemU9Mj5JIHRoaW5rIA0KImVhcmx5LXNlc3Npb24iIG9w dGlvbiB0YWcmbmJzcDttdXN0IGJlIGFjY29tcGFuaWVkICIxMDByZWwiIGlmIGl0IGlzJm5ic3A7 aW4gDQoiUmVxdWlyZSIgaGVhZGVyPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+DQo8RElWPjxT UEFOIGNsYXNzPTQ4MzA2MzAxNS0yMzA1MjAwNT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDgw ODAgDQpzaXplPTI+dG8mbmJzcDtpbmRpY2F0ZSAiUmVsaWFiaWxpdHkgb2YgUHJvdmlzaW9uYWwg UmVzcG9uc2UiIA0Kc3VwcG9ydDwvRk9OVD48L1NQQU4+PFNQQU4gY2xhc3M9NDgzMDYzMDE1LTIz MDUyMDA1PjxGT05UIGZhY2U9QXJpYWwgDQpjb2xvcj0jMDA4MDgwIHNpemU9Mj4gYXMgSSBkaWRu J3QgZmluZCBhbnkgcmVsYXRpb25zaGlwIGNpdGVkIA0KPC9GT05UPjwvU1BBTj48L0RJVj4NCjxE SVY+PFNQQU4gY2xhc3M9NDgzMDYzMDE1LTIzMDUyMDA1PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9 IzAwODA4MCBzaXplPTI+aW4gDQpSRkNzLiA8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BB TiBjbGFzcz00ODMwNjMwMTUtMjMwNTIwMDU+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZm IA0Kc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTQ4 MzA2MzAxNS0yMzA1MjAwNT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDgwODAgDQpzaXplPTI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7IERvZXMgImVhcmx5LXNlc3Npb24iIGltcGxpY2l0bHkgaW5kaWNh dGUgDQp0aGF0PzwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTQ4MzA2MzAx NS0yMzA1MjAwNT48Rk9OVCANCmNvbG9yPSMwMDAwZmY+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJ Vj4NCjxESVY+PFNQQU4gY2xhc3M9NDgzMDYzMDE1LTIzMDUyMDA1PklmIG5vdCANCnRoZW4sPC9T UEFOPjwvRElWPjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTQ4MzA2MzAx NS0yMzA1MjAwNT48L1NQQU4+PFNQQU4gY2xhc3M9NDgzMDYzMDE1LTIzMDUyMDA1PjxGT05UIA0K ZmFjZT1BcmlhbCBjb2xvcj0jMDA4MDgwIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElW Pg0KPERJVj48U1BBTiBjbGFzcz00ODMwNjMwMTUtMjMwNTIwMDU+PEZPTlQgZmFjZT1BcmlhbCBj b2xvcj0jMDA4MDgwIA0Kc2l6ZT0yPjEuPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4g Y2xhc3M9NDgzMDYzMDE1LTIzMDUyMDA1PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwODA4MCAN CnNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpBJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KQjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxT UEFOIGNsYXNzPTQ4MzA2MzAxNS0yMzA1MjAwNT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDgw ODAgDQpzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7LS0t SU5WSVRFKFJlcXVpcmU6Jm5ic3A7ZWFybHktc2Vzc2lvbikmbmJzcDstLS0tJmd0OzwvRk9OVD48 L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTQ4MzA2MzAxNS0yMzA1MjAwNT48Rk9OVCBm YWNlPUFyaWFsIGNvbG9yPSMwMDgwODAgc2l6ZT0yPg0KPERJVj48U1BBTiBjbGFzcz00ODMwNjMw MTUtMjMwNTIwMDU+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDA4MDgwIHNpemU9Mj48U1BBTiAN CmNsYXNzPTQ4MzA2MzAxNS0yMzA1MjAwNT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDgwODAg c2l6ZT0yPjxTUEFOIA0KY2xhc3M9NDgzMDYzMDE1LTIzMDUyMDA1PjxGT05UIGZhY2U9QXJpYWwg Y29sb3I9IzAwMDBmZiANCnNpemU9Mj48L0ZPTlQ+PC9TUEFOPjwvRk9OVD48L1NQQU4+PC9GT05U PjwvU1BBTj4mbmJzcDs8L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9NDgzMDYzMDE1LTIzMDUyMDA1 PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwODA4MCBzaXplPTI+PFNQQU4gDQpjbGFzcz00ODMw NjMwMTUtMjMwNTIwMDU+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDA4MDgwIHNpemU9Mj48U1BB TiANCmNsYXNzPTQ4MzA2MzAxNS0yMzA1MjAwNT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDgw ODAgc2l6ZT0yPihJTlZJVEUgaXMgDQp3aXRob3V0IDEwMHJlbCANCm9wdGlvbik8L0ZPTlQ+PC9T UEFOPjwvRk9OVD48L1NQQU4+PC9GT05UPjwvU1BBTj48L0RJVj48L0ZPTlQ+PC9TUEFOPjwvRElW Pg0KPERJVj48U1BBTiBjbGFzcz00ODMwNjMwMTUtMjMwNTIwMDU+PEZPTlQgZmFjZT1BcmlhbCBj b2xvcj0jMDA4MDgwIHNpemU9Mj5BcyANCjEwMHJlbCBpcyBub3QgdGhlcmUgd2hhdCB3aWxsIGJl IHJlc3BvbnNlIGZyb20gQj88L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBjbGFzcz00 ODMwNjMwMTUtMjMwNTIwMDU+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDA4MDgwIA0Kc2l6ZT0y PjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTQ4MzA2MzAxNS0y MzA1MjAwNT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDgwODAgc2l6ZT0yPg0KPERJVj48U1BB TiBjbGFzcz00ODMwNjMwMTUtMjMwNTIwMDU+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDA4MDgw IA0Kc2l6ZT0yPjIuJm5ic3A7Jm5ic3A7Jm5ic3A7PC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+ PFNQQU4gY2xhc3M9NDgzMDYzMDE1LTIzMDUyMDA1PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAw ODA4MCANCnNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQombmJzcDtBJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IA0KQjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTQ4 MzA2MzAxNS0yMzA1MjAwNT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDgwODAgDQpzaXplPTI+ Jm5ic3A7Jm5ic3A7IC0tLS1JTlZJVEUoU3VwcG9ydGVkOiZuYnNwO2Vhcmx5LXNlc3Npb24pIHdp dGggDQpPRkZFUiZuYnNwOy0tLS0mZ3Q7PC9GT05UPjwvU1BBTj48L0RJVj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmx0Oy0tLS0gMTgwIA0KUmVsaWFibGUgd2l0aCBlYXJseS1vZmZlciAmYW1w OyZuYnNwO0FOU1dFUi0tLS08L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBjbGFzcz00 ODMwNjMwMTUtMjMwNTIwMDU+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDA4MDgwIHNpemU9Mj48 U1BBTiANCmNsYXNzPTQ4MzA2MzAxNS0yMzA1MjAwNT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMw MDgwODAgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9NDgzMDYzMDE1LTIzMDUyMDA1Pg0KPERJVj48U1BB TiBjbGFzcz00ODMwNjMwMTUtMjMwNTIwMDU+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDA4MDgw IHNpemU9Mj48U1BBTiANCmNsYXNzPTQ4MzA2MzAxNS0yMzA1MjAwNT48Rk9OVCBmYWNlPUFyaWFs IGNvbG9yPSMwMDgwODAgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9NDgzMDYzMDE1LTIzMDUyMDA1PjxG T05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCnNpemU9Mj48L0ZPTlQ+PC9TUEFOPjwvRk9O VD48L1NQQU4+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9NDgz MDYzMDE1LTIzMDUyMDA1PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwODA4MCBzaXplPTI+PFNQ QU4gDQpjbGFzcz00ODMwNjMwMTUtMjMwNTIwMDU+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDA4 MDgwIHNpemU9Mj48U1BBTiANCmNsYXNzPTQ4MzA2MzAxNS0yMzA1MjAwNT48Rk9OVCBmYWNlPUFy aWFsIGNvbG9yPSMwMDgwODAgc2l6ZT0yPihJTlZJVEUgaXMgDQp3aXRob3V0IDEwMHJlbCBvcHRp b24gDQopPC9GT05UPjwvU1BBTj48L0ZPTlQ+PC9TUEFOPjwvRk9OVD48L1NQQU4+PC9ESVY+PC9T UEFOPjwvRk9OVD48L1NQQU4+PC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9 NDgzMDYzMDE1LTIzMDUyMDA1PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwODA4MCBzaXplPTI+ V2hhdCANCndpbGwgYmUgcmVzcG9uc2UgZnJvbSBBIGFzIG5vIDEwMHJlbCBzdXBwb3J0ZWQ/PC9G T05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9NDgzMDYzMDE1LTIzMDUyMDA1PjxG T05UIGZhY2U9QXJpYWwgY29sb3I9IzAwODA4MCANCnNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNw OzwvRElWPg0KPERJVj48U1BBTiBjbGFzcz00ODMwNjMwMTUtMjMwNTIwMDU+PEZPTlQgZmFjZT1B cmlhbCBjb2xvcj0jMDA4MDgwIA0Kc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8 RElWIGFsaWduPWxlZnQ+DQo8RElWIGFsaWduPWxlZnQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0j MDA0MDgwIA0Kc2l6ZT0yPjxTVFJPTkc+UmVnYXJkcyw8L1NUUk9ORz48L0ZPTlQ+PC9ESVY+DQo8 RElWIGFsaWduPWxlZnQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDA0MDgwIHNpemU9Mj48U1RS T05HPkJoYXZpayANCkNoYXVoYW48L1NUUk9ORz48L0ZPTlQ+PC9ESVY+DQo8RElWIGFsaWduPWxl ZnQ+PFNUUk9ORz48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDQwODAgDQpzaXplPTI+PC9GT05U PjwvU1RST05HPiZuYnNwOzwvRElWPg0KPERJViBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTQ4MzA2 MzAxNS0yMzA1MjAwNT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDQwODAgDQpzaXplPTI+PFNU Uk9ORz5Nb3Rvcm9sYSBJbmRpYSBFbGV0cm9uaWNzIFB2dCANCkx0ZC48L1NUUk9ORz48L0ZPTlQ+ PC9TUEFOPjwvRElWPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDgwODAg c2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj48L0JPRFk+PC9IVE1MPg0K ------_=_NextPart_001_01C56020.97B044FE-- --===============1059871762== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1059871762==-- From sip-bounces@ietf.org Tue May 24 02:55:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaTJs-0007pC-7f; Tue, 24 May 2005 02:55:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaTJq-0007og-RD for sip@megatron.ietf.org; Tue, 24 May 2005 02:55:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01043 for ; Tue, 24 May 2005 02:55:13 -0400 (EDT) Received: from inno-exchange.innovaphone.com ([145.253.157.4] helo=innovaphone.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaTbx-0006a8-WA for sip@ietf.org; Tue, 24 May 2005 03:13:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Sip] Diversion interrogation Date: Tue, 24 May 2005 08:56:18 +0200 Message-ID: <0E6CC1D4D38A5742930CE896A653477AB6ADCE@inno-exchange.innovaphone.sifi> Thread-Topic: [Sip] Event Package for Registrations (RFC-3680) Thread-Index: AcVQqr4PcoX030jLRviCYLt/UW7AvwO9yQdAACIp2qA= From: "Thomas Ackermann" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Ok, but I am looking for a centralized way to handle diversions. If I want to divert all incoming calls to my homeoffice phone while my office phone is offline, I have to activate a unconditional diversion at my local PBX|proxy|server, because my office phone cannot send a 302 response or a REFER in case of an incoming call. Once a diversion is active at my local PBX|proxy|server, the office = phone goes online again I would like to see something on the office phone's = display telling me: "Unconditional diversion active". So I would deactivate that diversion. Otherwise I'd miss all calls to my office phone. So there should be some kind of subscription that notifies me of current diversions on my contact|aor and any changes made on that diversion status (adds or dels). Is there such an event package already defined, or do I have to devise = my own? Best regards, Thomas _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 24 03:04:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaTSW-0000cv-Di; Tue, 24 May 2005 03:04:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaTST-0000aU-93; Tue, 24 May 2005 03:04:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01536; Tue, 24 May 2005 03:04:07 -0400 (EDT) From: Wayne.Davies@mmv.vic.gov.au Received: from doi-fire.doi.vic.gov.au ([203.34.63.1] helo=ndoigwy01.doi.vic.gov.au) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaTkV-0006sK-Lm; Tue, 24 May 2005 03:22:53 -0400 In-Reply-To: <00ca01c55fbe$a645bba0$6a01010a@keywest> Subject: RE: [Sip] Diversion interrogation To: "Dale Worley" X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: Date: Tue, 24 May 2005 17:03:29 +1000 X-MIMETrack: Serialize by Router on nDOIGWY01/Server/DOI(Release 6.5.1|January 21, 2004) at 24/05/2005 05:04:02 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.3 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: sip@ietf.org, sip-bounces@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dale, Thomas, I agree with all that Dale said below but had a somewhat different take on the question, Thomas - if you can advise if the response below cover what you were after, If not can you clarify the query more. I took the phrase below "active call diversions" and the H.323 reference to be more about the profile for call forwarding supplemental services (H.450.3) than of an end points *actual* diversions for a call that is in progress. I will try to illustrate what I see as the difference. In H.450.3 allows an endpoint to activate call forwarding supplemental services CFB, CFNR, CFU, it also allows interrogation of an endpoint to determine current settings - i.e. state of a diversion service, and if applicable what number is it to be deflected to. I don't think the above ability for interrogating these profile kind of settings in SIP, because they are implemented in logic outside the protocol. You can make these kind of settings on intelligent SIP phones say via a local menu system, or provision a central hosting registrar/proxy (B2BUA...)via web or other means but I don't know of a way to 'interrogate' for these service profile settings via SIP ?. Off the top of my head could it be done using caller-prefs or similar ?. Sorry if I am way off the mark, also please advise if this thread should be moved to Implementors or other. Regards, Wayne. > From: Thomas Ackermann > > I would like to display active call diversions on the phone's display. > To achieve that I must do what H323 calls 'interrogation'. > Is there an idea how to implement that with SIP? > Is there a dedicated RFC addressing that issue? > Is anybody already doing this? There are at least two ways that a call could be diverted to another target -- during call setup, the phone could return a 302 response, or later, the phone could send a REFER to the remote end. In the latter case, monitoring the diversion is simple, as the remote end will send refer event information telling the dialog identification of the call from the remote end to the new recipient. The phone could then do a dialog event SUBSCRIBE to the new recipient and follow the progress of the new dialog. In the first case, it looks messier to monitor the dialog. But the phone knows the addresses it provided in the 302, and can do dialog event SUBSCRIBEs to them. It already knows the Call-Id to watch for, since it is the same as in the INVITE that it responded 302 to. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ********************************************************************** Any personal or sensitive information contained in this email and attachments must be handled in accordance with the Victorian Information Privacy Act 2000, the Health Records Act 2001 or the Privacy Act 1988 (Commonwealth), as applicable. This email, including all attachments, is confidential. If you are not the intended recipient, you must not disclose, distribute, copy or use the information contained in this email or attachments. Any confidentiality or privilege is not waived or lost because this email has been sent to you in error. If you have received it in error, please let us know by reply email, delete it from your system and destroy any copies. ********************************************************************** _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 24 08:14:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaYIz-0002QR-Gd; Tue, 24 May 2005 08:14:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaYIw-0002QG-Mm; Tue, 24 May 2005 08:14:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22730; Tue, 24 May 2005 08:14:35 -0400 (EDT) From: dave.robbins@verizon.com Received: from irvmail2.verizon.com ([192.76.80.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaYb3-0000im-9b; Tue, 24 May 2005 08:33:23 -0400 Received: from smtptpa.verizon.com (smtptpa.verizon.com [138.83.66.45]) by irvmail2.verizon.com (8.13.3/8.13.3) with ESMTP id j4OCENev009116; Tue, 24 May 2005 07:14:23 -0500 (EST) Received: from usflttpstcmms03.ent.verizon.com (TPAMMS03B.interwan.gte.com [138.83.67.211]) by smtptpa.verizon.com (8.13.3/8.13.3) with ESMTP id j4OCELGJ029411; Tue, 24 May 2005 08:14:21 -0400 (EDT) Received: from 138.83.34.22 by usflttpstcmms03.ent.verizon.com with ESMTP (SMTP Relay); Tue, 24 May 2005 08:14:15 -0400 X-Server-Uuid: 19D292D1-71A4-486E-A2B1-BD56777388A4 Received: from dwsmtp01.core.verizon.com (dwmail21.interwan.gte.com [138.83.36.17]) by coregate1.verizon.com (8.13.3/8.13.3) with ESMTP id j4OCEEkN000224; Tue, 24 May 2005 07:14:14 -0500 (CDT) Subject: Re: AW: [Sip] Diversion interrogation To: "Thomas Ackermann" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Tue, 24 May 2005 08:14:09 -0400 X-MIMETrack: Serialize by Router on DWSMTP01/HSVR/Verizon(Release 6.0.2CF2|July 23, 2003) at 05/24/2005 07:14:13 MIME-Version: 1.0 X-WSS-ID: 6E8DC51D10W379434-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, sip-bounces@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org The idea here seems to be that you have an agent somewhere (e.g., a PBX or a proxy) that is managing call forwarding (diversion) on behalf of an AOR, and you would like one or more of your SIP phones to be able to know the current status of diversions. An event package would seem to be one of the best ways to fit this into the SIP framework. A phone that wants to know the status would subscribe to that event package at the AOR, and would be notified whenever the diversion state changes. When the phone first comes online and subscribes to the event package, it gets an immediate notification of the state. Such a call forwarding/diversion event package has not, AFAIK, been defined or even proposed to date. It is probably debatable whether such an event package would be of sufficient general interest and applicability to be the subject of an IETF standard; if it is, SIPPING is probably the place to propose it. I can say that such a package would be of interest in at least some contexts. Dave Robbins Verizon Laboratories, Waltham, MA "Thomas Ackermann" To: sip@ietf.org Subject: AW: [Sip] Diversion interrogation Sent by: sip-bounces@ietf. org 05/24/2005 02:56 AM Ok, but I am looking for a centralized way to handle diversions. If I want to divert all incoming calls to my homeoffice phone while my office phone is offline, I have to activate a unconditional diversion at my local PBX|proxy|server, because my office phone cannot send a 302 response or a REFER in case of an incoming call. Once a diversion is active at my local PBX|proxy|server, the office phone goes online again I would like to see something on the office phone's display telling me: "Unconditional diversion active". So I would deactivate that diversion. Otherwise I'd miss all calls to my office phone. So there should be some kind of subscription that notifies me of current diversions on my contact|aor and any changes made on that diversion status (adds or dels). Is there such an event package already defined, or do I have to devise my own? Best regards, Thomas _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 sip-bounces@ietf.org Tue May 24 09:33:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaZXO-0007Cc-QO; Tue, 24 May 2005 09:33:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaZXL-0007CO-Lz; Tue, 24 May 2005 09:33:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29927; Tue, 24 May 2005 09:33:33 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaZpX-0003SU-55; Tue, 24 May 2005 09:52:23 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 24 May 2005 06:33:25 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j4ODWp3q004573; Tue, 24 May 2005 06:33:23 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 May 2005 06:33:22 -0700 Received: from cisco.com ([161.44.79.130]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 May 2005 06:33:21 -0700 Message-ID: <42932D20.5050004@cisco.com> Date: Tue, 24 May 2005 09:33:20 -0400 From: Paul Kyzivat 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: dave.robbins@verizon.com Subject: Re: AW: [Sip] Diversion interrogation References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 May 2005 13:33:21.0701 (UTC) FILETIME=[27495D50:01C56065] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, sip-bounces@ietf.org, Thomas Ackermann X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Thomas, I'm inclined to agree with Dave, and with Wayne on another post in this thread. The problem is that you want to monitor the policy settings of the proxy responsible for your AOR. There are currently no standards for what kinds of policy, if any, might reside there, so there is no clear way to monitor the setting of that policy. (The closest thing that I am aware of is RFC 3880 for CPL. But it would be difficult to interrogate a CPL script to determine if it is set to do call diversion.) You can of course achieve this through proprietary means. But if you think a standard is needed in this space, then I think the first step would be to start gathering requirements for standard policy to be applied to routing of requests addressed to an AOR. SIPPING is probably the right place to start. But I'm not at all confident that there would be widespread interest in this. A proxy responsible for an AoR can have arbitrary logic to decide how to direct an incoming call addressed to that AoR. I don't think people want to restrict that. Characterizing arbitrary behavior as being "diversion" or "not diversion" is an impossible job. A perhaps more likely possibility would be to find a way for a device, such as your office phone, to obtain a description of the policy in effect. It could perhaps then learn to simply identify one or a few policies that it considers "normal" and others that are not. Paul dave.robbins@verizon.com wrote: > > > > The idea here seems to be that you have an agent somewhere (e.g., a PBX or > a proxy) that is managing call forwarding (diversion) on behalf of an AOR, > and you would like one or more of your SIP phones to be able to know the > current status of diversions. An event package would seem to be one of the > best ways to fit this into the SIP framework. A phone that wants to know > the status would subscribe to that event package at the AOR, and would be > notified whenever the diversion state changes. When the phone first comes > online and subscribes to the event package, it gets an immediate > notification of the state. > > Such a call forwarding/diversion event package has not, AFAIK, been defined > or even proposed to date. It is probably debatable whether such an event > package would be of sufficient general interest and applicability to be the > subject of an IETF standard; if it is, SIPPING is probably the place to > propose it. I can say that such a package would be of interest in at least > some contexts. > > Dave Robbins > Verizon Laboratories, Waltham, MA > > > > > "Thomas > Ackermann" To: sip@ietf.org > aphone.com> Subject: AW: [Sip] Diversion interrogation > Sent by: > sip-bounces@ietf. > org > > > 05/24/2005 02:56 > AM > > > > > > > Ok, > > but I am looking for a centralized way to handle diversions. > If I want to divert all incoming calls to my homeoffice phone > while my office phone is offline, I have to activate a unconditional > diversion at my local PBX|proxy|server, because my office phone > cannot send a 302 response or a REFER in case of an incoming call. > > Once a diversion is active at my local PBX|proxy|server, the office phone > goes online again I would like to see something on the office phone's > display > telling me: "Unconditional diversion active". So I would deactivate that > diversion. Otherwise I'd miss all calls to my office phone. > > So there should be some kind of subscription that notifies me of > current diversions on my contact|aor and any changes made on that > diversion status (adds or dels). > > Is there such an event package already defined, or do I have to devise my > own? > > Best regards, > Thomas > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 sip-bounces@ietf.org Tue May 24 11:34:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DabQf-0003x5-1I; Tue, 24 May 2005 11:34:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DabQb-0003wx-SX for sip@megatron.ietf.org; Tue, 24 May 2005 11:34:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11397 for ; Tue, 24 May 2005 11:34:43 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dabio-00081L-S8 for sip@ietf.org; Tue, 24 May 2005 11:53:35 -0400 Received: from [64.101.146.106] ([64.101.146.106]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j4OFbogu007834 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 24 May 2005 10:37:52 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <19b5da77b03ab3bea11a1ab2f12fc305@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: AW: [Sip] Diversion interrogation Date: Tue, 24 May 2005 10:34:41 -0500 To: Thomas Ackermann , dave.robbins@verizon.com X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On May 24, 2005, at 7:14 AM, dave.robbins@verizon.com (following up on Thomas' question) wrote: > The idea here seems to be that you have an agent somewhere (e.g., a > PBX or > a proxy) that is managing call forwarding (diversion) on behalf of an > AOR, > and you would like one or more of your SIP phones to be able to know > the > current status of diversions. An event package would seem to be one of > the > best ways to fit this into the SIP framework. A phone that wants to > know > the status would subscribe to that event package at the AOR, and would > be > notified whenever the diversion state changes. When the phone first > comes > online and subscribes to the event package, it gets an immediate > notification of the state. > > In the general case, this is actually an intractable problem. Imagine a case where a call originates from PSTN and comes through an SS7 gateway to SIP. The gateway generates an INVITE, which goes to a proxy. The proxy sends a 302 REDIRECT with tel: URI as the Contact. The gateway uses something like the ISUP release-link-trunk extension to drop the call back to the preceding switch, which then IAMs the new phone number. How would the proxy, which was involved only in the stateless issuance of a 302, know the future state of the new call that is proceeding entirely in the PSTN? So to completely satisfy the requirement for knowing the state of ongoing diversions, we probably need to base this sort of service from a back-to-back user agent instead of a proxy. This greatly reduces the flexibility and efficiency, as we're essentially going to "trombone" calls. That being said, the dialog event package lets a watcher know what dialogs the B2BUA is engaged in, and I think a simple set-difference operation gives us the "current diversions" set (the set of dialogs the B2BUA is involved in MINUS the set of dialogs that the watching UA is involved in). So -- good news. I don't think you need any SIP extensions to build a service that works this way. But most SIP systems aren't going to have the information you need. -- 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 sip-bounces@ietf.org Tue May 24 12:27:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DacFa-0006hv-K3; Tue, 24 May 2005 12:27:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DacFZ-0006hp-5u for sip@megatron.ietf.org; Tue, 24 May 2005 12:27:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16161 for ; Tue, 24 May 2005 12:27:22 -0400 (EDT) From: dave.robbins@verizon.com Received: from irvmail2.verizon.com ([192.76.80.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DacXm-00020p-AB for sip@ietf.org; Tue, 24 May 2005 12:46:14 -0400 Received: from smtpirv2.verizon.com (smtpirv2.verizon.com [138.83.34.66]) by irvmail2.verizon.com (8.13.3/8.13.3) with ESMTP id j4OGR9Co013724; Tue, 24 May 2005 11:27:09 -0500 (EST) Received: from usinftwiccmms03.ent.verizon.com (ftwmms03a.interwan.gte.com [138.83.138.66]) by smtpirv2.verizon.com (8.13.3/8.13.3) with ESMTP id j4OGR8Hs009450; Tue, 24 May 2005 11:27:08 -0500 (CDT) Received: from 138.83.34.22 by usinftwiccmms03.ent.verizon.com with ESMTP (SMTP Relay); Tue, 24 May 2005 12:26:54 -0400 X-Server-Uuid: 2F91DA65-DB13-41BC-8809-D657BCBC59D7 Received: from dwsmtp01.core.verizon.com (dwmail21.interwan.gte.com [138.83.36.17]) by coregate1.verizon.com (8.13.3/8.13.3) with ESMTP id j4OGQrIL029953; Tue, 24 May 2005 11:26:53 -0500 (CDT) Subject: Re: AW: [Sip] Diversion interrogation To: "Dean Willis" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Tue, 24 May 2005 12:26:13 -0400 X-MIMETrack: Serialize by Router on DWSMTP01/HSVR/Verizon(Release 6.0.2CF2|July 23, 2003) at 05/24/2005 11:26:52 MIME-Version: 1.0 X-WSS-ID: 6E8D8A4732K480812-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Thomas Ackermann X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Your are absolutely correct in describing the problem of knowing the state of calls that have been diverted as intractable. However, this may not be the problem the initiator of this thread was trying to solve, and it is not a problem I would seriously think of solving. What may be a tractable problem is for a device to know the current state of some service (diversion in this case) provided by, say, a proxy. The state of the service can be well-defined, but the current state of any dialogs that may have been affected by that service is not generally knowable. Communicating the state of a service is in general a problem that no single standard can solve. Even limiting consideration to a diversion service, diversion can be arbitrarily complex when considering the criteria by which the service would decide whether and to what destination to redirect an INVITE. What would be the appropriate state for the service to communicate to an agent that subscribes to the state? RFC 3265 provides a framework within which an event package can be defined for a particular, relatively constrained notion of a diversion service. I suspect that to define a sufficiently constrained event package would result in something that is too constrained to be considered worthy of attention at the SIP or SIPPING WG level. "Dean Willis" , Dave C. armor.com> Robbins/EMPL/MA/Verizon@VZNotes cc: sip@ietf.org 05/24/2005 11:34 Subject: Re: AW: [Sip] Diversion interrogation AM On May 24, 2005, at 7:14 AM, dave.robbins@verizon.com (following up on Thomas' question) wrote: > The idea here seems to be that you have an agent somewhere (e.g., a > PBX or > a proxy) that is managing call forwarding (diversion) on behalf of an > AOR, > and you would like one or more of your SIP phones to be able to know > the > current status of diversions. An event package would seem to be one of > the > best ways to fit this into the SIP framework. A phone that wants to > know > the status would subscribe to that event package at the AOR, and would > be > notified whenever the diversion state changes. When the phone first > comes > online and subscribes to the event package, it gets an immediate > notification of the state. > > In the general case, this is actually an intractable problem. Imagine a case where a call originates from PSTN and comes through an SS7 gateway to SIP. The gateway generates an INVITE, which goes to a proxy. The proxy sends a 302 REDIRECT with tel: URI as the Contact. The gateway uses something like the ISUP release-link-trunk extension to drop the call back to the preceding switch, which then IAMs the new phone number. How would the proxy, which was involved only in the stateless issuance of a 302, know the future state of the new call that is proceeding entirely in the PSTN? So to completely satisfy the requirement for knowing the state of ongoing diversions, we probably need to base this sort of service from a back-to-back user agent instead of a proxy. This greatly reduces the flexibility and efficiency, as we're essentially going to "trombone" calls. That being said, the dialog event package lets a watcher know what dialogs the B2BUA is engaged in, and I think a simple set-difference operation gives us the "current diversions" set (the set of dialogs the B2BUA is involved in MINUS the set of dialogs that the watching UA is involved in). So -- good news. I don't think you need any SIP extensions to build a service that works this way. But most SIP systems aren't going to have the information you need. -- 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 sip-bounces@ietf.org Tue May 24 15:01:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Daef9-0007jk-1Z; Tue, 24 May 2005 15:01:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dadt2-0000Y3-V7 for sip@megatron.ietf.org; Tue, 24 May 2005 14:12:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27428 for ; Tue, 24 May 2005 14:12:15 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaeBH-0006zQ-43 for sip@ietf.org; Tue, 24 May 2005 14:31:07 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 24 May 2005 14:12:06 -0400 Received: from [161.44.55.253] (dhcp-161-44-55-253.cisco.com [161.44.55.253]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4OIC34u014543; Tue, 24 May 2005 14:12:04 -0400 (EDT) Message-ID: <42936E73.3000905@cisco.com> Date: Tue, 24 May 2005 14:12:03 -0400 From: Anders Kristensen Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dave.robbins@verizon.com Subject: Re: AW: [Sip] Diversion interrogation References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 24 May 2005 15:01:56 -0400 Cc: sip@ietf.org, Thomas Ackermann , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org You could have the service configuration be accessible to clients through XCAP. Clients would retrieve the configuration on startup and can subscribe to the sip-profile event package to get notifications about changes to the service configuration. Anders dave.robbins@verizon.com wrote: > > > > Your are absolutely correct in describing the problem of knowing the state > of calls that have been diverted as intractable. > > However, this may not be the problem the initiator of this thread was > trying to solve, and it is not a problem I would seriously think of > solving. What may be a tractable problem is for a device to know the > current state of some service (diversion in this case) provided by, say, a > proxy. The state of the service can be well-defined, but the current state > of any dialogs that may have been affected by that service is not generally > knowable. > > Communicating the state of a service is in general a problem that no single > standard can solve. Even limiting consideration to a diversion service, > diversion can be arbitrarily complex when considering the criteria by which > the service would decide whether and to what destination to redirect an > INVITE. What would be the appropriate state for the service to communicate > to an agent that subscribes to the state? RFC 3265 provides a framework > within which an event package can be defined for a particular, relatively > constrained notion of a diversion service. I suspect that to define a > sufficiently constrained event package would result in something that is > too constrained to be considered worthy of attention at the SIP or SIPPING > WG level. > > > > > "Dean Willis" > , Dave C. > armor.com> Robbins/EMPL/MA/Verizon@VZNotes > cc: sip@ietf.org > 05/24/2005 11:34 Subject: Re: AW: [Sip] Diversion interrogation > AM > > > > > > > > On May 24, 2005, at 7:14 AM, dave.robbins@verizon.com (following up on > Thomas' question) wrote: > > >>The idea here seems to be that you have an agent somewhere (e.g., a >>PBX or >>a proxy) that is managing call forwarding (diversion) on behalf of an >>AOR, >>and you would like one or more of your SIP phones to be able to know >>the >>current status of diversions. An event package would seem to be one of >>the >>best ways to fit this into the SIP framework. A phone that wants to >>know >>the status would subscribe to that event package at the AOR, and would >>be >>notified whenever the diversion state changes. When the phone first >>comes >>online and subscribes to the event package, it gets an immediate >>notification of the state. >> >> > > In the general case, this is actually an intractable problem. > > Imagine a case where a call originates from PSTN and comes through an > SS7 gateway to SIP. The gateway generates an INVITE, which goes to a > proxy. The proxy sends a 302 REDIRECT with tel: URI as the Contact. The > gateway uses something like the ISUP release-link-trunk extension to > drop the call back to the preceding switch, which then IAMs the new > phone number. > > How would the proxy, which was involved only in the stateless issuance > of a 302, know the future state of the new call that is proceeding > entirely in the PSTN? > > So to completely satisfy the requirement for knowing the state of > ongoing diversions, we probably need to base this sort of service from > a back-to-back user agent instead of a proxy. This greatly reduces the > flexibility and efficiency, as we're essentially going to "trombone" > calls. > > That being said, the dialog event package lets a watcher know what > dialogs the B2BUA is engaged in, and I think a simple set-difference > operation gives us the "current diversions" set (the set of dialogs the > B2BUA is involved in MINUS the set of dialogs that the watching UA is > involved in). > > So -- good news. I don't think you need any SIP extensions to build a > service that works this way. But most SIP systems aren't going to have > the information you need. > > -- > 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 sip-bounces@ietf.org Tue May 24 15:35:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DafBJ-0004pz-6I; Tue, 24 May 2005 15:35:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DafBG-0004pu-Km for sip@megatron.ietf.org; Tue, 24 May 2005 15:35:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05347 for ; Tue, 24 May 2005 15:35:08 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DafTU-0001Zd-Cp for sip@ietf.org; Tue, 24 May 2005 15:54:02 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 24 May 2005 12:35:00 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4OJYFmS004906; Tue, 24 May 2005 12:34:57 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 May 2005 12:34:55 -0700 Received: from cisco.com ([161.44.79.130]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 May 2005 12:34:55 -0700 Message-ID: <429381DE.5040200@cisco.com> Date: Tue, 24 May 2005 15:34:54 -0400 From: Paul Kyzivat 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: Anders Kristensen Subject: Re: AW: [Sip] Diversion interrogation References: <42936E73.3000905@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 May 2005 19:34:55.0248 (UTC) FILETIME=[A9A5F100:01C56097] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Dean Willis , Thomas Ackermann , dave.robbins@verizon.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Anders Kristensen wrote: > You could have the service configuration be accessible to clients > through XCAP. Clients would retrieve the configuration on startup and > can subscribe to the sip-profile event package to get notifications > about changes to the service configuration. Yes, you could - if there was general agreement that there *is* such a thing as a service configuration for an AoR that is available via XCAP in some well known way. The feature that started this thread could be abstracted to: the phone wants to indicate something like "this phone isn't ever going to ring because of the way the service configuration is set." Even if the phone could get the service agreement, its not obvious how it could draw this conclusion. If you are willing to constrain the features to some well known set, then it becomes easier to do this. But I certainly hope we don't go that way. Paul > Anders > > > dave.robbins@verizon.com wrote: > >> >> >> >> Your are absolutely correct in describing the problem of knowing the >> state >> of calls that have been diverted as intractable. >> >> However, this may not be the problem the initiator of this thread was >> trying to solve, and it is not a problem I would seriously think of >> solving. What may be a tractable problem is for a device to know the >> current state of some service (diversion in this case) provided by, >> say, a >> proxy. The state of the service can be well-defined, but the current >> state >> of any dialogs that may have been affected by that service is not >> generally >> knowable. >> >> Communicating the state of a service is in general a problem that no >> single >> standard can solve. Even limiting consideration to a diversion service, >> diversion can be arbitrarily complex when considering the criteria by >> which >> the service would decide whether and to what destination to redirect an >> INVITE. What would be the appropriate state for the service to >> communicate >> to an agent that subscribes to the state? RFC 3265 provides a framework >> within which an event package can be defined for a particular, relatively >> constrained notion of a diversion service. I suspect that to define a >> sufficiently constrained event package would result in something that is >> too constrained to be considered worthy of attention at the SIP or >> SIPPING >> WG level. >> >> >> >> >> "Dean >> Willis" >> > Ackermann" , Dave C. >> armor.com> >> Robbins/EMPL/MA/Verizon@VZNotes >> cc: >> sip@ietf.org >> 05/24/2005 11:34 Subject: Re: AW: [Sip] >> Diversion interrogation >> >> AM >> >> >> >> >> >> >> >> On May 24, 2005, at 7:14 AM, dave.robbins@verizon.com (following up on >> Thomas' question) wrote: >> >> >>> The idea here seems to be that you have an agent somewhere (e.g., a >>> PBX or >>> a proxy) that is managing call forwarding (diversion) on behalf of an >>> AOR, >>> and you would like one or more of your SIP phones to be able to know >>> the >>> current status of diversions. An event package would seem to be one of >>> the >>> best ways to fit this into the SIP framework. A phone that wants to >>> know >>> the status would subscribe to that event package at the AOR, and would >>> be >>> notified whenever the diversion state changes. When the phone first >>> comes >>> online and subscribes to the event package, it gets an immediate >>> notification of the state. >>> >>> >> >> In the general case, this is actually an intractable problem. >> >> Imagine a case where a call originates from PSTN and comes through an >> SS7 gateway to SIP. The gateway generates an INVITE, which goes to a >> proxy. The proxy sends a 302 REDIRECT with tel: URI as the Contact. The >> gateway uses something like the ISUP release-link-trunk extension to >> drop the call back to the preceding switch, which then IAMs the new >> phone number. >> >> How would the proxy, which was involved only in the stateless issuance >> of a 302, know the future state of the new call that is proceeding >> entirely in the PSTN? >> >> So to completely satisfy the requirement for knowing the state of >> ongoing diversions, we probably need to base this sort of service from >> a back-to-back user agent instead of a proxy. This greatly reduces the >> flexibility and efficiency, as we're essentially going to "trombone" >> calls. >> >> That being said, the dialog event package lets a watcher know what >> dialogs the B2BUA is engaged in, and I think a simple set-difference >> operation gives us the "current diversions" set (the set of dialogs the >> B2BUA is involved in MINUS the set of dialogs that the watching UA is >> involved in). >> >> So -- good news. I don't think you need any SIP extensions to build a >> service that works this way. But most SIP systems aren't going to have >> the information you need. >> >> -- >> Dean >> >> >> >> >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 25 12:33:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dayoi-0001I0-2M; Wed, 25 May 2005 12:33:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dayof-0001Hv-BA for sip@megatron.ietf.org; Wed, 25 May 2005 12:33:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25750 for ; Wed, 25 May 2005 12:33:06 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Daz74-00024u-Hu for sip@ietf.org; Wed, 25 May 2005 12:52:11 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 25 May 2005 09:32:59 -0700 Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4PGWtlq008367; Wed, 25 May 2005 09:32:55 -0700 (PDT) Received: from [192.168.1.100] (che-vpn-cluster-2-89.cisco.com [10.86.242.89]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AJV68292; Wed, 25 May 2005 09:32:52 -0700 (PDT) Message-ID: <4294A8B4.8000500@cisco.com> Date: Wed, 25 May 2005 12:32:52 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: AW: [Sip] Diversion interrogation References: <42936E73.3000905@cisco.com> <429381DE.5040200@cisco.com> In-Reply-To: <429381DE.5040200@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, dave.robbins@verizon.com, Anders Kristensen , Thomas Ackermann , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org inline. Paul Kyzivat wrote: > > > Anders Kristensen wrote: > >> You could have the service configuration be accessible to clients >> through XCAP. Clients would retrieve the configuration on startup and >> can subscribe to the sip-profile event package to get notifications >> about changes to the service configuration. > > > Yes, you could - if there was general agreement that there *is* such a > thing as a service configuration for an AoR that is available via XCAP > in some well known way. Sure there is. Its called the sipping configuration framework. One of the things it allows you to do is to subscribe to the applications for a particular AOR. Each application would have its own xcap application usage that defines the data for that application. > > The feature that started this thread could be abstracted to: the phone > wants to indicate something like "this phone isn't ever going to ring > because of the way the service configuration is set." Even if the phone > could get the service agreement, its not obvious how it could draw this > conclusion. Drawing the conclusion is going to be very hard without standardizing the set of services that can cause forwarding to take place. Screening applications could also cause the phone to never ring. I agree with others that it is not a good thing to fix the set of services. However, there is a means for the phone to learn the applications enabled for a particular AOR, and for those applications understood by the phone, and for those that have xcap data associated with them, it could figure out what is going to happen. I don't think we can or should do better than that. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.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 sip-bounces@ietf.org Thu May 26 02:24:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbBnC-0002dB-Vo; Thu, 26 May 2005 02:24:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbBnA-0002d3-PY for sip@megatron.ietf.org; Thu, 26 May 2005 02:24:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01602 for ; Thu, 26 May 2005 02:24:27 -0400 (EDT) Received: from inno-exchange.innovaphone.com ([145.253.157.4] helo=innovaphone.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbC5i-0008Mn-1M for sip@ietf.org; Thu, 26 May 2005 02:43:38 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: AW: AW: [Sip] Diversion interrogation MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 May 2005 08:25:35 +0200 Message-ID: <0E6CC1D4D38A5742930CE896A653477AB6ADD6@inno-exchange.innovaphone.sifi> Thread-Topic: AW: [Sip] Diversion interrogation Thread-Index: AcVhR6kzz/iKHfIxSV6fdvA4SJiqhwAcgRpw From: "Thomas Ackermann" To: "Jonathan Rosenberg" , "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, dave.robbins@verizon.com, Anders Kristensen , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Thanks for your input, the reason why I've asked for that is with my H.323 background I simply = thought there must be an equivalent in SIP for the H.450.3 "Call diversion = supplementary service". In H.450.3 there just 3 different types of diversions: unconditional, = busy, no-reply. With the means of H.450.3 you're able to query current state of every = single div type. In the interrogation response the server tells you where you are = diverted to (name and number). Actually that's all I want to implement with SIP. Not more. Thomas Ackermann -----Urspr=FCngliche Nachricht----- Von: Jonathan Rosenberg [mailto:jdrosen@cisco.com] Gesendet: Mittwoch, 25. Mai 2005 18:33 An: Paul Kyzivat Cc: Anders Kristensen; sip@ietf.org; Dean Willis; Thomas Ackermann; dave.robbins@verizon.com Betreff: Re: AW: [Sip] Diversion interrogation inline. Paul Kyzivat wrote: >=20 >=20 > Anders Kristensen wrote: >=20 >> You could have the service configuration be accessible to clients=20 >> through XCAP. Clients would retrieve the configuration on startup and = >> can subscribe to the sip-profile event package to get notifications=20 >> about changes to the service configuration. >=20 >=20 > Yes, you could - if there was general agreement that there *is* such a = > thing as a service configuration for an AoR that is available via XCAP = > in some well known way. Sure there is. Its called the sipping configuration framework. One of=20 the things it allows you to do is to subscribe to the applications for=20 a particular AOR. Each application would have its own xcap=20 application usage that defines the data for that application. >=20 > The feature that started this thread could be abstracted to: the phone = > wants to indicate something like "this phone isn't ever going to ring=20 > because of the way the service configuration is set." Even if the = phone=20 > could get the service agreement, its not obvious how it could draw = this=20 > conclusion. Drawing the conclusion is going to be very hard without standardizing=20 the set of services that can cause forwarding to take place. Screening=20 applications could also cause the phone to never ring. I agree with=20 others that it is not a good thing to fix the set of services. However, there is a means for the phone to learn the applications=20 enabled for a particular AOR, and for those applications understood by=20 the phone, and for those that have xcap data associated with them, it=20 could figure out what is going to happen. I don't think we can or should = do better than that. -Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.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 sip-bounces@ietf.org Thu May 26 11:19:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbK8n-0005pb-TZ; Thu, 26 May 2005 11:19:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbK8h-0005nm-UB for sip@megatron.ietf.org; Thu, 26 May 2005 11:19:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05912 for ; Thu, 26 May 2005 11:19:13 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.206]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbKRJ-0003N7-40 for sip@ietf.org; Thu, 26 May 2005 11:38:30 -0400 Received: by wproxy.gmail.com with SMTP id 71so838207wri for ; Thu, 26 May 2005 08:19:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XixkSOXx/JIJlJ6GpkHrWd9AztP5gTJjSPIJvxWNvYiGK00u8xKRNqFfTTsh3oFnBTSxKZbMI9tnVY4dvAVIAwV9Y5IG1fsp7UeOaQBdxgRfIpSr+nG6i21g9ZoPLIjnZQ3vO9hn8U/T1imogJgNOWVv0B5qx8C4DaocMC6lcgI= Received: by 10.54.36.72 with SMTP id j72mr1008204wrj; Thu, 26 May 2005 08:19:05 -0700 (PDT) Received: by 10.54.66.16 with HTTP; Thu, 26 May 2005 08:19:05 -0700 (PDT) Message-ID: Date: Thu, 26 May 2005 12:19:05 -0300 From: Mariano Stokle To: Thomas Ackermann Subject: Re: AW: [Sip] Diversion interrogation In-Reply-To: <0E6CC1D4D38A5742930CE896A653477AB6ADD6@inno-exchange.innovaphone.sifi> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <0E6CC1D4D38A5742930CE896A653477AB6ADD6@inno-exchange.innovaphone.sifi> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: quoted-printable Cc: Dean Willis , sip@ietf.org, Paul Kyzivat , dave.robbins@verizon.com, Anders Kristensen X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mariano Stokle List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org well, in my sip client I have a diversion rule established that says:"if the call comes from my wife cellphone, ring my wired office phone and my sip client by 5 times, if I did not answer then ring my cell phone". I have other several rules established for other numbers and presence conditions (Busy Anywhere or Out to Lunch). I cannot imagine an easy way to represent those diversion conditions by any rather than accesing the web page where I establish the rules... On 5/26/05, Thomas Ackermann wrote: > Thanks for your input, > the reason why I've asked for that is with my H.323 background I simply t= hought > there must be an equivalent in SIP for the H.450.3 "Call diversion supple= mentary service". > In H.450.3 there just 3 different types of diversions: unconditional, bus= y, no-reply. > With the means of H.450.3 you're able to query current state of every sin= gle div type. > In the interrogation response the server tells you where you are diverted= to (name and number). > Actually that's all I want to implement with SIP. Not more. >=20 > Thomas Ackermann >=20 > -----Urspr=FCngliche Nachricht----- > Von: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Gesendet: Mittwoch, 25. Mai 2005 18:33 > An: Paul Kyzivat > Cc: Anders Kristensen; sip@ietf.org; Dean Willis; Thomas Ackermann; > dave.robbins@verizon.com > Betreff: Re: AW: [Sip] Diversion interrogation >=20 >=20 > inline. >=20 > Paul Kyzivat wrote: >=20 > > > > > > Anders Kristensen wrote: > > > >> You could have the service configuration be accessible to clients > >> through XCAP. Clients would retrieve the configuration on startup and > >> can subscribe to the sip-profile event package to get notifications > >> about changes to the service configuration. > > > > > > Yes, you could - if there was general agreement that there *is* such a > > thing as a service configuration for an AoR that is available via XCAP > > in some well known way. >=20 > Sure there is. Its called the sipping configuration framework. One of > the things it allows you to do is to subscribe to the applications for > a particular AOR. Each application would have its own xcap > application usage that defines the data for that application. >=20 >=20 > > > > The feature that started this thread could be abstracted to: the phone > > wants to indicate something like "this phone isn't ever going to ring > > because of the way the service configuration is set." Even if the phone > > could get the service agreement, its not obvious how it could draw this > > conclusion. >=20 > Drawing the conclusion is going to be very hard without standardizing > the set of services that can cause forwarding to take place. Screening > applications could also cause the phone to never ring. I agree with > others that it is not a good thing to fix the set of services. >=20 > However, there is a means for the phone to learn the applications > enabled for a particular AOR, and for those applications understood by > the phone, and for those that have xcap data associated with them, it > could figure out what is going to happen. I don't think we can or should > do better than that. >=20 > -Jonathan R. >=20 >=20 > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.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 Mariano Stokle One Protocol to rule them all, One Protocol to find them, One Protocol to bring them all And in the darkness bind them _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 26 14:07:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbMlM-0002K8-Kk; Thu, 26 May 2005 14:07:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbMlJ-0002JT-HK for sip@megatron.ietf.org; Thu, 26 May 2005 14:07:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17883 for ; Thu, 26 May 2005 14:07:16 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbN3x-0007ct-2N for sip@ietf.org; Thu, 26 May 2005 14:26:33 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 26 May 2005 11:07:08 -0700 X-IronPort-AV: i="3.93,140,1115017200"; d="scan'208"; a="270072100:sNHT32812332" Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4QI6vlq001040; Thu, 26 May 2005 11:06:57 -0700 (PDT) Received: from [161.44.55.58] (dhcp-161-44-55-58.cisco.com [161.44.55.58]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AJV87692; Thu, 26 May 2005 11:06:57 -0700 (PDT) Message-ID: <42961040.2030300@cisco.com> Date: Thu, 26 May 2005 14:06:56 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mariano Stokle Subject: Re: AW: [Sip] Diversion interrogation References: <0E6CC1D4D38A5742930CE896A653477AB6ADD6@inno-exchange.innovaphone.sifi> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA17883 Cc: Dean Willis , sip@ietf.org, Paul Kyzivat , dave.robbins@verizon.com, Anders Kristensen , Thomas Ackermann X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Exactly - thats the point. In a world where the set of call features and services is fixed,=20 immutable, and written into stone, then it is possible for a client to=20 know whether its call will be diverted. In a world where we allow new services that the clients don't know about=20 (the SIP model), then there is no way to know. THe best we can do is=20 that the client can know the configuration of the services it does know=20 about, and for which configuration information is exposed through the=20 sipping configuration framework. -Jonathan R. Mariano Stokle wrote: > well, in my sip client I have a diversion rule established that > says:"if the call comes from my wife cellphone, ring my wired office > phone and my sip client by 5 times, if I did not answer then ring my > cell phone". I have other several rules established for other numbers > and presence conditions (Busy Anywhere or Out to Lunch). I cannot > imagine an easy way to represent those diversion conditions by any > rather than accesing the web page where I establish the rules... >=20 > On 5/26/05, Thomas Ackermann wrote: >=20 >>Thanks for your input, >>the reason why I've asked for that is with my H.323 background I simply= thought >>there must be an equivalent in SIP for the H.450.3 "Call diversion supp= lementary service". >>In H.450.3 there just 3 different types of diversions: unconditional, b= usy, no-reply. >>With the means of H.450.3 you're able to query current state of every s= ingle div type. >>In the interrogation response the server tells you where you are divert= ed to (name and number). >>Actually that's all I want to implement with SIP. Not more. >> >>Thomas Ackermann >> >>-----Urspr=FCngliche Nachricht----- >>Von: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >>Gesendet: Mittwoch, 25. Mai 2005 18:33 >>An: Paul Kyzivat >>Cc: Anders Kristensen; sip@ietf.org; Dean Willis; Thomas Ackermann; >>dave.robbins@verizon.com >>Betreff: Re: AW: [Sip] Diversion interrogation >> >> >>inline. >> >>Paul Kyzivat wrote: >> >> >>> >>>Anders Kristensen wrote: >>> >>> >>>>You could have the service configuration be accessible to clients >>>>through XCAP. Clients would retrieve the configuration on startup and >>>>can subscribe to the sip-profile event package to get notifications >>>>about changes to the service configuration. >>> >>> >>>Yes, you could - if there was general agreement that there *is* such a >>>thing as a service configuration for an AoR that is available via XCAP >>>in some well known way. >> >>Sure there is. Its called the sipping configuration framework. One of >>the things it allows you to do is to subscribe to the applications for >> a particular AOR. Each application would have its own xcap >>application usage that defines the data for that application. >> >> >> >>>The feature that started this thread could be abstracted to: the phone >>>wants to indicate something like "this phone isn't ever going to ring >>>because of the way the service configuration is set." Even if the phon= e >>>could get the service agreement, its not obvious how it could draw thi= s >>>conclusion. >> >>Drawing the conclusion is going to be very hard without standardizing >>the set of services that can cause forwarding to take place. Screening >>applications could also cause the phone to never ring. I agree with >>others that it is not a good thing to fix the set of services. >> >>However, there is a means for the phone to learn the applications >>enabled for a particular AOR, and for those applications understood by >>the phone, and for those that have xcap data associated with them, it >>could figure out what is going to happen. I don't think we can or shoul= d >>do better than that. >> >>-Jonathan R. >> >> >>-- >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>Director, Service Provider VoIP Architecture Parsippany, NJ 07054-271= 1 >>Cisco Systems >>jdrosen@cisco.com FAX: (973) 952-5050 >>http://www.jdrosen.net PHONE: (973) 952-5000 >>http://www.cisco.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 >=20 >=20 --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.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 sip-bounces@ietf.org Thu May 26 18:28:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbQqT-0003kq-TI; Thu, 26 May 2005 18:28:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbQqS-0003kf-8I for sip@megatron.ietf.org; Thu, 26 May 2005 18:28:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19419 for ; Thu, 26 May 2005 18:28:49 -0400 (EDT) Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbR95-0000Ok-9c for sip@ietf.org; Thu, 26 May 2005 18:48:10 -0400 Received: from unknown (HELO alpha.jnpr.net) (172.24.18.126) by kremlin.juniper.net with ESMTP; 26 May 2005 15:28:40 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,141,1115017200"; d="scan'208,217"; a="338033470:sNHT31627396" Received: from hadron.jnpr.net ([172.24.15.25]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 May 2005 15:28:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 26 May 2005 15:28:38 -0700 Message-ID: Thread-Topic: About Invite Server transaction Thread-Index: AcViQkN0kajhSeeGTCmlWQRDcegWPg== From: "Anil Bollineni" To: , X-OriginalArrivalTime: 26 May 2005 22:28:39.0384 (UTC) FILETIME=[43BE5D80:01C56242] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: Subject: [Sip] About Invite Server transaction X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0678600581==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0678600581== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C56242.4363DE14" This is a multi-part message in MIME format. ------_=_NextPart_001_01C56242.4363DE14 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi,=20 Assume 100, 200 responses are sent from UAS to client, and they are lost. Then INVITE is retransmitted to UAS. As soon as UAS send 200 OK it destroys the server transaction. Per UAS, the dialog state is already created after sending 200 response. If INVITE is passed to TU from transport layer, then how this INVITE is been treated as retransmission of INVITE, since the TU, will not able to match any existing dialog (since no to-tag in INVITE), and will it treat as a new call. Is the assumption correct? Or where in RFC this scenario will be treated. =20 Thanks, Anil ------_=_NextPart_001_01C56242.4363DE14 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

         =    Assume 100, 200 responses are sent from UAS to client, and they are lost. Then = INVITE is retransmitted to UAS. As soon as UAS send 200 OK it destroys the = server transaction. Per UAS, the dialog state is already created after sending = 200 response. If INVITE is passed to TU from transport layer, then how this INVITE is = been treated as retransmission of INVITE, since the TU, will  not able to match = any existing dialog (since no to-tag in INVITE), and will it treat as a new = call. Is the assumption correct? Or where in RFC this scenario will be = treated.

 

Thanks,

Anil

=00 ------_=_NextPart_001_01C56242.4363DE14-- --===============0678600581== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0678600581==-- From sip-bounces@ietf.org Fri May 27 02:23:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbYFI-0002H2-Vh; Fri, 27 May 2005 02:23:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbYFH-0002Gx-62 for sip@megatron.ietf.org; Fri, 27 May 2005 02:22:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11916 for ; Fri, 27 May 2005 02:22:58 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbYY0-00023z-6m for sip@ietf.org; Fri, 27 May 2005 02:42:21 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 26 May 2005 23:22:49 -0700 Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4R6Mgbw019986; Thu, 26 May 2005 23:22:42 -0700 (PDT) Received: from [192.168.1.100] (che-vpn-cluster-2-297.cisco.com [10.86.243.42]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AJV97307; Thu, 26 May 2005 23:22:43 -0700 (PDT) Message-ID: <4296BCB0.3020602@cisco.com> Date: Fri, 27 May 2005 02:22:40 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: R: [SIP] Multiple instances of same UA: How to distinguish them? References: <20050519124409.01006332767@mail.abbeynet.it> <428C98AF.9060308@cisco.com> In-Reply-To: <428C98AF.9060308@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id CAA11916 Cc: sip@ietf.org, Giacomo Vacca X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org To add to this, if a proxy does decide to somehow do this correlation,=20 the GRUU mechanism is the best way to do that. The contact URI populated=20 in the INVITE will contain the GRUU, and since the SIP provider had=20 created this gruu as a result of a registration from a particular UA=20 instance, it can correlate them together. -Jonathan R. Paul Kyzivat wrote: > The significant point here is that sip does not require a sender to=20 > first register. A sender is a sender and should be judged by any server= =20 > along the path by what information is contained in the request. >=20 > If the sender and the proxy want to make a side agreement that the prox= y=20 > will correlate an outgoing message with a registration, and provide som= e=20 > services based on that correlation, then they can do so. But sip isn't=20 > going to tell them how to do it. >=20 > Paul >=20 > Giacomo Vacca wrote: >=20 >> Thank you for your reply: I agree with you. >> But let's consider a case where the Contact stored after the=20 >> registration differs from that carried by the INVITE. Perhaps this is=20 >> not a "ideal" case, but I'm confident it can happen. >> I think that the only way to distinguish them is to store IP address=20 >> and port from which the requests arrived. What do you think about? >> =20 >> Thanks >> Giacomo >> >> =20 >> ----------------------------------------------------------------------= -- >> *Da:* innovation.interops@wipro.com >> [mailto:innovation.interops@wipro.com] >> *Inviato:* gioved=EC 19 maggio 2005 13.31 >> *A:* giacomo.vacca@abbeynet.it >> *Oggetto:* RE: [SIP] Multiple instances of same UA: How to >> distinguish them? >> >> Normally proxy would not require to know who is calling except for >> authentication purpose.All it does is to check if it can locate th= e >> person mentioned in the Request URI in the Location Information. >> But if u need a way to really distinguish at proxy which=20 >> instance is >> sending the INVITE.Contact header In INVITE can be compared with t= he >> contact header value already existing in the Location Information. >> =20 >> =20 >> ----------------------------------------------------------------------= -- >> *From:* sip-bounces@ietf.org on behalf of Giacomo Vacca >> *Sent:* Thu 5/19/2005 2:07 PM >> *To:* sip@ietf.org >> *Subject:* [SIP] Multiple instances of same UA: How to distinguish= =20 >> them? >> >> Hi All, >> Take this scenario: I have a SIP Phone in my office, and I use my >> account: UserID: giacomo, Password: ****, registering to >> "myregistrar.domain". >> Now, in order to use the same service I want to use the same accou= nt >> at home. So I register mysoftphone with same UserID, password and = in >> the same registrar "myregistrar.domain" from home. >> Suppose that the registrar allows this multiple registration=20 >> for the >> same UserID, adding the home contact to the previous office contac= t. >> The question is: "Is there a way for the Proxy/Registrar >> (myregistrar.domain) to distinguish which entity (office or home) = is >> trying to invite someone, if the registrar receives an INVITE from >> the office SIP Phone or from the home softphone?" >> Thank you in advance! >> Giacomo >> =20 >> >> Confidentiality Notice >> >> The information contained in this electronic message and any >> attachments to this message are intended >> for the exclusive use of the addressee(s) and may contain >> confidential or privileged information. If >> you are not the intended recipient, please notify the sender at >> Wipro or Mailadmin@wipro.com immediately >> and destroy all copies of this message and any attachments. >> >> >> ----------------------------------------------------------------------= -- >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.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 sip-bounces@ietf.org Fri May 27 14:46:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbjqS-0001eQ-8K; Fri, 27 May 2005 14:46:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbjqO-0001d2-Ki; Fri, 27 May 2005 14:46:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12197; Fri, 27 May 2005 14:46:03 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbk9F-0004A5-GF; Fri, 27 May 2005 15:05:33 -0400 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1DbjqN-0002Se-TY; Fri, 27 May 2005 14:46:03 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Fri, 27 May 2005 14:46:03 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: sip@ietf.org Subject: [Sip] Last Call: 'Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)' to Proposed Standard X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org The IESG has received a request from the Session Initiation Protocol WG to consider the following document: - 'Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP) ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-06-10. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-identity-05.txt _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 27 16:58:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbluv-0005T0-US; Fri, 27 May 2005 16:58:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dblur-0005Sv-Br for sip@megatron.ietf.org; Fri, 27 May 2005 16:58:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03626 for ; Fri, 27 May 2005 16:58:46 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbmDh-0002PC-Ml for sip@ietf.org; Fri, 27 May 2005 17:18:18 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id j4RKwN2c001327; Fri, 27 May 2005 16:58:23 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA13466; Fri, 27 May 2005 16:58:23 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Fri, 27 May 2005 16:58:22 -0400 Message-ID: <313680C9A886D511A06000204840E1CF09A83D94@whq-msgusr-02.pit.comms.marconi.com> From: "Punj, Arun" To: "'Anil Bollineni'" , sip-implementors@cs.columbia.edu, sip@ietf.org Date: Fri, 27 May 2005 16:58:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Subject: [Sip] RE: [Sip-implementors] About Invite Server transaction X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Anil, The presence of same call-id, cseq, branch-id in vias should be enough to indicate that it is a retransmitted INVITE rather than a forked INVITE or a new INVITE. On receiving an INVITE on UAS typically the "software" looks up the CALLID to check if there is a call(dialog) with that CALLID. if there is a dialog with that callid, then you look at the from-tag (different from tag should instantly be flagged as an error), branchid, cseq number etc to verify that it is not a forked invite or a re-invite(if to-tag present). Given that it does not meet the above three conditions : it is not a INVITE on an INVALID call, it is not a forked INVITE, it is not a re-INVITE, it is treated as a retransmitted INVITE) On the otherhand, on a stateless proxy such a retransmitted INVITE needs to be forwarded towards the UAS since it does not have the context to interpret the message. thanks Arun Punj ViPr Principal Engineer Broadband Routing & Switching Marconi 3000 Marconi Drive Warrendale, PA 15086 Phone: 724-742-7583 Arun.Punj@marconi.com > -----Original Message----- > From: sip-implementors-bounces@cs.columbia.edu > [mailto:sip-implementors-bounces@cs.columbia.edu]On Behalf Of Anil > Bollineni > Sent: Thursday, May 26, 2005 6:29 PM > To: sip-implementors@cs.columbia.edu; sip@ietf.org > Subject: [Sip-implementors] About Invite Server transaction > > > Hi, > > Assume 100, 200 responses are sent from UAS to client, and > they are lost. Then INVITE is retransmitted to UAS. As soon > as UAS send > 200 OK it destroys the server transaction. Per UAS, the > dialog state is > already created after sending 200 response. If INVITE is passed to TU > from transport layer, then how this INVITE is been treated as > retransmission of INVITE, since the TU, will not able to match any > existing dialog (since no to-tag in INVITE), and will it > treat as a new > call. Is the assumption correct? Or where in RFC this scenario will be > treated. > > > > Thanks, > > Anil > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 27 18:22:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbnEG-0004RI-5B; Fri, 27 May 2005 18:22:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbnEA-0004Qr-Sy for sip@megatron.ietf.org; Fri, 27 May 2005 18:22:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10299 for ; Fri, 27 May 2005 18:22:48 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbnX2-0004AW-Dr for sip@ietf.org; Fri, 27 May 2005 18:42:21 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 27 May 2005 15:22:39 -0700 X-IronPort-AV: i="3.93,146,1115017200"; d="scan'208"; a="639253191:sNHT30498412" Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4RMMVlq012880; Fri, 27 May 2005 15:22:37 -0700 (PDT) Received: from jmpolk-wxp.diablo.cisco.com (sjc-vpn6-442.cisco.com [10.21.121.186]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA03039; Fri, 27 May 2005 15:22:31 -0700 (PDT) Message-Id: <4.3.2.7.2.20050527171758.02055530@diablo.cisco.com> X-Sender: jmpolk@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 27 May 2005 17:22:30 -0500 To: Avasarala Ranjit-A20990 , Chauhan Bhavik-A20762 , sip@ietf.org, sip-implementors@cs.columbia.edu From: "James M. Polk" Subject: RE: [Sip] UPDATE with ANSWER? In-Reply-To: <19B94C8C331A7546A88C88502083353BB2284E@zin24exm02.ap.mot.c om> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At 03:21 PM 5/19/2005 +0530, Avasarala Ranjit-A20990 wrote: >Hi > No UPDATE cannot be used to send answer, since UPDATE can be used > only after a dialog is established. The only valid Request message that can include an SDP answer is in the ACK message [RFC3261], and only if the original INVITE did not contain an Offer (meaning the offer was in the 200 OK message). and to the second point made above: generally, a reINVITE is used after a dialog is established for the same Call-ID. An UPDATE is used before a final response has been received to alter the parameters contained in the INVITE. > Regards >Ranjit > > >-----Original Message----- >From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of >Chauhan Bhavik-A20762 >Sent: Thursday, May 19, 2005 3:10 PM >To: sip@ietf.org; sip-implementors@cs.columbia.edu >Subject: [Sip] UPDATE with ANSWER? > >Hi all, > >I was exploring the possibility for the UPDATE to send the Answer, >As I haven't found any explicit restriction in RFC 3311. > >I went through the older Thread >http://lists.cs.columbia.edu/pipermail/sip-implementors/2004-January/006017.html >and came across following Qs which I found not clarified though. > >1. Can UPDATE be used to send an answer SDP ? > Consider the following scenario: > - INVITE was sent without SDP > - 18x is received with Offer SDP > - There is no PRACK exchange because 18x does not contain a >Require:100rel header > Now can UPDATE be used to send answer SDP?? > >2. As per RFC 3311, UPDATE method should be used only if dialog is >established. > If INVITE/18x exchange happened without PRACK, can both ends treat >this as early dialog and feel free to use UPDATE ? > >3. Is 18x send/recv over TCP considered reliable ? > In the following scenario: > - INVITE with offer sdp sent > - 18x over TCP with answer sdp recvd (No PRACK exchange happened) > Now can the caller/calleee use UPDATE ? >Can any body clarify the same? > >Thanks in advance, >Bhavik Chauhan > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip cheers, James ******************* Truth is not to be argued... it is to be presented. Alas, few *truths* exist without the math. ...all else is a matter of perspective _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun May 29 17:14:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcV74-0001yP-A6; Sun, 29 May 2005 17:14:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcV72-0001yK-Ac for sip@megatron.ietf.org; Sun, 29 May 2005 17:14:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24802 for ; Sun, 29 May 2005 17:14:20 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcVQH-0007Yz-JT for sip@ietf.org; Sun, 29 May 2005 17:34:18 -0400 Received: from [192.168.0.31] (pool-138-89-100-232.mad.east.verizon.net [138.89.100.232]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j4TLEHhq004242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 29 May 2005 17:14:18 -0400 (EDT) Message-ID: <429A30B3.6080100@cs.columbia.edu> Date: Sun, 29 May 2005 17:14:27 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "GOLDMAN, STUART O (STUART)" Subject: Re: [Sip] comments on draft-ietf-sip-resource-priority-08 and draft-ietf-s ipping-reason-header-for-preemption-02 References: <17D8724A2A8D9542B2B8AE546B9E5BBC045FB737@az4315exch001u.phx.lucent.com> In-Reply-To: <17D8724A2A8D9542B2B8AE546B9E5BBC045FB737@az4315exch001u.phx.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.2 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I'm working through the GOLDMAN, STUART O (STUART) wrote: > ---------------------------------------------------------------------------- > The following comments are submitted on draft-ietf-sip-resource-priority-08: > > Section 4.2 Rule 1 says "... If there are sufficient > resources, treat the request like a regular SIP request and skip > the remaining steps. (This does not cause removal of the header > fields.)" Is authorization to be repeated at each node even within > a given network or is it sufficient that the first node in the > network perform it? If the first node is following rule 1, how would > the subsequent node know if authorization had been performed or if > the prior node had sufficient resources and skipped that step? This would presumably depend on each deployment and I don't think the document is the right place to architect SIP authentication/authorization requirements. The document mentions (in the Security Considerations) section RFC 3325 as an example, which would imply one-time authentication at the "edge" of the trusted network. > > Section 4.3 says "Following standard SIP behavior, if a SIP request > contains the 'Require' header field with the 'resource-priority' > option tag, a SIP element MUST respond with a 420 (Bad Extension) if > it does not support the SIP extensions described in this document. > It then lists "resource-priority" in the 'Unsupported' header field > included in the response." If a SIP request contains the 'Require' > header field with multiple proxies along the path and one of the > proxies is not supported, is the 'resource-priority' header still > applied to the remaining proxies? I'm afraid I don't quite understand this question. In SIP, 'Require' only applies to UAs, not proxies. Proxies would use 'Proxy-Require', as noted (and not recommended). I'll swap 'SIP element' with 'SIP UA', for additional clarity. > > In section 4.5.2, the process is defined for an RP actor to handle > the priority request. Depending on implementations, some real-time > services may be in weighted queues rather than priority queues and > these CoS also may require multi-level priority handling. Shouldn't > a similar process be applicable to weighted queuing also? Shouldn't > priority signaling and processing be independent of how the routers > handle the session packets in their queuing and scheduling mechanism?" I don't understand your reference to weighted queues. As noted early in the document, RPH does not address IP-level routing and switching (or queueing) at all, but maybe you're referring to something else? Queues only refer to the waiting requests, not anything related to packets. > > Section 4.7.1 paragraph 2 says "Upon receiving a 417 (Unknown > Resource-Priority) response, the UAC MAY attempt a subsequent > request with the same or different resource value. If available, it > SHOULD choose authorized resource values from the set of values > returned in the 'Accept-Resource-Priority'." It would be useful to > understand the criteria used by the UAC to request a different > resource value from the set returned. It is not clear if an > interoperability problem might exist in the absence of such criteria. Since all such values returned to the UAC are, by definition, valid, I'm not sure what interoperability issue you would anticipate or what guidance you would suggest. Presumably, the UAC would pick values that it is authorized for and that "make sense", from an operational perspective. > > Section 4.7.3 para 3: Why does it say "SHOULD"? Intermediate > elements cannot process the RPH unless the RPH is in the "outer" > header. Is it correct that the RPH "MUST" be in the "outer" header > if RPH is used? No. If you only want a UAS to inspect the RPH, putting it in the "inner" layer is just fine. I rephrased as " MUST also be placed in the "outer" message if the UAC would like proxy servers to be able to act on the header information." I hope this makes this more explicit. > > Section 4.7.3 para 5: Perhaps this paragraph could be reworded to > more clearly state its purpose. Is it correct that once an element > sets or receives a RPH with a given r-value, it MUST NOT send a RPH > with a different r-value for the same call?- it shouldn't matter how > the proxy is implemented. If it is illegal for the UA to change the > value, is the proxy then free to drop the message if it detects the > change? Must it check for a change? To avoid misunderstandings, paragraph 5 is "If a stateful proxy has authorized a particular resource ..." Thus, it only refers to those proxies and responses. It does not say anything about changing the r-value mid-call. I don't see the need to explicitly disallow changes in r-values. Clearly, an element that did something beyond just passing it on has to do "due diligence" (authenticate, etc.) to make this secure. Currently, the document treats initial and subsequent requests within a call the same; making changes here may have ripple effects elsewhere. Clearly, your deployment may choose to disallow changes in priority values. I don't think interoperability is affected by whether you make this choice and I don't think we can exhaustively specify all such policy choices. For all I know, you might disallow certain priority values based on the length of the conversation... > > Section 12.1 Says that "New priority-values MUST NOT be added to > existing namespace registries. The registration MUST describe, in > the registration itself, how SIP elements should treat requests from > that namespace in 'operation', e.g., whether preemption or only > preferential queuing are allowed. " This seems to prohibit the > later addition of a new priority value to a namespace. If this is > because of potential Interoperability problems, would it be possible > to explain them? Is this wise given the possibility of the need for In earlier versions of the draft, we tried to solve this problem, and it became a mess, as it added more failure cases. Adding values after the fact would then lead to possible rejections of calls somewhere else, if not all elements have been upgraded, i.e., unreliable operation. Unless there is a strong reason to allow this, this just seems to add complexity. > an addition should unforeseen event occur, and that the addition may > need to occur rapidly? Is it wise to explicitly specify operations > in the IANA registration as these may not be complete and may be > modified/expanded in the future? Is there evidence that such additions have "suddenly" occurred in the past? Here, compared to more traditional networks, we have the advantage that if you want to upgrade your network to something new, you can define a namespace, with then well-defined behavior. If there's a real need to solve the problem, we need to find a solution, but given past experience with this draft, I'm somewhat reluctant to add complexity unless there's a clearly established need. To cite another possible interop problem: Say, you build your network to rely on proxies for authentication. The UAS adds a new priority level, but some proxy hasn't been upgraded yet. It will pass through the unrecognized level and bad things happen. Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun May 29 17:23:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcVG8-0003CN-FF; Sun, 29 May 2005 17:23:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcVG6-0003CC-B2; Sun, 29 May 2005 17:23:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25557; Sun, 29 May 2005 17:23:44 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcVZM-0007mS-W3; Sun, 29 May 2005 17:43:42 -0400 Received: from [192.168.0.31] (pool-138-89-100-232.mad.east.verizon.net [138.89.100.232]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j4TLNhi3014914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 29 May 2005 17:23:43 -0400 (EDT) Message-ID: <429A32E8.1060702@cs.columbia.edu> Date: Sun, 29 May 2005 17:23:52 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com Subject: Re: [Sip] Comments on Resource Priority -08 (nits) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.2 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, iesg@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org My apologies for the delay in responding to these comments. I'll respond in several messages, just to avoid mile-long tripled-nested follow-up messages. I'll also add () notes to the subject header to make tracking any discussion easier. Mpierce1@aol.com wrote: > The following comments are submitted on draft-ietf-sip-resource-priority-08: > > 1 NITS > > Section 1, 7th paragraph (beginning "This document defines...") needs to > be rewritten to refer to the two headers which this document defines. Changed. > > Section 4.6.5 wording of 2nd sentence is incomplete. I don't know what > was intended, so I can not suggest new wording. Fixed to Insufficient resource conditions can occur on proxy servers and user agent servers, typically trunk gateways, if an RP actor receives an authorized request, has insufficient resources and the request neither preempts another session nor is queued. > > Section 10.4 reference to "multi-layer priority preemption" needs to be > changed to "Multi-Level Precedence and Preemption". > Changed. Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun May 29 17:32:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcVOr-0004V2-JO; Sun, 29 May 2005 17:32:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcVOp-0004Uu-KP; Sun, 29 May 2005 17:32:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26184; Sun, 29 May 2005 17:32:45 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcVi7-000808-95; Sun, 29 May 2005 17:52:43 -0400 Received: from [192.168.0.31] (pool-138-89-100-232.mad.east.verizon.net [138.89.100.232]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j4TLWjLF005535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 29 May 2005 17:32:46 -0400 (EDT) Message-ID: <429A34FC.6000102@cs.columbia.edu> Date: Sun, 29 May 2005 17:32:44 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com Subject: Re: [Sip] Comments on Resource Priority -08 (no resource shortage) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.2 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, iesg@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is indeed an oversight. I agree that authorization is (almost) always needed. There are some cases where only the request, e.g., in a proxy, gets handling priority, i.e., there is no call state and thus the problem you mention doesn't occur. But it is probably not worth teasing out these special cases. > Section 4.2, rule 1 indicates that, if there is no resource shortage at > the moment, the RP actor omits the following steps. However, the > following steps are the authorization/authentication steps which must > always be done first, since one of the results of requesting a priority > level, even when there is no resource shortage at the moment, is to use > the priority level during the remainder of the call and to provide it to > the destination user. For example, the level requested may prevent a > later preemption after a shortage of resources occurs. Rule 1 should > simply be the final sentence in Rule 1. This rule was not in version -05 > of this draft, and I am unaware of any e-mail or meeting discussion to > add such a rule. Any attempt to explain or justify this rule as it is > currently written will only add confusion. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun May 29 17:39:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcVVR-0005Q9-My; Sun, 29 May 2005 17:39:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcVVQ-0005Q1-OB; Sun, 29 May 2005 17:39:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26592; Sun, 29 May 2005 17:39:34 -0400 (EDT) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcVoi-00089E-Hd; Sun, 29 May 2005 17:59:32 -0400 Received: from [192.168.0.31] (pool-138-89-100-232.mad.east.verizon.net [138.89.100.232]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j4TLdYIv023389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 29 May 2005 17:39:35 -0400 (EDT) Message-ID: <429A3694.1010308@cs.columbia.edu> Date: Sun, 29 May 2005 17:39:32 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com Subject: Re: [Sip] Comments on Resource Priority -08 (417) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.2 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, iesg@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org A different reviewer has just requested on more detailed rules on what to do in this case, so one can't win, I suppose... Note that it says "a subsequent request". This does not imply that the UAC "redials". It simply tells the UAC and its user what values are permitted for future calls, for example. A user agent could, for example, display such values where known. The user interface is clearly beyond the scope of the draft. I don't see the need to change this. > Section 4.7.1 2nd paragraph states that "Upon receiving a 417, the UAC > MAY attempt a subsequent request with the same or different resource > value." This is contrary to the policies for using priority values and > should not be mentioned. The user (human) is supposed to select the > correct value before requested a call setup. A UAC must never > automatically attempt another request using a different resource value > upon receipt of a 417. Of course, a human user may choose to do whatever > they are authorized to do when trying a new call, but no device can be > allowed to do this automatically, since it would be violating the > policies for the use of priority levels. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun May 29 17:43:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcVZZ-0006B7-M4; Sun, 29 May 2005 17:43:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcVZX-0006Au-J8; Sun, 29 May 2005 17:43:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26871; Sun, 29 May 2005 17:43:49 -0400 (EDT) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcVsp-0008G4-FA; Sun, 29 May 2005 18:03:47 -0400 Received: from [192.168.0.31] (pool-138-89-100-232.mad.east.verizon.net [138.89.100.232]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j4TLho4D023651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 29 May 2005 17:43:50 -0400 (EDT) Message-ID: <429A3793.2050507@cs.columbia.edu> Date: Sun, 29 May 2005 17:43:47 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com Subject: Re: [Sip] Comments on Resource Priority -08 (DSN) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.2 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, iesg@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > Section 10.2 states in the last sentence that the DSN (incorrectly > written as "DRSN") uses preemption. This is misleading, since it may use Typo fixed. > other preferential treatment procedures as well. It is unnecessary for > this document to state the algorithms/procedures used in each domain. > Any mention of algorithms or procedures should only be as examples of > what might occur in a domain. This information on "semantics" had, as far as I recall, been previously requested by the WG chair(s). The authors would appreciate guidance from the chairs, as removal would, in my opinion, contradict earlier advice from the WG chairs. Clearly, if a namespace does not specify any treatment in its defining documents, we should say so. I gather DSN is among those? > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun May 29 17:58:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcVnP-0007we-No; Sun, 29 May 2005 17:58:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcVnN-0007wP-Lc; Sun, 29 May 2005 17:58:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27635; Sun, 29 May 2005 17:58:07 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcW6e-00005N-LF; Sun, 29 May 2005 18:18:05 -0400 Received: from [192.168.0.31] (pool-138-89-100-232.mad.east.verizon.net [138.89.100.232]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j4TLw7Ed017315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 29 May 2005 17:58:07 -0400 (EDT) Message-ID: <429A3AE9.9030304@cs.columbia.edu> Date: Sun, 29 May 2005 17:58:01 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com Subject: Re: [Sip] Comments on Resource Priority -08 (label length) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.2 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, iesg@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > Sections 10.2 and 10.3 > Security concerns make it appear that the variable length priority names > will be a problem. When individual SIP packets are encrypted for > confidentiality, the lengths of signaling messages will be a function of > the priority level, thereby letting an attacker know when the volume of > high priority calls increases. It appears now that it would be > preferable to use same-length names for all priority levels. Should this be a concern, there is a trivial mechanism to solve the problem: just add some whitespace, as in Resource-Priority: routine Resource-Priority: priority Resource-Priority: immediate Resource-Priority: flash etc. (I'm showing spaces before the r-value, but you can place these anywhere; they are just harder to see in email if I had put them after the label...) Given this simple solution, I don't see a need for a change. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun May 29 18:03:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcVsQ-0000A2-1m; Sun, 29 May 2005 18:03:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcVsL-00009r-DY; Sun, 29 May 2005 18:03:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28049; Sun, 29 May 2005 18:03:15 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcWBb-0000CB-9w; Sun, 29 May 2005 18:23:13 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 29 May 2005 15:03:06 -0700 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4TM2wlw007133; Sun, 29 May 2005 15:02:58 -0700 (PDT) Received: from jmpolk-wxp.cisco.com (syd-vpn-client-254-29.cisco.com [10.66.254.29]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA09564; Sun, 29 May 2005 15:03:00 -0700 (PDT) Message-Id: <4.3.2.7.2.20050529165758.03063ef0@diablo.cisco.com> X-Sender: jmpolk@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 29 May 2005 17:02:58 -0500 To: Henning Schulzrinne , Mpierce1@aol.com From: "James M. Polk" Subject: Re: [Sip] Comments on Resource Priority -08 (DSN) In-Reply-To: <429A3793.2050507@cs.columbia.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: sip@ietf.org, iesg@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At 05:43 PM 5/29/2005 -0400, Henning Schulzrinne wrote: >>other preferential treatment procedures as well. It is unnecessary for >>this document to state the algorithms/procedures used in each domain. Any >>mention of algorithms or procedures should only be as examples of what >>might occur in a domain. > >This information on "semantics" had, as far as I recall, been previously >requested by the WG chair(s). This was clearly pointed out by the SIP WG chair with the following message header: Date: Wed, 17 Nov 2004 19:17:19 -0600 From: Dean Willis To: Mpierce1@aol.com, sip@ietf.org Subject: Re: [Sip] Comments on Resource-priority-05 Mike - you did not comment on the list to this message from Dean, while others did. References: <1ea.2fbc8541.2ecc624e@aol.com> In-Reply-To: <1ea.2fbc8541.2ecc624e@aol.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit >The authors would appreciate guidance from the chairs, as removal would, >in my opinion, contradict earlier advice from the WG chairs. cheers, James ******************* Truth is not to be argued... it is to be presented. Alas, few *truths* exist without the math. ...all else is a matter of perspective _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun May 29 18:07:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcVwR-0000ma-Fp; Sun, 29 May 2005 18:07:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcVwP-0000m8-Op; Sun, 29 May 2005 18:07:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28634; Sun, 29 May 2005 18:07:27 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcWFh-0000IB-N7; Sun, 29 May 2005 18:27:26 -0400 Received: from [192.168.0.31] (pool-138-89-100-232.mad.east.verizon.net [138.89.100.232]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j4TM7RVD007924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 29 May 2005 18:07:28 -0400 (EDT) Message-ID: <429A3D19.2090605@cs.columbia.edu> Date: Sun, 29 May 2005 18:07:21 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com Subject: Re: [Sip] Comments on Resource Priority -08 (new labels) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.2 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, iesg@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > Section 12.1 2nd paragraph forbids adding a new priority value to a > namespace (MUST NOT). Previous versions of this draft (-06 and before) > allowed it, while advising against it (SHOULD NOT). For example, there > is no reason why another value cannot be added to DSN later, if the > operator of the DSN wishes to. If added, it is the responsibility of the > operator of the DSN domain to figure out how to do it to avoid > interoperability problems. For example, there is a possibility that the > DSN will need to add a new level below Routine. The RFC can not forbid this. I'm happy to use SHOULD NOT, but I believe the MUST NOT reflected working group consensus, given that specs issues by the IETF have the obligation to avoid interoperability issues. A "SHOULD NOT" would only make sense, I believe, if we were to state when and where such additions are "safe". Just leaving the implementor, IANA and future standardizers with a vague "yellow flag" (SHOULD NOT) seems imprudent. Earlier drafts had more unknown-namespace handling, so this might now have become simpler. Adding a new value in a namespace could, however, cause problems, for example, if a proxy ignored the namespace/priority value as being unknown, while a UAS relied on the proxy to have authenticated and authorized the request. That seems brittle. In other words, before allowing a change, we need to understand whether this requires special care in IANA registration. If additions are allowed, we may have to change the proxy behavior description to be more picky for known namespaces and unknown labels. This error condition cannot occur at the moment. Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun May 29 18:12:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcW0f-0001g1-Gm; Sun, 29 May 2005 18:11:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcW0d-0001fk-O5; Sun, 29 May 2005 18:11:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29262; Sun, 29 May 2005 18:11:49 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcWJu-0000Q3-PD; Sun, 29 May 2005 18:31:47 -0400 Received: from [192.168.0.31] (pool-138-89-100-232.mad.east.verizon.net [138.89.100.232]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j4TMBnab008229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 29 May 2005 18:11:49 -0400 (EDT) Message-ID: <429A3E1D.5010405@cs.columbia.edu> Date: Sun, 29 May 2005 18:11:41 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com Subject: Re: [Sip] Comments on Resource Priority -08 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.2 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, iesg@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Mpierce1@aol.com wrote: > > Section 1, paragraph beginning "Since calls may traverse..." states that > "it is important that all such domains and elements apply the same > algorithms for the same namespace as otherwise the end-to-end experience > of privileged users may be compromised." While this may be true for some > combinations of preemption followed by queuing, it is not necessarily > true for all combinations and for any algorithm that might be added > later. Suggest that this sentence be reworded to say: "It is important > that careful consideration be made before different algorithms are used > at different places within a single call." Noted and adjusted to simply say "It is strongly suggested ...". This is all non-normative in any event. Removed example to avoid giving offense. Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun May 29 18:16:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcW5J-0002Vb-Gn; Sun, 29 May 2005 18:16:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcW5H-0002VT-CQ; Sun, 29 May 2005 18:16:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29846; Sun, 29 May 2005 18:16:34 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcWOW-0000WC-DF; Sun, 29 May 2005 18:36:33 -0400 Received: from [192.168.0.31] (pool-138-89-100-232.mad.east.verizon.net [138.89.100.232]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j4TMGYqu018639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 29 May 2005 18:16:35 -0400 (EDT) Message-ID: <429A3F3A.7010204@cs.columbia.edu> Date: Sun, 29 May 2005 18:16:26 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com Subject: Re: [Sip] Comments on Resource Priority -08 (180/200) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.2 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, iesg@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Mpierce1@aol.com wrote: > Although section 7 only gives "examples", the use of "DSN" causes > confusion since it shows an operation which would not be used in the DSN > domain. Specifically, the inclusion of the R-P header in the 180 and 200 > in 7.1 and the list of accepted values in the 417 in 7.2 would not be > used in the DSN since this causes a security problem by telling the > originator what precedence level call the called party is involved in. There's a slightly different problem in that we decided, I believe, that the response header serves no particular purpose and can't be trusted by intermediaries, so the table in 3.3 doesn't specify its use. Unfortunately, this change didn't make it into the example. They are now gone. > The example should use a domain that might use these techniques. Since > there is none that is known to work this way, the examples should use > "Foo" and "Bar" as in Section 8.2. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun May 29 18:17:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcW5n-0002Z2-RP; Sun, 29 May 2005 18:17:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcW5m-0002Yu-Ag; Sun, 29 May 2005 18:17:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29902; Sun, 29 May 2005 18:17:07 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcWP4-0000WR-97; Sun, 29 May 2005 18:37:06 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 29 May 2005 15:17:00 -0700 X-IronPort-AV: i="3.93,148,1115017200"; d="scan'208"; a="271357773:sNHT28783210" Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4TMGvlq025807; Sun, 29 May 2005 15:16:58 -0700 (PDT) Received: from jmpolk-wxp.cisco.com (syd-vpn-client-254-29.cisco.com [10.66.254.29]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA13294; Sun, 29 May 2005 15:16:53 -0700 (PDT) Message-Id: <4.3.2.7.2.20050529170422.025079e8@diablo.cisco.com> X-Sender: jmpolk@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 29 May 2005 17:16:52 -0500 To: Mpierce1@aol.com, iesg@ietf.org, sip@ietf.org, sipping@ieft.org From: "James M. Polk" Subject: Re: [Sip] Comments on Last Call of "Extending Reason-header for Preemption Events" In-Reply-To: <143.454b8510.2fbe01cd@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org comments below At 10:50 AM 5/19/2005 -0400, Mpierce1@aol.com wrote: >The following comments are submitted on >draft-ietf-sipping-reason-header-for-preemption-02. > >Section 5 >The second reason listed should be for a general network preemption, no >matter what technique is used to cause it. RSVP is only one possible way. >The reason should not be named "RSVP". This is how I originally wrote it (as "network-based"). Early WG consensus changed it to "RSVP" as several commented they wanted the granularity of more than one type of non-endpoint reason for preemption. In the future, I believe there could be one for NSIS, one for security level, etc. Each of those will necessitate an extension to this document once the WG agrees there is such a need. >In fact, it appears that the important part of the defined protocol is the >cause value (2" for this case) to mean "network preemption". The following >"default" text is optional, only used for those cases in which a human >user might read this for more information concerning the reasons for >preemption. Since it is referred to as "default text", there should be no >reason that it could not be anything else an implementation wanted to use. >The formal definition of the syntax in RFC 3326 makes the text part >optional. However, this draft appears to require that both the cause value >and the text are always present and with the exact text string given >(mistakenly described in the "IANA Considerations" section.) This needs to >be corrected to be consistent with RFC 3326. The text is default and optional and can be changed within an administrative domain to something else. The cause code is what SIP elements react to. These is nothing in the document stating anything to do with the UI. I left that out on purpose. >Section 5.2 >This needs to be reworded so it is not RSVP-specific. Any mention of RSVP >should only be as an example of how network preemption might be controlled. If the WG wanted cause=2 to be RSVP Preemption (see above), then I don't believe changes are necessary. >Section 7 IANA Considerations >As noted above, this section contains an erroneous statement about what >"syntax shall be used". At the same time, it is unclear what the IANA >registration requirements are. For example, this part implies that IANA >needs to register the text strings, when there is clearly no need for that. > >Section 10 Normative References >RFC 2205, RSVP, should not be listed as Normative. 2205 describes premption in RSVP. In order for the reader to know that is the case, and how this mechanism is mapped to that mechanism, there needs to be a binding. I chose normative based on the desire of the WG to have cause=2 to be RSVP Preemption. With this in mind, I don't believe changes are necessary. >Mike Pierce >Artel, Inc. >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip cheers, James ******************* Truth is not to be argued... it is to be presented. Alas, few *truths* exist without the math. ...all else is a matter of perspective _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun May 29 18:24:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcWCs-00031L-W7; Sun, 29 May 2005 18:24:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcWCr-00030v-CL; Sun, 29 May 2005 18:24:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00523; Sun, 29 May 2005 18:24:27 -0400 (EDT) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcWW9-0000go-Iy; Sun, 29 May 2005 18:44:25 -0400 Received: from [192.168.0.31] (pool-138-89-100-232.mad.east.verizon.net [138.89.100.232]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j4TMORSb026319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 29 May 2005 18:24:27 -0400 (EDT) Message-ID: <429A4111.8000906@cs.columbia.edu> Date: Sun, 29 May 2005 18:24:17 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com Subject: Re: [Sip] Comments on Resource Priority -08 (namespace order) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.2 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, iesg@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Mpierce1@aol.com wrote: > Section 8.1 causes confusion since it implies the existence of a > relative order between different namespaces. It should instead say that > there is no defined relationship between the values of different > namespaces and that RP actors may apply whatever algorithms or > procedures they wish when dealing with multiple namespaces, as long as > the relative levels within each namespace are maintained. As far as I can tell, the section does not imply any ordering beyond a single administrative domain. It simply says that "If an *RP actor* understands multiple namespaces, it must create a *local* total ordering across all resource values from these namespaces" [emphasis added] Maybe you can identify where such a namespace ordering is implied. Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun May 29 18:27:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcWFz-0004D1-Hp; Sun, 29 May 2005 18:27:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcWFx-0004Cp-6y; Sun, 29 May 2005 18:27:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01052; Sun, 29 May 2005 18:27:38 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcWZE-0000ql-Cu; Sun, 29 May 2005 18:47:37 -0400 Received: from [192.168.0.31] (pool-138-89-100-232.mad.east.verizon.net [138.89.100.232]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j4TMRc2F019397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 29 May 2005 18:27:38 -0400 (EDT) Message-ID: <429A41CF.1060704@cs.columbia.edu> Date: Sun, 29 May 2005 18:27:27 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com Subject: Re: [Sip] Comments on Resource Priority -08 (10.3) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.2 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, iesg@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Continuing to flood your mailbox (maybe this will convince the IESG of the need for an issue tracker for last-call comments :-)): Mpierce1@aol.com wrote: > Section 10.3 > The final paragraph should be deleted, since it is not the > responsibility of this document to describe the detailed operation > within the DRSN, which could change at any time. I'm happy to delete this, but this was inserted by request of working group members as it provides implementor information. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun May 29 18:34:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcWM7-0005XK-BB; Sun, 29 May 2005 18:34:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcWM5-0005VJ-NG; Sun, 29 May 2005 18:34:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01514; Sun, 29 May 2005 18:33:59 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcWfM-0000zl-Sj; Sun, 29 May 2005 18:53:58 -0400 Received: from [192.168.0.31] (pool-138-89-100-232.mad.east.verizon.net [138.89.100.232]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j4TMXw11009734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 29 May 2005 18:33:59 -0400 (EDT) Message-ID: <429A434B.5080407@cs.columbia.edu> Date: Sun, 29 May 2005 18:33:47 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com Subject: Re: [Sip] Comments on Resource Priority -08 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.2 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, iesg@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Mpierce1@aol.com wrote: > Section 11.3 > The association of the requirement for confidentiality and integrity of > the user's data with the Resource-Priority header leads to confusion. > They are unrelated requirements. Other policies and requirements dictate > whether there is a need for confidentiality and integrity of the user's > data independently from the need for precedence levels. The first > paragraph should be deleted so that this section only addresses the > security of the R-P header itself, since that is the subject of this > document. Security of the user's data is not the subject of this document. These requirements were, if I recall correctly, added based on either WG chair and/or AD suggestion. I await advice from the IESG whether this paragraph should be removed. They have been in the draft since draft-polk-sip-resource-03 (March 2003). Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun May 29 18:38:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcWQb-0006Kw-Ix; Sun, 29 May 2005 18:38:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcWQZ-0006Kd-3K; Sun, 29 May 2005 18:38:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01972; Sun, 29 May 2005 18:38:36 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcWjq-000172-Ek; Sun, 29 May 2005 18:58:35 -0400 Received: from [192.168.0.31] (pool-138-89-100-232.mad.east.verizon.net [138.89.100.232]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j4TMcZ4a010031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 29 May 2005 18:38:35 -0400 (EDT) Message-ID: <429A446B.1080306@cs.columbia.edu> Date: Sun, 29 May 2005 18:38:35 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com Subject: Re: [Sip] Comments on Resource Priority -08 (anonymity) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.2 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, iesg@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > Section 11.4 > No system that allows the use of the R-P header should allow anonymity. > In any case, the issue of anonymity is independent from the use of R-P > header and should not be mentioned in this document. I don't know how you can know about all current and future R-P header deployments to make such a categorical statement. Same considerations as discussed for Section 11.3. Nothing in this section requires the support of anonymity in RP systems. The section simply provides guidance to implementors should such support be desired. Note, in paticular, that anonymity in the "do not know your name" does not imply lack of authentication or authorization. As the paragraph notes, capability-based certificates may well offer the functionality desired. Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun May 29 18:46:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcWYN-0007Gl-Qx; Sun, 29 May 2005 18:46:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcWYM-0007Gd-68; Sun, 29 May 2005 18:46:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02545; Sun, 29 May 2005 18:46:39 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcWre-0001Gc-IR; Sun, 29 May 2005 19:06:38 -0400 Received: from [192.168.0.31] (pool-138-89-100-232.mad.east.verizon.net [138.89.100.232]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j4TMkbXD010523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 29 May 2005 18:46:37 -0400 (EDT) Message-ID: <429A464D.2030805@cs.columbia.edu> Date: Sun, 29 May 2005 18:46:37 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com Subject: Re: [Sip] Comments on Resource Priority -08 (IANA) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.2 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, iesg@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is my final response to Mike's comments. I'd like to thank him for the careful reading of the document and his efforts to improve its clarity and technical correctness. > Section 12.1 > The purpose of IANA registration is to prevent conflicts in assignment > of names and numbers, such as the namespace, and to ensure compatibility > for things like the priority values. There is no need to include the > "operation" (preemption or preferential queuing) in the IANA > registration. It is described sufficiently in this document. In fact, > the DSN uses other techniques besides preemption, such as exemption from > network management controls, as described in > draft-pierce-tsvwg-pref-treat-example, so it is wrong to register it as > just "preemption". Likewise, ETS may use other techniques besides > "queue", such as exemption from control restrictions and enhanced > routing (See explanation at www.ncs.gov/docs/GETS overview brief). > Clearly, the draft and registration cannot and does not attempt to exhaustively specify all behaviors associated with a namespace. Any implementation will need to add, as per your example, description of the relationship to other aspects mentioned in the draft, such as routing and management controls. Either we remove all useful descriptions of behavior, contradicting earlier SIP WG chair advice, or the IANA registration needs to carry forth the collection of this information where it is available. I have added a disclaimer "Other behavior, such as request routing or network management controls, is not defined by this specification." earlier in the text. Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun May 29 18:54:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcWfZ-0000Hu-S1; Sun, 29 May 2005 18:54:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcWfX-0000Hm-L3; Sun, 29 May 2005 18:54:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03503; Sun, 29 May 2005 18:54:05 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcWyo-0001UT-Uu; Sun, 29 May 2005 19:14:04 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 29 May 2005 15:53:57 -0700 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4TMrolw018129; Sun, 29 May 2005 15:53:50 -0700 (PDT) Received: from jmpolk-wxp.cisco.com (syd-vpn-client-254-29.cisco.com [10.66.254.29]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA22660; Sun, 29 May 2005 15:53:51 -0700 (PDT) Message-Id: <4.3.2.7.2.20050529175011.02414de8@diablo.cisco.com> X-Sender: jmpolk@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 29 May 2005 17:53:50 -0500 To: Henning Schulzrinne , Mpierce1@aol.com From: "James M. Polk" Subject: Re: [Sip] Comments on Resource Priority -08 (10.3) In-Reply-To: <429A41CF.1060704@cs.columbia.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: sip@ietf.org, iesg@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At 06:27 PM 5/29/2005 -0400, Henning Schulzrinne wrote: >Continuing to flood your mailbox (maybe this will convince the IESG of the >need for an issue tracker for last-call comments :-)): > >Mpierce1@aol.com wrote: >>Section 10.3 >>The final paragraph should be deleted, since it is not the responsibility >>of this document to describe the detailed operation within the DRSN, >>which could change at any time. > >I'm happy to delete this, but this was inserted by request of working >group members as it provides implementor information. This was explicitly requested because this is a change in the operation from other namespaces in that the requesting priority level of FOO is defended at a lower level (FO). This is the only current known case of this operation, and implementors should have a hint at this operation. >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip cheers, James ******************* Truth is not to be argued... it is to be presented. Alas, few *truths* exist without the math. ...all else is a matter of perspective _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun May 29 18:57:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcWj6-0000a0-7d; Sun, 29 May 2005 18:57:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcWj4-0000ZW-5t for sip@megatron.ietf.org; Sun, 29 May 2005 18:57:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03702 for ; Sun, 29 May 2005 18:57:43 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcX2M-0001YZ-KH for sip@ietf.org; Sun, 29 May 2005 19:17:42 -0400 Received: from [192.168.0.31] (pool-138-89-100-232.mad.east.verizon.net [138.89.100.232]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j4TMvisG011257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 29 May 2005 18:57:45 -0400 (EDT) Message-ID: <429A48EA.90500@cs.columbia.edu> Date: Sun, 29 May 2005 18:57:46 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dale Worley Subject: Re: [Sip] Comments on draft-ietf-sip-resource-priority-08 (normal calls) References: <00eb01c549d8$bf290fb0$6a01010a@keywest> In-Reply-To: <00eb01c549d8$bf290fb0$6a01010a@keywest> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: "Sip \(E-mail\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dale, thanks for your comments below and my apologies for addressing them late. Please see inline for responses. Dale Worley wrote: > - Requests without the Resource-Priority: header are intended to be > processed at a lower priority than requests with a Resource-Priority: > header. But I don't recall this being stated explicitly anywhere, and > certainly not up-front in the document. And there seems to be no > fixed terminology for such requests. The phrase "normal, > non-prioritized" seems to be used a lot, despite its cumbersomeness, > and the fact that it is objectively incorrect. (Any PR actor > prioritizes *all* requests; requests without Resource-Priority: are > given the lowest priority.) > Nothing prevents somebody to define a "scavenger" service for the R-P header, i.e., a service that has priority *below* the normal priority level. Unlikely, but possible. For example, the gas meter could prioritize its meter reading calls as Resource-Priority: gas.unimportant I grep'ed for the terms you mentioned, but only found one such reference. Maybe you can identify (in private email) conflicting wording. > - Given the age of this I-D, there are likely to be implementations of > this mechanism in the field. It would enhance the reader's interest > of these were briefly mentioned. I don't think this is customary and I'm not sure what we should say here. More to come. Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun May 29 19:02:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcWnJ-0001eZ-OG; Sun, 29 May 2005 19:02:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcWnH-0001ak-Ea for sip@megatron.ietf.org; Sun, 29 May 2005 19:02:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04199 for ; Sun, 29 May 2005 19:02:04 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcX6Z-0001gv-0d for sip@ietf.org; Sun, 29 May 2005 19:22:04 -0400 Received: from [192.168.0.31] (pool-138-89-100-232.mad.east.verizon.net [138.89.100.232]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j4TN24Ij021800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 29 May 2005 19:02:05 -0400 (EDT) Message-ID: <429A49EF.2080902@cs.columbia.edu> Date: Sun, 29 May 2005 19:02:07 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dale Worley Subject: Re: [Sip] Comments on draft-ietf-sip-resource-priority-08 References: <00eb01c549d8$bf290fb0$6a01010a@keywest> In-Reply-To: <00eb01c549d8$bf290fb0$6a01010a@keywest> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.4 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: "Sip \(E-mail\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dale Worley wrote: > - There seems to be some ambiguity as to whether a request is > queued/delayed waiting for the resources needed to process the request > *itself*, or waiting for resources (like UA facilities, or bandwidth) > needed for the *dialog* containing the request. This is probably not > important, as the prioritization for both sorts of resources is the > same, but it gets a bit confusing as the draft refers randomly to one > situation and then the other. It might help to state up-front that > there can be queuing for various sorts of resources, and (absent > specific policy rules in the IANA registration) they are handled the > same way. The document assumes that only sessions are preempted. See Section 4.5: "Preemption applies only to sessions created by SIP requests, while both sessions and request handling can be subject to priority queueing." I don't think preemption makes sense for processing SIP requests themselves (parsing, authenticating, etc.), as this has all kinds of bad consequences. If you find other references where the distinction is not made clear, please let me know. Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun May 29 19:53:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcXay-0000GJ-1V; Sun, 29 May 2005 19:53:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcXaw-0000GD-GF for sip@megatron.ietf.org; Sun, 29 May 2005 19:53:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06949 for ; Sun, 29 May 2005 19:53:23 -0400 (EDT) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcXuC-0002Yr-DD for sip@ietf.org; Sun, 29 May 2005 20:13:21 -0400 Received: from [192.168.0.31] (pool-138-89-100-232.mad.east.verizon.net [138.89.100.232]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j4TNrH9r002574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 29 May 2005 19:53:21 -0400 (EDT) Message-ID: <429A55F4.8060709@cs.columbia.edu> Date: Sun, 29 May 2005 19:53:24 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dale Worley Subject: Re: [Sip] Comments on draft-ietf-sip-resource-priority-08 (policies) References: <00eb01c549d8$bf290fb0$6a01010a@keywest> In-Reply-To: <00eb01c549d8$bf290fb0$6a01010a@keywest> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.2 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: "Sip \(E-mail\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > - There are many places where the text notes that the generic > prioritization behavior can be modified by the specific policies in > the IANA registration for the namespace. This seems to be redundant, > and perhaps could be replaced by a single up-front statement. This > could be augmented by a statement that the operation of a PR actor can > also be modified by local administrative policy. Can you help me by identifying these places? I searched for 'IANA' and didn't find undue duplication. Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun May 29 19:57:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcXeV-0000f1-NL; Sun, 29 May 2005 19:57:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcXeU-0000df-5k for sip@megatron.ietf.org; Sun, 29 May 2005 19:57:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07398 for ; Sun, 29 May 2005 19:57:05 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcXxm-0002ek-6o for sip@ietf.org; Sun, 29 May 2005 20:17:03 -0400 Received: from [192.168.0.31] (pool-138-89-100-232.mad.east.verizon.net [138.89.100.232]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j4TNv3V0015384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 29 May 2005 19:57:03 -0400 (EDT) Message-ID: <429A56D7.1020004@cs.columbia.edu> Date: Sun, 29 May 2005 19:57:11 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dale Worley Subject: Re: [Sip] Comments on draft-ietf-sip-resource-priority-08 (Accept-R-P) References: <00eb01c549d8$bf290fb0$6a01010a@keywest> In-Reply-To: <00eb01c549d8$bf290fb0$6a01010a@keywest> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.2 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: "Sip \(E-mail\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dale Worley wrote: > - Section 3.2, "Accept-Resource-Priority" is unclear as to the > semantics of the header. Usually, "Accept" headers describe > "configuration" information about the device which changes very > slowly. Within that concept, I would expect that > "Accept-Resource-Priority" would list the namespaces that the RP actor > understands. But since the definition of the header says that it > lists priority values, it must be to indicate the priorities that the > actor currently has the resources to handle. If so, this should be > made explicit. In this case, it seems like there needs to be an > extension of the definition to allow it to specify that > "non-prioritized" requests will be accepted. This is indeed simply a syntactic understanding. Accept-R-P does not indicate which resource priority value would yield a successful call. (Among other reaons, such information would be of limited use, given the possibly rapid change in load.) I changed "willing to accept" to "willing to process". Let me know if there are any other places that could be read as implying that this is dynamic, load-dependent state. Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun May 29 20:03:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcXky-0001py-5c; Sun, 29 May 2005 20:03:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcXkv-0001ps-Ug for sip@megatron.ietf.org; Sun, 29 May 2005 20:03:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07968 for ; Sun, 29 May 2005 20:03:44 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcY4E-0002pV-19 for sip@ietf.org; Sun, 29 May 2005 20:23:43 -0400 Received: from [192.168.0.31] (pool-138-89-100-232.mad.east.verizon.net [138.89.100.232]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j4U03h8B026166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 29 May 2005 20:03:43 -0400 (EDT) Message-ID: <429A5868.4090206@cs.columbia.edu> Date: Sun, 29 May 2005 20:03:52 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dale Worley Subject: Re: [Sip] Comments on draft-ietf-sip-resource-priority-08 (Section 4) References: <00eb01c549d8$bf290fb0$6a01010a@keywest> In-Reply-To: <00eb01c549d8$bf290fb0$6a01010a@keywest> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.2 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: "Sip \(E-mail\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dale Worley wrote: > - In section 4.6.4, "Insufficient authorization" seems to presuppose > that the RP actor can determine whether the requester is authorized to > use any particular priority. But this seems like it is not always > true. A better phrasing might be "... but it can determine that the > originator is not authorized ...". I don't see how an RP actor can *not* know whether somebody is authorized, since it needs to decide whether to honor the request. > > - Section 4.6.5 contains the sentence fragment "If an RP actor > receives an authorized request, has insufficient resources and the > request neither preempts another request nor is queued." Fixed. > > - In section 4.7.2.1, it might be an improvement to say "MUST > terminate or interrupt (as appropriate) a session established". It > seems that the range of resources that might be needed to establish a > dialog is quite broad (we've already identified signaling processing > capacity, media bandwidth, and UA facilities, and there are likely to > be more), and so we need to allow a broad range of strategies for RP > actors to free resources, with only the overriding constraint that the > higher-priority request must not be blocked from being processed by > resources consumed by a request of sufficiently lower priority. (See > section 4.9 describe how request priorities might be grouped and > handled together.) I'm not sure I understand. Are you suggesting a new behavior where the gateway puts the lower-priority call on hold and then later resumes it? (I don't know what you mean by "interrupt".) > > - In section 4.7.2.2, the last sentence might read better as "However, > the requirements in [RFC3261] regarding the frequency of provisional > messages still apply, in order to keep each session set-up active > until successful or rejected." This is indeed an odd sentence; fixed. Again, thanks for your comments. Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun May 29 20:04:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcXlx-0001sS-BT; Sun, 29 May 2005 20:04:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcXlv-0001sN-Dr for sip@megatron.ietf.org; Sun, 29 May 2005 20:04:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07988 for ; Sun, 29 May 2005 20:04:46 -0400 (EDT) Received: from ausmtp01.au.ibm.com ([202.81.18.186]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcY5D-0002qX-1m for sip@ietf.org; Sun, 29 May 2005 20:24:44 -0400 Received: from sd0208e0.au.ibm.com (d23rh904.au.ibm.com [202.81.18.202]) by ausmtp01.au.ibm.com (8.12.10/8.12.10) with ESMTP id j4U070AR089570 for ; Mon, 30 May 2005 10:07:00 +1000 Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.250.244]) by sd0208e0.au.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4U07Mwv151654 for ; Mon, 30 May 2005 10:07:22 +1000 Received: from d23av03.au.ibm.com (loopback [127.0.0.1]) by d23av03.au.ibm.com (8.12.11/8.13.3) with ESMTP id j4U04TTw007028 for ; Mon, 30 May 2005 10:04:29 +1000 Received: from d23m0037.cn.ibm.com (d23m0037.cn.ibm.com [9.181.2.105]) by d23av03.au.ibm.com (8.12.11/8.12.11) with ESMTP id j4U04SnU007010 for ; Mon, 30 May 2005 10:04:29 +1000 From: Ke Ke Qi To: sip@ietf.org Message-ID: Date: Mon, 30 May 2005 08:06:00 +0800 X-MIMETrack: Serialize by Router on D23M0037/23/M/IBM(Build V70_M4_01112005 Beta 3|January 11, 2005) at 05/30/2005 08:06:02 MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Sip] Ke Ke Qi/China/IBM is out of the office. X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2140782295==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============2140782295== Content-type: multipart/alternative; Boundary="0__=C7BBFA82DF930A518f9e8a93df938690918cC7BBFA82DF930A51" Content-Disposition: inline --0__=C7BBFA82DF930A518f9e8a93df938690918cC7BBFA82DF930A51 Content-type: text/plain; charset=US-ASCII I will be out of the office starting 2005-05-30 and will not return until 2005-06-06. I will respond to you when I return. Any urgent thing, please contact with my manager Yan Da Lai --0__=C7BBFA82DF930A518f9e8a93df938690918cC7BBFA82DF930A51 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

I will be out of the office starting 2005-05-30 and will not return until 2005-06-06.

I will respond to you when I return.
Any urgent thing, please contact with my manager Yan Da Lai --0__=C7BBFA82DF930A518f9e8a93df938690918cC7BBFA82DF930A51-- --===============2140782295== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2140782295==-- From sip-bounces@ietf.org Mon May 30 08:16:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcjC7-0005Ou-1n; Mon, 30 May 2005 08:16:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcjC5-0005Oo-4S for sip@megatron.ietf.org; Mon, 30 May 2005 08:16:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09571 for ; Mon, 30 May 2005 08:16:31 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcjVT-0007Wy-7x for sip@ietf.org; Mon, 30 May 2005 08:36:36 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate7) with ESMTP id j4UCOVP7018243 for ; Mon, 30 May 2005 05:24:31 -0700 (MST) Received: from zin24exm01.ap.mot.com (zin24exm01.ap.mot.com [10.232.25.1]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id j4UCKXJA008773 for ; Mon, 30 May 2005 07:20:34 -0500 (CDT) Received: by zin24exm01.ap.mot.com with Internet Mail Service (5.5.2657.72) id ; Mon, 30 May 2005 17:00:40 +0530 Message-ID: <772BCEF88A1DD91191F80011856715F302235736@zin24exm01.ap.mot.com> From: Chauhan Bhavik-A20762 To: "'sip@ietf.org'" , sip-implementors@cs.columbia.edu Date: Mon, 30 May 2005 17:00:39 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 2.5 (++) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Cc: Subject: [Sip] RE: 100rel and early-session option tags (RFC 3959) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1433335013==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org 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. --===============1433335013== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5650B.0149390E" 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_01C5650B.0149390E Content-Type: text/plain Resending it. Any comments on this? Thanks, Bhavik -----Original Message----- From: Chauhan Bhavik-A20762 Sent: Tuesday, May 24, 2005 10:53 AM To: sip@ietf.org Subject: 100rel and early-session option tags (RFC 3959) Hi, With Reference to RFC 3959 section 6, I think "early-session" option tag must be accompanied "100rel" if it is in "Require" header to indicate "Reliability of Provisional Response" support as I didn't find any relationship cited in RFCs. Does "early-session" implicitly indicate that? If not then, 1. A B ---INVITE(Require: early-session) ----> (INVITE is without 100rel option) As 100rel is not there what will be response from B? 2. A B ----INVITE(Supported: early-session) with OFFER ----> <---- 180 Reliable with early-offer & ANSWER---- (INVITE is without 100rel option ) What will be response from A as no 100rel supported? Regards, Bhavik Chauhan Motorola India Eletronics Pvt Ltd. ------_=_NextPart_001_01C5650B.0149390E Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KPFRJVExFPk1lc3NhZ2U8L1RJVExF Pg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yODAwLjE0OTEiIG5hbWU9R0VORVJBVE9S PjwvSEVBRD4NCjxCT0RZPg0KPERJVj48U1BBTiBjbGFzcz0yNDI1OTI0MTEtMzAwNTIwMDU+PEZP TlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0Kc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7 PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTI0MjU5MjQxMS0zMDA1MjAwNT48Rk9OVCBmYWNlPUFy aWFsIGNvbG9yPSMwMDAwZmYgDQpzaXplPTI+UmVzZW5kaW5nIGl0LiBBbnkgY29tbWVudHMgb24g dGhpcz88L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBjbGFzcz0yNDI1OTI0MTEtMzAw NTIwMDU+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0Kc2l6ZT0yPiZuYnNwOzwvRk9O VD48L1NQQU4+PC9ESVY+DQo8RElWIGFsaWduPWxlZnQ+PEZPTlQgZmFjZT1WZXJkYW5hPjxGT05U IGNvbG9yPSMwMDQwODA+PEZPTlQgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9MjQyNTkyNDExLTMwMDUy MDA1PlRoYW5rcyw8L1NQQU4+PC9GT05UPjwvRk9OVD48L0ZPTlQ+PC9ESVY+DQo8RElWIGFsaWdu PWxlZnQ+PEZPTlQgZmFjZT1WZXJkYW5hPjxGT05UIGNvbG9yPSMwMDQwODA+PEZPTlQgc2l6ZT0y PjxTUEFOIA0KY2xhc3M9MjQyNTkyNDExLTMwMDUyMDA1PjwvU1BBTj5CaGF2aWs8L0ZPTlQ+PC9G T05UPjwvRk9OVD48L0RJVj4NCjxCTE9DS1FVT1RFIGRpcj1sdHIgc3R5bGU9Ik1BUkdJTi1SSUdI VDogMHB4Ij4NCiAgPERJVj48L0RJVj4NCiAgPERJViBjbGFzcz1PdXRsb29rTWVzc2FnZUhlYWRl ciBsYW5nPWVuLXVzIGRpcj1sdHIgYWxpZ249bGVmdD48Rk9OVCANCiAgZmFjZT1UYWhvbWEgc2l6 ZT0yPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPEJSPjxCPkZyb206PC9CPiBDaGF1aGFuIA0K ICBCaGF2aWstQTIwNzYyIDxCUj48Qj5TZW50OjwvQj4gVHVlc2RheSwgTWF5IDI0LCAyMDA1IDEw OjUzIEFNPEJSPjxCPlRvOjwvQj4gDQogIHNpcEBpZXRmLm9yZzxCUj48Qj5TdWJqZWN0OjwvQj4g MTAwcmVsIGFuZCBlYXJseS1zZXNzaW9uIG9wdGlvbiB0YWdzIChSRkMgDQogIDM5NTkpPEJSPjxC Uj48L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNp emU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0j MDA4MDgwIHNpemU9Mj48U1BBTiANCiAgY2xhc3M9NDgzMDYzMDE1LTIzMDUyMDA1PkhpLDwvU1BB Tj48L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDA4MDgwIHNp emU9Mj48U1BBTiANCiAgY2xhc3M9NDgzMDYzMDE1LTIzMDUyMDA1PjwvU1BBTj48L0ZPTlQ+Jm5i c3A7PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9NDgzMDYzMDE1LTIzMDUyMDA1PjxGT05UIGZh Y2U9QXJpYWwgY29sb3I9IzAwODA4MCANCiAgc2l6ZT0yPjxGT05UIGNvbG9yPSMwMDAwZmY+PFNQ QU4gY2xhc3M9Nzc0MjIyMTA1LTI0MDUyMDA1PjxGT05UIA0KICBjb2xvcj0jMDA4MDgwPldpdGgg UmVmZXJlbmNlPC9GT05UPjwvU1BBTj48L0ZPTlQ+IHRvJm5ic3A7UkZDIDM5NTkgc2VjdGlvbiAN CiAgNiw8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTQ4MzA2MzAxNS0y MzA1MjAwNT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDgwODAgDQogIHNpemU9Mj48L0ZPTlQ+ PC9TUEFOPiZuYnNwOzwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTQ4MzA2MzAxNS0yMzA1MjAw NT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDgwODAgDQogIHNpemU9Mj48U1BBTiBjbGFzcz00 ODMwNjMwMTUtMjMwNTIwMDU+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDA4MDgwIHNpemU9Mj5J IA0KICB0aGluayAiZWFybHktc2Vzc2lvbiIgb3B0aW9uIHRhZyZuYnNwO211c3QgYmUgYWNjb21w YW5pZWQgIjEwMHJlbCIgaWYgaXQgDQogIGlzJm5ic3A7aW4gIlJlcXVpcmUiIGhlYWRlcjwvRk9O VD48L1NQQU4+PC9ESVY+DQogIDxESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9NDgzMDYzMDE1LTIz MDUyMDA1PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwODA4MCANCiAgc2l6ZT0yPnRvJm5ic3A7 aW5kaWNhdGUgIlJlbGlhYmlsaXR5IG9mIFByb3Zpc2lvbmFsIFJlc3BvbnNlIiANCiAgc3VwcG9y dDwvRk9OVD48L1NQQU4+PFNQQU4gY2xhc3M9NDgzMDYzMDE1LTIzMDUyMDA1PjxGT05UIGZhY2U9 QXJpYWwgDQogIGNvbG9yPSMwMDgwODAgc2l6ZT0yPiBhcyBJIGRpZG4ndCBmaW5kIGFueSByZWxh dGlvbnNoaXAgY2l0ZWQgDQogIDwvRk9OVD48L1NQQU4+PC9ESVY+DQogIDxESVY+PFNQQU4gY2xh c3M9NDgzMDYzMDE1LTIzMDUyMDA1PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwODA4MCBzaXpl PTI+aW4gDQogIFJGQ3MuIDwvRk9OVD48L1NQQU4+PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9 NDgzMDYzMDE1LTIzMDUyMDA1PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCiAgc2l6 ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9NDgzMDYz MDE1LTIzMDUyMDA1PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwODA4MCANCiAgc2l6ZT0yPiZu YnNwOyZuYnNwOyZuYnNwOyBEb2VzICJlYXJseS1zZXNzaW9uIiBpbXBsaWNpdGx5IGluZGljYXRl IA0KICB0aGF0PzwvRk9OVD48L1NQQU4+PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9NDgzMDYz MDE1LTIzMDUyMDA1PjxGT05UIA0KICBjb2xvcj0jMDAwMGZmPjwvRk9OVD48L1NQQU4+Jm5ic3A7 PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9NDgzMDYzMDE1LTIzMDUyMDA1PklmIG5vdCANCiAg dGhlbiw8L1NQQU4+PC9ESVY+PC9GT05UPjwvU1BBTj48L0RJVj4NCiAgPERJVj48U1BBTiBjbGFz cz00ODMwNjMwMTUtMjMwNTIwMDU+PC9TUEFOPjxTUEFOIA0KICBjbGFzcz00ODMwNjMwMTUtMjMw NTIwMDU+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDA4MDgwIA0KICBzaXplPTI+PC9GT05UPjwv U1BBTj4mbmJzcDs8L0RJVj4NCiAgPERJVj48U1BBTiBjbGFzcz00ODMwNjMwMTUtMjMwNTIwMDU+ PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDA4MDgwIA0KICBzaXplPTI+MS48L0ZPTlQ+PC9TUEFO PjwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTQ4MzA2MzAxNS0yMzA1MjAwNT48Rk9OVCBmYWNl PUFyaWFsIGNvbG9yPSMwMDgwODAgDQogIHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgDQogIEEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIEI8 L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTQ4MzA2MzAxNS0yMzA1MjAw NT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDgwODAgDQogIHNpemU9Mj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDstLS1JTlZJVEUoUmVxdWlyZTombmJzcDtlYXJs eS1zZXNzaW9uKSZuYnNwOy0tLS0mZ3Q7PC9GT05UPjwvU1BBTj48L0RJVj4NCiAgPERJVj48U1BB TiBjbGFzcz00ODMwNjMwMTUtMjMwNTIwMDU+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDA4MDgw IHNpemU9Mj4NCiAgPERJVj48U1BBTiBjbGFzcz00ODMwNjMwMTUtMjMwNTIwMDU+PEZPTlQgZmFj ZT1BcmlhbCBjb2xvcj0jMDA4MDgwIA0KICBzaXplPTI+PFNQQU4gY2xhc3M9NDgzMDYzMDE1LTIz MDUyMDA1PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwODA4MCANCiAgc2l6ZT0yPjxTUEFOIGNs YXNzPTQ4MzA2MzAxNS0yMzA1MjAwNT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQog IHNpemU9Mj48L0ZPTlQ+PC9TUEFOPjwvRk9OVD48L1NQQU4+PC9GT05UPjwvU1BBTj4mbmJzcDs8 L0RJVj4NCiAgPERJVj48U1BBTiBjbGFzcz00ODMwNjMwMTUtMjMwNTIwMDU+PEZPTlQgZmFjZT1B cmlhbCBjb2xvcj0jMDA4MDgwIA0KICBzaXplPTI+PFNQQU4gY2xhc3M9NDgzMDYzMDE1LTIzMDUy MDA1PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwODA4MCANCiAgc2l6ZT0yPjxTUEFOIGNsYXNz PTQ4MzA2MzAxNS0yMzA1MjAwNT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDgwODAgDQogIHNp emU9Mj4oSU5WSVRFIGlzIHdpdGhvdXQgMTAwcmVsIA0KICBvcHRpb24pPC9GT05UPjwvU1BBTj48 L0ZPTlQ+PC9TUEFOPjwvRk9OVD48L1NQQU4+PC9ESVY+PC9GT05UPjwvU1BBTj48L0RJVj4NCiAg PERJVj48U1BBTiBjbGFzcz00ODMwNjMwMTUtMjMwNTIwMDU+PEZPTlQgZmFjZT1BcmlhbCBjb2xv cj0jMDA4MDgwIHNpemU9Mj5BcyANCiAgMTAwcmVsIGlzIG5vdCB0aGVyZSB3aGF0IHdpbGwgYmUg cmVzcG9uc2UgZnJvbSBCPzwvRk9OVD48L1NQQU4+PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9 NDgzMDYzMDE1LTIzMDUyMDA1PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwODA4MCANCiAgc2l6 ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9NDgzMDYz MDE1LTIzMDUyMDA1PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwODA4MCBzaXplPTI+DQogIDxE SVY+PFNQQU4gY2xhc3M9NDgzMDYzMDE1LTIzMDUyMDA1PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9 IzAwODA4MCANCiAgc2l6ZT0yPjIuJm5ic3A7Jm5ic3A7Jm5ic3A7PC9GT05UPjwvU1BBTj48L0RJ Vj4NCiAgPERJVj48U1BBTiBjbGFzcz00ODMwNjMwMTUtMjMwNTIwMDU+PEZPTlQgZmFjZT1Bcmlh bCBjb2xvcj0jMDA4MDgwIA0KICBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IA0KICAmbmJzcDtBJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICBCPC9GT05UPjwvU1BBTj48L0RJVj4NCiAg PERJVj48U1BBTiBjbGFzcz00ODMwNjMwMTUtMjMwNTIwMDU+PEZPTlQgZmFjZT1BcmlhbCBjb2xv cj0jMDA4MDgwIA0KICBzaXplPTI+Jm5ic3A7Jm5ic3A7IC0tLS1JTlZJVEUoU3VwcG9ydGVkOiZu YnNwO2Vhcmx5LXNlc3Npb24pIHdpdGggDQogIE9GRkVSJm5ic3A7LS0tLSZndDs8L0ZPTlQ+PC9T UEFOPjwvRElWPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7LS0tLSAxODAgDQogIFJlbGlh YmxlIHdpdGggZWFybHktb2ZmZXIgJmFtcDsmbmJzcDtBTlNXRVItLS0tPC9GT05UPjwvU1BBTj48 L0RJVj4NCiAgPERJVj48U1BBTiBjbGFzcz00ODMwNjMwMTUtMjMwNTIwMDU+PEZPTlQgZmFjZT1B cmlhbCBjb2xvcj0jMDA4MDgwIA0KICBzaXplPTI+PFNQQU4gY2xhc3M9NDgzMDYzMDE1LTIzMDUy MDA1PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwODA4MCANCiAgc2l6ZT0yPjxTUEFOIGNsYXNz PTQ4MzA2MzAxNS0yMzA1MjAwNT4NCiAgPERJVj48U1BBTiBjbGFzcz00ODMwNjMwMTUtMjMwNTIw MDU+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDA4MDgwIA0KICBzaXplPTI+PFNQQU4gY2xhc3M9 NDgzMDYzMDE1LTIzMDUyMDA1PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwODA4MCANCiAgc2l6 ZT0yPjxTUEFOIGNsYXNzPTQ4MzA2MzAxNS0yMzA1MjAwNT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9y PSMwMDAwZmYgDQogIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPjwvRk9OVD48L1NQQU4+PC9GT05UPjwv U1BBTj4mbmJzcDs8L0RJVj4NCiAgPERJVj48U1BBTiBjbGFzcz00ODMwNjMwMTUtMjMwNTIwMDU+ PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDA4MDgwIA0KICBzaXplPTI+PFNQQU4gY2xhc3M9NDgz MDYzMDE1LTIzMDUyMDA1PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwODA4MCANCiAgc2l6ZT0y PjxTUEFOIGNsYXNzPTQ4MzA2MzAxNS0yMzA1MjAwNT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMw MDgwODAgDQogIHNpemU9Mj4oSU5WSVRFIGlzIHdpdGhvdXQgMTAwcmVsIG9wdGlvbiANCiAgKTwv Rk9OVD48L1NQQU4+PC9GT05UPjwvU1BBTj48L0ZPTlQ+PC9TUEFOPjwvRElWPjwvU1BBTj48L0ZP TlQ+PC9TUEFOPjwvRk9OVD48L1NQQU4+PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9NDgzMDYz MDE1LTIzMDUyMDA1PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwODA4MCBzaXplPTI+V2hhdCAN CiAgd2lsbCBiZSByZXNwb25zZSBmcm9tIEEgYXMgbm8gMTAwcmVsIHN1cHBvcnRlZD88L0ZPTlQ+ PC9TUEFOPjwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTQ4MzA2MzAxNS0yMzA1MjAwNT48Rk9O VCBmYWNlPUFyaWFsIGNvbG9yPSMwMDgwODAgDQogIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNw OzwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTQ4MzA2MzAxNS0yMzA1MjAwNT48Rk9OVCBmYWNl PUFyaWFsIGNvbG9yPSMwMDgwODAgDQogIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElW Pg0KICA8RElWIGFsaWduPWxlZnQ+DQogIDxESVYgYWxpZ249bGVmdD48Rk9OVCBmYWNlPUFyaWFs IGNvbG9yPSMwMDQwODAgDQogIHNpemU9Mj48U1RST05HPlJlZ2FyZHMsPC9TVFJPTkc+PC9GT05U PjwvRElWPg0KICA8RElWIGFsaWduPWxlZnQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDA0MDgw IHNpemU9Mj48U1RST05HPkJoYXZpayANCiAgQ2hhdWhhbjwvU1RST05HPjwvRk9OVD48L0RJVj4N CiAgPERJViBhbGlnbj1sZWZ0PjxTVFJPTkc+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDA0MDgw IA0KICBzaXplPTI+PC9GT05UPjwvU1RST05HPiZuYnNwOzwvRElWPg0KICA8RElWIGFsaWduPWxl ZnQ+PFNQQU4gY2xhc3M9NDgzMDYzMDE1LTIzMDUyMDA1PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9 IzAwNDA4MCANCiAgc2l6ZT0yPjxTVFJPTkc+TW90b3JvbGEgSW5kaWEgRWxldHJvbmljcyBQdnQg DQogIEx0ZC48L1NUUk9ORz48L0ZPTlQ+PC9TUEFOPjwvRElWPjwvRElWPg0KICA8RElWPjxGT05U IGZhY2U9QXJpYWwgY29sb3I9IzAwODA4MCANCnNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+PC9C TE9DS1FVT1RFPjwvQk9EWT48L0hUTUw+DQo= ------_=_NextPart_001_01C5650B.0149390E-- --===============1433335013== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1433335013==-- From sip-bounces@ietf.org Mon May 30 08:43:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcjcR-0007yI-U3; Mon, 30 May 2005 08:43:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcjcM-0007y0-IA for sip@megatron.ietf.org; Mon, 30 May 2005 08:43:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11632 for ; Mon, 30 May 2005 08:43:40 -0400 (EDT) Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dcjvl-00089f-Pj for sip@ietf.org; Mon, 30 May 2005 09:03:46 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id j4UCmxYP025503 for ; Mon, 30 May 2005 05:48:59 -0700 (MST) Received: from zin24exm01.ap.mot.com (zin24exm01.ap.mot.com [10.232.25.1]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id j4UCkENQ021114 for ; Mon, 30 May 2005 07:46:16 -0500 (CDT) Received: by zin24exm01.ap.mot.com with Internet Mail Service (5.5.2657.72) id ; Mon, 30 May 2005 18:13:32 +0530 Message-ID: <772BCEF88A1DD91191F80011856715F30357A305@zin24exm01.ap.mot.com> From: Chadha Retesh-A19894 To: Chauhan Bhavik-A20762 , sip@ietf.org, sip-implementors@cs.columbia.edu Subject: RE: [Sip] RE: 100rel and early-session option tags (RFC 3959) Date: Mon, 30 May 2005 18:13:27 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 2.7 (++) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0805087849==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org 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. --===============0805087849== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C56515.2D3ECD3A" 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_01C56515.2D3ECD3A Content-Type: text/plain I think early-session in REQUIRE, doesnt mandate 100rel. But also, early-session without PRACK surely doesnt make sense, as then how will the answer to 1xx(for early session) go. UPDATE?? Rgds Retesh -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Chauhan Bhavik-A20762 Sent: Monday, May 30, 2005 5:01 PM To: sip@ietf.org; sip-implementors@cs.columbia.edu Subject: [Sip] RE: 100rel and early-session option tags (RFC 3959) Resending it. Any comments on this? Thanks, Bhavik -----Original Message----- From: Chauhan Bhavik-A20762 Sent: Tuesday, May 24, 2005 10:53 AM To: sip@ietf.org Subject: 100rel and early-session option tags (RFC 3959) Hi, With Reference to RFC 3959 section 6, I think "early-session" option tag must be accompanied "100rel" if it is in "Require" header to indicate "Reliability of Provisional Response" support as I didn't find any relationship cited in RFCs. Does "early-session" implicitly indicate that? If not then, 1. A B ---INVITE(Require: early-session) ----> (INVITE is without 100rel option) As 100rel is not there what will be response from B? 2. A B ----INVITE(Supported: early-session) with OFFER ----> <---- 180 Reliable with early-offer & ANSWER---- (INVITE is without 100rel option ) What will be response from A as no 100rel supported? Regards, Bhavik Chauhan Motorola India Eletronics Pvt Ltd. ------_=_NextPart_001_01C56515.2D3ECD3A Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KPFRJVExFPk1lc3NhZ2U8L1RJVExF Pg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yODAwLjE0NzkiIG5hbWU9R0VORVJBVE9S PjwvSEVBRD4NCjxCT0RZPg0KPERJVj48U1BBTiBjbGFzcz03MDkxMzIyMTItMzAwNTIwMDU+PEZP TlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj5JIA0KdGhpbmsgZWFybHktc2Vzc2lv biBpbiBSRVFVSVJFLCBkb2VzbnQgbWFuZGF0ZSAxMDByZWwuIDwvRk9OVD48L1NQQU4+PC9ESVY+ DQo8RElWPjxTUEFOIGNsYXNzPTcwOTEzMjIxMi0zMDA1MjAwNT48L1NQQU4+PFNQQU4gY2xhc3M9 NzA5MTMyMjEyLTMwMDUyMDA1PjxGT05UIA0KZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9 Mj5CdXQgYWxzbywgZWFybHktc2Vzc2lvbiB3aXRob3V0IFBSQUNLIHN1cmVseSANCmRvZXNudCBt YWtlIHNlbnNlLCBhcyB0aGVuIGhvdyB3aWxsIHRoZSBhbnN3ZXIgdG8gMXh4KGZvciBlYXJseSAN CnNlc3Npb24pJm5ic3A7Z28uIFVQREFURT8/PC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQ QU4gY2xhc3M9NzA5MTMyMjEyLTMwMDUyMDA1PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBm ZiANCnNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJVj48U1BBTiBjbGFzcz03 MDkxMzIyMTItMzAwNTIwMDU+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0Kc2l6ZT0y PlJnZHM8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBjbGFzcz03MDkxMzIyMTItMzAw NTIwMDU+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0Kc2l6ZT0yPlJldGVzaDwvRk9O VD48L1NQQU4+PC9ESVY+DQo8QkxPQ0tRVU9URSBkaXI9bHRyIHN0eWxlPSJNQVJHSU4tUklHSFQ6 IDBweCI+DQogIDxESVY+PC9ESVY+DQogIDxESVYgY2xhc3M9T3V0bG9va01lc3NhZ2VIZWFkZXIg bGFuZz1lbi11cyBkaXI9bHRyIGFsaWduPWxlZnQ+PEZPTlQgDQogIGZhY2U9VGFob21hIHNpemU9 Mj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxCUj48Qj5Gcm9tOjwvQj4gDQogIHNpcC1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86c2lwLWJvdW5jZXNAaWV0Zi5vcmddIDxCPk9uIEJlaGFsZiBP ZiA8L0I+Q2hhdWhhbiANCiAgQmhhdmlrLUEyMDc2MjxCUj48Qj5TZW50OjwvQj4gTW9uZGF5LCBN YXkgMzAsIDIwMDUgNTowMSBQTTxCUj48Qj5Ubzo8L0I+IA0KICBzaXBAaWV0Zi5vcmc7IHNpcC1p bXBsZW1lbnRvcnNAY3MuY29sdW1iaWEuZWR1PEJSPjxCPlN1YmplY3Q6PC9CPiBbU2lwXSBSRTog DQogIDEwMHJlbCBhbmQgZWFybHktc2Vzc2lvbiBvcHRpb24gdGFncyAoUkZDIDM5NTkpPEJSPjxC Uj48L0ZPTlQ+PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9MjQyNTkyNDExLTMwMDUyMDA1PjxG T05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCiAgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5i c3A7PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9MjQyNTkyNDExLTMwMDUyMDA1PjxGT05UIGZh Y2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCiAgc2l6ZT0yPlJlc2VuZGluZyBpdC4gQW55IGNvbW1l bnRzIG9uIHRoaXM/PC9GT05UPjwvU1BBTj48L0RJVj4NCiAgPERJVj48U1BBTiBjbGFzcz0yNDI1 OTI0MTEtMzAwNTIwMDU+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0KICBzaXplPTI+ PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgPERJViBhbGlnbj1sZWZ0PjxGT05UIGZhY2U9 VmVyZGFuYT48Rk9OVCBjb2xvcj0jMDA0MDgwPjxGT05UIHNpemU9Mj48U1BBTiANCiAgY2xhc3M9 MjQyNTkyNDExLTMwMDUyMDA1PlRoYW5rcyw8L1NQQU4+PC9GT05UPjwvRk9OVD48L0ZPTlQ+PC9E SVY+DQogIDxESVYgYWxpZ249bGVmdD48Rk9OVCBmYWNlPVZlcmRhbmE+PEZPTlQgY29sb3I9IzAw NDA4MD48Rk9OVCBzaXplPTI+PFNQQU4gDQogIGNsYXNzPTI0MjU5MjQxMS0zMDA1MjAwNT48L1NQ QU4+QmhhdmlrPC9GT05UPjwvRk9OVD48L0ZPTlQ+PC9ESVY+DQogIDxCTE9DS1FVT1RFIGRpcj1s dHIgc3R5bGU9Ik1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgICA8RElWPjwvRElWPg0KICAgIDxESVYg Y2xhc3M9T3V0bG9va01lc3NhZ2VIZWFkZXIgbGFuZz1lbi11cyBkaXI9bHRyIGFsaWduPWxlZnQ+ PEZPTlQgDQogICAgZmFjZT1UYWhvbWEgc2l6ZT0yPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t PEJSPjxCPkZyb206PC9CPiBDaGF1aGFuIA0KICAgIEJoYXZpay1BMjA3NjIgPEJSPjxCPlNlbnQ6 PC9CPiBUdWVzZGF5LCBNYXkgMjQsIDIwMDUgMTA6NTMgQU08QlI+PEI+VG86PC9CPiANCiAgICBz aXBAaWV0Zi5vcmc8QlI+PEI+U3ViamVjdDo8L0I+IDEwMHJlbCBhbmQgZWFybHktc2Vzc2lvbiBv cHRpb24gdGFncyAoUkZDIA0KICAgIDM5NTkpPEJSPjxCUj48L0ZPTlQ+PC9ESVY+DQogICAgPERJ Vj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJ Vj4NCiAgICA8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwODA4MCBzaXplPTI+PFNQQU4g DQogICAgY2xhc3M9NDgzMDYzMDE1LTIzMDUyMDA1PkhpLDwvU1BBTj48L0ZPTlQ+PC9ESVY+DQog ICAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDgwODAgc2l6ZT0yPjxTUEFOIA0KICAg IGNsYXNzPTQ4MzA2MzAxNS0yMzA1MjAwNT48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KICAg IDxESVY+PFNQQU4gY2xhc3M9NDgzMDYzMDE1LTIzMDUyMDA1PjxGT05UIGZhY2U9QXJpYWwgY29s b3I9IzAwODA4MCANCiAgICBzaXplPTI+PEZPTlQgY29sb3I9IzAwMDBmZj48U1BBTiBjbGFzcz03 NzQyMjIxMDUtMjQwNTIwMDU+PEZPTlQgDQogICAgY29sb3I9IzAwODA4MD5XaXRoIFJlZmVyZW5j ZTwvRk9OVD48L1NQQU4+PC9GT05UPiB0byZuYnNwO1JGQyAzOTU5IHNlY3Rpb24gDQogICAgNiw8 L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICAgIDxESVY+PFNQQU4gY2xhc3M9NDgzMDYzMDE1LTIzMDUy MDA1PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwODA4MCANCiAgICBzaXplPTI+PC9GT05UPjwv U1BBTj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPjxTUEFOIGNsYXNzPTQ4MzA2MzAxNS0yMzA1MjAw NT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDgwODAgDQogICAgc2l6ZT0yPjxTUEFOIGNsYXNz PTQ4MzA2MzAxNS0yMzA1MjAwNT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDgwODAgDQogICAg c2l6ZT0yPkkgdGhpbmsgImVhcmx5LXNlc3Npb24iIG9wdGlvbiB0YWcmbmJzcDttdXN0IGJlIGFj Y29tcGFuaWVkICIxMDByZWwiIA0KICAgIGlmIGl0IGlzJm5ic3A7aW4gIlJlcXVpcmUiIGhlYWRl cjwvRk9OVD48L1NQQU4+PC9ESVY+DQogICAgPERJVj4NCiAgICA8RElWPjxTUEFOIGNsYXNzPTQ4 MzA2MzAxNS0yMzA1MjAwNT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDgwODAgDQogICAgc2l6 ZT0yPnRvJm5ic3A7aW5kaWNhdGUgIlJlbGlhYmlsaXR5IG9mIFByb3Zpc2lvbmFsIFJlc3BvbnNl IiANCiAgICBzdXBwb3J0PC9GT05UPjwvU1BBTj48U1BBTiBjbGFzcz00ODMwNjMwMTUtMjMwNTIw MDU+PEZPTlQgZmFjZT1BcmlhbCANCiAgICBjb2xvcj0jMDA4MDgwIHNpemU9Mj4gYXMgSSBkaWRu J3QgZmluZCBhbnkgcmVsYXRpb25zaGlwIGNpdGVkIA0KICAgIDwvRk9OVD48L1NQQU4+PC9ESVY+ DQogICAgPERJVj48U1BBTiBjbGFzcz00ODMwNjMwMTUtMjMwNTIwMDU+PEZPTlQgZmFjZT1Bcmlh bCBjb2xvcj0jMDA4MDgwIHNpemU9Mj5pbiANCiAgICBSRkNzLiA8L0ZPTlQ+PC9TUEFOPjwvRElW Pg0KICAgIDxESVY+PFNQQU4gY2xhc3M9NDgzMDYzMDE1LTIzMDUyMDA1PjxGT05UIGZhY2U9QXJp YWwgY29sb3I9IzAwMDBmZiANCiAgICBzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4N CiAgICA8RElWPjxTUEFOIGNsYXNzPTQ4MzA2MzAxNS0yMzA1MjAwNT48Rk9OVCBmYWNlPUFyaWFs IGNvbG9yPSMwMDgwODAgDQogICAgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyBEb2VzICJlYXJs eS1zZXNzaW9uIiBpbXBsaWNpdGx5IGluZGljYXRlIA0KICAgIHRoYXQ/PC9GT05UPjwvU1BBTj48 L0RJVj4NCiAgICA8RElWPjxTUEFOIGNsYXNzPTQ4MzA2MzAxNS0yMzA1MjAwNT48Rk9OVCANCiAg ICBjb2xvcj0jMDAwMGZmPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogICAgPERJVj48U1BB TiBjbGFzcz00ODMwNjMwMTUtMjMwNTIwMDU+SWYgbm90IA0KICAgIHRoZW4sPC9TUEFOPjwvRElW PjwvRk9OVD48L1NQQU4+PC9ESVY+DQogICAgPERJVj48U1BBTiBjbGFzcz00ODMwNjMwMTUtMjMw NTIwMDU+PC9TUEFOPjxTUEFOIA0KICAgIGNsYXNzPTQ4MzA2MzAxNS0yMzA1MjAwNT48Rk9OVCBm YWNlPUFyaWFsIGNvbG9yPSMwMDgwODAgDQogICAgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7 PC9ESVY+DQogICAgPERJVj48U1BBTiBjbGFzcz00ODMwNjMwMTUtMjMwNTIwMDU+PEZPTlQgZmFj ZT1BcmlhbCBjb2xvcj0jMDA4MDgwIA0KICAgIHNpemU9Mj4xLjwvRk9OVD48L1NQQU4+PC9ESVY+ DQogICAgPERJVj48U1BBTiBjbGFzcz00ODMwNjMwMTUtMjMwNTIwMDU+PEZPTlQgZmFjZT1Bcmlh bCBjb2xvcj0jMDA4MDgwIA0KICAgIHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgDQogICAgQSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgICBC PC9GT05UPjwvU1BBTj48L0RJVj4NCiAgICA8RElWPjxTUEFOIGNsYXNzPTQ4MzA2MzAxNS0yMzA1 MjAwNT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDgwODAgDQogICAgc2l6ZT0yPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy0tLUlOVklURShSZXF1aXJlOiZuYnNw O2Vhcmx5LXNlc3Npb24pJm5ic3A7LS0tLSZndDs8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICAgIDxE SVY+PFNQQU4gY2xhc3M9NDgzMDYzMDE1LTIzMDUyMDA1PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9 IzAwODA4MCBzaXplPTI+DQogICAgPERJVj48U1BBTiBjbGFzcz00ODMwNjMwMTUtMjMwNTIwMDU+ PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDA4MDgwIA0KICAgIHNpemU9Mj48U1BBTiBjbGFzcz00 ODMwNjMwMTUtMjMwNTIwMDU+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDA4MDgwIA0KICAgIHNp emU9Mj48U1BBTiBjbGFzcz00ODMwNjMwMTUtMjMwNTIwMDU+PEZPTlQgZmFjZT1BcmlhbCBjb2xv cj0jMDAwMGZmIA0KICAgIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPjwvRk9OVD48L1NQQU4+PC9GT05U PjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPjxTUEFOIGNsYXNzPTQ4MzA2MzAxNS0yMzA1 MjAwNT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDgwODAgDQogICAgc2l6ZT0yPjxTUEFOIGNs YXNzPTQ4MzA2MzAxNS0yMzA1MjAwNT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDgwODAgDQog ICAgc2l6ZT0yPjxTUEFOIGNsYXNzPTQ4MzA2MzAxNS0yMzA1MjAwNT48Rk9OVCBmYWNlPUFyaWFs IGNvbG9yPSMwMDgwODAgDQogICAgc2l6ZT0yPihJTlZJVEUgaXMgd2l0aG91dCAxMDByZWwgDQog ICAgb3B0aW9uKTwvRk9OVD48L1NQQU4+PC9GT05UPjwvU1BBTj48L0ZPTlQ+PC9TUEFOPjwvRElW PjwvRk9OVD48L1NQQU4+PC9ESVY+DQogICAgPERJVj48U1BBTiBjbGFzcz00ODMwNjMwMTUtMjMw NTIwMDU+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDA4MDgwIHNpemU9Mj5BcyANCiAgICAxMDBy ZWwgaXMgbm90IHRoZXJlIHdoYXQgd2lsbCBiZSByZXNwb25zZSBmcm9tIEI/PC9GT05UPjwvU1BB Tj48L0RJVj4NCiAgICA8RElWPjxTUEFOIGNsYXNzPTQ4MzA2MzAxNS0yMzA1MjAwNT48Rk9OVCBm YWNlPUFyaWFsIGNvbG9yPSMwMDgwODAgDQogICAgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7 PC9ESVY+DQogICAgPERJVj48U1BBTiBjbGFzcz00ODMwNjMwMTUtMjMwNTIwMDU+PEZPTlQgZmFj ZT1BcmlhbCBjb2xvcj0jMDA4MDgwIHNpemU9Mj4NCiAgICA8RElWPjxTUEFOIGNsYXNzPTQ4MzA2 MzAxNS0yMzA1MjAwNT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDgwODAgDQogICAgc2l6ZT0y PjIuJm5ic3A7Jm5ic3A7Jm5ic3A7PC9GT05UPjwvU1BBTj48L0RJVj4NCiAgICA8RElWPjxTUEFO IGNsYXNzPTQ4MzA2MzAxNS0yMzA1MjAwNT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDgwODAg DQogICAgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgICAmbmJzcDtB Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IA0KICAgIEI8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICAgIDxESVY+PFNQ QU4gY2xhc3M9NDgzMDYzMDE1LTIzMDUyMDA1PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwODA4 MCANCiAgICBzaXplPTI+Jm5ic3A7Jm5ic3A7IC0tLS1JTlZJVEUoU3VwcG9ydGVkOiZuYnNwO2Vh cmx5LXNlc3Npb24pIHdpdGggDQogICAgT0ZGRVImbmJzcDstLS0tJmd0OzwvRk9OVD48L1NQQU4+ PC9ESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDstLS0tIDE4MCANCiAgICBSZWxpYWJs ZSB3aXRoIGVhcmx5LW9mZmVyICZhbXA7Jm5ic3A7QU5TV0VSLS0tLTwvRk9OVD48L1NQQU4+PC9E SVY+DQogICAgPERJVj48U1BBTiBjbGFzcz00ODMwNjMwMTUtMjMwNTIwMDU+PEZPTlQgZmFjZT1B cmlhbCBjb2xvcj0jMDA4MDgwIA0KICAgIHNpemU9Mj48U1BBTiBjbGFzcz00ODMwNjMwMTUtMjMw NTIwMDU+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDA4MDgwIA0KICAgIHNpemU9Mj48U1BBTiBj bGFzcz00ODMwNjMwMTUtMjMwNTIwMDU+DQogICAgPERJVj48U1BBTiBjbGFzcz00ODMwNjMwMTUt MjMwNTIwMDU+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDA4MDgwIA0KICAgIHNpemU9Mj48U1BB TiBjbGFzcz00ODMwNjMwMTUtMjMwNTIwMDU+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDA4MDgw IA0KICAgIHNpemU9Mj48U1BBTiBjbGFzcz00ODMwNjMwMTUtMjMwNTIwMDU+PEZPTlQgZmFjZT1B cmlhbCBjb2xvcj0jMDAwMGZmIA0KICAgIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPjwvRk9OVD48L1NQ QU4+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPjxTUEFOIGNsYXNzPTQ4MzA2 MzAxNS0yMzA1MjAwNT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDgwODAgDQogICAgc2l6ZT0y PjxTUEFOIGNsYXNzPTQ4MzA2MzAxNS0yMzA1MjAwNT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMw MDgwODAgDQogICAgc2l6ZT0yPjxTUEFOIGNsYXNzPTQ4MzA2MzAxNS0yMzA1MjAwNT48Rk9OVCBm YWNlPUFyaWFsIGNvbG9yPSMwMDgwODAgDQogICAgc2l6ZT0yPihJTlZJVEUgaXMgd2l0aG91dCAx MDByZWwgb3B0aW9uIA0KICAgICk8L0ZPTlQ+PC9TUEFOPjwvRk9OVD48L1NQQU4+PC9GT05UPjwv U1BBTj48L0RJVj48L1NQQU4+PC9GT05UPjwvU1BBTj48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICAg IDxESVY+PFNQQU4gY2xhc3M9NDgzMDYzMDE1LTIzMDUyMDA1PjxGT05UIGZhY2U9QXJpYWwgY29s b3I9IzAwODA4MCANCiAgICBzaXplPTI+V2hhdCB3aWxsIGJlIHJlc3BvbnNlIGZyb20gQSBhcyBu byAxMDByZWwgDQogICAgc3VwcG9ydGVkPzwvRk9OVD48L1NQQU4+PC9ESVY+DQogICAgPERJVj48 U1BBTiBjbGFzcz00ODMwNjMwMTUtMjMwNTIwMDU+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDA4 MDgwIA0KICAgIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KICAgIDxESVY+PFNQ QU4gY2xhc3M9NDgzMDYzMDE1LTIzMDUyMDA1PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwODA4 MCANCiAgICBzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgICA8RElWIGFsaWdu PWxlZnQ+DQogICAgPERJViBhbGlnbj1sZWZ0PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwNDA4 MCANCiAgICBzaXplPTI+PFNUUk9ORz5SZWdhcmRzLDwvU1RST05HPjwvRk9OVD48L0RJVj4NCiAg ICA8RElWIGFsaWduPWxlZnQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDA0MDgwIHNpemU9Mj48 U1RST05HPkJoYXZpayANCiAgICBDaGF1aGFuPC9TVFJPTkc+PC9GT05UPjwvRElWPg0KICAgIDxE SVYgYWxpZ249bGVmdD48U1RST05HPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwNDA4MCANCiAg ICBzaXplPTI+PC9GT05UPjwvU1RST05HPiZuYnNwOzwvRElWPg0KICAgIDxESVYgYWxpZ249bGVm dD48U1BBTiBjbGFzcz00ODMwNjMwMTUtMjMwNTIwMDU+PEZPTlQgZmFjZT1BcmlhbCANCiAgICBj b2xvcj0jMDA0MDgwIHNpemU9Mj48U1RST05HPk1vdG9yb2xhIEluZGlhIEVsZXRyb25pY3MgUHZ0 IA0KICAgIEx0ZC48L1NUUk9ORz48L0ZPTlQ+PC9TUEFOPjwvRElWPjwvRElWPg0KICAgIDxESVY+ PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDA4MDgwIA0Kc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJ Vj48L0JMT0NLUVVPVEU+PC9CTE9DS1FVT1RFPjwvQk9EWT48L0hUTUw+DQo= ------_=_NextPart_001_01C56515.2D3ECD3A-- --===============0805087849== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0805087849==-- From sip-bounces@ietf.org Tue May 31 00:53:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dcyku-0002YE-JT; Tue, 31 May 2005 00:53:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dcykm-0002Y4-8Z for sip@megatron.ietf.org; Tue, 31 May 2005 00:53:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13912 for ; Tue, 31 May 2005 00:53:20 -0400 (EDT) Received: from rproxy.gmail.com ([64.233.170.196]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dcz4J-0001EI-Fz for sip@ietf.org; Tue, 31 May 2005 01:13:36 -0400 Received: by rproxy.gmail.com with SMTP id i8so1639523rne for ; Mon, 30 May 2005 21:53:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YC7JkqWbT+KobKjkHT9owctO/jkw3BFG9/M8XkkLdRb9NqkT4uqQF0PFgoV3ZkxfU/JknWZeZKHEBdSzWMUS6qVUpgw2XWIhypOnYn4yIG4NWkM7S38VVxhb79ZI6bOeICpCLUpgklGQSwHDi8Gy1aLan90Ub1lcjRKkqdoG7f8= Received: by 10.38.92.63 with SMTP id p63mr79963rnb; Mon, 30 May 2005 21:53:21 -0700 (PDT) Received: by 10.38.11.59 with HTTP; Mon, 30 May 2005 21:53:21 -0700 (PDT) Message-ID: <3fe6b86405053021532bf47594@mail.gmail.com> Date: Tue, 31 May 2005 10:23:21 +0530 From: Malleswara Rao Ankem To: Chadha Retesh-A19894 Subject: Re: [Sip] RE: 100rel and early-session option tags (RFC 3959) In-Reply-To: <772BCEF88A1DD91191F80011856715F30357A305@zin24exm01.ap.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <772BCEF88A1DD91191F80011856715F30357A305@zin24exm01.ap.mot.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, sip-implementors@cs.columbia.edu X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Malleswara Rao Ankem List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I guess the RFC 3959 completely misses out whether the "100rel" in required in the Require/Supported headers. I think 3959 is very much dependent on the RFC 3262 which it doesnot explicitly say so.=20 May be the Author of the RFC 3959 can clarify the same.=20 regards On 5/30/05, Chadha Retesh-A19894 wrote: > I think early-session in REQUIRE, doesnt mandate 100rel.=20 > But also, early-session without PRACK surely doesnt make sense, as then h= ow > will the answer to 1xx(for early session) go. UPDATE?? > =20 > Rgds > Retesh >=20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Chauhan Bhavik-A20762 > Sent: Monday, May 30, 2005 5:01 PM > To: sip@ietf.org; sip-implementors@cs.columbia.edu > Subject: [Sip] RE: 100rel and early-session option tags (RFC 3959) >=20 > =20 > Resending it. Any comments on this? > =20 > Thanks, > Bhavik >=20 > -----Original Message----- > From: Chauhan Bhavik-A20762=20 > Sent: Tuesday, May 24, 2005 10:53 AM > To: sip@ietf.org > Subject: 100rel and early-session option tags (RFC 3959) >=20 > =20 > Hi, > =20 > With Reference to RFC 3959 section 6, > =20 > I think "early-session" option tag must be accompanied "100rel" if it is = in > "Require" header > to indicate "Reliability of Provisional Response" support as I didn't fin= d > any relationship cited=20 > in RFCs.=20 > =20 > Does "early-session" implicitly indicate that? > =20 > If not then, > =20 > 1. > A =20 > B > ---INVITE(Require: early-session) ----> > =20 > (INVITE is without 100rel option) > As 100rel is not there what will be response from B? > =20 > 2. =20 > A =20 > B > ----INVITE(Supported: early-session) with OFFER ----> =20 > <---- 180 Reliable with early-offer & ANSWER---- > =20 > (INVITE is without 100rel option ) > What will be response from A as no 100rel supported? > =20 > =20 > Regards, > Bhavik Chauhan > =20 > Motorola India Eletronics Pvt Ltd. > =20 > _______________________________________________ > Sip mailing list=20 > https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on > current sip > Use sipping@ietf.org for new developments on the application of sip >=20 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 31 15:42:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdCdM-0005tl-7y; Tue, 31 May 2005 15:42:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdCdJ-0005tg-Th for sip@megatron.ietf.org; Tue, 31 May 2005 15:42:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11688 for ; Tue, 31 May 2005 15:42:35 -0400 (EDT) Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdCwx-00061a-HP for sip@ietf.org; Tue, 31 May 2005 16:02:57 -0400 Received: from keywest (hide.pingtel.com [65.220.123.2]) by mail.pingtel.com (Postfix) with SMTP id 5AE4A6C017; Tue, 31 May 2005 15:42:21 -0400 (EDT) From: "Dale Worley" To: , Date: Tue, 31 May 2005 15:40:50 -0400 Message-ID: <01a801c56618$a6ff13b0$6a01010a@keywest> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_01A9_01C565F7.1FED73B0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-MS-TNEF-Correlator: 0000000086BE11490398134F8F750E4364F87F8204B53900 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: Subject: [Sip] RE: [Sip-implementors] About Invite Server transaction X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_01A9_01C565F7.1FED73B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > From: Anil Bollineni > > Assume 100, 200 responses are sent from UAS to client, and > they are lost. Then INVITE is retransmitted to UAS. As soon > as UAS send > 200 OK it destroys the server transaction. Per UAS, the > dialog state is > already created after sending 200 response. If INVITE is passed to TU > from transport layer, then how this INVITE is been treated as > retransmission of INVITE, since the TU, will not able to match any > existing dialog (since no to-tag in INVITE), and will it > treat as a new > call. Is the assumption correct? Or where in RFC this scenario will be > treated. I believe that the correct handling is that the transport layer will discover that it is a retransmission of the original INVITE because of the Via branch-parameter, etc. So the transport layer will re-send its 200 response, and not notify the TU. Dale ------=_NextPart_000_01A9_01C565F7.1FED73B0 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IjMTAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANUHBQAfAA8AKAAAAAIAOQEB A5AGALgHAAApAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAA AAAAHgBwAAEAAAAzAAAAW1NpcC1pbXBsZW1lbnRvcnNdIEFib3V0IEludml0ZSBTZXJ2ZXIgdHJh bnNhY3Rpb24AAAIBcQABAAAAFgAAAAHFZhil33Khfyf2PUvzgiExJsEpKVUAAAIBHQwBAAAAGQAA AFNNVFA6RFdPUkxFWUBQSU5HVEVMLkNPTQAAAAALAAEOAAAAAEAABg4AqC+IGGbFAQIBCg4BAAAA GAAAAAAAAACGvhFJA5gTT491DkNk+H+CwoAAAAMAFA4BAAAACwAfDgEAAAACAQkQAQAAAOwCAADo AgAAuwQAAExaRnXbOV2LAwAKAHJjcGcxMjXiMgNDdGV4BUEBAwH3/wqAAqQD5AcTAoAP8wBQBFY/ CFUHshElDlEDAQIAY2jhCsBzZXQyBgAGwxEl9jMERhO3MBIsETMI7wn3tjsYHw4wNREiDGBjAFAz CwkBZDM2FlALpiA+tCBGA2E6EMADAkIG8P5sC4AJ8ACgCrEKgBzwHlYKQQQQdQeAIDEwMJwsIAHQ FlAYIHNwAiC/FBAEIArAH6AUEAIwIANSCCBVQQXwdG8gYz8d8CFBH/AAcAsxHnR0aAxleSDjF7Bz dC4gBlQjgAOgSU5WSVRMRSAEACBBdHIAcW3+aQJACYAiAiHRJEAfUCEg9m8CIB7HYQQgIdIhMSLn +SAST0slEAVAAQAkIANgznkEICNxISFydhKBJXPZANB0aQIgJEBQEoEh0Zcf8CoSHlZkBzFvZyEg LwGQDrAlESc3bBggYWTvI6AFAC6AJfJhAYASgSgizwuALTAgGiRASWYkqQqw8wQQJgRUVR5WIYMl cyCAcwAgI/BheQSQLAMDoGjebwfgI3AlISS4YgnhKrGfLvUtxyVXBBArQSBvMSbzH/AAkG5jH6Aq EjKAH/DDA/Ad4CAgbm8FQAGgbmw5USIgAMB0E9AisXm/HlYOwAQAKzAwASzlKDkUezpQIgEtAZAt MAuAJKUpvyKjOeQpUSL3LuInomE6QOsH0B5WYwdAbDDxKfQx8b8fgAUwOCIFoRggKyA/KRAdBcB3 I4AhAT4xUkZD/zUEBPAJ8ArAK0A55DYAP7vtCYAuHlQeVEk18SJRKoD/I2FAYSoSQxU0wCLBHfE+ Eb8p8kh1M3055CzgBPBvKoN/SGIpUSUhQMA3fyoDBbBpvmcLgAdAJKY2AEGQdRQQvU5GVgcwNfAl gRPQLQqx3mEHgC9xH/AUIGMkQAYA7z2hSo9LlRggLSgiKUEEIP8gGj7UOlI6UQaQI6A5dEbrFkQH QEXlfVigHgBCEAEAAAA5AAAAPEYwN0YxN0I2MUI3RkY1NDVCQzdEN0U0QkZCRTE1RDJBRTdGQkND QGhhZHJvbi5qbnByLm5ldD4AAAAAAwAJWQEAAAADAAFuIAAAAAsAAIAIIAYAAAAAAMAAAAAAAABG AAAAAAOFAAAAAAAAAwACgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADAAeACCAGAAAAAADA AAAAAAAARgAAAABShQAAJ2oBAB4ACYAIIAYAAAAAAMAAAAAAAABGAAAAAFSFAAABAAAABAAAADku MAAeAAqACCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgALgAggBgAAAAAAwAAA AAAAAEYAAAAAN4UAAAEAAAABAAAAAAAAAB4ADIAIIAYAAAAAAMAAAAAAAABGAAAAADiFAAABAAAA AQAAAAAAAAALABGACCAGAAAAAADAAAAAAAAARgAAAAAGhQAAAAAAAAMAEoAIIAYAAAAAAMAAAAAA AABGAAAAAAGFAAAAAAAACwAbgAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADAByACCAGAAAA AADAAAAAAAAARgAAAAARhQAAAAAAAAMAHoAIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAAAgH4 DwEAAAAQAAAAhr4RSQOYE0+PdQ5DZPh/ggIB+g8BAAAAEAAAAIa+EUkDmBNPj3UOQ2T4f4ICAfsP AQAAAJUAAAAAAAAAOKG7EAXlEBqhuwgAKypWwgAAbXNwc3QuZGxsAAAAAABOSVRB+b+4AQCqADfZ bgAAAEM6XERvY3VtZW50cyBhbmQgU2V0dGluZ3NcZHdvcmxleVxMb2NhbCBTZXR0aW5nc1xBcHBs aWNhdGlvbiBEYXRhXE1pY3Jvc29mdFxPdXRsb29rXG1haWxib3gucHN0AAAAAAMA/g8FAAAAAwAN NP03AAACAX8AAQAAADEAAAAwMDAwMDAwMDg2QkUxMTQ5MDM5ODEzNEY4Rjc1MEU0MzY0Rjg3Rjgy MDRCNTM5MDAAAAAAAwAGEJI690gDAAcQoQIAAAMAEBABAAAAAwAREAAAAAAeAAgQAQAAAGUAAABG Uk9NOkFOSUxCT0xMSU5FTklBU1NVTUUxMDAsMjAwUkVTUE9OU0VTQVJFU0VOVEZST01VQVNUT0NM SUVOVCxBTkRUSEVZQVJFTE9TVFRIRU5JTlZJVEVJU1JFVFJBTlNNSVRUAAAAABS9 ------=_NextPart_000_01A9_01C565F7.1FED73B0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------=_NextPart_000_01A9_01C565F7.1FED73B0-- From sip-bounces@ietf.org Tue May 31 15:53:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdCoC-00080d-H7; Tue, 31 May 2005 15:53:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdCo9-0007zu-1U; Tue, 31 May 2005 15:53:49 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13201; Tue, 31 May 2005 15:53:47 -0400 (EDT) Message-Id: <200505311953.PAA13201@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 31 May 2005 15:53:47 -0400 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-resource-priority-09.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Communications Resource Priority for the Session Initiation Protocol (SIP) Author(s) : H. Schulzrinne, J. Polk Filename : draft-ietf-sip-resource-priority-09.txt Pages : 36 Date : 2005-5-31 This document defines two new SIP header fields for communicating resource priority, namely "Resource-Priority" and "Accept-Resource- Priority". The "Resource-Priority" header field can influence the behavior of SIP user agents, such as telephone gateways and IP telephones, and SIP proxies. It does not directly influence the forwarding behavior of IP routers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-resource-priority-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-resource-priority-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-resource-priority-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-31155802.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-resource-priority-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-resource-priority-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-31155802.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Tue May 31 18:36:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdFLN-0007Hj-Cf; Tue, 31 May 2005 18:36:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdFLL-0007He-4b for sip@megatron.ietf.org; Tue, 31 May 2005 18:36:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06522 for ; Tue, 31 May 2005 18:36:12 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdFf2-0002Fh-RM for sip@ietf.org; Tue, 31 May 2005 18:56:37 -0400 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j4VMaBmD025505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 31 May 2005 18:36:12 -0400 (EDT) Message-ID: <429CE6D6.4070108@cs.columbia.edu> Date: Tue, 31 May 2005 18:36:06 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Subject: [Sip] Update to draft-ietf-sip-resource-priority X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org http://www.ietf.org/internet-drafts/draft-ietf-sip-resource-priority-09.txt addresses the working group and IETF last-call comments, at least where the authors and the commenter were in agreement (see the flood of messages from the weekend). Hopefully, this update can speed up the resolution of any remaining issues by avoiding discussion of items that have been resolved already. I would appreciate if astute readers could alert me to any omissions or misunderstandings of comments offered. Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip