From exim@www1.ietf.org Fri Jan 2 06:45:01 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27930 for ; Fri, 2 Jan 2004 06:45:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcNjH-00049z-PG for sip-archive@odin.ietf.org; Fri, 02 Jan 2004 06:44:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i02BiZSP015872 for sip-archive@odin.ietf.org; Fri, 2 Jan 2004 06:44:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcNil-00045V-Gf; Fri, 02 Jan 2004 06:44:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcITB-0007lv-GJ for sip@optimus.ietf.org; Fri, 02 Jan 2004 01:07:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04555 for ; Fri, 2 Jan 2004 01:07:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcIT3-0004KC-00 for sip@ietf.org; Fri, 02 Jan 2004 01:07:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcIPk-0004Ga-00 for sip@ietf.org; Fri, 02 Jan 2004 01:04:07 -0500 Received: from web20607.mail.yahoo.com ([216.136.226.165]) by ietf-mx with smtp (Exim 4.12) id 1AcILv-0004BE-00 for sip@ietf.org; Fri, 02 Jan 2004 01:00:08 -0500 Message-ID: <20040102060008.95990.qmail@web20607.mail.yahoo.com> Received: from [219.95.16.90] by web20607.mail.yahoo.com via HTTP; Thu, 01 Jan 2004 22:00:08 PST Date: Thu, 1 Jan 2004 22:00:08 -0800 (PST) From: vvarun kumar To: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Sip] RE:SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , HI, I am ArunKumar a software engineer working on SIP. Please clarify my problem that Iam facing in SIP. The problem can be small or easy to solve but I am unable to find solution. The problem is When I am calling from client to Server like thru SJPhone software(which resembles Phone in daily use) in Windows to a software based in Linux. I am able to recieve trying , ringing message that has been generated by server but Iam not able to get ACK or OK message when Iam capturing thru Ethreal software. How can I debug and how I can get the OK/ACK message and when I am calling from other end point I am getting segementation fault.What could the reason and How to debug it so that I can get ACK/OK message from both ends. Thanks®ards, Arunkumar. __________________________________ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Jan 2 06:45:01 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27932 for ; Fri, 2 Jan 2004 06:45:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcNjH-0004A0-Pe for sip-archive@odin.ietf.org; Fri, 02 Jan 2004 06:44:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i02BiZJg015875 for sip-archive@odin.ietf.org; Fri, 2 Jan 2004 06:44:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcNij-00045J-NQ; Fri, 02 Jan 2004 06:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYkJQ-00027K-3J for sip@optimus.ietf.org; Tue, 23 Dec 2003 06:02:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15599 for ; Tue, 23 Dec 2003 06:02:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYkJM-0000JF-01 for sip@ietf.org; Tue, 23 Dec 2003 06:02:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYkIc-0000Iq-00 for sip@ietf.org; Tue, 23 Dec 2003 06:02:02 -0500 Received: from [203.88.139.151] (helo=qmailserver) by ietf-mx with smtp (Exim 4.12) id 1AYkIa-0000IX-00 for sip@ietf.org; Tue, 23 Dec 2003 06:02:01 -0500 Received: (qmail 20157 invoked from network); 23 Dec 2003 09:45:21 -0000 Received: from unknown (HELO einfochips.com) (192.168.9.170) by 0 with SMTP; 23 Dec 2003 09:45:21 -0000 Message-ID: <3FE8231B.5010102@einfochips.com> Date: Tue, 23 Dec 2003 16:42:27 +0530 From: Chirag Dhruv User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org, dromasca@avaya.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] sip standard related query Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi I am new to SIP and in the process of feasibility study for SIP. I went through a lot of material on the web, and failed to understand if there is a common standard for SIP protocol or not. I understand that RFC2543 is the latest starndard available till now, and if I implement that standard in my device, there is no need to implement other standards. Looking for a response. Thanks and Regards, Chirag. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Jan 2 07:02:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03047 for ; Fri, 2 Jan 2004 07:02:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcO0E-0004uV-0E for sip-archive@odin.ietf.org; Fri, 02 Jan 2004 07:02:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i02C25eu018866 for sip-archive@odin.ietf.org; Fri, 2 Jan 2004 07:02:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcO09-0004tL-Uv; Fri, 02 Jan 2004 07:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcNza-0004sX-A1 for sip@optimus.ietf.org; Fri, 02 Jan 2004 07:01:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03021 for ; Fri, 2 Jan 2004 07:01:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcNzR-00021G-00 for sip@ietf.org; Fri, 02 Jan 2004 07:01:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcNvM-0001nH-00 for sip@ietf.org; Fri, 02 Jan 2004 06:57:07 -0500 Received: from mta2.huawei.com ([61.144.161.24] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1AcNtL-0001fs-00 for sip@ietf.org; Fri, 02 Jan 2004 06:55:03 -0500 Received: from huawei.com (localhost [127.0.0.1]) by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTP id <0HQV001HM2GI4U@mta2.huawei.com> for sip@ietf.org; Fri, 02 Jan 2004 19:55:30 +0800 (CST) Received: from mailin.huawei.com ([10.18.1.252]) by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTP id <0HQV001RU2GHW2@mta2.huawei.com> for sip@ietf.org; Fri, 02 Jan 2004 19:55:30 +0800 (CST) Received: from Shambhudrcl1069 ([10.18.5.66]) by mailin.huawei.com (Netscape Messaging Server 4.15) with ESMTP id HQV2LD00.30W; Fri, 02 Jan 2004 19:58:25 +0800 Date: Fri, 02 Jan 2004 17:17:13 +0530 From: shambhu Subject: RE: [Sip] sip standard related query In-reply-to: <3FE8231B.5010102@einfochips.com> To: "'Chirag Dhruv'" , sip@ietf.org, dromasca@avaya.com Reply-to: shambhudr@huawei.com Message-id: <000501c3d126$2ac9b350$4205120a@in.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hi Chirag, RFC 2543 has been obsoleted by RFC 3261. rfc 3261 specifies base protocol. There are some drafts and rfcs extending the same for specific features. Regards, Shambhu Regards, Shambhu -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Chirag Dhruv Sent: Tuesday, 23 December 2003 4:42 PM To: sip@ietf.org; dromasca@avaya.com Subject: [Sip] sip standard related query Hi I am new to SIP and in the process of feasibility study for SIP. I went through a lot of material on the web, and failed to understand if there is a common standard for SIP protocol or not. I understand that RFC2543 is the latest starndard available till now, and if I implement that standard in my device, there is no need to implement other standards. Looking for a response. Thanks and Regards, Chirag. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Jan 2 11:23:48 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14349 for ; Fri, 2 Jan 2004 11:23:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcS52-0005ta-Ev for sip-archive@odin.ietf.org; Fri, 02 Jan 2004 11:23:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i02GNKXb022658 for sip-archive@odin.ietf.org; Fri, 2 Jan 2004 11:23:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcS4k-0005sr-0c; Fri, 02 Jan 2004 11:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcS4T-0005sa-AC for sip@optimus.ietf.org; Fri, 02 Jan 2004 11:22:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14334 for ; Fri, 2 Jan 2004 11:22:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcS4I-0007Wa-00 for sip@ietf.org; Fri, 02 Jan 2004 11:22:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcS0I-0007LV-00 for sip@ietf.org; Fri, 02 Jan 2004 11:18:29 -0500 Received: from mailgate.siemenscomms.co.uk ([194.129.217.115]) by ietf-mx with esmtp (Exim 4.12) id 1AcRur-00076r-00 for SIP@ietf.org; Fri, 02 Jan 2004 11:12:49 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0HQV00501E9NZV@siemenscomms.co.uk> for SIP@ietf.org; Fri, 02 Jan 2004 16:10:35 +0000 (GMT) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0HQV0052ME9NY8@siemenscomms.co.uk> for SIP@ietf.org; Fri, 02 Jan 2004 16:10:35 +0000 (GMT) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id ; Fri, 02 Jan 2004 16:11:43 +0000 Content-return: allowed Date: Fri, 02 Jan 2004 16:10:57 +0000 From: "Elwell, John" To: SIP@ietf.org Message-id: <50B1CBA96870A34799A506B2313F2667D4AA53@ntht201e> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Subject: [Sip] Use of P-Asserted-Identity in a response Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT There seem to be some differences of opinion concerning the use of P-Asserted-Identity (PAI) in a response. In particular, this is delaying the progress of draft-ietf-sipping-qsig2sip, which makes use of PAI in a 200 OK to convey the connected party identity received from the QSIG network. The same situation is likely to be encountered when interworking with other legacy signalling systems. It is my opinion that PAI can be used in a 200 OK to assert the identity of the connect party. Moreover, it can be inserted by a gateway UAS and, unless subject to privacy, can be passed on even to untrusted entities including the UAC. My evidence for assuming this is as follows: 1. RFC 3325: In section 5, 2nd paragraph it states: "If the proxy receives a message (request or response) from a node that it trusts, it can use the information in the P-Asserted-Identity header field, if any, as if it had authenticated the user itself." There is nowhere that forbids the use of P-Asserted-ID in a response, although there are places in the RFC that mention procedures for a request without mentioning a response. In many places it talks about "message", which, according to the text above, means request or response. 2. RFC 3324 clause 5 clearly states that PAI in INVITE identifies the calling user, PAI in a 180 response the ringing user and PAI in 200 OK the user who answered the call. RFC 3325 is supposed to meet the requirement of RFC3324. I have seen a number of arguments against the use of PAI in a response: a) It has been suggested that a PAI in a response represents the identity of the entity that issued the request. This does not hold water. It clearly would be in contradiction to clause 5 of RFC3324 and there is nowhere in RFC3324 or RFC3325 that suggests echoing in a response the PAI in the request. b)It has been suggested that there would need to be corresponding privacy requirements for identity information in a response. However, RFC 3323 does indeed address privacy in responses. See last paragraph of section 3: "It may be desirable to restrict identity information on both requests and responses. Initially, it might seem unusual to suggest that a response has privacy concerns - presumably, the originator of the request knows who they were attempting to contact, so the identity of the respondent can hardly be confidential. However, some personal information in responses (such as the contact address at which the respondent is currently registered) is subject to privacy concerns and can be addressed by these mechanisms." Also see section 4.2, which states: "...this document defines a new SIP header, Privacy, that can be used to specify privacy handling for requests and responses." c)It has been argued that using PAI in a response may cause an existing implementation to do the wrong thing with respect to privacy, e.g., if privacy is required by the caller, a proxy may apply this to the connected user's identity in the response as well. I don't think this is a likely scenario in view of RFC 3323's coverage of privacy in requests and responses. d)Also it has been suggested that an existing UAS may not take care to request privacy in a response, not realising that a proxy might add a PAI. Again, since RFC 3323 covers privacy in both requests and responses, any UA implementation that supports privacy in requests should also support privacy in responses. e) It has been pointed out that a proxy cannot reject a response if the PAI is wrong. I don't believe this matters - it should be sufficient for the proxy just to strip out a PAI that is wrong. In conclusion, I see evidence that PAI can be used in a response to assert the ID of the connected party and no solid evidence to the contrary. John Elwell (john.elwell@siemens.com) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Jan 2 14:10:48 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19055 for ; Fri, 2 Jan 2004 14:10:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcUge-0003Mo-Q3 for sip-archive@odin.ietf.org; Fri, 02 Jan 2004 14:10:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i02JAK5d012882 for sip-archive@odin.ietf.org; Fri, 2 Jan 2004 14:10:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcUgM-0003LG-Hu; Fri, 02 Jan 2004 14:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcUfq-0003KX-Hg for sip@optimus.ietf.org; Fri, 02 Jan 2004 14:09:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19034 for ; Fri, 2 Jan 2004 14:09:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcUfj-0006TC-00 for sip@ietf.org; Fri, 02 Jan 2004 14:09:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcUa2-0006Ex-00 for sip@ietf.org; Fri, 02 Jan 2004 14:03:33 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AcUVT-00060g-00 for sip@ietf.org; Fri, 02 Jan 2004 13:58:47 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by sj-iport-5.cisco.com with ESMTP; 02 Jan 2004 18:59:40 +0000 Received: from cisco.com (dhcp-64-102-92-137.cisco.com [64.102.92.137]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i02IwEK6004206 for ; Fri, 2 Jan 2004 13:58:14 -0500 (EST) Message-ID: <3FF5BF46.80502@cisco.com> Date: Fri, 02 Jan 2004 13:58:14 -0500 From: Sanjay Sinha Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Subscribe dialog and target refresh request Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, For a dialog initiated with SUBSCRIBE, can a subscription for a new event on that dialog also be a target refresh request? - Sanjay. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sat Jan 3 14:19:52 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09548 for ; Sat, 3 Jan 2004 14:19:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcrIx-0004JT-TY for sip-archive@odin.ietf.org; Sat, 03 Jan 2004 14:19:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i03JJNCa016573 for sip-archive@odin.ietf.org; Sat, 3 Jan 2004 14:19:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcrIb-0004IO-Kb; Sat, 03 Jan 2004 14:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcrI6-0004I8-IB for sip@optimus.ietf.org; Sat, 03 Jan 2004 14:18:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09447 for ; Sat, 3 Jan 2004 14:18:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcrI4-0005e7-00 for sip@ietf.org; Sat, 03 Jan 2004 14:18:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcrG8-0005VA-00 for sip@ietf.org; Sat, 03 Jan 2004 14:16:28 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AcrEd-0005Ki-00 for sip@ietf.org; Sat, 03 Jan 2004 14:14:55 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 03 Jan 2004 11:20:27 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i03JDRGN017261; Sat, 3 Jan 2004 11:13:31 -0800 (PST) Received: from [10.32.245.157] (stealth-10-32-245-157.cisco.com [10.32.245.157]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id ALD32022; Sat, 3 Jan 2004 11:13:25 -0800 (PST) Date: Sat, 03 Jan 2004 14:13:24 -0500 From: David Oran To: "Elwell, John" , SIP@ietf.org Subject: Re: [Sip] Use of P-Asserted-Identity in a response Message-ID: <2147483647.1073139204@[10.32.245.157]> In-Reply-To: <50B1CBA96870A34799A506B2313F2667D4AA53@ntht201e> References: <50B1CBA96870A34799A506B2313F2667D4AA53@ntht201e> X-Mailer: Mulberry/3.1.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit These arguments are good ones. Even if they weren't good I'd still be in favor of what John proposes, because it's eminently reasonable and provides desperately needed functionality for which we currently have no alternative machinery. Dave. --On Friday, January 2, 2004 4:10 PM +0000 "Elwell, John" wrote: > There seem to be some differences of opinion concerning the use of > P-Asserted-Identity (PAI) in a response. In particular, this is delaying > the progress of draft-ietf-sipping-qsig2sip, which makes use of PAI in a > 200 OK to convey the connected party identity received from the QSIG > network. The same situation is likely to be encountered when interworking > with other legacy signalling systems. > > It is my opinion that PAI can be used in a 200 OK to assert the identity > of the connect party. Moreover, it can be inserted by a gateway UAS and, > unless subject to privacy, can be passed on even to untrusted entities > including the UAC. > > My evidence for assuming this is as follows: > > 1. RFC 3325: In section 5, 2nd paragraph it states: > "If the proxy receives a message (request or response) from a node that it > trusts, it can use the information in the P-Asserted-Identity header > field, if any, as if it had authenticated the user itself." > There is nowhere that forbids the use of P-Asserted-ID in a response, > although there are places in the RFC that mention procedures for a request > without mentioning a response. In many places it talks about "message", > which, according to the text above, means request or response. > > 2. RFC 3324 clause 5 clearly states that PAI in INVITE identifies the > calling user, PAI in a 180 response the ringing user and PAI in 200 OK the > user who answered the call. RFC 3325 is supposed to meet the requirement > of RFC3324. > > I have seen a number of arguments against the use of PAI in a response: > > a) It has been suggested that a PAI in a response represents the identity > of the entity that issued the request. This does not hold water. It > clearly would be in contradiction to clause 5 of RFC3324 and there is > nowhere in RFC3324 or RFC3325 that suggests echoing in a response the PAI > in the request. > > b)It has been suggested that there would need to be corresponding privacy > requirements for identity information in a response. However, RFC 3323 > does indeed address privacy in responses. See last paragraph of section 3: > "It may be desirable to restrict identity information on both requests and > responses. Initially, it might seem unusual to suggest that a response > has privacy concerns - presumably, the originator of the request knows > who they were attempting to contact, so the identity of the respondent > can hardly be confidential. However, some personal information in > responses (such as the contact address at which the respondent is > currently registered) is subject to privacy concerns and can be addressed > by these mechanisms." > Also see section 4.2, which states: > "...this document defines a new SIP header, Privacy, that can be used to > specify privacy handling for requests and responses." > > c)It has been argued that using PAI in a response may cause an existing > implementation to do the wrong thing with respect to privacy, e.g., if > privacy is required by the caller, a proxy may apply this to the connected > user's identity in the response as well. I don't think this is a likely > scenario in view of RFC 3323's coverage of privacy in requests and > responses. > > d)Also it has been suggested that an existing UAS may not take care to > request privacy in a response, not realising that a proxy might add a PAI. > Again, since RFC 3323 covers privacy in both requests and responses, any > UA implementation that supports privacy in requests should also support > privacy in responses. > > e) It has been pointed out that a proxy cannot reject a response if the > PAI is wrong. I don't believe this matters - it should be sufficient for > the proxy just to strip out a PAI that is wrong. > > In conclusion, I see evidence that PAI can be used in a response to assert > the ID of the connected party and no solid evidence to the contrary. > > John Elwell (john.elwell@siemens.com) > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sat Jan 3 19:31:51 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18760 for ; Sat, 3 Jan 2004 19:31:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcwAu-00051Z-5N for sip-archive@odin.ietf.org; Sat, 03 Jan 2004 19:31:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i040VOVA019310 for sip-archive@odin.ietf.org; Sat, 3 Jan 2004 19:31:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcwAa-00050W-3l; Sat, 03 Jan 2004 19:31:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcwAF-0004zB-E7 for sip@optimus.ietf.org; Sat, 03 Jan 2004 19:30:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18746 for ; Sat, 3 Jan 2004 19:30:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcwAD-0002Kq-00 for sip@ietf.org; Sat, 03 Jan 2004 19:30:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Acw8M-0002HC-00 for sip@ietf.org; Sat, 03 Jan 2004 19:28:47 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1Acw7w-0002DB-00 for SIP@ietf.org; Sat, 03 Jan 2004 19:28:20 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i040RXJ05183; Sat, 3 Jan 2004 19:27:33 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id ZL7N0NFZ; Sat, 3 Jan 2004 19:27:34 -0500 Received: from nortelnetworks.com (acart1hr.ca.nortel.com [47.129.129.232]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XLPWNGFN; Sat, 3 Jan 2004 19:27:33 -0500 Message-ID: <3FF75DF0.7080402@nortelnetworks.com> Date: Sat, 03 Jan 2004 19:27:28 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Oran CC: "Elwell, John" , SIP@ietf.org Subject: Re: [Sip] Use of P-Asserted-Identity in a response References: <50B1CBA96870A34799A506B2313F2667D4AA53@ntht201e> <2147483647.1073139204@[10.32.245.157]> In-Reply-To: <2147483647.1073139204@[10.32.245.157]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I would also support this usage. David Oran wrote: > These arguments are good ones. > Even if they weren't good I'd still be in favor of what John proposes, > because it's eminently reasonable and provides desperately needed > functionality for which we currently have no alternative machinery. > > Dave. > > --On Friday, January 2, 2004 4:10 PM +0000 "Elwell, John" > wrote: > >> There seem to be some differences of opinion concerning the use of >> P-Asserted-Identity (PAI) in a response. In particular, this is delaying >> the progress of draft-ietf-sipping-qsig2sip, which makes use of PAI in a >> 200 OK to convey the connected party identity received from the QSIG >> network. The same situation is likely to be encountered when interworking >> with other legacy signalling systems. >> >> It is my opinion that PAI can be used in a 200 OK to assert the identity >> of the connect party. Moreover, it can be inserted by a gateway UAS and, >> unless subject to privacy, can be passed on even to untrusted entities >> including the UAC. >> >> My evidence for assuming this is as follows: >> >> 1. RFC 3325: In section 5, 2nd paragraph it states: >> "If the proxy receives a message (request or response) from a node >> that it >> trusts, it can use the information in the P-Asserted-Identity header >> field, if any, as if it had authenticated the user itself." >> There is nowhere that forbids the use of P-Asserted-ID in a response, >> although there are places in the RFC that mention procedures for a >> request >> without mentioning a response. In many places it talks about "message", >> which, according to the text above, means request or response. >> >> 2. RFC 3324 clause 5 clearly states that PAI in INVITE identifies the >> calling user, PAI in a 180 response the ringing user and PAI in 200 OK >> the >> user who answered the call. RFC 3325 is supposed to meet the requirement >> of RFC3324. >> >> I have seen a number of arguments against the use of PAI in a response: >> >> a) It has been suggested that a PAI in a response represents the identity >> of the entity that issued the request. This does not hold water. It >> clearly would be in contradiction to clause 5 of RFC3324 and there is >> nowhere in RFC3324 or RFC3325 that suggests echoing in a response the PAI >> in the request. >> >> b)It has been suggested that there would need to be corresponding privacy >> requirements for identity information in a response. However, RFC 3323 >> does indeed address privacy in responses. See last paragraph of >> section 3: >> "It may be desirable to restrict identity information on both requests >> and >> responses. Initially, it might seem unusual to suggest that a response >> has privacy concerns - presumably, the originator of the request knows >> who they were attempting to contact, so the identity of the respondent >> can hardly be confidential. However, some personal information in >> responses (such as the contact address at which the respondent is >> currently registered) is subject to privacy concerns and can be addressed >> by these mechanisms." >> Also see section 4.2, which states: >> "...this document defines a new SIP header, Privacy, that can be used to >> specify privacy handling for requests and responses." >> >> c)It has been argued that using PAI in a response may cause an existing >> implementation to do the wrong thing with respect to privacy, e.g., if >> privacy is required by the caller, a proxy may apply this to the >> connected >> user's identity in the response as well. I don't think this is a likely >> scenario in view of RFC 3323's coverage of privacy in requests and >> responses. >> >> d)Also it has been suggested that an existing UAS may not take care to >> request privacy in a response, not realising that a proxy might add a >> PAI. >> Again, since RFC 3323 covers privacy in both requests and responses, any >> UA implementation that supports privacy in requests should also support >> privacy in responses. >> >> e) It has been pointed out that a proxy cannot reject a response if the >> PAI is wrong. I don't believe this matters - it should be sufficient for >> the proxy just to strip out a PAI that is wrong. >> >> In conclusion, I see evidence that PAI can be used in a response to >> assert >> the ID of the connected party and no solid evidence to the contrary. >> >> John Elwell (john.elwell@siemens.com) >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sat Jan 3 20:04:36 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19306 for ; Sat, 3 Jan 2004 20:04:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcwgY-000681-Pj for sip-archive@odin.ietf.org; Sat, 03 Jan 2004 20:04:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0414605023556 for sip-archive@odin.ietf.org; Sat, 3 Jan 2004 20:04:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcwgT-00066S-Kc; Sat, 03 Jan 2004 20:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Acwfa-00065I-BL for sip@optimus.ietf.org; Sat, 03 Jan 2004 20:03:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19292 for ; Sat, 3 Jan 2004 20:02:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcwfM-0003OM-00 for sip@ietf.org; Sat, 03 Jan 2004 20:02:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcwbF-0003KE-00 for sip@ietf.org; Sat, 03 Jan 2004 19:58:38 -0500 Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1Acwaq-0003Ha-00 for SIP@ietf.org; Sat, 03 Jan 2004 19:58:12 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i040vdL01598 for ; Sat, 3 Jan 2004 18:57:40 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sun, 4 Jan 2004 00:57:38 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00AA7817B@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "Elwell, John" , SIP@ietf.org Subject: RE: [Sip] Use of P-Asserted-Identity in a response Date: Sun, 4 Jan 2004 00:57:31 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , RFC 3325 section 9.1 and section 9.2 both extend table 2 of RFC 3261 with the new header. Both entires leave the "where" column empty. The key to RFC 3261 table 2 states: An empty entry in the "where" column indicates that the header field may be present in all requests and responses. I would therefore conclude from the existing specification that both headers may appear in any response to BYE, INV, OPT, SUB, NOT, REF, i.e. those methods that either create a dialog, or are used outside a dialog. As MESSAGE appeared after RFC 3325 I would also assume that it is allowed in the MESSAGE method, in both requests and all responses. Note that these tables do not restrict it to 18x and 2xx responses, although for ISDN mapping purposes those responses are the useful ones. It is perfectly valid in 3xx, 4xx and 5xx responses. Any assertion of identity in responses (and its value) is of course dependent on the specification of privacy by the UAS and on the requirements of the first proxy in the trust domain. This usage corresponds to what has been specified in 3GPP TS 24.229 and I believe in ITU-T Q.1912.5. regards Keith > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: 02 January 2004 16:11 > To: SIP@ietf.org > Subject: [Sip] Use of P-Asserted-Identity in a response > > > There seem to be some differences of opinion concerning the use of > P-Asserted-Identity (PAI) in a response. In particular, this > is delaying the > progress of draft-ietf-sipping-qsig2sip, which makes use of > PAI in a 200 OK > to convey the connected party identity received from the QSIG > network. The > same situation is likely to be encountered when interworking > with other > legacy signalling systems. > > It is my opinion that PAI can be used in a 200 OK to assert > the identity of > the connect party. Moreover, it can be inserted by a gateway > UAS and, unless > subject to privacy, can be passed on even to untrusted > entities including > the UAC. > > My evidence for assuming this is as follows: > > 1. RFC 3325: In section 5, 2nd paragraph it states: > "If the proxy receives a message (request or response) from a > node that it > trusts, it can use the information in the P-Asserted-Identity > header field, > if any, as if it had authenticated the user itself." > There is nowhere that forbids the use of P-Asserted-ID in a response, > although there are places in the RFC that mention procedures > for a request > without mentioning a response. In many places it talks about > "message", > which, according to the text above, means request or response. > > 2. RFC 3324 clause 5 clearly states that PAI in INVITE identifies the > calling user, PAI in a 180 response the ringing user and PAI > in 200 OK the > user who answered the call. RFC 3325 is supposed to meet the > requirement of > RFC3324. > > I have seen a number of arguments against the use of PAI in a > response: > > a) It has been suggested that a PAI in a response represents > the identity of > the entity that issued the request. This does not hold water. > It clearly > would be in contradiction to clause 5 of RFC3324 and there is > nowhere in > RFC3324 or RFC3325 that suggests echoing in a response the PAI in the > request. > > b)It has been suggested that there would need to be > corresponding privacy > requirements for identity information in a response. However, > RFC 3323 does > indeed address privacy in responses. See last paragraph of section 3: > "It may be desirable to restrict identity information on both > requests and > responses. Initially, it might seem unusual to suggest that > a response has > privacy concerns - presumably, the originator of the request > knows who they > were attempting to contact, so the identity of the respondent > can hardly be > confidential. However, some personal information in > responses (such as the > contact address at which the respondent is currently > registered) is subject > to privacy concerns and can be addressed by these mechanisms." > Also see section 4.2, which states: > "...this document defines a new SIP header, Privacy, that can > be used to > specify privacy handling for requests and responses." > > c)It has been argued that using PAI in a response may cause > an existing > implementation to do the wrong thing with respect to privacy, e.g., if > privacy is required by the caller, a proxy may apply this to > the connected > user's identity in the response as well. I don't think this > is a likely > scenario in view of RFC 3323's coverage of privacy in requests and > responses. > > d)Also it has been suggested that an existing UAS may not take care to > request privacy in a response, not realising that a proxy > might add a PAI. > Again, since RFC 3323 covers privacy in both requests and > responses, any UA > implementation that supports privacy in requests should also > support privacy > in responses. > > e) It has been pointed out that a proxy cannot reject a > response if the PAI > is wrong. I don't believe this matters - it should be > sufficient for the > proxy just to strip out a PAI that is wrong. > > In conclusion, I see evidence that PAI can be used in a > response to assert > the ID of the connected party and no solid evidence to the contrary. > > John Elwell (john.elwell@siemens.com) > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sun Jan 4 11:45:53 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01297 for ; Sun, 4 Jan 2004 11:45:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdBNV-0008P8-PQ for sip-archive@odin.ietf.org; Sun, 04 Jan 2004 11:45:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i04GjPQr032246 for sip-archive@odin.ietf.org; Sun, 4 Jan 2004 11:45:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdBN9-0008Mq-C8; Sun, 04 Jan 2004 11:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdBN4-0008M7-9e for sip@optimus.ietf.org; Sun, 04 Jan 2004 11:44:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01287 for ; Sun, 4 Jan 2004 11:44:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdBN3-0001x8-00 for sip@ietf.org; Sun, 04 Jan 2004 11:44:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdBLC-0001uP-00 for sip@ietf.org; Sun, 04 Jan 2004 11:43:03 -0500 Received: from brandt-online.net ([217.160.90.205] helo=p10088371.pureserver.de) by ietf-mx with esmtp (Exim 4.12) id 1AdBKx-0001qs-00 for SIP@ietf.org; Sun, 04 Jan 2004 11:42:47 -0500 Received: from Renne (reverse-213-146-113-66.dialin.kamp-dsl.de [213.146.113.66]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by p10088371.pureserver.de (Postfix) with ESMTP id 57BEE420118 for ; Sun, 4 Jan 2004 17:42:29 +0100 (CET) From: Rene Bartsch To: SIP@ietf.org Date: Sun, 4 Jan 2004 17:43:45 +0100 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401041743.45713.ml@bartschnet.de> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Emergency Calls with SIP? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, currently I'm faced with the problem of emergency calls. As you need to gather the location of the caller to connect to the nearest emergency center when 911, 110, 112, ... is dialed, SIP needs some way for determining location. My idea is to store a location-tag (e.g. address or GPS-data) in the SIP-phone, which is transmitted to the SIP-provider in case an emergency number is dialed. That way the SIP-provider can determine the appropriate emergency center by country and zip/area code transmitting three addresses to the emergency center: location, SIP-account holder and IP. With location you can send help directly (e.g. ambulance). In case of wrong location or misuse you can investigate the caller by account-holder address and IP. Are there any RFCs or Drafts for a emergency-call use-case with SIP? Rene Bartsch _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sun Jan 4 16:29:17 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09196 for ; Sun, 4 Jan 2004 16:29:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdFnl-0000k0-Ie for sip-archive@odin.ietf.org; Sun, 04 Jan 2004 16:28:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i04LSn30002844 for sip-archive@odin.ietf.org; Sun, 4 Jan 2004 16:28:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdFn0-0000iY-1f; Sun, 04 Jan 2004 16:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdFmD-0000hz-NE for sip@optimus.ietf.org; Sun, 04 Jan 2004 16:27:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09145 for ; Sun, 4 Jan 2004 16:27:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdFmB-0003vg-00 for sip@ietf.org; Sun, 04 Jan 2004 16:27:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdFka-0003sE-00 for sip@ietf.org; Sun, 04 Jan 2004 16:25:33 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AdFjO-0003nc-00 for SIP@ietf.org; Sun, 04 Jan 2004 16:24:18 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i04LMxt02875; Sun, 4 Jan 2004 16:22:59 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id ZL7N0PT4; Sun, 4 Jan 2004 16:22:59 -0500 Received: from nortelnetworks.com (acart1h0.ca.nortel.com [47.129.129.208]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XLPWNGJW; Sun, 4 Jan 2004 16:22:59 -0500 Message-ID: <3FF8842F.9020800@nortelnetworks.com> Date: Sun, 04 Jan 2004 16:22:55 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rene Bartsch CC: SIP@ietf.org Subject: Re: [Sip] Emergency Calls with SIP? References: <200401041743.45713.ml@bartschnet.de> In-Reply-To: <200401041743.45713.ml@bartschnet.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Henning Schulrinne wrote a number of relevant drafts. The topic of connection from a SIP phone to a legacy emergency call centre was explored in draft-taylor-sipping-emerg-scen-01.txt, which also gives the references to Henning's drafts. Rene Bartsch wrote: > Hi, > > currently I'm faced with the problem of emergency calls. > > As you need to gather the location of the caller to connect to the nearest > emergency center when 911, 110, 112, ... is dialed, SIP needs some way for > determining location. > > My idea is to store a location-tag (e.g. address or GPS-data) in the > SIP-phone, which is transmitted to the SIP-provider in case an emergency > number is dialed. > That way the SIP-provider can determine the appropriate emergency center by > country and zip/area code transmitting three addresses to the emergency > center: > > location, SIP-account holder and IP. > > With location you can send help directly (e.g. ambulance). In case of wrong > location or misuse you can investigate the caller by account-holder address > and IP. > > Are there any RFCs or Drafts for a emergency-call use-case with SIP? > > Rene Bartsch > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Jan 5 03:17:59 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06568 for ; Mon, 5 Jan 2004 03:17:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdPvV-0007KA-E7 for sip-archive@odin.ietf.org; Mon, 05 Jan 2004 03:17:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i058HT9W028098 for sip-archive@odin.ietf.org; Mon, 5 Jan 2004 03:17:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdPv3-0007Hn-P6; Mon, 05 Jan 2004 03:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdPuM-0007Gz-M7 for sip@optimus.ietf.org; Mon, 05 Jan 2004 03:16:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06541 for ; Mon, 5 Jan 2004 03:16:12 -0500 (EST) From: nataraju.alilaghatta@wipro.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdPuA-00029H-00 for sip@ietf.org; Mon, 05 Jan 2004 03:16:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdPrT-00024g-00 for sip@ietf.org; Mon, 05 Jan 2004 03:13:20 -0500 Received: from wiproecmx1.wipro.com ([164.164.31.5]) by ietf-mx with esmtp (Exim 4.12) id 1AdPno-0001yT-00 for sip@ietf.org; Mon, 05 Jan 2004 03:09:33 -0500 Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx1.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i0588YCr013042 for ; Mon, 5 Jan 2004 13:38:35 +0530 (IST) Received: from blr-ec-bh1.wipro.com ([10.200.50.91]) by ec-vwall-wd with InterScan Messaging Security Suite; Mon, 05 Jan 2004 13:39:45 +0530 Received: from blr-ec-msg04.wipro.com ([10.200.53.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 5 Jan 2004 13:38:33 +0530 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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Subscribe dialog and target refresh request Date: Mon, 5 Jan 2004 13:38:33 +0530 Message-ID: <10C4348A1BA43A4FA8D5B767E052CEADD2587F@blr-ec-msg04.wipro.com> Thread-Topic: [Sip] Subscribe dialog and target refresh request Thread-Index: AcPRZEI/dqNQk56FQ6e4HbEbMaQTTQB/3rRg To: , X-OriginalArrivalTime: 05 Jan 2004 08:08:33.0538 (UTC) FILETIME=[1CD3EE20:01C3D363] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Regards, Nataraju A.B.=20 -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Sanjay Sinha Sent: Saturday, January 03, 2004 12:28 AM To: sip@ietf.org Subject: [Sip] Subscribe dialog and target refresh request Hi, For a dialog initiated with SUBSCRIBE, can a subscription for a new=20 event on that dialog also be a target refresh request? [Natraj] No, it's not a Target refresh request. Target refresh could only happen either through INVITE or UPDATE requests..=20 - Sanjay. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Jan 5 06:48:47 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14082 for ; Mon, 5 Jan 2004 06:48:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdTDY-00081g-TE for sip-archive@odin.ietf.org; Mon, 05 Jan 2004 06:48:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i05BmKIN030793 for sip-archive@odin.ietf.org; Mon, 5 Jan 2004 06:48:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdTDF-0007z3-HU; Mon, 05 Jan 2004 06:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdTCQ-0007xa-JM for sip@optimus.ietf.org; Mon, 05 Jan 2004 06:47:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14022 for ; Mon, 5 Jan 2004 06:47:06 -0500 (EST) From: Jussi.Turunen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdTCM-0004wy-00 for sip@ietf.org; Mon, 05 Jan 2004 06:47:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdTAR-0004rS-00 for sip@ietf.org; Mon, 05 Jan 2004 06:45:08 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AdT8Y-0004mm-00 for sip@ietf.org; Mon, 05 Jan 2004 06:43:10 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i05BhB618203 for ; Mon, 5 Jan 2004 13:43:11 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 5 Jan 2004 13:43:10 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 5 Jan 2004 13:43:10 +0200 Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 5 Jan 2004 13:43:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Subscribe dialog and target refresh request Date: Mon, 5 Jan 2004 13:43:05 +0200 Message-ID: Thread-Topic: [Sip] Subscribe dialog and target refresh request Thread-Index: AcPRZEI/dqNQk56FQ6e4HbEbMaQTTQB/3rRgAAcgTzA= To: , , X-OriginalArrivalTime: 05 Jan 2004 11:43:06.0186 (UTC) FILETIME=[158622A0:01C3D381] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi > For a dialog initiated with SUBSCRIBE, can a subscription for a new=20 > event on that dialog also be a target refresh request? >=20 > [Natraj] No, it's not a Target refresh request. Target refresh could > only happen either through INVITE or UPDATE requests..=20 >=20 There is a bug in RFC3265. Bug description = (http://bugs.sipit.net/sipwg/show_bug.cgi?id=3D699) says: "NOTIFY and SUBSCRIBE are target refresh requests ...but the text never says this explicitly." Haven't seen this bug closed yet... I remember some discussion on this = on this a while (a year or so) ago, so you might want to check the = archives for that. Jussi _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Jan 5 11:30:40 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23491 for ; Mon, 5 Jan 2004 11:30:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdXcK-0001jl-5L for sip-archive@odin.ietf.org; Mon, 05 Jan 2004 11:30:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i05GUC9c006619 for sip-archive@odin.ietf.org; Mon, 5 Jan 2004 11:30:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdXcB-0001hA-NN; Mon, 05 Jan 2004 11:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdXbB-0001fE-M5 for sip@optimus.ietf.org; Mon, 05 Jan 2004 11:29:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23254 for ; Mon, 5 Jan 2004 11:28:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdXbA-0001oT-00 for sip@ietf.org; Mon, 05 Jan 2004 11:29:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdXYV-0001Y7-00 for sip@ietf.org; Mon, 05 Jan 2004 11:26:16 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AdXVL-0001DN-00 for sip@ietf.org; Mon, 05 Jan 2004 11:22:59 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id i05GLjd06824; Mon, 5 Jan 2004 10:21:51 -0600 Subject: Re: [Sip] Re: SIPIT 14 Registration From: Robert Sparks To: sip-implementors@cs.columbia.edu Cc: sip@ietf.org In-Reply-To: <1071851412.1380.43.camel@RjS.localdomain> References: <1070661467.911.30.camel@RjS.localdomain> <1071851412.1380.43.camel@RjS.localdomain> Content-Type: text/plain Message-Id: <1073319702.935.10.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 05 Jan 2004 10:21:42 -0600 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit SIPIT 14 Registration will close soon. The event will be held 9-February through 13-February 2004. The last day to register is 16-January-2004 (The last day to secure a room at the event is 9-January-2004) Registration information is available at: http://www.etsi.org/plugtests/SIPIT14.htm RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Jan 5 16:53:36 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06462 for ; Mon, 5 Jan 2004 16:53:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adceq-0006BO-St for sip-archive@odin.ietf.org; Mon, 05 Jan 2004 16:53:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i05Lr8VL023764 for sip-archive@odin.ietf.org; Mon, 5 Jan 2004 16:53:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adcdl-00065Z-Ah; Mon, 05 Jan 2004 16:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdcdB-000651-0f for sip@optimus.ietf.org; Mon, 05 Jan 2004 16:51:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06437 for ; Mon, 5 Jan 2004 16:51:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Adcd8-0000hf-00 for sip@ietf.org; Mon, 05 Jan 2004 16:51:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdcbJ-0000fO-00 for sip@ietf.org; Mon, 05 Jan 2004 16:49:29 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Adcar-0000cI-00 for sip@ietf.org; Mon, 05 Jan 2004 16:49:01 -0500 Received: from dynamicsoft.com ([63.113.46.36]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i05LmLmR009585; Mon, 5 Jan 2004 16:48:21 -0500 (EST) Message-ID: <3FF9DB9E.60702@dynamicsoft.com> Date: Mon, 05 Jan 2004 16:48:14 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jussi.Turunen@nokia.com CC: nataraju.alilaghatta@wipro.com, sanjsinh@cisco.com, sip@ietf.org Subject: Re: [Sip] Subscribe dialog and target refresh request References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Yes, SUB and NOT are target refresh requests. However, the question that was asked, I think, had to do with establishing a second subscription in the context of a dialog created by a first subscription. In such a case, a SUBSCRIBE or NOTIFY would be a target refresh request, but what state does it update? For example, if a SUBSCRIBE refresh for the second subscription contains a new Contact, does that contact apply to both subscriptions, or just the second one? I think its both, because the remote target is part of the dialog state, and there is but one dialog here. However, I think its a much better idea to send a second subscription on a different dialog, rather than trying to reuse an existing dialog. -Jonathan R. Jussi.Turunen@nokia.com wrote: > Hi > > >>For a dialog initiated with SUBSCRIBE, can a subscription for a new >>event on that dialog also be a target refresh request? >> >>[Natraj] No, it's not a Target refresh request. Target refresh could >>only happen either through INVITE or UPDATE requests.. >> > > > There is a bug in RFC3265. Bug description (http://bugs.sipit.net/sipwg/show_bug.cgi?id=699) says: > > "NOTIFY and SUBSCRIBE are target refresh requests > > ...but the text never says this explicitly." > > Haven't seen this bug closed yet... I remember some discussion on this on this a while (a year or so) ago, so you might want to check the archives for that. > > Jussi > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Jan 5 18:41:00 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13337 for ; Mon, 5 Jan 2004 18:41:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdeKo-0003vm-3O for sip-archive@odin.ietf.org; Mon, 05 Jan 2004 18:40:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i05NeYJ8015106 for sip-archive@odin.ietf.org; Mon, 5 Jan 2004 18:40:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdeKO-0003ny-Oc; Mon, 05 Jan 2004 18:40:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdeK0-0003kL-4F for sip@optimus.ietf.org; Mon, 05 Jan 2004 18:39:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12757 for ; Mon, 5 Jan 2004 18:39:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdeJw-0002MC-00 for sip@ietf.org; Mon, 05 Jan 2004 18:39:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdeFR-0001DR-00 for sip@ietf.org; Mon, 05 Jan 2004 18:35:02 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AdeAy-000021-00 for sip@ietf.org; Mon, 05 Jan 2004 18:30:24 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 05 Jan 2004 23:30:34 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i05NTpLE002915; Mon, 5 Jan 2004 18:29:51 -0500 (EST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFA36927; Mon, 5 Jan 2004 18:29:50 -0500 (EST) Message-ID: <3FF9F36D.5060604@cisco.com> Date: Mon, 05 Jan 2004 18:29:49 -0500 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 CC: Jussi.Turunen@nokia.com, nataraju.alilaghatta@wipro.com, sanjsinh@cisco.com, sip@ietf.org Subject: Re: [Sip] Subscribe dialog and target refresh request References: <3FF9DB9E.60702@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Yes, SUB and NOT are target refresh requests. > > However, the question that was asked, I think, had to do with > establishing a second subscription in the context of a dialog created by > a first subscription. In such a case, a SUBSCRIBE or NOTIFY would be a > target refresh request, but what state does it update? For example, if a > SUBSCRIBE refresh for the second subscription contains a new Contact, > does that contact apply to both subscriptions, or just the second one? I > think its both, because the remote target is part of the dialog state, > and there is but one dialog here. I agree. > However, I think its a much better idea to send a second subscription on > a different dialog, rather than trying to reuse an existing dialog. I think this actually depends on intent. If the subscriptions are intended to be independent then I agree. OTOH, if it is important that the subscriptions always be associated with the same UA even as that moves around, then there is an advantage to using a single dialog. Its easier to find such cases in the sharing of a dialog between an invite and a subscribe than it is between two subscribes. Paul > -Jonathan R. > > Jussi.Turunen@nokia.com wrote: > >> Hi >> >> >>> For a dialog initiated with SUBSCRIBE, can a subscription for a new >>> event on that dialog also be a target refresh request? >>> >>> [Natraj] No, it's not a Target refresh request. Target refresh could >>> only happen either through INVITE or UPDATE requests.. >> >> >> >> There is a bug in RFC3265. Bug description >> (http://bugs.sipit.net/sipwg/show_bug.cgi?id=699) says: >> >> "NOTIFY and SUBSCRIBE are target refresh requests >> >> ...but the text never says this explicitly." >> >> Haven't seen this bug closed yet... I remember some discussion on this >> on this a while (a year or so) ago, so you might want to check the >> archives for that. >> >> Jussi >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Jan 5 19:11:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15044 for ; Mon, 5 Jan 2004 19:11:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdeoO-0005Ck-0r for sip-archive@odin.ietf.org; Mon, 05 Jan 2004 19:11:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i060B7Vq020000 for sip-archive@odin.ietf.org; Mon, 5 Jan 2004 19:11:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdeoI-0005C3-Ro; Mon, 05 Jan 2004 19:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdenX-0005B8-E3 for sip@optimus.ietf.org; Mon, 05 Jan 2004 19:10:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15004 for ; Mon, 5 Jan 2004 19:10:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdenP-0004gu-00 for sip@ietf.org; Mon, 05 Jan 2004 19:10:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Adehu-0004VO-00 for sip@ietf.org; Mon, 05 Jan 2004 19:04:27 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Adeeg-0004Lk-00 for sip@ietf.org; Mon, 05 Jan 2004 19:01:06 -0500 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i06009GN025564; Mon, 5 Jan 2004 16:00:09 -0800 (PST) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA02551; Mon, 5 Jan 2004 16:00:08 -0800 (PST) Message-Id: <4.3.2.7.2.20040105175613.03790198@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 05 Jan 2004 18:00:14 -0600 To: Rene Bartsch From: "James M. Polk" Subject: Re: [Sip] Emergency Calls with SIP? Cc: SIP@ietf.org In-Reply-To: <3FF8842F.9020800@nortelnetworks.com> References: <200401041743.45713.ml@bartschnet.de> <200401041743.45713.ml@bartschnet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , At 04:22 PM 1/4/2004 -0500, Tom Taylor wrote: >Henning Schulrinne wrote a number of relevant drafts. The topic of >connection from a SIP phone to a legacy emergency call centre was explored >in draft-taylor-sipping-emerg-scen-01.txt, which also gives the references >to Henning's drafts. see: http://www.ietf.org/internet-drafts/draft-polk-sipping-location-requirements-01.txt containing a scenario just like I read yours below. Comments are appreciated A new version of the above ID will be generated before the Seoul meeting. BTW - the SIPPING mailing list has had a few threads recently on this ID. >Rene Bartsch wrote: > >>Hi, >>currently I'm faced with the problem of emergency calls. >>As you need to gather the location of the caller to connect to the >>nearest emergency center when 911, 110, 112, ... is dialed, SIP needs >>some way for determining location. >>My idea is to store a location-tag (e.g. address or GPS-data) in the >>SIP-phone, which is transmitted to the SIP-provider in case an emergency >>number is dialed. >>That way the SIP-provider can determine the appropriate emergency center >>by country and zip/area code transmitting three addresses to the >>emergency center: >>location, SIP-account holder and IP. >>With location you can send help directly (e.g. ambulance). In case of >>wrong location or misuse you can investigate the caller by account-holder >>address and IP. >>Are there any RFCs or Drafts for a emergency-call use-case with SIP? >>Rene Bartsch >>_______________________________________________ cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Jan 6 02:18:54 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07896 for ; Tue, 6 Jan 2004 02:18:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdlTp-0003qg-89 for sip-archive@odin.ietf.org; Tue, 06 Jan 2004 02:18:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i067ILxr014795 for sip-archive@odin.ietf.org; Tue, 6 Jan 2004 02:18:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdlTV-0003nc-Fu; Tue, 06 Jan 2004 02:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdlT0-0003kZ-0o for sip@optimus.ietf.org; Tue, 06 Jan 2004 02:17:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07764 for ; Tue, 6 Jan 2004 02:17:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdlSm-0004iD-00 for sip@ietf.org; Tue, 06 Jan 2004 02:17:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdlPj-0004ae-00 for sip@ietf.org; Tue, 06 Jan 2004 02:14:08 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AdlL5-0004QS-00 for sip@ietf.org; Tue, 06 Jan 2004 02:09:19 -0500 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i0678VmR009736; Tue, 6 Jan 2004 02:08:31 -0500 (EST) Message-ID: <3FFA5EE1.1050302@dynamicsoft.com> Date: Tue, 06 Jan 2004 02:08:17 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Jussi.Turunen@nokia.com, nataraju.alilaghatta@wipro.com, sanjsinh@cisco.com, sip@ietf.org Subject: GRUU and UA instances, was: Re: [Sip] Subscribe dialog and target refresh request References: <3FF9DB9E.60702@dynamicsoft.com> <3FF9F36D.5060604@cisco.com> In-Reply-To: <3FF9F36D.5060604@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline. Paul Kyzivat wrote: >> However, I think its a much better idea to send a second subscription >> on a different dialog, rather than trying to reuse an existing dialog. > > > I think this actually depends on intent. If the subscriptions are > intended to be independent then I agree. OTOH, if it is important that > the subscriptions always be associated with the same UA even as that > moves around, then there is an advantage to using a single dialog. > > Its easier to find such cases in the sharing of a dialog between an > invite and a subscribe than it is between two subscribes. The GRUU would allow you to keep both dialogs attached to a particular UA instance. Should the UA move around, it would require you to generate a target refresh request on each dialog to update the Contact. This, however, leads me into thinking a bit on the lifecycle management for GRUUs. Currently, GRUU is bound to a single registration, where the registration is defined by the Contact URI. If the UA should "move", in the sense that it acquires a new IP address, this will be a new Contact URI, and therefore, a new GRUU. It would be nice if, instead, the GRUU were truly bound to the UA instance, and that even if the UA instance changed IP addresses, the GRUU could remain unchanged. In such a case, if the UA moves, there is actually no need to issue any target refresh requests. The UA would simply re-register, update the binding of its GRUU to its new IP address, and existing calls would be correctly routed. Indeed, this has the interesting benefit that, even if both UA in a call should move at the same time, the call would still be able to continue, since such updates are never propagated to the peer in the call. For this to work, it would require that the registration have a way of identifying the UA instance. This goes back to the instance identifier we had (but removed) from callee-caps. If we added it, we could then associate the GRUU with this ID, rather than the Contact URI. In other words, if the client registered thusly: REGISTER To: sip:user@example.com Contact: sip:1.2.3.4;+instance-id="9asdd9a887sdasd=asd888a" Supported: gruu the registrar would allocate a GRUU, and associate it with that instance ID: 200 OK Contact: sip:1.2.3.4;+instance-id="9asdd9a887sdasd=asd888a";gruu=sip:f4@example.com Now, if the UA should update its registration because it moves: REGISTER To: sip:user@example.com Contact: sip:5.6.7.8;+instance-id="9asdd9a887sdasd=asd888a" Contact: sip:1.2.3.4;expires=0 the registrar would return the *same* gruu for the new registration: 200 OK Contact: sip:5.6.7.8;+instance-id="9asdd9a887sdasd=asd888a";gruu=sip:f4@example.com It is still possible for the registrar to not store additional state if GRUU is defined this way. The GRUU URI would be computed thusly: sip:@example.com That is, the GRUU now encodes the instance ID. When a request is received with a GRUU, the registrar extracts the instance ID. It then looks up the registration corresponding to that instance ID, and obtains its Contact URI. This doesnt require additional state per se, but does require that the registration data be structured to allow lookups based on the instance-id. Thoughts? -Jonathan R. > > Paul > >> -Jonathan R. >> >> Jussi.Turunen@nokia.com wrote: >> >>> Hi >>> >>> >>>> For a dialog initiated with SUBSCRIBE, can a subscription for a new >>>> event on that dialog also be a target refresh request? >>>> >>>> [Natraj] No, it's not a Target refresh request. Target refresh could >>>> only happen either through INVITE or UPDATE requests.. >>> >>> >>> >>> >>> There is a bug in RFC3265. Bug description >>> (http://bugs.sipit.net/sipwg/show_bug.cgi?id=699) says: >>> >>> "NOTIFY and SUBSCRIBE are target refresh requests >>> >>> ...but the text never says this explicitly." >>> >>> Haven't seen this bug closed yet... I remember some discussion on >>> this on this a while (a year or so) ago, so you might want to check >>> the archives for that. >>> >>> Jussi >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> >> > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Jan 6 02:42:39 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09412 for ; Tue, 6 Jan 2004 02:42:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adlqu-0005Xz-4d for sip-archive@odin.ietf.org; Tue, 06 Jan 2004 02:42:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i067gC7e021264 for sip-archive@odin.ietf.org; Tue, 6 Jan 2004 02:42:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adlql-0005Vj-Ok; Tue, 06 Jan 2004 02:42:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdlqE-0005To-Kl for sip@optimus.ietf.org; Tue, 06 Jan 2004 02:41:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09386 for ; Tue, 6 Jan 2004 02:41:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdlqA-0006i2-00 for sip@ietf.org; Tue, 06 Jan 2004 02:41:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdloF-0006dM-00 for sip@ietf.org; Tue, 06 Jan 2004 02:39:27 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AdlmO-0006Ty-00 for sip@ietf.org; Tue, 06 Jan 2004 02:37:32 -0500 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i067b9mR009750 for ; Tue, 6 Jan 2004 02:37:09 -0500 (EST) Message-ID: <3FFA6598.3000500@dynamicsoft.com> Date: Tue, 06 Jan 2004 02:36:56 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Updated GRUU spec Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, I've just submitted an update to the GRUU spec. It is now a working item of the SIP working group. Until it appears in the archives, you can pick up a copy at: http://www.jdrosen.net/papers/draft-ietf-sip-gruu-00.txt The changes from the previous version are: * incorporates the content of the requirements document, which will no longer be proceeding as a separate document * updates the discussion on registrar behavior to clarify behavior * removes the 128 bit restriction on the grid The only open issue, which I have discussed in another thread, is whether or not to associate the gruu to the Contact URI or instance ID. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Jan 6 04:07:48 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11516 for ; Tue, 6 Jan 2004 04:07:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdnBI-0000dO-2W for sip-archive@odin.ietf.org; Tue, 06 Jan 2004 04:07:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0697JED002429 for sip-archive@odin.ietf.org; Tue, 6 Jan 2004 04:07:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdnB0-0000ae-PS; Tue, 06 Jan 2004 04:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdnAS-0000Zt-Pq for sip@optimus.ietf.org; Tue, 06 Jan 2004 04:06:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11500 for ; Tue, 6 Jan 2004 04:06:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdnAL-000203-00 for sip@ietf.org; Tue, 06 Jan 2004 04:06:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Adn88-0001wX-00 for sip@ietf.org; Tue, 06 Jan 2004 04:04:05 -0500 Received: from cluster-a.mailcontrol.com ([80.69.8.190] helo=rly05a.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1Adn3t-0001nf-00 for sip@ietf.org; Tue, 06 Jan 2004 03:59:41 -0500 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly05a.srv.mailcontrol.com (MailControl) with SMTP id i068wxXf006711; Tue, 6 Jan 2004 08:59:00 GMT Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-a.mailcontrol.com [80.69.8.190]) with SMTP; Tue, 6 Jan 2004 08:58:58 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: GRUU and UA instances, was: Re: [Sip] Subscribe dialog and target refresh request Date: Tue, 6 Jan 2004 08:58:59 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE0219B154@gbnewp0758m.eu.ubiquity.net> Thread-Topic: GRUU and UA instances, was: Re: [Sip] Subscribe dialog and target refresh request Thread-Index: AcPUJUbzameYLrPZRsKNZrhG8PKHdAADVhnA From: "Chris Boulton" To: "Jonathan Rosenberg" , "Paul Kyzivat" Cc: , , , X-Scanned-By: MailControl A-02-00-00 (www.mailcontrol.com) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Comments [in-line] >-----Original Message----- >From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >Sent: 06 January 2004 07:08 >To: Paul Kyzivat >Cc: Jussi.Turunen@nokia.com; nataraju.alilaghatta@wipro.com; >sanjsinh@cisco.com; sip@ietf.org >Subject: GRUU and UA instances, was: Re: [Sip] Subscribe dialog and target >refresh request > >inline. > >Paul Kyzivat wrote: > > >>> However, I think its a much better idea to send a second subscription >>> on a different dialog, rather than trying to reuse an existing dialog. >> >> >> I think this actually depends on intent. If the subscriptions are >> intended to be independent then I agree. OTOH, if it is important that >> the subscriptions always be associated with the same UA even as that >> moves around, then there is an advantage to using a single dialog. >> >> Its easier to find such cases in the sharing of a dialog between an >> invite and a subscribe than it is between two subscribes. > >The GRUU would allow you to keep both dialogs attached to a particular >UA instance. Should the UA move around, it would require you to >generate a target refresh request on each dialog to update the Contact. > >This, however, leads me into thinking a bit on the lifecycle >management for GRUUs. Currently, GRUU is bound to a single >registration, where the registration is defined by the Contact URI. If >the UA should "move", in the sense that it acquires a new IP address, >this will be a new Contact URI, and therefore, a new GRUU. It would be >nice if, instead, the GRUU were truly bound to the UA instance, and >that even if the UA instance changed IP addresses, the GRUU could >remain unchanged. In such a case, if the UA moves, there is actually >no need to issue any target refresh requests. The UA would simply >re-register, update the binding of its GRUU to its new IP address, and >existing calls would be correctly routed. > >Indeed, this has the interesting benefit that, even if both UA in a >call should move at the same time, the call would still be able to >continue, since such updates are never propagated to the peer in the >call. > >For this to work, it would require that the registration have a way of >identifying the UA instance. This goes back to the instance identifier >we had (but removed) from callee-caps. If we added it, we could then >associate the GRUU with this ID, rather than the Contact URI. In other >words, if the client registered thusly: > >REGISTER >To: sip:user@example.com >Contact: sip:1.2.3.4;+instance-id=3D"9asdd9a887sdasd=3Dasd888a" >Supported: gruu > >the registrar would allocate a GRUU, and associate it with that >instance ID: > >200 OK >Contact: >sip:1.2.3.4;+instance-id=3D"9asdd9a887sdasd=3Dasd888a";gruu=3Dsip:f4@examp= le. com > >Now, if the UA should update its registration because it moves: > >REGISTER >To: sip:user@example.com >Contact: sip:5.6.7.8;+instance-id=3D"9asdd9a887sdasd=3Dasd888a" >Contact: sip:1.2.3.4;expires=3D0 > >the registrar would return the *same* gruu for the new registration: > >200 OK >Contact: >sip:5.6.7.8;+instance-id=3D"9asdd9a887sdasd=3Dasd888a";gruu=3Dsip:f4@examp= le. com > > >It is still possible for the registrar to not store additional state >if GRUU is defined this way. The GRUU URI would be computed thusly: > >sip:@example.com > >That is, the GRUU now encodes the instance ID. When a request is >received with a GRUU, the registrar extracts the instance ID. It then >looks up the registration corresponding to that instance ID, and >obtains its Contact URI. This doesnt require additional state per se, >but does require that the registration data be structured to allow >lookups based on the instance-id. > >Thoughts? [Chris Boulton] Jonathan - I really like this. It makes the GRUU mechanism extremely powerful and increases usability and flexibility. As long as the rule set for this functionality is strong (e.g. ensuring that any client wishing to alter a binding for a GRUU terminates the existing binding) I think it should be included.=20=20=20 Chris. >-Jonathan R. >> >> Paul >> >>> -Jonathan R. >>> >>> Jussi.Turunen@nokia.com wrote: >>> >>>> Hi >>>> >>>> >>>>> For a dialog initiated with SUBSCRIBE, can a subscription for a new >>>>> event on that dialog also be a target refresh request? >>>>> >>>>> [Natraj] No, it's not a Target refresh request. Target refresh could >>>>> only happen either through INVITE or UPDATE requests.. >>>> >>>> >>>> >>>> >>>> There is a bug in RFC3265. Bug description >>>> (http://bugs.sipit.net/sipwg/show_bug.cgi?id=3D699) says: >>>> >>>> "NOTIFY and SUBSCRIBE are target refresh requests >>>> >>>> ...but the text never says this explicitly." >>>> >>>> Haven't seen this bug closed yet... I remember some discussion on >>>> this on this a while (a year or so) ago, so you might want to check >>>> the archives for that. >>>> >>>> Jussi >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol >>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>> Use sipping@ietf.org for new developments on the application of sip >>>> >>> >> > >-- >Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >Chief Technology Officer Parsippany, NJ 07054-2711 >dynamicsoft >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.dynamicsoft.com > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Jan 6 09:29:20 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19103 for ; Tue, 6 Jan 2004 09:29:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdsCR-0002wS-UE for sip-archive@odin.ietf.org; Tue, 06 Jan 2004 09:28:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i06ESpNq011307 for sip-archive@odin.ietf.org; Tue, 6 Jan 2004 09:28:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdsBd-0002qc-1s; Tue, 06 Jan 2004 09:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdsBV-0002qM-3h for sip@optimus.ietf.org; Tue, 06 Jan 2004 09:27:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18992 for ; Tue, 6 Jan 2004 09:27:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdsBT-0006q5-00 for sip@ietf.org; Tue, 06 Jan 2004 09:27:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ads5p-0006fD-00 for sip@ietf.org; Tue, 06 Jan 2004 09:22:02 -0500 Received: from pooh.ulticom.com ([208.255.120.2] helo=chuckie.dgms.com) by ietf-mx with esmtp (Exim 4.12) id 1Ads1O-0006UE-00 for sip@ietf.org; Tue, 06 Jan 2004 09:17:26 -0500 Received: from pcasveren (localhost [127.0.0.1]) by chuckie.dgms.com (8.9.3/8.9.3) with SMTP id JAA26455; Tue, 6 Jan 2004 09:16:45 -0500 (EST) From: "Tolga Asveren" To: "Paul Kyzivat" Cc: Subject: RE: [Sip] Subscribe dialog and target refresh request Date: Tue, 6 Jan 2004 09:15:03 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <3FF9F36D.5060604@cisco.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit one question/comment below... > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Paul > Kyzivat > Sent: Monday, January 05, 2004 6:30 PM > To: Jonathan Rosenberg > Cc: Jussi.Turunen@nokia.com; nataraju.alilaghatta@wipro.com; > sanjsinh@cisco.com; sip@ietf.org > Subject: Re: [Sip] Subscribe dialog and target refresh request > > > > > Jonathan Rosenberg wrote: > > Yes, SUB and NOT are target refresh requests. > > > > However, the question that was asked, I think, had to do with > > establishing a second subscription in the context of a dialog > created by > > a first subscription. In such a case, a SUBSCRIBE or NOTIFY would be a > > target refresh request, but what state does it update? For > example, if a > > SUBSCRIBE refresh for the second subscription contains a new Contact, > > does that contact apply to both subscriptions, or just the > second one? I > > think its both, because the remote target is part of the dialog state, > > and there is but one dialog here. > > I agree. > > > However, I think its a much better idea to send a second > subscription on > > a different dialog, rather than trying to reuse an existing dialog. > > I think this actually depends on intent. If the subscriptions are > intended to be independent then I agree. OTOH, if it is important that > the subscriptions always be associated with the same UA even as that > moves around, then there is an advantage to using a single dialog. [TOLGA]Maybe it is not an issue totally black and white but I prefer to think that such associations are better done on application level, rather than relying them to be part of the same dialogue. I personally like the approach, to use dialogue construct more for on-the-wire SIP protocol procedures. Even for SUBSCRIBE in an INVITE initiated dialogue, IMO, those are two different signalling relationships, asociated on the application level, rather than on SIP signalling level -I am not saying it is wrong to send them on the same dialogue, just I think, one won't loose much, if they are sent on different one-. For that particular target refresh issue, there is maybe a minor advantage of sending only one target refresh message instead of two, if both SUBSCRIBESs (or INVITe and SUBSCRIBE) are sent as part of the same dialogue, but IMO this is insignifact. > > Its easier to find such cases in the sharing of a dialog between an > invite and a subscribe than it is between two subscribes. > > Paul > > > -Jonathan R. > > > > Jussi.Turunen@nokia.com wrote: > > > >> Hi > >> > >> > >>> For a dialog initiated with SUBSCRIBE, can a subscription for a new > >>> event on that dialog also be a target refresh request? > >>> > >>> [Natraj] No, it's not a Target refresh request. Target refresh could > >>> only happen either through INVITE or UPDATE requests.. > >> > >> > >> > >> There is a bug in RFC3265. Bug description > >> (http://bugs.sipit.net/sipwg/show_bug.cgi?id=699) says: > >> > >> "NOTIFY and SUBSCRIBE are target refresh requests > >> > >> ...but the text never says this explicitly." > >> > >> Haven't seen this bug closed yet... I remember some discussion on this > >> on this a while (a year or so) ago, so you might want to check the > >> archives for that. > >> > >> Jussi > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of sip > >> > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Jan 6 10:18:39 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21701 for ; Tue, 6 Jan 2004 10:18:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdsyB-0004lP-OY for sip-archive@odin.ietf.org; Tue, 06 Jan 2004 10:18:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i06FIBFo018307 for sip-archive@odin.ietf.org; Tue, 6 Jan 2004 10:18:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adsy1-0004kj-HI; Tue, 06 Jan 2004 10:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adsx1-0004jt-Rv for sip@optimus.ietf.org; Tue, 06 Jan 2004 10:17:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21573 for ; Tue, 6 Jan 2004 10:16:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Adswu-0001Bk-00 for sip@ietf.org; Tue, 06 Jan 2004 10:16:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdssV-0000tV-00 for sip@ietf.org; Tue, 06 Jan 2004 10:12:20 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1Adsmk-0000bC-00 for sip@ietf.org; Tue, 06 Jan 2004 10:06:22 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i06F5LK6017630; Tue, 6 Jan 2004 10:05:22 -0500 (EST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFA64802; Tue, 6 Jan 2004 10:05:20 -0500 (EST) Message-ID: <3FFACEB0.1050304@cisco.com> Date: Tue, 06 Jan 2004 10:05:20 -0500 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 CC: Jussi.Turunen@nokia.com, nataraju.alilaghatta@wipro.com, sanjsinh@cisco.com, sip@ietf.org Subject: Re: GRUU and UA instances, was: Re: [Sip] Subscribe dialog and target refresh request References: <3FF9DB9E.60702@dynamicsoft.com> <3FF9F36D.5060604@cisco.com> <3FFA5EE1.1050302@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > inline. > > Paul Kyzivat wrote: > > >>> However, I think its a much better idea to send a second subscription >>> on a different dialog, rather than trying to reuse an existing dialog. >> >> I think this actually depends on intent. If the subscriptions are >> intended to be independent then I agree. OTOH, if it is important that >> the subscriptions always be associated with the same UA even as that >> moves around, then there is an advantage to using a single dialog. >> >> Its easier to find such cases in the sharing of a dialog between an >> invite and a subscribe than it is between two subscribes. > > The GRUU would allow you to keep both dialogs attached to a particular > UA instance. Should the UA move around, it would require you to generate > a target refresh request on each dialog to update the Contact. Yes, this is another way to solve that problem. I am not especially attached to using shared dialogs this way once all the machinery to do otherwise is in place. OTOH, I don't think shared dialogs are going away, so they remain *a* way to solve this or related problems. > This, however, leads me into thinking a bit on the lifecycle management > for GRUUs. Currently, GRUU is bound to a single registration, where the > registration is defined by the Contact URI. If the UA should "move", in > the sense that it acquires a new IP address, this will be a new Contact > URI, and therefore, a new GRUU. It would be nice if, instead, the GRUU > were truly bound to the UA instance, and that even if the UA instance > changed IP addresses, the GRUU could remain unchanged. In such a case, > if the UA moves, there is actually no need to issue any target refresh > requests. The UA would simply re-register, update the binding of its > GRUU to its new IP address, and existing calls would be correctly routed. > > Indeed, this has the interesting benefit that, even if both UA in a call > should move at the same time, the call would still be able to continue, > since such updates are never propagated to the peer in the call. This seems to presume that address changes of this sort are common, and a frequent source of target refreshes. I don't have any useful data on the subject, but it seems likely to me that other reasons for target refreshes would be at least as significant. For instance load balancing. > For this to work, it would require that the registration have a way of > identifying the UA instance. This goes back to the instance identifier > we had (but removed) from callee-caps. If we added it, we could then > associate the GRUU with this ID, rather than the Contact URI. In other > words, if the client registered thusly: > > REGISTER > To: sip:user@example.com > Contact: sip:1.2.3.4;+instance-id="9asdd9a887sdasd=asd888a" > Supported: gruu > > the registrar would allocate a GRUU, and associate it with that instance > ID: > > 200 OK > Contact: > sip:1.2.3.4;+instance-id="9asdd9a887sdasd=asd888a";gruu=sip:f4@example.com > > Now, if the UA should update its registration because it moves: > > REGISTER > To: sip:user@example.com > Contact: sip:5.6.7.8;+instance-id="9asdd9a887sdasd=asd888a" > Contact: sip:1.2.3.4;expires=0 > > the registrar would return the *same* gruu for the new registration: > > 200 OK > Contact: > sip:5.6.7.8;+instance-id="9asdd9a887sdasd=asd888a";gruu=sip:f4@example.com > > > It is still possible for the registrar to not store additional state if > GRUU is defined this way. The GRUU URI would be computed thusly: > > sip:@example.com > > That is, the GRUU now encodes the instance ID. When a request is > received with a GRUU, the registrar extracts the instance ID. It then > looks up the registration corresponding to that instance ID, and obtains > its Contact URI. This doesnt require additional state per se, but does > require that the registration data be structured to allow lookups based > on the instance-id. > > Thoughts? In spite of my comment above, I think I like the general approach. However there may still be details to work out. Notably, your stateless algorithm won't work right if a UA uses the same instance id when registering with multiple AORs managed by the same registrar. (It could be fixed by using: sip:@example.com.) Going this way will also require careful specification of instance-id, but that is a useful exercise in any case. It will be important to specify what the uniqueness properties are for instance-ids, and to investigate what the implications are when they are violated. (Since it is easy to predict that they will be violated.) The implications on registrar data storage and retrieval are significant, but in practice most registrars will require some alternate access path like this in any case. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Jan 6 10:30:50 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22262 for ; Tue, 6 Jan 2004 10:30:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adt9y-0005GE-Ji for sip-archive@odin.ietf.org; Tue, 06 Jan 2004 10:30:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i06FUMdC020221 for sip-archive@odin.ietf.org; Tue, 6 Jan 2004 10:30:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adt9f-0005DV-Cj; Tue, 06 Jan 2004 10:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adt9P-0005CD-9U for sip@optimus.ietf.org; Tue, 06 Jan 2004 10:29:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22182 for ; Tue, 6 Jan 2004 10:29:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Adt9M-0001nZ-00 for sip@ietf.org; Tue, 06 Jan 2004 10:29:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Adt7V-0001iD-00 for sip@ietf.org; Tue, 06 Jan 2004 10:27:50 -0500 Received: from ckmso2.att.com ([209.219.209.75] helo=ckmso2.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1Adt5y-0001Wx-00 for sip@ietf.org; Tue, 06 Jan 2004 10:26:14 -0500 Received: from attrh0i.attrh.att.com ([135.37.94.54]) by ckmso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id i06FLUWZ031852 for ; Tue, 6 Jan 2004 10:25:15 -0500 Received: from acclust02evs1.ugd.att.com (135.37.16.8) by attrh0i.attrh.att.com (6.5.032) id 3FF847AA0005E10B; Tue, 6 Jan 2004 10:22:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: GRUU and UA instances, was: Re: [Sip] Subscribe dialog and target refresh request Date: Tue, 6 Jan 2004 10:25:14 -0500 Message-ID: <34DA635B184A644DA4588E260EC0A25A05DCE6A7@ACCLUST02EVS1.ugd.att.com> Thread-Topic: GRUU and UA instances, was: Re: [Sip] Subscribe dialog and target refresh request Thread-Index: AcPUJWXja5Y3y8BIS1mq255uvfkDnwAQkKLA From: "Roy, Radhika R, ALABS" To: "Jonathan Rosenberg" , "Paul Kyzivat" Cc: , , , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi, Jonathan: I agree. In fact, this should be the basic principle to address the mobility in the application layer. That is, the URL (e.g., rrroy@att.com) will remain the same no matter where the use moves, however, the IP address (layer 3) or addresses of the other lower layers may change. The change in lower "physical" addresses is called as the "change in point of contact." The point of contact at different (lower) layer may change for the mobile user (specially in the case of the terminal mobility), but its impact may or may not propagate in all upper layers. If the URL would have been kept same under all circumstances, it would have been the most elegant solution especially to address the problems of the terminal mobility. br, Radhika -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Tuesday, January 06, 2004 2:08 AM To: Paul Kyzivat Cc: Jussi.Turunen@nokia.com; nataraju.alilaghatta@wipro.com; sanjsinh@cisco.com; sip@ietf.org Subject: GRUU and UA instances, was: Re: [Sip] Subscribe dialog and target refresh request inline. Paul Kyzivat wrote: >> However, I think its a much better idea to send a second subscription >> on a different dialog, rather than trying to reuse an existing dialog. >=20 >=20 > I think this actually depends on intent. If the subscriptions are=20 > intended to be independent then I agree. OTOH, if it is important that > the subscriptions always be associated with the same UA even as that=20 > moves around, then there is an advantage to using a single dialog. >=20 > Its easier to find such cases in the sharing of a dialog between an=20 > invite and a subscribe than it is between two subscribes. The GRUU would allow you to keep both dialogs attached to a particular=20 UA instance. Should the UA move around, it would require you to=20 generate a target refresh request on each dialog to update the Contact. This, however, leads me into thinking a bit on the lifecycle=20 management for GRUUs. Currently, GRUU is bound to a single=20 registration, where the registration is defined by the Contact URI. If=20 the UA should "move", in the sense that it acquires a new IP address,=20 this will be a new Contact URI, and therefore, a new GRUU. It would be=20 nice if, instead, the GRUU were truly bound to the UA instance, and=20 that even if the UA instance changed IP addresses, the GRUU could=20 remain unchanged. In such a case, if the UA moves, there is actually=20 no need to issue any target refresh requests. The UA would simply=20 re-register, update the binding of its GRUU to its new IP address, and=20 existing calls would be correctly routed. Indeed, this has the interesting benefit that, even if both UA in a=20 call should move at the same time, the call would still be able to=20 continue, since such updates are never propagated to the peer in the=20 call. For this to work, it would require that the registration have a way of=20 identifying the UA instance. This goes back to the instance identifier=20 we had (but removed) from callee-caps. If we added it, we could then=20 associate the GRUU with this ID, rather than the Contact URI. In other=20 words, if the client registered thusly: REGISTER To: sip:user@example.com Contact: sip:1.2.3.4;+instance-id=3D"9asdd9a887sdasd=3Dasd888a" Supported: gruu the registrar would allocate a GRUU, and associate it with that=20 instance ID: 200 OK Contact:=20 sip:1.2.3.4;+instance-id=3D"9asdd9a887sdasd=3Dasd888a";gruu=3Dsip:f4@exam= ple.c om Now, if the UA should update its registration because it moves: REGISTER To: sip:user@example.com Contact: sip:5.6.7.8;+instance-id=3D"9asdd9a887sdasd=3Dasd888a" Contact: sip:1.2.3.4;expires=3D0 the registrar would return the *same* gruu for the new registration: 200 OK Contact:=20 sip:5.6.7.8;+instance-id=3D"9asdd9a887sdasd=3Dasd888a";gruu=3Dsip:f4@exam= ple.c om It is still possible for the registrar to not store additional state=20 if GRUU is defined this way. The GRUU URI would be computed thusly: sip:@example.com That is, the GRUU now encodes the instance ID. When a request is=20 received with a GRUU, the registrar extracts the instance ID. It then=20 looks up the registration corresponding to that instance ID, and=20 obtains its Contact URI. This doesnt require additional state per se,=20 but does require that the registration data be structured to allow=20 lookups based on the instance-id. Thoughts? -Jonathan R. >=20 > Paul >=20 >> -Jonathan R. >> >> Jussi.Turunen@nokia.com wrote: >> >>> Hi >>> >>> >>>> For a dialog initiated with SUBSCRIBE, can a subscription for a new >>>> event on that dialog also be a target refresh request? >>>> >>>> [Natraj] No, it's not a Target refresh request. Target refresh could >>>> only happen either through INVITE or UPDATE requests.. >>> >>> >>> >>> >>> There is a bug in RFC3265. Bug description=20 >>> (http://bugs.sipit.net/sipwg/show_bug.cgi?id=3D699) says: >>> >>> "NOTIFY and SUBSCRIBE are target refresh requests >>> >>> ...but the text never says this explicitly." >>> >>> Haven't seen this bug closed yet... I remember some discussion on=20 >>> this on this a while (a year or so) ago, so you might want to check=20 >>> the archives for that. >>> >>> Jussi >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> >> >=20 --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Jan 6 15:01:03 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00871 for ; Tue, 6 Jan 2004 15:01:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdxNQ-0006st-1u for sip-archive@odin.ietf.org; Tue, 06 Jan 2004 15:00:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i06K0VBP026403 for sip-archive@odin.ietf.org; Tue, 6 Jan 2004 15:00:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdxMy-0006qT-1q; Tue, 06 Jan 2004 15:00:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdxMh-0006pF-I6 for sip@optimus.ietf.org; Tue, 06 Jan 2004 14:59:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00832 for ; Tue, 6 Jan 2004 14:59:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdxMe-0005yh-00 for sip@ietf.org; Tue, 06 Jan 2004 14:59:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdxKn-0005vw-00 for sip@ietf.org; Tue, 06 Jan 2004 14:57:50 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1AdxJn-0005tF-00 for sip@ietf.org; Tue, 06 Jan 2004 14:56:47 -0500 Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se [138.85.133.52]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id i06Ju9Yb021387; Tue, 6 Jan 2004 13:56:09 -0600 (CST) Received: from noah.lmc.ericsson.se ([142.133.1.1]) by eamrcnt751.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id Y2CAKZ7F; Tue, 6 Jan 2004 13:55:27 -0600 Received: from EAMMLEX034.lmc.ericsson.se (eammlex034.lmc.ericsson.se [142.133.1.134]) by noah.lmc.ericsson.se (8.12.10/8.12.10) with ESMTP id i06Ju8bD019128; Tue, 6 Jan 2004 14:56:08 -0500 (EST) Received: by eammlex034.lmc.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 6 Jan 2004 14:56:08 -0500 Message-ID: <2DBF697D5B36014ABA46E66A96107DA02C9417@lmc37.lmc.ericsson.se> From: "George Foti (QC/EMC)" To: "'jdrosen@dynamicsoft.com'" , sip@ietf.org Date: Tue, 6 Jan 2004 14:55:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Sip] Clarification on Presence Use Case in draft-ietf-sip-gruu-00 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi, The presence use case (section 4.3) indicates that the GRUU, representing the contact URI in the tuple information included in the presence document, needs to be generated by a presence agent. I am unclear as to why this needs to be the case. The UA can publish a GRUU it acquired from a registrar to the presence agent. The registrar will be consulted at call routing to make sure that it gets routed to the proper UA associated with the GRUU. Did I misunderstand something ? Thanks/gf _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Jan 6 15:52:39 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03363 for ; Tue, 6 Jan 2004 15:52:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdyBP-0000lD-5J for sip-archive@odin.ietf.org; Tue, 06 Jan 2004 15:52:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i06KqB8x002862 for sip-archive@odin.ietf.org; Tue, 6 Jan 2004 15:52:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdyBF-0000jA-AN; Tue, 06 Jan 2004 15:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdyAx-0000ij-Ub for sip@optimus.ietf.org; Tue, 06 Jan 2004 15:51:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03351 for ; Tue, 6 Jan 2004 15:51:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdyAw-0007lY-00 for sip@ietf.org; Tue, 06 Jan 2004 15:51:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ady93-0007jb-00 for sip@ietf.org; Tue, 06 Jan 2004 15:49:46 -0500 Received: from mail.ee.gatech.edu ([130.207.225.105]) by ietf-mx with esmtp (Exim 4.12) id 1Ady8B-0007hi-00 for sip@ietf.org; Tue, 06 Jan 2004 15:48:51 -0500 Received: from yamsrv2.ece.gatech.edu (yamsrv2.ece.gatech.edu [130.207.232.10]) by mail.ee.gatech.edu (8.12.10/8.12.10) with ESMTP id i06Kmfo1024991 for ; Tue, 6 Jan 2004 15:48:41 -0500 (EST) Received: from localhost (ana@localhost) by yamsrv2.ece.gatech.edu (8.12.0.Beta19/8.12.0.Beta19/Submit) with ESMTP id i06KmffC007026 for ; Tue, 6 Jan 2004 15:48:41 -0500 (EST) Date: Tue, 6 Jan 2004 15:48:41 -0500 (EST) From: "Ana Elisa P. Goulart" To: sip@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-SPAM: NO X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Sip] Question about the beginning of the media session Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi, I have a basic SIP question about the actual beginning of the media session following an INVITE transaction. In section 13.1 (Initiating a Session), the RFC says that "a 2xx response to an INVITE establishes a session". My question is whether this applies to the time the UAC receives the final 2xx response or the time the UAS sends the 2xx response or both. In other words, from the UAS's perspective, is it correct to assume that the actual media transmission can begin after the 2xx response is sent (before the ACK is received) ? Thanks a lot, Ana -- Ana Elisa P. Goulart The School of Electrical and Computer Engineering at Georgia Tech Atlanta, GA 30332-0250 E-Mail: ana@ece.gatech.edu, gt8722a@prism.gatech.edu _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Jan 6 17:05:54 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06277 for ; Tue, 6 Jan 2004 17:05:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdzKJ-00042I-H7 for sip-archive@odin.ietf.org; Tue, 06 Jan 2004 17:05:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i06M5RWY015513 for sip-archive@odin.ietf.org; Tue, 6 Jan 2004 17:05:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdzJz-00041F-Dr; Tue, 06 Jan 2004 17:05:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdzJI-0003xL-FL for sip@optimus.ietf.org; Tue, 06 Jan 2004 17:04:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06248 for ; Tue, 6 Jan 2004 17:04:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdzJG-000344-00 for sip@ietf.org; Tue, 06 Jan 2004 17:04:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdzIP-0002wB-00 for sip@ietf.org; Tue, 06 Jan 2004 17:03:29 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AdzG8-0002jp-00 for sip@ietf.org; Tue, 06 Jan 2004 17:01:08 -0500 Received: from dynamicsoft.com ([63.113.46.36]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i06M0CmR010074; Tue, 6 Jan 2004 17:00:13 -0500 (EST) Message-ID: <3FFB2FE7.60505@dynamicsoft.com> Date: Tue, 06 Jan 2004 17:00:07 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Roy, Radhika R, ALABS" CC: Paul Kyzivat , Jussi.Turunen@nokia.com, nataraju.alilaghatta@wipro.com, sanjsinh@cisco.com, sip@ietf.org Subject: Re: GRUU and UA instances, was: Re: [Sip] Subscribe dialog and target refresh request References: <34DA635B184A644DA4588E260EC0A25A05DCE6A7@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <34DA635B184A644DA4588E260EC0A25A05DCE6A7@ACCLUST02EVS1.ugd.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline. Roy, Radhika R, ALABS wrote: > Hi, Jonathan: > > I agree. In fact, this should be the basic principle to address the > mobility in the application layer. That is, the URL (e.g., > rrroy@att.com) will remain the same no matter where the use moves, > however, the IP address (layer 3) or addresses of the other lower layers > may change. > > The change in lower "physical" addresses is called as the "change in > point of contact." The point of contact at different (lower) layer may > change for the mobile user (specially in the case of the terminal > mobility), but its impact may or may not propagate in all upper layers. > > If the URL would have been kept same under all circumstances, it would > have been the most elegant solution especially to address the problems > of the terminal mobility. Right. The principal value of this approach would be to allow for application layer SIP mobility. Effectively, the Contact URI/GRUU would join the AOR as a URI that is independent of the point of attachment of the UA. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Jan 6 17:12:38 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06515 for ; Tue, 6 Jan 2004 17:12:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdzQp-0004fl-TI for sip-archive@odin.ietf.org; Tue, 06 Jan 2004 17:12:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i06MCBrj017958 for sip-archive@odin.ietf.org; Tue, 6 Jan 2004 17:12:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdzQe-0004el-Uw; Tue, 06 Jan 2004 17:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdzQS-0004dP-RY for sip@optimus.ietf.org; Tue, 06 Jan 2004 17:11:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06465 for ; Tue, 6 Jan 2004 17:11:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdzQQ-0003Gp-00 for sip@ietf.org; Tue, 06 Jan 2004 17:11:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdzOW-0003Dc-00 for sip@ietf.org; Tue, 06 Jan 2004 17:09:49 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AdzMu-00037w-00 for sip@ietf.org; Tue, 06 Jan 2004 17:08:08 -0500 Received: from dynamicsoft.com ([63.113.46.36]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i06M7amR010087; Tue, 6 Jan 2004 17:07:36 -0500 (EST) Message-ID: <3FFB31A2.3000701@dynamicsoft.com> Date: Tue, 06 Jan 2004 17:07:30 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Jussi.Turunen@nokia.com, nataraju.alilaghatta@wipro.com, sanjsinh@cisco.com, sip@ietf.org Subject: Re: GRUU and UA instances, was: Re: [Sip] Subscribe dialog and target refresh request References: <3FF9DB9E.60702@dynamicsoft.com> <3FF9F36D.5060604@cisco.com> <3FFA5EE1.1050302@dynamicsoft.com> <3FFACEB0.1050304@cisco.com> In-Reply-To: <3FFACEB0.1050304@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > >> >> The GRUU would allow you to keep both dialogs attached to a particular >> UA instance. Should the UA move around, it would require you to >> generate a target refresh request on each dialog to update the Contact. > > > Yes, this is another way to solve that problem. I am not especially > attached to using shared dialogs this way once all the machinery to do > otherwise is in place. OTOH, I don't think shared dialogs are going > away, so they remain *a* way to solve this or related problems. Well, I would prefer one way rather than two, but we've already beaten this horse a bit... > >> This, however, leads me into thinking a bit on the lifecycle >> management for GRUUs. Currently, GRUU is bound to a single >> registration, where the registration is defined by the Contact URI. If >> the UA should "move", in the sense that it acquires a new IP address, >> this will be a new Contact URI, and therefore, a new GRUU. It would be >> nice if, instead, the GRUU were truly bound to the UA instance, and >> that even if the UA instance changed IP addresses, the GRUU could >> remain unchanged. In such a case, if the UA moves, there is actually >> no need to issue any target refresh requests. The UA would simply >> re-register, update the binding of its GRUU to its new IP address, and >> existing calls would be correctly routed. >> >> Indeed, this has the interesting benefit that, even if both UA in a >> call should move at the same time, the call would still be able to >> continue, since such updates are never propagated to the peer in the >> call. > > > This seems to presume that address changes of this sort are common, and > a frequent source of target refreshes. Right. In particular I was thinking about application layer mobility. For WiFi SIP phones, this would be particularly attractive, I think. > > I don't have any useful data on the subject, but it seems likely to me > that other reasons for target refreshes would be at least as > significant. For instance load balancing. Sure. There too, you get interesting benefits from using GRUUs that are not bound to a specific IP address. You could migrate subscriptions from one server to another without needing to inform the watcher; you simply change the routing logic for the gruu to instead route to the server that will now handle the subscription (of course, you would have to have taken care of transferring subscription state in all cases). > >> For this to work, it would require that the registration have a way of >> identifying the UA instance. This goes back to the instance identifier >> we had (but removed) from callee-caps. If we added it, we could then >> associate the GRUU with this ID, rather than the Contact URI. In other >> words, if the client registered thusly: >> >> REGISTER >> To: sip:user@example.com >> Contact: sip:1.2.3.4;+instance-id="9asdd9a887sdasd=asd888a" >> Supported: gruu >> >> the registrar would allocate a GRUU, and associate it with that >> instance ID: >> >> 200 OK >> Contact: >> sip:1.2.3.4;+instance-id="9asdd9a887sdasd=asd888a";gruu=sip:f4@example.com >> >> >> Now, if the UA should update its registration because it moves: >> >> REGISTER >> To: sip:user@example.com >> Contact: sip:5.6.7.8;+instance-id="9asdd9a887sdasd=asd888a" >> Contact: sip:1.2.3.4;expires=0 >> >> the registrar would return the *same* gruu for the new registration: >> >> 200 OK >> Contact: >> sip:5.6.7.8;+instance-id="9asdd9a887sdasd=asd888a";gruu=sip:f4@example.com >> >> >> >> It is still possible for the registrar to not store additional state >> if GRUU is defined this way. The GRUU URI would be computed thusly: >> >> sip:@example.com >> >> That is, the GRUU now encodes the instance ID. When a request is >> received with a GRUU, the registrar extracts the instance ID. It then >> looks up the registration corresponding to that instance ID, and >> obtains its Contact URI. This doesnt require additional state per se, >> but does require that the registration data be structured to allow >> lookups based on the instance-id. >> >> Thoughts? > > > In spite of my comment above, I think I like the general approach. > However there may still be details to work out. Notably, your stateless > algorithm won't work right if a UA uses the same instance id when > registering with multiple AORs managed by the same registrar. > > (It could be fixed by using: sip:@example.com.) This is much better. Another benefit of doing this is that you could extract the AOR, look up the user, and then just do a search of the existing contacts to see which one matched the instance-id. It would mean that one could add support for gruus, and be stateless, without changing the existing schemas for the back-end data stores (I am making some assumptions about how the schema looks). > > Going this way will also require careful specification of instance-id, > but that is a useful exercise in any case. It will be important to > specify what the uniqueness properties are for instance-ids, and to > investigate what the implications are when they are violated. (Since it > is easy to predict that they will be violated.) We can also be sure that there will be cases where the same UA instance uses different instance IDs over time. This is particularly likely with software agents. > > The implications on registrar data storage and retrieval are > significant, but in practice most registrars will require some alternate > access path like this in any case. See above - I think with your proposal they can be minimized. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Jan 7 09:03:57 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09791 for ; Wed, 7 Jan 2004 09:03:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeEHR-000484-Do for sip-archive@odin.ietf.org; Wed, 07 Jan 2004 09:03:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07E3TpV015871 for sip-archive@odin.ietf.org; Wed, 7 Jan 2004 09:03:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeEH0-00046z-EJ; Wed, 07 Jan 2004 09:03:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeEGk-000466-5b for sip@optimus.ietf.org; Wed, 07 Jan 2004 09:02:46 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09773; Wed, 7 Jan 2004 09:02:43 -0500 (EST) Message-Id: <200401071402.JAA09773@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 07 Jan 2004 09:02:43 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-callee-caps-03.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Indicating User Agent Capabilities in the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg Filename : draft-ietf-sip-callee-caps-03.txt Pages : 45 Date : 2004-1-6 This specification defines mechanisms by which a Session Initiation Protocol (SIP) user agent can convey its capabilities and characteristics to other user agents. These capabilities are conveyed as parameters of the Contact header field. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-callee-caps-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-callee-caps-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-callee-caps-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-6142544.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-callee-caps-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-callee-caps-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-6142544.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Jan 7 13:19:54 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23330 for ; Wed, 7 Jan 2004 13:19:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeIH9-0001Wf-0n for sip-archive@odin.ietf.org; Wed, 07 Jan 2004 13:19:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07IJQ14005804 for sip-archive@odin.ietf.org; Wed, 7 Jan 2004 13:19:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeIGk-0001Pw-NA; Wed, 07 Jan 2004 13:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeIGI-0001OP-4z for sip@optimus.ietf.org; Wed, 07 Jan 2004 13:18:34 -0500 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23274 for ; Wed, 7 Jan 2004 13:18:30 -0500 (EST) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1AeIFH-00039V-9Z; Wed, 07 Jan 2004 13:17:31 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , Message-Id: Date: Wed, 07 Jan 2004 13:17:31 -0500 Subject: [Sip] Protocol Action: 'Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)' to Proposed Standard Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , The IESG has approved following document: - 'Indicating User Agent Capabilities in the Session Initiation Protocol (SIP) ' 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 specification defines mechanisms by which a Session Initiation Protocol (SIP) user agent can convey its capabilities and characteristics to other user agents and to the registrar for its domain. This information is conveyed as parameters of the Contact header field. It may be used by a proxy for call routing. The parameter design is based on RFC 2506, media feature tags. The specification creates a SIP tree registry parallel to the IETF tree registry from RFC 2506. The syntax of the parameters is based on RFC 2533. Strong considerations regarding the privacy and data integrity of the information are discussed by the document. Working Group Summary The working group took a lot of care and review developing this design. There was a mid-course design review from an Applications area standpoint that resulted in the advice to work with the RFC 2533, 2506 approach, which has proved to be very constructive. The WG supported the advancement strongly, after thorough review. Protocol Quality The document was reviewed for the IESG by Allison Mankin. The Applications mid-course reviews were by Patrik Faltstrom and Ted Hardie. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Jan 7 16:02:50 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01705 for ; Wed, 7 Jan 2004 16:02:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeKoo-0000pN-0Z for sip-archive@odin.ietf.org; Wed, 07 Jan 2004 16:02:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07L2Lep003171 for sip-archive@odin.ietf.org; Wed, 7 Jan 2004 16:02:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeKoW-0000im-Gh; Wed, 07 Jan 2004 16:02:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeKoL-0000he-F5 for sip@optimus.ietf.org; Wed, 07 Jan 2004 16:01:53 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01563; Wed, 7 Jan 2004 16:01:50 -0500 (EST) Message-Id: <200401072101.QAA01563@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 07 Jan 2004 16:01:50 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-publish-02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Session Initiation Protocol (SIP) Extension for Event State Publication Author(s) : A. Niemi Filename : draft-ietf-sip-publish-02.txt Pages : 39 Date : 2004-1-7 This document describes an extension to the Session Initiation Protocol (SIP) for publishing event state used within the framework for SIP Event Notification. The first application of this extension is targeted at the publication of presence information. The mechanism described in this document can be extended to support publication of any event state, for which there exists an appropriate event package. It is not intended to be a general-purpose mechanism for transport of arbitrary data, as there are better-suited mechanisms for this purpose (FTP, HTTP, etc.) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-publish-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-publish-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-publish-02.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: <2004-1-7153204.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-publish-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-publish-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-7153204.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Jan 7 16:50:36 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01707 for ; Wed, 7 Jan 2004 16:02:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeKoo-0000pP-1A for sip-archive@odin.ietf.org; Wed, 07 Jan 2004 16:02:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07L2L5A003172 for sip-archive@odin.ietf.org; Wed, 7 Jan 2004 16:02:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeKoV-0000iZ-24; Wed, 07 Jan 2004 16:02:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeKoG-0000hY-7w for sip@optimus.ietf.org; Wed, 07 Jan 2004 16:01:48 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01546; Wed, 7 Jan 2004 16:01:45 -0500 (EST) Message-Id: <200401072101.QAA01546@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 07 Jan 2004 16:01:45 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-gruu-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg Filename : draft-ietf-sip-gruu-00.txt Pages : 20 Date : 2004-1-7 Several applications of the Session Initiation Protocol (SIP) require a user agent (UA) to construct and distribute a URI which can be used by anyone on the Internet to route a call to that specific UA instance. A URI which routes to a specific UA instance is called a Globally Routable UA URI (GRUU). This document describes an extension to SIP for obtaining a GRUU from a server, and for communicating a GRUU to a peer within a dialog. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-gruu-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-gruu-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-7152806.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-gruu-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-gruu-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-7152806.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Jan 7 23:10:54 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22872 for ; Wed, 7 Jan 2004 23:10:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeRV4-00058F-Kb for sip-archive@odin.ietf.org; Wed, 07 Jan 2004 23:10:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i084AQ2m019728 for sip-archive@odin.ietf.org; Wed, 7 Jan 2004 23:10:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeRTk-00056F-LP; Wed, 07 Jan 2004 23:09:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeRT1-00050o-Pd for sip@optimus.ietf.org; Wed, 07 Jan 2004 23:08:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22834 for ; Wed, 7 Jan 2004 23:08:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeRSw-0006PR-00 for sip@ietf.org; Wed, 07 Jan 2004 23:08:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeRRY-0006Ml-00 for sip@ietf.org; Wed, 07 Jan 2004 23:06:49 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AeRQ2-0006IY-00 for sip@ietf.org; Wed, 07 Jan 2004 23:05:14 -0500 Received: from dynamicsoft.com ([63.113.46.48]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i0844lmR010837; Wed, 7 Jan 2004 23:04:47 -0500 (EST) Message-ID: <3FFCD6D9.2010200@dynamicsoft.com> Date: Wed, 07 Jan 2004 23:04:41 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "George Foti (QC/EMC)" CC: sip@ietf.org References: <2DBF697D5B36014ABA46E66A96107DA02C9417@lmc37.lmc.ericsson.se> In-Reply-To: <2DBF697D5B36014ABA46E66A96107DA02C9417@lmc37.lmc.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Clarification on Presence Use Case in draft-ietf-sip-gruu-00 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline. George Foti (QC/EMC) wrote: > Hi, > > The presence use case (section 4.3) indicates that the GRUU, > representing the contact URI in the tuple information included in > the presence document, needs to be generated by a presence agent. > > I am unclear as to why this needs to be the case. > > The UA can publish a GRUU it acquired from a registrar to the > presence agent. The registrar will be consulted at call routing to > make sure that it gets routed to the proper UA associated with the > GRUU. > > Did I misunderstand something ? It depends on how the composition is done. There may be cases where the PA needs to construct a URI that was no supplied by the UA. In other cases, a published GRUU would suffice. I've clarified. The text now reads: It is interesting to note that the GRUU may need to be constructed by a presence agent, depending on how the presence document is computed by the server. I think its probably a good idea for the presence document use cases draft being done in SIMPLE to talk about publishing presence documents with gruus. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jan 8 07:59:47 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21706 for ; Thu, 8 Jan 2004 07:59:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeZkp-0005w1-2O for sip-archive@odin.ietf.org; Thu, 08 Jan 2004 07:59:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i08CxFFl022810 for sip-archive@odin.ietf.org; Thu, 8 Jan 2004 07:59:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeZkb-0005uw-CT; Thu, 08 Jan 2004 07:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeZjz-0005tS-Qw for sip@optimus.ietf.org; Thu, 08 Jan 2004 07:58:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21670 for ; Thu, 8 Jan 2004 07:58:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeZjy-0000gx-00 for sip@ietf.org; Thu, 08 Jan 2004 07:58:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeZi5-0000Zj-00 for sip@ietf.org; Thu, 08 Jan 2004 07:56:25 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1AeZgD-0000Qt-00 for sip@ietf.org; Thu, 08 Jan 2004 07:54:29 -0500 Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se [138.85.133.52]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id i08CrqYb018848; Thu, 8 Jan 2004 06:53:52 -0600 (CST) Received: from noah.lmc.ericsson.se ([142.133.1.1]) by eamrcnt751.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id Y2CAQS1H; Thu, 8 Jan 2004 06:53:08 -0600 Received: from EAMMLEX034.lmc.ericsson.se (eammlex034.lmc.ericsson.se [142.133.1.134]) by noah.lmc.ericsson.se (8.12.10/8.12.10) with ESMTP id i08CrpbD025489; Thu, 8 Jan 2004 07:53:51 -0500 (EST) Received: by eammlex034.lmc.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 8 Jan 2004 07:53:51 -0500 Message-ID: <2DBF697D5B36014ABA46E66A96107DA02C941F@lmc37.lmc.ericsson.se> From: "George Foti (QC/EMC)" To: "'Jonathan Rosenberg'" Cc: sip@ietf.org Date: Thu, 8 Jan 2004 07:53:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Sip] RE: Clarification on Presence Use Case in draft-ietf-sip-gruu-00 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Comments inline > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, January 07, 2004 11:05 PM > To: George Foti (QC/EMC) > Cc: sip@ietf.org > Subject: Re: Clarification on Presence Use Case in > draft-ietf-sip-gruu-00 > > > inline. > > George Foti (QC/EMC) wrote: > > > Hi, > > > > The presence use case (section 4.3) indicates that the GRUU, > > representing the contact URI in the tuple information included in > > the presence document, needs to be generated by a presence agent. > > > > I am unclear as to why this needs to be the case. > > > > The UA can publish a GRUU it acquired from a registrar to the > > presence agent. The registrar will be consulted at call routing to > > make sure that it gets routed to the proper UA associated with the > > GRUU. > > > > Did I misunderstand something ? > > It depends on how the composition is done. There may be cases where > the PA needs to construct a URI that was no supplied by the UA. In > other cases, a published GRUU would suffice. I've clarified. The text > now reads: > > It is interesting to note that the GRUU may need to be > constructed by a presence agent, depending on how the > presence document is > computed by the server. > I like that better. > > > I think its probably a good idea for the presence document use cases > draft being done in SIMPLE to talk about publishing presence > documents > with gruus. > It is definitely needed to be added in there. > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jan 8 10:13:42 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26969 for ; Thu, 8 Jan 2004 10:13:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AebqU-0004Dp-76 for sip-archive@odin.ietf.org; Thu, 08 Jan 2004 10:13:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i08FDEj5016223 for sip-archive@odin.ietf.org; Thu, 8 Jan 2004 10:13:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AebqH-0004CH-U1; Thu, 08 Jan 2004 10:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aebpn-0004BT-VC for sip@optimus.ietf.org; Thu, 08 Jan 2004 10:12:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26833 for ; Thu, 8 Jan 2004 10:12:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aebpl-0000gM-00 for sip@ietf.org; Thu, 08 Jan 2004 10:12:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aebo3-0000bJ-00 for sip@ietf.org; Thu, 08 Jan 2004 10:10:43 -0500 Received: from liszt-01.ednet.co.uk ([212.20.226.18] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1Aebmf-0000X6-00 for sip@ietf.org; Thu, 08 Jan 2004 10:09:17 -0500 Received: from liszt-01.ednet.co.uk (mail.ednet.co.uk [212.20.226.52]) by liszt-01.ednet.co.uk (Postfix) with ESMTP id B63703B847; Thu, 8 Jan 2004 15:09:16 +0000 (GMT) Received: from gilbert.ednet.co.uk (gilbert.ednet.co.uk [212.20.231.234]) by liszt-01.ednet.co.uk (postfixfilterd/14247) id VQMVXTFHPZ; Thu, 08 Jan 2004 15:09:16 +0000 (GMT) Received: from Azopardi (azopardi.ednet.co.uk [212.20.231.227]) by gilbert.ednet.co.uk (Postfix) with ESMTP id E78B4164006; Thu, 8 Jan 2004 15:09:15 +0000 (GMT) Reply-To: From: "Suha Cubukcuoglu" To: Cc: "edNET Telco" Date: Thu, 8 Jan 2004 15:06:10 -0000 Organization: edNET Message-ID: <003a01c3d5f8$f326fc50$e3e714d4@Azopardi> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Comment: Virus scanned by edNET X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=EXCUSE_16,OFFERS_ETC autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] 1xx Provisional Responses Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, In the RFC for SIP (#3261) it is stated that 1xx provisional responses are not transmitted reliably and never cause the client to send an ACK message. SIP clients use UDP to send messages across networks. Therefore, for example, '180 Ringing' message may or may reach the calling party without the called party recognizing whether the message has reached its destination. This has adverse effects in terms of call setup and usability. If the 180 Ringing message is lost in the network while the called party is ringing, the calling party will have no idea what state the call is in at any time (e.g. one could think they dialed a wrong number, or its taking too long to contact the other end, etc.). '180 Ringing' message, in our opinion, should be treated as a critical message just like INVITE and 200 OK or the called party must send multiple '180 Ringing' messages, instead of just one, to make sure the other end will receive the message one way or other. Could you please tell us your comments about this? Thanks very much. Regards, Suha Cubukcuoglu nplusone t: +44 131 514 2000 d: +44 131 514 4037 -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. Any offers or quotation of service are subject to formal specification. Errors and omissions excepted. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of edNET or lightershade ltd. Finally, the recipient should check this email and any attachments for the presence of viruses. edNET and lightershade ltd accepts no liability for any damage caused by any virus transmitted by this email. -- -- Virus scanned by edNET. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jan 8 10:32:40 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27892 for ; Thu, 8 Jan 2004 10:32:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aec8r-0005GC-9Y for sip-archive@odin.ietf.org; Thu, 08 Jan 2004 10:32:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i08FWDeK020218 for sip-archive@odin.ietf.org; Thu, 8 Jan 2004 10:32:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aec8g-0005Ds-Qm; Thu, 08 Jan 2004 10:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aec7m-0005D4-Sk for sip@optimus.ietf.org; Thu, 08 Jan 2004 10:31:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27823 for ; Thu, 8 Jan 2004 10:30:53 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aec7U-0001ce-00 for sip@ietf.org; Thu, 08 Jan 2004 10:30:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aec3z-0001LI-00 for sip@ietf.org; Thu, 08 Jan 2004 10:27:11 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AebwE-000110-00 for sip@ietf.org; Thu, 08 Jan 2004 10:19:10 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i08FIw621000 for ; Thu, 8 Jan 2004 17:18:59 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 8 Jan 2004 17:18:49 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 8 Jan 2004 17:18:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] 1xx Provisional Responses Date: Thu, 8 Jan 2004 17:18:48 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797595@esebe019.ntc.nokia.com> Thread-Topic: [Sip] 1xx Provisional Responses thread-index: AcPV+gAHhIUScsHYSP2bofTeEZrmlQAAHsHw To: , Cc: X-OriginalArrivalTime: 08 Jan 2004 15:18:48.0449 (UTC) FILETIME=[B6F3FF10:01C3D5FA] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,EXCUSE_16,NO_REAL_NAME, OFFERS_ETC autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable You can certainly send 180 responses periodically until you send a final = response. If you really want to send provisional responses reliably, then please = look at RFC3262. Regards, Hisham > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of ext > Suha Cubukcuoglu > Sent: 08.January.2004 17:06 > To: sip@ietf.org > Cc: edNET Telco > Subject: [Sip] 1xx Provisional Responses >=20 >=20 > Hi, >=20 > In the RFC for SIP (#3261) it is stated that 1xx provisional responses > are not transmitted reliably and never cause the client to send an ACK > message. SIP clients use UDP to send messages across networks. > Therefore, for example, '180 Ringing' message may or may reach the > calling party without the called party recognizing whether the message > has reached its destination. This has adverse effects in terms of call > setup and usability. If the 180 Ringing message is lost in the network > while the called party is ringing, the calling party will have no idea > what state the call is in at any time (e.g. one could think=20 > they dialed > a wrong number, or its taking too long to contact the other=20 > end, etc.). > '180 Ringing' message, in our opinion, should be treated as a critical > message just like INVITE and 200 OK or the called party must send > multiple '180 Ringing' messages, instead of just one, to make sure the > other end will receive the message one way or other.=20 >=20 > Could you please tell us your comments about this? >=20 > Thanks very much. >=20 > Regards, >=20 > Suha Cubukcuoglu > nplusone > t: +44 131 514 2000 > d: +44 131 514 4037 >=20 > --=20 >=20 > This email and any files transmitted with it are confidential=20 > and intended > solely for the use of the individual or entity to whom they=20 > are addressed. > If you have received this email in error please notify the sender. Any > offers or quotation of service are subject to formal specification. > Errors and omissions excepted. Please note that any views or opinions > presented in this email are solely those of the author and do not > necessarily represent those of edNET or lightershade ltd. Finally, the > recipient should check this email and any attachments for the=20 > presence of > viruses. edNET and lightershade ltd accepts no liability for=20 > any damage > caused by any virus transmitted by this email. >=20 > --=20 > --=20 > Virus scanned by edNET. >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jan 8 10:41:35 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28484 for ; Thu, 8 Jan 2004 10:41:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AecHU-0006TK-0h for sip-archive@odin.ietf.org; Thu, 08 Jan 2004 10:41:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i08Ff7j1024869 for sip-archive@odin.ietf.org; Thu, 8 Jan 2004 10:41:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AecHP-0006S9-Ff; Thu, 08 Jan 2004 10:41:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AecHI-0006RX-5i for sip@optimus.ietf.org; Thu, 08 Jan 2004 10:40:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28460 for ; Thu, 8 Jan 2004 10:40:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AecH5-00026I-00 for sip@ietf.org; Thu, 08 Jan 2004 10:40:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AecBB-0001lJ-00 for sip@ietf.org; Thu, 08 Jan 2004 10:34:38 -0500 Received: from mail01.corp.tellme.com ([209.157.157.98]) by ietf-mx with esmtp (Exim 4.12) id 1Aec5V-0001N2-00 for sip@ietf.org; Thu, 08 Jan 2004 10:28:45 -0500 Received: from mail01.corp.tellme.com (localhost [127.0.0.1]) by localhost.corp.tellme.com (Postfix) with ESMTP id 562B97EC53; Thu, 8 Jan 2004 07:27:47 -0800 (PST) Received: from spider (xshell02.corp.tellme.com [209.157.157.73]) by mail01.corp.tellme.com (Postfix) with SMTP id 3DA997EC19; Thu, 8 Jan 2004 07:27:45 -0800 (PST) From: "Greg Scallan" To: , Cc: "edNET Telco" Subject: RE: [Sip] 1xx Provisional Responses Date: Thu, 8 Jan 2004 10:26:21 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <003a01c3d5f8$f326fc50$e3e714d4@Azopardi> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=EXCUSE_16,OFFERS_ETC autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable See RFC 3262 (http://www.ietf.org/rfc/rfc3262.txt), Reliability of = Provisional Responses in the Session Initiation Protocol (SIP). greg -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Suha Cubukcuoglu Sent: Thursday, January 08, 2004 10:06 AM To: sip@ietf.org Cc: edNET Telco Subject: [Sip] 1xx Provisional Responses Hi, In the RFC for SIP (#3261) it is stated that 1xx provisional responses are not transmitted reliably and never cause the client to send an ACK message. SIP clients use UDP to send messages across networks. Therefore, for example, '180 Ringing' message may or may reach the calling party without the called party recognizing whether the message has reached its destination. This has adverse effects in terms of call setup and usability. If the 180 Ringing message is lost in the network while the called party is ringing, the calling party will have no idea what state the call is in at any time (e.g. one could think they dialed a wrong number, or its taking too long to contact the other end, etc.). '180 Ringing' message, in our opinion, should be treated as a critical message just like INVITE and 200 OK or the called party must send multiple '180 Ringing' messages, instead of just one, to make sure the other end will receive the message one way or other.=20 Could you please tell us your comments about this? Thanks very much. Regards, Suha Cubukcuoglu nplusone t: +44 131 514 2000 d: +44 131 514 4037 --=20 This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the sender. Any offers or quotation of service are subject to formal specification. Errors and omissions excepted. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of edNET or lightershade ltd. Finally, the recipient should check this email and any attachments for the presence = of viruses. edNET and lightershade ltd accepts no liability for any damage caused by any virus transmitted by this email. --=20 --=20 Virus scanned by edNET. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jan 8 10:48:42 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28876 for ; Thu, 8 Jan 2004 10:48:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AecOI-0006vK-5a for sip-archive@odin.ietf.org; Thu, 08 Jan 2004 10:48:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i08Fm9hK026525 for sip-archive@odin.ietf.org; Thu, 8 Jan 2004 10:48:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AecOB-0006sK-Rd; Thu, 08 Jan 2004 10:48:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AecNx-0006qq-Vx for sip@optimus.ietf.org; Thu, 08 Jan 2004 10:47:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28742 for ; Thu, 8 Jan 2004 10:47:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AecNl-0002Vr-00 for sip@ietf.org; Thu, 08 Jan 2004 10:47:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AecGl-00025x-00 for sip@ietf.org; Thu, 08 Jan 2004 10:40:24 -0500 Received: from [209.116.120.7] (helo=tnint11.telogy.design.ti.com) by ietf-mx with esmtp (Exim 4.12) id 1AecAx-0001dL-00 for sip@ietf.org; Thu, 08 Jan 2004 10:34:23 -0500 Received: by tnint11.telogy.design.ti.com with Internet Mail Service (5.5.2653.19) id ; Thu, 8 Jan 2004 10:30:42 -0500 Message-ID: <37A3C2F21006D611995100B0D0F9B73C0199B841@tnint11.telogy.design.ti.com> From: "Reddy, Muralidhar" To: "'suhac@ednet.co.uk'" , sip@ietf.org Cc: edNET Telco Subject: RE: [Sip] 1xx Provisional Responses Date: Thu, 8 Jan 2004 10:30:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=EXCUSE_16,OFFERS_ETC autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hello, We too had lot of discussion regarding when calling party should start ring back tone (RBT)? 1. Trigger RBT as soon as calling party sends Invite message. But Phone starts ringing for any number dialed. Or 2. Trigger RBT only when you receive 180 Ringing. As 180 is optional message, calling party can get connected without receiving 180 ringing message. Or 3. Trigger RBT when calling part receives 100 trying from the Proxy which is always true in the network. There is no strict rule defined in RFC regarding when calling party should start RBT. Murali -----Original Message----- From: Suha Cubukcuoglu [mailto:suhac@nplusone.net] Sent: Thursday, January 08, 2004 10:06 AM To: sip@ietf.org Cc: edNET Telco Subject: [Sip] 1xx Provisional Responses Hi, In the RFC for SIP (#3261) it is stated that 1xx provisional responses are not transmitted reliably and never cause the client to send an ACK message. SIP clients use UDP to send messages across networks. Therefore, for example, '180 Ringing' message may or may reach the calling party without the called party recognizing whether the message has reached its destination. This has adverse effects in terms of call setup and usability. If the 180 Ringing message is lost in the network while the called party is ringing, the calling party will have no idea what state the call is in at any time (e.g. one could think they dialed a wrong number, or its taking too long to contact the other end, etc.). '180 Ringing' message, in our opinion, should be treated as a critical message just like INVITE and 200 OK or the called party must send multiple '180 Ringing' messages, instead of just one, to make sure the other end will receive the message one way or other. Could you please tell us your comments about this? Thanks very much. Regards, Suha Cubukcuoglu nplusone t: +44 131 514 2000 d: +44 131 514 4037 -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. Any offers or quotation of service are subject to formal specification. Errors and omissions excepted. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of edNET or lightershade ltd. Finally, the recipient should check this email and any attachments for the presence of viruses. edNET and lightershade ltd accepts no liability for any damage caused by any virus transmitted by this email. -- -- Virus scanned by edNET. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jan 8 10:48:42 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28875 for ; Thu, 8 Jan 2004 10:48:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AecOI-0006v3-4Z for sip-archive@odin.ietf.org; Thu, 08 Jan 2004 10:48:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i08Fm9s3026524 for sip-archive@odin.ietf.org; Thu, 8 Jan 2004 10:48:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AecOA-0006ra-Cu; Thu, 08 Jan 2004 10:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AecNo-0006qI-J5 for sip@optimus.ietf.org; Thu, 08 Jan 2004 10:47:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28733 for ; Thu, 8 Jan 2004 10:47:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AecNc-0002Vh-00 for sip@ietf.org; Thu, 08 Jan 2004 10:47:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AecGj-00025R-00 for sip@ietf.org; Thu, 08 Jan 2004 10:40:23 -0500 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 1AecAq-0001im-00 for sip@ietf.org; Thu, 08 Jan 2004 10:34:16 -0500 Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id i08FWpij013168; Thu, 8 Jan 2004 08:32:51 -0700 (MST) Received: from bulb ([10.14.25.99]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i08FULgs027070; Thu, 8 Jan 2004 09:30:22 -0600 Date: Thu, 8 Jan 2004 10:28:43 -0500 (EST) From: Srinivasan Krishnamoorthy X-Sender: ksrini@bulb.corp.mot.com Reply-To: ksrini@motorola.com To: suhac@ednet.co.uk cc: sip@ietf.org, edNET Telco Subject: Re: [Sip] 1xx Provisional Responses In-Reply-To: <003a01c3d5f8$f326fc50$e3e714d4@Azopardi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Not sure if you looked at RFC3262 - specifies an extension (100rel) to support reliability of Provisional Responses. -Srini On Thu, 8 Jan 2004, Suha Cubukcuoglu wrote: suhac>Hi, suhac> suhac>In the RFC for SIP (#3261) it is stated that 1xx provisional responses suhac>are not transmitted reliably and never cause the client to send an ACK suhac>message. SIP clients use UDP to send messages across networks. suhac>Therefore, for example, '180 Ringing' message may or may reach the suhac>calling party without the called party recognizing whether the message suhac>has reached its destination. This has adverse effects in terms of call suhac>setup and usability. If the 180 Ringing message is lost in the network suhac>while the called party is ringing, the calling party will have no idea suhac>what state the call is in at any time (e.g. one could think they dialed suhac>a wrong number, or its taking too long to contact the other end, etc.). suhac>'180 Ringing' message, in our opinion, should be treated as a critical suhac>message just like INVITE and 200 OK or the called party must send suhac>multiple '180 Ringing' messages, instead of just one, to make sure the suhac>other end will receive the message one way or other. suhac> suhac>Could you please tell us your comments about this? suhac> suhac>Thanks very much. suhac> suhac>Regards, suhac> suhac>Suha Cubukcuoglu suhac>nplusone suhac>t: +44 131 514 2000 suhac>d: +44 131 514 4037 suhac> suhac> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Jan 9 04:25:02 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18864 for ; Fri, 9 Jan 2004 04:25:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aessb-0003Xh-Hd for sip-archive@odin.ietf.org; Fri, 09 Jan 2004 04:24:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i099OX5G013492 for sip-archive@odin.ietf.org; Fri, 9 Jan 2004 04:24:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AessA-0003PI-Tu; Fri, 09 Jan 2004 04:24:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdQSD-0000cc-9I for sip@optimus.ietf.org; Mon, 05 Jan 2004 03:51:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07869 for ; Mon, 5 Jan 2004 03:51:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdQSA-00042d-00 for sip@ietf.org; Mon, 05 Jan 2004 03:51:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdQQW-0003yc-00 for sip@ietf.org; Mon, 05 Jan 2004 03:49:32 -0500 Received: from web20610.mail.yahoo.com ([216.136.226.168]) by ietf-mx with smtp (Exim 4.12) id 1AdQP7-0003sC-00 for sip@ietf.org; Mon, 05 Jan 2004 03:48:05 -0500 Message-ID: <20040105084806.21038.qmail@web20610.mail.yahoo.com> Received: from [219.95.16.90] by web20610.mail.yahoo.com via HTTP; Mon, 05 Jan 2004 00:48:06 PST Date: Mon, 5 Jan 2004 00:48:06 -0800 (PST) From: vvarun kumar To: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Sip] Re:Redirect server in SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi Jonathan, I am a S/W Engr working on SIP. I am new to SIP so please guide me as I have seen solving these type of answers by u in IETF mailarchive. So I am mailing to u regarding this issue so that I can make a step ahead in my project. The problem is I am able to register with registrar and get the 200(OK) after registering. But when Iam trying to register with redirect server using aliases I am not able to register.I am using OPAL (PWLIB and OPenH323) software running in LINUX. Can u suggest How I can register the redirectserver using alias. Thank u, Regards, Arunkumar, Actinium Networks. __________________________________ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Jan 9 04:25:03 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18881 for ; Fri, 9 Jan 2004 04:25:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aessb-0003Xg-HS for sip-archive@odin.ietf.org; Fri, 09 Jan 2004 04:24:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i099OXRn013491 for sip-archive@odin.ietf.org; Fri, 9 Jan 2004 04:24:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AessC-0003PU-Bb; Fri, 09 Jan 2004 04:24:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeMsS-0008PN-Nx for sip@optimus.ietf.org; Wed, 07 Jan 2004 18:14:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12570 for ; Wed, 7 Jan 2004 18:14:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeMsP-0007Dk-00 for sip@ietf.org; Wed, 07 Jan 2004 18:14:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeMqY-00079g-00 for sip@ietf.org; Wed, 07 Jan 2004 18:12:19 -0500 Received: from mail3.pi.se ([195.7.64.137] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AeMp9-00075x-00 for sip@ietf.org; Wed, 07 Jan 2004 18:10:51 -0500 Received: from vit (h161n2fls31o265.telia.com [217.208.189.161]) (authenticated (0 bits)) by mail3.pi.se (8.12.10/8.11.2) with ESMTP id i07N9fSu001025; Thu, 8 Jan 2004 00:09:47 +0100 (CET) From: "Gunnar Hellstrom" To: "Jonathan Rosenberg" , "Toip list" Cc: Date: Thu, 8 Jan 2004 00:10:29 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_037C_01C3D57B.D3615190" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Sip] Text well covered in : I-D ACTION:draft-ietf-sip-callee-caps-03.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_037C_01C3D57B.D3615190 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by mail3.pi.se id i07N9fSu001025 Content-Transfer-Encoding: quoted-printable It is good to see the text medium listed among other media in the callee-caps specification. The spec provides an opportunity to declare capabilities for the real tim= e conversational media of video, text and audio to be known at SIP registry time. I hope this will stimulate to smart applications, invoking transcoding services when needed, selecting the proper terminal among a group of call= ed ones on the same address etc. I also hope that other editors and authors will remember to include real time conversational text as a natural component in other specs for SIP ba= sed real time services. It is so important that this medium is included from = the beginning, and not introduced as a cumbersome afterthought as happened to= o many times before. Thanks Gunnar Hellstr=F6m ------------------------------------------- Gunnar Hellstr=F6m Omnitor AB Renathv=E4gen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- -----Original Message----- From: owner-ietf-announce@ietf.org [mailto:owner-ietf-announce@ietf.org]On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, January 07, 2004 3:03 PM To: IETF-Announce: Cc: sip@ietf.org Subject: I-D ACTION:draft-ietf-sip-callee-caps-03.txt 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 Grou= p of the IETF. Title : Indicating User Agent Capabilities in the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg Filename : draft-ietf-sip-callee-caps-03.txt Pages : 45 Date : 2004-1-6 This specification defines mechanisms by which a Session Initiation Protocol (SIP) user agent can convey its capabilities and characteristics to other user agents. These capabilities are conveyed as parameters of the Contact header field. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-callee-caps-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the messag= e. Internet-Drafts are also available by anonymous FTP. Login with the usern= ame "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-callee-caps-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-callee-caps-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ----------------------------------------------------------------------- The IESG has approved following document: - 'Indicating User Agent Capabilities in the Session Initiation Protocol (SIP) ' 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 specification defines mechanisms by which a Session Initiation Protocol (SIP) user agent can convey its capabilities and characteristics to other user agents and to the registrar for its domain. This information is conveyed as parameters of the Contact header field. It may be used by a proxy for call routing. The paramet= er design is based on RFC 2506, media feature tags. The specification creates a SIP tree registry parallel to the IETF tree registry from RFC 2506. The syntax of the parameters is based on RFC 2533. Strong considerations regarding the privacy and data integrity of the information are discussed by the document. Working Group Summary The working group took a lot of care and review developing this design. There was a mid-course design review from an Applications area standpoint that resulted in the advice to work with the RFC 2533, 2506 approach, which has proved to be very constructive. The WG supported the advancement strongly, after thorough review. Protocol Quality The document was reviewed for the IESG by Allison Mankin. The Applications mid-course reviews were by Patrik Faltstrom and Ted Hardie. ------=_NextPart_000_037C_01C3D57B.D3615190 Content-Type: Message/External-body; name="ATT00643.dat" Content-Disposition: attachment; filename="ATT00643.dat" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-1-6142544.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-callee-caps-03.txt ------=_NextPart_000_037C_01C3D57B.D3615190 Content-Type: Message/External-body; name="draft-ietf-sip-callee-caps-03.txt" Content-Disposition: attachment; filename="draft-ietf-sip-callee-caps-03.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-1-6142544.I-D@ietf.org> ------=_NextPart_000_037C_01C3D57B.D3615190-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Jan 9 05:32:56 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21688 for ; Fri, 9 Jan 2004 05:32:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AetwL-000705-8d for sip-archive@odin.ietf.org; Fri, 09 Jan 2004 05:32:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i09AWToG026905 for sip-archive@odin.ietf.org; Fri, 9 Jan 2004 05:32:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aetvu-0006xW-3T; Fri, 09 Jan 2004 05:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aetuz-0006nt-A8 for sip@optimus.ietf.org; Fri, 09 Jan 2004 05:31:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21584 for ; Fri, 9 Jan 2004 05:31:02 -0500 (EST) From: ranjit.avasarala@wipro.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aetuv-00042R-00 for sip@ietf.org; Fri, 09 Jan 2004 05:31:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AettO-0003sD-00 for sip@ietf.org; Fri, 09 Jan 2004 05:29:27 -0500 Received: from wiproecmx1.wipro.com ([164.164.31.5]) by ietf-mx with esmtp (Exim 4.12) id 1Aetrk-0003g1-00 for sip@ietf.org; Fri, 09 Jan 2004 05:27:44 -0500 Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx1.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i09ARBCr008800 for ; Fri, 9 Jan 2004 15:57:11 +0530 (IST) Received: from blr-ec-bh3.wipro.com ([10.200.50.93]) by ec-vwall-wd with InterScan Messaging Security Suite; Fri, 09 Jan 2004 15:58:32 +0530 Received: from blr-ec-msg03.wipro.com ([10.200.52.99]) by blr-ec-bh3.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 9 Jan 2004 15:57:11 +0530 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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re:Redirect server in SIP Date: Fri, 9 Jan 2004 15:57:11 +0530 Message-ID: Thread-Topic: [Sip] Re:Redirect server in SIP Thread-Index: AcPWkp018+iqp7jVQHG5RKlcF+4fuwAB+5DQ To: , X-OriginalArrivalTime: 09 Jan 2004 10:27:11.0601 (UTC) FILETIME=[246E9E10:01C3D69B] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Arun It is better if u put such questions on sip-implementors or openH323 mailing lists.=20 Answering to ur question, I suggest u go through articles on SIP and RFC 3261 to get a good understaning on SIP and also through openH323 documentation to get a understanding on portable windows library (pwlib) and h323 code. then u should be in a position to solve the problems you are facing. Regards Ranjit -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of vvarun kumar Sent: Monday, January 05, 2004 2:18 PM To: sip@ietf.org Subject: [Sip] Re:Redirect server in SIP Hi Jonathan, I am a S/W Engr working on SIP. I am new to SIP so please guide me as I have seen solving these type of answers by u in IETF mailarchive. So I am mailing to u regarding this issue so that I can make a step ahead in my project. The problem is I am able to register with registrar and get the 200(OK) after registering. But when Iam trying to register with redirect server using aliases I am not able to register.I am using OPAL (PWLIB and OPenH323) software running in LINUX. Can u suggest How I can register the redirectserver using alias. Thank u, Regards, Arunkumar, Actinium Networks. __________________________________ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Jan 9 08:08:45 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27555 for ; Fri, 9 Jan 2004 08:08:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AewN6-0004PI-AB for sip-archive@odin.ietf.org; Fri, 09 Jan 2004 08:08:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i09D8Gn4016880 for sip-archive@odin.ietf.org; Fri, 9 Jan 2004 08:08:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AewMs-0004LS-7Q; Fri, 09 Jan 2004 08:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AewMd-0004HM-NR for sip@optimus.ietf.org; Fri, 09 Jan 2004 08:07:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27533 for ; Fri, 9 Jan 2004 08:07:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AewMT-0005b1-00 for sip@ietf.org; Fri, 09 Jan 2004 08:07:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AewHr-0005MC-00 for sip@ietf.org; Fri, 09 Jan 2004 08:02:51 -0500 Received: from smtp.dataconnection.com ([192.91.191.4] helo=coltrane.dataconnection.com) by ietf-mx with esmtp (Exim 4.12) id 1AewCC-00054u-00 for sip@ietf.org; Fri, 09 Jan 2004 07:57:00 -0500 Received: by coltrane.datcon.co.uk with Internet Mail Service (5.5.2656.59) id ; Fri, 9 Jan 2004 12:55:52 -0000 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F80261FF0D@baker.datcon.co.uk> From: "Paul D.Smith" To: SIP WG Date: Fri, 9 Jan 2004 12:55:56 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Sip] Server Location and trying requests bug? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , All, I believe there is an issue with Server Location that makes it impossible to reroute requests successfully in the following scenario. If the request reaches the server, but the resulting response does not reach the client (perhaps a NAT blocked its path) then Server Location processing cannot be used to find a different route via which the request can be completed and result in a successful response to the client. Could people please take a look at this, see if they have already encountered it and it so, let me know if they have suggestions for a solution? At SIPit13 we encountered the following problem. - Send a request using UDP - Request reached the server but the response could not get back for some reason - Client timed out and then tried TCP, changing the branch - New request reached the server which complained because the request did appear to increment the CSeq. These were specifically REGISTER requests but I believe this affects other requests, especially those in-dialog and INVITEs. Clearly the server was operating correctly and so there was some discussion as to whether the client was at fault. RFC3261 only states the following (RFC3261, 8.1.2, p42). The UAC SHOULD follow the procedures defined in [4] for stateful elements, trying each address until a server is contacted. Each try constitutes a new transaction, and therefore each carries a different topmost Via header field value with a new branch parameter. Furthermore, the transport value in the Via header field is set to whatever transport was determined for the target server. However it was decided that in fact the CSeq of the transaction should also have been incremented by the client when sending the new transaction over TCP. But now consider what would happen if the CSeq were updated in this manner but there was an intervening proxy. - Client sends request which reaches proxy - Proxy forwards on using UDP - Request reaches server but response cannot get back - Proxy times out UDP transaction and now tries TCP, changing the branch and the CSeq - New request reaches the server, which is happy and responds - Response now reaches proxy but the original request had Cseq X and the response has CSeq (X+1) Now the proxy might be able to massage the response Cseq back to X but then we have the strange situation that the client believes the next CSeq should be (X+1) whilst the server believes it should be (X+2). Clearly, a subsequent in-dialog reINVITE from the client will fail because the server does not believe the Cseq has been incremented. Clearly, without incrementing Cseq, we will hit the "response not returned, subsequent request fails" problem in both the UAC/UAS and UAC/proxy/UAS cases. But incrementing the CSeq only fixes the UAC/UAS case and introduces more problems in the UAC/proxy/UAS case. For this reason we believe the discussed solution is wrong. At the moment, this seems to be a problem that RFC3261 fails to address and we have yet to determine a simple fix. Thanks, Paul DS. Paul D.Smith Network Protocols Group Data Connection Ltd (DCL) Tel: +44 20 8366 1177 Email: paul.d.smith@dataconnection.com Fax: +44 20 8363 1039 Web: http://www.dataconnection.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Jan 9 08:43:40 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29427 for ; Fri, 9 Jan 2004 08:43:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aewut-0006Wq-4P for sip-archive@odin.ietf.org; Fri, 09 Jan 2004 08:43:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i09DhBLU025090 for sip-archive@odin.ietf.org; Fri, 9 Jan 2004 08:43:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aewuk-0006Vk-36; Fri, 09 Jan 2004 08:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AewuX-0006VQ-2D for sip@optimus.ietf.org; Fri, 09 Jan 2004 08:42:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29404 for ; Fri, 9 Jan 2004 08:42:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AewuV-0000nI-00 for sip@ietf.org; Fri, 09 Jan 2004 08:42:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aewsb-0000ks-00 for sip@ietf.org; Fri, 09 Jan 2004 08:40:50 -0500 Received: from [81.171.101.3] (helo=smtp.eweka.nl) by ietf-mx with esmtp (Exim 4.12) id 1Aewqn-0000if-00 for sip@ietf.org; Fri, 09 Jan 2004 08:38:57 -0500 Received: from solstice (ew-dsl-81-171-0-31.eweka.nl [81.171.0.31]) by smtp.eweka.nl (8.12.9/8.12.9) with ESMTP id i09E2eIr066494; Fri, 9 Jan 2004 14:02:41 GMT (envelope-from a.vwijk@viataal.nl) Message-Id: <200401091402.i09E2eIr066494@smtp.eweka.nl> From: "Arnoud van Wijk" To: "'Gunnar Hellstrom'" , "'Jonathan Rosenberg'" , "'Toip list'" Cc: Subject: RE: [Sip] Text well covered in : I-D ACTION:draft-ietf-sip-callee-caps-03.txt Date: Fri, 9 Jan 2004 14:38:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcPWo8zF7mjKbjJAQPaBpBLeHOekMQAEbwIQ X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Maybe it is a good idea to hold a small presentation reminding everybody = at the IETF that real time conversational text is a natural component like video and audio. Which WG would be the best? I am open to suggestions. Drs. Arnoud A. T. van Wijk=20 Viataal=20 Research & Development=20 Afdeling RDS=20 Theerestraat 42=20 5271 GD Sint-Michielsgestel=20 The Netherlands.=20 Mobile: +31651921948=20 International text telephone: +31735588408=20 -----Original Message----- From: owner-toip@snowshore.com [mailto:owner-toip@snowshore.com] On = Behalf Of Gunnar Hellstrom Sent: donderdag 8 januari 2004 0:10 To: Jonathan Rosenberg; Toip list Cc: sip@ietf.org Subject: [Sip] Text well covered in : I-D ACTION:draft-ietf-sip-callee-caps-03.txt It is good to see the text medium listed among other media in the callee-caps specification. The spec provides an opportunity to declare capabilities for the real = time conversational media of video, text and audio to be known at SIP registry time. I hope this will stimulate to smart applications, invoking transcoding services when needed, selecting the proper terminal among a group of = called ones on the same address etc. I also hope that other editors and authors will remember to include real time conversational text as a natural component in other specs for SIP = based real time services. It is so important that this medium is included from = the beginning, and not introduced as a cumbersome afterthought as happened = too many times before. Thanks Gunnar Hellstr=F6m ------------------------------------------- Gunnar Hellstr=F6m Omnitor AB Renathv=E4gen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- -----Original Message----- From: owner-ietf-announce@ietf.org [mailto:owner-ietf-announce@ietf.org]On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, January 07, 2004 3:03 PM To: IETF-Announce: Cc: sip@ietf.org Subject: I-D ACTION:draft-ietf-sip-callee-caps-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working = Group of the IETF. Title : Indicating User Agent Capabilities in the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg Filename : draft-ietf-sip-callee-caps-03.txt Pages : 45 Date : 2004-1-6 This specification defines mechanisms by which a Session Initiation Protocol (SIP) user agent can convey its capabilities and characteristics to other user agents. These capabilities are conveyed as parameters of the Contact header field. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-callee-caps-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the = message. Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-callee-caps-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-callee-caps-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ----------------------------------------------------------------------- The IESG has approved following document: - 'Indicating User Agent Capabilities in the Session Initiation Protocol (SIP) ' 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 specification defines mechanisms by which a Session Initiation Protocol (SIP) user agent can convey its capabilities and characteristics to other user agents and to the registrar for its domain. This information is conveyed as parameters of the Contact header field. It may be used by a proxy for call routing. The = parameter design is based on RFC 2506, media feature tags. The specification creates a SIP tree registry parallel to the IETF tree registry from RFC 2506. The syntax of the parameters is based on RFC 2533. Strong considerations regarding the privacy and data integrity of the information are discussed by the document. Working Group Summary The working group took a lot of care and review developing this = design. There was a mid-course design review from an Applications area standpoint that resulted in the advice to work with the RFC 2533, 2506 approach, which has proved to be very constructive. The WG supported the advancement strongly, after thorough review. Protocol Quality The document was reviewed for the IESG by Allison Mankin. The Applications mid-course reviews were by Patrik Faltstrom and Ted Hardie. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Jan 9 11:01:19 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09531 for ; Fri, 9 Jan 2004 11:01:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aez3f-00045p-5d for sip-archive@odin.ietf.org; Fri, 09 Jan 2004 11:00:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i09G0M3i015670 for sip-archive@odin.ietf.org; Fri, 9 Jan 2004 11:00:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aez3O-00040B-2P; Fri, 09 Jan 2004 11:00:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aez2h-0003yg-2w for sip@optimus.ietf.org; Fri, 09 Jan 2004 10:59:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09424 for ; Fri, 9 Jan 2004 10:59:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aez2U-0001oN-00 for sip@ietf.org; Fri, 09 Jan 2004 10:59:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeywD-0001f1-00 for sip@ietf.org; Fri, 09 Jan 2004 10:52:42 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Aeyvl-0001ZV-00; Fri, 09 Jan 2004 10:52:13 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id i09Fpad26878; Fri, 9 Jan 2004 09:51:36 -0600 From: Robert Sparks To: sip@ietf.org, simple@ietf.org, sip-implementors@cs.columbia.edu Content-Type: text/plain Message-Id: <1073663495.943.48.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 09 Jan 2004 09:51:35 -0600 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] SIPIT 14 registration closes next Friday Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Registration for SIPIT 14 closes in 7 days. See http://www.etsi.org/plugtests/SIPIT14.htm to register if you are planning to attend. RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sun Jan 11 10:04:50 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00661 for ; Sun, 11 Jan 2004 10:04:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Afh8Y-0004Hm-Av for sip-archive@odin.ietf.org; Sun, 11 Jan 2004 10:04:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0BF4MPV016473 for sip-archive@odin.ietf.org; Sun, 11 Jan 2004 10:04:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Afh8D-0004Gn-PV; Sun, 11 Jan 2004 10:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Afh7I-0004G5-5x for sip@optimus.ietf.org; Sun, 11 Jan 2004 10:03:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00458 for ; Sun, 11 Jan 2004 10:03:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Afh7F-0000RJ-00 for sip@ietf.org; Sun, 11 Jan 2004 10:03:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Afh5K-0000LW-00 for sip@ietf.org; Sun, 11 Jan 2004 10:01:03 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Afh49-0000Ey-00 for sip@ietf.org; Sun, 11 Jan 2004 09:59:49 -0500 Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i0BEx89W000805; Sun, 11 Jan 2004 09:59:09 -0500 (EST) Message-ID: <400164B6.2060901@dynamicsoft.com> Date: Sun, 11 Jan 2004 09:59:02 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Paul D.Smith" CC: SIP WG Subject: Re: [Sip] Server Location and trying requests bug? References: <53F74F5A7B94D511841C00B0D0AB16F80261FF0D@baker.datcon.co.uk> In-Reply-To: <53F74F5A7B94D511841C00B0D0AB16F80261FF0D@baker.datcon.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline. Paul D.Smith wrote: > All, > > I believe there is an issue with Server Location that makes it impossible to > reroute requests successfully in the following scenario. > > If the request reaches the server, but the resulting response does not reach > the client (perhaps a NAT blocked its path) then Server Location processing > cannot be used to find a different route via which the request can be > completed and result in a successful response to the client. I dont see why. The client (UAC or proxy) cannot differentiate the case where a request fails to reach the server, and the response fails to reach the client. Both manifest themselves as failure to receive a response. > At SIPit13 we encountered the following problem. > > - Send a request using UDP > - Request reached the server but the response could not get back for some > reason > - Client timed out and then tried TCP, changing the branch > - New request reached the server which complained because the request did > appear to increment the CSeq. The server should be prepared to receive requests with CSeq more than one higher. RFC3261 explicitly discusses this. > > These were specifically REGISTER requests but I believe this affects other > requests, especially those in-dialog and INVITEs. > > Clearly the server was operating correctly and so there was some discussion > as > to whether the client was at fault. RFC3261 only states the following > (RFC3261, 8.1.2, p42). > > The UAC SHOULD follow the procedures defined in [4] for stateful > elements, trying each address until a server is contacted. Each try > constitutes a new transaction, and therefore each carries a different > topmost Via header field value with a new branch parameter. > Furthermore, the transport value in the Via header field is set to > whatever transport was determined for the target server. > > However it was decided that in fact the CSeq of the transaction should also > have been incremented by the client when sending the new transaction over > TCP. It should, though in rfc3261 (as opposed to 2543), it should actually work in either case. > > But now consider what would happen if the CSeq were updated in this manner > but there was an intervening proxy. > > - Client sends request which reaches proxy > - Proxy forwards on using UDP > - Request reaches server but response cannot get back > - Proxy times out UDP transaction and now tries TCP, changing the branch and > the CSeq It should NOT have done that. The proxy should not touch the CSeq. Only the branch ID parameter. > - New request reaches the server, which is happy and responds > - Response now reaches proxy but the original request had Cseq X and the > response has CSeq (X+1) > > Now the proxy might be able to massage the response Cseq back to X but then > we > have the strange situation that the client believes the next CSeq should be > (X+1) whilst the server believes it should be (X+2). Clearly, a subsequent > in-dialog reINVITE from the client will fail because the server does not > believe the Cseq has been incremented. As I mentioned above, the server should be prepared to receive requests with CSeq one or more greater than the last received. > > Clearly, without incrementing Cseq, we will hit the "response not returned, > subsequent request fails" problem in both the UAC/UAS and UAC/proxy/UAS > cases. > But incrementing the CSeq only fixes the UAC/UAS case and introduces more > problems in the UAC/proxy/UAS case. For this reason we believe the > discussed > solution is wrong. > > At the moment, this seems to be a problem that RFC3261 fails to address and > we > have yet to determine a simple fix. The problem is in the server. From 12.2.2: > If the remote sequence number is empty, it MUST be set to the value > of the sequence number in the CSeq header field value in the request. > If the remote sequence number was not empty, but the sequence number > of the request is lower than the remote sequence number, the request > is out of order and MUST be rejected with a 500 (Server Internal > Error) response. If the remote sequence number was not empty, and > the sequence number of the request is greater than the remote > sequence number, the request is in order. It is possible for the > CSeq sequence number to be higher than the remote sequence number by > more than one. This is not an error condition, and a UAS SHOULD be > prepared to receive and process requests with CSeq values more than > one higher than the previous received request. The UAS MUST then set > the remote sequence number to the value of the sequence number in the > CSeq header field value in the request. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Jan 12 11:12:59 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04023 for ; Mon, 12 Jan 2004 11:12:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag4g2-0001mw-5C for sip-archive@odin.ietf.org; Mon, 12 Jan 2004 11:12:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0CGCUwX006871 for sip-archive@odin.ietf.org; Mon, 12 Jan 2004 11:12:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag4fZ-0001lY-Ru; Mon, 12 Jan 2004 11:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag4em-0001l1-Bj for sip@optimus.ietf.org; Mon, 12 Jan 2004 11:11:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03980 for ; Mon, 12 Jan 2004 11:11:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag4ej-0001Nc-00 for sip@ietf.org; Mon, 12 Jan 2004 11:11:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag4d0-0001Kl-00 for sip@ietf.org; Mon, 12 Jan 2004 11:09:23 -0500 Received: from smtp2.dataconnection.com ([192.91.191.8] helo=miles.dataconnection.com) by ietf-mx with esmtp (Exim 4.12) id 1Ag4cT-0001Gp-00 for sip@ietf.org; Mon, 12 Jan 2004 11:08:49 -0500 Received: by miles.datcon.co.uk with Internet Mail Service (5.5.2656.59) id ; Mon, 12 Jan 2004 16:08:10 -0000 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F80261FF29@baker.datcon.co.uk> From: "Paul D.Smith" To: "'Jonathan Rosenberg'" Cc: SIP WG Subject: RE: [Sip] Server Location and trying requests bug? Date: Mon, 12 Jan 2004 16:08:05 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,LINES_OF_YELLING, LINES_OF_YELLING_2 autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Jonathan, I have commented on your responses below, but it seems that I have failed to get across the problems that we encountered. I will therefore attempt to recouch the problem using some ASCII-art flows. My comments on your response are couched in terms of my new examples so please read this section before looking at my in-line comments. There are two scenarios which I am considering. 1. UAC/UAS "direct" (i.e. not intervening SIP proxy) 2. UAC/proxy/UAS Note that in both cases there is a NAT (or similar) between the UAS and the SIP entity (UAC or proxy) to which it is attached. I've shown this as a NAT below. This entity is not SIP aware but can cause problems with responses failing to traverse back towards the UAC. I have shown requests as RQ[c,b] where c and b represent CSeq and branches respectively: - RQ[1,1] and RQ[1,2] have the same CSeq but different branches - RQ[1,1] and RQ[2,2] have different CSeq and different branches. Scenario 1.a (we hit this at SIPit13) UAC NAT UAS RQ[1,1] -----------> RQ[1,1]----------> <---------2XX[1,1] RQ[1,2] -----------> RQ[1,2]----------> <------------5XX[1,2] <---------5XX[1,2] What has happened here is that the UAS has received the request, processed it successfully but the response could not reach the UAC. Server (re)Location then kicked in on the UAC and found a different route (say TCP instead of UDP) and the request again reached the UAS. But the CSeq has not been increased so the UAS correctly rejects the request. After discussions with various people at SIPit13, it seemed a reasonable fix to have the UAC increment the CSeq during Server (re)Location which results in the following... Scenario 1.b - Allow Server (re)Location to increment Cseq UAC NAT UAS RQ[1,1] -----------> RQ[1,1]---------> <--------2XX[1,1] RQ[2,2] -----------> RQ[2,2]---------> <------------2XX[2,2] <--------2XX[2,2] This seemed to solve the problem until we considered proxies. If we assume that incrementing Cseq is correct we end up with the following. Scenario 1.2 UAC Proxy NAT UAS RQ[1,1] -----------> RQ[1,1]-------> RQ[1,1]---------> <---------2XX[1,1] RQ[2,2]-------> RQ[2,2]----------> <---------------???? <------2XX[2,2] <---------2XX[2,2] But now what happens to the response? We cannot mangle the CSeq before the proxy returns it otherwise the next Cseq the UAC would expect to send would be 2 whilst the UAS would expect a Cseq of 3. So, as you correctly say, I have to conclude that it must be wrong for Server (re)Location to increment the Cseq. But how, therefore, do we solve the problem of scenario 1.a? I've commented on your specific feedback in line below, referencing the scenarios given above. I look forward to reading your comments, Paul DS. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: 11 January 2004 14:59 To: SIP (E-mail) Subject: Re: [Sip] Server Location and trying requests bug? inline. Paul D.Smith wrote: > All, > > I believe there is an issue with Server Location that makes it impossible to > reroute requests successfully in the following scenario. > > If the request reaches the server, but the resulting response does not reach > the client (perhaps a NAT blocked its path) then Server Location processing > cannot be used to find a different route via which the request can be > completed and result in a successful response to the client. I dont see why. The client (UAC or proxy) cannot differentiate the case where a request fails to reach the server, and the response fails to reach the client. Both manifest themselves as failure to receive a response. [PDS] Hopefully scenario 1.a has explained this. The issue is that the UAC and UAS now have different ideas of the state of the dialog or call i.e. the next Cseq that the UAC should send on a request. > At SIPit13 we encountered the following problem. > > - Send a request using UDP > - Request reached the server but the response could not get back for some > reason > - Client timed out and then tried TCP, changing the branch > - New request reached the server which complained because the request did > appear to increment the CSeq. The server should be prepared to receive requests with CSeq more than one higher. RFC3261 explicitly discusses this. [PDS] That is not the problem. In scenario 1.a, the UAS believes that the UAC sent a new request that _didn't_ increment the Cseq. > > These were specifically REGISTER requests but I believe this affects other > requests, especially those in-dialog and INVITEs. > > Clearly the server was operating correctly and so there was some discussion > as > to whether the client was at fault. RFC3261 only states the following > (RFC3261, 8.1.2, p42). > > The UAC SHOULD follow the procedures defined in [4] for stateful > elements, trying each address until a server is contacted. Each try > constitutes a new transaction, and therefore each carries a different > topmost Via header field value with a new branch parameter. > Furthermore, the transport value in the Via header field is set to > whatever transport was determined for the target server. > > However it was decided that in fact the CSeq of the transaction should also > have been incremented by the client when sending the new transaction over > TCP. It should, though in rfc3261 (as opposed to 2543), it should actually work in either case. [PDS] I disagree. As per scenario 1.a, the UAS is quite correct to reject what it believes is a new request that has not incremented the CSeq. > > But now consider what would happen if the CSeq were updated in this manner > but there was an intervening proxy. > > - Client sends request which reaches proxy > - Proxy forwards on using UDP > - Request reaches server but response cannot get back > - Proxy times out UDP transaction and now tries TCP, changing the branch and > the CSeq It should NOT have done that. The proxy should not touch the CSeq. Only the branch ID parameter. [PDS] Agreed. But this means that scenario 2 fails. Also, if you are implying that the "real" UAC can increment the Cseq but the "proxy" UAC cannot, then the UAC side of proxy and the "real" UAC are now inconsistent. > - New request reaches the server, which is happy and responds > - Response now reaches proxy but the original request had Cseq X and the > response has CSeq (X+1) > > Now the proxy might be able to massage the response Cseq back to X but then > we > have the strange situation that the client believes the next CSeq should be > (X+1) whilst the server believes it should be (X+2). Clearly, a subsequent > in-dialog reINVITE from the client will fail because the server does not > believe the Cseq has been incremented. As I mentioned above, the server should be prepared to receive requests with CSeq one or more greater than the last received. [PDS] As above, this is not the problem that we hit. > > Clearly, without incrementing Cseq, we will hit the "response not returned, > subsequent request fails" problem in both the UAC/UAS and UAC/proxy/UAS > cases. > But incrementing the CSeq only fixes the UAC/UAS case and introduces more > problems in the UAC/proxy/UAS case. For this reason we believe the > discussed > solution is wrong. > > At the moment, this seems to be a problem that RFC3261 fails to address and > we > have yet to determine a simple fix. The problem is in the server. From 12.2.2: > If the remote sequence number is empty, it MUST be set to the value > of the sequence number in the CSeq header field value in the request. > If the remote sequence number was not empty, but the sequence number > of the request is lower than the remote sequence number, the request > is out of order and MUST be rejected with a 500 (Server Internal > Error) response. If the remote sequence number was not empty, and > the sequence number of the request is greater than the remote > sequence number, the request is in order. It is possible for the > CSeq sequence number to be higher than the remote sequence number by > more than one. This is not an error condition, and a UAS SHOULD be > prepared to receive and process requests with CSeq values more than > one higher than the previous received request. The UAS MUST then set > the remote sequence number to the value of the sequence number in the > CSeq header field value in the request. [PDS] As above, this is not the problem we are hitting. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Jan 12 12:30:44 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06891 for ; Mon, 12 Jan 2004 12:30:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag5tI-0004nf-J2 for sip-archive@odin.ietf.org; Mon, 12 Jan 2004 12:30:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0CHUGf5018445 for sip-archive@odin.ietf.org; Mon, 12 Jan 2004 12:30:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag5t5-0004lf-G3; Mon, 12 Jan 2004 12:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag5sJ-0004ju-57 for sip@optimus.ietf.org; Mon, 12 Jan 2004 12:29:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06846 for ; Mon, 12 Jan 2004 12:29:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag5sH-0004oR-00 for sip@ietf.org; Mon, 12 Jan 2004 12:29:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag5qU-0004kT-00 for sip@ietf.org; Mon, 12 Jan 2004 12:27:23 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1Ag5pE-0004gQ-00 for sip@ietf.org; Mon, 12 Jan 2004 12:26:04 -0500 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i0CHQ3Dc008231 for ; Mon, 12 Jan 2004 10:26:03 -0700 (MST) Received: from bulb ([10.14.25.99]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id i0CHOhTs019851 for ; Mon, 12 Jan 2004 11:24:43 -0600 Date: Mon, 12 Jan 2004 12:24:08 -0500 (EST) From: Srinivasan Krishnamoorthy X-Sender: ksrini@bulb.corp.mot.com Reply-To: ksrini@motorola.com To: sip@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Sip] Registering Multiple 'Contacts' Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi, Section 10.2.4 of RFC3261 'Refreshing Bindings' says: "The UA then issues a REGISTER request for each of its bindings before the expiration interval has elapsed. It MAY combine several updates into one REGISTER request." The above seems to indicate that the UAC may send: (forgive the Syntax) REGISTER To: user@operator.net Contact: sip:user1@10.0.0.1;expires=3600 200 OK REGISTER To: user@operator.net Contact: sip:user1@192.0.0.1;expires=3600 200 OK This, according to RFC3261, will register both Contact1 and Contact2 for user@operator.net. (The server will then use the q parameter of the contact for priority among contacts) Take a case where a SIP UAC power-cycles or moves without sending an explicit de-REGISTER. Assume it gets a new IP-address everytime - therefore the 'Contact' will be a new URI every time it sends a REGISTER after a power-cycle. If the power-cycle occured before the 'registration expiration interval' elapsed - the Server will essentially be adding 'multiple' bindings for this user. Is this correct interpretation? Now, is the UAclient mandated to 'deREGISTER' all of its previous contacts before sending its new REGISTER? Or risk adding multiple 'contacts' at the Server? How will the Server prevent against mis-behaved clients in this case? Thank you very much for any help. -Srini _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Jan 12 13:04:38 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08717 for ; Mon, 12 Jan 2004 13:04:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag6Q7-0006ux-LY for sip-archive@odin.ietf.org; Mon, 12 Jan 2004 13:04:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0CI4BWh026590 for sip-archive@odin.ietf.org; Mon, 12 Jan 2004 13:04:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag6Px-0006tN-R0; Mon, 12 Jan 2004 13:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag6PQ-0006s0-H0 for sip@optimus.ietf.org; Mon, 12 Jan 2004 13:03:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08561 for ; Mon, 12 Jan 2004 13:03:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag6PO-0006Vr-00 for sip@ietf.org; Mon, 12 Jan 2004 13:03:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag6OH-0006Nd-00 for sip@ietf.org; Mon, 12 Jan 2004 13:02:17 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Ag6N3-0006I5-00 for sip@ietf.org; Mon, 12 Jan 2004 13:01:01 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 12 Jan 2004 10:02:14 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0CI0QGP019051; Mon, 12 Jan 2004 10:00:29 -0800 (PST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFE42269; Mon, 12 Jan 2004 13:00:25 -0500 (EST) Message-ID: <4002E0B9.8030203@cisco.com> Date: Mon, 12 Jan 2004 13:00:25 -0500 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: ksrini@motorola.com CC: sip@ietf.org Subject: Re: [Sip] Registering Multiple 'Contacts' References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Srinivasan Krishnamoorthy wrote: > Hi, > > Section 10.2.4 of RFC3261 'Refreshing Bindings' says: > > "The UA then issues a REGISTER request for each of its bindings > before the expiration interval has elapsed. It MAY combine > several updates into one REGISTER request." > > The above seems to indicate that the UAC may send: > (forgive the Syntax) > > REGISTER > To: user@operator.net > Contact: sip:user1@10.0.0.1;expires=3600 > > 200 OK > > REGISTER > To: user@operator.net > Contact: sip:user1@192.0.0.1;expires=3600 > > 200 OK > > This, according to RFC3261, will register both Contact1 and Contact2 > for user@operator.net. (The server will then use the q parameter > of the contact for priority among contacts) Yes. > Take a case where a SIP UAC power-cycles or moves without sending > an explicit de-REGISTER. Assume it gets a new IP-address everytime > - therefore the 'Contact' will be a new URI every time it sends a > REGISTER after a power-cycle. > > If the power-cycle occured before the 'registration expiration interval' > elapsed - the Server will essentially be adding 'multiple' bindings > for this user. Is this correct interpretation? Yes > Now, is the UAclient mandated to 'deREGISTER' all of its previous contacts > before sending its new REGISTER? Its not mandated to do so, but that would probably be a wise thing to do. > Or risk adding multiple 'contacts' > at the Server? That is the alternative. > How will the Server prevent against mis-behaved clients in this case? The expiration time bounds the problem, but doesn't eliminate it. Assume the UAC power cycles, forgets its old address, gets a new one and registers it. It will then presumably continue to refresh the new address, but not the old one. So the old registration will continue to be active until it expires. During that time requests will probably be forked to it and the new address, but the ones to the old address will fail. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Jan 12 17:07:45 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24925 for ; Mon, 12 Jan 2004 17:07:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgADN-0007Xj-42 for sip-archive@odin.ietf.org; Mon, 12 Jan 2004 17:07:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0CM7Hdn028933 for sip-archive@odin.ietf.org; Mon, 12 Jan 2004 17:07:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgAD7-0007Rb-QB; Mon, 12 Jan 2004 17:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgACa-0007Qb-71 for sip@optimus.ietf.org; Mon, 12 Jan 2004 17:06:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24783 for ; Mon, 12 Jan 2004 17:06:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgACY-00057B-00 for sip@ietf.org; Mon, 12 Jan 2004 17:06:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgAB4-0004v6-00 for sip@ietf.org; Mon, 12 Jan 2004 17:04:55 -0500 Received: from brandt-online.net ([217.160.90.205] helo=p10088371.pureserver.de) by ietf-mx with esmtp (Exim 4.12) id 1AgA8z-0004eg-00 for sip@ietf.org; Mon, 12 Jan 2004 17:02:45 -0500 Received: from bartschnet.de (p5080A369.dip0.t-ipconnect.de [80.128.163.105]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by p10088371.pureserver.de (Postfix) with ESMTP id 2DE13420118 for ; Mon, 12 Jan 2004 23:02:37 +0100 (CET) Message-ID: <40031925.1020505@bartschnet.de> Date: Mon, 12 Jan 2004 23:01:09 +0100 From: Rene Bartsch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.3) Gecko/20030312 X-Accept-Language: de-at, de, en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Suggestion to locate nearest ERC-center by ENUM Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, for emergency calls we have the problem to locate the nearest ERC-center. As most SIP-phones will have a numeric pad only, we'll have to use ENUM anyway. This brought me to the idea to use ENUM for allocating the SIP or WhatEverProtocol address of the nearest ERC-center. The idea is simply: Just using NAPTR-RR and LOC-RR. The ITU would run the top-layer ERC-ENUM-domain 1.1.9.e164.arpa. The Zone-file would have a LOC-RR and a NAPTR-RR pointing to each national ERC-domain (e.g. 1.1.9.1.e164.arpa for the US, 1.1.9.9.4.e164.arpa for Germany, 1.1.9.4.4.e164.arpa for UK, 1.1.9.3.3.e164.arpa for France, 1.1.9.3.4.e164.arpa for Austria, etc.) Every national regulator would run the national ERC-ENUM-domain in the same shape, either pointing directly to the adresses of the ERC-centers or having additional sub-layers of ERC-ENUM-domains for e.g. federal states, districts, etc. This would be quite flexible and could also be used for any other ERC-service/communication protocol. The SIP-phones would just use their geographic coordinates (either manually stored in fixed phones or e.g. evaluated by GPS for cell phones, ...) and do a DNS-lookup when 911 is dialed to find the nearest LOC-RR and the corresponding NAPTR-RR for the ERC-center. Comments? Rene Bartsch _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Jan 12 20:03:47 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02825 for ; Mon, 12 Jan 2004 20:03:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgCxh-0004Jr-Ew for sip-archive@odin.ietf.org; Mon, 12 Jan 2004 20:03:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0D13Hns016544 for sip-archive@odin.ietf.org; Mon, 12 Jan 2004 20:03:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgCxR-0004Ho-RR; Mon, 12 Jan 2004 20:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgCwd-0004Gv-Bf for sip@optimus.ietf.org; Mon, 12 Jan 2004 20:02:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02811 for ; Mon, 12 Jan 2004 20:02:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgCwb-0005sw-00 for sip@ietf.org; Mon, 12 Jan 2004 20:02:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgCul-0005oA-00 for sip@ietf.org; Mon, 12 Jan 2004 20:00:16 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AgCt8-0005ht-00 for sip@ietf.org; Mon, 12 Jan 2004 19:58:34 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 12 Jan 2004 16:59:51 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i0D0w2VM001774; Mon, 12 Jan 2004 16:58:03 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id APE79233; Mon, 12 Jan 2004 16:58:01 -0800 (PST) Date: Mon, 12 Jan 2004 16:59:38 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Cc: Dean Willis , aki.niemi@nokia.com, rohan@cisco.com To: sip@ietf.org From: Rohan Mahy Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.553) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] WGLC for PUBLISH Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, I'd like to begin Working Group Last Call for PUBLISH: http://www.ietf.org/internet-drafts/draft-ietf-sip-publish-02.txt This WGLC will end on January 28, 2004. thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Jan 13 16:30:51 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15033 for ; Tue, 13 Jan 2004 16:30:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgW79-0004Ol-VR for sip-archive@odin.ietf.org; Tue, 13 Jan 2004 16:30:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0DLUJ58016901 for sip-archive@odin.ietf.org; Tue, 13 Jan 2004 16:30:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgW5u-0004Js-3R; Tue, 13 Jan 2004 16:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgW5M-0004JK-Vp for sip@optimus.ietf.org; Tue, 13 Jan 2004 16:28:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14550 for ; Tue, 13 Jan 2004 16:28:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgW5K-0006uF-00 for sip@ietf.org; Tue, 13 Jan 2004 16:28:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgW27-0006LJ-00 for sip@ietf.org; Tue, 13 Jan 2004 16:25:09 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AgVyf-0005j6-00 for sip@ietf.org; Tue, 13 Jan 2004 16:21:33 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA28842; Tue, 13 Jan 2004 16:20:58 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA26702; Tue, 13 Jan 2004 16:20:59 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Jan 2004 16:20:59 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B62AA@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Rene Bartsch'" , sip@ietf.org Subject: RE: [Sip] Suggestion to locate nearest ERC-center by ENUM Date: Tue, 13 Jan 2004 16:20:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I'm working on a proposal to use the DNS somewhat like this. This is a little premature, but Rene brought it up, so.... The fundamental difference between what I will propose, and your proposal is that the phone number mapping to geographic area breaks down after the country code (for example, in North America, there is no relationship between the "area code" (first 3 digits in a phone number) and ERC service boundaries. Also, there is no agreement on the "number" for emergency calls, and in fact, there is an active draft that should be ready for WGLC soon that proposes that the SIP URI for an emergency call is sos@. Therefore, using ENUM like structure isn't very usefull. As you point out, in most countries, there are one or more levels of "delegation" on ERC organization that match political subdivisions. For example, in the U.S., ERCs are organized by the states, and in some cases, there is further delegation to counties. This varies by country. In my immediate area, the ERC is called "NEWCOM" and is in Allegheny County, in Pennsylvania. I propose that the service boundary of this ERC be found in the DNS at something like newcom.allegheny.pa.us.sos.arpa There are some details to be worked out. My proposal will be more complex than this, because I would include much more information in the DNS. For example, the boundary of Room 235 on the 5th floor of the Wigit suite at 123 Main Street in Pittsburgh PA might be found in the DNS at 235.5.wigit.123.main.pittsburgh.allegheny.pa.us.sos.arpa In this proposal, there is a VERY BIG ASSUMPTION. The assumption is that the DNS is used for PUBLISHING the data, and is not actually used in the processing of an emergency call. Rather, I envision that spiders will periodically walk the DNS tree and extract the boundary information, storing it in a local database organized to make the operations more efficient. Boundary information would be available at intermediate nodes in this proposal (that is, the boundary of Allegheny County could be found at allegheny.pa.us.sos.arpa). It is probably the case that the boundary information below the street address level would be encrypted if the building owner did not want to make interior layout information public. The data in the DNS would then allow a conversion between civil (room/floor/building/street address) and geo (lat/lon/altitide). It would also replace what in the U.S. is called the "Master Street Address Guide". In operation, phones will learn their location, either civil or geo. They pass that information on a call to sos@. A proxy routing an emergency call converts a civil to a geo using the (previously spidered) DNS sos.arpa data if necessary, and intersects the geo with the ERC service boundaries to find the serving ERC. The entry in the DNS contains a URI for the ERC, and the proxy routes the call to that ERC. The ERC gets location in civil or geo form. It validates a civil by verifying that the address exists in the sos.arpa domain, or converts a geo to a (valid) civil for dispatch. You could also imagine a link between sos.arpa and e164.arpa, whereby for a fixed phone, there was a "domain name" in sos.arpa stored in the terminal e164.arpa entry that mapped a phone number to a civil location. This too might be encrypted. You could use such a mechanism to replace existing "ALI" databases that convert a caller phone number to a location for legacy phone systems. Note that the delegation mechanism in the DNS is very appropriate for this purpose: An international organization (possibly ITU) delegates the iso country code in sos.arpa to a national agency The national agency delegates to lower layer political entities (states in my example) The (say) state agency, delegates to any lower level agencies which in turn delegate to lower level agencies. In my example, PA delegates to Allegheny County, which would delegate newcom.allegheny.pa.us.sos.arpa to NEWCOM. It would delegate pittsburgh.allegheny.pa.us to the City of Pittsburgh. The City would create entries for all of its streets, and for all of the buildings on those streets. The City (township, village,...) would delegate to building owners Building owners would (if appropriate) delegate to tenants Tenants would enter floor/room data An entity at some level might decide that it would not actually delegate lower levels, but create an administrative mechanism to populate the lower levels. More later. Brian -----Original Message----- From: Rene Bartsch [mailto:ml@bartschnet.de] Sent: Monday, January 12, 2004 5:01 PM To: sip@ietf.org Subject: [Sip] Suggestion to locate nearest ERC-center by ENUM Hi, for emergency calls we have the problem to locate the nearest ERC-center. As most SIP-phones will have a numeric pad only, we'll have to use ENUM anyway. This brought me to the idea to use ENUM for allocating the SIP or WhatEverProtocol address of the nearest ERC-center. The idea is simply: Just using NAPTR-RR and LOC-RR. The ITU would run the top-layer ERC-ENUM-domain 1.1.9.e164.arpa. The Zone-file would have a LOC-RR and a NAPTR-RR pointing to each national ERC-domain (e.g. 1.1.9.1.e164.arpa for the US, 1.1.9.9.4.e164.arpa for Germany, 1.1.9.4.4.e164.arpa for UK, 1.1.9.3.3.e164.arpa for France, 1.1.9.3.4.e164.arpa for Austria, etc.) Every national regulator would run the national ERC-ENUM-domain in the same shape, either pointing directly to the adresses of the ERC-centers or having additional sub-layers of ERC-ENUM-domains for e.g. federal states, districts, etc. This would be quite flexible and could also be used for any other ERC-service/communication protocol. The SIP-phones would just use their geographic coordinates (either manually stored in fixed phones or e.g. evaluated by GPS for cell phones, ...) and do a DNS-lookup when 911 is dialed to find the nearest LOC-RR and the corresponding NAPTR-RR for the ERC-center. Comments? Rene Bartsch _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Jan 13 17:41:58 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19191 for ; Tue, 13 Jan 2004 17:41:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgXE3-0007uc-60 for sip-archive@odin.ietf.org; Tue, 13 Jan 2004 17:41:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0DMfVRf030353 for sip-archive@odin.ietf.org; Tue, 13 Jan 2004 17:41:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgXDa-0007sX-Vx; Tue, 13 Jan 2004 17:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgXD4-0007qR-TV for sip@optimus.ietf.org; Tue, 13 Jan 2004 17:40:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19172 for ; Tue, 13 Jan 2004 17:40:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgXD2-0003hg-00 for sip@ietf.org; Tue, 13 Jan 2004 17:40:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgXBn-0003fE-00 for sip@ietf.org; Tue, 13 Jan 2004 17:39:12 -0500 Received: from brandt-online.net ([217.160.90.205] helo=p10088371.pureserver.de) by ietf-mx with esmtp (Exim 4.12) id 1AgXA3-0003YY-00 for sip@ietf.org; Tue, 13 Jan 2004 17:37:24 -0500 Received: from bartschnet.de (p5080A2DE.dip0.t-ipconnect.de [80.128.162.222]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by p10088371.pureserver.de (Postfix) with ESMTP id 475F7420118; Tue, 13 Jan 2004 23:37:21 +0100 (CET) Message-ID: <400472CC.7030609@bartschnet.de> Date: Tue, 13 Jan 2004 23:35:56 +0100 From: Rene Bartsch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.3) Gecko/20030312 X-Accept-Language: de-at, de, en-us, en MIME-Version: 1.0 To: "Rosen, Brian" , sip@ietf.org Subject: Re: [Sip] Suggestion to locate nearest ERC-center by ENUM References: <313680C9A886D511A06000204840E1CF070B62AA@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF070B62AA@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Rosen, Brian schrieb: > I'm working on a proposal to use the DNS somewhat like this. > This is a little premature, but Rene brought it up, so.... > > The fundamental difference between what I will propose, and your > proposal is that the phone number mapping to geographic area > breaks down after the country code (for example, in North America, > there is no relationship between the "area code" (first 3 digits > in a phone number) and ERC service boundaries. Also, there is > no agreement on the "number" for emergency calls, The ITU should just delegate ENUM-911 for ERCs world-wide. and in fact, > there is an active draft that should be ready for WGLC soon > that proposes that the SIP URI for an emergency call is > sos@. Therefore, using ENUM like structure isn't > very usefull. > But there is a problem: Most SIP-phones will habe numeric pads, but no alpanumeric 80-key pads. So we cannot use an addressing out of the decimal range - no letters, no "@"! And there's no problem with the number mapping to the geographic area as the geographic is not determined by the area prefixes but by the LOC-records. I think my explanation was a bit misunderstandable. When you do an ERC, 1.) you dial 911 at your phone 2.) the phone looks up the ENUM 1.1.9.e164.arpa 3.) the phone checks it's geographic data against the LOC-records listed in the 1.1.9.e164.arpa-zone and finds the nearest LOC-entry (in your case it would be a NAPTR-RR pointing to the ERC-ENUM of the US - 1.1.9.1.e164.arpa) 4.) the phone looks up the ENUM 1.1.9.1.e164.arpa 5.) the phone checks it's geographic data against the LOC-records listed in the 1.1.9.1.e164.arpa-zone and finds the nearest LOC-entry (in your case it would be a NAPTR-RR pointing to the ERC-ENUM-domain of Pennsylvania - 1.1.9.[WhatEverYouWantLevel1].1.e164.arpa) 6.) the phone looks up the ENUM 1.1.9.[WhatEverYouWantLevel1].1.e164.arpa 7.) the phone checks it's geographic data against the LOC-records listed in the 1.1.9.[WhatEverYouWantLevel1].1.e164.arpa-zone and finds the nearest LOC-entry (in your case it would be a NAPTR-RR pointing to the ERC-ENUM of Allegheny County 1.1.9.[WhatEverYouWantLevel2].1.e164.arpa) . . . n.) the phone looks up the ENUM 1.1.9.[LastLayer].1.e164.arpa n+1.) the phone checks it's geographic data against the LOC-records listed in the 1.1.9.[LastLayer].1.e164.arpa-zone and finds the nearest LOC-entry (in your case it would be a NAPTR-RR pointing to the SIP-address of NEWCOM) n+2.) the phone connects to the ERC transmitting it geographical data (longitude, latitude, altitude). n+3.) the ERC looks up the Address/Room, etc. based on the received geographical data and static land office data n+4.) ambulance, police or whatever is send It's a quite easy, reliable, flexible and user-friendly solution. Only the top-level ENUM 1.1.9.e164.arpa has to be fix, in the lower levels you can use ANY domain-name (but I'd suggest to use ENUMs with local prefixes to allow users to directly dial their local area ERC-ENUM in case upper DNS-brances break down by a nuclear war ;-) ). > My proposal will be more complex than this, because I would include > much more information in the DNS. For example, the boundary of > Room 235 on the 5th floor of the Wigit suite at 123 Main Street in > Pittsburgh PA might be found in the DNS at > 235.5.wigit.123.main.pittsburgh.allegheny.pa.us.sos.arpa > > In this proposal, there is a VERY BIG ASSUMPTION. The assumption > is that the DNS is used for PUBLISHING the data, and is not > actually used in the processing of an emergency call. Rather, > I envision that spiders will periodically walk the DNS tree and > extract the boundary information, storing it in a local database > organized to make the operations more efficient. > > Boundary information would be available at intermediate nodes in > this proposal (that is, the boundary of Allegheny County could > be found at allegheny.pa.us.sos.arpa). It is probably the case > that the boundary information below the street address level > would be encrypted if the building owner did not want to make > interior layout information public. > > The data in the DNS would then allow a conversion between civil > (room/floor/building/street address) and geo (lat/lon/altitide). > It would also replace what in the U.S. is called the "Master > Street Address Guide". > > In operation, phones will learn their location, either civil > or geo. They pass that information on a call to sos@. > A proxy routing an emergency call converts a civil to a geo using > the (previously spidered) DNS sos.arpa data if necessary, and > intersects the geo with the ERC service boundaries to find the > serving ERC. The entry in the DNS contains a URI for the ERC, > and the proxy routes the call to that ERC. The ERC gets > location in civil or geo form. It validates a civil by verifying > that the address exists in the sos.arpa domain, or converts a geo > to a (valid) civil for dispatch. what about privacy? If you put the address data of a person into DNS anyone can look it up - No chance to get european countries into the boat! > > You could also imagine a link between sos.arpa and e164.arpa, > whereby for a fixed phone, there was a "domain name" in sos.arpa > stored in the terminal e164.arpa entry that mapped a phone number > to a civil location. This too might be encrypted. You could > use such a mechanism to replace existing "ALI" databases that > convert a caller phone number to a location for legacy phone > systems. > > Note that the delegation mechanism in the DNS is very appropriate > for this purpose: > An international organization (possibly ITU) delegates the > iso country code in sos.arpa to a national agency > The national agency delegates to lower layer political entities > (states in my example) > The (say) state agency, delegates to any lower level agencies > which in turn delegate to lower level agencies. In my > example, PA delegates to Allegheny County, which would > delegate newcom.allegheny.pa.us.sos.arpa to NEWCOM. It > would delegate pittsburgh.allegheny.pa.us to the City of > Pittsburgh. The City would create entries for all of > its streets, and for all of the buildings on those > streets. > The City (township, village,...) would delegate to building > owners > Building owners would (if appropriate) delegate to tenants > Tenants would enter floor/room data > > An entity at some level might decide that it would not actually > delegate lower levels, but create an administrative mechanism to > populate the lower levels. > And such a complex system will never work reliable. If you register all that phones and flats the data will never be up-to-date. Do you really think users will update DNS here and something else here all the time? Rene Bartsch _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Jan 13 18:05:39 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20197 for ; Tue, 13 Jan 2004 18:05:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgXaz-0000Xg-06 for sip-archive@odin.ietf.org; Tue, 13 Jan 2004 18:05:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0DN5C0T002024 for sip-archive@odin.ietf.org; Tue, 13 Jan 2004 18:05:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgXaq-0000VV-0S; Tue, 13 Jan 2004 18:05:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgXaK-0000UE-Lw for sip@optimus.ietf.org; Tue, 13 Jan 2004 18:04:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20071 for ; Tue, 13 Jan 2004 18:04:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgXaH-0004TS-00 for sip@ietf.org; Tue, 13 Jan 2004 18:04:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgXYT-0004Qi-00 for sip@ietf.org; Tue, 13 Jan 2004 18:02:38 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AgXXP-0004Nf-00 for sip@ietf.org; Tue, 13 Jan 2004 18:01:31 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA00955; Tue, 13 Jan 2004 18:00:59 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA07649; Tue, 13 Jan 2004 18:00:59 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Jan 2004 18:00:59 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B62AD@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Rene Bartsch'" , "Rosen, Brian" , sip@ietf.org Subject: RE: [Sip] Suggestion to locate nearest ERC-center by ENUM Date: Tue, 13 Jan 2004 18:00:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Rene 9-1-1 is a valid number (or service invocation) in many dialing plans. In fact, the delegation of 1.9.e164.arpa would be to India, since it owns the +91 country code. A phone with a numeric pad only would dial the "local" emergency number. That would be translated by a routing proxy to the universal emergency URI (sos@localdomain). The draft discusses this. A LOC entry is a single point. You need a boundary. In fact, you need a list of polygons. The "nearest" ERC is not correct. ERCs have defined service boundaries. You must intersect the location (a point) with the boundary to determine which ERC service area the point is located. I'll expand this later, but there are circumstances where there might be more than one ERC serving a given location. This is even more obvious with levels above the ERC; the boundary for the U.S. and Canada for example, cannot be reduced to a point where you can determine which side of the border you are on by comparing distance from a single point to the target location. Your outline of walking the tree differs in detail from my proposal, but it is similar. I start at sos.arpa. You start at 1.1.9.e164.arpa. I use 2 character ISO country codes. You use e.164 numeric country codes. You don't identify the form of "whatever you want". I use political subdivisions that actually do delegation for lower levels. You suffix all entries with 1.1.9, I'm working on a couple different ways of identifying ERC entries. Otherwise, the BASIC idea is the same, the details are quite different. Brian -----Original Message----- From: Rene Bartsch [mailto:ml@bartschnet.de] Sent: Tuesday, January 13, 2004 5:36 PM To: Rosen, Brian; sip@ietf.org Subject: Re: [Sip] Suggestion to locate nearest ERC-center by ENUM Rosen, Brian schrieb: > I'm working on a proposal to use the DNS somewhat like this. > This is a little premature, but Rene brought it up, so.... > > The fundamental difference between what I will propose, and your > proposal is that the phone number mapping to geographic area > breaks down after the country code (for example, in North America, > there is no relationship between the "area code" (first 3 digits > in a phone number) and ERC service boundaries. Also, there is > no agreement on the "number" for emergency calls, The ITU should just delegate ENUM-911 for ERCs world-wide. and in fact, > there is an active draft that should be ready for WGLC soon > that proposes that the SIP URI for an emergency call is > sos@. Therefore, using ENUM like structure isn't > very usefull. > But there is a problem: Most SIP-phones will habe numeric pads, but no alpanumeric 80-key pads. So we cannot use an addressing out of the decimal range - no letters, no "@"! And there's no problem with the number mapping to the geographic area as the geographic is not determined by the area prefixes but by the LOC-records. I think my explanation was a bit misunderstandable. When you do an ERC, 1.) you dial 911 at your phone 2.) the phone looks up the ENUM 1.1.9.e164.arpa 3.) the phone checks it's geographic data against the LOC-records listed in the 1.1.9.e164.arpa-zone and finds the nearest LOC-entry (in your case it would be a NAPTR-RR pointing to the ERC-ENUM of the US - 1.1.9.1.e164.arpa) 4.) the phone looks up the ENUM 1.1.9.1.e164.arpa 5.) the phone checks it's geographic data against the LOC-records listed in the 1.1.9.1.e164.arpa-zone and finds the nearest LOC-entry (in your case it would be a NAPTR-RR pointing to the ERC-ENUM-domain of Pennsylvania - 1.1.9.[WhatEverYouWantLevel1].1.e164.arpa) 6.) the phone looks up the ENUM 1.1.9.[WhatEverYouWantLevel1].1.e164.arpa 7.) the phone checks it's geographic data against the LOC-records listed in the 1.1.9.[WhatEverYouWantLevel1].1.e164.arpa-zone and finds the nearest LOC-entry (in your case it would be a NAPTR-RR pointing to the ERC-ENUM of Allegheny County 1.1.9.[WhatEverYouWantLevel2].1.e164.arpa) . . . n.) the phone looks up the ENUM 1.1.9.[LastLayer].1.e164.arpa n+1.) the phone checks it's geographic data against the LOC-records listed in the 1.1.9.[LastLayer].1.e164.arpa-zone and finds the nearest LOC-entry (in your case it would be a NAPTR-RR pointing to the SIP-address of NEWCOM) n+2.) the phone connects to the ERC transmitting it geographical data (longitude, latitude, altitude). n+3.) the ERC looks up the Address/Room, etc. based on the received geographical data and static land office data n+4.) ambulance, police or whatever is send It's a quite easy, reliable, flexible and user-friendly solution. Only the top-level ENUM 1.1.9.e164.arpa has to be fix, in the lower levels you can use ANY domain-name (but I'd suggest to use ENUMs with local prefixes to allow users to directly dial their local area ERC-ENUM in case upper DNS-brances break down by a nuclear war ;-) ). > My proposal will be more complex than this, because I would include > much more information in the DNS. For example, the boundary of > Room 235 on the 5th floor of the Wigit suite at 123 Main Street in > Pittsburgh PA might be found in the DNS at > 235.5.wigit.123.main.pittsburgh.allegheny.pa.us.sos.arpa > > In this proposal, there is a VERY BIG ASSUMPTION. The assumption > is that the DNS is used for PUBLISHING the data, and is not > actually used in the processing of an emergency call. Rather, > I envision that spiders will periodically walk the DNS tree and > extract the boundary information, storing it in a local database > organized to make the operations more efficient. > > Boundary information would be available at intermediate nodes in > this proposal (that is, the boundary of Allegheny County could > be found at allegheny.pa.us.sos.arpa). It is probably the case > that the boundary information below the street address level > would be encrypted if the building owner did not want to make > interior layout information public. > > The data in the DNS would then allow a conversion between civil > (room/floor/building/street address) and geo (lat/lon/altitide). > It would also replace what in the U.S. is called the "Master > Street Address Guide". > > In operation, phones will learn their location, either civil > or geo. They pass that information on a call to sos@. > A proxy routing an emergency call converts a civil to a geo using > the (previously spidered) DNS sos.arpa data if necessary, and > intersects the geo with the ERC service boundaries to find the > serving ERC. The entry in the DNS contains a URI for the ERC, > and the proxy routes the call to that ERC. The ERC gets > location in civil or geo form. It validates a civil by verifying > that the address exists in the sos.arpa domain, or converts a geo > to a (valid) civil for dispatch. what about privacy? If you put the address data of a person into DNS anyone can look it up - No chance to get european countries into the boat! > > You could also imagine a link between sos.arpa and e164.arpa, > whereby for a fixed phone, there was a "domain name" in sos.arpa > stored in the terminal e164.arpa entry that mapped a phone number > to a civil location. This too might be encrypted. You could > use such a mechanism to replace existing "ALI" databases that > convert a caller phone number to a location for legacy phone > systems. > > Note that the delegation mechanism in the DNS is very appropriate > for this purpose: > An international organization (possibly ITU) delegates the > iso country code in sos.arpa to a national agency > The national agency delegates to lower layer political entities > (states in my example) > The (say) state agency, delegates to any lower level agencies > which in turn delegate to lower level agencies. In my > example, PA delegates to Allegheny County, which would > delegate newcom.allegheny.pa.us.sos.arpa to NEWCOM. It > would delegate pittsburgh.allegheny.pa.us to the City of > Pittsburgh. The City would create entries for all of > its streets, and for all of the buildings on those > streets. > The City (township, village,...) would delegate to building > owners > Building owners would (if appropriate) delegate to tenants > Tenants would enter floor/room data > > An entity at some level might decide that it would not actually > delegate lower levels, but create an administrative mechanism to > populate the lower levels. > And such a complex system will never work reliable. If you register all that phones and flats the data will never be up-to-date. Do you really think users will update DNS here and something else here all the time? Rene Bartsch _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Jan 13 18:45:40 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23447 for ; Tue, 13 Jan 2004 18:45:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgYDi-0002es-Im for sip-archive@odin.ietf.org; Tue, 13 Jan 2004 18:45:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0DNjEY5010212 for sip-archive@odin.ietf.org; Tue, 13 Jan 2004 18:45:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgYDX-0002dU-5A; Tue, 13 Jan 2004 18:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgYD0-0002bi-Lk for sip@optimus.ietf.org; Tue, 13 Jan 2004 18:44:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23316 for ; Tue, 13 Jan 2004 18:44:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgYCx-0006mH-00 for sip@ietf.org; Tue, 13 Jan 2004 18:44:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgYB7-0006ej-00 for sip@ietf.org; Tue, 13 Jan 2004 18:42:34 -0500 Received: from brandt-online.net ([217.160.90.205] helo=p10088371.pureserver.de) by ietf-mx with esmtp (Exim 4.12) id 1AgY9L-0006YR-00 for sip@ietf.org; Tue, 13 Jan 2004 18:40:43 -0500 Received: from bartschnet.de (p5080A8B9.dip0.t-ipconnect.de [80.128.168.185]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by p10088371.pureserver.de (Postfix) with ESMTP id 0DE3E420118; Wed, 14 Jan 2004 00:40:42 +0100 (CET) Message-ID: <400481A5.1050002@bartschnet.de> Date: Wed, 14 Jan 2004 00:39:17 +0100 From: Rene Bartsch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.3) Gecko/20030312 X-Accept-Language: de-at, de, en-us, en MIME-Version: 1.0 To: "Rosen, Brian" , sip@ietf.org Subject: Re: [Sip] Suggestion to locate nearest ERC-center by ENUM References: <313680C9A886D511A06000204840E1CF070B62AD@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF070B62AD@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Rosen, Brian schrieb: > Rene > > 9-1-1 is a valid number (or service invocation) in many dialing plans. > In fact, the delegation of 1.9.e164.arpa would be to India, since it > owns the +91 country code. Ok, we just cut off India ;-) (Should have checked the dialing plans ...) So we'll have to find another, world wide ERC-number or use national ones with country prefix. But looking at internationalization and people crossing the world by plane I'd prefer one world-wide ERC-number. And the ITU has the possibilites to realize that. > > A phone with a numeric pad only would dial the "local" emergency number. > That would be translated by a routing proxy to the universal emergency > URI (sos@localdomain). The draft discusses this. And what if the phone cannot reach a proxy? There should be a Peer2Peer-fallback in such a case. In that situation the translation of numerics to alphanumerics can only be done by ENUM. Our national regulator (Germany) will never allow ERC-systems dependent on one proxy without redundancy! > > A LOC entry is a single point. You need a boundary. In fact, you need > a list of polygons. And how do you define a polygon? If I do remind well from my math-lessons by several points ... > The "nearest" ERC is not correct. ERCs have defined > service boundaries. You must intersect the location (a point) with the > boundary to determine which ERC service area the point is located. > I'll expand this later, but there are circumstances where there might be > more than one ERC serving a given location. This is even more obvious > with levels above the ERC; the boundary for the U.S. and Canada for example, > cannot be reduced to a point where you can determine which side of the > border you are on by comparing distance from a single point to the > target location. A polygon of LOCs ... > > Your outline of walking the tree differs in detail from my proposal, > but it is similar. I start at sos.arpa. You start at 1.1.9.e164.arpa. > I use 2 character ISO country codes. You use e.164 numeric country codes. To be discussed. But I'd prefer ENUM as starting-point to avoid problems with dialing by numeric pads. > You don't identify the form of "whatever you want". I use political > subdivisions that actually do delegation for lower levels. You suffix > all entries with 1.1.9, I'm working on a couple different ways of > identifying > ERC entries. Otherwise, the BASIC idea is the same, the details are > quite different. It's my goal to set up a flexible, common layer based system independent from political issues - you never know how long political/national borders are kept (no Sowjet Union anymore, Germany, France, Great Britain, ... may become EU and maybe Iraq the 53rd federal state of the US ;-) My suggestion allows to use any domains below the top-layer domain. Rene _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Jan 13 21:41:45 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28418 for ; Tue, 13 Jan 2004 21:41:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agay5-0001B4-Fc for sip-archive@odin.ietf.org; Tue, 13 Jan 2004 21:41:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0E2fH0h004465 for sip-archive@odin.ietf.org; Tue, 13 Jan 2004 21:41:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agaxs-00017j-EY; Tue, 13 Jan 2004 21:41:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgaxN-00016g-KF for sip@optimus.ietf.org; Tue, 13 Jan 2004 21:40:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28368 for ; Tue, 13 Jan 2004 21:40:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgaxK-0004vw-00 for sip@ietf.org; Tue, 13 Jan 2004 21:40:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgavY-0004lr-00 for sip@ietf.org; Tue, 13 Jan 2004 21:38:40 -0500 Received: from [61.51.70.99] (helo=mail.udtech.com.cn) by ietf-mx with esmtp (Exim 4.12) id 1Agath-0004Mj-00; Tue, 13 Jan 2004 21:36:48 -0500 Received: from zwx ([61.194.192.236]) by mail.udtech.com.cn (8.12.2/8.11.2) with ESMTP id i0E2UuWC001025; Wed, 14 Jan 2004 10:31:08 +0800 Message-ID: <003301c3da47$753dbf60$1949a8c0@udtech.net> From: "wendy" To: Cc: Date: Wed, 14 Jan 2004 11:37:58 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] SIP DTMF Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello all, Who can tell me whether there is a RFC or I-D on DTMF in SIP which is still not expired? I remember someone proposed using SIP INFO method for DTMF one or two years ago. Is the DTMF relay implemented only by RTP now? Regards, Wendy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Jan 13 22:16:54 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00064 for ; Tue, 13 Jan 2004 22:16:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgbW7-0003Ku-0E for sip-archive@odin.ietf.org; Tue, 13 Jan 2004 22:16:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0E3GQje012763 for sip-archive@odin.ietf.org; Tue, 13 Jan 2004 22:16:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgbVj-0003F8-47; Tue, 13 Jan 2004 22:16:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgbV8-0003Dy-UQ for sip@optimus.ietf.org; Tue, 13 Jan 2004 22:15:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00049 for ; Tue, 13 Jan 2004 22:15:23 -0500 (EST) From: sreeram.kanumuri@wipro.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgbV0-0006k7-00 for sip@ietf.org; Tue, 13 Jan 2004 22:15:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgbOj-0006f0-00 for sip@ietf.org; Tue, 13 Jan 2004 22:08:49 -0500 Received: from wiproecmx1.wipro.com ([164.164.31.5]) by ietf-mx with esmtp (Exim 4.12) id 1AgbMz-0006Sn-00; Tue, 13 Jan 2004 22:07:02 -0500 Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx1.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i0E36TLH015527; Wed, 14 Jan 2004 08:36:29 +0530 (IST) Received: from blr-ec-bh1.wipro.com ([10.200.50.91]) by ec-vwall-wd with InterScan Messaging Security Suite; Wed, 14 Jan 2004 08:37:59 +0530 Received: from blr-ec-msg04.wipro.com ([10.200.53.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 14 Jan 2004 08:36:28 +0530 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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] SIP DTMF Date: Wed, 14 Jan 2004 08:36:28 +0530 Message-ID: <72001BBBF6CB124BA1C40E415914E2130300BF@blr-ec-msg04.wipro.com> Thread-Topic: [Sip] SIP DTMF Thread-Index: AcPaR/R12+2o9NobQ+ikqwjgRuJy0QAAO8TA To: , Cc: X-OriginalArrivalTime: 14 Jan 2004 03:06:28.0772 (UTC) FILETIME=[6757DE40:01C3DA4B] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Wendy, There was a discussion in the list some time back and it was decided that SIP-INFO method should not be used to=20 Send the DTMF info. It was proposed that it is better to you kpxml for sending DTMF tones. Please look in to the SIP-Kpxml draft for sending DTMF tomes in-midcall processing and all....=20 Regards, Sreeram =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Sreeram Kanumuri Plot No 72, Keonics Electronics City Hosur Main Road Wipro Technologies Bangalore -29 INDIA sreeram.kanumuri@wipro.com Phone: 8520408 Ex:3208 skanumury@yahoo.com ESN : www.wipro.com Mobile: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of wendy Sent: Wednesday, January 14, 2004 8:08 AM To: sip@ietf.org Cc: sipping@ietf.org Subject: [Sip] SIP DTMF Hello all,=20 Who can tell me whether there is a RFC or I-D on DTMF in SIP which is still not expired? I remember someone proposed using SIP INFO method for DTMF one or two years ago. Is the DTMF relay implemented only by RTP now? Regards, Wendy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Jan 14 09:18:11 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19763 for ; Wed, 14 Jan 2004 09:18:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aglq2-0001M5-PV for sip-archive@odin.ietf.org; Wed, 14 Jan 2004 09:17:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0EEHg5M005205 for sip-archive@odin.ietf.org; Wed, 14 Jan 2004 09:17:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AglpO-0001GO-Jg; Wed, 14 Jan 2004 09:17:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aglon-0001E7-Cc for sip@optimus.ietf.org; Wed, 14 Jan 2004 09:16:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19631 for ; Wed, 14 Jan 2004 09:16:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aglol-0005T1-00 for sip@ietf.org; Wed, 14 Jan 2004 09:16:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgloM-0005Q3-00 for sip@ietf.org; Wed, 14 Jan 2004 09:16:00 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1Aglns-0005AW-00 for sip@ietf.org; Wed, 14 Jan 2004 09:15:29 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA12987; Wed, 14 Jan 2004 09:14:55 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA15409; Wed, 14 Jan 2004 09:14:56 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 14 Jan 2004 09:14:56 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B62B0@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Rene Bartsch'" , sip@ietf.org Subject: RE: [Sip] Suggestion to locate nearest ERC-center by ENUM Date: Wed, 14 Jan 2004 09:14:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , > So we'll have to find another, world wide ERC-number or use national > ones with country prefix. But looking at internationalization > and people > crossing the world by plane I'd prefer one world-wide ERC-number. And > the ITU has the possibilites to realize that. This is WAY beyond anything the IETF can do, and I think is not practical at this time. If you want to take such an effort on, please go ahead and let us know if you suceed. In the mean time, we will have to deal with current reality, which is that there is no universal number. > > > > > A phone with a numeric pad only would dial the "local" > emergency number. > > That would be translated by a routing proxy to the > universal emergency > > URI (sos@localdomain). The draft discusses this. > > And what if the phone cannot reach a proxy? There should be a > Peer2Peer-fallback in such a case. In that situation the > translation of > numerics to alphanumerics can only be done by ENUM. You are dreaming, I think. Very few phones will know how to do an ENUM lookup. It is not practical for a phone to do the calculations involved in determining the correct psap. Therefore, you will depend on a proxy to do it. There could be more than one (actually, I personally think that EVERY proxy server should be capable of handling an emergency call, even if normally they are short-circuit routed to a proxy that is designated for emergency calls. > > Our national regulator (Germany) will never allow ERC-systems > dependent > on one proxy without redundancy! Redundancy will be required, I agree > > > > > A LOC entry is a single point. You need a boundary. In > fact, you need > > a list of polygons. > > And how do you define a polygon? If I do remind well from my > math-lessons by several points ... Yes, of course. There are many details. We need a new RR to be able to have a list of polygons. We need to have the argument about the format chosen for LOC. I don't think this is a big problem, but it will need new DNS machinery. > > > The "nearest" ERC is not correct. ERCs have defined > > service boundaries. You must intersect the location (a > point) with the > > boundary to determine which ERC service area the point is located. > > I'll expand this later, but there are circumstances where > there might be > > more than one ERC serving a given location. This is even > more obvious > > with levels above the ERC; the boundary for the U.S. and > Canada for example, > > cannot be reduced to a point where you can determine which > side of the > > border you are on by comparing distance from a single point to the > > target location. > > A polygon of LOCs ... A list of a list of LOCS (or something equivalent) > > > > > Your outline of walking the tree differs in detail from my proposal, > > but it is similar. I start at sos.arpa. You start at > 1.1.9.e164.arpa. > > I use 2 character ISO country codes. You use e.164 numeric > country codes. > > To be discussed. But I'd prefer ENUM as starting-point to > avoid problems > with dialing by numeric pads. I agree that a phone with a numeric pad only has to be able to reliably place an emergency call. I don't think we can use ENUM to do that. > > > You don't identify the form of "whatever you want". I use political > > subdivisions that actually do delegation for lower levels. > You suffix > > all entries with 1.1.9, I'm working on a couple different ways of > > identifying > > ERC entries. Otherwise, the BASIC idea is the same, the details are > > quite different. > > It's my goal to set up a flexible, common layer based system > independent > from political issues - you never know how long political/national > borders are kept (no Sowjet Union anymore, Germany, France, Great > Britain, ... may become EU and maybe Iraq the 53rd federal > state of the > US ;-) Yes, but you have to deal with the fact that emergency response is a government function, and is organized by different governments in different ways. My proposal will be acceptable only if the civil format is acceptable to every government. There has been work on this by Henning Schultzrinne. I do think that we can have a multiple level system where the exact meaning of each level is not standardized, but the process for delegation and populating is. That would allow any country to organize its civil location formats as it prefers, and still allow a phone manufactured by any vendor work anywhere, and be able to reliably make emergency calls anywhere. I think that is what you propose, and we are just having a minor semantic difficulty. In my example, you don't need to know that "allegheny" is a county. Its just a level in the DNS tree, where there are levels above and below it. > > My suggestion allows to use any domains below the top-layer domain. > Which I agree with. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Jan 14 11:35:44 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26331 for ; Wed, 14 Jan 2004 11:35:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgnzA-0000pE-QR for sip-archive@odin.ietf.org; Wed, 14 Jan 2004 11:35:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0EGZGNt003171 for sip-archive@odin.ietf.org; Wed, 14 Jan 2004 11:35:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agnyx-0000oJ-8X; Wed, 14 Jan 2004 11:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agnyg-0000mn-0o for sip@optimus.ietf.org; Wed, 14 Jan 2004 11:34:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26284 for ; Wed, 14 Jan 2004 11:34:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Agnyf-0003DK-00 for sip@ietf.org; Wed, 14 Jan 2004 11:34:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Agnxk-0003Br-00 for sip@ietf.org; Wed, 14 Jan 2004 11:33:49 -0500 Received: from brandt-online.net ([217.160.90.205] helo=p10088371.pureserver.de) by ietf-mx with esmtp (Exim 4.12) id 1Agnwt-0003Ak-00 for sip@ietf.org; Wed, 14 Jan 2004 11:32:56 -0500 Received: from bartschnet.de (p5080A4A1.dip0.t-ipconnect.de [80.128.164.161]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by p10088371.pureserver.de (Postfix) with ESMTP id 8767C420118; Wed, 14 Jan 2004 17:32:53 +0100 (CET) Message-ID: <40056EDD.4010300@bartschnet.de> Date: Wed, 14 Jan 2004 17:31:25 +0100 From: Rene Bartsch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.3) Gecko/20030312 X-Accept-Language: de-at, de, en-us, en MIME-Version: 1.0 To: "Rosen, Brian" , sip@ietf.org Subject: Re: [Sip] Suggestion to locate nearest ERC-center by ENUM References: <313680C9A886D511A06000204840E1CF070B62B0@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF070B62B0@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Rosen, Brian schrieb: > This is WAY beyond anything the IETF can do, and I think is not > practical at this time. If you want to take such an effort on, please > go ahead and let us know if you suceed. In the mean time, we will have > to deal with current reality, which is that there is no universal number. > What if they set up a RFC for a inernational ERC-number? I think regulators will adapt it, even if it will last years. > You are dreaming, I think. Very few phones will know how to do > an ENUM lookup. The ENUM-drafts delegate the DNS-lookup to the phones. This is reasonable as it will decrease load for the proxies and increase redundancy as DNS is spread over the world. And it's just some lines of code in the firmware. Simon Morlat has just implemented ENUM into Linphone within a few days. And without dreaming and visions we'd still live in trees ... ;-) > It is not practical for a phone to do the > calculations involved in determining the correct psap. > Therefore, you will depend on a proxy to do it. There could > be more than one (actually, I personally think that EVERY proxy > server should be capable of handling an emergency call, even > if normally they are short-circuit routed to a proxy that is > designated for emergency calls. > This would mean a phone must be capable to handle several proxies. > > Yes, of course. There are many details. We need a new RR to be > able to have a list of polygons. We need to have the argument about > the format chosen for LOC. I don't think this is a big problem, > but it will need new DNS machinery. > Just a firmware-/software update on the DNS machinery, if really necessary. But maybe we can define a geographical area based on one point and a exponential function. That function could just be added to the text-field with coordinates of the standard LOC-entry. > > I agree that a phone with a numeric pad only has to be able to reliably > place an emergency call. I don't think we can use ENUM to do that. > Why not? DNS has proven being the most reliable addressing system in world for 15 years. And setting up a zone-file is quite simple. > > Yes, but you have to deal with the fact that emergency response is a > government function, and is organized by different governments in different > ways. My proposal will be acceptable only if the civil format is acceptable > to every government. There has been work on this by Henning Schultzrinne. > I do think that we can have a multiple level system where the exact > meaning of each level is not standardized, but the process for delegation > and populating is. That would allow any country to organize its civil > location formats as it prefers, and still allow a phone manufactured by any > vendor work anywhere, and be able to reliably make emergency calls anywhere. > > I think that is what you propose, and we are just having a minor semantic > difficulty. In my example, you don't need to know that "allegheny" is > a county. Its just a level in the DNS tree, where there are levels above > and below it. In my example, "alleghny" is just a unspecified level, too. > >>My suggestion allows to use any domains below the top-layer domain. >> > > Which I agree with. The difference between your ideas and mine is just the way of addressing. I want to use ENUM only for reasons of reliability and redundancy and combine the caller's data only in the ERC-center for reasons of privacy, while you want to use proxies which need excessive encryption to ensure privacy and a more complex SIP-protocol, which really isn't "Simple" anymore. And all data of each human being will be published in DNS - a SPAM-friendly world I don't want to live in! I've learned to use simple solutions as complex solutions are quite fragile. Rene _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Jan 14 12:31:42 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29139 for ; Wed, 14 Jan 2004 12:31:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgorL-0004Q3-73 for sip-archive@odin.ietf.org; Wed, 14 Jan 2004 12:31:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0EHVFU9016981 for sip-archive@odin.ietf.org; Wed, 14 Jan 2004 12:31:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agor8-0004Ov-BB; Wed, 14 Jan 2004 12:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgoqE-0004NY-Ec for sip@optimus.ietf.org; Wed, 14 Jan 2004 12:30:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29049 for ; Wed, 14 Jan 2004 12:30:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgoqC-0006It-00 for sip@ietf.org; Wed, 14 Jan 2004 12:30:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgopP-0006Er-00 for sip@ietf.org; Wed, 14 Jan 2004 12:29:16 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1Agoob-00067j-00 for sip@ietf.org; Wed, 14 Jan 2004 12:28:25 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA20548; Wed, 14 Jan 2004 12:27:53 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA18750; Wed, 14 Jan 2004 12:27:54 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 14 Jan 2004 12:27:53 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B62B5@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Rene Bartsch'" , sip@ietf.org Subject: RE: [Sip] Suggestion to locate nearest ERC-center by ENUM Date: Wed, 14 Jan 2004 12:27:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , > > This is WAY beyond anything the IETF can do, and I think is not > > practical at this time. If you want to take such an effort > on, please > > go ahead and let us know if you suceed. In the mean time, > we will have > > to deal with current reality, which is that there is no > universal number. > > > > What if they set up a RFC for a inernational ERC-number? I think > regulators will adapt it, even if it will last years. Because the world numbering plan is "owned" by the ITU, and any attempt to define anything in the e.164 area is going to be impossibly hard. I don't think the IETF would even try to do this, and I don't think we have to. Actually, I think that there is no 3 digit number that would not be in use in some country for a purpose other than emergency calls. > > > You are dreaming, I think. Very few phones will know how to do > > an ENUM lookup. > > The ENUM-drafts delegate the DNS-lookup to the phones. This is > reasonable as it will decrease load for the proxies and increase > redundancy as DNS is spread over the world. And it's just > some lines of > code in the firmware. Simon Morlat has just implemented ENUM into > Linphone within a few days. I don't think the drafts talk about who does the lookup. Most of the systems I know do not have ENUM In the phones, it is in routing proxies. I don't see that changing because there isn't any benefit. We will have to change the way phones work to provide emergency calls, so in theory we could do it, but I don't think it's reasonable, or necessary. I also don't think that numbers are the right way forward for any kind of address, but of course it will be aa LONG time before numeric-only dialing will be obsolete. > > And without dreaming and visions we'd still live in trees ... ;-) > > > It is not practical for a phone to do the > > calculations involved in determining the correct psap. > > Therefore, you will depend on a proxy to do it. There could > > be more than one (actually, I personally think that EVERY proxy > > server should be capable of handling an emergency call, even > > if normally they are short-circuit routed to a proxy that is > > designated for emergency calls. > > > > This would mean a phone must be capable to handle several proxies. Which is a heck of a lot easier than intersecting a point in a series of polygons - in code, execution time, and probability of getting it right in corner cases. > > > > > Yes, of course. There are many details. We need a new RR to be > > able to have a list of polygons. We need to have the argument about > > the format chosen for LOC. I don't think this is a big problem, > > but it will need new DNS machinery. > > > > Just a firmware-/software update on the DNS machinery, if > really necessary. Yes, I think this is relatively easy, although difficult to get agreement on. > > But maybe we can define a geographical area based on one point and a > exponential function. That function could just be added to the > text-field with coordinates of the standard LOC-entry. No, the ERC service area is not defined by any function, it is defined by a political process and described by an irregular physical boundary. There is no way to use any simple function to choose the ERC. You need to know the service boundary polygons of each ERC and intersect your location with them until you find the one that you are inside of. There are circumstances in which you will find that you are in more than one service area, but I'll leave that problem for a little later. > > > > > I agree that a phone with a numeric pad only has to be able > to reliably > > place an emergency call. I don't think we can use ENUM to do that. > > > > Why not? DNS has proven being the most reliable addressing system in > world for 15 years. And setting up a zone-file is quite simple. I'm happy to use the DNS. I don't think you can use e164.arpa as the root. Would you agree that the only difference between your proposal and mine comes down to two things: 1. The root of the tree you want to see is .e164.arpa and the root I propose is .sos.arpa? 2. The terminal nodes in the tree you propose is something like 1.1.9. while the terminal node I propose is something like newcom (or any name for the psap). I'm still discussing my proposal with some DNS folks. It may be that the DNS entry is newcom.psap.allegheny.pa.us.sos.arpa, or it may be that the newcom.allegheny.pa.us.arpa is somehow marked as a psap entry. I think that you can't really take advantage of the fact that the terminal part of your proposal is the emergency calling number, because the middle of the tree is not ENUM. If you branch off the real ENUM tree, then it doesn't matter, much, what the terminal part of the entry looks like - it's a new definition of a part of the DNS. The name doesn't matter to the phone; it has to find all of the service boundaries in the tree, and find the intersection of the point in the polygon. A complication we have to deal with is that in some areas, the psap is located at different depths of the tree. So, for example, you might have a statewide ERC center, but a city ERC for the largest few cities. This means either that the service boundary has holes in it, or that you need a "most specific" kind of search of the tree (and maybe both). I don't think that your proposal is any simpler than mine. I think I have merely thought out exactly how the data in the DNS gets populated, and how you deal with geo as well as civil location. Take, for example, the interior layout information. Right now, in most places I know about, the way that is kept is that the fire marshall carries a big box of paper in his truck. The way that location to a building or a room is communicated between an enterprise and the psap involves a bunch of forms, two or three intermediaries and, sometimes, a fax, that maps a phony phone number to a room/floor/building string. I'm proposing a mechanism that we know will scale well to delegate and populate a database that contains the information needed to respond. Consider, for example, that EVERY CALL needs both a geo and a civil location: You need a geo to find the ERC service boundary, as I have explained. You need a civil to dispatch a responder. Therefore, we need a good source of civil to geo translation. We need that to match what is called a "Master Street Address Guide". We need that to work down to a room on a floor in a building. Not every phone will have geo, not every phone will have civil, but every phone will, we propose, have one or the other. That means we need a universal, reliable conversion database between civil and geo. > > > > > Yes, but you have to deal with the fact that emergency response is a > > government function, and is organized by different > governments in different > > ways. My proposal will be acceptable only if the civil > format is acceptable > > to every government. There has been work on this by > Henning Schultzrinne. > > I do think that we can have a multiple level system where the exact > > meaning of each level is not standardized, but the process > for delegation > > and populating is. That would allow any country to > organize its civil > > location formats as it prefers, and still allow a phone > manufactured by any > > vendor work anywhere, and be able to reliably make > emergency calls anywhere. > > > > I think that is what you propose, and we are just having a > minor semantic > > difficulty. In my example, you don't need to know that > "allegheny" is > > a county. Its just a level in the DNS tree, where there > are levels above > > and below it. > > In my example, "alleghny" is just a unspecified level, too. > > > > >>My suggestion allows to use any domains below the top-layer domain. > >> > > > > Which I agree with. > > The difference between your ideas and mine is just the way of > addressing. I want to use ENUM only for reasons of reliability and > redundancy and combine the caller's data only in the ERC-center for > reasons of privacy, while you want to use proxies which need > excessive > encryption to ensure privacy and a more complex SIP-protocol, which > really isn't "Simple" anymore. And all data of each human > being will be > published in DNS - a SPAM-friendly world I don't want to live in! As above, I think we have the same mechanism to address, up to the ERC boundary location. I propose to go beyond that to solve another real problem. The proxies don't need to decrypt any data to route a call. The ERC would have to decrypt data below building level in order to dispatch to a specific place in a building. I think that is quite reasonable (and the decrypting can be done in advance). I propose to use the DNS to publish the data because the delegation mechanism matches what we need so well. Having the civil to geo translation database to street address level will be usefull for many other purposes as well. I think the SIP part of the problem is in the eye of the beholder. I don't think UAs will implement ENUM, and I think proxies will route emergency calls. You think phones will implement ENUM and phones will be able to directly route calls. The SIP messaging is the same, right? Its only where routing decisions are made. I don't think there is any more data on individual humans in my proposal than yours. There is a more boundary information for the interior of buildings. In some jurisdictions, this is public data already. In most it is not, which is why it needs to be protected. I think the mechanism to do that is simple, and is only between the publisher (building owner or tenant for example) and the emergency response providers. > > I've learned to use simple solutions as complex solutions are > quite fragile. Agree But you have to solve the whole problem, not just a part of it. In emergency calls, there are 4 basic things you have to do: 1. Recognize a call as an emergency call 2. Route the call to the correct ERC 3. Deliver location of the caller 4. Provide a useable call-back identifier for the call The ERCs would also like to be able to prevent the UA from hanging up the call, but I don't think we can give that to them. Brian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Jan 14 20:17:00 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24929 for ; Wed, 14 Jan 2004 20:17:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agw7b-0004dc-FB for sip-archive@odin.ietf.org; Wed, 14 Jan 2004 20:16:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0F1GVaC017767 for sip-archive@odin.ietf.org; Wed, 14 Jan 2004 20:16:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agw79-0004bZ-2U; Wed, 14 Jan 2004 20:16:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agw6E-0004Zl-PK for sip@optimus.ietf.org; Wed, 14 Jan 2004 20:15:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24907 for ; Wed, 14 Jan 2004 20:15:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Agw6C-0005ju-00 for sip@ietf.org; Wed, 14 Jan 2004 20:15:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Agw5H-0005ia-00 for sip@ietf.org; Wed, 14 Jan 2004 20:14:08 -0500 Received: from smtp.sylantro.com ([65.200.90.207]) by ietf-mx with esmtp (Exim 4.12) id 1Agw4o-0005fw-00 for sip@ietf.org; Wed, 14 Jan 2004 20:13:38 -0500 Received: from 10.10.5.1 by smtp.sylantro.com with ESMTP (Tumbleweed MMS SMTP Relay (MMS v5.6.0)); Wed, 14 Jan 2004 17:12:13 -0800 X-Server-Uuid: A2273672-8896-48F6-829D-BBF711663783 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 Jan 2004 17:12:13 -0800 Message-ID: <22ACFCD87A5780449EEBDD6D78BB8DB50C379B@sylmail1> Thread-Topic: Question regarding RFC 3265. Thread-Index: AcPbBJuHuFn5AtxeShup/oIP4S87tQ== From: "Venkatesh Venkataramanan" To: sip@ietf.org, adam@dynamicsoft.com X-WSS-ID: 6C1B37671D073555-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Sip] Question regarding RFC 3265. Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi: Per section 3.3.2 of RFC 3265, a NOTIFY request is considered failed if = a response times out and that if the subscription was installed using = soft-state (SUBSCRIBE), the notifier should remove the subscription. The = reason for this being the subscriber could have crashed or disappeared = for ever.=20 While the above mentioned approach works well where the reasons provided = in the RFC are the real reasons; it has an undesirable side effect in = scenarios where a NOTIFY timesout due to a temporary network outage, an = intermediate proxy crash, et al. It results in a subscriber not getting = status until such time he/she attempts to reSUBSCRIBE. Thus applications = using the same like MWI, presence, dialog state break down until such = period...... Wanted to know if this issue was considered?? Regards, Venkatesh _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Jan 14 21:13:42 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26371 for ; Wed, 14 Jan 2004 21:13:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agx0U-0007D0-KF for sip-archive@odin.ietf.org; Wed, 14 Jan 2004 21:13:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0F2DEQU027649 for sip-archive@odin.ietf.org; Wed, 14 Jan 2004 21:13:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agx0I-0007Ab-77; Wed, 14 Jan 2004 21:13:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgwzU-00079m-Is for sip@optimus.ietf.org; Wed, 14 Jan 2004 21:12:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26328 for ; Wed, 14 Jan 2004 21:12:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgwzS-00078W-00 for sip@ietf.org; Wed, 14 Jan 2004 21:12:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgwyT-00076k-00 for sip@ietf.org; Wed, 14 Jan 2004 21:11:10 -0500 Received: from broadsoft.com ([198.104.184.110]) by ietf-mx with esmtp (Exim 4.12) id 1AgwyF-00075A-00 for sip@ietf.org; Wed, 14 Jan 2004 21:10:55 -0500 Received: from tate (host4.brodsoft.com [66.160.10.4]) by broadsoft.com (8.12.10/8.12.9) with SMTP id i0F2AuKg037934; Wed, 14 Jan 2004 21:10:56 -0500 (EST) Reply-To: From: "Brett Tate" To: "'Venkatesh Venkataramanan'" , Subject: RE: [Sip] Question regarding RFC 3265. Date: Wed, 14 Jan 2004 21:13:25 -0500 Message-ID: <003d01c3db0d$28e83430$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <22ACFCD87A5780449EEBDD6D78BB8DB50C379B@sylmail1> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Per section 3.3.2 of RFC 3265, a NOTIFY request > is considered failed if a response times out and > that if the subscription was installed using > soft-state (SUBSCRIBE), the notifier > should remove the subscription. The reason for this > being the subscriber could have crashed or disappeared > for ever. > While the above mentioned approach works well where the > reasons provided in the RFC are the real reasons; it has an > undesirable side effect in scenarios where a NOTIFY timesout > due to a temporary network outage, an intermediate proxy > crash, et al. It results in a subscriber not getting status > until such time he/she attempts to reSUBSCRIBE. Thus > applications using the same like MWI, presence, dialog state > break down until such period...... Wanted to know if this > issue was considered?? Yes. The same concept is associated with the session-timer and rfc3261; a 408 type situation triggers the release of a call. The strength is currently only a SHOULD. If you want to avoid some customer complaints, you might not want to apply the SHOULD to every event package. You potentially can satisfy the "undue strain on a network" aspects of 3.2.2 by allowing a 408 type situation to trigger a temporary throttling mechanism instead of removing the subscription. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Jan 14 21:30:01 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26960 for ; Wed, 14 Jan 2004 21:30:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgxGG-00005G-Ix for sip-archive@odin.ietf.org; Wed, 14 Jan 2004 21:29:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0F2TW3F032730 for sip-archive@odin.ietf.org; Wed, 14 Jan 2004 21:29:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgxFm-0008MC-CU; Wed, 14 Jan 2004 21:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgxEx-0008Kj-AA for sip@optimus.ietf.org; Wed, 14 Jan 2004 21:28:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26885 for ; Wed, 14 Jan 2004 21:28:08 -0500 (EST) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgxEu-0007k5-00 for sip@ietf.org; Wed, 14 Jan 2004 21:28:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgxDz-0007hz-00 for sip@ietf.org; Wed, 14 Jan 2004 21:27:12 -0500 Received: from imo-r05.mx.aol.com ([152.163.225.101]) by ietf-mx with esmtp (Exim 4.12) id 1AgxDQ-0007dv-00 for sip@ietf.org; Wed, 14 Jan 2004 21:26:36 -0500 Received: from Mpierce1@aol.com by imo-r05.mx.aol.com (mail_out_v36_r4.12.) id c.128.3964bb9e (14374); Wed, 14 Jan 2004 21:25:48 -0500 (EST) Message-ID: <128.3964bb9e.2d37542c@aol.com> Date: Wed, 14 Jan 2004 21:25:48 EST Subject: Re: [Sip] re: WGLC: resource priority To: rohan@cisco.com, sip@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_128.3964bb9e.2d37542c_boundary" X-Mailer: 6.0 for Windows XP sub 10501 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --part1_128.3964bb9e.2d37542c_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 12/31/2003 4:46:50 PM Eastern Standard Time, rohan@cisco.com writes: > 1. There is no normative description of the behavior of SIP devices > which receive a particular priority value. Some specifications needs > to either specify detailed behavior for specific priority values, or > the detailed semantics of those values. I think this belongs in the > IANA registration of each namespace, but those references are currently > very thin. I made some specific comments to this end in the > appropriate sections. > [MAP] I believe this document should be limited to the definition of the data (header) and leave detailed behaviour and procedures to other documents that define specific services/capabilities which use it. It should not specify detailed behaviour for specific priority values. The references to IANA registration are thin because they only describe what IANA needs to deal with - assigning an ordered set of names for the priority levels for each "namespace". > > 3. Finally, the document shows that proxies can modify, insert, and > delete the RP header. I don't think this is a good idea. Where > cooperating UAs and proxies need to agree on an RP value, I believe the > session policy mechanism can be used. A proxy can reject the message > for policy reasons (use a lower/higher/specific resource-value) and the > UA can retry the request with these new values. > [MAP] While it may not be normal for a proxy to modify or delete an RP header, there may be services defined using this header that are based on proxies doing exactly that. For example, an originator tries to place a call using a high priority header. The proxy authenticates, determines tha the user is only authorized a lower priority level, automatically lowers it by changing the RP header, and forwards the call on its way, without requiring the UA to retry the call. Other documents would describe various operations, possibly including some cases in which a proxy can not modify the RP header. Mike Pierce --part1_128.3964bb9e.2d37542c_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message=20= dated 12/31/2003 4:46:50 PM Eastern Standard Time, rohan@cisco.com writes:


1. There is no normative de= scription of the behavior of SIP devices=20
which receive a particular priority value.  Some specifications nee= ds=20
to either specify detailed behavior for specific priority values, or=20
the detailed semantics of those values.  I think this belongs in th= e=20
IANA registration of each namespace, but those references are currently=20
very thin.  I made some specific comments to this end in the=20
appropriate sections.


[MAP] I believe this document should be limited to the definition of the= data (header) and leave detailed behaviour and procedures to other document= s that define specific services/capabilities which use it. It should not spe= cify detailed behaviour for specific priority values. The references to IANA= registration are thin because they only describe what IANA needs to deal wi= th - assigning an ordered set of names for the priority levels for each "nam= espace".


3. Finally, the document shows that proxies can modify, insert, and=20
delete the RP header. I don't think this is a good idea. Where=20
cooperating UAs and proxies need to agree on an RP value, I believe the=20
session policy mechanism can be used.  A proxy can reject the messa= ge=20
for policy reasons (use a lower/higher/specific resource-value) and the=20
UA can retry the request with these new values.



[MAP] While it may not be normal for a proxy to modify or delete an RP h= eader, there may be services defined using this header that are based on pro= xies doing exactly that. For example, an originator tries to place a call us= ing a high priority header. The proxy authenticates, determines tha the user= is only authorized a lower priority level, automatically lowers it by chang= ing the RP header, and forwards the call on its way, without requiring the U= A to retry the call. Other documents would describe various operations, poss= ibly including some cases in which a proxy can not modify the RP header.

Mike Pierce

--part1_128.3964bb9e.2d37542c_boundary-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jan 15 03:53:01 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19827 for ; Thu, 15 Jan 2004 03:53:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah3Eu-0004Pc-EJ for sip-archive@odin.ietf.org; Thu, 15 Jan 2004 03:52:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0F8qWQK016895 for sip-archive@odin.ietf.org; Thu, 15 Jan 2004 03:52:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah3EU-0004Hw-RY; Thu, 15 Jan 2004 03:52:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah3Dq-0004F8-Qe for sip@optimus.ietf.org; Thu, 15 Jan 2004 03:51:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19793 for ; Thu, 15 Jan 2004 03:51:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah3Do-00050j-00 for sip@ietf.org; Thu, 15 Jan 2004 03:51:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah3Cp-0004tD-00 for sip@ietf.org; Thu, 15 Jan 2004 03:50:25 -0500 Received: from eins.siemens.at ([193.81.246.11]) by ietf-mx with esmtp (Exim 4.12) id 1Ah3BJ-0004fu-00 for sip@ietf.org; Thu, 15 Jan 2004 03:48:49 -0500 Received: from mailhost2.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id i0F8mKTm009690 for ; Thu, 15 Jan 2004 09:48:20 +0100 Received: from zagh102a.zag.siemens.hr (nets109x.sie.siemens.at [158.226.134.96]) by mailhost2.sie.siemens.at (8.12.10/8.12.1) with ESMTP id i0F8mHYA017777 for ; Thu, 15 Jan 2004 09:48:19 +0100 Received: by zagh102a.zag.siemens.hr with Internet Mail Service (5.5.2653.19) id ; Thu, 15 Jan 2004 09:41:40 +0100 Message-ID: From: Bilajbegovic Damir To: sip@ietf.org Subject: [Sip] Two IP addresses (c= lines) in invite Date: Thu, 15 Jan 2004 09:41:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , If I sent a INVITE message with two IP addresses (i.e. user has two IP addresses and on one it should receive messages) what happens? Is it valid and how the terminal or proxy should react on this. (there are c= lines ) And one more additional question: If one c= is IPv6 and another line is c= IPv4 and colleen (B) party is IPv4 what does is do? Will B party (or B proxy) reject the message, replay with deleted misunderstood lines, or will put the port numbers on 0. The message invite is down below (I think it should look like this- is it good?) Thanks in advance. Damir Bilajbegovic INVITE tel:+1-212-555-2222 SIP/2.0 ............ v=0 o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd s=- c=IN IP6 5555::aaa:bbb:ccc:ddd t=0 0 m=video 3400 RTP/AVP 98 99 b=AS:75 a=curr:qos local none a=curr:qos remote none a=des:qos mandatory local sendrecv a=des:qos none remote sendrecv a=rtpmap:98 H263 a=fmtp:98 profile-level-id=0 a=rtpmap:99 MP4V-ES c=IN IP6 5555::aaa:bbb:ccc:eee t=0 0 m=video 3400 RTP/AVP 98 99 b=AS:75 a=curr:qos local none a=curr:qos remote none a=des:qos mandatory local sendrecv a=des:qos none remote sendrecv a=rtpmap:98 H263 a=fmtp:98 profile-level-id=0 a=rtpmap:99 MP4V-ES _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jan 15 04:14:08 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20771 for ; Thu, 15 Jan 2004 04:14:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah3Z9-0006M7-6E for sip-archive@odin.ietf.org; Thu, 15 Jan 2004 04:13:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0F9DRPY024425 for sip-archive@odin.ietf.org; Thu, 15 Jan 2004 04:13:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah3Yk-0006LO-Q3; Thu, 15 Jan 2004 04:13:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah3YE-0006Jy-7J for sip@optimus.ietf.org; Thu, 15 Jan 2004 04:12:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20722 for ; Thu, 15 Jan 2004 04:12:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah3YB-00067w-00 for sip@ietf.org; Thu, 15 Jan 2004 04:12:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah3Xd-000655-00 for sip@ietf.org; Thu, 15 Jan 2004 04:11:54 -0500 Received: from gw.softfront.co.jp ([202.232.222.2] helo=mail2.softfront.co.jp) by ietf-mx with smtp (Exim 4.12) id 1Ah3Wo-0005y2-00 for sip@ietf.org; Thu, 15 Jan 2004 04:11:03 -0500 Received: from wstar by mail2.softfront.co.jp id AA03304 ; 15 Jan 2004 18:10:54 +0900 Date: Thu, 15 Jan 2004 18:10:55 +0900 From: OKUMURA Shinji Subject: Re: [Sip] WGLC for PUBLISH To: Rohan Mahy Cc: sip@ietf.org, Dean Willis , aki.niemi@nokia.com Organization: SOFTFRONT In-Reply-To: References: X-Mailer: Datula version 1.50.45 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Message-Id: <200401150910.AA03304@mail2.softfront.co.jp> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , $B1|B<$G$9!#(B $B$*Hh$lMM$G$9!#(B $B0J2<$N%a!<%k$r1QLu$7$F$/$@$5$$!#(B ----------------------------------------------------------------------- [1] 12. Examples$B$N(B M1$B$N(B Contact: $B$O(B Contact: M2$B$N(B Contact: $B$O(B Contact: M3$B$N(B NOTIFY sip:presentity@example.com SIP/2.0 Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK8sdf2 To: ;tag=12341234 From: ;tag=abcd1234 Call-ID: 12345678@10.0.0.1 CSeq: 1 NOTIFY ..... $B$O(B NOTIFY sip:watcher@10.0.0.1 SIP/2.0 Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK8sdf2 To: ;tag=12341234 From: ;tag=abcd1234 Call-ID: 12345678@10.0.0.1 CSeq: 1 NOTIFY Contact: ..... $B$G$O$J$$$+!#(B [2] 12. Examples$B$NNc$O(B PUA <---> PA <---> WATCHER $B$NB>$K(B PUA <---> proxy <---> PA $B$H$$$&Nc$bM_$7$$!#(B $BNc$($P(B PUA <-----> proxy <------> PA | M1 PUBLISH | | |----------->| M2 PUBLISH | | |----------->| | | M3 200 OK | | M4 200 OK |<-----------| |<-----------| | M1 PUBLISH sip:pa@example.com SIP/2.0 Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge From: ;tag=1234wxyz To: Call-ID: 81818181@pua.example.com CSeq: 1 PUBLISH Max-Forwards: 70 Expires: 3600 Event: presence Content-Type: application/pidf+xml Content-Length: ... M2 PUBLISH sip:pa.example.com SIP/2.0 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKpx123 Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge From: ;tag=1234wxyz To: Call-ID: 81818181@pua.example.com CSeq: 1 PUBLISH Max-Forwards: 70 Expires: 3600 Event: presence Content-Type: application/pidf+xml Content-Length: ... M3 SIP/2.0 200 OK Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKpx123 Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge From: ;tag=1234wxyz To: ;tag=1a2b3c4d Call-ID: 81818181@pua.example.com CSeq: 1 PUBLISH SIP-ETag: dx200xyz Expires: 1800 Content-Length: 0 M4 SIP/2.0 200 OK Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge From: ;tag=1234wxyz To: ;tag=1a2b3c4d Call-ID: 81818181@pua.example.com CSeq: 1 PUBLISH SIP-ETag: dx200xyz Expires: 1800 Content-Length: 0 [3] Request-URI$B$O%a%C%;!<%8$N08@h$H$7$F;H$$!"%W%l%<%s%9%j%=!<%9$N(B $B;XDj$O(BTo$B%X%C%@$G9T$&$h$&$K$7$?J}$,NI$$$H;W$&!#(B REGISTER$B$K$h$k%m%1!<%7%g%sEPO?$HF1$8F0:n$KJ}$,$o$+$j$d$9$$!#(B $B$3$NE@$O(BRFC3265$B$K$D$$$F$bF1$8$3$H$,8@$($k!#(B $B$J$<$J$i!"(BRFC3256$B$K$O(B |3.1.5. Proxy SUBSCRIBE Behavior | Proxies need no additional behavior beyond that described in SIP [1] | to support SUBSCRIBE. $B$H$"$k$+$i$G$"$k!#(B [4]$B%W%l%<%s%9%j%=!<%9$r$"$i$o$9(BURI$B$O(Bsip-URI$B$G$O$J$/!"(B pres-URI(draft-ietf-impp-pres-04)$B$,NI$$$H;W$&!#(B $B7k6I(B[3][4]$B$r9g$o$;$k$H0J2<$N$h$&$J(BURI$B$N;H$$J}$,NI$$$H;W$&!#(B +------------+-----------------------------+-----------------------------+-----------------------------+ | | PUBLISH | SUBSCRIBE | NOTIFY | +------------+-----------------------------+-----------------------------+-----------------------------+ |Request-URI | URI of PA | URI of PA | Contact-URI of SUBSCRIBE | | | sip:pa@example.com | sip:pa@example.com | sip:watcher.example.com | +------------+-----------------------------+-----------------------------+-----------------------------+ |To-URI | URI of presence resource | URI of presence resource | From-URI of SUBSCRIBE | | | pres:presentity@example.com | pres:presentity@example.com | sip:watcher@example.com | +------------+-----------------------------+-----------------------------+-----------------------------+ |From-URI | URI of presentity | URI of watcher | To-URI of SUBSCRIBE | | | sip:presentity@example.com | sip:watcher@example.com | pres:presentity@example.com | +------------+-----------------------------+-----------------------------+-----------------------------+ Rohan Mahy wrote in >Hi, > >I'd like to begin Working Group Last Call for PUBLISH: > > http://www.ietf.org/internet-drafts/draft-ietf-sip-publish-02.txt > >This WGLC will end on January 28, 2004. > >thanks, >-rohan ___________________________________________________________ $B1|B<(B $B?-Fs(B ($B3t(B)$B%=%U%H%U%m%s%H(B $B")(B060-0009 $BKL(B9$B>r@>(B15$BCzL\(B28-195 tel:+81-11-623-1003 mailto:shin@softfront.co.jp fax:+81-11-623-1005 sip:shin@softfront.co.jp _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jan 15 04:57:00 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22315 for ; Thu, 15 Jan 2004 04:57:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah4Eq-00009H-8U for sip-archive@odin.ietf.org; Thu, 15 Jan 2004 04:56:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0F9uWig000565 for sip-archive@odin.ietf.org; Thu, 15 Jan 2004 04:56:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah4EO-0008VB-DF; Thu, 15 Jan 2004 04:56:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah4Dh-0008UG-Sc for sip@optimus.ietf.org; Thu, 15 Jan 2004 04:55:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22106 for ; Thu, 15 Jan 2004 04:55:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah4De-0000AG-00 for sip@ietf.org; Thu, 15 Jan 2004 04:55:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah4Cp-00007N-00 for sip@ietf.org; Thu, 15 Jan 2004 04:54:27 -0500 Received: from central.switch.ch ([130.59.11.11]) by ietf-mx with esmtp (Exim 4.12) id 1Ah4CW-00005E-00 for sip@ietf.org; Thu, 15 Jan 2004 04:54:08 -0500 Received: from machb.switch.ch ([130.59.6.129]) by central.switch.ch with esmtp (Exim 3.20 #1) id 1Ah4C2-0000GM-00; Thu, 15 Jan 2004 10:53:38 +0100 Date: Thu, 15 Jan 2004 10:53:38 +0100 (CET) From: Bernie Hoeneisen To: Bilajbegovic Damir cc: sip@ietf.org Subject: Re: [Sip] Two IP addresses (c= lines) in invite In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi Damir! Have you already checked this in RFC 2327 and RFC 3266? http://www.ietf.org/rfc/rfc2327 (SDP) http://www.ietf.org/rfc/rfc3266 (IPv6 extensions to SDP) (Note, that in RFC 3266 there is a typo in section 1, where it refers to RFC 2328. It should be RFC 2327.) According to RFC 2327 (section 6) you can have either one connection 'c= ' line for the whole session or then serveral connection 'c= ' lines per media 'm= ' line. In the lattter the connection 'c= ' lines must appear after the media 'm= ' lines. I just wonder, how many SIP implementations out in the world do handle this as standardized... cheers, Bernie On Thu, 15 Jan 2004, Bilajbegovic Damir wrote: > If I sent a INVITE message with two IP addresses (i.e. user has two IP > addresses and on one it should receive messages) what happens? > Is it valid and how the terminal or proxy should react on this. (there are > c= lines ) > And one more additional question: If one c= is IPv6 and another line is c= > IPv4 and colleen (B) party is IPv4 what does is do? Will B party (or B > proxy) reject the message, replay with deleted misunderstood lines, or will > put the port numbers on 0. > The message invite is down below (I think it should look like this- is it > good?) > Thanks in advance. > > Damir Bilajbegovic > > INVITE tel:+1-212-555-2222 SIP/2.0 > > ............ > > v=0 > o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd > s=- > c=IN IP6 5555::aaa:bbb:ccc:ddd > t=0 0 > m=video 3400 RTP/AVP 98 99 > b=AS:75 > a=curr:qos local none > a=curr:qos remote none > a=des:qos mandatory local sendrecv > a=des:qos none remote sendrecv > a=rtpmap:98 H263 > a=fmtp:98 profile-level-id=0 > a=rtpmap:99 MP4V-ES > > > c=IN IP6 5555::aaa:bbb:ccc:eee > t=0 0 > m=video 3400 RTP/AVP 98 99 > b=AS:75 > a=curr:qos local none > a=curr:qos remote none > a=des:qos mandatory local sendrecv > a=des:qos none remote sendrecv > a=rtpmap:98 H263 > a=fmtp:98 profile-level-id=0 > a=rtpmap:99 MP4V-ES > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jan 15 05:52:03 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26545 for ; Thu, 15 Jan 2004 05:52:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah564-0004MY-9x for sip-archive@odin.ietf.org; Thu, 15 Jan 2004 05:51:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0FApW0N016771 for sip-archive@odin.ietf.org; Thu, 15 Jan 2004 05:51:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah55b-0004DB-OL; Thu, 15 Jan 2004 05:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah559-0004CE-8f for sip@optimus.ietf.org; Thu, 15 Jan 2004 05:50:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26517 for ; Thu, 15 Jan 2004 05:50:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah555-0005AQ-00 for sip@ietf.org; Thu, 15 Jan 2004 05:50:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah548-00057j-00 for sip@ietf.org; Thu, 15 Jan 2004 05:49:33 -0500 Received: from gw.softfront.co.jp ([202.232.222.2] helo=mail2.softfront.co.jp) by ietf-mx with smtp (Exim 4.12) id 1Ah53n-00054s-00 for sip@ietf.org; Thu, 15 Jan 2004 05:49:11 -0500 Received: from wstar by mail2.softfront.co.jp id AA03044 ; 15 Jan 2004 19:49:09 +0900 Date: Thu, 15 Jan 2004 19:49:09 +0900 From: OKUMURA Shinji Subject: Re: [Sip] WGLC for PUBLISH To: Rohan Mahy Cc: sip@ietf.org, Dean Willis , aki.niemi@nokia.com Organization: SOFTFRONT X-Priority: 3 In-Reply-To: <200401150912.AA02192@mail2.softfront.co.jp> References: <200401150912.AA02192@mail2.softfront.co.jp> X-Mailer: Datula version 1.50.45 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Message-Id: <200401151049.AA03044@mail2.softfront.co.jp> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi, [1] I believe it requires following changes in some headers of the illustrated example in section 12. In M1, Contact: should be rewritten as Contact: In M2, Contact: should be Contact: In M3, NOTIFY sip:presentity@example.com SIP/2.0 Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK8sdf2 To: ;tag=12341234 From: ;tag=abcd1234 Call-ID: 12345678@10.0.0.1 CSeq: 1 NOTIFY .... should be NOTIFY sip:watcher@10.0.0.1 SIP/2.0 Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK8sdf2 To: ;tag=12341234 From: ;tag=abcd1234 Call-ID: 12345678@10.0.0.1 CSeq: 1 NOTIFY Contact: .... [2] It could be helpful if the following example (2) is added in the document as an addition to the only example (1) illustrated in section 12. (1) PUA <---> PA <---> WATCHER (2) PUA <---> proxy <---> PA For example: PUA <-----> proxy <------> PA | | | | M1 PUBLISH | | |----------->| M2 PUBLISH | | |----------->| | | M3 200 OK | | M4 200 OK |<-----------| |<-----------| | M1: PUBLISH sip:pa@example.com SIP/2.0 Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge From: ;tag=1234wxyz To: Call-ID: 81818181@pua.example.com CSeq: 1 PUBLISH Max-Forwards: 70 Expires: 3600 Event: presence Content-Type: application/pidf+xml Content-Length: ... M2: PUBLISH sip:pa.example.com SIP/2.0 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKpx123 Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge From: ;tag=1234wxyz To: Call-ID: 81818181@pua.example.com CSeq: 1 PUBLISH Max-Forwards: 70 Expires: 3600 Event: presence Content-Type: application/pidf+xml Content-Length: ... M3: SIP/2.0 200 OK Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKpx123 Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge From: ;tag=1234wxyz To: ;tag=1a2b3c4d Call-ID: 81818181@pua.example.com CSeq: 1 PUBLISH SIP-ETag: dx200xyz Expires: 1800 Content-Length: 0 M4: SIP/2.0 200 OK Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge From: ;tag=1234wxyz To: ;tag=1a2b3c4d Call-ID: 81818181@pua.example.com CSeq: 1 PUBLISH SIP-ETag: dx200xyz Expires: 1800 Content-Length: 0 [3] It could be better if the "Request-URI" is used as the message's target address and the 'Presence Resource' is specified using "To" header. It would be easy for understanding if REGISTER's location registration operation like mechanism is considered. The same point could also be said about RFC3265. This is because, |3.1.5. Proxy SUBSCRIBE Behavior | Proxies need no additional behavior beyond that described in SIP [1] | to support SUBSCRIBE. [4] For expressing 'Presence Resource', the pres-URI(draft-ietf-impp-pres-04) would be better than that of the sip-URI. Finally, when [3] & [4] are considered together, the various usages of URI can be expressed as listed below. +------------+-----------------------------+-----------------------------+-----------------------------+ | | PUBLISH | SUBSCRIBE | NOTIFY | +------------+-----------------------------+-----------------------------+-----------------------------+ |Request-URI | URI of PA | URI of PA | Contact-URI of SUBSCRIBE | | | sip:pa@example.com | sip:pa@example.com | sip:watcher.example.com | +------------+-----------------------------+-----------------------------+-----------------------------+ |To-URI | URI of presence resource | URI of presence resource | From-URI of SUBSCRIBE | | | pres:presentity@example.com | pres:presentity@example.com | sip:watcher@example.com | +------------+-----------------------------+-----------------------------+-----------------------------+ |From-URI | URI of presentity | URI of watcher | To-URI of SUBSCRIBE | | | sip:presentity@example.com | sip:watcher@example.com | pres:presentity@example.com | +------------+-----------------------------+-----------------------------+-----------------------------+ Regards, shinji Rohan Mahy wrote in >Hi, > >I'd like to begin Working Group Last Call for PUBLISH: > > http://www.ietf.org/internet-drafts/draft-ietf-sip-publish-02.txt > >This WGLC will end on January 28, 2004. > >thanks, >-rohan _________________________________________________ OKUMURA Shinji E-mail:shin@softfront.co.jp _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jan 15 07:08:57 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00457 for ; Thu, 15 Jan 2004 07:08:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah6IY-00017m-30 for sip-archive@odin.ietf.org; Thu, 15 Jan 2004 07:08:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0FC8UtH004316 for sip-archive@odin.ietf.org; Thu, 15 Jan 2004 07:08:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah6I8-00010m-8P; Thu, 15 Jan 2004 07:08:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah6Hr-0000wB-2S for sip@optimus.ietf.org; Thu, 15 Jan 2004 07:07:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00271 for ; Thu, 15 Jan 2004 07:07:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah6Hm-0002RP-00 for sip@ietf.org; Thu, 15 Jan 2004 07:07:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah6Gs-0002KD-00 for sip@ietf.org; Thu, 15 Jan 2004 07:06:47 -0500 Received: from eins.siemens.at ([193.81.246.11]) by ietf-mx with esmtp (Exim 4.12) id 1Ah6Ft-00029P-00 for sip@ietf.org; Thu, 15 Jan 2004 07:05:45 -0500 Received: from mailhost2.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id i0FC5FTm012077; Thu, 15 Jan 2004 13:05:15 +0100 Received: from zagh102a.zag.siemens.hr (nets109x.sie.siemens.at [158.226.134.96]) by mailhost2.sie.siemens.at (8.12.10/8.12.1) with ESMTP id i0FC5DYA010632; Thu, 15 Jan 2004 13:05:14 +0100 Received: by zagh102a.zag.siemens.hr with Internet Mail Service (5.5.2653.19) id ; Thu, 15 Jan 2004 12:58:36 +0100 Message-ID: From: Bilajbegovic Damir To: Bernie Hoeneisen Cc: sip@ietf.org Subject: RE: [Sip] Two IP addresses (c= lines) in invite Date: Thu, 15 Jan 2004 12:56:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi, Yes I looked for it and I did not see the answer. It answers about hawing the lines "c= ..." but it doesn't say how it reacts when this message is not valid. Regards Damir Bilajbegovic -----Original Message----- From: Bernie Hoeneisen [mailto:bhoeneis@switch.ch] Sent: Thursday, January 15, 2004 10:54 AM To: Bilajbegovic Damir Cc: sip@ietf.org Subject: Re: [Sip] Two IP addresses (c= lines) in invite Hi Damir! Have you already checked this in RFC 2327 and RFC 3266? http://www.ietf.org/rfc/rfc2327 (SDP) http://www.ietf.org/rfc/rfc3266 (IPv6 extensions to SDP) (Note, that in RFC 3266 there is a typo in section 1, where it refers to RFC 2328. It should be RFC 2327.) According to RFC 2327 (section 6) you can have either one connection 'c= ' line for the whole session or then serveral connection 'c= ' lines per media 'm= ' line. In the lattter the connection 'c= ' lines must appear after the media 'm= ' lines. I just wonder, how many SIP implementations out in the world do handle this as standardized... cheers, Bernie On Thu, 15 Jan 2004, Bilajbegovic Damir wrote: > If I sent a INVITE message with two IP addresses (i.e. user has > two IP addresses and on one it should receive messages) what happens? > Is it valid and how the terminal or proxy should react on this. (there > are c= lines ) And one more additional question: If one c= is IPv6 and > another line is c= IPv4 and colleen (B) party is IPv4 what does is do? > Will B party (or B > proxy) reject the message, replay with deleted misunderstood lines, or > will put the port numbers on 0. The message invite is down below (I > think it should look like this- is it > good?) > Thanks in advance. > > Damir Bilajbegovic > > INVITE tel:+1-212-555-2222 SIP/2.0 > > ............ > > v=0 > o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd > s=- > c=IN IP6 5555::aaa:bbb:ccc:ddd > t=0 0 > m=video 3400 RTP/AVP 98 99 > b=AS:75 > a=curr:qos local none > a=curr:qos remote none > a=des:qos mandatory local sendrecv > a=des:qos none remote sendrecv > a=rtpmap:98 H263 > a=fmtp:98 profile-level-id=0 > a=rtpmap:99 MP4V-ES > > > c=IN IP6 5555::aaa:bbb:ccc:eee > t=0 0 > m=video 3400 RTP/AVP 98 99 > b=AS:75 > a=curr:qos local none > a=curr:qos remote none > a=des:qos mandatory local sendrecv > a=des:qos none remote sendrecv > a=rtpmap:98 H263 > a=fmtp:98 profile-level-id=0 > a=rtpmap:99 MP4V-ES > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jan 15 08:08:03 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03186 for ; Thu, 15 Jan 2004 08:08:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah7Dh-0004l7-BN for sip-archive@odin.ietf.org; Thu, 15 Jan 2004 08:07:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0FD7XNJ018281 for sip-archive@odin.ietf.org; Thu, 15 Jan 2004 08:07:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah7DC-0004TA-Cl; Thu, 15 Jan 2004 08:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah7CS-0004PX-W9 for sip@optimus.ietf.org; Thu, 15 Jan 2004 08:06:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02877 for ; Thu, 15 Jan 2004 08:06:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah7CR-0005pU-00 for sip@ietf.org; Thu, 15 Jan 2004 08:06:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah7AS-0005R3-00 for sip@ietf.org; Thu, 15 Jan 2004 08:04:13 -0500 Received: from central.switch.ch ([130.59.11.11]) by ietf-mx with esmtp (Exim 4.12) id 1Ah78H-00054X-00 for sip@ietf.org; Thu, 15 Jan 2004 08:01:57 -0500 Received: from machb.switch.ch ([130.59.6.129]) by central.switch.ch with esmtp (Exim 3.20 #1) id 1Ah77M-0005WT-00; Thu, 15 Jan 2004 14:01:00 +0100 Date: Thu, 15 Jan 2004 14:00:59 +0100 (CET) From: Bernie Hoeneisen To: Bilajbegovic Damir cc: sip@ietf.org Subject: RE: [Sip] Two IP addresses (c= lines) in invite In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi Damir! What about: 400 Bad Request RFC 3261, 21.4.1: "400 Bad Request The request could not be understood due to malformed syntax. ..." But I have a feeling, that is is not what you are looking for. Maybe you'd ask the sip-implementors list for current practice on this issue: http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors Regards, Bernie On Thu, 15 Jan 2004, Bilajbegovic Damir wrote: > Hi, > Yes I looked for it and I did not see the answer. > It answers about hawing the lines "c= ..." but it doesn't say how it reacts > when this message is not valid. > > Regards Damir Bilajbegovic > -----Original Message----- > From: Bernie Hoeneisen [mailto:bhoeneis@switch.ch] > Sent: Thursday, January 15, 2004 10:54 AM > To: Bilajbegovic Damir > Cc: sip@ietf.org > Subject: Re: [Sip] Two IP addresses (c= lines) in invite > > > Hi Damir! > > Have you already checked this in RFC 2327 and RFC 3266? > > http://www.ietf.org/rfc/rfc2327 (SDP) > http://www.ietf.org/rfc/rfc3266 (IPv6 extensions to SDP) > > (Note, that in RFC 3266 there is a typo in section 1, where it refers to > RFC 2328. It should be RFC 2327.) > > According to RFC 2327 (section 6) you can have either one connection 'c= ' > line for the whole session or then serveral connection 'c= ' lines per media > 'm= ' line. In the lattter the connection 'c= ' lines must appear after the > media 'm= ' lines. > > I just wonder, how many SIP implementations out in the world do handle this > as standardized... > > cheers, > Bernie > > > > On Thu, 15 Jan 2004, Bilajbegovic Damir wrote: > > > If I sent a INVITE message with two IP addresses (i.e. user has > > two IP addresses and on one it should receive messages) what happens? > > Is it valid and how the terminal or proxy should react on this. (there > > are c= lines ) And one more additional question: If one c= is IPv6 and > > another line is c= IPv4 and colleen (B) party is IPv4 what does is do? > > Will B party (or B > > proxy) reject the message, replay with deleted misunderstood lines, or > > will put the port numbers on 0. The message invite is down below (I > > think it should look like this- is it > > good?) > > Thanks in advance. > > > > Damir Bilajbegovic > > > > INVITE tel:+1-212-555-2222 SIP/2.0 > > > > ............ > > > > v=0 > > o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd > > s=- > > c=IN IP6 5555::aaa:bbb:ccc:ddd > > t=0 0 > > m=video 3400 RTP/AVP 98 99 > > b=AS:75 > > a=curr:qos local none > > a=curr:qos remote none > > a=des:qos mandatory local sendrecv > > a=des:qos none remote sendrecv > > a=rtpmap:98 H263 > > a=fmtp:98 profile-level-id=0 > > a=rtpmap:99 MP4V-ES > > > > > > c=IN IP6 5555::aaa:bbb:ccc:eee > > t=0 0 > > m=video 3400 RTP/AVP 98 99 > > b=AS:75 > > a=curr:qos local none > > a=curr:qos remote none > > a=des:qos mandatory local sendrecv > > a=des:qos none remote sendrecv > > a=rtpmap:98 H263 > > a=fmtp:98 profile-level-id=0 > > a=rtpmap:99 MP4V-ES > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip Use > > sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jan 15 08:53:42 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05338 for ; Thu, 15 Jan 2004 08:53:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah7vt-000809-Oq for sip-archive@odin.ietf.org; Thu, 15 Jan 2004 08:53:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0FDrDmo030751 for sip-archive@odin.ietf.org; Thu, 15 Jan 2004 08:53:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah7vi-0007yL-5x; Thu, 15 Jan 2004 08:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah7vT-0007xw-WA for sip@optimus.ietf.org; Thu, 15 Jan 2004 08:52:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05267 for ; Thu, 15 Jan 2004 08:52:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah7vS-0001Dz-00 for sip@ietf.org; Thu, 15 Jan 2004 08:52:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah7uU-0001Af-00 for sip@ietf.org; Thu, 15 Jan 2004 08:51:47 -0500 Received: from phobos.simply.net ([81.3.64.11]) by ietf-mx with smtp (Exim 4.12) id 1Ah7u3-00015y-00 for sip@ietf.org; Thu, 15 Jan 2004 08:51:19 -0500 Received: (qmail 9133 invoked from network); 15 Jan 2004 13:50:46 -0000 Received: from 145-232-28.dial.terra.cl (HELO albers) (200.28.232.145) by phobos.simply.net with SMTP; 15 Jan 2004 13:50:46 -0000 From: "Ken Carlberg" To: Subject: [Sip] re: WGLC: resource priority Date: Thu, 15 Jan 2004 08:50:34 -0500 Message-ID: <000901c3db6e$8e1719f0$91e81cc8@albers> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit My apologies for the tardy comments on this thread. > From: Rohan Mahy > Date: Wed, 31 Dec 2003 13:42:01 -0800 > > 1. There is no normative description of the behavior of SIP devices > which receive a particular priority value. Some specifications needs > to either specify detailed behavior for specific priority values, or > the detailed semantics of those values. I think this belongs in the > IANA registration of each namespace, but those references are currently > very thin. I made some specific comments to this end in the appropriate > sections. I'll agree with Mike Pierce on this. The header is just a vessel designed to facilitate carrying a variety of values. Specifications and descriptions of behavior should not be in this draft. > include a registration template (for example) > > Namespace: > Description: > Organization Responsible for Change Control of this Namespace: > Priority values (ordered from least priority to greatest priority): > Default priority: > Preempt or Prioritize: > Document Containing Normative Description: > Section Containing Normative Description: > Additional security requirements: I'm not thrilled about a registration template in this document at this time. My feeling is that should be addressed by subsequent document(s) since the form of the registration is outside the scope of the header. As an example, I would take issue with line three above "Organization responsible for Change Control". On the surface, this implies versioning of the namespace, which we don't have in the R-P header format, and continued control by that organization. Outside of who is right or wrong on that point of discussion, it seems to me that its out of scope of the definition of the header. > would also consider including Section B.1 as section 9.4, B.2 -> 9.5, > B.3 -> 9.6 Given what I've stated above, I'd like section B to stay outside of the body of the draft. The items listed in that section are only an example to consider. Also, my preference would be to remove section A. I think its helpful for the drafts initial introduction to the group, but in the end, it's a bit of overkill for the final document. Regards, -ken _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jan 15 12:10:38 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15064 for ; Thu, 15 Jan 2004 12:10:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhB0V-0003oL-7N for sip-archive@odin.ietf.org; Thu, 15 Jan 2004 12:10:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0FHABZE014648 for sip-archive@odin.ietf.org; Thu, 15 Jan 2004 12:10:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhB0L-0003nE-P6; Thu, 15 Jan 2004 12:10:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhAzz-0003mS-RY for sip@optimus.ietf.org; Thu, 15 Jan 2004 12:09:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15044 for ; Thu, 15 Jan 2004 12:09:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhAzy-0003uX-00 for sip@ietf.org; Thu, 15 Jan 2004 12:09:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhAz7-0003sK-00 for sip@ietf.org; Thu, 15 Jan 2004 12:08:46 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AhAyC-0003mk-00 for sip@ietf.org; Thu, 15 Jan 2004 12:07:48 -0500 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0FH7GGN019173; Thu, 15 Jan 2004 09:07:16 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id APH47660; Thu, 15 Jan 2004 09:07:14 -0800 (PST) Date: Thu, 15 Jan 2004 09:08:51 -0800 Subject: Re: [Sip] re: WGLC: resource priority Content-Type: multipart/alternative; boundary=Apple-Mail-8--757432981 Mime-Version: 1.0 (Apple Message framework v553) Cc: sip@ietf.org To: Mpierce1@aol.com From: Rohan Mahy In-Reply-To: <128.3964bb9e.2d37542c@aol.com> Message-Id: <7D9C8DA7-477D-11D8-999C-0003938AF740@cisco.com> X-Mailer: Apple Mail (2.553) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --Apple-Mail-8--757432981 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Mike, comments inline... On Wednesday, January 14, 2004, at 06:25 PM, Mpierce1@aol.com wrote: > In a message dated 12/31/2003 4:46:50 PM Eastern Standard Time,=20 > rohan@cisco.com writes: > > 1. There is no normative description of the behavior of SIP devices > which receive a particular priority value. =A0Some specifications = needs > to either specify detailed behavior for specific priority values, or > the detailed semantics of those values. =A0I think this belongs in the > IANA registration of each namespace, but those references are = currently > very thin. =A0I made some specific comments to this end in the > appropriate sections. > > [MAP] I believe this document should be limited to the definition of=20= > the data (header) and leave detailed behaviour and procedures to other=20= > documents that define specific services/capabilities which use it. It=20= > should not specify detailed behaviour for specific priority values.=20 > The references to IANA registration are thin because they only=20 > describe what IANA needs to deal with - assigning an ordered set of=20 > names for the priority levels for each "namespace". How will an *implementer* determine correct behavior without a=20 normative description or reference? This kind of reference is not=20 unusual in IANA registrations. > 3. Finally, the document shows that proxies can modify, insert, and > delete the RP header. I don't think this is a good idea. Where > cooperating UAs and proxies need to agree on an RP value, I believe = the > session policy mechanism can be used. =A0A proxy can reject the = message > for policy reasons (use a lower/higher/specific resource-value) and = the > UA can retry the request with these new values. > > [MAP] While it may not be normal for a proxy to modify or delete an RP=20= > header, there may be services defined using this header that are based=20= > on proxies doing exactly that. For example, an originator tries to=20 > place a call using a high priority header. The proxy authenticates,=20 > determines tha the user is only authorized a lower priority level,=20 > automatically lowers it by changing the RP header, and forwards the=20 > call on its way, without requiring the UA to retry the call. Other=20 > documents would describe various operations, possibly including some=20= > cases in which a proxy can not modify the RP header. How is this any different from any of the other proxy modifications=20 (ex: modifying SDP) which we've decided to avoid by using session=20 policy? Cooperating user agents can easily find out what the policy is=20= and would only very rarely have to retry a call (no extra round trips=20 for most calls). Non-cooperating user agents have their non-policy=20 conforming requests rejected. thanks, -rohan --Apple-Mail-8--757432981 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Mike, comments inline... On Wednesday, January 14, 2004, at 06:25 PM, Mpierce1@aol.com wrote: ArialIn a message dated 12/31/2003 4:46:50 PM Eastern Standard Time, rohan@cisco.com writes: 1. There is no normative description of the behavior of SIP devices which receive a particular priority value. =A0Some specifications needs to either specify detailed behavior for specific priority values, or the detailed semantics of those values. =A0I think this belongs in the IANA registration of each namespace, but those references are currently very thin. =A0I made some specific comments to this end in the appropriate sections. [MAP] I believe this document should be limited to the definition of the data (header) and leave detailed behaviour and procedures to other documents that define specific services/capabilities which use it. It should not specify detailed behaviour for specific priority values. The references to IANA registration are thin because they only describe what IANA needs to deal with - assigning an ordered set of names for the priority levels for each "namespace". How will an *implementer* determine correct behavior without a normative description or reference? This kind of reference is not unusual in IANA registrations. 3. Finally, the document shows that proxies can modify, insert, and delete the RP header. I don't think this is a good idea. Where cooperating UAs and proxies need to agree on an RP value, I believe the session policy mechanism can be used. =A0A proxy can reject the message for policy reasons (use a lower/higher/specific resource-value) and the UA can retry the request with these new values. = Arial0000,0000,0000[MAP] While it may not be normal for a proxy to modify or delete an RP header, there may be services defined using this header that are based on proxies doing exactly that. For example, an originator tries to place a call using a high priority header. The proxy authenticates, determines tha the user is only authorized a lower priority level, automatically lowers it by changing the RP header, and forwards the call on its way, without requiring the UA to retry the call. Other documents would describe various operations, possibly including some cases in which a proxy can not modify the RP header. How is this any different from any of the other proxy modifications (ex: modifying SDP) which we've decided to avoid by using session policy? Cooperating user agents can easily find out what the policy is and would only very rarely have to retry a call (no extra round trips for most calls). Non-cooperating user agents have their non-policy conforming requests rejected. thanks, -rohan --Apple-Mail-8--757432981-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jan 15 12:17:03 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15540 for ; Thu, 15 Jan 2004 12:17:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhB6g-0004Ov-IQ for sip-archive@odin.ietf.org; Thu, 15 Jan 2004 12:16:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0FHGYin016918 for sip-archive@odin.ietf.org; Thu, 15 Jan 2004 12:16:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhB6B-0004IX-Hl; Thu, 15 Jan 2004 12:16:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhB5n-0004HL-KU for sip@optimus.ietf.org; Thu, 15 Jan 2004 12:15:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15480 for ; Thu, 15 Jan 2004 12:15:36 -0500 (EST) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhB5m-0004Jj-00 for sip@ietf.org; Thu, 15 Jan 2004 12:15:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhB4w-0004Hc-00 for sip@ietf.org; Thu, 15 Jan 2004 12:14:47 -0500 Received: from imo-d04.mx.aol.com ([205.188.157.36]) by ietf-mx with esmtp (Exim 4.12) id 1AhB4D-0004Ap-00 for sip@ietf.org; Thu, 15 Jan 2004 12:14:01 -0500 Received: from Mpierce1@aol.com by imo-d04.mx.aol.com (mail_out_v36_r4.12.) id c.139.2a12df5e (3948); Thu, 15 Jan 2004 12:13:14 -0500 (EST) Message-ID: <139.2a12df5e.2d38242a@aol.com> Date: Thu, 15 Jan 2004 12:13:14 EST Subject: Re: [Sip] re: WGLC: resource priority To: rohan@cisco.com, sip@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_139.2a12df5e.2d38242a_boundary" X-Mailer: 6.0 for Windows XP sub 10501 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --part1_139.2a12df5e.2d38242a_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Regarding IANA Considerations: In a message dated 12/31/2003 4:46:50 PM Eastern Standard Time, rohan@cisco.com writes: > include a registration template (for example) > > Namespace: > Description: > Organization Responsible for Change Control of this Namespace: > Priority values (ordered from least priority to greatest priority): > Default priority: > Preempt or Prioritize: > Document Containing Normative Description: > Section Containing Normative Description: > Additional security requirements: > > Namespace: q735 > Description: ITU Q.735.3 Multi-level precedence and preemption in SS7 > Organization Responsible for Change Control of this Namespace: ITU-T > Priority values (ordered from least priority to greatest priority): 4, > 3, 2, 1, 0 > Default priority: 4 > Preempt or Prioritize: prioritize > Document Containing Normative Description: ITU-T Q.735.3 [3] > Section Containing Normative Description: ?? > Additional security requirements: none > > Namespace: dsrn > Description: United States Defense Red Switched Network > Organization Responsible for Change Control of this Namespace: US > Department of Defense? > Priority values (ordered from least priority to greatest priority): > routine, priority, immediate, flash, flash-override, > flash-override-override > Default priority: routine > Preempt or Prioritize: preempt > Document Containing Normative Description: FIPS XXXX ?? [?] > Section Containing Normative Description: ?? > Additional security requirements: All implementations must follow the > certificate management guidelines specified in xxxx [?] > I presume that, if these namespaces are registered by inclusion in this RFC, then change control continues to be under control of the IETF, by revision of this RFC. (In fact, the text indicates that changes "should not" occur.) Other namespaces registered later are under change control of whoever registers them. (It isn't clear to me who can register new namespaces, and how.) The IANA considerations and registration information should only contain what is needed for the registration. "Preempt or Prioritize" is not needed as part of the registration. It is a detail to be described in other RFCs or documents for the particular application. For example, some service might require that either be done depending on other conditions. In addition, there may be preferential treatments that would not be classified as either "preempt" or "prioritize", as described in my draft on the subject. Note that Section 2 of this draft lists 4 treatments, some of which I would not classify as being either "preempt" or "prioritize". The security requirements depend on the application, so the registration should not make normative statements about what "MUST" be done. Further, in Section 12, I believe it is necessary that the registration indicate the relative precedence levels (as shown in the above suggested template), not "may". It doesn't seem to make sense to not require specifying order, but yet require a default. I continue to believe that every namespace must have at least two priority values defined. The statements in Section 3 indicate otherwise. A namespace with only one value (which therefore must be the default) would be useless. Mike Pierce --part1_139.2a12df5e.2d38242a_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Regarding IAN= A Considerations:

In a message dated 12/31/2003 4:46:50 PM Eastern Standard Time, rohan@ci= sco.com writes:


include a registration temp= late  (for example)

Namespace:
Description:
Organization Responsible for Change Control of this Namespace:
Priority values (ordered from least priority to greatest priority):
Default priority:
Preempt or Prioritize:
Document Containing Normative Description:
Section Containing Normative Description:
Additional security requirements:

Namespace: q735
Description: ITU Q.735.3 Multi-level precedence and preemption in SS7
Organization Responsible for Change Control of this Namespace: ITU-T
Priority values (ordered from least priority to greatest priority): 4,=20
3, 2, 1, 0
Default priority: 4
Preempt or Prioritize: prioritize
Document Containing Normative Description: ITU-T Q.735.3 [3]
Section Containing Normative Description: ??
Additional security requirements: none

Namespace: dsrn
Description: United States Defense Red Switched Network
Organization Responsible for Change Control of this Namespace: US=20
Department of Defense?
Priority values (ordered from least priority to greatest priority):
  routine, priority, immediate, flash, flash-override,=20
flash-override-override
Default priority: routine
Preempt or Prioritize: preempt
Document Containing Normative Description: FIPS XXXX ??  [?]
Section Containing Normative Description: ??
Additional security requirements: All implementations must follow the=20
certificate management guidelines specified in xxxx [?]



I presume that, if these namespaces are registered by inclusion in this=20= RFC, then change control continues to be under control of the IETF, by revis= ion of this RFC. (In fact, the text indicates that changes "should not" occu= r.)

Other namespaces registered later are under change control of whoever re= gisters them. (It isn't clear to me who can register new namespaces, and how= .)

The IANA considerations and registration information should only contain= what is needed for the registration. "Preempt or Prioritize" is not needed=20= as part of the registration. It is a detail to be described in other RFCs or= documents for the particular application. For example, some service might r= equire that either be done depending on other conditions. In addition, there= may be preferential treatments that would not be classified as either "pree= mpt" or "prioritize", as described in my draft on the subject. Note that Sec= tion 2 of this draft lists 4 treatments, some of which I would not classify=20= as being either "preempt" or "prioritize".

The security requirements depend on the application, so the registration= should not make normative statements about what "MUST" be done.

Further, in Section 12, I believe it is necessary that the registration=20= indicate the relative precedence levels (as shown in the above suggested tem= plate), not "may". It doesn't seem to make sense to not require specifying o= rder, but yet require a default.

I continue to believe that every namespace must have at least two priori= ty values defined. The statements in Section 3 indicate otherwise. A namespa= ce with only one value (which therefore must be the default) would be useles= s.

Mike Pierce

--part1_139.2a12df5e.2d38242a_boundary-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jan 15 14:30:48 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21713 for ; Thu, 15 Jan 2004 14:30:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhDC8-0003ZC-Hp for sip-archive@odin.ietf.org; Thu, 15 Jan 2004 14:30:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0FJUKl9013649 for sip-archive@odin.ietf.org; Thu, 15 Jan 2004 14:30:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhDBr-0003WH-FN; Thu, 15 Jan 2004 14:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhDBV-0003U8-Lh for sip@optimus.ietf.org; Thu, 15 Jan 2004 14:29:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21618 for ; Thu, 15 Jan 2004 14:29:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhDBS-0003dI-00 for sip@ietf.org; Thu, 15 Jan 2004 14:29:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhDAU-0003Yt-00 for sip@ietf.org; Thu, 15 Jan 2004 14:28:39 -0500 Received: from host205.cisp.cc ([65.196.203.205] helo=nocmailsvc005.allthesites.org) by ietf-mx with esmtp (Exim 4.12) id 1AhD9d-0003SO-00 for sip@ietf.org; Thu, 15 Jan 2004 14:27:45 -0500 Received: from afaith2 (unverified [24.175.16.103]) by copper.net (Rockliffe SMTPRA 5.3.6) with ESMTP id for ; Thu, 15 Jan 2004 19:27:13 +0000 From: "Paul Long" To: Subject: RE: [Sip] SIP DTMF Date: Thu, 15 Jan 2004 13:21:56 -0600 Message-ID: <001601c3db9c$d7cfb240$0201a8c0@afaith2> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <72001BBBF6CB124BA1C40E415914E2130300BF@blr-ec-msg04.wipro.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Sreeram, I can't find a "kpxml" draft on the IETF site or via Google--anywhere. Can you provide a link to it? Also, from my experience, the preferred method of DTMF carriage is RFC 2833, followed by in-band audio, and then various proprietary INFO-method schemes. What is the standing of RFC 2833 vis-=E0-vis = "kpxml?" Paul -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of sreeram.kanumuri@wipro.com Sent: Tuesday, January 13, 2004 9:06 PM To: xyxie@udtech.com.cn; sip@ietf.org Cc: sipping@ietf.org Subject: RE: [Sip] SIP DTMF Wendy, There was a discussion in the list some time back and it was decided that SIP-INFO method should not be used to=20 Send the DTMF info. It was proposed that it is better to you kpxml for sending DTMF tones. Please look in to the SIP-Kpxml draft for sending DTMF tomes in-midcall processing and all....=20 Regards, Sreeram =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Sreeram Kanumuri Plot No 72, Keonics Electronics City Hosur Main Road Wipro Technologies Bangalore -29 INDIA sreeram.kanumuri@wipro.com Phone: 8520408 Ex:3208 skanumury@yahoo.com ESN : www.wipro.com Mobile: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of wendy Sent: Wednesday, January 14, 2004 8:08 AM To: sip@ietf.org Cc: sipping@ietf.org Subject: [Sip] SIP DTMF Hello all,=20 Who can tell me whether there is a RFC or I-D on DTMF in SIP which is still not expired? I remember someone proposed using SIP INFO method for DTMF one or two years ago. Is the DTMF relay implemented only by RTP now? Regards, Wendy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jan 15 14:47:37 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22841 for ; Thu, 15 Jan 2004 14:47:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhDSQ-0004kz-BM for sip-archive@odin.ietf.org; Thu, 15 Jan 2004 14:47:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0FJlAtc018284 for sip-archive@odin.ietf.org; Thu, 15 Jan 2004 14:47:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhDSJ-0004jx-0j; Thu, 15 Jan 2004 14:47:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhDS7-0004j2-Am for sip@optimus.ietf.org; Thu, 15 Jan 2004 14:46:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22829 for ; Thu, 15 Jan 2004 14:46:48 -0500 (EST) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhDS4-00051X-00 for sip@ietf.org; Thu, 15 Jan 2004 14:46:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhDRH-0004yT-00 for sip@ietf.org; Thu, 15 Jan 2004 14:46:01 -0500 Received: from imo-m07.mx.aol.com ([64.12.136.162]) by ietf-mx with esmtp (Exim 4.12) id 1AhDQl-0004qJ-00 for sip@ietf.org; Thu, 15 Jan 2004 14:45:27 -0500 Received: from Mpierce1@aol.com by imo-m07.mx.aol.com (mail_out_v36_r4.12.) id c.1d2.17ec8e80 (3858); Thu, 15 Jan 2004 14:44:42 -0500 (EST) Message-ID: <1d2.17ec8e80.2d3847aa@aol.com> Date: Thu, 15 Jan 2004 14:44:42 EST Subject: Re: [Sip] re: WGLC: resource priority To: rohan@cisco.com CC: sip@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_1d2.17ec8e80.2d3847aa_boundary" X-Mailer: 6.0 for Windows XP sub 10501 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --part1_1d2.17ec8e80.2d3847aa_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 1/15/2004 12:07:39 PM Eastern Standard Time, rohan@cisco.com writes: > How will an *implementer* determine correct behavior without a > normative description or reference? This kind of reference is not > unusual in IANA registrations. > [MAP] I think the proper relationship of documents is that the implementor will be given a requirements document for equipment to be purchased. (Might be another RFC or could be a document produced by the entity that is going to purchase the equipement - like the DOD.) That document would point back to the RP-header RFC for the definition of that part of the protocol, just like it would point to lots of other documents. The RP-header document does not have to make forward references to those documents which might come later or that give all the procedural requirements. In a message dated 1/15/2004 12:07:39 PM Eastern Standard Time, rohan@cisco.com writes: > How is this any different from any of the other proxy modifications > (ex: modifying SDP) which we've decided to avoid by using session > policy? Cooperating user agents can easily find out what the policy is > and would only very rarely have to retry a call (no extra round trips > for most calls). Non-cooperating user agents have their non-policy > conforming requests rejected. > [MAP] I understand all this, but it doesn't mean that the RP-header spec should mandate that Proxies can not change or insert the header, which I believe is what you were suggesting. I feel there are legitimate cases in which it could do this. For example, if the originating user does not enter a header, the proxy uses the default, and might insert the header with the default value. Or, if the user includes a header with a priority values higher than what they are allowed, the proxy may simply lower the value to what they are allowed and forward the call. The RP-header definition should not forbid this. This is not an issue of "cooperating user agents" finding out what the policy is. The user (person) pushes a button and the UA (telephone) codes an INVITE based on what buttons they pushed. Some networks/service providers may not want to reject the call and make the user try it again. It may not be the UA but the person who controls the retry or "knows" the policy. Mike Pierce --part1_1d2.17ec8e80.2d3847aa_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message=20= dated 1/15/2004 12:07:39 PM Eastern Standard Time, rohan@cisco.com writes:


How will an *implementer* d= etermine correct behavior without a=20
normative description or reference?  This kind of reference is not=20
unusual in IANA registrations.


[MAP] I think the proper relationship of documents is that the implement= or will be given a requirements document for equipment to be purchased. (Mig= ht be another RFC or could be a document produced by the entity that is goin= g to purchase the equipement - like the DOD.) That document would point back= to the RP-header RFC for the definition of that part of the protocol, just=20= like it would point to lots of other documents.

The RP-header document does not have to make forward references to those= documents which might come later or that give all the procedural requiremen= ts.

In a message dated 1/15/2004 12:07:39 PM Eastern Standard Time, rohan@ci= sco.com writes:


How is this any different f= rom any of the other proxy modifications=20
(ex: modifying SDP) which we've decided to avoid by using session=20
policy?  Cooperating user agents can easily find out what the polic= y is=20
and would only very rarely have to retry a call (no extra round trips=20
for most calls).  Non-cooperating user agents have their non-policy= =20
conforming requests rejected.



[MAP] I understand all this, but it doesn't mean that the RP-header spec= should mandate that Proxies can not change or insert the header, which I be= lieve is what you were suggesting. I feel there are legitimate cases in whic= h it could do this. For example, if the originating user does not enter a he= ader, the proxy uses the default, and might insert the header with the defau= lt value. Or, if the user includes a header with a priority values higher th= an what they are allowed, the proxy may simply lower the value to what they=20= are allowed and forward the call. The RP-header definition should not forbid= this.

This is not an issue of "cooperating user agents" finding out what the p= olicy is. The user (person) pushes a button and the UA (telephone) codes an=20= INVITE based on what buttons they pushed. Some networks/service providers ma= y not want to reject the call and make the user try it again. It may not be=20= the UA but the person who controls the retry or "knows" the policy.

Mike Pierce
--part1_1d2.17ec8e80.2d3847aa_boundary-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jan 15 14:52:58 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23252 for ; Thu, 15 Jan 2004 14:52:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhDXa-0005RJ-Ve for sip-archive@odin.ietf.org; Thu, 15 Jan 2004 14:52:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0FJqUjr020905 for sip-archive@odin.ietf.org; Thu, 15 Jan 2004 14:52:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhDX8-0005EN-Cn; Thu, 15 Jan 2004 14:52:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhDWv-0005Cv-8d for sip@optimus.ietf.org; Thu, 15 Jan 2004 14:51:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23196 for ; Thu, 15 Jan 2004 14:51:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhDWr-0005QB-00 for sip@ietf.org; Thu, 15 Jan 2004 14:51:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhDWB-0005O7-00 for sip@ietf.org; Thu, 15 Jan 2004 14:51:04 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AhDVU-0005HN-00 for sip@ietf.org; Thu, 15 Jan 2004 14:50:20 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 15 Jan 2004 11:52:47 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0FJnlGN028195; Thu, 15 Jan 2004 11:49:47 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id APH69101; Thu, 15 Jan 2004 11:49:45 -0800 (PST) Date: Thu, 15 Jan 2004 11:51:22 -0800 Subject: Re: [Sip] re: WGLC: resource priority Content-Type: multipart/alternative; boundary=Apple-Mail-10--747681949 Mime-Version: 1.0 (Apple Message framework v553) Cc: sip@ietf.org To: Mpierce1@aol.com From: Rohan Mahy In-Reply-To: <139.2a12df5e.2d38242a@aol.com> Message-Id: <31AE20AF-4794-11D8-999C-0003938AF740@cisco.com> X-Mailer: Apple Mail (2.553) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --Apple-Mail-10--747681949 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Thursday, January 15, 2004, at 09:13 AM, Mpierce1@aol.com wrote: > I presume that, if these namespaces are registered by inclusion in > this RFC, then change control continues to be under control of the > IETF, by revision of this RFC. (In fact, the text indicates that > changes "should not" occur.) > Other namespaces registered later are under change control of whoever > registers them. (It isn't clear to me who can register new namespaces, > and how.) Please do not confuse the change control of the *registration* with the change control of the *normative behavior*. Only the change control of the registration is under the control of the IETF. Obviously if you change the normative behavior in a separate document, you need to change the registration to point at the changes behavior. Recall that the IANA registration serves two purposes: 1) to prevent namespace conflicts, and 2) to allows implementors to find the documents relevant to any namespaces which interest them. > The IANA considerations and registration information should only > contain what is needed for the registration. "Preempt or Prioritize" > is not needed as part of the registration. It is a detail to be > described in other RFCs or documents for the particular application. > For example, some service might require that either be done depending > on other conditions. In addition, there may be preferential treatments > that would not be classified as either "preempt" or "prioritize", as > described in my draft on the subject. Note that Section 2 of this > draft lists 4 treatments, some of which I would not classify as being > either "preempt" or "prioritize". Can you provide an existence proof of a separate type of treatment? > The security requirements depend on the application, so the > registration should not make normative statements about what "MUST" be > done. That should be purely at the discretion of the registrar of each namespace. If additional security requirements are warranted then they can certainly be included. If there are no additional requirements or requirements are deferred to other documents then the registration should indicate that. > Further, in Section 12, I believe it is necessary that the > registration indicate the relative precedence levels (as shown in the > above suggested template), not "may". It doesn't seem to make sense to > not require specifying order, but yet require a default. > I continue to believe that every namespace must have at least two > priority values defined. The statements in Section 3 indicate > otherwise. A namespace with only one value (which therefore must be > the default) would be useless. agreed to both. thanks, -rohan --Apple-Mail-10--747681949 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thursday, January 15, 2004, at 09:13 AM, Mpierce1@aol.com wrote: Arial0000,0000,0000I presume that, if these namespaces are registered by inclusion in this RFC, then change control continues to be under control of the IETF, by revision of this RFC. (In fact, the text indicates that changes "should not" occur.) Other namespaces registered later are under change control of whoever registers them. (It isn't clear to me who can register new namespaces, and how.) Please do not confuse the change control of the *registration* with the change control of the *normative behavior*. Only the change control of the registration is under the control of the IETF. Obviously if you change the normative behavior in a separate document, you need to change the registration to point at the changes behavior. Recall that the IANA registration serves two purposes: 1) to prevent namespace conflicts, and 2) to allows implementors to find the documents relevant to any namespaces which interest them. Arial0000,0000,0000The IANA considerations and registration information should only contain what is needed for the registration. "Preempt or Prioritize" is not needed as part of the registration. It is a detail to be described in other RFCs or documents for the particular application. For example, some service might require that either be done depending on other conditions. In addition, there may be preferential treatments that would not be classified as either "preempt" or "prioritize", as described in my draft on the subject. Note that Section 2 of this draft lists 4 treatments, some of which I would not classify as being either "preempt" or "prioritize". Can you provide an existence proof of a separate type of treatment? Arial0000,0000,0000The security requirements depend on the application, so the registration should not make normative statements about what "MUST" be done. That should be purely at the discretion of the registrar of each namespace. If additional security requirements are warranted then they can certainly be included. If there are no additional requirements or requirements are deferred to other documents then the registration should indicate that. Arial0000,0000,0000Further, in Section 12, I believe it is necessary that the registration indicate the relative precedence levels (as shown in the above suggested template), not "may". It doesn't seem to make sense to not require specifying order, but yet require a default. I continue to believe that every namespace must have at least two priority values defined. The statements in Section 3 indicate otherwise. A namespace with only one value (which therefore must be the default) would be useless. agreed to both. thanks, -rohan --Apple-Mail-10--747681949-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jan 15 14:58:36 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23851 for ; Thu, 15 Jan 2004 14:58:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhDd2-00062o-HM for sip-archive@odin.ietf.org; Thu, 15 Jan 2004 14:58:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0FJw8g9023207 for sip-archive@odin.ietf.org; Thu, 15 Jan 2004 14:58:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhDcx-00061B-QR; Thu, 15 Jan 2004 14:58:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhDch-0005yy-Up for sip@optimus.ietf.org; Thu, 15 Jan 2004 14:57:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23819 for ; Thu, 15 Jan 2004 14:57:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhDcf-000602-00 for sip@ietf.org; Thu, 15 Jan 2004 14:57:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhDbo-0005vi-00 for sip@ietf.org; Thu, 15 Jan 2004 14:56:53 -0500 Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx with esmtp (Exim 4.12) id 1AhDb2-0005pJ-00 for sip@ietf.org; Thu, 15 Jan 2004 14:56:04 -0500 Received: from sukothai.pingtel.com (sukothai.pingtel.com [10.1.1.59]) by mail.pingtel.com (8.11.6/8.11.6) with ESMTP id i0FJu3J07517; Thu, 15 Jan 2004 14:56:04 -0500 To: Paul Kyzivat Cc: ksrini@motorola.com, sip@ietf.org Subject: Re: [Sip] Registering Multiple 'Contacts' References: <4002E0B9.8030203@cisco.com> Organization: Pingtel Corp. http://www.pingtel.com/ From: Scott Lawrence Date: Thu, 15 Jan 2004 14:56:03 -0500 In-Reply-To: <4002E0B9.8030203@cisco.com> (Paul Kyzivat's message of "Mon, 12 Jan 2004 13:00:25 -0500") Message-ID: User-Agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Srinivasan Krishnamoorthy wrote: >> Section 10.2.4 of RFC3261 'Refreshing Bindings' says: >> "The UA then issues a REGISTER request for each of its bindings >> before the expiration interval has elapsed. It MAY combine several >> updates into one REGISTER request." >> The above seems to indicate that the UAC may send: (forgive the >> Syntax) >> REGISTER To: user@operator.net >> Contact: sip:user1@10.0.0.1;expires=3600 >> 200 OK >> REGISTER To: user@operator.net >> Contact: sip:user1@192.0.0.1;expires=3600 >> 200 OK >> This, according to RFC3261, will register both Contact1 and Contact2 >> for user@operator.net. (The server will then use the q parameter >> of the contact for priority among contacts) Paul Kyzivat writes: > Yes. My reading is that the results should differ depending on the Call-Id used in those two REGISTER requests: - If they have different Call-Id values, then the server should register both contacts. - If they have the same Call-Id value, then the second REGISTER should cause the server to replace the first contact with the second, so that there would be only If correct, this adds an additional alternative for the UA - if it can remember its Call-Id values across contact changes, it can make sure that old registrations are replaced even before they expire. -- Scott Lawrence Pingtel Corp. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jan 15 16:24:22 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29302 for ; Thu, 15 Jan 2004 16:24:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhEy1-0001mJ-UO for sip-archive@odin.ietf.org; Thu, 15 Jan 2004 16:23:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0FLNr4h006832 for sip-archive@odin.ietf.org; Thu, 15 Jan 2004 16:23:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhDqT-0007R0-5s; Thu, 15 Jan 2004 15:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhDpY-0007P8-I2 for sip@optimus.ietf.org; Thu, 15 Jan 2004 15:11:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25450 for ; Thu, 15 Jan 2004 15:11:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhDpV-0007Je-00 for sip@ietf.org; Thu, 15 Jan 2004 15:11:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhDoY-0007Dv-00 for sip@ietf.org; Thu, 15 Jan 2004 15:10:04 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AhDnd-00071s-00 for sip@ietf.org; Thu, 15 Jan 2004 15:09:05 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 15 Jan 2004 12:10:55 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i0FK8XVM003049; Thu, 15 Jan 2004 12:08:33 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id APH71307; Thu, 15 Jan 2004 12:08:27 -0800 (PST) Date: Thu, 15 Jan 2004 12:10:07 -0800 Subject: Re: [Sip] re: WGLC: resource priority Content-Type: multipart/alternative; boundary=Apple-Mail-14--746556426 Mime-Version: 1.0 (Apple Message framework v553) Cc: sip@ietf.org To: Mpierce1@aol.com From: Rohan Mahy In-Reply-To: <1d2.17ec8e80.2d3847aa@aol.com> Message-Id: X-Mailer: Apple Mail (2.553) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --Apple-Mail-14--746556426 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On Thursday, January 15, 2004, at 11:44 AM, Mpierce1@aol.com wrote: > In a message dated 1/15/2004 12:07:39 PM Eastern Standard Time,=20 > rohan@cisco.com writes: > > > How will an *implementer* determine correct behavior without a > normative description or reference? =A0This kind of reference is not > unusual in IANA registrations. > > [MAP] I think the proper relationship of documents is that the=20 > implementor will be given a requirements document for equipment to be=20= > purchased. (Might be another RFC or could be a document produced by=20 > the entity that is going to purchase the equipement - like the DOD.)=20= > That document would point back to the RP-header RFC for the definition=20= > of that part of the protocol, just like it would point to lots of=20 > other documents. > > The RP-header document does not have to make forward references to=20 > those documents which might come later or that give all the procedural=20= > requirements. I believe that the IANA *registration* does need to have such a forward=20= reference and that the IESG will tend to agree with me. > In a message dated 1/15/2004 12:07:39 PM Eastern Standard Time,=20 > rohan@cisco.com writes: > > How is this any different from any of the other proxy modifications > (ex: modifying SDP) which we've decided to avoid by using session > policy? =A0Cooperating user agents can easily find out what the policy = is > and would only very rarely have to retry a call (no extra round trips > for most calls). =A0Non-cooperating user agents have their non-policy > conforming requests rejected. > > [MAP] I understand all this, but it doesn't mean that the RP-header=20 > spec should mandate that Proxies can not change or insert the header,=20= > which I believe is what you were suggesting. I feel there are=20 > legitimate cases in which it could do this. For example, if the=20 > originating user does not enter a header, the proxy uses the default,=20= > and might insert the header with the default value. Or, if the user=20 > includes a header with a priority values higher than what they are=20 > allowed, the proxy may simply lower the value to what they are allowed=20= > and forward the call. The RP-header definition should not forbid this. > > This is not an issue of "cooperating user agents" finding out what the=20= > policy is. The user (person) pushes a button and the UA (telephone)=20 > codes an INVITE based on what buttons they pushed. Some=20 > networks/service providers may not want to reject the call and make=20 > the user try it again. It may not be the UA but the person who=20 > controls the retry or "knows" the policy. The UA should know the policy. There is no technical reason it can't=20 know or collect the policy and then use the appropriate policy. That's=20= what the session policy mechanism is for. However, there are a number=20 of technical problems related to security we get when proxies start to=20= insert or modify RP. thanks, -rohan= --Apple-Mail-14--746556426 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thursday, January 15, 2004, at 11:44 AM, Mpierce1@aol.com wrote: ArialIn a message dated 1/15/2004 12:07:39 PM Eastern Standard Time, rohan@cisco.com writes: How will an *implementer* determine correct behavior without a normative description or reference? =A0This kind of reference is not unusual in IANA registrations. = Arial0000,0000,0000[MAP] I think the proper relationship of documents is that the implementor will be given a requirements document for equipment to be purchased. (Might be another RFC or could be a document produced by the entity that is going to purchase the equipement - like the DOD.) That document would point back to the RP-header RFC for the definition of that part of the protocol, just like it would point to lots of other documents. The RP-header document does not have to make forward references to those documents which might come later or that give all the procedural requirements. I believe that the IANA *registration* does need to have such a forward reference and that the IESG will tend to agree with me. = Arial0000,0000,0000In a message dated 1/15/2004 12:07:39 PM Eastern Standard Time, rohan@cisco.com writes: How is this any different from any of the other proxy modifications (ex: modifying SDP) which we've decided to avoid by using session policy? =A0Cooperating user agents can easily find out what the policy = is and would only very rarely have to retry a call (no extra round trips for most calls). =A0Non-cooperating user agents have their non-policy conforming requests rejected. [MAP] I understand all this, but it doesn't mean that the RP-header spec should mandate that Proxies can not change or insert the header, which I believe is what you were suggesting. I feel there are legitimate cases in which it could do this. For example, if the originating user does not enter a header, the proxy uses the default, and might insert the header with the default value. Or, if the user includes a header with a priority values higher than what they are allowed, the proxy may simply lower the value to what they are allowed and forward the call. The RP-header definition should not forbid this. This is not an issue of "cooperating user agents" finding out what the policy is. The user (person) pushes a button and the UA (telephone) codes an INVITE based on what buttons they pushed. Some networks/service providers may not want to reject the call and make the user try it again. It may not be the UA but the person who controls the retry or "knows" the policy. The UA should know the policy. There is no technical reason it can't know or collect the policy and then use the appropriate policy. That's what the session policy mechanism is for. However, there are a number of technical problems related to security we get when proxies start to insert or modify RP. thanks, -rohan= --Apple-Mail-14--746556426-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jan 15 16:24:39 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29324 for ; Thu, 15 Jan 2004 16:24:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhEyJ-0001sL-6P for sip-archive@odin.ietf.org; Thu, 15 Jan 2004 16:24:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0FLOB1g007172 for sip-archive@odin.ietf.org; Thu, 15 Jan 2004 16:24:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhEyI-0001r8-ER; Thu, 15 Jan 2004 16:24:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhDvy-0007lI-B0 for sip@optimus.ietf.org; Thu, 15 Jan 2004 15:17:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26219 for ; Thu, 15 Jan 2004 15:17:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhDvx-0007jd-00 for sip@ietf.org; Thu, 15 Jan 2004 15:17:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhDv5-0007i0-00 for sip@ietf.org; Thu, 15 Jan 2004 15:16:47 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1AhDuN-0007gH-00 for sip@ietf.org; Thu, 15 Jan 2004 15:16:03 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i0FKG0Ja000903; Thu, 15 Jan 2004 13:16:00 -0700 (MST) Received: from bulb ([10.14.25.99]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id i0FKFwEb028140; Thu, 15 Jan 2004 14:15:58 -0600 Date: Thu, 15 Jan 2004 15:13:55 -0500 (EST) From: Srinivasan Krishnamoorthy X-Sender: ksrini@bulb.corp.mot.com Reply-To: ksrini@motorola.com To: sip@ietf.org cc: Paul Kyzivat Subject: Re: [Sip] Registering Multiple 'Contacts' In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , >> How will the Server prevent against mis-behaved clients in this case? >The expiration time bounds the problem, but doesn't eliminate it. >Assume the UAC power cycles, forgets its old address, gets a new one and registers it. It will then presumably continue to refresh the new address, but not the old one. So the old registration will continue to be active until it expires. During that time requests will probably be forked to it and the new address, but the ones to the old address will fail. > >Paul Another case I could think of is a DHCP environment - where a mobile-ua gets different ipaddresses on every power-cycle. In this case we may have to make sure the DHCP lease timers are longer than registration duration in the network - or else we could be terminating a call to an old-IP - that has possibly been granted to another UA that registered in the interim??? it looks like nothing can be done at the server to 'eliminate' the problem. Thanks -Srini _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jan 15 16:25:02 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29444 for ; Thu, 15 Jan 2004 16:25:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhEyg-00028Q-8v for sip-archive@odin.ietf.org; Thu, 15 Jan 2004 16:24:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0FLOYHb008162 for sip-archive@odin.ietf.org; Thu, 15 Jan 2004 16:24:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhEye-00026f-QV; Thu, 15 Jan 2004 16:24:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhEks-0001N8-MO for sip@optimus.ietf.org; Thu, 15 Jan 2004 16:10:18 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28551; Thu, 15 Jan 2004 16:10:16 -0500 (EST) Message-Id: <200401152110.QAA28551@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 15 Jan 2004 16:10:15 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-session-timer-13.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Session Timers in the Session Initiation Protocol (SIP) Author(s) : S. Donovan, J. Rosenberg Filename : draft-ietf-sip-session-timer-13.txt Pages : 36 Date : 2004-1-15 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 if 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-session-timer-13.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-session-timer-13.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-session-timer-13.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: <2004-1-15152611.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-session-timer-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-session-timer-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-15152611.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jan 15 17:13:49 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04785 for ; Thu, 15 Jan 2004 17:13:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhFii-0006O7-Q3 for sip-archive@odin.ietf.org; Thu, 15 Jan 2004 17:12:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0FMC8KY024546 for sip-archive@odin.ietf.org; Thu, 15 Jan 2004 17:12:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhFib-0006N8-VB; Thu, 15 Jan 2004 17:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhFiQ-0006Mj-7n for sip@optimus.ietf.org; Thu, 15 Jan 2004 17:11:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04724 for ; Thu, 15 Jan 2004 17:11:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhFiN-0000lv-00 for sip@ietf.org; Thu, 15 Jan 2004 17:11:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhFhO-0000jb-00 for sip@ietf.org; Thu, 15 Jan 2004 17:10:46 -0500 Received: from phobos.simply.net ([81.3.64.11]) by ietf-mx with smtp (Exim 4.12) id 1AhFgo-0000gT-00 for sip@ietf.org; Thu, 15 Jan 2004 17:10:10 -0500 Received: (qmail 13205 invoked from network); 15 Jan 2004 22:09:39 -0000 Received: from 200-232-28.dial.terra.cl (HELO albers) (200.28.232.200) by phobos.simply.net with SMTP; 15 Jan 2004 22:09:39 -0000 From: "Ken Carlberg" To: "'Rohan Mahy'" , Cc: Subject: RE: [Sip] re: WGLC: resource priority Date: Thu, 15 Jan 2004 17:09:32 -0500 Message-ID: <000501c3dbb4$430e6940$c8e81cc8@albers> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <31AE20AF-4794-11D8-999C-0003938AF740@cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit >> That should be purely at the discretion of the registrar of each >> namespace. If additional security requirements are warranted then >> they can certainly be included. If there are no additional >> requirements or requirements are deferred to other documents then >> the registration should indicate that. > > Further, in Section 12, I believe it is necessary that the registration > indicate the relative precedence levels (as shown in the above suggested > template), not "may". It doesn't seem to make sense to not require > specifying order, but yet require a default. > I continue to believe that every namespace must have at least two > priority values defined. The statements in Section 3 indicate otherwise. > A namespace with only one value (which therefore must be the default) > would be useless. > > agreed to both. I disagree on the latter part that every namespace must have two "priority" values. If one has a binary "on/off" NameSpace Value, and the "off" means that the message is to be treated the same as if the R-P never existed, then I don't see why an additional Value must exist. Its counter to the age old practice of be conservative in what you send. An example of such a binary condition is if I wanted to have a namespace that mapped to the binary NS/EP codepoint of T1.631. -ken _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jan 15 17:25:44 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05529 for ; Thu, 15 Jan 2004 17:25:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhFvR-0007OL-G5 for sip-archive@odin.ietf.org; Thu, 15 Jan 2004 17:25:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0FMPHYV028351 for sip-archive@odin.ietf.org; Thu, 15 Jan 2004 17:25:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhFvE-0007ML-SR; Thu, 15 Jan 2004 17:25:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhFuz-0007LO-IG for sip@optimus.ietf.org; Thu, 15 Jan 2004 17:24:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05514 for ; Thu, 15 Jan 2004 17:24:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhFux-0001l8-00 for sip@ietf.org; Thu, 15 Jan 2004 17:24:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhFu8-0001jc-00 for sip@ietf.org; Thu, 15 Jan 2004 17:23:56 -0500 Received: from amer-mta02.csc.com ([20.137.2.248]) by ietf-mx with esmtp (Exim 4.12) id 1AhFtq-0001gt-00 for sip@ietf.org; Thu, 15 Jan 2004 17:23:38 -0500 Received: from amer-mta02.csc.com (localhost [127.0.0.1]) by amer-mta02.csc.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i0FMOgXC004697 for ; Thu, 15 Jan 2004 17:24:42 -0500 (EST) Received: from csc.com (va-fch32.csc.com [20.6.39.233]) by amer-mta02.csc.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i0FMOfXC004684 for ; Thu, 15 Jan 2004 17:24:41 -0500 (EST) Subject: Re: [Sip] re: WGLC: resource priority To: Janet P Gunn Cc: Mpierce1@aol.com, rohan@cisco.com, sip@ietf.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Janet P Gunn Date: Thu, 15 Jan 2004 17:22:18 -0500 X-MIMETrack: Serialize by Router on VA-FCH32/SRV/CSC(Release 6.0.3|September 26, 2003) at 01/15/2004 05:21:58 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Janet P Gunn /FED/CSC To: cc: rohan@cisco.com, sip@ietf.org 01/15/2004 12:16 Subject: Re: [Sip] re: WGLC: resource priority(Document link: Janet P Gunn) PM I support Mike on this one. The Resource Priority Header is the "protocol", not the "policy". What policy will be evoked in a particular Administrative Domain, by a particular RPH namespace:value will be the subject of an SLA between relevant parties. Restrictions on the extent of the policy (for instance that it not be the instrument for DoS attacks) are already in the document. Janet ---------------------------------------------------------------------------------------- This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ---------------------------------------------------------------------------------------- To: , cc: 01/14/2004 09:25 Subject: Re: [Sip] re: WGLC: resource priority PM In a message dated 12/31/2003 4:46:50 PM Eastern Standard Time, rohan@cisco.com writes: 1. There is no normative description of the behavior of SIP devices which receive a particular priority value. Some specifications needs to either specify detailed behavior for specific priority values, or the detailed semantics of those values. I think this belongs in the IANA registration of each namespace, but those references are currently very thin. I made some specific comments to this end in the appropriate sections. [MAP] I believe this document should be limited to the definition of the data (header) and leave detailed behaviour and procedures to other documents that define specific services/capabilities which use it. It should not specify detailed behaviour for specific priority values. The references to IANA registration are thin because they only describe what IANA needs to deal with - assigning an ordered set of names for the priority levels for each "namespace". 3. Finally, the document shows that proxies can modify, insert, and delete the RP header. I don't think this is a good idea. Where cooperating UAs and proxies need to agree on an RP value, I believe the session policy mechanism can be used. A proxy can reject the message for policy reasons (use a lower/higher/specific resource-value) and the UA can retry the request with these new values. [MAP] While it may not be normal for a proxy to modify or delete an RP header, there may be services defined using this header that are based on proxies doing exactly that. For example, an originator tries to place a call using a high priority header. The proxy authenticates, determines tha the user is only authorized a lower priority level, automatically lowers it by changing the RP header, and forwards the call on its way, without requiring the UA to retry the call. Other documents would describe various operations, possibly including some cases in which a proxy can not modify the RP header. Mike Pierce _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jan 15 19:55:40 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11234 for ; Thu, 15 Jan 2004 19:55:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhIGU-00075c-4d for sip-archive@odin.ietf.org; Thu, 15 Jan 2004 19:55:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0G0tAio027251 for sip-archive@odin.ietf.org; Thu, 15 Jan 2004 19:55:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhIGO-00074U-3i; Thu, 15 Jan 2004 19:55:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhIGC-00071f-37 for sip@optimus.ietf.org; Thu, 15 Jan 2004 19:54:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11192 for ; Thu, 15 Jan 2004 19:54:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhIGA-0000iU-00 for sip@ietf.org; Thu, 15 Jan 2004 19:54:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhIFH-0000eI-00 for sip@ietf.org; Thu, 15 Jan 2004 19:53:56 -0500 Received: from usjk1002.kddi.com ([211.4.169.18]) by ietf-mx with esmtp (Exim 4.12) id 1AhIEL-0000Xl-00 for sip@ietf.org; Thu, 15 Jan 2004 19:52:58 -0500 Received: from usjk1006.kddi.com (usjk1006 [10.96.2.3]) by usjk1002.kddi.com (3.7W-030228132558) with ESMTP id JAA03917; Fri, 16 Jan 2004 09:51:55 +0900 (JST) Received: from usjk1010.kddi.com (localhost [127.0.0.1]) by usjk1006.kddi.com (3.7W-040107142500) with ESMTP id JAA08795; Fri, 16 Jan 2004 09:51:55 +0900 (JST) Received: from KDDI-0003PC0281.kddi.com ([10.100.94.32]) by usjk1010.kddi.com (InterMail vM.5.01.02.00 201-253-116-121-20001201) with ESMTP id <20040116005152.QCSF13285.usjk1010.kddi.com@KDDI-0003PC0281.kddi.com>; Fri, 16 Jan 2004 09:51:52 +0900 To: slawrence@pingtel.com, pkyzivat@cisco.com Cc: ksrini@motorola.com, sip@ietf.org Subject: Re: [Sip] Registering Multiple 'Contacts' From: Takuya Sawada References: <4002E0B9.8030203@cisco.com> In-Reply-To: Message-Id: <200401160951.HGC28341.-EBBVTXUB@kddi.com> X-Mailer: Winbiff [Version 2.42 PL2] X-Accept-Language: ja,en Date: Fri, 16 Jan 2004 09:51:51 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi, > > Srinivasan Krishnamoorthy wrote: > > >> Section 10.2.4 of RFC3261 'Refreshing Bindings' says: > >> "The UA then issues a REGISTER request for each of its bindings > >> before the expiration interval has elapsed. It MAY combine several > >> updates into one REGISTER request." > >> The above seems to indicate that the UAC may send: (forgive the > >> Syntax) > >> REGISTER To: user@operator.net > >> Contact: sip:user1@10.0.0.1;expires=3600 > >> 200 OK > >> REGISTER To: user@operator.net > >> Contact: sip:user1@192.0.0.1;expires=3600 > >> 200 OK > >> This, according to RFC3261, will register both Contact1 and Contact2 > >> for user@operator.net. (The server will then use the q parameter > >> of the contact for priority among contacts) > > Paul Kyzivat writes: > > > Yes. > > My reading is that the results should differ depending on the Call-Id > used in those two REGISTER requests: > > - If they have different Call-Id values, then the server should > register both contacts. > > - If they have the same Call-Id value, then the second REGISTER > should cause the server to replace the first contact with the > second, so that there would be only > In my reading of RFC 3261 section 10.3 step 7, Contact URI will be added to the list irrelevant to Call-ID value if its value is new to the list. > If correct, this adds an additional alternative for the UA - if it can > remember its Call-Id values across contact changes, it can make sure > that old registrations are replaced even before they expire. > If it can remember any value in the previous power-cycle, it may remember Contact URI and then can remove it with expires=0 explicitly. Note that assumeing it uses the same "fixed" Call-ID across power-cycle, it must remember "dynamic" CSeq value in old power-cycle. Regards, Takuya > -- > Scott Lawrence > Pingtel Corp. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -------- Takuya Sawada KDDI Corporation (KDDI) Garden Air Tower, 3-10-10 Iidabashi Chiyoda-ku Tokyo 102-8460, Japan Tel: +81-3-6678-2997 Fax: +81-3-6678-0285 tu-sawada@kddi.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jan 15 20:06:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11660 for ; Thu, 15 Jan 2004 20:06:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhIR3-0007ej-Ql for sip-archive@odin.ietf.org; Thu, 15 Jan 2004 20:06:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0G165lC029423 for sip-archive@odin.ietf.org; Thu, 15 Jan 2004 20:06:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhIR0-0007cc-6q; Thu, 15 Jan 2004 20:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhIQm-0007bD-Jk for sip@optimus.ietf.org; Thu, 15 Jan 2004 20:05:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11634 for ; Thu, 15 Jan 2004 20:05:47 -0500 (EST) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhIQk-0001Kw-00 for sip@ietf.org; Thu, 15 Jan 2004 20:05:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhIPm-0001Hc-00 for sip@ietf.org; Thu, 15 Jan 2004 20:04:47 -0500 Received: from imo-r01.mx.aol.com ([152.163.225.97]) by ietf-mx with esmtp (Exim 4.12) id 1AhIOr-0001Do-00 for sip@ietf.org; Thu, 15 Jan 2004 20:03:49 -0500 Received: from Mpierce1@aol.com by imo-r01.mx.aol.com (mail_out_v36_r4.12.) id v.1d4.1891a8a9 (4184); Thu, 15 Jan 2004 20:03:08 -0500 (EST) Message-ID: <1d4.1891a8a9.2d38924c@aol.com> Date: Thu, 15 Jan 2004 20:03:08 EST Subject: Re: [Sip] re: WGLC: resource priority (3) To: carlberg@g11.org.uk, rohan@cisco.com CC: sip@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_1d4.1891a8a9.2d38924c_boundary" X-Mailer: 6.0 for Windows XP sub 10501 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --part1_1d4.1891a8a9.2d38924c_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 1/15/2004 5:12:56 PM Eastern Standard Time, carlberg@g11.org.uk writes: > > I disagree on the latter part that every namespace must have two > "priority" values. If one has a binary "on/off" NameSpace Value, and > the "off" means that the message is to be treated the same as if the R-P > never existed, then I don't see why an additional Value must exist. Its > counter to the age old practice of be conservative in what you send. > > An example of such a binary condition is if I wanted to have a namespace > that mapped to the binary NS/EP codepoint of T1.631. > > [MAP] You're going to have to explain how that could work, considering that the draft states: Every namespace must have a default level. The default is assumed in the absence of a priority level (in a message). That means that, if there is only one priority value in the namespace (such as "on") registered with IANA, it must be the default, and any INVITE that does not contain an RP-header is treated as if it contained the default value ("on"). How would it be possible to signal the "off" value? If one wants a "binary" on/off, then why not just define two values: ON and OFF with OFF as the default? Then either can be signalled, and the absence of the RP-header means OFF. I think the age old practice of being conservative in what you send applies to what we say to each other, not what signaling is sent by telecommunications devices :>} Explain how one would signal the NS/EP codepoint case with only one value (which is the default). Mike Pierce --part1_1d4.1891a8a9.2d38924c_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message=20= dated 1/15/2004 5:12:56 PM Eastern Standard Time, carlberg@g11.org.uk writes= :



I disagree on the latter part that every namespace must have two
"priority" values.  If one has a binary "on/off" NameSpace Value, a= nd
the "off" means that the message is to be treated the same as if the R-P
never existed, then I don't see why an additional Value must exist. &nbs= p;Its
counter to the age old practice of be conservative in what you send.

An example of such a binary condition is if I wanted to have a namespace
that mapped to the binary NS/EP codepoint of T1.631.




[MAP] You're going to have to explain how that could work, considering t= hat the draft states:

Every namespace must have a default level.
The default is assumed in the absence of a priority level (in a message)= .

That means that, if there is only one priority value in the namespace (s= uch as "on") registered with IANA, it must be the default, and any INVITE th= at does not contain an RP-header is treated as if it contained the default v= alue ("on"). How would it be possible to signal the "off" value?

If one wants a "binary" on/off, then why not just define two values: ON=20= and OFF with OFF as the default? Then either can be signalled, and the absen= ce of the RP-header means OFF.

I think the age old practice of being conservative in what you send appl= ies to what we say to each other, not what signaling is sent by telecommunic= ations devices :>}

Explain how one would signal the NS/EP codepoint case with only one valu= e (which is the default).

Mike Pierce


--part1_1d4.1891a8a9.2d38924c_boundary-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jan 15 20:18:37 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11921 for ; Thu, 15 Jan 2004 20:18:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhIci-00006l-JH for sip-archive@odin.ietf.org; Thu, 15 Jan 2004 20:18:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0G1I853000353 for sip-archive@odin.ietf.org; Thu, 15 Jan 2004 20:18:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhIcb-0008WN-Ey; Thu, 15 Jan 2004 20:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhIcT-0008W1-0z for sip@optimus.ietf.org; Thu, 15 Jan 2004 20:17:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11914 for ; Thu, 15 Jan 2004 20:17:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhIcQ-0001l9-00 for sip@ietf.org; Thu, 15 Jan 2004 20:17:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhIbS-0001jZ-00 for sip@ietf.org; Thu, 15 Jan 2004 20:16:51 -0500 Received: from usjk1002.kddi.com ([211.4.169.18]) by ietf-mx with esmtp (Exim 4.12) id 1AhIae-0001gv-00 for sip@ietf.org; Thu, 15 Jan 2004 20:16:00 -0500 Received: from usjk1006.kddi.com (usjk1006 [10.96.2.3]) by usjk1002.kddi.com (3.7W-030228132558) with ESMTP id KAA11322; Fri, 16 Jan 2004 10:15:00 +0900 (JST) Received: from usjk1009.kddi.com (localhost [127.0.0.1]) by usjk1006.kddi.com (3.7W-040107142500) with ESMTP id KAA19162; Fri, 16 Jan 2004 10:15:01 +0900 (JST) Received: from KDDI-0003PC0281.kddi.com ([10.100.94.32]) by usjk1009.kddi.com (InterMail vM.5.01.02.00 201-253-116-121-20001201) with ESMTP id <20040116011457.SZCR5356.usjk1009.kddi.com@KDDI-0003PC0281.kddi.com>; Fri, 16 Jan 2004 10:14:57 +0900 To: ksrini@motorola.com, sip@ietf.org Cc: pkyzivat@cisco.com Subject: Re: [Sip] Registering Multiple 'Contacts' From: Takuya Sawada References: In-Reply-To: Message-Id: <200401161014.DJH59500.T-BEVUBBX@kddi.com> X-Mailer: Winbiff [Version 2.42 PL2] X-Accept-Language: ja,en Date: Fri, 16 Jan 2004 10:14:57 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi, > > >> How will the Server prevent against mis-behaved clients in this case? > > >The expiration time bounds the problem, but doesn't eliminate it. > >Assume the UAC power cycles, forgets its old address, gets a new one and registers it. It will then presumably continue to refresh the new address, but not the old one. So the old registration will continue to be active until it expires. During that time requests will probably be forked to it and the new address, but the ones to the old address will fail. > > > >Paul > > Another case I could think of is a DHCP environment - where a mobile-ua gets > different ipaddresses on every power-cycle. > > In this case we may have to make sure the DHCP lease timers are longer than > registration duration in the network - or else we could be terminating > a call to an old-IP - that has possibly been granted to another UA that > registered in the interim??? > I think that SIP UA which use dynamic IP address SHOULD obey the behaviour described above. Keep DHCP lease timer > SIP registration timer. (any timer used in app level) > it looks like nothing can be done at the server to 'eliminate' the problem. > I agree. As a SIP UAS, it can reject the request which has other Request-URI other than its registered Contact URI with 404, or just ignore such a request. This can eliminate or reduce the possibility of wrong call termination to the UAS. Here I assume that user part of Contact URI is unique enough to avoid accidental collision. Regards, Takuya > Thanks > -Srini > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -------- Takuya Sawada KDDI Corporation (KDDI) Garden Air Tower, 3-10-10 Iidabashi Chiyoda-ku Tokyo 102-8460, Japan Tel: +81-3-6678-2997 Fax: +81-3-6678-0285 tu-sawada@kddi.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jan 15 20:48:43 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12916 for ; Thu, 15 Jan 2004 20:48:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhJ5q-0001dj-Kd for sip-archive@odin.ietf.org; Thu, 15 Jan 2004 20:48:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0G1mEB1006241 for sip-archive@odin.ietf.org; Thu, 15 Jan 2004 20:48:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhJ5e-0001bv-43; Thu, 15 Jan 2004 20:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhJ5S-0001bc-DZ for sip@optimus.ietf.org; Thu, 15 Jan 2004 20:47:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12912 for ; Thu, 15 Jan 2004 20:47:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhJ5Q-00037c-00 for sip@ietf.org; Thu, 15 Jan 2004 20:47:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhJ4R-00035f-00 for sip@ietf.org; Thu, 15 Jan 2004 20:46:48 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AhJ3T-000326-00 for sip@ietf.org; Thu, 15 Jan 2004 20:45:47 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 15 Jan 2004 17:47:40 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id i0G1jFNp018810; Thu, 15 Jan 2004 17:45:16 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id API13580; Thu, 15 Jan 2004 17:45:14 -0800 (PST) Date: Thu, 15 Jan 2004 17:46:52 -0800 Subject: Re: [Sip] re: WGLC: resource priority Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Cc: , To: "Ken Carlberg" From: Rohan Mahy In-Reply-To: <000501c3dbb4$430e6940$c8e81cc8@albers> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.553) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ken, The binary namespace you described has TWO values. (ON and OFF) thanks, -rohan On Thursday, January 15, 2004, at 02:09 PM, Ken Carlberg wrote: > >>> That should be purely at the discretion of the registrar of each >>> namespace. If additional security requirements are warranted then >>> they can certainly be included. If there are no additional >>> requirements or requirements are deferred to other documents then >>> the registration should indicate that. >> >> Further, in Section 12, I believe it is necessary that the > registration >> indicate the relative precedence levels (as shown in the above > suggested >> template), not "may". It doesn't seem to make sense to not require >> specifying order, but yet require a default. >> I continue to believe that every namespace must have at least two >> priority values defined. The statements in Section 3 indicate > otherwise. >> A namespace with only one value (which therefore must be the default) >> would be useless. >> >> agreed to both. > > I disagree on the latter part that every namespace must have two > "priority" values. If one has a binary "on/off" NameSpace Value, and > the "off" means that the message is to be treated the same as if the > R-P > never existed, then I don't see why an additional Value must exist. > Its > counter to the age old practice of be conservative in what you send. > > An example of such a binary condition is if I wanted to have a > namespace > that mapped to the binary NS/EP codepoint of T1.631. > > -ken > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Jan 16 02:31:21 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04018 for ; Fri, 16 Jan 2004 02:31:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhORR-0001vW-8s for sip-archive@odin.ietf.org; Fri, 16 Jan 2004 02:30:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0G7Urch007405 for sip-archive@odin.ietf.org; Fri, 16 Jan 2004 02:30:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhOPf-0001eS-Cs; Fri, 16 Jan 2004 02:29:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhB5o-0004HQ-JI for sip@optimus.ietf.org; Thu, 15 Jan 2004 12:15:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15483 for ; Thu, 15 Jan 2004 12:15:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhB5m-0004Jo-00 for sip@ietf.org; Thu, 15 Jan 2004 12:15:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhB4x-0004Hk-00 for sip@ietf.org; Thu, 15 Jan 2004 12:14:48 -0500 Received: from amer-mta02.csc.com ([20.137.2.248]) by ietf-mx with esmtp (Exim 4.12) id 1AhB4D-0004Ej-00 for sip@ietf.org; Thu, 15 Jan 2004 12:14:01 -0500 Received: from amer-mta02.csc.com (localhost [127.0.0.1]) by amer-mta02.csc.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i0FHF3XC027859 for ; Thu, 15 Jan 2004 12:15:03 -0500 (EST) Received: from csc.com (va-fch32.csc.com [20.6.39.233]) by amer-mta02.csc.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i0FHF0XC027761 for ; Thu, 15 Jan 2004 12:15:03 -0500 (EST) Subject: Re: [Sip] re: WGLC: resource priority To: Cc: rohan@cisco.com, sip@ietf.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Janet P Gunn Date: Thu, 15 Jan 2004 12:16:40 -0500 X-MIMETrack: Serialize by Router on VA-FCH32/SRV/CSC(Release 6.0.3|September 26, 2003) at 01/15/2004 12:12:20 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I support Mike on this one. The Resource Priority Header is the "protocol", not the "policy". What policy will be evoked in a particular Administrative Domain, by a particular RPH namespace:value will be the subject of an SLA between relevant parties. Restrictions on the extent of the policy (for instance that it not be the instrument for DoS attacks) are already in the document. Janet ---------------------------------------------------------------------------------------- This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ---------------------------------------------------------------------------------------- To: , cc: 01/14/2004 09:25 Subject: Re: [Sip] re: WGLC: resource priority PM In a message dated 12/31/2003 4:46:50 PM Eastern Standard Time, rohan@cisco.com writes: 1. There is no normative description of the behavior of SIP devices which receive a particular priority value. Some specifications needs to either specify detailed behavior for specific priority values, or the detailed semantics of those values. I think this belongs in the IANA registration of each namespace, but those references are currently very thin. I made some specific comments to this end in the appropriate sections. [MAP] I believe this document should be limited to the definition of the data (header) and leave detailed behaviour and procedures to other documents that define specific services/capabilities which use it. It should not specify detailed behaviour for specific priority values. The references to IANA registration are thin because they only describe what IANA needs to deal with - assigning an ordered set of names for the priority levels for each "namespace". 3. Finally, the document shows that proxies can modify, insert, and delete the RP header. I don't think this is a good idea. Where cooperating UAs and proxies need to agree on an RP value, I believe the session policy mechanism can be used. A proxy can reject the message for policy reasons (use a lower/higher/specific resource-value) and the UA can retry the request with these new values. [MAP] While it may not be normal for a proxy to modify or delete an RP header, there may be services defined using this header that are based on proxies doing exactly that. For example, an originator tries to place a call using a high priority header. The proxy authenticates, determines tha the user is only authorized a lower priority level, automatically lowers it by changing the RP header, and forwards the call on its way, without requiring the UA to retry the call. Other documents would describe various operations, possibly including some cases in which a proxy can not modify the RP header. Mike Pierce _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Jan 16 04:45:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06824 for ; Fri, 16 Jan 2004 04:45:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhQXG-00088P-M0 for sip-archive@odin.ietf.org; Fri, 16 Jan 2004 04:45:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0G9j2Qo031199 for sip-archive@odin.ietf.org; Fri, 16 Jan 2004 04:45:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhQWJ-000866-HA; Fri, 16 Jan 2004 04:44:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhQVP-00084C-Gb for sip@optimus.ietf.org; Fri, 16 Jan 2004 04:43:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06780 for ; Fri, 16 Jan 2004 04:43:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhQVM-0006E3-00 for sip@ietf.org; Fri, 16 Jan 2004 04:43:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhQUT-0006CQ-00 for sip@ietf.org; Fri, 16 Jan 2004 04:42:09 -0500 Received: from mail4.telekom.de ([195.243.210.197]) by ietf-mx with esmtp (Exim 4.12) id 1AhQU8-0006AO-00 for sip@ietf.org; Fri, 16 Jan 2004 04:41:48 -0500 Received: from g8pbr.blf01.telekom.de by mail2.dmz.telekom.de with ESMTP for sip@ietf.org; Fri, 16 Jan 2004 10:29:09 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Jan 2004 10:29:09 +0100 Message-Id: <953B9B08F98DD61183F8000347AE660102862DE6@G8PPV.blf01.telekom.de> From: "Jesske, R" To: sip@ietf.org Cc: "Poetzl, Joachim" , "Alexeitsev, D" Date: Fri, 16 Jan 2004 10:29:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Sip] draft-ietf-sip-history-info-01.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Dear all, in 1.3 Ensuring the Privacy of History_Info it is proposed to use a priv-value of Session or Header level privacy. I would like to propose a own privacy level for the history info, because the Information shows also information about the network. With regard to the provider operating a network some of the providers don't like to transmit information about call history. Or a redirecting party don't like to show the redirecting address. Therefore it should be possible to delete the history info at domain boundaries based on the privacy-value. I propose the priv-value = "history_info" for the whole History-Info header. In addition a option would be useful where only parts (e.g Indes1.1) of the history info are restricted. That could be done with a privacy statement within the History-Info . Best Regards Roland Deutsche Telekom AG T Com Zentrale Roland Jesske, T332-2 Section T33; Signalling, Gateways and Switching Systems Am Kavalleriesand 3, 64295 Darmstadt, Germany Phone: +49 6151 83-5940 Fax: +49 6151 83-4577 email: r.jesske@t-com.net _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Jan 16 07:12:55 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11498 for ; Fri, 16 Jan 2004 07:12:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhSpr-0006QA-Sp for sip-archive@odin.ietf.org; Fri, 16 Jan 2004 07:12:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0GCCNoF024678 for sip-archive@odin.ietf.org; Fri, 16 Jan 2004 07:12:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhSoZ-0006Kb-BB; Fri, 16 Jan 2004 07:11:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhSo8-0006Jx-0K for sip@optimus.ietf.org; Fri, 16 Jan 2004 07:10:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11462 for ; Fri, 16 Jan 2004 07:10:30 -0500 (EST) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhSny-0006Gg-00 for sip@ietf.org; Fri, 16 Jan 2004 07:10:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhSlT-00068S-00 for sip@ietf.org; Fri, 16 Jan 2004 07:07:52 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AhSjF-00061B-00 for sip@ietf.org; Fri, 16 Jan 2004 07:05:33 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0GC58Y21812 for ; Fri, 16 Jan 2004 14:05:08 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 16 Jan 2004 14:05:07 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 16 Jan 2004 14:05:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] WGLC for PUBLISH Date: Fri, 16 Jan 2004 14:05:07 +0200 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D92C9@esebe013.ntc.nokia.com> Thread-Topic: [Sip] WGLC for PUBLISH Thread-Index: AcPbVVqdkNJ1XCQuRU2n++Dn0yJv2QAOhkKQ To: Cc: X-OriginalArrivalTime: 16 Jan 2004 12:05:08.0170 (UTC) FILETIME=[FC0822A0:01C3DC28] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Shinji, Thanks for the comments. Answers inline. > -----Original Message----- > From: ext OKUMURA Shinji [mailto:shin@softfront.co.jp] > Sent: 15 January, 2004 12:49 > To: Rohan Mahy > Cc: sip@ietf.org; Dean Willis; Niemi Aki (Nokia-M/Helsinki) > Subject: Re: [Sip] WGLC for PUBLISH >=20 >=20 > Hi, >=20 > [1] I believe it requires following changes in some headers of > the illustrated example in section 12. >=20 > In M1, Contact: should be=20 > rewritten as > Contact: > >=20 > In M2, Contact: should be > Contact: > > In M3, NOTIFY sip:presentity@example.com SIP/2.0 > Via: SIP/2.0/UDP pa.example.com;branch=3Dz9hG4bK8sdf2 > To: ;tag=3D12341234 > From: ;tag=3Dabcd1234 > Call-ID: 12345678@10.0.0.1 > CSeq: 1 NOTIFY > .... >=20 > should be >=20 > NOTIFY sip:watcher@10.0.0.1 SIP/2.0 > Via: SIP/2.0/UDP pa.example.com;branch=3Dz9hG4bK8sdf2 > To: ;tag=3D12341234 > From: ;tag=3Dabcd1234 > Call-ID: 12345678@10.0.0.1 > CSeq: 1 NOTIFY > Contact: > .... All true. Also, since the Via contains a domain name, I will add a = "received" param to the Via in the response. It's very good that you pointed out these mistakes in the examples. I = swear, I've looked at them a few times before, but I guess my internal = SIP parser is so well built that it never gave me an error message. ;-) I'll fix these for the next revision. =20 > [2] It could be helpful if the following example (2) is added in=20 > the document as an addition to the only example (1) illustrated=20 > in section 12. I'm a little reluctant to adding this. There are excellent SIP call = flows already documented elsewhere (see RFC 3665, e.g., Section 3.2), = and to this particular method, adding a proxy in between the PUA and the = PA works no different from how this works for other methods (MESSAGE, = INVITE). I.e., the proxy rewriting the Request-URI follows the same = logic as the other methods would. However, since this issue has come up before, it might be a good idea to = add a proxy between the PUA and PA. Any other views on this?=20 > (1) PUA <---> PA <---> WATCHER >=20 > (2) PUA <---> proxy <---> PA >=20 > For example: >=20 > PUA <-----> proxy <------> PA > | | | > | M1 PUBLISH | | > |----------->| M2 PUBLISH | > | |----------->| > | | M3 200 OK | > | M4 200 OK |<-----------| > |<-----------| | > =20 > M1: > PUBLISH sip:pa@example.com SIP/2.0 > Via: SIP/2.0/UDP pua.example.com;branch=3Dz9hG4bK652hsge > From: ;tag=3D1234wxyz > To: > Call-ID: 81818181@pua.example.com > CSeq: 1 PUBLISH > Max-Forwards: 70 > Expires: 3600 > Event: presence > Content-Type: application/pidf+xml > Content-Length: ... Note that the Request-URI needs to be 'sip:presentity@example.com'. = PUBLISH is specifically addressed to the resource, not the presence = agent. =20 > M2: > PUBLISH sip:pa.example.com SIP/2.0 > Via: SIP/2.0/UDP proxy.example.com;branch=3Dz9hG4bKpx123 > Via: SIP/2.0/UDP pua.example.com;branch=3Dz9hG4bK652hsge > From: ;tag=3D1234wxyz > To: > Call-ID: 81818181@pua.example.com > CSeq: 1 PUBLISH > Max-Forwards: 70 > Expires: 3600 > Event: presence > Content-Type: application/pidf+xml > Content-Length: ... The proxy would rewrite the Request-URI, but probably to something like = 'sip:presentity@pa.example.com'. Note that when the request is received = by the PA/ESC, it specifically uses the Request-URI to determine what = resource the PUBLISH is targeted for. This is identical to a SUBSCRIBE. = > M3: > SIP/2.0 200 OK > Via: SIP/2.0/UDP proxy.example.com;branch=3Dz9hG4bKpx123 > Via: SIP/2.0/UDP pua.example.com;branch=3Dz9hG4bK652hsge > From: ;tag=3D1234wxyz > To: ;tag=3D1a2b3c4d > Call-ID: 81818181@pua.example.com > CSeq: 1 PUBLISH > SIP-ETag: dx200xyz > Expires: 1800 > Content-Length: 0 > =20 > M4: > SIP/2.0 200 OK > Via: SIP/2.0/UDP pua.example.com;branch=3Dz9hG4bK652hsge > From: ;tag=3D1234wxyz > To: ;tag=3D1a2b3c4d > Call-ID: 81818181@pua.example.com > CSeq: 1 PUBLISH > SIP-ETag: dx200xyz > Expires: 1800 > Content-Length: 0 > =20 > [3] It could be better if the "Request-URI" is used as the message's > target address and the 'Presence Resource' is specified=20 > using "To" > header. >=20 > It would be easy for understanding if REGISTER's location=20 > registration operation like mechanism is considered. This is actually how PUBLISH used to work. But having the Request-URI = point to a PA requires special handling from the proxies and/or a = specific naming convention for PAs to be able to route the request. So = we decided to reject the REGISTER-like operation (determining the = resource by the To-field) in favor of the SUBSCRIBE-like behavior the = draft currently has. >=20 > The same point could also be said about RFC3265. This is because, >=20 > |3.1.5. Proxy SUBSCRIBE Behavior > | Proxies need no additional behavior beyond that=20 > described in SIP [1] > | to support SUBSCRIBE. >=20 > [4] For expressing 'Presence Resource', the=20 > pres-URI(draft-ietf-impp-pres-04) > would be better than that of the sip-URI. >=20 > Finally, when [3] & [4] are considered together, the=20 > various usages=20 > of URI can be expressed as listed below. >=20 > +------------+-----------------------------+----------------- > ------------+-----------------------------+ > | | PUBLISH | SUBSCRIBE =20 > | NOTIFY | > +------------+-----------------------------+----------------- > ------------+-----------------------------+ > |Request-URI | URI of PA | URI of PA =20 > | Contact-URI of SUBSCRIBE | > | | sip:pa@example.com |=20 > sip:pa@example.com | sip:watcher.example.com | > +------------+-----------------------------+----------------- > ------------+-----------------------------+ > |To-URI | URI of presence resource | URI of presence=20 > resource | From-URI of SUBSCRIBE | > | | pres:presentity@example.com |=20 > pres:presentity@example.com | sip:watcher@example.com | > +------------+-----------------------------+----------------- > ------------+-----------------------------+ > |From-URI | URI of presentity | URI of watcher =20 > | To-URI of SUBSCRIBE | > | | sip:presentity@example.com |=20 > sip:watcher@example.com | pres:presentity@example.com | > +------------+-----------------------------+----------------- > ------------+-----------------------------+ Adding to my previous comments, how would the UA find out the address of = a PA that services the presentity? We can't mandate a specific naming = convention for PAs in general, which is why the Request-URI is always = the address of the subscribed/published resource. Note that one valid location for a PA is in the client device. Because = of the way PUBLISH and SUBSCRIBE currently work, this requires nothing = special from a proxy - it simply forwards/redirects these requests to = the UA like any other request for that AoR. Cheers, Aki >=20 > Regards, > shinji >=20 > Rohan Mahy wrote in > >Hi, > > > >I'd like to begin Working Group Last Call for PUBLISH: > > > >=09 > http://www.ietf.org/internet-drafts/draft-ietf-sip-publish-02.txt > > > >This WGLC will end on January 28, 2004. > > > >thanks, > >-rohan > _________________________________________________ > OKUMURA Shinji E-mail:shin@softfront.co.jp >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Jan 16 08:30:47 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13309 for ; Fri, 16 Jan 2004 08:30:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhU3F-00018A-VR for sip-archive@odin.ietf.org; Fri, 16 Jan 2004 08:30:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0GDUHlS004345 for sip-archive@odin.ietf.org; Fri, 16 Jan 2004 08:30:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhU14-0000sk-EI; Fri, 16 Jan 2004 08:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhU0Y-0000s2-GQ for sip@optimus.ietf.org; Fri, 16 Jan 2004 08:27:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13235 for ; Fri, 16 Jan 2004 08:27:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhU0M-0002dZ-00 for sip@ietf.org; Fri, 16 Jan 2004 08:27:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhTwr-0002S2-00 for sip@ietf.org; Fri, 16 Jan 2004 08:23:42 -0500 Received: from phobos.simply.net ([81.3.64.11]) by ietf-mx with smtp (Exim 4.12) id 1AhTtk-0002CE-00 for sip@ietf.org; Fri, 16 Jan 2004 08:20:28 -0500 Received: (qmail 1891 invoked from network); 16 Jan 2004 13:19:28 -0000 Received: from 210-232-28.dial.terra.cl (HELO albers) (200.28.232.210) by phobos.simply.net with SMTP; 16 Jan 2004 13:19:28 -0000 From: "Ken Carlberg" To: , Cc: Subject: RE: [Sip] re: WGLC: resource priority (3) Date: Fri, 16 Jan 2004 08:19:22 -0500 Message-ID: <000f01c3dc33$5d8c1450$d2e81cc8@albers> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <1d4.1891a8a9.2d38924c@aol.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > [MAP] You're going to have to explain how that could work, considering > that the draft states: > > Every namespace must have a default level. > The default is assumed in the absence of a priority level (in a > message). > > That means that, if there is only one priority value in the > namespace (such as "on") registered with IANA, it must be the > default, and any INVITE that does not contain an RP-header is > treated as if it contained the default value ("on"). You've just explained your own request. > How would it be possible to signal the "off" value? "off" = absence of message/signal, ie, the SIP Invite msg is the same as if the R-P header didn't exist. If I'm forced to have an "off" R-P header value, than I'll need to write more code to recognize this, and I'll do more processing for the label and the subsequent authentication. And what did I gain in doing this added work compared to not sending the R-P header Invite? Nothing. I'm going to have a fun time explaining that to my guy who has written code to support the previous versions of the draft that he is going to write additional code that amounts to no gain. In fact, in thinking about this, it will be code that will never be used in our client using a namespace to support the NS/EP codepoint. The trigger for our SIP R-P client is a particular phone number sequence. Absence of that sequence means that all other calls from that client are regular SIP messages. > I think the age old practice of being conservative in what you send > applies to what we say to each other, not what signaling is sent by > telecommunications devices :>} agreed on the former, but Postel applied it to the latter and drilled it into many a head, who in turn continued the drilling :-). (note, the full quote is be liberal in what you accept, and conservative in what you send, see rfc-760) > Explain how one would signal the NS/EP codepoint case with only one > value (which is the default). You already have. And I've added a case in point where the "off" value will never see light of day. As a side note, this issue has been discussed in the past on a different list, so there is a reason why the draft has taken the position not requiring at least 2 values per namespace. My desire is to defend the current position, but the issue is not critical, so I will not add any other comments on the matter on the list. Regards, -ken ps, it would be nice to see plain text messages rather than html marked ones. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Jan 16 10:21:38 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17740 for ; Fri, 16 Jan 2004 10:21:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhVmU-0006g4-2z for sip-archive@odin.ietf.org; Fri, 16 Jan 2004 10:21:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0GFL6mI025665 for sip-archive@odin.ietf.org; Fri, 16 Jan 2004 10:21:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhVlU-0006aE-IS; Fri, 16 Jan 2004 10:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhVke-0006Yn-E7 for sip@optimus.ietf.org; Fri, 16 Jan 2004 10:19:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17685 for ; Fri, 16 Jan 2004 10:19:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhVkS-0001sd-00 for sip@ietf.org; Fri, 16 Jan 2004 10:19:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhVg7-0001gw-00 for sip@ietf.org; Fri, 16 Jan 2004 10:14:32 -0500 Received: from amer-mta01.csc.com ([20.137.2.247]) by ietf-mx with esmtp (Exim 4.12) id 1AhVe5-0001XF-00 for sip@ietf.org; Fri, 16 Jan 2004 10:12:25 -0500 Received: from amer-mta01.csc.com (localhost [127.0.0.1]) by amer-mta01.csc.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i0GFE1II001255; Fri, 16 Jan 2004 10:14:02 -0500 (EST) Received: from csc.com (va-fch32.csc.com [20.6.39.233]) by amer-mta01.csc.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i0GFE0IK001152; Fri, 16 Jan 2004 10:14:01 -0500 (EST) Subject: RE: [Sip] re: WGLC: resource priority (3) To: "Ken Carlberg" Cc: Mpierce1@aol.com, rohan@cisco.com, sip@ietf.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Janet P Gunn Date: Fri, 16 Jan 2004 10:10:18 -0500 X-MIMETrack: Serialize by Router on VA-FCH32/SRV/CSC(Release 6.0.3|September 26, 2003) at 01/16/2004 10:09:56 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Just a very small quibble. You say "The trigger for our SIP R-P client is a particular phone number sequence. Absence of that sequence means that all other calls from that client are regular SIP messages." That is one trigger, but there are other triggers for the NS/EP code point. But that doesn't change your point that if the call doesn't "trigger" the NS/EP code point, the RPH won't be there. Janet ---------------------------------------------------------------------------------------- This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ---------------------------------------------------------------------------------------- "Ken Carlberg" , @g11.org.uk> cc: Subject: RE: [Sip] re: WGLC: resource priority (3) 01/16/2004 08:19 AM > [MAP] You're going to have to explain how that could work, considering > that the draft states: > > Every namespace must have a default level. > The default is assumed in the absence of a priority level (in a > message). > > That means that, if there is only one priority value in the > namespace (such as "on") registered with IANA, it must be the > default, and any INVITE that does not contain an RP-header is > treated as if it contained the default value ("on"). You've just explained your own request. > How would it be possible to signal the "off" value? "off" = absence of message/signal, ie, the SIP Invite msg is the same as if the R-P header didn't exist. If I'm forced to have an "off" R-P header value, than I'll need to write more code to recognize this, and I'll do more processing for the label and the subsequent authentication. And what did I gain in doing this added work compared to not sending the R-P header Invite? Nothing. I'm going to have a fun time explaining that to my guy who has written code to support the previous versions of the draft that he is going to write additional code that amounts to no gain. In fact, in thinking about this, it will be code that will never be used in our client using a namespace to support the NS/EP codepoint. The trigger for our SIP R-P client is a particular phone number sequence. Absence of that sequence means that all other calls from that client are regular SIP messages. > I think the age old practice of being conservative in what you send > applies to what we say to each other, not what signaling is sent by > telecommunications devices :>} agreed on the former, but Postel applied it to the latter and drilled it into many a head, who in turn continued the drilling :-). (note, the full quote is be liberal in what you accept, and conservative in what you send, see rfc-760) > Explain how one would signal the NS/EP codepoint case with only one > value (which is the default). You already have. And I've added a case in point where the "off" value will never see light of day. As a side note, this issue has been discussed in the past on a different list, so there is a reason why the draft has taken the position not requiring at least 2 values per namespace. My desire is to defend the current position, but the issue is not critical, so I will not add any other comments on the matter on the list. Regards, -ken ps, it would be nice to see plain text messages rather than html marked ones. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Jan 16 11:07:40 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19518 for ; Fri, 16 Jan 2004 11:07:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhWV2-0000pj-Gc for sip-archive@odin.ietf.org; Fri, 16 Jan 2004 11:07:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0GG78V2003072 for sip-archive@odin.ietf.org; Fri, 16 Jan 2004 11:07:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhWU0-0000bg-Ck; Fri, 16 Jan 2004 11:06:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhWTh-0000at-If for sip@optimus.ietf.org; Fri, 16 Jan 2004 11:05:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19453 for ; Fri, 16 Jan 2004 11:05:41 -0500 (EST) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhWTa-0004xF-00 for sip@ietf.org; Fri, 16 Jan 2004 11:05:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhWQl-0004mX-00 for sip@ietf.org; Fri, 16 Jan 2004 11:02:44 -0500 Received: from imo-r02.mx.aol.com ([152.163.225.98]) by ietf-mx with esmtp (Exim 4.12) id 1AhWNo-0004Y7-00 for sip@ietf.org; Fri, 16 Jan 2004 10:59:40 -0500 Received: from Mpierce1@aol.com by imo-r02.mx.aol.com (mail_out_v36_r4.12.) id c.db.15cafc6 (4312); Fri, 16 Jan 2004 10:58:16 -0500 (EST) Message-ID: Date: Fri, 16 Jan 2004 10:58:15 EST Subject: Re: [Sip] re: WGLC: resource priority (2) To: rohan@cisco.com CC: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: 6.0 for Windows XP sub 10501 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit In a message dated 1/15/2004 3:09:02 PM Eastern Standard Time, rohan@cisco.com writes: I believe that the IANA *registration* does need to have such a forward reference and that the IESG will tend to agree with me. [MAP] Then it's a chicken and egg problem. I can't get the other normative reference through as an RFC or an internal DOD spec or an ITU-T Recommendation until this one is approved and we can't get this one approved until all the other ones it needs to reference are approved. In a message dated 1/15/2004 3:09:02 PM Eastern Standard Time, rohan@cisco.com writes: The UA should know the policy. There is no technical reason it can't know or collect the policy and then use the appropriate policy. That's what the session policy mechanism is for. However, there are a number of technical problems related to security we get when proxies start to insert or modify RP. [MAP] I didn't mean that the UA could never know the "policy" and do all kinds of things like ensuring that the human user is complying with "policy" before it sends an INVITE. Certainly one can be built to do this. But it is equally possible to build/operate a UA that does not do these types of things - that is, a "dumb device" that expects the human user to know what to do and to react properly. Both are possible, so lets ensure that the definition of the RP-header in this RFC allows both. Mike Pierce _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Jan 16 11:31:53 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20421 for ; Fri, 16 Jan 2004 11:31:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhWsX-0002Xv-7L for sip-archive@odin.ietf.org; Fri, 16 Jan 2004 11:31:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0GGVPZ0009726 for sip-archive@odin.ietf.org; Fri, 16 Jan 2004 11:31:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhWrF-0002IF-5B; Fri, 16 Jan 2004 11:30:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhWqk-0002Fy-HA for sip@optimus.ietf.org; Fri, 16 Jan 2004 11:29:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20273 for ; Fri, 16 Jan 2004 11:29:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhWqj-0006OX-00 for sip@ietf.org; Fri, 16 Jan 2004 11:29:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhWpp-0006KT-00 for sip@ietf.org; Fri, 16 Jan 2004 11:28:38 -0500 Received: from amer-mta01.csc.com ([20.137.2.247]) by ietf-mx with esmtp (Exim 4.12) id 1AhWpO-0006EG-00; Fri, 16 Jan 2004 11:28:10 -0500 Received: from amer-mta01.csc.com (localhost [127.0.0.1]) by amer-mta01.csc.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i0GGTqII022156; Fri, 16 Jan 2004 11:29:52 -0500 (EST) Received: from csc.com (va-fch32.csc.com [20.6.39.233]) by amer-mta01.csc.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i0GGTfIK021846; Fri, 16 Jan 2004 11:29:52 -0500 (EST) Subject: Re: [Sip] re: WGLC: resource priority (3) To: Mpierce1@aol.com Cc: carlberg@g11.org.uk, rohan@cisco.com, sip@ietf.org, sip-admin@ietf.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Janet P Gunn Date: Fri, 16 Jan 2004 11:30:32 -0500 X-MIMETrack: Serialize by Router on VA-FCH32/SRV/CSC(Release 6.0.3|September 26, 2003) at 01/16/2004 11:25:47 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , OK, now _I_ am confused. You say "If a message (INVITE) is sent without an RP-header, it should be treated by the receiver as if it contained an RP-header with the default value for that namespace, that is, "ON"." But if the message does not contain the R-P Header, how do I even know which namespace it (isn't) referring to. Are you saying that if a SIP message contains no R-P Header, it should be assumed to be "the default" for EVERY registered namespace? Or even for every namespace recognized by that network? (This doesn't seem sensible, since the default value, and the associated default behavior, are different for different namespaces.) I understood the document to say that the default value is used when there IS a R-P Header, and the header DOES contain the namespace, but DOES NOT contain the value. There is no one-to-one mapping between R-P namespaces and IP Administrative domains. I understood that two (or more) R-P Header namespaces (with different associated policies/behaviors) can be used in the same network, and even in the same SIP message. ---------------------------------------------------------------------------------------- This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ---------------------------------------------------------------------------------------- Mpierce1 @aol.com To: carlberg@g11.org.uk, rohan@cisco.com Sent by: cc: sip@ietf.org sip-admin Subject: Re: [Sip] re: WGLC: resource priority (3) 01/16/2004 10:58 AM In a message dated 1/16/2004 8:19:35 AM Eastern Standard Time, carlberg@g11.org.uk writes: > How would it be possible to signal the "off" value? "off" = absence of message/signal, ie, the SIP Invite msg is the same as if the R-P header didn't exist. If I'm forced to have an "off" R-P header value, than I'll need to write more code to recognize this, and I'll do more processing for the label and the subsequent authentication. And what did I gain in doing this added work compared to not sending the R-P header Invite? Nothing. I'm going to have a fun time explaining that to my guy who has written code to support the previous versions of the draft that he is going to write additional code that amounts to no gain. [MAP] We must be talking about two different things or we have completely different understandings of what the draft RP-header doc means, which scares me. I hope someone else can examine this issue and help us resolve it. If a namespace is defined with one single value of "ON", then that value "ON" must also be designated as the default. If a message (INVITE) is sent without an RP-header, it should be treated by the receiver as if it contained an RP-header with the default value for that namespace, that is, "ON". There is then no way to signal any other value (e.g.,"OFF") for this namespace since no other value is defined in the IANA registration. The absence of "ON" is not "OFF" since these are defined in IANA as text strings, not a boolean. "OFF" simply does not exist for this namespace. I don't understand the argument about saving (a trivial) amount of code (to recognize the "OFF" value). It seems to me that any implementation should be able to handle the case of multiple priority values (e.g., 5 for DOD), so the code to recognize 2 must already be there. What I always learned when defining protocols is that it is always best to be explicit in what you send, so that the receiver does not have to infer or guess or assume what was really meant. Mike Pierce _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Jan 16 11:55:43 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19519 for ; Fri, 16 Jan 2004 11:07:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhWV2-0000pk-Gz for sip-archive@odin.ietf.org; Fri, 16 Jan 2004 11:07:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0GG78VR003071 for sip-archive@odin.ietf.org; Fri, 16 Jan 2004 11:07:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhWTz-0000bU-5j; Fri, 16 Jan 2004 11:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhWTC-0000aX-Tt for sip@optimus.ietf.org; Fri, 16 Jan 2004 11:05:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19443 for ; Fri, 16 Jan 2004 11:05:10 -0500 (EST) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhWT5-0004ui-00 for sip@ietf.org; Fri, 16 Jan 2004 11:05:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhWQ4-0004jp-00 for sip@ietf.org; Fri, 16 Jan 2004 11:02:01 -0500 Received: from imo-r06.mx.aol.com ([152.163.225.102]) by ietf-mx with esmtp (Exim 4.12) id 1AhWNV-0004Vy-00 for sip@ietf.org; Fri, 16 Jan 2004 10:59:21 -0500 Received: from Mpierce1@aol.com by imo-r06.mx.aol.com (mail_out_v36_r4.12.) id v.92.1571dc6 (4312); Fri, 16 Jan 2004 10:58:04 -0500 (EST) Message-ID: <92.1571dc6.2d39640c@aol.com> Date: Fri, 16 Jan 2004 10:58:04 EST Subject: Re: [Sip] re: WGLC: resource priority (3) To: carlberg@g11.org.uk, rohan@cisco.com CC: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: 6.0 for Windows XP sub 10501 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit In a message dated 1/16/2004 8:19:35 AM Eastern Standard Time, carlberg@g11.org.uk writes: > How would it be possible to signal the "off" value? "off" = absence of message/signal, ie, the SIP Invite msg is the same as if the R-P header didn't exist. If I'm forced to have an "off" R-P header value, than I'll need to write more code to recognize this, and I'll do more processing for the label and the subsequent authentication. And what did I gain in doing this added work compared to not sending the R-P header Invite? Nothing. I'm going to have a fun time explaining that to my guy who has written code to support the previous versions of the draft that he is going to write additional code that amounts to no gain. [MAP] We must be talking about two different things or we have completely different understandings of what the draft RP-header doc means, which scares me. I hope someone else can examine this issue and help us resolve it. If a namespace is defined with one single value of "ON", then that value "ON" must also be designated as the default. If a message (INVITE) is sent without an RP-header, it should be treated by the receiver as if it contained an RP-header with the default value for that namespace, that is, "ON". There is then no way to signal any other value (e.g.,"OFF") for this namespace since no other value is defined in the IANA registration. The absence of "ON" is not "OFF" since these are defined in IANA as text strings, not a boolean. "OFF" simply does not exist for this namespace. I don't understand the argument about saving (a trivial) amount of code (to recognize the "OFF" value). It seems to me that any implementation should be able to handle the case of multiple priority values (e.g., 5 for DOD), so the code to recognize 2 must already be there. What I always learned when defining protocols is that it is always best to be explicit in what you send, so that the receiver does not have to infer or guess or assume what was really meant. Mike Pierce _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Jan 16 12:37:22 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22535 for ; Fri, 16 Jan 2004 12:37:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhXtu-0007IY-Rt for sip-archive@odin.ietf.org; Fri, 16 Jan 2004 12:36:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0GHasGW028048 for sip-archive@odin.ietf.org; Fri, 16 Jan 2004 12:36:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhXt5-0007DI-3f; Fri, 16 Jan 2004 12:36:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhXsR-00079R-S6 for sip@optimus.ietf.org; Fri, 16 Jan 2004 12:35:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22473 for ; Fri, 16 Jan 2004 12:35:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhXsQ-0002Lc-00 for sip@ietf.org; Fri, 16 Jan 2004 12:35:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhXrU-0002IK-00 for sip@ietf.org; Fri, 16 Jan 2004 12:34:24 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AhXqe-0002D8-00 for sip@ietf.org; Fri, 16 Jan 2004 12:33:33 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 16 Jan 2004 09:33:03 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id i0GHX0Qu005285; Fri, 16 Jan 2004 09:33:00 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id API58020; Fri, 16 Jan 2004 09:32:58 -0800 (PST) Date: Fri, 16 Jan 2004 09:34:36 -0800 Subject: Re: [Sip] re: WGLC: resource priority (3) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Cc: , To: "Ken Carlberg" From: Rohan Mahy In-Reply-To: <000f01c3dc33$5d8c1450$d2e81cc8@albers> Message-Id: <412CB351-484A-11D8-8B82-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.553) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ken, Just because you normally don't send the value "off" doesn't mean it doesn't exist. thx, -r On Friday, January 16, 2004, at 05:19 AM, Ken Carlberg wrote: >> [MAP] You're going to have to explain how that could work, considering > >> that the draft states: >> >> Every namespace must have a default level. >> The default is assumed in the absence of a priority level (in a >> message). >> >> That means that, if there is only one priority value in the >> namespace (such as "on") registered with IANA, it must be the >> default, and any INVITE that does not contain an RP-header is >> treated as if it contained the default value ("on"). > > You've just explained your own request. > >> How would it be possible to signal the "off" value? > > "off" = absence of message/signal, ie, the SIP Invite msg is the same > as > if the R-P header didn't exist. If I'm forced to have an "off" R-P > header value, than I'll need to write more code to recognize this, and > I'll do more processing for the label and the subsequent > authentication. > And what did I gain in doing this added work compared to not sending > the > R-P header Invite? Nothing. I'm going to have a fun time explaining > that to my guy who has written code to support the previous versions of > the draft that he is going to write additional code that amounts to no > gain. > > In fact, in thinking about this, it will be code that will never be > used > in our client using a namespace to support the NS/EP codepoint. The > trigger for our SIP R-P client is a particular phone number sequence. > Absence of that sequence means that all other calls from that client > are > regular SIP messages. > >> I think the age old practice of being conservative in what you send >> applies to what we say to each other, not what signaling is sent by >> telecommunications devices :>} > > agreed on the former, but Postel applied it to the latter and drilled > it > into many a head, who in turn continued the drilling :-). (note, the > full quote is be liberal in what you accept, and conservative in what > you send, see rfc-760) > >> Explain how one would signal the NS/EP codepoint case with only one >> value (which is the default). > > You already have. And I've added a case in point where the "off" value > will never see light of day. > > As a side note, this issue has been discussed in the past on a > different > list, so there is a reason why the draft has taken the position not > requiring at least 2 values per namespace. My desire is to defend the > current position, but the issue is not critical, so I will not add any > other comments on the matter on the list. > > Regards, > > -ken > > ps, it would be nice to see plain text messages rather than html marked > ones. > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Jan 16 12:49:12 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23041 for ; Fri, 16 Jan 2004 12:49:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhY5N-0008Ga-Mz for sip-archive@odin.ietf.org; Fri, 16 Jan 2004 12:48:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0GHmjqd031716 for sip-archive@odin.ietf.org; Fri, 16 Jan 2004 12:48:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhY4f-0008A5-Lj; Fri, 16 Jan 2004 12:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhY49-000895-WC for sip@optimus.ietf.org; Fri, 16 Jan 2004 12:47:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23014 for ; Fri, 16 Jan 2004 12:47:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhY48-0003Gl-00 for sip@ietf.org; Fri, 16 Jan 2004 12:47:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhY3E-0003DU-00 for sip@ietf.org; Fri, 16 Jan 2004 12:46:33 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AhY2v-00039i-00 for sip@ietf.org; Fri, 16 Jan 2004 12:46:13 -0500 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id i0GHjejQ013911; Fri, 16 Jan 2004 09:45:41 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id API59489; Fri, 16 Jan 2004 09:45:32 -0800 (PST) Date: Fri, 16 Jan 2004 09:47:13 -0800 Subject: Re: [Sip] re: WGLC: resource priority (2) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Cc: sip@ietf.org To: Mpierce1@aol.com From: Rohan Mahy In-Reply-To: Message-Id: <0426263C-484C-11D8-8B82-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.553) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Friday, January 16, 2004, at 07:58 AM, Mpierce1@aol.com wrote: > In a message dated 1/15/2004 3:09:02 PM Eastern Standard Time, > rohan@cisco.com writes: > > I believe that the IANA *registration* does need to have such a forward > reference and that the IESG will tend to agree with me. > > [MAP] Then it's a chicken and egg problem. I can't get the other > normative > reference through as an RFC or an internal DOD spec or an ITU-T > Recommendation > until this one is approved and we can't get this one approved until > all the > other ones it needs to reference are approved. There is no chicken and egg problem here. The Resource-Priority header and setting up the IANA namespace can happen as soon as this document is ready to go. Any initial namespaces that need to get registered are really optional--they can get registered if there is a document to reference. There is no dependency here. My understanding is that documents already exist which describe the behavior expected in the PSTN world for the proposed initial namespace registrations. If they aren't, then at a later time someone can write a document explaining the normative behavior and include the IANA registration in the document if it is an IETF document, or write a very short (~2 page) companion IETF document which just performs the registration. > In a message dated 1/15/2004 3:09:02 PM Eastern Standard Time, > rohan@cisco.com writes: > > The UA should know the policy. There is no technical reason it can't > know or collect the policy and then use the appropriate policy. That's > what the session policy mechanism is for. However, there are a number > of technical problems related to security we get when proxies start to > insert or modify RP. > > [MAP] I didn't mean that the UA could never know the "policy" and do > all > kinds of things like ensuring that the human user is complying with > "policy" > before it sends an INVITE. Certainly one can be built to do this. But > it is equally > possible to build/operate a UA that does not do these types of things > - that > is, a "dumb device" that expects the human user to know what to do and > to > react properly. Yes, I agree it is possible to build a dumb UA. That hurts, so don't do that. > Both are possible, so lets ensure that the definition of the RP-header > in > this RFC allows both. If you insist on allowing both, this work will have to wait for the appropriate mechanisms to secure proxy insertion (Middle to End security) which will take many months. I don't think this is in your best interest, or the best interest of the WG or the larger community. thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Jan 16 14:16:00 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25082 for ; Fri, 16 Jan 2004 14:16:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhZRI-0005N8-2p for sip-archive@odin.ietf.org; Fri, 16 Jan 2004 14:15:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0GJFSIm020644 for sip-archive@odin.ietf.org; Fri, 16 Jan 2004 14:15:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhZPt-0005AL-DS; Fri, 16 Jan 2004 14:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhZPF-00059N-1L for sip@optimus.ietf.org; Fri, 16 Jan 2004 14:13:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25007 for ; Fri, 16 Jan 2004 14:13:08 -0500 (EST) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhZOx-0006wq-00 for sip@ietf.org; Fri, 16 Jan 2004 14:13:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhZLW-0006oQ-00 for sip@ietf.org; Fri, 16 Jan 2004 14:09:31 -0500 Received: from imo-r05.mx.aol.com ([152.163.225.101]) by ietf-mx with esmtp (Exim 4.12) id 1AhZKl-0006ij-00 for sip@ietf.org; Fri, 16 Jan 2004 14:08:43 -0500 Received: from Mpierce1@aol.com by imo-r05.mx.aol.com (mail_out_v36_r4.12.) id t.17e.2549c794 (4196); Fri, 16 Jan 2004 14:07:23 -0500 (EST) Message-ID: <17e.2549c794.2d39906b@aol.com> Date: Fri, 16 Jan 2004 14:07:23 EST Subject: Re: [Sip] re: WGLC: resource priority (3) To: jgunn6@csc.com CC: carlberg@g11.org.uk, rohan@cisco.com, sip@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_17e.2549c794.2d39906b_boundary" X-Mailer: 6.0 for Windows XP sub 10501 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --part1_17e.2549c794.2d39906b_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 1/16/2004 11:28:02 AM Eastern Standard Time, jgunn6@csc.com writes: [JG] OK, now _I_ am confused. You say "If a message (INVITE) is sent without an RP-header, it should be treated by the receiver as if it contained an RP-header with the default value for that namespace, that is, "ON"." But if the message does not contain the R-P Header, how do I even know which namespace it (isn't) referring to. Are you saying that if a SIP message contains no R-P Header, it should be assumed to be "the default" for EVERY registered namespace? Or even for every namespace recognized by that network? (This doesn't seem sensible, since the default value, and the associated default behavior, are different for different namespaces.) [MAP] Yes, that is what I'm saying. Namespaces aren't some arbitrary things that just may or may not be present at random. Any device that might possibly react to the priority value of a namespace (or the default implied by its absence), must have an awareness of all the namespaces it needs to be concerned with. It must ignore all others, since they are meaningless. For the namespaces that it must be concerned with for a call setup, it must have a value to associate with each, even if derived by default. For Ken's apparent case where the defined value of "ON" means to use the NS/EP codepoint of T1.631, then the default (when nothing is specified as in 99.9999% of the calls) is to default to "OFF" for this namespace. If a device doesn't understand the need to default the namespace to "OFF", then it also could not know what "ON" means. This requires defining a namespace with two values, "ON" and "OFF", with "OFF" as the default. There is no way to do this with only one value ("ON") defined in the IANA registration. I agree with Ken's "be conservative in what you send" idea, that an implementation would never send an RP-header containing "OFF" for this namespace, but it still must be registered and receivers must be able to understand it ("be liberal in what you accept"). As Rohan says "Just because you normally don't send the value "off" doesn't mean it doesn't exist." [JG] I understood the document to say that the default value is used when there IS a R-P Header, and the header DOES contain the namespace, but DOES NOT contain the value. [MAP] The draft only says "in the absence of the priority value", which you could read to mean what you said above. I read it to mean any condition in which the priority value is not available, including the absence of the header, which I expect to be the way to code the message for the majority of calls that want the default value (as explained above). As I read the ABNF, the priority value can not be left out if a namespace is specified. [JG] There is no one-to-one mapping between R-P namespaces and IP Administrative domains. I understood that two (or more) R-P Header namespaces (with different associated policies/behaviors) can be used in the same network, and even in the same SIP message. [MAP] Yes, but the draft intentionally does not talk about the interaction between them. Each is treated separately. Mike Pierce --part1_17e.2549c794.2d39906b_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message=20= dated 1/16/2004 11:28:02 AM Eastern Standard Time, jgunn6@csc.com writes:

[JG]
OK, now _I_ am confused.

You say "If a message (INVITE) is sent without an RP-header, it should b= e
treated by
the receiver as if it contained an RP-header with the default value for
that
namespace, that is, "ON"."

But  if the message does not contain the R-P Header, how do I even=20= know
which namespace it (isn't) referring to.  Are you saying that if a=20=  SIP
message contains no R-P Header, it should be assumed to be "the default"
for EVERY registered namespace? Or even for every namespace recognized b= y
that network? (This doesn't seem sensible, since the default value, and=20= the
associated default behavior, are different for different namespaces.)



[MAP] Yes, that is what I'm saying. Namespaces aren't some arbitrary thi= ngs that just may or may not be present at random. Any device that might pos= sibly react to the priority value of a namespace (or the default implied by=20= its absence), must have an awareness of all the namespaces it needs to be co= ncerned with. It must ignore all others, since they are meaningless. For the= namespaces that it must be concerned with for a call setup, it must have a=20= value to associate with each, even if derived by default. For Ken's apparent= case where the defined value of "ON" means to use the NS/EP codepoint of T1= .631, then the default (when nothing is specified as in 99.9999% of the call= s) is to default to "OFF" for this namespace. If a device doesn't understand= the need to default the namespace to "OFF", then it also could not know wha= t "ON" means. This requires defining a namespace with two values, "ON" and "= OFF", with "OFF" as the default. There is no way to do this with only one va= lue ("ON") defined in the IANA registration. I agree with Ken's "be conserva= tive in what you send" idea, that an implementation would never send an RP-h= eader containing "OFF" for this namespace, but it still must be registered a= nd receivers must be able to understand it ("be liberal in what you accept")= . As Rohan says "Just because you normally don't send the value "off" doesn'= t mean it doesn't exist."

[JG]

I understood the document to say that the default value is used when the= re
IS a R-P Header, and the header DOES contain the namespace, but DOES NOT
contain the value.



[MAP] The draft only says "in the absence of the priority value", which=20= you could read to mean what you said above. I read it to mean any condition=20= in which the priority value is not available, including the absence of the h= eader, which I expect to be the way to code the message for the majority of=20= calls that want the default value (as explained above). As I read the ABNF,=20= the priority value can not be left out if a namespace is specified.

[JG]

There is no one-to-one mapping between R-P namespaces and IP Administrat= ive
domains.

I understood that two (or more) R-P Header namespaces (with different
associated policies/behaviors) can be used in the same network, and even= in
the same SIP message.



[MAP] Yes, but the draft intentionally does not talk about the interacti= on between them. Each is treated separately.

Mike Pierce

--part1_17e.2549c794.2d39906b_boundary-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Jan 16 19:22:40 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06779 for ; Fri, 16 Jan 2004 19:22:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AheE9-000735-2D for sip-archive@odin.ietf.org; Fri, 16 Jan 2004 19:22:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0H0MCdU027033 for sip-archive@odin.ietf.org; Fri, 16 Jan 2004 19:22:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AheD0-0006ut-OU; Fri, 16 Jan 2004 19:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AheCu-0006uG-LF for sip@optimus.ietf.org; Fri, 16 Jan 2004 19:20:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06634 for ; Fri, 16 Jan 2004 19:20:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AheCj-0006v0-00 for sip@ietf.org; Fri, 16 Jan 2004 19:20:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ahe7z-0006Zb-00 for sip@ietf.org; Fri, 16 Jan 2004 19:15:52 -0500 Received: from broadsoft.com ([198.104.184.110]) by ietf-mx with esmtp (Exim 4.12) id 1Ahe48-0006Fn-00 for sip@ietf.org; Fri, 16 Jan 2004 19:11:52 -0500 Received: from tate (host4.brodsoft.com [66.160.10.4]) by broadsoft.com (8.12.10/8.12.9) with SMTP id i0H0BRjx097575 for ; Fri, 16 Jan 2004 19:11:28 -0500 (EST) Reply-To: From: "Brett Tate" To: "sip-ietf \(E-mail\)" Date: Fri, 16 Jan 2004 19:13:58 -0500 Message-ID: <004801c3dc8e$ce240640$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Is Retry-After:0 valid? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit (Trying the sip list because I did not receive any reply concerning my sip-implementors posting...) Is 0 a valid value for the retry-after header? I assume that it is; and the bnf allows it. However I guess that it depends upon the meaning of "positive" in section 20.33 and if the "between" statement of section 14.2 is inclusive. RFC3261 section 20.33 mentions the following: "The value of this field is a positive integer number of seconds (in decimal) after the time of the response." RFC3261 section 14.2 mentions the following: "MUST include a Retry-After header field with a randomly chosen value of between 0 and 10 seconds." _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Jan 19 00:19:14 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17255 for ; Mon, 19 Jan 2004 00:19:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiRoE-0000YI-RQ for sip-archive@odin.ietf.org; Mon, 19 Jan 2004 00:18:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0J5IkaI002119 for sip-archive@odin.ietf.org; Mon, 19 Jan 2004 00:18:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiRmX-0000Rk-P1; Mon, 19 Jan 2004 00:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiRln-0000Q0-Hl for sip@optimus.ietf.org; Mon, 19 Jan 2004 00:16:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17174 for ; Mon, 19 Jan 2004 00:16:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiRll-0000CW-00 for sip@ietf.org; Mon, 19 Jan 2004 00:16:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AiRko-0000Ad-00 for sip@ietf.org; Mon, 19 Jan 2004 00:15:15 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AiRkI-00008m-00 for sip@ietf.org; Mon, 19 Jan 2004 00:14:42 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 18 Jan 2004 21:17:50 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i0J5EBVM017396; Sun, 18 Jan 2004 21:14:11 -0800 (PST) Received: from [10.0.1.3] (sjc-vpn2-407.cisco.com [10.21.113.151]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ALN78784; Sun, 18 Jan 2004 21:14:09 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Sun, 18 Jan 2004 21:14:09 -0800 Subject: Re: [Sip] SIP DTMF From: Cullen Jennings To: Paul Long , Message-ID: In-Reply-To: <001601c3db9c$d7cfb240$0201a8c0@afaith2> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable The draft is http://www.ietf.org/internet-drafts/draft-burger-sipping-kpml-02.txt 2833 is the preferred method, but if an off media axis device wished to get notification about key presses, it could. How these all relate is covered i= n http://www.softarmor.com/wgdb/docs/ draft-ietf-sipping-app-interaction-framework-00.txt Cullen On 1/15/04 11:21 AM, "Paul Long" wrote: > Sreeram, >=20 > I can't find a "kpxml" draft on the IETF site or via Google--anywhere. > Can you provide a link to it? >=20 > Also, from my experience, the preferred method of DTMF carriage is RFC > 2833, followed by in-band audio, and then various proprietary > INFO-method schemes. What is the standing of RFC 2833 vis-=E0-vis "kpxml?" >=20 > Paul >=20 > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of > sreeram.kanumuri@wipro.com > Sent: Tuesday, January 13, 2004 9:06 PM > To: xyxie@udtech.com.cn; sip@ietf.org > Cc: sipping@ietf.org > Subject: RE: [Sip] SIP DTMF >=20 > Wendy, >=20 > There was a discussion in the list some time back and it was decided > that SIP-INFO method should not be used to > Send the DTMF info. >=20 > It was proposed that it is better to you kpxml for sending DTMF tones. >=20 > Please look in to the SIP-Kpxml draft for sending DTMF tomes in-midcall > processing and all.... >=20 >=20 > Regards, > Sreeram >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Sreeram Kanumuri Plot No 72, Keonics Electronics City > Hosur Main Road > Wipro Technologies Bangalore -29 INDIA > sreeram.kanumuri@wipro.com Phone: 8520408 Ex:3208 > skanumury@yahoo.com ESN : > www.wipro.com Mobile: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of wendy > Sent: Wednesday, January 14, 2004 8:08 AM > To: sip@ietf.org > Cc: sipping@ietf.org > Subject: [Sip] SIP DTMF >=20 >=20 > Hello all,=20 >=20 > Who can tell me whether there is a RFC or I-D on DTMF in SIP which is > still not expired? I remember someone proposed using SIP INFO method for > DTMF one or two years ago. Is the DTMF relay implemented only by RTP > now? >=20 >=20 > Regards, > Wendy >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Jan 19 02:38:09 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04002 for ; Mon, 19 Jan 2004 02:38:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiTyf-0007NT-2Y for sip-archive@odin.ietf.org; Mon, 19 Jan 2004 02:37:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0J7beSo028294 for sip-archive@odin.ietf.org; Mon, 19 Jan 2004 02:37:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiTx6-0006xs-63; Mon, 19 Jan 2004 02:36:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhWpg-00029a-GA for sip@optimus.ietf.org; Fri, 16 Jan 2004 11:28:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20244 for ; Fri, 16 Jan 2004 11:28:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhWpf-0006Jb-00 for sip@ietf.org; Fri, 16 Jan 2004 11:28:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhWpE-0006Fc-00 for sip@ietf.org; Fri, 16 Jan 2004 11:28:01 -0500 Received: from dns1.tilab.com ([163.162.42.4]) by ietf-mx with esmtp (Exim 4.12) id 1AhWn5-00066K-00 for sip@ietf.org; Fri, 16 Jan 2004 11:25:48 -0500 Received: from iowa2k01a.cselt.it ([163.162.242.203]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0HRL00B22C805G@dns1.cselt.it> for sip@ietf.org; Fri, 16 Jan 2004 17:24:00 +0100 (MET) Received: from iowa2k01a.cselt.it ([163.162.242.201]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Fri, 16 Jan 2004 17:25:19 +0100 Received: from EXC2K04A.cselt.it ([163.162.161.229]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Fri, 16 Jan 2004 17:25:19 +0100 Received: from EXC2K01B.cselt.it ([163.162.4.97]) by EXC2K04A.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Fri, 16 Jan 2004 17:24:50 +0100 Date: Fri, 16 Jan 2004 17:24:48 +0100 From: Home Cortes John Alexander To: sip@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: Difference between SIP URL and SIP URI thread-index: AcPcTYVRztCuK7wzTdmHFTbUlVOUmw== Content-Class: urn:content-classes:message X-OriginalArrivalTime: 16 Jan 2004 16:24:50.0225 (UTC) FILETIME=[43A90A10:01C3DC4D] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Sip] Difference between SIP URL and SIP URI Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I'm studying the specification 3GPP TS 23.228, and there are concepts = related to SIP. I would like to know some concepts and clarify some = terms. The identification of User are defined by some user identities. = It's defined that the temporary public user identity shall take the form = of a SIP URL as described in the section 4.3.3.1 (3GPP TS 23.228 V5.9.0 = (2003-06), "Network Architecture" (Release 5). I looked for this term = "SIP URL" in the RFC3261 and SIP URL is not mentioned. As far as know, = user agents are identify for a SIP URI.=20 I would like to know what is the difference between SIP URL and SIP URI? I would appreciate for your help Thanks in advance. John Home=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Jan 19 04:49:24 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09468 for ; Mon, 19 Jan 2004 04:49:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiW1g-0007Ck-BB for sip-archive@odin.ietf.org; Mon, 19 Jan 2004 04:48:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0J9musG027691 for sip-archive@odin.ietf.org; Mon, 19 Jan 2004 04:48:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiW0o-0006z9-Sy; Mon, 19 Jan 2004 04:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiW0S-0006wT-GL for sip@optimus.ietf.org; Mon, 19 Jan 2004 04:47:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09389 for ; Mon, 19 Jan 2004 04:47:37 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiW0P-0007nW-00 for sip@ietf.org; Mon, 19 Jan 2004 04:47:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AiVzN-0007ib-00 for sip@ietf.org; Mon, 19 Jan 2004 04:46:33 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AiVyg-0007f7-00 for sip@ietf.org; Mon, 19 Jan 2004 04:45:50 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0J9joY12188 for ; Mon, 19 Jan 2004 11:45:50 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 19 Jan 2004 11:45:50 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 19 Jan 2004 11:45:49 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Is Retry-After:0 valid? Date: Mon, 19 Jan 2004 11:45:48 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017975D5@esebe019.ntc.nokia.com> Thread-Topic: [Sip] Is Retry-After:0 valid? Thread-Index: AcPckAZrnW59r2TqTqGXZ6G+cH1MagB4MODg To: , X-OriginalArrivalTime: 19 Jan 2004 09:45:49.0766 (UTC) FILETIME=[05462660:01C3DE71] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I don't see why it would be disallowed. It is certainly valid and says = to retry immediately (after 0 seconds). I guess the second quote can have the word "inclusive" added. Regards, Hisham > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of ext > Brett Tate > Sent: 17.January.2004 02:14 > To: sip-ietf (E-mail) > Subject: [Sip] Is Retry-After:0 valid? >=20 >=20 > (Trying the sip list because I did not > receive any reply concerning my=20 > sip-implementors posting...) >=20 >=20 > Is 0 a valid value for the retry-after header? >=20 > I assume that it is; and the bnf allows it. > However I guess that it depends upon the meaning=20 > of "positive" in section 20.33 and if the=20 > "between" statement of section 14.2 is inclusive. >=20 > RFC3261 section 20.33 mentions the following: > "The value of this field is a positive integer > number of seconds (in decimal) after the time=20 > of the response." >=20 > RFC3261 section 14.2 mentions the following: > "MUST include a Retry-After header field with a > randomly chosen value of between 0 and 10 seconds." >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Jan 19 06:22:29 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12757 for ; Mon, 19 Jan 2004 06:22:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiXTm-0003js-KO for sip-archive@odin.ietf.org; Mon, 19 Jan 2004 06:22:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0JBM2TJ014368 for sip-archive@odin.ietf.org; Mon, 19 Jan 2004 06:22:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiXSo-0003hP-TT; Mon, 19 Jan 2004 06:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiXSF-0003g2-K8 for sip@optimus.ietf.org; Mon, 19 Jan 2004 06:20:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12667 for ; Mon, 19 Jan 2004 06:20:23 -0500 (EST) From: ajit.katankot@wipro.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiXSB-0005fa-00 for sip@ietf.org; Mon, 19 Jan 2004 06:20:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AiXRE-0005bG-00 for sip@ietf.org; Mon, 19 Jan 2004 06:19:25 -0500 Received: from wiproecmx2.wipro.com ([164.164.31.6]) by ietf-mx with esmtp (Exim 4.12) id 1AiXQJ-0005Uo-00 for sip@ietf.org; Mon, 19 Jan 2004 06:18:29 -0500 Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx2.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i0JBHsHB011349 for ; Mon, 19 Jan 2004 16:47:55 +0530 (IST) Received: from blr-ec-bh1.wipro.com ([10.200.50.91]) by ec-vwall-wd with InterScan Messaging Security Suite; Mon, 19 Jan 2004 16:48:36 +0530 Received: from blr-itp-msg.wipro.com ([10.185.50.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 19 Jan 2004 16:47:54 +0530 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3DE7D.E1DCEB8C" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 19 Jan 2004 16:47:53 +0530 Message-ID: <0F0DBEBBBDFC0D41A3E5CDDF7EAE6E18C5148F@blr-itp-msg.wipro.com> Thread-Topic: Comment in draft-ietf-sipping-torture-tests-02.txt Thread-Index: AcPefeEI4uNTOUShQQOU/p3zPLGppg== To: Cc: X-OriginalArrivalTime: 19 Jan 2004 11:17:54.0112 (UTC) FILETIME=[E20A7400:01C3DE7D] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=HTML_30_40,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.60 Subject: [Sip] Comment in draft-ietf-sipping-torture-tests-02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3DE7D.E1DCEB8C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I have a question on the parsing of the following INVITE message given in section 3.1.1.1 of draft-ietf-sipping-torture-tests-02.txt. =20 In this message the contact header (m line) is extended over multiple lines, but the extra line does not precede with at least one SP or HT. Is this a valid Contact header ? =20 Section 7.3.1 in RFC 3261 mentions that:=20 =20 "Header fields can be extended over multiple lines by preceding each extra line with at least one SP or horizontal tab (HT). The line break and the whitespace at the beginning of the next line are treated as a single SP character." =20 ------------------------------ INVITE sip:vivekg@chair-dnrc.example.com;unknownparam SIP/2.0 TO : sip:vivekg@chair-dnrc.example.com ; tag =3D 1918181833n from : "J Rosenberg \\\"" ; tag =3D 98asjd8 MaX-fOrWaRdS: 0068 Call-ID: 0ha0isndaksdj@192.0.2.1 Content-Length : 151 cseq: 0009 INVITE Via : SIP / 2.0 /UDP 192.0.2.2;branch=3D390skdjuw s : NewFangledHeader: newfangled value continued newfangled value UnknownHeaderWithUnusualValue: ;;,,;;,; Content-Type: application/sdp Route: v: SIP / 2.0 / TCP spindle.example.com ; branch =3D z9hG4bK9ikj8 , SIP / 2.0 / UDP 192.168.255.111 ; branch=3D z9hG4bK30239 m:"Quoted string \"\"" ; newparam =3D newvalue ; secondparam ; q =3D 0.33 =20 v=3D0 o=3Dmhandley 29739 7272939 IN IP4 192.0.2.3 s=3D- c=3DIN IP4 192.0.2.4 t=3D0 0 m=3Daudio 492170 RTP/AVP 0 12 m=3Dvideo 3227 RTP/AVP 31 a=3Drtpmap:31 LPC =20 ------_=_NextPart_001_01C3DE7D.E1DCEB8C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi,
 
I have = a question on=20 the parsing of the following INVITE message given in section =20 3.1.1.1 of = draft-ietf-sipping-torture-tests-02.txt.
 
In = this=20 message the contact header (m line) is extended over multiple = lines,=20 but the extra line does not precede with at least one SP or HT. Is this = a valid=20 Contact header ?
 
Section 7.3.1 in RFC=20 3261 mentions that:
 
"Header fields can be extended over = multiple=20 lines by preceding each extra line=20 with at least one SP or horizontal tab (HT).  The line break and the whitespace at the = beginning=20 of the next line are treated as = a single=20 SP character."
 
------------------------------
INVITE=20 sip:vivekg@chair-dnrc.example.com;unknownparam SIP/2.0
TO=20 :
 sip:vivekg@chair-dnrc.example.com ;   = tag   =20 =3D 1918181833n
from   : "J Rosenberg=20 \\\""      =20 <sip:jdrosen@example.com>
  ;
  tag =3D=20 98asjd8
MaX-fOrWaRdS: 0068
Call-ID: 0ha0isndaksdj@192.0.2.1
Co= ntent-Length  =20 : 151
cseq: 0009
  INVITE
Via  : SIP  = /  =20 2.0
 /UDP
    = 192.0.2.2;branch=3D390skdjuw
s=20 :
NewFangledHeader:   newfangled value
 continued=20 newfangled value
UnknownHeaderWithUnusualValue: = ;;,,;;,;
Content-Type:=20 application/sdp
Route:
 <sip:services.example.com;lr;unknow= nwith=3Dvalue;unknown-no-value>
v: =20 SIP  / 2.0  / TCP    =20 spindle.example.com   ;
  branch  =3D   = z9hG4bK9ikj8  ,
 SIP  /    = 2.0   /=20 UDP  192.168.255.111   ;=20 branch=3D
 z9hG4bK30239
m:"Quoted string \"\""=20 <sip:jdrosen@example.com> ; newparam =3D
newvalue ;
  = secondparam=20 ; q =3D 0.33
 
v=3D0
o=3Dmhandley 29739 7272939 IN = IP4=20 192.0.2.3
s=3D-
c=3DIN IP4 192.0.2.4
t=3D0 0
m=3Daudio = 492170 RTP/AVP 0=20 12
m=3Dvideo 3227 RTP/AVP 31
a=3Drtpmap:31 LPC
 
------_=_NextPart_001_01C3DE7D.E1DCEB8C-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Jan 19 08:25:01 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15747 for ; Mon, 19 Jan 2004 08:25:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiZOL-00018v-8J for sip-archive@odin.ietf.org; Mon, 19 Jan 2004 08:24:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0JDOXde004390 for sip-archive@odin.ietf.org; Mon, 19 Jan 2004 08:24:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiZNQ-0000xy-Qj; Mon, 19 Jan 2004 08:23:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiYFf-0006DQ-H2 for sip@optimus.ietf.org; Mon, 19 Jan 2004 07:11:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13870 for ; Mon, 19 Jan 2004 07:11:26 -0500 (EST) From: nataraju.alilaghatta@wipro.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiYFW-00007u-00 for sip@ietf.org; Mon, 19 Jan 2004 07:11:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AiYCe-00001C-00 for sip@ietf.org; Mon, 19 Jan 2004 07:08:25 -0500 Received: from wiproecmx1.wipro.com ([164.164.31.5]) by ietf-mx with esmtp (Exim 4.12) id 1AiYB4-0007i8-00 for sip@ietf.org; Mon, 19 Jan 2004 07:06:47 -0500 Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx1.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i0JC5nXu029990 for ; Mon, 19 Jan 2004 17:35:49 +0530 (IST) Received: from blr-ec-bh3.wipro.com ([10.200.50.93]) by ec-vwall-wd with InterScan Messaging Security Suite; Mon, 19 Jan 2004 17:36:31 +0530 Received: from blr-ec-msg04.wipro.com ([10.200.53.99]) by blr-ec-bh3.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 19 Jan 2004 17:35:47 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3DE84.929427AA" Subject: RE: [Sip] Comment in draft-ietf-sipping-torture-tests-02.txt Date: Mon, 19 Jan 2004 17:35:47 +0530 Message-ID: <10C4348A1BA43A4FA8D5B767E052CEADE05A13@blr-ec-msg04.wipro.com> Thread-Topic: [Sip] Comment in draft-ietf-sipping-torture-tests-02.txt Thread-Index: AcPefeEI4uNTOUShQQOU/p3zPLGppgAB7qZQ To: , Cc: X-OriginalArrivalTime: 19 Jan 2004 12:05:47.0961 (UTC) FILETIME=[92FD0290:01C3DE84] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_50_60, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3DE84.929427AA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 Thanks & Regards, Nataraju A.B.=20 -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Ajit Katankot (WT01 - TELECOM & INTER-NETWORKING SOLUTIONS) Sent: Monday, January 19, 2004 4:48 PM To: sip@ietf.org Cc: rsparks@dynamicsoft.com Subject: [Sip] Comment in draft-ietf-sipping-torture-tests-02.txt =20 Hi, =20 I have a question on the parsing of the following INVITE message given in section 3.1.1.1 of draft-ietf-sipping-torture-tests-02.txt. =20 In this message the contact header (m line) is extended over multiple lines, but the extra line does not precede with at least one SP or HT. Is this a valid Contact header ? =20 [ABN] this is an INVALID input, the parser should not consider this header as an invalid header... =20 Section 7.3.1 in RFC 3261 mentions that:=20 =20 "Header fields can be extended over multiple lines by preceding each extra line with at least one SP or horizontal tab (HT). The line break and the whitespace at the beginning of the next line are treated as a single SP character." =20 ------------------------------ INVITE sip:vivekg@chair-dnrc.example.com;unknownparam SIP/2.0 TO : sip:vivekg@chair-dnrc.example.com ; tag =3D 1918181833n from : "J Rosenberg \\\"" ; tag =3D 98asjd8 MaX-fOrWaRdS: 0068 Call-ID: 0ha0isndaksdj@192.0.2.1 Content-Length : 151 cseq: 0009 INVITE Via : SIP / 2.0 /UDP 192.0.2.2;branch=3D390skdjuw s : NewFangledHeader: newfangled value continued newfangled value UnknownHeaderWithUnusualValue: ;;,,;;,; Content-Type: application/sdp Route: v: SIP / 2.0 / TCP spindle.example.com ; branch =3D z9hG4bK9ikj8 , SIP / 2.0 / UDP 192.168.255.111 ; branch=3D z9hG4bK30239 m:"Quoted string \"\"" ; newparam =3D newvalue ; secondparam ; q =3D 0.33 =20 v=3D0 o=3Dmhandley 29739 7272939 IN IP4 192.0.2.3 s=3D- c=3DIN IP4 192.0.2.4 t=3D0 0 m=3Daudio 492170 RTP/AVP 0 12 m=3Dvideo 3227 RTP/AVP 31 a=3Drtpmap:31 LPC =20 ------_=_NextPart_001_01C3DE84.929427AA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

 

 

Thanks & Regards,
Nataraju A.B.

-----Original Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On = Behalf Of Ajit Katankot (WT01 - TELECOM & INTER-NETWORKING SOLUTIONS)
Sent: Monday, January 19, 2004 4:48 = PM
To: sip@ietf.org
Cc: = rsparks@dynamicsoft.com
Subject: [Sip] Comment in draft-ietf-sipping-torture-tests-02.txt

 

Hi,

 

I have a question on the parsing of the following = INVITE message given in section  3.1.1.1 of draft-ietf-sipping-torture-tests-02.txt.

 

In this message the contact header (m line) = is extended over multiple lines, but the extra line does not precede with = at least one SP or HT. Is this a valid Contact header ?

=  

=  [ABN] this = is an INVALID input, the parser should not consider this header as an invalid = header…

 

Section 7.3.1 in RFC 3261 mentions that: =

 

"Header fields can be extended over multiple = lines by preceding each extra line with at least one SP or horizontal tab (HT).  The line break and the whitespace at the beginning of = the next line are treated as a single SP = character."

 

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

INVITE sip:vivekg@chair-dnrc.example.com;unknownparam SIP/2.0
TO :
 sip:vivekg@chair-dnrc.example.com ;   = tag    =3D 1918181833n
from   : "J Rosenberg \\\""       <sip:jdrosen@example.com>
  ;
  tag =3D 98asjd8
MaX-fOrWaRdS: 0068
Call-ID: 0ha0isndaksdj@192.0.2.1
Content-Length   : 151
cseq: 0009
  INVITE
Via  : SIP  /   2.0
 /UDP
    192.0.2.2;branch=3D390skdjuw
s :
NewFangledHeader:   newfangled value
 continued newfangled value
UnknownHeaderWithUnusualValue: ;;,,;;,;
Content-Type: application/sdp
Route:
 <sip:services.example.com;lr;unknownwith=3Dvalue;unknown-no-valu= e>
v:  SIP  / 2.0  / TCP     spindle.example.com   ;
  branch  =3D   z9hG4bK9ikj8  ,
 SIP  /    2.0   / UDP  192.168.255.111   ; branch=3D
 z9hG4bK30239
m:"Quoted string \"\"" = <sip:jdrosen@example.com> ; newparam =3D
newvalue ;
  secondparam ; q =3D 0.33

 

v=3D0
o=3Dmhandley 29739 7272939 IN IP4 192.0.2.3
s=3D-
c=3DIN IP4 192.0.2.4
t=3D0 0
m=3Daudio 492170 RTP/AVP 0 12
m=3Dvideo 3227 RTP/AVP 31
a=3Drtpmap:31 LPC

 

------_=_NextPart_001_01C3DE84.929427AA-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Jan 19 09:53:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18827 for ; Mon, 19 Jan 2004 09:53:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aialz-00081g-9K for sip-archive@odin.ietf.org; Mon, 19 Jan 2004 09:53:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0JEr3ia030848 for sip-archive@odin.ietf.org; Mon, 19 Jan 2004 09:53:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aiaky-0007yP-Ie; Mon, 19 Jan 2004 09:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aiakp-0007y9-GL for sip@optimus.ietf.org; Mon, 19 Jan 2004 09:51:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18788 for ; Mon, 19 Jan 2004 09:51:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aiaki-0001GX-00 for sip@ietf.org; Mon, 19 Jan 2004 09:51:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aiak4-0001Di-00 for sip@ietf.org; Mon, 19 Jan 2004 09:51:05 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AiajM-00019E-00 for sip@ietf.org; Mon, 19 Jan 2004 09:50:20 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id i0JEned30236; Mon, 19 Jan 2004 08:49:40 -0600 Subject: RE: [Sip] Comment in draft-ietf-sipping-torture-tests-02.txt From: Robert Sparks To: nataraju.alilaghatta@wipro.com Cc: ajit.katankot@wipro.com, sip@ietf.org In-Reply-To: <10C4348A1BA43A4FA8D5B767E052CEADE05A13@blr-ec-msg04.wipro.com> References: <10C4348A1BA43A4FA8D5B767E052CEADE05A13@blr-ec-msg04.wipro.com> Content-Type: text/plain; charset=UTF-8 Message-Id: <1074523773.906.1.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 19 Jan 2004 08:49:33 -0600 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by dyn-tx-arch-crash.dfw.dynamicsoft.com id i0JEned30236 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable This is a SIPPING draft. This bug has already been discussed on that list and will be fixed in the next version of the draft (which will appear before the draft deadline). RjS On Mon, 2004-01-19 at 06:05, nataraju.alilaghatta@wipro.com wrote: > =20 >=20 > =20 >=20 > Thanks & Regards, > Nataraju A.B.=20 >=20 >=20 > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Ajit > Katankot (WT01 - TELECOM & INTER-NETWORKING SOLUTIONS) > Sent: Monday, January 19, 2004 4:48 PM > To: sip@ietf.org > Cc: rsparks@dynamicsoft.com > Subject: [Sip] Comment in draft-ietf-sipping-torture-tests-02.txt >=20 > =20 >=20 > Hi, >=20 >=20 > =20 >=20 >=20 > I have a question on the parsing of the following INVITE message given > in section 3.1.1.1 of draft-ietf-sipping-torture-tests-02.txt. >=20 >=20 > =20 >=20 >=20 > In this message the contact header (m line) is extended over multiple > lines, but the extra line does not precede with at least one SP or HT. > Is this a valid Contact header ? >=20 >=20 > =20 >=20 > [ABN]this is an INVALID input, the parser should not consider this > header as an invalid header=E2=80=A6 >=20 > =20 >=20 >=20 > Section 7.3.1 in RFC 3261 mentions that:=20 >=20 >=20 > =20 >=20 >=20 > "Header fields can be extended over multiple lines by preceding > each extra line with at least one SP or horizontal tab (HT). The > line break and the whitespace at the beginning of the next line are > treated as a single SP character." >=20 >=20 > =20 >=20 >=20 > ------------------------------ >=20 >=20 > INVITE sip:vivekg@chair-dnrc.example.com;unknownparam SIP/2.0 > TO : > sip:vivekg@chair-dnrc.example.com ; tag =3D 1918181833n > from : "J Rosenberg \\\"" > ; > tag =3D 98asjd8 > MaX-fOrWaRdS: 0068 > Call-ID: 0ha0isndaksdj@192.0.2.1 > Content-Length : 151 > cseq: 0009 > INVITE > Via : SIP / 2.0 > /UDP > 192.0.2.2;branch=3D390skdjuw > s : > NewFangledHeader: newfangled value > continued newfangled value > UnknownHeaderWithUnusualValue: ;;,,;;,; > Content-Type: application/sdp > Route: > > v: SIP / 2.0 / TCP spindle.example.com ; > branch =3D z9hG4bK9ikj8 , > SIP / 2.0 / UDP 192.168.255.111 ; branch=3D > z9hG4bK30239 > m:"Quoted string \"\"" ; newparam =3D > newvalue ; > secondparam ; q =3D 0.33 >=20 >=20 > =20 >=20 >=20 > v=3D0 > o=3Dmhandley 29739 7272939 IN IP4 192.0.2.3 > s=3D- > c=3DIN IP4 192.0.2.4 > t=3D0 0 > m=3Daudio 492170 RTP/AVP 0 12 > m=3Dvideo 3227 RTP/AVP 31 > a=3Drtpmap:31 LPC >=20 >=20 > =20 >=20 >=20 > Confidentiality Notice >=20 >=20 > The information contained in this electronic message and any attachment= s 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 o= r 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 From exim@www1.ietf.org Mon Jan 19 11:13:10 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23906 for ; Mon, 19 Jan 2004 11:13:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aic13-0002Fh-LT for sip-archive@odin.ietf.org; Mon, 19 Jan 2004 11:12:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0JGCfSi008651 for sip-archive@odin.ietf.org; Mon, 19 Jan 2004 11:12:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AibzT-0002BE-AD; Mon, 19 Jan 2004 11:11:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AibzF-0002AU-9M for sip@optimus.ietf.org; Mon, 19 Jan 2004 11:10:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23596 for ; Mon, 19 Jan 2004 11:10:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aibz2-0006Wf-00 for sip@ietf.org; Mon, 19 Jan 2004 11:10:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aibv4-0006JV-00 for sip@ietf.org; Mon, 19 Jan 2004 11:06:31 -0500 Received: from imo-d02.mx.aol.com ([205.188.157.34]) by ietf-mx with esmtp (Exim 4.12) id 1AibtR-0006B7-00 for sip@ietf.org; Mon, 19 Jan 2004 11:04:49 -0500 Received: from bertculpepper@netscape.net by imo-d02.mx.aol.com (mail_out_v36_r4.12.) id c.eb.c242211 (22683); Mon, 19 Jan 2004 11:03:35 -0500 (EST) Received: from netscape.net (87.67.33.65.cfl.rr.com [65.33.67.87]) by air-in04.mx.aol.com (v97.18) with ESMTP id MAILININ44-589b400bffd616e; Mon, 19 Jan 2004 11:03:35 -0500 Message-ID: <400BFFFC.6030907@netscape.net> Date: Mon, 19 Jan 2004 11:04:12 -0500 From: Bert Culpepper User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: Paul Long , sip@ietf.org Subject: Re: [Sip] SIP DTMF References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-AOL-IP: 65.33.67.87 X-Mailer: Unknown (No Version) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA23597 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable The SIPPING work group web page on the IETF site has=20 http://www.ietf.org/internet-drafts/draft-ietf-sipping-kpml-01.txt as=20 the current draft. This version has significant differences than the=20 one quoted below, one in particular is the use of SUBSCRIBE/NOTIFY for=20 requesting and reporting key presses. Best regards, Bert Cullen Jennings wrote: > The draft is > http://www.ietf.org/internet-drafts/draft-burger-sipping-kpml-02.txt >=20 > 2833 is the preferred method, but if an off media axis device wished to= get > notification about key presses, it could. How these all relate is cover= ed in >=20 > http://www.softarmor.com/wgdb/docs/ > draft-ietf-sipping-app-interaction-framework-00.txt >=20 > Cullen >=20 >=20 > On 1/15/04 11:21 AM, "Paul Long" wrote: >=20 >=20 >>Sreeram, >> >>I can't find a "kpxml" draft on the IETF site or via Google--anywhere. >>Can you provide a link to it? >> >>Also, from my experience, the preferred method of DTMF carriage is RFC >>2833, followed by in-band audio, and then various proprietary >>INFO-method schemes. What is the standing of RFC 2833 vis-=E0-vis "kpxm= l?" >> >>Paul >> >>-----Original Message----- >>From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of >>sreeram.kanumuri@wipro.com >>Sent: Tuesday, January 13, 2004 9:06 PM >>To: xyxie@udtech.com.cn; sip@ietf.org >>Cc: sipping@ietf.org >>Subject: RE: [Sip] SIP DTMF >> >>Wendy, >> >>There was a discussion in the list some time back and it was decided >>that SIP-INFO method should not be used to >>Send the DTMF info. >> >>It was proposed that it is better to you kpxml for sending DTMF tones. >> >>Please look in to the SIP-Kpxml draft for sending DTMF tomes in-midcall >>processing and all.... >> >> >>Regards, >>Sreeram >> >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >>Sreeram Kanumuri Plot No 72, Keonics Electronics City >> Hosur Main Road >>Wipro Technologies Bangalore -29 INDIA >>sreeram.kanumuri@wipro.com Phone: 8520408 Ex:3208 >>skanumury@yahoo.com ESN : >>www.wipro.com Mobile: >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >> >> >>-----Original Message----- >>From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of wendy >>Sent: Wednesday, January 14, 2004 8:08 AM >>To: sip@ietf.org >>Cc: sipping@ietf.org >>Subject: [Sip] SIP DTMF >> >> >>Hello all,=20 >> >>Who can tell me whether there is a RFC or I-D on DTMF in SIP which is >>still not expired? I remember someone proposed using SIP INFO method fo= r >>DTMF one or two years ago. Is the DTMF relay implemented only by RTP >>now? >> >> >>Regards, >>Wendy >> >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP 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 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Jan 19 12:26:25 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28645 for ; Mon, 19 Jan 2004 12:26:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aid9y-0006ih-HH for sip-archive@odin.ietf.org; Mon, 19 Jan 2004 12:25:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0JHPwo7025771 for sip-archive@odin.ietf.org; Mon, 19 Jan 2004 12:25:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aid96-0006fs-3V; Mon, 19 Jan 2004 12:25:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aid8g-0006ep-2G for sip@optimus.ietf.org; Mon, 19 Jan 2004 12:24:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28609 for ; Mon, 19 Jan 2004 12:24:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aid8U-000638-00 for sip@ietf.org; Mon, 19 Jan 2004 12:24:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aid6J-0005zV-00 for sip@ietf.org; Mon, 19 Jan 2004 12:22:12 -0500 Received: from broadsoft.com ([198.104.184.110]) by ietf-mx with esmtp (Exim 4.12) id 1Aid3w-0005qA-00 for sip@ietf.org; Mon, 19 Jan 2004 12:19:44 -0500 Received: from tate (host4.brodsoft.com [66.160.10.4]) by broadsoft.com (8.12.10/8.12.9) with SMTP id i0JHJI5a062462 for ; Mon, 19 Jan 2004 12:19:18 -0500 (EST) Reply-To: From: "Brett Tate" To: Subject: RE: [Sip] Difference between SIP URL and SIP URI Date: Mon, 19 Jan 2004 12:21:52 -0500 Message-ID: <000e01c3deb0$bb3be1a0$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > I would like to know what is the difference > between SIP URL and SIP URI? There was a naming problem. RFC 2543 should have defined a SIP URI instead of SIP URL. It was corrected by RFC 3261. All reference to SIP URL should be references to SIP URI. The same problem exists concerning RFC 2806's definition of telephone-url. It should have been telephone-uri. It is corrected within the rfc2806bis. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Jan 19 13:47:00 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01556 for ; Mon, 19 Jan 2004 13:47:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiePw-0003PV-M7 for sip-archive@odin.ietf.org; Mon, 19 Jan 2004 13:46:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0JIkWBq013103 for sip-archive@odin.ietf.org; Mon, 19 Jan 2004 13:46:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AieOW-0003Bl-LL; Mon, 19 Jan 2004 13:45:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AieOE-00038N-NP for sip@optimus.ietf.org; Mon, 19 Jan 2004 13:44:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01372 for ; Mon, 19 Jan 2004 13:44:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AieOC-0002iV-00 for sip@ietf.org; Mon, 19 Jan 2004 13:44:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AieNL-0002dg-00 for sip@ietf.org; Mon, 19 Jan 2004 13:43:51 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AieMh-0002TF-00 for sip@ietf.org; Mon, 19 Jan 2004 13:43:11 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 19 Jan 2004 10:45:22 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id i0JIgDgP006021; Mon, 19 Jan 2004 10:42:13 -0800 (PST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFJ02242; Mon, 19 Jan 2004 13:42:11 -0500 (EST) Message-ID: <400C2503.7070804@cisco.com> Date: Mon, 19 Jan 2004 13:42:11 -0500 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: Takuya Sawada CC: slawrence@pingtel.com, ksrini@motorola.com, sip@ietf.org Subject: Re: [Sip] Registering Multiple 'Contacts' References: <4002E0B9.8030203@cisco.com> <200401160951.HGC28341.-EBBVTXUB@kddi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I agree with Takuya. Paul Takuya Sawada wrote: > Hi, > > >>Srinivasan Krishnamoorthy wrote: >> >> >>>> Section 10.2.4 of RFC3261 'Refreshing Bindings' says: >>>> "The UA then issues a REGISTER request for each of its bindings >>>>before the expiration interval has elapsed. It MAY combine several >>>>updates into one REGISTER request." >>>> The above seems to indicate that the UAC may send: (forgive the >>>>Syntax) >>>> REGISTER To: user@operator.net >>>> Contact: sip:user1@10.0.0.1;expires=3600 >>>> 200 OK >>>> REGISTER To: user@operator.net >>>> Contact: sip:user1@192.0.0.1;expires=3600 >>>> 200 OK >>>> This, according to RFC3261, will register both Contact1 and Contact2 >>>>for user@operator.net. (The server will then use the q parameter >>>> of the contact for priority among contacts) >>> >>Paul Kyzivat writes: >> >> >>>Yes. >> >>My reading is that the results should differ depending on the Call-Id >>used in those two REGISTER requests: >> >> - If they have different Call-Id values, then the server should >> register both contacts. >> >> - If they have the same Call-Id value, then the second REGISTER >> should cause the server to replace the first contact with the >> second, so that there would be only >> > > In my reading of RFC 3261 section 10.3 step 7, Contact URI will be added > to the list irrelevant to Call-ID value if its value is new to the list. > > >>If correct, this adds an additional alternative for the UA - if it can >>remember its Call-Id values across contact changes, it can make sure >>that old registrations are replaced even before they expire. >> > > If it can remember any value in the previous power-cycle, it may remember > Contact URI and then can remove it with expires=0 explicitly. > > Note that assumeing it uses the same "fixed" Call-ID across power-cycle, > it must remember "dynamic" CSeq value in old power-cycle. > > Regards, > Takuya > > >>-- >>Scott Lawrence >> Pingtel Corp. >> >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip > > > > -------- > Takuya Sawada > KDDI Corporation (KDDI) > Garden Air Tower, 3-10-10 Iidabashi Chiyoda-ku > Tokyo 102-8460, Japan > Tel: +81-3-6678-2997 > Fax: +81-3-6678-0285 > tu-sawada@kddi.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Jan 19 13:48:45 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01652 for ; Mon, 19 Jan 2004 13:48:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AieRd-0003jf-VK for sip-archive@odin.ietf.org; Mon, 19 Jan 2004 13:48:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0JImHFP014299 for sip-archive@odin.ietf.org; Mon, 19 Jan 2004 13:48:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AieQO-0003RM-P2; Mon, 19 Jan 2004 13:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AieQH-0003R1-01 for sip@optimus.ietf.org; Mon, 19 Jan 2004 13:46:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01553 for ; Mon, 19 Jan 2004 13:46:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AieQE-0002se-00 for sip@ietf.org; Mon, 19 Jan 2004 13:46:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AiePN-0002pn-00 for sip@ietf.org; Mon, 19 Jan 2004 13:45:58 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AieOx-0002kb-00 for sip@ietf.org; Mon, 19 Jan 2004 13:45:32 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0JIitGN005990; Mon, 19 Jan 2004 10:44:56 -0800 (PST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFJ02622; Mon, 19 Jan 2004 13:44:54 -0500 (EST) Message-ID: <400C25A6.9040808@cisco.com> Date: Mon, 19 Jan 2004 13:44:54 -0500 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: Takuya Sawada CC: ksrini@motorola.com, sip@ietf.org Subject: Re: [Sip] Registering Multiple 'Contacts' References: <200401161014.DJH59500.T-BEVUBBX@kddi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Takuya Sawada wrote: > Hi, > >>>>How will the Server prevent against mis-behaved clients in this case? >>> >>>The expiration time bounds the problem, but doesn't eliminate it. >>>Assume the UAC power cycles, forgets its old address, gets a new one and registers it. It will then >> > presumably continue to refresh the new address, but not the old one. So the old registration will continue > to be active until it expires. During that time requests will probably be forked to it and the new address, > but the ones to the old address will fail. > >>>Paul >> >>Another case I could think of is a DHCP environment - where a mobile-ua gets >>different ipaddresses on every power-cycle. >> >>In this case we may have to make sure the DHCP lease timers are longer than >>registration duration in the network - or else we could be terminating >>a call to an old-IP - that has possibly been granted to another UA that >>registered in the interim??? >> > > I think that SIP UA which use dynamic IP address SHOULD obey the behaviour > described above. > Keep DHCP lease timer > SIP registration timer. (any timer used in app level) I think I would go further and say the UA which uses addresses like this MUST do so. If the UA only has temporary ownership of the address, then it has no business registering it for a time period when it may not own it. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Jan 19 14:21:58 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03207 for ; Mon, 19 Jan 2004 14:21:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aiexl-00060d-DM for sip-archive@odin.ietf.org; Mon, 19 Jan 2004 14:21:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0JJLTXs023038 for sip-archive@odin.ietf.org; Mon, 19 Jan 2004 14:21:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiewP-0005qN-9G; Mon, 19 Jan 2004 14:20:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aiew8-0005pQ-VY for sip@optimus.ietf.org; Mon, 19 Jan 2004 14:19:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03128 for ; Mon, 19 Jan 2004 14:19:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aiew1-0005Vb-00 for sip@ietf.org; Mon, 19 Jan 2004 14:19:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AiesS-0005Cw-00 for sip@ietf.org; Mon, 19 Jan 2004 14:16:00 -0500 Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx with esmtp (Exim 4.12) id 1Aieoq-0004th-00 for sip@ietf.org; Mon, 19 Jan 2004 14:12:16 -0500 Received: from localhost (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (8.11.6/8.11.6) with ESMTP id i0JJB9J31667; Mon, 19 Jan 2004 14:11:10 -0500 Subject: Re: [Sip] Registering Multiple 'Contacts' From: Scott Lawrence To: Paul Kyzivat Cc: Takuya Sawada , ksrini@motorola.com, sip@ietf.org In-Reply-To: <400C2503.7070804@cisco.com> References: <4002E0B9.8030203@cisco.com> <200401160951.HGC28341.-EBBVTXUB@kddi.com> <400C2503.7070804@cisco.com> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Message-Id: <1074539469.5662.3.camel@sukothai.pingtel.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 19 Jan 2004 14:11:09 -0500 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Mon, 2004-01-19 at 13:42, Paul Kyzivat wrote: > I agree with Takuya. > Takuya Sawada wrote: > > If it can remember any value in the previous power-cycle, it may remember > > Contact URI and then can remove it with expires=0 explicitly. > > > > Note that assumeing it uses the same "fixed" Call-ID across power-cycle, > > it must remember "dynamic" CSeq value in old power-cycle. I agree with this as well; my point was actually that the correct thing for the registry in the original inquiry could not actually be determined based on the messages given, because they did not include the Call-Id and Cseq values. Whether or not registrations should be dependant on these values, and what the right strategy is for a user agent are interesting quesitons too. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Jan 19 15:17:37 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06433 for ; Mon, 19 Jan 2004 15:17:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aifpb-0002DQ-Gx for sip-archive@odin.ietf.org; Mon, 19 Jan 2004 15:17:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0JKH7E2008510 for sip-archive@odin.ietf.org; Mon, 19 Jan 2004 15:17:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AifpX-0002AD-6A; Mon, 19 Jan 2004 15:17:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AifpM-00026S-1L for sip@optimus.ietf.org; Mon, 19 Jan 2004 15:16:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06332 for ; Mon, 19 Jan 2004 15:16:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AifpK-000289-00 for sip@ietf.org; Mon, 19 Jan 2004 15:16:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AifoS-00023h-00 for sip@ietf.org; Mon, 19 Jan 2004 15:15:56 -0500 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1AifnU-0001uW-00 for sip@ietf.org; Mon, 19 Jan 2004 15:14:56 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i0JKE0dt028798; Mon, 19 Jan 2004 14:14:00 -0600 (CST) Message-ID: <400C3A87.96D11493@alcatel.com> Date: Mon, 19 Jan 2004 14:13:59 -0600 From: Alex Audu Reply-To: alex.audu@alcatel.com X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rohan Mahy CC: sip@ietf.org, Dean Willis , Henning Schulzrinne , "James M. Polk" Subject: Re: [Sip] re: WGLC: resource priority References: <2B1A3BDE-3BDA-11D8-A0DC-0003938AF740@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, The questions I had while reading this draft were mostly along the points Rohan has listed. There were attempts to describe behavior (section 4.5 User Agent Client Behavior, 4.6 User Agent Server Behavior, and 4.6 Proxy Behavior), but these sections were very silent regarding what actions these elements would take to prevent or ease congestion based on assigned priority values. Another issue that needs to be addressed is: what should be the behavior of these devices to ensure low priority events/requests don't get starved out of processing resources? I was also a bit confused by the fact that you seemed to be addressing authorization issues within priority specifications (section 4.3, and 4.6 and 5.0 for example). I think it will be better to decouple authorization issues from this document and leave such issues to drafts devoted to authorzation. Besides, authorization processing should have passed before prioritization. Lastly, is 417 (Unknown Resource-Priority) a new error code? I assume it is since it is not in rfc 3261. If so, can we make the name more generic,..like Unknown Value (or Parameter)? This will aid re-use of this code, instead of it being limited to priority handling alone. Regards, Alex. Rohan Mahy wrote: > Hi, > > Below is my review of resource-priority. Detailed comments are below, but I have a few general ones: > > 1. There is no normative description of the behavior of SIP devices which receive a particular priority value. Some specifications needs to either specify detailed behavior for specific priority values, or the detailed semantics of those values. I think this belongs in the IANA registration of each namespace, but those references are currently very thin. I made some specific comments to this end in the appropriate sections. > > 2. Also, I am curious what the semantics of this header mean in the context of SUB/NOT. Can someone provide an example that makes sense? > > 3. Finally, the document shows that proxies can modify, insert, and delete the RP header. I don't think this is a good idea. Where cooperating UAs and proxies need to agree on an RP value, I believe the session policy mechanism can be used. A proxy can reject the message for policy reasons (use a lower/higher/specific resource-value) and the UA can retry the request with these new values. > > thanks, > -rohan > > -------------- > > detailed comments: > > put TOC at the beginning > > section 2 > > suggest > ..telephone circuits, IP bandwidth ^reservations or allocations^... > > remove or motivate references to presence > > section 3: > > " Implementations MAY change the value offered in the request; in some > environments, the response value is known to be the same as in the > request." ??? what does that mean ??? > > BNF is wrong (your current syntax would require a leading comma). do this instead: > > Resource-Priority = "Resource-Priority" HCOLON Resource-value > > Accept-Resource-Priority = "Accept-Resource-Priority" HCOLON > [Resource-value *(COMMA Resource-value)] > > check consolidated bnf for reuse of terms > > also, the case of Resource-value is highly unusual. > > reword this, it is awkward: > > " We require that even namespaces with only one priority > value list that value to avoid problems if additional > priority values are added later." > > There may be multiple resource values or, equivalently, multiple > Resource-Priority header /fields/field values/. > > what does it mean to "support" a particular Resource-value? > > our current method list is: > INV ACK CAN BYE REG OPT PRA > SUB NOT UPD MSG REF INF PUB > > what does RP mean in a SUB or NOT? > > where is section 4.2? > > section 4.3 > > add comma here please... > Elements receiving > requests with namespaces or priority values that they do not > understand ^,^ act according to the rules in the next section. > > section 4.4: you should introduce the resource-priority option tag (just the tag) back in section 3 > > section 4.7: i don't think a proxy should be able to insert, delete, or modify the RP header. This makes it impossible to use e2e on the RP headers, which I think will be required. > > section 9-12: > > option-tags are always lowercase by convention > > you should add a note to the RFC editor asking for RFCXXXX to be replaced with the RFC number of this document. > > please make section 9 be IANA considerations (start with the text in section 12), then under this, create section 9.1 (formerly section 9) to register the new headers, section 9.2 (formerly section 10) to register the resource-priority header, section 11 becomes 9.3. > > include a registration template (for example) > > Namespace: > Description: > Organization Responsible for Change Control of this Namespace: > Priority values (ordered from least priority to greatest priority): > Default priority: > Preempt or Prioritize: > Document Containing Normative Description: > Section Containing Normative Description: > Additional security requirements: > > I would also consider including Section B.1 as section 9.4, B.2 -> 9.5, B.3 -> 9.6 > (IANA will be happy if all the work they have to do is consolidated under a single 1st-level section heading). > > in any case for the initial registrations, please fill in the template for each one; for example: > > Namespace: q735 > Description: ITU Q.735.3 Multi-level precedence and preemption in SS7 > Organization Responsible for Change Control of this Namespace: ITU-T > Priority values (ordered from least priority to greatest priority): 4, 3, 2, 1, 0 > Default priority: 4 > Preempt or Prioritize: prioritize > Document Containing Normative Description: ITU-T Q.735.3 [3] > Section Containing Normative Description: ?? > Additional security requirements: none > > Namespace: dsrn > Description: United States Defense Red Switched Network > Organization Responsible for Change Control of this Namespace: US Department of Defense? > Priority values (ordered from least priority to greatest priority): > routine, priority, immediate, flash, flash-override, flash-override-override > Default priority: routine > Preempt or Prioritize: preempt > Document Containing Normative Description: FIPS XXXX ?? [?] > Section Containing Normative Description: ?? > Additional security requirements: All implementations must follow the certificate management guidelines specified in xxxx [?] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Jan 20 06:02:46 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24374 for ; Tue, 20 Jan 2004 06:02:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiteE-0004um-Or for sip-archive@odin.ietf.org; Tue, 20 Jan 2004 06:02:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0KB2I3t018888 for sip-archive@odin.ietf.org; Tue, 20 Jan 2004 06:02:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aitdz-0004u6-4Q; Tue, 20 Jan 2004 06:02:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AitdF-0004tf-Mi for sip@optimus.ietf.org; Tue, 20 Jan 2004 06:01:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24365 for ; Tue, 20 Jan 2004 06:01:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AitdC-0007lL-00 for sip@ietf.org; Tue, 20 Jan 2004 06:01:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AitcH-0007jN-00 for sip@ietf.org; Tue, 20 Jan 2004 06:00:18 -0500 Received: from gw.softfront.co.jp ([202.232.222.2] helo=mail2.softfront.co.jp) by ietf-mx with smtp (Exim 4.12) id 1AitbM-0007gX-00 for sip@ietf.org; Tue, 20 Jan 2004 05:59:20 -0500 Received: from wstar by mail2.softfront.co.jp id AA03088 ; 20 Jan 2004 19:59:15 +0900 Date: Tue, 20 Jan 2004 19:59:15 +0900 From: OKUMURA Shinji Subject: Re: [Sip] WGLC for PUBLISH To: aki.niemi@nokia.com Cc: Organization: SOFTFRONT In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D92C9@esebe013.ntc.nokia.com> References: <200401151049.AA03044@mail2.softfront.co.jp> <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D92C9@esebe013.ntc.nokia.com> X-Mailer: Datula version 1.50.45 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Message-Id: <200401201059.AA03088@mail2.softfront.co.jp> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi Aki, Thank you for your comments. You say that R-uri is used to determine what resource the PUBLISH is targeted for. But R-uri has the possibility to be rewritten by proxy. Even if PUA sends "sip:presentity@example.com", "sip:presentity@pa.example.com" may reach to PA. Now my questions are: a) PUBLISH message MUST NOT pass proxy? b) proxy MUST NOT rewrite R-uri? b-1. the uri MUST NOT be registered? b-2. Register-Contact is ? b-3. original message has Route: ? c) PA MUST determine the target resource ONLY by username of R-uri? Best regards, Shinji aki.niemi@nokia.com wrote in <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D92C9@esebe013.ntc.nokia.com> >Hi Shinji, > >Thanks for the comments. Answers inline. > > > -----Original Message----- > > From: ext OKUMURA Shinji [mailto:shin@softfront.co.jp] > > Sent: 15 January, 2004 12:49 > > To: Rohan Mahy > > Cc: sip@ietf.org; Dean Willis; Niemi Aki (Nokia-M/Helsinki) > > Subject: Re: [Sip] WGLC for PUBLISH > > > > > > Hi, > > > > [1] I believe it requires following changes in some headers of > > the illustrated example in section 12. > > > > In M1, Contact: should be > > rewritten as > > Contact: > > > > > > In M2, Contact: should be > > Contact: > > > > In M3, NOTIFY sip:presentity@example.com SIP/2.0 > > Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK8sdf2 > > To: ;tag=12341234 > > From: ;tag=abcd1234 > > Call-ID: 12345678@10.0.0.1 > > CSeq: 1 NOTIFY > > .... > > > > should be > > > > NOTIFY sip:watcher@10.0.0.1 SIP/2.0 > > Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK8sdf2 > > To: ;tag=12341234 > > From: ;tag=abcd1234 > > Call-ID: 12345678@10.0.0.1 > > CSeq: 1 NOTIFY > > Contact: > > .... > >All true. Also, since the Via contains a domain name, I will add a "received" >param to the Via in the response. > >It's very good that you pointed out these mistakes in the examples. I swear, >I've looked at them a few times before, but I guess my internal SIP parser is >so well built that it never gave me an error message. ;-) > >I'll fix these for the next revision. > > > [2] It could be helpful if the following example (2) is added in > > the document as an addition to the only example (1) illustrated > > in section 12. > >I'm a little reluctant to adding this. There are excellent SIP call flows >already documented elsewhere (see RFC 3665, e.g., Section 3.2), and to this >particular method, adding a proxy in between the PUA and the PA works no >different from how this works for other methods (MESSAGE, INVITE). I.e., the >proxy rewriting the Request-URI follows the same logic as the other methods >would. > >However, since this issue has come up before, it might be a good idea to add a >proxy between the PUA and PA. Any other views on this? > > > (1) PUA <---> PA <---> WATCHER > > > > (2) PUA <---> proxy <---> PA > > > > For example: > > > > PUA <-----> proxy <------> PA > > | | | > > | M1 PUBLISH | | > > |----------->| M2 PUBLISH | > > | |----------->| > > | | M3 200 OK | > > | M4 200 OK |<-----------| > > |<-----------| | > > > > M1: > > PUBLISH sip:pa@example.com SIP/2.0 > > Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge > > From: ;tag=1234wxyz > > To: > > Call-ID: 81818181@pua.example.com > > CSeq: 1 PUBLISH > > Max-Forwards: 70 > > Expires: 3600 > > Event: presence > > Content-Type: application/pidf+xml > > Content-Length: ... > >Note that the Request-URI needs to be 'sip:presentity@example.com'. PUBLISH is >specifically addressed to the resource, not the presence agent. > > > M2: > > PUBLISH sip:pa.example.com SIP/2.0 > > Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKpx123 > > Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge > > From: ;tag=1234wxyz > > To: > > Call-ID: 81818181@pua.example.com > > CSeq: 1 PUBLISH > > Max-Forwards: 70 > > Expires: 3600 > > Event: presence > > Content-Type: application/pidf+xml > > Content-Length: ... > >The proxy would rewrite the Request-URI, but probably to something like >'sip:presentity@pa.example.com'. Note that when the request is received by the >PA/ESC, it specifically uses the Request-URI to determine what resource the >PUBLISH is targeted for. This is identical to a SUBSCRIBE. > > > M3: > > SIP/2.0 200 OK > > Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKpx123 > > Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge > > From: ;tag=1234wxyz > > To: ;tag=1a2b3c4d > > Call-ID: 81818181@pua.example.com > > CSeq: 1 PUBLISH > > SIP-ETag: dx200xyz > > Expires: 1800 > > Content-Length: 0 > > > > M4: > > SIP/2.0 200 OK > > Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge > > From: ;tag=1234wxyz > > To: ;tag=1a2b3c4d > > Call-ID: 81818181@pua.example.com > > CSeq: 1 PUBLISH > > SIP-ETag: dx200xyz > > Expires: 1800 > > Content-Length: 0 > > > > [3] It could be better if the "Request-URI" is used as the message's > > target address and the 'Presence Resource' is specified > > using "To" > > header. > > > > It would be easy for understanding if REGISTER's location > > registration operation like mechanism is considered. > >This is actually how PUBLISH used to work. But having the Request-URI point to >a PA requires special handling from the proxies and/or a specific naming >convention for PAs to be able to route the request. So we decided to reject the >REGISTER-like operation (determining the resource by the To-field) in favor of >the SUBSCRIBE-like behavior the draft currently has. > > > > > The same point could also be said about RFC3265. This is because, > > > > |3.1.5. Proxy SUBSCRIBE Behavior > > | Proxies need no additional behavior beyond that > > described in SIP [1] > > | to support SUBSCRIBE. > > > > [4] For expressing 'Presence Resource', the > > pres-URI(draft-ietf-impp-pres-04) > > would be better than that of the sip-URI. > > > > Finally, when [3] & [4] are considered together, the > > various usages > > of URI can be expressed as listed below. > > > > +------------+-----------------------------+----------------- > > ------------+-----------------------------+ > > | | PUBLISH | SUBSCRIBE > > | NOTIFY | > > +------------+-----------------------------+----------------- > > ------------+-----------------------------+ > > |Request-URI | URI of PA | URI of PA > > | Contact-URI of SUBSCRIBE | > > | | sip:pa@example.com | > > sip:pa@example.com | sip:watcher.example.com | > > +------------+-----------------------------+----------------- > > ------------+-----------------------------+ > > |To-URI | URI of presence resource | URI of presence > > resource | From-URI of SUBSCRIBE | > > | | pres:presentity@example.com | > > pres:presentity@example.com | sip:watcher@example.com | > > +------------+-----------------------------+----------------- > > ------------+-----------------------------+ > > |From-URI | URI of presentity | URI of watcher > > | To-URI of SUBSCRIBE | > > | | sip:presentity@example.com | > > sip:watcher@example.com | pres:presentity@example.com | > > +------------+-----------------------------+----------------- > > ------------+-----------------------------+ > >Adding to my previous comments, how would the UA find out the address of a PA >that services the presentity? We can't mandate a specific naming convention for >PAs in general, which is why the Request-URI is always the address of the >subscribed/published resource. > >Note that one valid location for a PA is in the client device. Because of the >way PUBLISH and SUBSCRIBE currently work, this requires nothing special from a >proxy - it simply forwards/redirects these requests to the UA like any other >request for that AoR. > >Cheers, >Aki > > > > > Regards, > > shinji > > > > Rohan Mahy wrote in > > >Hi, > > > > > >I'd like to begin Working Group Last Call for PUBLISH: > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-sip-publish-02.txt > > > > > >This WGLC will end on January 28, 2004. > > > > > >thanks, > > >-rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Jan 20 09:04:01 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29974 for ; Tue, 20 Jan 2004 09:04:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiwTb-00068X-Dc for sip-archive@odin.ietf.org; Tue, 20 Jan 2004 09:03:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0KE3V25023588 for sip-archive@odin.ietf.org; Tue, 20 Jan 2004 09:03:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiwT7-00061w-Uh; Tue, 20 Jan 2004 09:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiwSd-0005xY-Hk for sip@optimus.ietf.org; Tue, 20 Jan 2004 09:02:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29941 for ; Tue, 20 Jan 2004 09:02:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiwSc-0001D9-00 for sip@ietf.org; Tue, 20 Jan 2004 09:02:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AiwRk-0001A0-00 for sip@ietf.org; Tue, 20 Jan 2004 09:01:37 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AiwR6-00016A-00 for sip@ietf.org; Tue, 20 Jan 2004 09:00:56 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0KE0sY04097 for ; Tue, 20 Jan 2004 16:00:55 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 20 Jan 2004 16:00:54 +0200 Received: from nokia.com ([172.21.98.221]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 20 Jan 2004 16:00:53 +0200 Message-ID: <400D3495.5010109@nokia.com> Date: Tue, 20 Jan 2004 16:00:53 +0200 From: "Niemi Aki (Nokia-M/Helsinki)" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext OKUMURA Shinji CC: sip@ietf.org Subject: Re: [Sip] WGLC for PUBLISH References: <200401151049.AA03044@mail2.softfront.co.jp> <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D92C9@esebe013.ntc.nokia.com> <200401201059.AA03088@mail2.softfront.co.jp> In-Reply-To: <200401201059.AA03088@mail2.softfront.co.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jan 2004 14:00:53.0899 (UTC) FILETIME=[D1A945B0:01C3DF5D] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Shinji, The key thing here is that there is nothing special about how a proxy determines the next hop target for PUBLISH requests. There are several options to doing this: - A domain has configured all PUBLISH requests to be forwarded to a PA - A PA has explicitly added an address binding for that AOR, possibly using the SIP registration - All requests get forwarded to a UA (no matter what the method is) that has an active address binding in the domain's location service for that AoR - The request gets targeted using some other, undefined logic The administrator for that domain just needs to pick a way of doing this. So when proxying a PUBLISH request, Section 16 in RFC 3261 applies in full. Cheers, Aki ext OKUMURA Shinji wrote: > Hi Aki, > > Thank you for your comments. > > You say that R-uri is used to determine what resource the PUBLISH is > targeted for. But R-uri has the possibility to be rewritten by proxy. > > > Even if PUA sends "sip:presentity@example.com", > "sip:presentity@pa.example.com" may reach to PA. > > Now my questions are: > > a) PUBLISH message MUST NOT pass proxy? > > b) proxy MUST NOT rewrite R-uri? > > b-1. the uri MUST NOT be registered? b-2. Register-Contact is > ? b-3. original > message has Route: ? > > c) PA MUST determine the target resource ONLY by username of R-uri? > > Best regards, > > > Shinji > > aki.niemi@nokia.com wrote in > <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D92C9@esebe013.ntc.nokia.com> > >> Hi Shinji, >> >> Thanks for the comments. Answers inline. >> >> >>> -----Original Message----- From: ext OKUMURA Shinji >>> [mailto:shin@softfront.co.jp] Sent: 15 January, 2004 12:49 To: >>> Rohan Mahy Cc: sip@ietf.org; Dean Willis; Niemi Aki >>> (Nokia-M/Helsinki) Subject: Re: [Sip] WGLC for PUBLISH >>> >>> >>> Hi, >>> >>> [1] I believe it requires following changes in some headers of >>> the illustrated example in section 12. >>> >>> In M1, Contact: should be rewritten >>> as Contact: >>> >>> >>> In M2, Contact: should be Contact: >>> >>> >>> In M3, NOTIFY sip:presentity@example.com SIP/2.0 Via: >>> SIP/2.0/UDP pa.example.com;branch=z9hG4bK8sdf2 To: >>> ;tag=12341234 From: >>> ;tag=abcd1234 Call-ID: >>> 12345678@10.0.0.1 CSeq: 1 NOTIFY .... >>> >>> should be >>> >>> NOTIFY sip:watcher@10.0.0.1 SIP/2.0 Via: SIP/2.0/UDP >>> pa.example.com;branch=z9hG4bK8sdf2 To: >>> ;tag=12341234 From: >>> ;tag=abcd1234 Call-ID: >>> 12345678@10.0.0.1 CSeq: 1 NOTIFY Contact: >>> .... >> >> All true. Also, since the Via contains a domain name, I will add a >> "received" param to the Via in the response. >> >> It's very good that you pointed out these mistakes in the examples. >> I swear, I've looked at them a few times before, but I guess my >> internal SIP parser is so well built that it never gave me an error >> message. ;-) >> >> I'll fix these for the next revision. >> >> >>> [2] It could be helpful if the following example (2) is added in >>> the document as an addition to the only example (1) illustrated >>> in section 12. >> >> I'm a little reluctant to adding this. There are excellent SIP call >> flows already documented elsewhere (see RFC 3665, e.g., Section >> 3.2), and to this particular method, adding a proxy in between the >> PUA and the PA works no different from how this works for other >> methods (MESSAGE, INVITE). I.e., the proxy rewriting the >> Request-URI follows the same logic as the other methods would. >> >> However, since this issue has come up before, it might be a good >> idea to add a proxy between the PUA and PA. Any other views on >> this? >> >> >>> (1) PUA <---> PA <---> WATCHER >>> >>> (2) PUA <---> proxy <---> PA >>> >>> For example: >>> >>> PUA <-----> proxy <------> PA | | | | M1 >>> PUBLISH | | |----------->| M2 PUBLISH | | >>> |----------->| | | M3 200 OK | | M4 200 OK >>> |<-----------| |<-----------| | >>> >>> M1: PUBLISH sip:pa@example.com SIP/2.0 Via: SIP/2.0/UDP >>> pua.example.com;branch=z9hG4bK652hsge From: >>> ;tag=1234wxyz To: >>> Call-ID: 81818181@pua.example.com >>> CSeq: 1 PUBLISH Max-Forwards: 70 Expires: 3600 Event: presence >>> Content-Type: application/pidf+xml Content-Length: ... >> >> Note that the Request-URI needs to be 'sip:presentity@example.com'. >> PUBLISH is specifically addressed to the resource, not the presence >> agent. >> >> >>> M2: PUBLISH sip:pa.example.com SIP/2.0 Via: SIP/2.0/UDP >>> proxy.example.com;branch=z9hG4bKpx123 Via: SIP/2.0/UDP >>> pua.example.com;branch=z9hG4bK652hsge From: >>> ;tag=1234wxyz To: >>> Call-ID: 81818181@pua.example.com >>> CSeq: 1 PUBLISH Max-Forwards: 70 Expires: 3600 Event: presence >>> Content-Type: application/pidf+xml Content-Length: ... >> >> The proxy would rewrite the Request-URI, but probably to something >> like 'sip:presentity@pa.example.com'. Note that when the request is >> received by the PA/ESC, it specifically uses the Request-URI to >> determine what resource the PUBLISH is targeted for. This is >> identical to a SUBSCRIBE. >> >> >>> M3: SIP/2.0 200 OK Via: SIP/2.0/UDP >>> proxy.example.com;branch=z9hG4bKpx123 Via: SIP/2.0/UDP >>> pua.example.com;branch=z9hG4bK652hsge From: >>> ;tag=1234wxyz To: >>> ;tag=1a2b3c4d Call-ID: >>> 81818181@pua.example.com CSeq: 1 PUBLISH SIP-ETag: dx200xyz >>> Expires: 1800 Content-Length: 0 >>> >>> M4: SIP/2.0 200 OK Via: SIP/2.0/UDP >>> pua.example.com;branch=z9hG4bK652hsge From: >>> ;tag=1234wxyz To: >>> ;tag=1a2b3c4d Call-ID: >>> 81818181@pua.example.com CSeq: 1 PUBLISH SIP-ETag: dx200xyz >>> Expires: 1800 Content-Length: 0 >>> >>> [3] It could be better if the "Request-URI" is used as the >>> message's target address and the 'Presence Resource' is specified >>> using "To" header. >>> >>> It would be easy for understanding if REGISTER's location >>> registration operation like mechanism is considered. >> >> This is actually how PUBLISH used to work. But having the >> Request-URI point to a PA requires special handling from the >> proxies and/or a specific naming convention for PAs to be able to >> route the request. So we decided to reject the REGISTER-like >> operation (determining the resource by the To-field) in favor of >> the SUBSCRIBE-like behavior the draft currently has. >> >> >>> The same point could also be said about RFC3265. This is because, >>> >>> >>> |3.1.5. Proxy SUBSCRIBE Behavior | Proxies need no additional >>> behavior beyond that described in SIP [1] | to support >>> SUBSCRIBE. >>> >>> [4] For expressing 'Presence Resource', the >>> pres-URI(draft-ietf-impp-pres-04) would be better than that of >>> the sip-URI. >>> >>> Finally, when [3] & [4] are considered together, the various >>> usages of URI can be expressed as listed below. >>> >>> +------------+-----------------------------+----------------- >>> ------------+-----------------------------+ | | >>> PUBLISH | SUBSCRIBE | NOTIFY >>> | +------------+-----------------------------+----------------- >>> ------------+-----------------------------+ |Request-URI | URI of >>> PA | URI of PA | Contact-URI of SUBSCRIBE | >>> | | sip:pa@example.com | sip:pa@example.com >>> | sip:watcher.example.com | >>> +------------+-----------------------------+----------------- >>> ------------+-----------------------------+ |To-URI | URI of >>> presence resource | URI of presence resource | From-URI of >>> SUBSCRIBE | | | pres:presentity@example.com | >>> pres:presentity@example.com | sip:watcher@example.com | >>> +------------+-----------------------------+----------------- >>> ------------+-----------------------------+ |From-URI | URI of >>> presentity | URI of watcher | To-URI of SUBSCRIBE >>> | | | sip:presentity@example.com | >>> sip:watcher@example.com | pres:presentity@example.com | >>> +------------+-----------------------------+----------------- >>> ------------+-----------------------------+ >> >> Adding to my previous comments, how would the UA find out the >> address of a PA that services the presentity? We can't mandate a >> specific naming convention for PAs in general, which is why the >> Request-URI is always the address of the subscribed/published >> resource. >> >> Note that one valid location for a PA is in the client device. >> Because of the way PUBLISH and SUBSCRIBE currently work, this >> requires nothing special from a proxy - it simply >> forwards/redirects these requests to the UA like any other request >> for that AoR. >> >> Cheers, Aki >> >> >>> Regards, shinji >>> >>> Rohan Mahy wrote in >>> >>> >>>> Hi, >>>> >>>> I'd like to begin Working Group Last Call for PUBLISH: >>>> >>>> >>> >>> http://www.ietf.org/internet-drafts/draft-ietf-sip-publish-02.txt >>> >>> >>>> This WGLC will end on January 28, 2004. >>>> >>>> thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Jan 20 09:04:35 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00042 for ; Tue, 20 Jan 2004 09:04:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiwU8-0006BC-DI for sip-archive@odin.ietf.org; Tue, 20 Jan 2004 09:04:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0KE44Xq023731 for sip-archive@odin.ietf.org; Tue, 20 Jan 2004 09:04:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiwU5-0006AG-Ew; Tue, 20 Jan 2004 09:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiY51-0005Ur-Dx for sip@optimus.ietf.org; Mon, 19 Jan 2004 07:00:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13676 for ; Mon, 19 Jan 2004 07:00:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiY4x-0007Up-00 for sip@ietf.org; Mon, 19 Jan 2004 07:00:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AiY42-0007Rk-00 for sip@ietf.org; Mon, 19 Jan 2004 06:59:30 -0500 Received: from [207.44.196.29] (helo=bharatmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AiY3L-0007PV-00 for sip@ietf.org; Mon, 19 Jan 2004 06:58:47 -0500 Received: (from apache@localhost) by bharatmail.com (8.11.6/8.11.6) id i0JFF9Y14856; Mon, 19 Jan 2004 09:15:09 -0600 Message-Id: <200401191515.i0JFF9Y14856@bharatmail.com> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.411 (Entity 5.404) From: murali To: sip@ietf.org Date: Mon Jan 19 17:26:39 2004 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=DATE_IN_PAST_06_12 autolearn=no version=2.60 Content-Transfer-Encoding: binary Subject: [Sip] Who Should Initiate Re-invite?? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: binary Hi, I have a question regarding the SDP negotiation. Consider the following scenario, INVITE(w/o SDP) --------------------> 100 trying <-------------------- 180 Ringing <-------------------- 200(with SDP, a=inactive) <-------------------- Ack(with SDP) --------------------> As a=inactive has been used in SDP the RTP session is not established. As RFC 2327 does not take care of a=inactive, some older implementations respond with one codec in ACK with sendrecv mode(default). 1. In this scenario, who should initiate Re- Invite? 2. What if both parties do not initiate a Re-invite? 3. What if both parties initiate a Re-invite? 4. When does the call gets terminated? 5. Does this have some interop issues(between 3264,2327 implementations)? Thanks & Rgds, Murali ------- _____________________________________________________________ Get Your Free ScanMail and Email At http://mail.ttkbharatplanet.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Jan 20 09:58:45 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01848 for ; Tue, 20 Jan 2004 09:58:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AixKb-0001PB-Te for sip-archive@odin.ietf.org; Tue, 20 Jan 2004 09:58:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0KEwHxI005395 for sip-archive@odin.ietf.org; Tue, 20 Jan 2004 09:58:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AixKL-0001NK-QV; Tue, 20 Jan 2004 09:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AixJw-0001Ll-Pj for sip@optimus.ietf.org; Tue, 20 Jan 2004 09:57:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01732 for ; Tue, 20 Jan 2004 09:57:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AixJu-0003vs-00 for sip@ietf.org; Tue, 20 Jan 2004 09:57:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AixIQ-0003oK-00 for sip@ietf.org; Tue, 20 Jan 2004 09:56:02 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AixFi-0003ca-00 for sip@ietf.org; Tue, 20 Jan 2004 09:53:14 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i0KEqAVM001983; Tue, 20 Jan 2004 06:52:11 -0800 (PST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFJ62437; Tue, 20 Jan 2004 09:52:09 -0500 (EST) Message-ID: <400D4099.208@cisco.com> Date: Tue, 20 Jan 2004 09:52:09 -0500 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: murali CC: sip@ietf.org Subject: Re: [Sip] Who Should Initiate Re-invite?? References: <200401191515.i0JFF9Y14856@bharatmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit murali wrote: > Hi, > > I have a question regarding the SDP negotiation. > Consider the following scenario, > > INVITE(w/o SDP) > --------------------> > 100 trying > <-------------------- > 180 Ringing > <-------------------- > 200(with SDP, a=inactive) > <-------------------- > Ack(with SDP) > --------------------> > > As a=inactive has been used in SDP the RTP session is not established. What do you mean by "not established"? There should be valid ports, though no packets should be flowing. And RTCP should be flowing between them. > As RFC 2327 does not take care of a=inactive, some older implementations > respond with one codec in ACK with sendrecv mode(default). Yes, the issue of backward compatibility hasn't been well addressed. Presumably we should expect the party sending the a=inactive to be prepared for a peer that doesn't understand and do the right thing. In this case, in addition to returning sendrecv, the caller will most likely begin to send media. The callee had better be prepared to deal with that. > 1. In this scenario, who should initiate Re- Invite? You can't expect much from the caller since it is a now obsolete device. If you are going to impose new requirements on it, the first one should be to support a=inactive. It isn't clear that a reinvite is required in this case. The caller is happy, and the callee is presumably dealing with the incoming audio it doesn't want. But if it wants to stop that, it could send a reinvite with c=0.0.0.0 to kill the audio. > 2. What if both parties do not initiate > a Re-invite? See above. > 3. What if both parties initiate a Re-invite? If they happen concurrently, then it is a glare condition, and is covered by 3261. If they don't happen concurrently there is no problem - they both get acted upon. > 4. When does the call gets terminated? When somebody sends a BYE. > 5. Does this have some interop issues(between 3264,2327 implementations)? Yes, clearly there are some backward compatibility issues. This has been discussed somewhat. If you use a=sendonly, recvonly, or inactive, you probably ought to be prepared for the other party not understanding. If it doesn't return a corresponding a-line in accord with the rules in 3264 then you should probably conclude it doesn't understand and act accordingly. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Jan 20 23:04:49 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09273 for ; Tue, 20 Jan 2004 23:04:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj9bI-00064l-0b for sip-archive@odin.ietf.org; Tue, 20 Jan 2004 23:04:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0L44JIF023294 for sip-archive@odin.ietf.org; Tue, 20 Jan 2004 23:04:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj9b0-00061P-4X; Tue, 20 Jan 2004 23:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj9an-00060h-5u for sip@optimus.ietf.org; Tue, 20 Jan 2004 23:03:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09250 for ; Tue, 20 Jan 2004 23:03:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aj9aj-0003nA-00 for sip@ietf.org; Tue, 20 Jan 2004 23:03:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aj9Zk-0003kx-00 for sip@ietf.org; Tue, 20 Jan 2004 23:02:45 -0500 Received: from gw.softfront.co.jp ([202.232.222.2] helo=mail2.softfront.co.jp) by ietf-mx with smtp (Exim 4.12) id 1Aj9Yz-0003j2-00 for sip@ietf.org; Tue, 20 Jan 2004 23:01:57 -0500 Received: from wstar by mail2.softfront.co.jp id AA03488 ; 21 Jan 2004 13:01:53 +0900 Date: Wed, 21 Jan 2004 13:01:53 +0900 From: OKUMURA Shinji Subject: Re: [Sip] WGLC for PUBLISH To: "Niemi Aki (Nokia-M/Helsinki)" Cc: sip@ietf.org Organization: SOFTFRONT In-Reply-To: <400D3495.5010109@nokia.com> References: <200401151049.AA03044@mail2.softfront.co.jp> <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D92C9@esebe013.ntc.nokia.com> <200401201059.AA03088@mail2.softfront.co.jp> <400D3495.5010109@nokia.com> X-Mailer: Datula version 1.50.45 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Message-Id: <200401210401.AA03488@mail2.softfront.co.jp> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi Aki, Thank you for your quick response. Now I understand. The important point I think is that PA determines the target resource using the r-uri of PUBLISH message "received by PA". In other words, the r-uri sending by PUA and the one received by PA need not to be same. Am I right or missing something? Cheers, Shinji >Hi Shinji, > >The key thing here is that there is nothing special about how a proxy >determines the next hop target for PUBLISH requests. There are several >options to doing this: > > - A domain has configured all PUBLISH requests to be > forwarded to a PA > - A PA has explicitly added an address binding for that > AOR, possibly using the SIP registration > - All requests get forwarded to a UA (no matter what the > method is) that has an active address binding in the > domain's location service for that AoR > - The request gets targeted using some other, undefined > logic > >The administrator for that domain just needs to pick a way of doing >this. So when proxying a PUBLISH request, Section 16 in RFC 3261 applies >in full. > >Cheers, >Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Jan 21 03:10:42 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11487 for ; Wed, 21 Jan 2004 03:10:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjDRG-0000jk-JN for sip-archive@odin.ietf.org; Wed, 21 Jan 2004 03:10:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0L8AEN0002829 for sip-archive@odin.ietf.org; Wed, 21 Jan 2004 03:10:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjDR5-0000iv-NH; Wed, 21 Jan 2004 03:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj6IQ-0002kt-Rn for sip@optimus.ietf.org; Tue, 20 Jan 2004 19:32:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03538 for ; Tue, 20 Jan 2004 19:32:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aj6IP-0001cr-00 for sip@ietf.org; Tue, 20 Jan 2004 19:32:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aj6HU-0001b0-00 for sip@ietf.org; Tue, 20 Jan 2004 19:31:40 -0500 Received: from web20728.mail.yahoo.com ([216.136.226.118]) by ietf-mx with smtp (Exim 4.12) id 1Aj6Gf-0001ZA-00 for sip@ietf.org; Tue, 20 Jan 2004 19:30:49 -0500 Message-ID: <20040121003049.18463.qmail@web20728.mail.yahoo.com> Received: from [63.80.142.2] by web20728.mail.yahoo.com via HTTP; Tue, 20 Jan 2004 16:30:49 PST Date: Tue, 20 Jan 2004 16:30:49 -0800 (PST) From: Ajay Gupta To: sip@ietf.org, sip-implementors-bounces@cs.columbia.edu Cc: stlevy@cisco.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1074324637-1074645049=:18395" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=HTML_MESSAGE autolearn=no version=2.60 Subject: [Sip] Query on sip-diversion draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --0-1074324637-1074645049=:18395 Content-Type: text/plain; charset=us-ascii Hi All, There was a draft-levy-sip-diversion-06.txt for diversion header processing which had expired and has been removed from the IETF site. A new version of the same draft draft-levy-sip-diversion-08.txt is available from www.employees.org/~fluffy/ietf/draft-levy-sip-diversion-08.txt but not on the IETF draft site. Moreover, as per one of the mail threads from the archives, it seems that "History-Info header" is the way to go instead of "Diversion header". So, is the "Diversion header" approach being dropped in favour of "History-Info header" and what is the status of the "Diversion header" draft. Can anybody provide information on these aspects. Thanks Ajay --------------------------------- Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes --0-1074324637-1074645049=:18395 Content-Type: text/html; charset=us-ascii

Hi All,

There was a draft-levy-sip-diversion-06.txt for diversion header processing which had expired and has been removed from the IETF site. A new version of the same draft draft-levy-sip-diversion-08.txt is available from

www.employees.org/~fluffy/ietf/draft-levy-sip-diversion-08.txt

but not on the IETF draft site.

Moreover, as per one of the mail threads from the archives, it seems that "History-Info header" is the way to go instead of "Diversion header". So, is the "Diversion header" approach being dropped in favour of "History-Info header" and what is the status of the "Diversion header" draft. Can anybody provide information on these aspects.

Thanks

Ajay

Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes --0-1074324637-1074645049=:18395-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Jan 21 07:41:05 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18392 for ; Wed, 21 Jan 2004 07:41:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjHet-0006RC-0U for sip-archive@odin.ietf.org; Wed, 21 Jan 2004 07:40:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0LCeY2E024742 for sip-archive@odin.ietf.org; Wed, 21 Jan 2004 07:40:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjHeP-0006Pd-1N; Wed, 21 Jan 2004 07:40:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjHdb-0006Nn-98 for sip@optimus.ietf.org; Wed, 21 Jan 2004 07:39:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18271 for ; Wed, 21 Jan 2004 07:39:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjHda-0001dR-00 for sip@ietf.org; Wed, 21 Jan 2004 07:39:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjHcX-0001TK-00 for sip@ietf.org; Wed, 21 Jan 2004 07:38:10 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AjHb6-0001DD-00 for sip@ietf.org; Wed, 21 Jan 2004 07:36:46 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0LCadY26478 for ; Wed, 21 Jan 2004 14:36:39 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 21 Jan 2004 14:36:35 +0200 Received: from nokia.com ([172.21.98.221]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 21 Jan 2004 14:36:33 +0200 Message-ID: <400E7251.80609@nokia.com> Date: Wed, 21 Jan 2004 14:36:33 +0200 From: "Niemi Aki (Nokia-M/Helsinki)" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext OKUMURA Shinji CC: sip@ietf.org Subject: Re: [Sip] WGLC for PUBLISH References: <200401151049.AA03044@mail2.softfront.co.jp> <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D92C9@esebe013.ntc.nokia.com> <200401201059.AA03088@mail2.softfront.co.jp> <400D3495.5010109@nokia.com> <200401210401.AA03488@mail2.softfront.co.jp> In-Reply-To: <200401210401.AA03488@mail2.softfront.co.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jan 2004 12:36:33.0379 (UTC) FILETIME=[33C4F330:01C3E01B] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Shinji, Exactly, that's the way it goes. Cheers, Aki ext OKUMURA Shinji wrote: > Hi Aki, > > Thank you for your quick response. > > Now I understand. > > The important point I think is that PA determines the target resource > using the r-uri of PUBLISH message "received by PA". > > In other words, the r-uri sending by PUA and the one received by PA > need not to be same. > > Am I right or missing something? > > Cheers, > > Shinji > > >>Hi Shinji, >> >>The key thing here is that there is nothing special about how a proxy >>determines the next hop target for PUBLISH requests. There are several >>options to doing this: >> >> - A domain has configured all PUBLISH requests to be >> forwarded to a PA >> - A PA has explicitly added an address binding for that >> AOR, possibly using the SIP registration >> - All requests get forwarded to a UA (no matter what the >> method is) that has an active address binding in the >> domain's location service for that AoR >> - The request gets targeted using some other, undefined >> logic >> >>The administrator for that domain just needs to pick a way of doing >>this. So when proxying a PUBLISH request, Section 16 in RFC 3261 applies >>in full. >> >>Cheers, >>Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jan 22 00:35:52 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26998 for ; Thu, 22 Jan 2004 00:35:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjXUy-0005fJ-Ft for sip-archive@odin.ietf.org; Thu, 22 Jan 2004 00:35:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0M5ZOna021716 for sip-archive@odin.ietf.org; Thu, 22 Jan 2004 00:35:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjXUd-0005dS-Fh; Thu, 22 Jan 2004 00:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjXUB-0005cW-8f for sip@optimus.ietf.org; Thu, 22 Jan 2004 00:34:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26984 for ; Thu, 22 Jan 2004 00:34:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjXU8-0000mt-00 for sip@ietf.org; Thu, 22 Jan 2004 00:34:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjXTG-0000li-00 for sip@ietf.org; Thu, 22 Jan 2004 00:33:39 -0500 Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1AjXSj-0000i2-00 for sip@ietf.org; Thu, 22 Jan 2004 00:33:06 -0500 Received: from huawei08hiby56 (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HRV009S6LZTYW@mta0.huawei.com> for sip@ietf.org; Thu, 22 Jan 2004 13:31:07 +0800 (CST) Date: Thu, 22 Jan 2004 11:05:47 +0530 From: Prasanna To: dean.willis@softarmor.com, sip@ietf.org, rohan@cisco.com, lavis@huawei.com Message-id: <000001c3e0a9$97ddb490$e905120a@huawei08hiby56> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Subject: [Sip] Issue with the Timestamp grammar in RFC-3261 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hi, I feel the grammar of the Timestamp header is buggy. The grammar being Timestamp = "Timestamp" HCOLON 1*(DIGIT) [ "." *(DIGIT) ] [ LWS delay ] delay = *(DIGIT) [ "." *(DIGIT) ] Can allow the following two cases which makes no sense Timestamp : 1. Timestamp : 1.0 . Should'nt a bug be raised against this to update the grammar to Timestamp = "Timestamp" HCOLON 1*(DIGIT) [ "." 1*(DIGIT) ] [ LWS delay ] delay = 1*(DIGIT) [ "." 1*(DIGIT) ] Thanks for the patient reading. Cheers, Prasanna ***************************************************************** This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ***************************************************************** _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jan 22 08:24:39 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20557 for ; Thu, 22 Jan 2004 08:24:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajeoc-0000hr-PA for sip-archive@odin.ietf.org; Thu, 22 Jan 2004 08:24:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MDOAIb002714 for sip-archive@odin.ietf.org; Thu, 22 Jan 2004 08:24:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjeoT-0000gS-Ir; Thu, 22 Jan 2004 08:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajenq-0000aE-Fs for sip@optimus.ietf.org; Thu, 22 Jan 2004 08:23:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20515 for ; Thu, 22 Jan 2004 08:23:20 -0500 (EST) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajenk-00029B-00 for sip@ietf.org; Thu, 22 Jan 2004 08:23:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjekO-00024W-00 for sip@ietf.org; Thu, 22 Jan 2004 08:19:48 -0500 Received: from imo-r05.mx.aol.com ([152.163.225.101]) by ietf-mx with esmtp (Exim 4.12) id 1AjeiY-0001yM-00 for sip@ietf.org; Thu, 22 Jan 2004 08:17:54 -0500 Received: from Mpierce1@aol.com by imo-r05.mx.aol.com (mail_out_v36_r4.12.) id c.1cf.184603f4 (4238); Thu, 22 Jan 2004 08:16:34 -0500 (EST) Message-ID: <1cf.184603f4.2d412732@aol.com> Date: Thu, 22 Jan 2004 08:16:34 EST Subject: Re: [Sip] re: WGLC: resource priority (1) To: rohan@cisco.com CC: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: 6.0 for Windows XP sub 10500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit In a message dated 1/15/2004 2:50:15 PM Eastern Standard Time, rohan@cisco.com writes: Please do not confuse the change control of the *registration* with the change control of the *normative behavior*. Only the change control of the registration is under the control of the IETF. Obviously if you change the normative behavior in a separate document, you need to change the registration to point at the changes behavior. Recall that the IANA registration serves two purposes: 1) to prevent namespace conflicts, and 2) to allows implementors to find the documents relevant to any namespaces which interest them. [MAP] That's the whole point I'm trying to get at - to keep the control of the "registration" and the control of the "normative behavior" separate. The IANA consideration section of this draft, and any "template" that is defined to provide information to IANA for the registration, should be limited to what is required for the registration. That should not include information about the behaviour of other entities that IANA doesn't need to do its job. In a message dated 1/15/2004 2:50:15 PM Eastern Standard Time, rohan@cisco.com writes: Note that Section 2 of this > draft lists 4 treatments, some of which I would not classify as being > either "preempt" or "prioritize". Can you provide an existence proof of a separate type of treatment? [MAP] I'm reading the word "prioritize" in its literal sense - to put one thing in front of another. One of the preferential treatments that may be applied to a call marked with a higher value is to use a higher call acceptance limit. Another is to exempt it from controls that may prevent lower valued calls from being carried, just as is done today for GETS. I just don't like to use the word "prioritize" to describe these types of preferential treatments, whihc have nothing to do with putting one call in front of another. There can be other types of "preferential treatment" besides just "preempt" and "prioritize", so the template used to register the RP-header with IANA could not be limited to only those two choices. It is not possible to say what all the methods might be in the future. Besides, there is no reason for the IANA registration to include such information. IANA can not use this information. The template should be only the following: Namespace: Description: Organization Responsible for Change Control of this Namespace: Priority values (ordered from least priority to greatest priority): Default priority: Mike Pierce _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jan 22 09:05:38 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21650 for ; Thu, 22 Jan 2004 09:05:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjfSI-0002ic-Au for sip-archive@odin.ietf.org; Thu, 22 Jan 2004 09:05:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0ME5ApI010449 for sip-archive@odin.ietf.org; Thu, 22 Jan 2004 09:05:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjfSB-0002hd-On; Thu, 22 Jan 2004 09:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjfRP-0002gE-8M for sip@optimus.ietf.org; Thu, 22 Jan 2004 09:04:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21616 for ; Thu, 22 Jan 2004 09:04:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjfRI-0003gF-00 for sip@ietf.org; Thu, 22 Jan 2004 09:04:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjfQ0-0003eV-00 for sip@ietf.org; Thu, 22 Jan 2004 09:02:48 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AjfPR-0003cU-00 for sip@ietf.org; Thu, 22 Jan 2004 09:02:14 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA25489; Thu, 22 Jan 2004 09:00:41 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA17017; Thu, 22 Jan 2004 09:00:39 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 22 Jan 2004 09:00:39 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B630A@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Prasanna'" , dean.willis@softarmor.com, sip@ietf.org, rohan@cisco.com, lavis@huawei.com Subject: RE: [Sip] Issue with the Timestamp grammar in RFC-3261 Date: Thu, 22 Jan 2004 09:00:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Generally, a number with a trailing decimal period is allowed. However, I'll agree you need at least one digit in delay. OTOH, it could be a fractional delay (.3). So, delay might have to be delay = (1*(DIGIT) [ "." *(DIGIT) ]) \ ( *(DIGIT) "." 1*DIGIT ) Brian > -----Original Message----- > From: Prasanna [mailto:prasanna@huawei.com] > Sent: Thursday, January 22, 2004 12:36 AM > To: dean.willis@softarmor.com; sip@ietf.org; rohan@cisco.com; > lavis@huawei.com > Subject: [Sip] Issue with the Timestamp grammar in RFC-3261 > > > Hi, > I feel the grammar of the Timestamp header is buggy. > The grammar being > Timestamp = "Timestamp" HCOLON 1*(DIGIT) > [ "." *(DIGIT) ] [ LWS delay ] > delay = *(DIGIT) [ "." *(DIGIT) ] > > Can allow the following two cases which makes no sense > > Timestamp : 1. > Timestamp : 1.0 . > > Should'nt a bug be raised against this to update the grammar to > > Timestamp = "Timestamp" HCOLON 1*(DIGIT) > [ "." 1*(DIGIT) ] [ LWS delay ] > delay = 1*(DIGIT) [ "." 1*(DIGIT) ] > > Thanks for the patient reading. > > Cheers, > Prasanna > > ***************************************************************** > This e-mail and its attachments contain confidential information from > HUAWEI, which is intended only for the person or entity whose > address is > listed above. Any use of the information contained herein in any way > (including, but not limited to, total or partial disclosure, > reproduction, or dissemination) by persons other than the intended > recipient(s) is prohibited. If you receive this e-mail in > error, please > notify the sender by phone or email immediately and delete it! > ***************************************************************** > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jan 22 10:10:39 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23458 for ; Thu, 22 Jan 2004 10:10:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjgTE-0000w8-H0 for sip-archive@odin.ietf.org; Thu, 22 Jan 2004 10:10:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MFACik003594 for sip-archive@odin.ietf.org; Thu, 22 Jan 2004 10:10:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjgT6-0000uZ-0m; Thu, 22 Jan 2004 10:10:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjgSl-0000t2-HI for sip@optimus.ietf.org; Thu, 22 Jan 2004 10:09:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23406 for ; Thu, 22 Jan 2004 10:09:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjgSZ-00064C-00 for sip@ietf.org; Thu, 22 Jan 2004 10:09:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjgQ1-00060N-00 for sip@ietf.org; Thu, 22 Jan 2004 10:06:54 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AjgOe-0005vP-00 for sip@ietf.org; Thu, 22 Jan 2004 10:05:29 -0500 Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i0MF4e9W007172; Thu, 22 Jan 2004 10:04:43 -0500 (EST) Message-ID: <400FE67A.1040505@dynamicsoft.com> Date: Thu, 22 Jan 2004 10:04:26 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bilajbegovic Damir CC: sip@ietf.org Subject: Re: [Sip] Two IP addresses (c= lines) in invite References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The SDP below is OK. I point out the following text in RFC2327: The connection (`c=') and attribute (`a=') information in the session-level section applies to all the media of that session unless overridden by connection information or an attribute of the same name in the media description. For instance, in the example below, each media behaves as if it were given a `recvonly' attribute. however, you won't get the behavior i think you want, which is to offer multiple IP addresses to which a stream can be sent. For within thte same IP version, the alt parameter is defined in ICE for this purpose: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-00.txt for indicating that a UA is dual stack and can receive using either v4 or v6, there is the ANAT specification: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-anat-00.txt -jonathan R. Bilajbegovic Damir wrote: > If I sent a INVITE message with two IP addresses (i.e. user has two IP > addresses and on one it should receive messages) what happens? > Is it valid and how the terminal or proxy should react on this. (there are > c= lines ) > And one more additional question: If one c= is IPv6 and another line is c= > IPv4 and colleen (B) party is IPv4 what does is do? Will B party (or B > proxy) reject the message, replay with deleted misunderstood lines, or will > put the port numbers on 0. > The message invite is down below (I think it should look like this- is it > good?) > Thanks in advance. > > Damir Bilajbegovic > > INVITE tel:+1-212-555-2222 SIP/2.0 > > ............ > > v=0 > o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd > s=- > c=IN IP6 5555::aaa:bbb:ccc:ddd > t=0 0 > m=video 3400 RTP/AVP 98 99 > b=AS:75 > a=curr:qos local none > a=curr:qos remote none > a=des:qos mandatory local sendrecv > a=des:qos none remote sendrecv > a=rtpmap:98 H263 > a=fmtp:98 profile-level-id=0 > a=rtpmap:99 MP4V-ES > > > c=IN IP6 5555::aaa:bbb:ccc:eee > t=0 0 > m=video 3400 RTP/AVP 98 99 > b=AS:75 > a=curr:qos local none > a=curr:qos remote none > a=des:qos mandatory local sendrecv > a=des:qos none remote sendrecv > a=rtpmap:98 H263 > a=fmtp:98 profile-level-id=0 > a=rtpmap:99 MP4V-ES > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jan 22 10:48:43 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25807 for ; Thu, 22 Jan 2004 10:48:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajh41-0007cn-Gp for sip-archive@odin.ietf.org; Thu, 22 Jan 2004 10:48:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MFmDV7029248 for sip-archive@odin.ietf.org; Thu, 22 Jan 2004 10:48:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajh3p-0007XK-Io; Thu, 22 Jan 2004 10:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajh2w-0007TH-4d for sip@optimus.ietf.org; Thu, 22 Jan 2004 10:47:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25744 for ; Thu, 22 Jan 2004 10:47:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajh2t-000033-00 for sip@ietf.org; Thu, 22 Jan 2004 10:47:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajh1u-0007nT-00 for sip@ietf.org; Thu, 22 Jan 2004 10:46:02 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Ajh13-0007hy-00 for sip@ietf.org; Thu, 22 Jan 2004 10:45:09 -0500 Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i0MFiW9W007177; Thu, 22 Jan 2004 10:44:33 -0500 (EST) Message-ID: <400FEFD1.60004@dynamicsoft.com> Date: Thu, 22 Jan 2004 10:44:17 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Lawrence CC: Paul Kyzivat , ksrini@motorola.com, sip@ietf.org Subject: Re: [Sip] Registering Multiple 'Contacts' References: <4002E0B9.8030203@cisco.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Scott Lawrence wrote: > Srinivasan Krishnamoorthy wrote: > > >>> Section 10.2.4 of RFC3261 'Refreshing Bindings' says: >>> "The UA then issues a REGISTER request for each of its bindings >>>before the expiration interval has elapsed. It MAY combine several >>>updates into one REGISTER request." >>> The above seems to indicate that the UAC may send: (forgive the >>>Syntax) >>> REGISTER To: user@operator.net >>> Contact: sip:user1@10.0.0.1;expires=3600 >>> 200 OK >>> REGISTER To: user@operator.net >>> Contact: sip:user1@192.0.0.1;expires=3600 >>> 200 OK >>> This, according to RFC3261, will register both Contact1 and Contact2 >>>for user@operator.net. (The server will then use the q parameter >>> of the contact for priority among contacts) > > > Paul Kyzivat writes: > > >>Yes. > > > My reading is that the results should differ depending on the Call-Id > used in those two REGISTER requests: > > - If they have different Call-Id values, then the server should > register both contacts. > > - If they have the same Call-Id value, then the second REGISTER > should cause the server to replace the first contact with the > second, so that there would be only No, this is not the case. The callid/cseq are used as an ordering tool. In the abovoe case, if the Call-ID are the same, both contacts are added, and both are marked as having that particular callid, but with different cseq. if the Call-id are different, both contacts are added, but with different call-id and cseq. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jan 22 10:56:37 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26410 for ; Thu, 22 Jan 2004 10:56:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjhBi-0008Mb-8g for sip-archive@odin.ietf.org; Thu, 22 Jan 2004 10:56:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MFuAZx032088 for sip-archive@odin.ietf.org; Thu, 22 Jan 2004 10:56:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjhBZ-0008KZ-Pa; Thu, 22 Jan 2004 10:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjhAg-0008JN-5e for sip@optimus.ietf.org; Thu, 22 Jan 2004 10:55:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26240 for ; Thu, 22 Jan 2004 10:55:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjhAd-0000lG-00 for sip@ietf.org; Thu, 22 Jan 2004 10:55:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajh9g-0000bw-00 for sip@ietf.org; Thu, 22 Jan 2004 10:54:05 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Ajh8m-0000QN-00 for sip@ietf.org; Thu, 22 Jan 2004 10:53:08 -0500 Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i0MFqf9W007184; Thu, 22 Jan 2004 10:52:43 -0500 (EST) Message-ID: <400FF1B9.909@dynamicsoft.com> Date: Thu, 22 Jan 2004 10:52:25 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: brett@broadsoft.com, sip@ietf.org Subject: Re: [Sip] Is Retry-After:0 valid? References: <2038BCC78B1AD641891A0D1AE133DBB7017975D5@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017975D5@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Yes, its valid. However the text is incorrect, since formally, "positive" most definitely does NOT include zero (see http://en2.wikipedia.org/wiki/Positive_number). I've logged this in bugzilla: http://bugs.sipit.net/sipwg/show_bug.cgi?id=746 -Jonathan R. hisham.khartabil@nokia.com wrote: > I don't see why it would be disallowed. It is certainly valid and says to retry immediately (after 0 seconds). > > I guess the second quote can have the word "inclusive" added. > > Regards, > Hisham > > >>-----Original Message----- >>From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of ext >>Brett Tate >>Sent: 17.January.2004 02:14 >>To: sip-ietf (E-mail) >>Subject: [Sip] Is Retry-After:0 valid? >> >> >>(Trying the sip list because I did not >>receive any reply concerning my >>sip-implementors posting...) >> >> >>Is 0 a valid value for the retry-after header? >> >>I assume that it is; and the bnf allows it. >>However I guess that it depends upon the meaning >>of "positive" in section 20.33 and if the >>"between" statement of section 14.2 is inclusive. >> >>RFC3261 section 20.33 mentions the following: >> "The value of this field is a positive integer >> number of seconds (in decimal) after the time >> of the response." >> >>RFC3261 section 14.2 mentions the following: >> "MUST include a Retry-After header field with a >> randomly chosen value of between 0 and 10 seconds." >> >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jan 22 14:21:43 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05465 for ; Thu, 22 Jan 2004 14:21:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjkOB-0002Kw-Kj for sip-archive@odin.ietf.org; Thu, 22 Jan 2004 14:21:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MJLFAF008978 for sip-archive@odin.ietf.org; Thu, 22 Jan 2004 14:21:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjkNz-0002Jo-NA; Thu, 22 Jan 2004 14:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjkNH-0002Ij-AR for sip@optimus.ietf.org; Thu, 22 Jan 2004 14:20:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05406 for ; Thu, 22 Jan 2004 14:20:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjkN4-00064y-00 for sip@ietf.org; Thu, 22 Jan 2004 14:20:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjkK4-0005zB-00 for sip@ietf.org; Thu, 22 Jan 2004 14:17:00 -0500 Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx with esmtp (Exim 4.12) id 1AjkHX-0005rI-00 for sip@ietf.org; Thu, 22 Jan 2004 14:14:23 -0500 Received: from localhost (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (8.11.6/8.11.6) with ESMTP id i0MJDWJ18146; Thu, 22 Jan 2004 14:13:32 -0500 Subject: Re: [Sip] Registering Multiple 'Contacts' From: Scott Lawrence To: Jonathan Rosenberg Cc: Paul Kyzivat , ksrini@motorola.com, sip@ietf.org In-Reply-To: <400FEFD1.60004@dynamicsoft.com> References: <4002E0B9.8030203@cisco.com> <400FEFD1.60004@dynamicsoft.com> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Message-Id: <1074798811.3880.36.camel@sukothai.pingtel.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 22 Jan 2004 14:13:32 -0500 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Earlier, I wrote: > > My reading is that the results should differ depending on the Call-Id > > used in those two REGISTER requests: > > > > - If they have different Call-Id values, then the server should > > register both contacts. > > > > - If they have the same Call-Id value, then the second REGISTER > > should cause the server to replace the first contact with the > > second, so that there would be only On Thu, 2004-01-22 at 10:44, Jonathan Rosenberg wrote: > No, this is not the case. The callid/cseq are used as an ordering > tool. In the abovoe case, if the Call-ID are the same, both contacts > are added, and both are marked as having that particular callid, but > with different cseq. if the Call-id are different, both contacts are > added, but with different call-id and cseq. I had quite a struggle with this recently; perhaps you could help clarify what is meant by RFC 3261 sec 10.3 in step 6 when it says: ...the registrar checks whether the Call-ID agrees with the value stored for each binding. If not, it MUST remove the binding. I read that to mean that if my registry contains a binding to: me@example.com call-id: 1234@example.org cseq: 100 contact: line1@10.1.1.1 and I receive a REGISTER for: to: me@example.com call-id: 5678@example.org cseq: 10 contact: line2@10.1.1.2 the Call-ID does not agree (making Cseq irrelevant), so shouldn't the registry remove the binding as directed above? [Whatever the answer, I believe that 10.3 is too hard to interpret. If I can learn what the right behavior is, I'll be happy to try to draft text] -- Scott Lawrence Pingtel Corp. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jan 22 19:27:39 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21398 for ; Thu, 22 Jan 2004 19:27:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjpAG-0006Zd-98 for sip-archive@odin.ietf.org; Thu, 22 Jan 2004 19:27:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0N0RCkc025265 for sip-archive@odin.ietf.org; Thu, 22 Jan 2004 19:27:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjpA5-0006YX-JN; Thu, 22 Jan 2004 19:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajp9b-0006RR-Om for sip@optimus.ietf.org; Thu, 22 Jan 2004 19:26:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21376 for ; Thu, 22 Jan 2004 19:26:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajp9O-0000H4-00 for sip@ietf.org; Thu, 22 Jan 2004 19:26:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajp5s-0000D8-00 for sip@ietf.org; Thu, 22 Jan 2004 19:22:41 -0500 Received: from usjk1004.kddi.com ([211.4.169.26]) by ietf-mx with esmtp (Exim 4.12) id 1Ajp3x-00007o-00 for sip@ietf.org; Thu, 22 Jan 2004 19:20:42 -0500 Received: from usjk1006.kddi.com (usjk1006 [10.96.2.3]) by usjk1004.kddi.com (3.7W-030228132558) with ESMTP id JAA03662; Fri, 23 Jan 2004 09:19:29 +0900 (JST) Received: from usjk1010.kddi.com (localhost [127.0.0.1]) by usjk1006.kddi.com (3.7W-040107142500) with ESMTP id JAA17094; Fri, 23 Jan 2004 09:19:31 +0900 (JST) Received: from KDDI-0003PC0281.kddi.com ([10.100.94.32]) by usjk1010.kddi.com (InterMail vM.5.01.02.00 201-253-116-121-20001201) with ESMTP id <20040123001927.VAVM13285.usjk1010.kddi.com@KDDI-0003PC0281.kddi.com>; Fri, 23 Jan 2004 09:19:27 +0900 To: slawrence@pingtel.com Cc: sip@ietf.org Subject: Re: [Sip] Registering Multiple 'Contacts' From: Takuya Sawada References: <4002E0B9.8030203@cisco.com> <400FEFD1.60004@dynamicsoft.com> <1074798811.3880.36.camel@sukothai.pingtel.com> In-Reply-To: <1074798811.3880.36.camel@sukothai.pingtel.com> Message-Id: <200401230919.BGI03217.VBBXBU-TE@kddi.com> X-Mailer: Winbiff [Version 2.42 PL2] X-Accept-Language: ja,en Date: Fri, 23 Jan 2004 09:19:27 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi, > Earlier, I wrote: > > > > My reading is that the results should differ depending on the Call-Id > > > used in those two REGISTER requests: > > > > > > - If they have different Call-Id values, then the server should > > > register both contacts. > > > > > > - If they have the same Call-Id value, then the second REGISTER > > > should cause the server to replace the first contact with the > > > second, so that there would be only > > On Thu, 2004-01-22 at 10:44, Jonathan Rosenberg wrote: > > > No, this is not the case. The callid/cseq are used as an ordering > > tool. In the abovoe case, if the Call-ID are the same, both contacts > > are added, and both are marked as having that particular callid, but > > with different cseq. if the Call-id are different, both contacts are > > added, but with different call-id and cseq. > > I had quite a struggle with this recently; perhaps you could help > clarify what is meant by RFC 3261 sec 10.3 in step 6 when it says: > > ...the registrar checks > whether > the Call-ID agrees with the value stored for each binding. If > not, it MUST remove the binding. > This part, step 6, applies in the case when REGISTER request contains one Contact field value that contains the special value "*" and Expires that value is zero to remove all bindings. When adding bindings or removing each binding or refresh bindings, you must follow step 7. Regards, Takuya > I read that to mean that if my registry contains a binding > > to: me@example.com > call-id: 1234@example.org > cseq: 100 > contact: line1@10.1.1.1 > > and I receive a REGISTER for: > > to: me@example.com > call-id: 5678@example.org > cseq: 10 > contact: line2@10.1.1.2 > > the Call-ID does not agree (making Cseq irrelevant), so shouldn't the > registry remove the binding as directed above? > > [Whatever the answer, I believe that 10.3 is too hard to interpret. If > I can learn what the right behavior is, I'll be happy to try to draft > text] > > -- > Scott Lawrence > Pingtel Corp. > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -------- Takuya Sawada KDDI Corporation (KDDI) Garden Air Tower, 3-10-10 Iidabashi Chiyoda-ku Tokyo 102-8460, Japan Tel: +81-3-6678-2997 Fax: +81-3-6678-0285 tu-sawada@kddi.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jan 22 23:25:04 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28281 for ; Thu, 22 Jan 2004 23:25:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajsrs-0004sh-Pc for sip-archive@odin.ietf.org; Thu, 22 Jan 2004 23:24:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0N4OSEg018757 for sip-archive@odin.ietf.org; Thu, 22 Jan 2004 23:24:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjsrS-0004q4-0r; Thu, 22 Jan 2004 23:24:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjsrC-0004pg-Vp for sip@optimus.ietf.org; Thu, 22 Jan 2004 23:23:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28263 for ; Thu, 22 Jan 2004 23:23:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajsr5-0001iR-00 for sip@ietf.org; Thu, 22 Jan 2004 23:23:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjsoD-0001dd-00 for sip@ietf.org; Thu, 22 Jan 2004 23:20:41 -0500 Received: from mta1.huawei.com ([61.144.161.40] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1AjsmI-0001Y8-00 for sip@ietf.org; Thu, 22 Jan 2004 23:18:43 -0500 Received: from huawei08hiby56 (huawei.com [172.17.1.60]) by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0HRX0053SCVR7F@mta1.huawei.com> for sip@ietf.org; Fri, 23 Jan 2004 12:09:29 +0800 (CST) Date: Fri, 23 Jan 2004 09:51:40 +0530 From: Prasanna Subject: RE: [Sip] Issue with the Timestamp grammar in RFC-3261 In-reply-to: <313680C9A886D511A06000204840E1CF070B630A@whq-msgusr-02.pit.comms.marconi.com> To: "'Rosen, Brian'" , dean.willis@softarmor.com, sip@ietf.org, rohan@cisco.com, lavis@huawei.com Message-id: <001601c3e168$675d6c10$e905120a@huawei08hiby56> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT I agree to this grammar. But I have one query? Any reasons why a number with a trailing decimal period is allowed (it is allowed in all the decimal numbers like "q" etc.)? Thanks, Prasanna -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Thursday, January 22, 2004 7:30 PM To: 'Prasanna'; dean.willis@softarmor.com; sip@ietf.org; rohan@cisco.com; lavis@huawei.com Subject: RE: [Sip] Issue with the Timestamp grammar in RFC-3261 Generally, a number with a trailing decimal period is allowed. However, I'll agree you need at least one digit in delay. OTOH, it could be a fractional delay (.3). So, delay might have to be delay = (1*(DIGIT) [ "." *(DIGIT) ]) \ ( *(DIGIT) "." 1*DIGIT ) Brian > -----Original Message----- > From: Prasanna [mailto:prasanna@huawei.com] > Sent: Thursday, January 22, 2004 12:36 AM > To: dean.willis@softarmor.com; sip@ietf.org; rohan@cisco.com; > lavis@huawei.com > Subject: [Sip] Issue with the Timestamp grammar in RFC-3261 > > > Hi, > I feel the grammar of the Timestamp header is buggy. > The grammar being > Timestamp = "Timestamp" HCOLON 1*(DIGIT) > [ "." *(DIGIT) ] [ LWS delay ] > delay = *(DIGIT) [ "." *(DIGIT) ] > > Can allow the following two cases which makes no sense > > Timestamp : 1. > Timestamp : 1.0 . > > Should'nt a bug be raised against this to update the grammar to > > Timestamp = "Timestamp" HCOLON 1*(DIGIT) > [ "." 1*(DIGIT) ] [ LWS delay ] > delay = 1*(DIGIT) [ "." 1*(DIGIT) ] > > Thanks for the patient reading. > > Cheers, > Prasanna > > ***************************************************************** > This e-mail and its attachments contain confidential information from > HUAWEI, which is intended only for the person or entity whose address > is listed above. Any use of the information contained herein in any > way (including, but not limited to, total or partial disclosure, > reproduction, or dissemination) by persons other than the intended > recipient(s) is prohibited. If you receive this e-mail in > error, please > notify the sender by phone or email immediately and delete it! > ***************************************************************** > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Jan 23 05:26:28 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23056 for ; Fri, 23 Jan 2004 05:26:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjyVc-00047B-WF for sip-archive@odin.ietf.org; Fri, 23 Jan 2004 05:25:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NAPqcX015818 for sip-archive@odin.ietf.org; Fri, 23 Jan 2004 05:25:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjyUo-000444-8t; Fri, 23 Jan 2004 05:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajc9p-00087Y-3Z for sip@optimus.ietf.org; Thu, 22 Jan 2004 05:33:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15963 for ; Thu, 22 Jan 2004 05:33:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajc9l-0002al-00 for sip@ietf.org; Thu, 22 Jan 2004 05:33:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajc8n-0002Yd-00 for sip@ietf.org; Thu, 22 Jan 2004 05:32:50 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx with esmtp (Exim 4.12) id 1Ajc8R-0002Wa-00 for sip@ietf.org; Thu, 22 Jan 2004 05:32:27 -0500 Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 22 Jan 2004 11:32:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE : [Sip] draft-ietf-sip-history-info-01.txt Content-Class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Thu, 22 Jan 2004 11:32:16 +0100 Message-ID: <57F140DC5CDA10438C41674629DE0D870178E90A@parmhs4.rd.francetelecom.fr> Thread-Topic: [Sip] draft-ietf-sip-history-info-01.txt Thread-Index: AcPcFXuqco6TFgzPRPmMD7C62RFYLQEvCvjw From: =?iso-8859-1?Q?PROUVOST_S=E9bastien_FTRD/DAC/ISS?= To: "Jesske, R" , , , , X-OriginalArrivalTime: 22 Jan 2004 10:32:16.0934 (UTC) FILETIME=[01CB7C60:01C3E0D3] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I fully support this proposal.=20 The privacy regarding the history-info header relates to the privacy = policy accorded to the target of the request (before it is retargeted). = Therefore it shall not depend on the privacy policy accorded to the = calling UA. The history-info header shall have its own privacy value.=20 Moreover in case the request is retargeted more than once (particularly = if the targets represent different users), it shall be possible to = request privacy for a target independently of the others. =20 Regards, S=E9bastien Prouvost France T=E9l=E9com R&D/DAC/CAR -----Message d'origine----- De : Jesske, R [mailto:R.Jesske@t-com.net]=20 Envoy=E9 : vendredi 16 janvier 2004 10:29 =C0 : sip@ietf.org Cc : Poetzl, Joachim; Alexeitsev, D Objet : [Sip] draft-ietf-sip-history-info-01.txt Dear all, in 1.3 Ensuring the Privacy of History_Info it is proposed to use a = priv-value of Session or Header level privacy. I would like to propose a = own privacy level for the history info, because the Information shows = also information about the network. With regard to the provider = operating a network some of the providers don't like to transmit = information about call history. Or a redirecting party don't like to = show the redirecting address. Therefore it should be possible to delete = the history info at domain boundaries based on the privacy-value. I propose the priv-value =3D "history_info" for the whole = History-Info header. In addition a option would be useful where only parts (e.g Indes1.1) of = the history info are restricted. That could be done with a privacy = statement within the History-Info . Best Regards Roland Deutsche Telekom AG T Com Zentrale Roland Jesske, T332-2 Section T33; Signalling, Gateways and Switching Systems=20 Am Kavalleriesand 3, 64295 Darmstadt, Germany Phone: +49 6151 83-5940=20 Fax: +49 6151 83-4577=20 email: r.jesske@t-com.net _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use = sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Jan 23 14:08:42 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16622 for ; Fri, 23 Jan 2004 14:08:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak6f9-0003ZV-8W for sip-archive@odin.ietf.org; Fri, 23 Jan 2004 14:08:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NJ8FF0013723 for sip-archive@odin.ietf.org; Fri, 23 Jan 2004 14:08:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak6ex-0003YG-Ar; Fri, 23 Jan 2004 14:08:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak6eo-0003VK-SI for sip@optimus.ietf.org; Fri, 23 Jan 2004 14:07:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16609 for ; Fri, 23 Jan 2004 14:07:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak6em-0007EJ-00 for sip@ietf.org; Fri, 23 Jan 2004 14:07:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak6dw-0007Cw-00 for sip@ietf.org; Fri, 23 Jan 2004 14:07:01 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1Ak6da-0007AO-00 for sip@ietf.org; Fri, 23 Jan 2004 14:06:38 -0500 Received: from bdsl.greycouncil.com (www.softarmor.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id i0NJD7sb021354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 23 Jan 2004 13:13:07 -0600 Received: (from dwillis@localhost) by bdsl.greycouncil.com (8.12.8/8.12.8/Submit) id i0NJD7Cd021352 for sip@ietf.org; Fri, 23 Jan 2004 13:13:07 -0600 X-Authentication-Warning: bdsl.greycouncil.com: dwillis set sender to dwillis@dynamicsoft.com using -f From: Dean Willis To: sip@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1074885187.20359.276.camel@bdsl.greycouncil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 23 Jan 2004 13:13:07 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Questions on draft-ietf-sip-session-timer-13 and refresh timers Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I'me reviewing some IESG comments on this draft, and I've found something I don't understand. The original comment from Ted was something like "Why do we recommend refresh at 1/2 the session timer in sections 7 and 8, but require a BYE at a recommended 1/3St-10s in section 10?" I understand why we require refresh, and why we suggested refreshing at 1/2 of the session timer value. What I don't understand is the BYE logic in Section 10. >From Section 10: If no 2xx response to a session refresh request is received before the session expiration, the UA SHOULD send a BYE request to terminate the session. It SHOULD send this BYE slightly before session expiration. The minimum of ten seconds and one third the session interval is RECOMMENDED. For example, if the session interval is 120 seconds, one third of this is 40 seconds. Since the minimum of 10 seconds and 40 seconds is 10 seconds, the BYE would be sent 10 seconds before the session expires. I read this as: A UA has issues a session refresh request, and is waiting around for that transaction to complete. Unfortunately, it either 1) didn't issue the request sufficiently early for the transaction to complete before the session is going to expire, so it needs to abandon the refreshing transaction and terminate the session before the session expires, or 2) the session refresh request failed, but we're going to continue to use this session for a while before tearing it down before it expires. It seems more reasonable that the UA should issue the session refresh request far enough in advance of session expiration that the session refresh request will complete (or fail with timeout) before the session expires, and that if the session refresh request fails, the UA should immediately terminate the session with a BYE. This implies that the lowest allowable threshold for the negotiated session timer should be larger than the largest timeout value for a session refresh request (which could be an INVITE transaction). It also may place requirements on UAs that have implemented non-standard timer values to calculate this lowest allowable threshold for the negotiated session timer value and include this calculated value in their negotiation by initializing the Min-SE value. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Jan 23 21:42:49 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08573 for ; Fri, 23 Jan 2004 21:42:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkDkb-0008Lf-5E for sip-archive@odin.ietf.org; Fri, 23 Jan 2004 21:42:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0O2gL2E032088 for sip-archive@odin.ietf.org; Fri, 23 Jan 2004 21:42:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkDkH-0008G8-PC; Fri, 23 Jan 2004 21:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkDjN-0008Fg-1V for sip@optimus.ietf.org; Fri, 23 Jan 2004 21:41:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08559 for ; Fri, 23 Jan 2004 21:41:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkDjK-0004Ra-00 for sip@ietf.org; Fri, 23 Jan 2004 21:41:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkDiR-0004Qo-00 for sip@ietf.org; Fri, 23 Jan 2004 21:40:07 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AkDhg-0004NN-00 for sip@ietf.org; Fri, 23 Jan 2004 21:39:20 -0500 Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i0O2cn9W008172; Fri, 23 Jan 2004 21:38:51 -0500 (EST) Message-ID: <4011DAAE.8020604@dynamicsoft.com> Date: Fri, 23 Jan 2004 21:38:38 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Takuya Sawada CC: slawrence@pingtel.com, sip@ietf.org Subject: Re: [Sip] Registering Multiple 'Contacts' References: <4002E0B9.8030203@cisco.com> <400FEFD1.60004@dynamicsoft.com> <1074798811.3880.36.camel@sukothai.pingtel.com> <200401230919.BGI03217.VBBXBU-TE@kddi.com> In-Reply-To: <200401230919.BGI03217.VBBXBU-TE@kddi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit You are correct. Step 6 is only for Contact: *. -Jonathan R. Takuya Sawada wrote: > Hi, > > >>Earlier, I wrote: >> >> >>>>My reading is that the results should differ depending on the Call-Id >>>>used in those two REGISTER requests: >>>> >>>> - If they have different Call-Id values, then the server should >>>> register both contacts. >>>> >>>> - If they have the same Call-Id value, then the second REGISTER >>>> should cause the server to replace the first contact with the >>>> second, so that there would be only >> >>On Thu, 2004-01-22 at 10:44, Jonathan Rosenberg wrote: >> >> >>>No, this is not the case. The callid/cseq are used as an ordering >>>tool. In the abovoe case, if the Call-ID are the same, both contacts >>>are added, and both are marked as having that particular callid, but >>>with different cseq. if the Call-id are different, both contacts are >>>added, but with different call-id and cseq. >> >>I had quite a struggle with this recently; perhaps you could help >>clarify what is meant by RFC 3261 sec 10.3 in step 6 when it says: >> >> ...the registrar checks >>whether >> the Call-ID agrees with the value stored for each binding. If >> not, it MUST remove the binding. >> > > This part, step 6, applies in the case when REGISTER request contains > one Contact field value that contains the special value "*" and > Expires that value is zero to remove all bindings. > When adding bindings or removing each binding or refresh bindings, > you must follow step 7. > > Regards, > Takuya > > > >>I read that to mean that if my registry contains a binding >> >> to: me@example.com >> call-id: 1234@example.org >> cseq: 100 >> contact: line1@10.1.1.1 >> >>and I receive a REGISTER for: >> >> to: me@example.com >> call-id: 5678@example.org >> cseq: 10 >> contact: line2@10.1.1.2 >> >>the Call-ID does not agree (making Cseq irrelevant), so shouldn't the >>registry remove the binding as directed above? >> >>[Whatever the answer, I believe that 10.3 is too hard to interpret. If >>I can learn what the right behavior is, I'll be happy to try to draft >>text] >> >>-- >>Scott Lawrence >> Pingtel Corp. >> >> >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip > > > > -------- > Takuya Sawada > KDDI Corporation (KDDI) > Garden Air Tower, 3-10-10 Iidabashi Chiyoda-ku > Tokyo 102-8460, Japan > Tel: +81-3-6678-2997 > Fax: +81-3-6678-0285 > tu-sawada@kddi.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sat Jan 24 11:29:50 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13429 for ; Sat, 24 Jan 2004 11:29:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkQev-0006PI-Vc for sip-archive@odin.ietf.org; Sat, 24 Jan 2004 11:29:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0OGTLke024568 for sip-archive@odin.ietf.org; Sat, 24 Jan 2004 11:29:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkQeb-0006NG-UY; Sat, 24 Jan 2004 11:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkQe9-0006Mt-Bn for sip@optimus.ietf.org; Sat, 24 Jan 2004 11:28:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13388 for ; Sat, 24 Jan 2004 11:28:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkQe8-00058P-00 for sip@ietf.org; Sat, 24 Jan 2004 11:28:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkQdF-00056e-00 for sip@ietf.org; Sat, 24 Jan 2004 11:27:37 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AkQcm-00054L-00 for sip@ietf.org; Sat, 24 Jan 2004 11:27:08 -0500 Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i0OGPp9W008332; Sat, 24 Jan 2004 11:25:55 -0500 (EST) Message-ID: <40129C86.2080102@dynamicsoft.com> Date: Sat, 24 Jan 2004 11:25:42 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Prasanna CC: "'Rosen, Brian'" , dean.willis@softarmor.com, sip@ietf.org, rohan@cisco.com, lavis@huawei.com Subject: Re: [Sip] Issue with the Timestamp grammar in RFC-3261 References: <001601c3e168$675d6c10$e905120a@huawei08hiby56> In-Reply-To: <001601c3e168$675d6c10$e905120a@huawei08hiby56> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Prasanna wrote: > I agree to this grammar. I believe the grammar for delay should be identical to the timestamp itself, so that: delay = 1*(DIGIT) [ "." *(DIGIT) ] I don't see the need to support somethiing like ".3"; since you can represent that as "0.3". I've logged a bug against this: http://bugs.sipit.net/sipwg/show_bug.cgi?id=748 But I have one query? > Any reasons why a number with a trailing decimal period is allowed (it > is allowed in all the decimal numbers like "q" etc.)? It was inherited from HTTP which did it this way. In hindsight there is really no point in supporting multiple different ways of representing a rational number, it just makes the implementation more complicated. But, its what we have, so be it. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sat Jan 24 17:50:48 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27103 for ; Sat, 24 Jan 2004 17:50:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkWbe-0007rH-2O for sip-archive@odin.ietf.org; Sat, 24 Jan 2004 17:50:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0OMoLoN030083 for sip-archive@odin.ietf.org; Sat, 24 Jan 2004 17:50:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkWbL-0007nG-Bo; Sat, 24 Jan 2004 17:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkWb6-0007mE-FS for sip@optimus.ietf.org; Sat, 24 Jan 2004 17:49:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27085 for ; Sat, 24 Jan 2004 17:49:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkWb3-0000cY-00 for sip@ietf.org; Sat, 24 Jan 2004 17:49:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkWa7-0000ad-00 for sip@ietf.org; Sat, 24 Jan 2004 17:48:48 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AkWZS-0000WU-00 for sip@ietf.org; Sat, 24 Jan 2004 17:48:06 -0500 Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i0OMle9W008367 for ; Sat, 24 Jan 2004 17:47:41 -0500 (EST) Message-ID: <4012E741.5000809@dynamicsoft.com> Date: Sat, 24 Jan 2004 16:44:33 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TAG_BALANCE_BODY autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] querying the current event state of a publication Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit In draft-ietf-sip-publish-02, section 5.7 proposes a way to query a specific published event state. It recommends subscribing to the AOR to learn it. However, it gives this caveat: Note that a subscription to the event package will likely deliver results of the event composition process of the state agent, which may be a subset or a superset of the current published event state. which is another way of saying, that subscribing to the aor doesnt really allow you to query for a specific published event state. If we want this functionality, I have an idea for an alternative approach that works much better, triggered by some conversations I had with Ben C. recently. In the response to a PUBLISH request, the ESC returns a URI that identifies that particular event state publication (effectively, a URI that is bound to the AOR+event+etag of a publication). This URI is basically a GRUU. If a user wishes to learn the state of this particular event state, they merely subscribe to that URI. Indeed, a particularly interestinig way to do this is to define sIP etags as URIs, rather than reusing the definition from http. I think that having an etag as a URI is far more elegant, as it would allow for things like this function in a natural way. The alternative would be to possibly use the Contact header field, as the meaning is the same as in a 2xx to INVITE - identifying the specific *instance* to which you were connected when you contacted the AOR. This makes sense if you think of the event state publication URI as a GRUU. Indeed, one might even then PUBLISH to that URI, and it would have the exact result you would expect - that particular event state is updated. In such a case the server woould NOT return an etag or another URI in the response. So, as an example, if I want to publish for sip:jdrosen@dynamicsoft.com: PUBLISH sip:jdrosen@dynamicsoft.com Event: presence the server responds: SIP 200 oK SIP-Etag: sip:9adjsss=9888sdahhsd77fggld@dynamicsoft.com now, I have a handle for the specific event state. To update it: PUBLISH sip:9adjsss=9888sdahhsd77fggld@dynamicsoft.com Event: presence This would mean we wouldnt need the SIP-If-match. Another alternative is to say that we are simply too far along in PUBLISH, and the time has passed for major changes as this would be. Thoughts? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sat Jan 24 17:50:48 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27102 for ; Sat, 24 Jan 2004 17:50:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkWbe-0007rG-1n for sip-archive@odin.ietf.org; Sat, 24 Jan 2004 17:50:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0OMoLH1030081 for sip-archive@odin.ietf.org; Sat, 24 Jan 2004 17:50:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkWbM-0007nT-Oy; Sat, 24 Jan 2004 17:50:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkWb7-0007mJ-2W for sip@optimus.ietf.org; Sat, 24 Jan 2004 17:49:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27088 for ; Sat, 24 Jan 2004 17:49:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkWb4-0000cd-00 for sip@ietf.org; Sat, 24 Jan 2004 17:49:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkWa8-0000al-00 for sip@ietf.org; Sat, 24 Jan 2004 17:48:50 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AkWZX-0000XQ-00 for sip@ietf.org; Sat, 24 Jan 2004 17:48:11 -0500 Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i0OMln9W008370 for ; Sat, 24 Jan 2004 17:47:50 -0500 (EST) Message-ID: <4012F405.5000606@dynamicsoft.com> Date: Sat, 24 Jan 2004 17:39:01 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-publish-02.txt References: <200401072101.QAA01563@ietf.org> In-Reply-To: <200401072101.QAA01563@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit enclosed are my comments on -02. Most are minor. There is one major question, and I sent a separate note on that. * the current title is not in line with the guidelines in draft-ietf-sip-guiudelines, which says: An important decision to be made about the extension is its title. The title MUST indicate that the document is an extension to SIP. It is RECOMMENDED that the title follow the basic form of "A [summary of function] for the Session Initiation Protocol (SIP)", where the summary of function is a one to three word description of the as such, I suggest changing to "An Event State Publication Extension to the Session Initiation Protocol (SIP)" * wording nit in the abstract: This document describes an extension to the Session Initiation Protocol (SIP) for publishing event state used within the framework for SIP Event Notification. is clearer as: This document describes an extension to the Session Initiation Protocol (SIP) for publishing event state used within the SIP event framework. * also in the abstract: It is not intended to be a general-purpose mechanism for transport of arbitrary data, as there are better-suited mechanisms for this purpose (FTP, HTTP, etc.) i suggest dropping the examples (FTP, HTTP) since it may raise some alarms that we are asserting that http should be used for all kinds of data transport functions. * In the intro: > The focus of this specification is to provide a framework for the > publication of event state from a user agent to an entity that is focus implies that it does other things also, but it doesnt. I would rather say "this specification provides a framework for the ...." * also in the intro: > The first application of this mechanism is the publication of > presence state by a presence user agent to a presence compositor, > which has a tightly coupled relationship with the presence agent. the beginning of this sentence doesnt make it clear that this spec indeed defines that application. how abouot: "In addition to defining an event publication framework, this specification defines a usage of that framework for the publication of presence state [REF draft-ietf-simple-presence]..." You shouuld add a reference to rfc2778 after "presence user agent", and to draft-ietf-simple-presence for the definition of presence agent. presence compositor is used here but not defined. Indeed, 'presence compositor' does not appear in the definitions which follow. As I believe the requiremenets and model will be folded into this spec, the definition shouould appear here. * from the intro: > The mechanism described in this document can be extended to support > publication of any event state, for which there exists an appropriate > event package as defined in [1]. the comma in the midddle is not needed * from the intro: > It is not intended to be a > general-purpose mechanism for transport of arbitrary data, as there > are better-suited mechanisms for this purpose (FTP [6], HTTP [7], > etc.) as above re: ftp, http * in the definitions section, you offer definitions of soft and hard state. These are not the definitions for those terms as they are commonly known. I suggest you instead usue the terms "event hard state" and "event soft state" to match the scope of the definitions. * section 3: > have multiple UAs or endpoints that publish event state. Each > endpoint may publish its own unique state, out of which the event > agent generates the composite event state of the resource. s/event agent/event state compositor * section 3: > Through a > subscription to that event package, "that" is a dangling reference, since you have not yet mentioned that publications address a resouurce and a specific event package. I suggest you make mention of that in the text abvoe * section 3, para 2; > In the generic sense, a UAC that publishes event state is labeled an > Event Publication Agent (EPA) "in the generic sense" implies that there is a more specific case under which the definition can be understood, which is not the case. I suggest removing 'in the generic sense' * section 3, paragraph 3: > That is, the steady-state of > this event package in the absence of, or in addition to, soft state > provided through the PUBLISH mechanism this makes it sound like steady state is a function of the event packae only. the hard state is a function of the resource uRI and event package. Indeed, one may think of an event package as merely sub-resource within the full resource. I wonder if it wouldn't be useful to come up with a term for this - for example, "scoped resource" is a combination of a URI and event package, and identifies a particular piece of event state. * section 3, para 3: > Setting this hard state or > configuring the composer policy is out of the scope of this > specification. you use the term composer here; it should be "event state compositor policy". I know it sounds like a real nit, but having rigorously consistent terminology is really important for new people to pick up the spec and understand it. We were religious about this in RFC 3261. * i suggest moving section 4 to later in the spec. the reason is that section 4 basically gives instructions for packages to use publish, yet it has not said how publish works. that context will be usefull to interpret section 4. * section 4.2: > There is no such meaning for the body of a response to a presence > publication when the document format used is CPIM PIDF. this implies that, in general, the meaning of the body in the response depends on the body in the request. the previous paragraph says that this is rather defined on a package by package basis. I suggest rermoving "when the document format used is CPIM PIDF" * section 4.3: > 4.3 Multple Sources for Event State s/Multple/Multiple * re: table 1, I suggest adding a column which is "Expires value". Without this, there is no way to know whether or not a publish with no body and a sip-if-match is refreshing or deleting. * section 5.1: > Identification of published event state is provided by four pieces of > information: Request-URI, event type, and (optionally) an entity-tag > and the message body. I think its just the first three. the message body itself does not IDENTIFY the event state - it IS the event state. The first three identify it. * section 5.2 > For determining the type of the published event state, the EPA MUST > include a single Event header field in the PUBLISH requests. The s/in the PUBLISH requests/in PUBLISH requests > The > value of this header field indicates the event package, for which > this request is publishing event state. comma in the middle is not needed * section 5.2: > For each successful PUBLISH request, the ESC will generate and assign > an entity-tag and return it in the SIP-ETag header field of the 200 > (OK) response. only 200 OK? Or 2xx? I thihnk its 2xx. * section 5.1: > The presence of a body and the SIP-If-Match header field determine > the specific operation that the request is performing, as described > in Table 1. These operations are described in more detail in the > following sections. it would probably be helpful though to say one sentence here on what each of these mean. * section 5.1: > As with any other SIP message, the PUBLISH mechanism MAY use the > content indirection mechanism defined in [10]. this statement makes [10] a normative reference, I believe. It is listed as informative in the references section. * section 5.2 > The EPA MAY send subsequent PUBLISH requests to refresh, modify, or > remove the event state established by a prior publication and > identified by the associated entity-tag. These operations will be > described in the following sections. this paragraph is redundant. you have already said in 5.1 to see the sections below on how to do reefresh, modify or removal. * section 5.3: > PUBLISH requests SHOULD contain a single Expires header field. i think MAY is sufficient; its a perfectly common case where the EPA jusut doesnt care and wants the server to tell it when to refresh. * section 5.3: > The actual validity period of the soft state is defined > by local policy at the ESC, although typically the event state is > cleared immediately after the publication expires. this sentence might lead one to believe that an ESC can still keep around, and thus use, event state after its actual expiration. That is not a good thing; an ESC MUST expire event state after its expiration. of course this doesnt mean that the data must physically be removed from any dB or memory in the eSC, but rather that the ESC behaves as if the data has been removed. we went through this with registrations. There are serious privacy implications for having the eSC in any way extend the lifetime as suggested by the client. Indeed, section 5.3 shouuld say that the ESC won't ever extend the lifetime of the publication. * section 5.3 is out of place. Section 5 is about generating requests. the subsections for the most part deal with the specific 4 sub-cases you identified in 5.1. However, 5.3 talks about setting expirations, which is something that is actually done for the cases in 5.2, 5.4, 5.5 and 5.6. I would suggest that eaech of those four sections rather describe how the Expires header field is constructed for each case. That is consistent with having a column in table 1 on expires. Indeed, each section should also talk about bodies and etag. Along those lines, section 5.2 does not actually say that a body has to be present; it shouold be stated given the importance of this fact from table 1. * section 5.4: > Note that like any other 200 (OK) response to a PUBLISH, also this > response will contain a SIP-ETag header field with an entity-tag. This is a little awkward. Suggest, "Like the 2xx rersponse to an initial PUBLISH request, the response to a refresh PUBLISH request will contain a SIP-ETag header field with an entity-tag." * section 5.5: > If the entity-tag matches previously > published event state at the ESC, that event state is replaced by the > event state carried in the PUBLISH request, and the EPA receives a > 200 (OK) response. I think we need to be really careful with the words here. What you have writteen actually disallows partial publication as an extension, wherein a UAC could send a publish that modifies a piece of the published state (i.e., change the note in tuple with id "3" to "out to lunch"). Thats because the text says the state is *replaced* by whats in the body. I would prefer to say that the state is updated, and that update depends on the content of the body. If the body contains a format whose semantics are 'this is the state of the resource' then the event state is replaced. * section 5.7 is out of place, since it has nothing to do with constructing publish at all. indeed, since the note basically says that this doesnt work, i would suggest removing the section entirely. It occurs to me that its a huge shame that etags are not URIs. If they weree, we would have a rerally neat way to find out the specific state of a particular publication - you woould subscribe to that etag. The next best thing might be to define a header field in the PUBLISH response that identifies this particular published instance. Hmm, Contact might even be a sensible choice there... worth discussing. I'll send a separate email on the topic. * I suggest changing section 5.8 to a top level section, section 6, and have this be 'processing PUBLISH responses'. it doesnt belong as a subsection of 5, since 5 is about generating requests. Also, sectiono 5.8 should point to 8.1.3 of RfC 3261 and say that those steps apply. * section 6: > PUBLISH requests MUST be processed in the order that they are > received. isnt this only true for requuests with the same r-uri? * section 6: > A client may probe the ESC for the support of PUBLISH using the > OPTIONS request defined in SIP [2]. In the response to such an > OPTIONS request, the ESC SHOULD include "PUBLISH" to the list of > allowed methods in the Allow header field. Also, it SHOULD list the > supported event packages in an Allow-Events header field. > > The "methods" Contact header field parameter may also be used to > specifically announce support for PUBLISH messages when > registering. (See SIP Capabilities [11] for details on the > "methods" parameter). This bit is out of place here, since the section is about publish processing. youo might want to make this section 7, else have section 6 be "ESC behavior" and then have subsections for PUBLISH and OPTIONS processing. Also, the indented note is not correct. Callee caps says that the Allow header should be used. * sectiono 6: The ESC inspects the Request-URI to determine whether this request is targeted to a resource for which the ESC is responsible for maintaining event state. If not, the ESC MUST return a 404 (Not Found) response and skip the remaining steps. this sounds like the publish cant be proxied, which it can. I suppose in such a case, its not an ESC at all, and that ESC is particularly something that processes the request. This should be clarified I think. * sectiono 6, steps 2,3,4 duplicate the behavipr specified in RFC 3261, section 8.2. I suggest referring to that section instead in the beginning of section 6. * the steps in section 6 omit handling for the case where there was no SIP-If-Match header field. step 6 says to check for it, and all the following steps assume it was there. I would suggest adding a bullet to step 6 which says, if there was no SIP-If-Match header field, the ESC creates a new etag, and associates it with as-yet empty event state. Processing continues in the steps below. This way, you always exit step 6 with an etag. * step 8 of section 6: > The ESC processes the published event state, typically contained > in the body of the PUBLISH request. If the request contains no > body (when it should contain one), i think we need to list the conditions for when it should contain one. Indeed, since you are always allowed to publish without a body in order to refresh or delete, under what conditions is it illegal for the body to not be there? * step 8: > * If present, the ESC stores the event state delivered in the > PUBLISH request and identified by the associated entity-tag, > replacing any existing event state for that entity-tag. as above - we need careful wording to allow partial publication * step 9: > The ESC returns a 200 (OK) response. The response MUST contain an > Expires header s/header/header field * step 9: > The response MUST also contain a SIP-ETag header field for > which the ESC MUST generate and store a locally unique entity-tag > for identifying the publication. You should clarify that it generates a new one in each response, and does so for both initial and refreshes. Also, clarify that this etag replaces the previous, such that the previous etag is no longer valid for identifying the publication. * step 9: > After returning the 200 (OK) > response, the state agent associated with this ESC may then issue > appropriate NOTIFY requests to any watchers of this event state. terminology confusioon here. Somoetimes, event state is usued to refer to the inputs of composition. Other times, the unique output associated with the aor. Here, it explicitly refers to the output associated with the aor, which may not even actually change dependening on comoposition policy. * good work on section 7; very concise and clear on the differences with http. * section 8: > As already explained in Section 5.3, choosing the expiration > interval for a publication is ultimately the ESC's responsibility, > and choosing longer expiration values reduces the rate at which > publications are refreshed. Careful - the ESC can't extend the expiration suggested by the client. It can reject one that it thinks is too short, but thats not the same, since the client could give up at that point. So, its not under eSC control completely. * section 9 isnt syntax since it defines the headers as well as the syntax. I would instead suggest following the pattern in rfc3261, and have a section that defines any additional semantics for the headers, methods and response codes, but has no syntax. Then, have a separate section just for bnf. * on evil table 2: | Allow | 2xx | o | | Allow | r | o | these can be folded together * the trend in tables 4/5 is to include columns for each method that has reached rfc. * sectiton 11.1: > Authentication issues are discussed in SIP [2]. The exact methods for > creation and manipulation of the ESC authorization policies are > outside the scope of this document. you will get dinged on this by Bellovin, guaranteed. He wants to see statements about baseline mandtory to implement mechahnisms. Its fine to say that this mechanism is digest, as mandated by rfc3261. > To prevent replay attacks, implementations SHOULD require > authentication with anti-replay protection. Authentication issues are > discussed in SIP [2]. as above.... does this mean digest with next-nonce or are you talking sips? and section 11.4: > To prevent such attacks, implementations SHOULD, at a minimum, > provide integrity protection across the To, From, Event, > SIP-If-Match, Route, and Expires headers and the bodies of PUBLISH > requests. as above, he will ask for a mechanism. This requiurement makes the choice sips. Same in 11.5. * In the examples, I suggest not using net10. You shouold instead use something in 192.0.2.0/24. * i think references 8 and 9 aree normative, since you are mandating a particular publication format (pidf) for usage with the presence event package. Thanks, Jonathan R. Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Session Initiation Protocol Working Group of the IETF. > > Title : Session Initiation Protocol (SIP) Extension for Event > State Publication > Author(s) : A. Niemi > Filename : draft-ietf-sip-publish-02.txt > Pages : 39 > Date : 2004-1-7 > > This document describes an extension to the Session Initiation > Protocol (SIP) for publishing event state used within the framework > for SIP Event Notification. The first application of this extension > is targeted at the publication of presence information. > The mechanism described in this document can be extended to support > publication of any event state, for which there exists an appropriate > event package. It is not intended to be a general-purpose mechanism > for transport of arbitrary data, as there are better-suited > mechanisms for this purpose (FTP, HTTP, etc.) > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-publish-02.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-sip-publish-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-sip-publish-02.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. > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Jan 28 03:01:42 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18336 for ; Wed, 28 Jan 2004 03:01:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlkdP-0007fx-JK for sip-archive@odin.ietf.org; Wed, 28 Jan 2004 03:01:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S81Fkg029446 for sip-archive@odin.ietf.org; Wed, 28 Jan 2004 03:01:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlkdD-0007dx-BF; Wed, 28 Jan 2004 03:01:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alkcr-0007cq-GL for sip@optimus.ietf.org; Wed, 28 Jan 2004 03:00:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18297 for ; Wed, 28 Jan 2004 03:00:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Alkcn-0003o6-00 for sip@ietf.org; Wed, 28 Jan 2004 03:00:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alkbq-0003is-00 for sip@ietf.org; Wed, 28 Jan 2004 02:59:38 -0500 Received: from law9-f40.law9.hotmail.com ([64.4.9.40] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1Alkay-0003XS-00 for sip@ietf.org; Wed, 28 Jan 2004 02:58:44 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 27 Jan 2004 23:58:14 -0800 Received: from 202.88.208.67 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 28 Jan 2004 07:58:13 GMT X-Originating-IP: [202.88.208.67] X-Originating-Email: [aartii@hotmail.com] X-Sender: aartii@hotmail.com From: "Aarti Iyengar" To: sip@ietf.org Date: Wed, 28 Jan 2004 07:58:13 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 28 Jan 2004 07:58:14.0280 (UTC) FILETIME=[7B38E880:01C3E574] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Sip] SIP-T and BICC Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , All, I am trying to understand SIP-T and BICC in detail. >From my initial reading, both are essentially to seamlessly interface the PSTN to broadband networks. SIP-T is specifically for SIP based IP networks, whereas BICC is bearer independent and can interface with IP/ATM networks well. Apart from that, SIP-T deals with ISUP translation and encapsulation while BICC deals with extensions with ISUP for additional bearer support. BICC CS3 will also enable SIP services to co-exist with BICC based networks. My questions are - Are these the only key differences between these protocols which essentially are intended perform the same function? If there are others, what are they? Are there certain situations where one would fit in better than the other, and if so what are these? How well would these interoperate with each other if they have to co-exist? Also, any pointers to urls/whitepapers on the above (BICC versus SIP-T) would be appreciated. thanks Aarti _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Jan 28 06:15:47 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25515 for ; Wed, 28 Jan 2004 06:15:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlnfE-0004l8-Nx for sip-archive@odin.ietf.org; Wed, 28 Jan 2004 06:15:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SBFKJf018236 for sip-archive@odin.ietf.org; Wed, 28 Jan 2004 06:15:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alnew-0004iv-9c; Wed, 28 Jan 2004 06:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlneN-0004i4-6W for sip@optimus.ietf.org; Wed, 28 Jan 2004 06:14:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25481 for ; Wed, 28 Jan 2004 06:14:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlneJ-0005Jo-00 for sip@ietf.org; Wed, 28 Jan 2004 06:14:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlndN-0005FQ-00 for sip@ietf.org; Wed, 28 Jan 2004 06:13:26 -0500 Received: from smtp2.dataconnection.com ([192.91.191.8] helo=miles.dataconnection.com) by ietf-mx with esmtp (Exim 4.12) id 1AlncS-00057V-00 for sip@ietf.org; Wed, 28 Jan 2004 06:12:29 -0500 Received: by miles.datcon.co.uk with Internet Mail Service (5.5.2656.59) id ; Wed, 28 Jan 2004 11:11:54 -0000 Message-ID: From: Paul Drew To: "'Cullen Jennings'" , SIP WG Subject: RE: [Sip] New ID related to voicemail and history requirements Date: Wed, 28 Jan 2004 11:11:47 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Cullen, This draft seems to address the same requirements as http://www.ietf.org/internet-drafts/draft-levy-sip-diversion-07.txt, which specifies a Diversion header to contain the target and reason parameter. Is there a preferred working group direction to address this issue? In addition the Referred-By header specified in draft-ietf-sip-referredby-03 addresses a similar related issue. Regards, Paul ------------ Paul Drew Product Manager MetaSwitch mailto: pd@metaswitch.com http://www.metaswitch.com Tel: +44 (0) 1244 305220 Fax +44 (0) 1244 312422 MetaSwitch is a division of Data Connection (DCL) -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: 19 October 2003 10:18 To: sip@ietf.org Cc: Cullen Jennings Subject: [Sip] New ID related to voicemail and history requirements I have submitted a new draft that deals with meeting a subset of the "history" requirements for sending calls to voicemail systems. Until it shows up in the archive, you can find it at: http://www.employees.org/~fluffy/ietf/ draft-jennings-sip-voicemail-uri-00.txt Or http://www.employees.org/~fluffy/ietf/ draft-jennings-sip-voicemail-uri-00.html Cullen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Jan 28 09:33:45 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01978 for ; Wed, 28 Jan 2004 09:33:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alqkn-0001pF-CA for sip-archive@odin.ietf.org; Wed, 28 Jan 2004 09:33:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SEXHL1007011 for sip-archive@odin.ietf.org; Wed, 28 Jan 2004 09:33:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlqkX-0001o3-G7; Wed, 28 Jan 2004 09:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alqk5-0001nC-IL for sip@optimus.ietf.org; Wed, 28 Jan 2004 09:32:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01960 for ; Wed, 28 Jan 2004 09:32:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Alqk3-0005tB-00 for sip@ietf.org; Wed, 28 Jan 2004 09:32:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alqj8-0005pM-00 for sip@ietf.org; Wed, 28 Jan 2004 09:31:35 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AlqiQ-0005lN-00 for sip@ietf.org; Wed, 28 Jan 2004 09:30:50 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0SEUlY03614 for ; Wed, 28 Jan 2004 16:30:48 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 28 Jan 2004 16:24:36 +0200 Received: from nokia.com ([172.21.11.146]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 28 Jan 2004 16:24:33 +0200 Message-ID: <4017C622.2050507@nokia.com> Date: Wed, 28 Jan 2004 16:24:34 +0200 From: "Niemi Aki (Nokia-M/Helsinki)" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Jonathan Rosenberg CC: sip@ietf.org Subject: Re: [Sip] querying the current event state of a publication References: <4012E741.5000809@dynamicsoft.com> In-Reply-To: <4012E741.5000809@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jan 2004 14:24:33.0844 (UTC) FILETIME=[7351AF40:01C3E5AA] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Inline. ext Jonathan Rosenberg wrote: > In draft-ietf-sip-publish-02, section 5.7 proposes a way to query a > specific published event state. It recommends subscribing to the AOR to > learn it. However, it gives this caveat: > > Note that a subscription to the event package will likely deliver > results of the event composition process of the state agent, which > may be a subset or a superset of the current published event > state. > > which is another way of saying, that subscribing to the aor doesnt > really allow you to query for a specific published event state. > > If we want this functionality, I have an idea for an alternative > approach that works much better, triggered by some conversations I had > with Ben C. recently. > > In the response to a PUBLISH request, the ESC returns a URI that > identifies that particular event state publication (effectively, a URI > that is bound to the AOR+event+etag of a publication). This URI is > basically a GRUU. If a user wishes to learn the state of this particular > event state, they merely subscribe to that URI. Indeed, a particularly > interestinig way to do this is to define sIP etags as URIs, rather than > reusing the definition from http. I think that having an etag as a URI > is far more elegant, as it would allow for things like this function in > a natural way. The alternative would be to possibly use the Contact > header field, as the meaning is the same as in a 2xx to INVITE - > identifying the specific *instance* to which you were connected when you > contacted the AOR. This makes sense if you think of the event state > publication URI as a GRUU. But a PUA has to know the state it just published, simply because it was the source of that state in the first place. What it can't learn is the state of the other active PUAs. And this is actually something currently missing from PUBLISH. A given PUA can't find out about publications other than thiose it itself has made. As a consequence, it can't for example, override the publications of a zombie PUA (a use case we have discussed in the past at length). In order to enable a PUA to find out about the *other* publications to a given resource, the ESC would have to return not only a pointer to this PUAs publication, but to all active publications for that AoR. This is very similar to a registrar returning all active address bindings of an AoR. > Indeed, one might even then PUBLISH to that URI, and it would have the > exact result you would expect - that particular event state is updated. > In such a case the server woould NOT return an etag or another URI in > the response. When you add the feature I describe above, etags would still be needed since it would allow two PUAs to publish to the same instance of state. Etags would be needed for versioning in that case. > This would mean we wouldnt need the SIP-If-match. > > Another alternative is to say that we are simply too far along in > PUBLISH, and the time has passed for major changes as this would be. I do think we are quite far along in PUBLISH for adding this sort of functionality. However, I see some low-hanging fruit here, and to be honest, it has always bothered me a bit that there is no way for a PUA to know about the state other PUAs are publishing. There is a requirement that calls for basically exactly this in draft-ietf-simple-publish-reqs-00 and it states: 14. PUAs must have a capability that allows them to query for the identifiers of all of the segments of presence information that have currently been published for a presentity (provided that the PUA is authorized to receive this information). Using the register-like behavior for returning the set of active state in the 2xx response to PUBLISH + having this set be a set of GRUUs would fulfill the above. The PUA would be able to query the state (using SUBSCRIBE), but also override it (using PUBLISH). This is also a requireemnt in the reqs draft: 15. It must be possible for the publication of presence information for a particular segment to overwrite existing information for that segment, even if the existing information had been published by a different PUA. ... So I would be willing to add this functionality simply because it would make the solution more complete. As far as adding complexity, sure, but an ESC whose policy doesn't allow cross PUA state could always just refuse to send the publication contacts in the PUBLISH response. Does this sound reasonable? Cheers, Aki P.S. I added an example message flow to illustrate the above ramblings... --- PUA publishes its (initial) state: PUBLISH sip:presentity@example.com SIP/2.0 To: From: ;tag=54321mm Expires: 3600 Event: presence ... ESC returns with an etag for that state, plus all active publications in the form of URIs: SIP/2.0 200 OK To: ;tag=effe22aa From: ;tag=54321mm SIP-ETag: qwi982ks Expires: 3600 Contact: sip:kaskjsdh@pa.example.com;etag=qwi982ks;expires=3600 Contact: sip:jhsk23jj@pa.example.com;etag=hh3j4kll;expires=3229 Contact: sip:hhfkjhjk@pa.example.com;etag=3ihy4hhk;expires=1200 > Thoughts? > > -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 exim@www1.ietf.org Wed Jan 28 12:41:10 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16232 for ; Wed, 28 Jan 2004 12:41:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Altg9-0008IC-Ns for sip-archive@odin.ietf.org; Wed, 28 Jan 2004 12:40:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SHef5f031869 for sip-archive@odin.ietf.org; Wed, 28 Jan 2004 12:40:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Altfa-0008Gn-1b; Wed, 28 Jan 2004 12:40:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AltfB-0008FW-4m for sip@optimus.ietf.org; Wed, 28 Jan 2004 12:39:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16173 for ; Wed, 28 Jan 2004 12:39:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Altf9-0004Wx-00 for sip@ietf.org; Wed, 28 Jan 2004 12:39:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlteD-0004Rz-00 for sip@ietf.org; Wed, 28 Jan 2004 12:38:41 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AltdT-0004Hg-00 for sip@ietf.org; Wed, 28 Jan 2004 12:37:55 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 28 Jan 2004 09:37:24 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id i0SHbHnI004725; Wed, 28 Jan 2004 09:37:21 -0800 (PST) Received: from [128.107.171.228] ([128.107.171.228]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ALV40263; Wed, 28 Jan 2004 09:37:17 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Wed, 28 Jan 2004 09:37:16 -0800 Subject: Re: [Sip] New ID related to voicemail and history requirements From: Cullen Jennings To: Paul Drew , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Well, it's always hard to speak for the whole WG :-) The history work has been adopted as a WG item - the others have not. One of the key things holding history back is that some people thought an idea using URI was more appropriate. I carefully wrote down these URI idea as best I could in draft-jennings-sip-voicemail-uri so it can be discussed and compared to history. Then the WG can decide what to do. Options include History, both, none. I could be completely wrong in my next statement but, it is my personal best guess that the SIP WG is highly unlikely to make draft-levy-sip-diversion a WG item for a standards track RFC. I think they are more likely to decide that text encoding was a bad idea, deprecate forking, then deprecate INVITE and replace with two methods called OFFER and ANSWER. Statements like "over my dead body" don't bode well for a draft getting WG consensus. We do need a solution to the set of problems these drafts address. I really hope we choose one, anything, some time soon. Cullen On 1/28/04 3:11 AM, "Paul Drew" wrote: > Cullen, > > This draft seems to address the same requirements as > http://www.ietf.org/internet-drafts/draft-levy-sip-diversion-07.txt, which > specifies a Diversion header to contain the target and reason parameter. > > Is there a preferred working group direction to address this issue? > > In addition the Referred-By header specified in draft-ietf-sip-referredby-03 > addresses a similar related issue. > > Regards, > > Paul > > ------------ > Paul Drew > Product Manager > MetaSwitch > > mailto: pd@metaswitch.com > http://www.metaswitch.com > Tel: +44 (0) 1244 305220 Fax +44 (0) 1244 312422 > MetaSwitch is a division of Data Connection (DCL) > > > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: 19 October 2003 10:18 > To: sip@ietf.org > Cc: Cullen Jennings > Subject: [Sip] New ID related to voicemail and history requirements > > > > I have submitted a new draft that deals with meeting a subset of the > "history" requirements for sending calls to voicemail systems. Until it > shows up in the archive, you can find it at: > > http://www.employees.org/~fluffy/ietf/ > draft-jennings-sip-voicemail-uri-00.txt > > Or > > http://www.employees.org/~fluffy/ietf/ > draft-jennings-sip-voicemail-uri-00.html > > Cullen > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Jan 28 14:41:39 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22830 for ; Wed, 28 Jan 2004 14:41:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlvYl-0001sp-S9 for sip-archive@odin.ietf.org; Wed, 28 Jan 2004 14:41:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SJfBOL007179 for sip-archive@odin.ietf.org; Wed, 28 Jan 2004 14:41:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlvYc-0001lX-SH; Wed, 28 Jan 2004 14:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlvYN-0001kO-Au for sip@optimus.ietf.org; Wed, 28 Jan 2004 14:40:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22781 for ; Wed, 28 Jan 2004 14:40:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlvYK-0001hS-00 for sip@ietf.org; Wed, 28 Jan 2004 14:40:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlvXL-0001a0-00 for sip@ietf.org; Wed, 28 Jan 2004 14:39:44 -0500 Received: from [62.119.82.43] (helo=hotsip.com) by ietf-mx with esmtp (Exim 4.12) id 1AlvWP-0001O9-00 for sip@ietf.org; Wed, 28 Jan 2004 14:38:45 -0500 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: GRUU and UA instances, was: Re: [Sip] Subscribe dialog and target refresh request Date: Wed, 28 Jan 2004 20:38:13 +0100 Message-ID: Thread-Topic: GRUU and UA instances, was: Re: [Sip] Subscribe dialog and target refresh request Thread-Index: AcPUJWn3qc/f1d3FQ++MZQOH5gkkuQRrtFxAAABIjYAAAAB5cAAAACugAAAAc0AAAAAlcA== From: "Christian Jansson" To: "Jonathan Rosenberg" , "Paul Kyzivat" Cc: , , , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Perhaps a little late, and hopefully not off topic. Comments inline. > Jonathan R. wrote > This, however, leads me into thinking a bit on the lifecycle > management for GRUUs. Currently, GRUU is bound to a single=20 > registration, where the registration is defined by the Contact URI. If > the UA should "move", in the sense that it acquires a new IP address,=20 > this will be a new Contact URI, and therefore, a new GRUU. It would be > nice if, instead, the GRUU were truly bound to the UA instance, and=20 > that even if the UA instance changed IP addresses, the GRUU could=20 > remain unchanged. In such a case, if the UA moves, there is actually=20 > no need to issue any target refresh requests. The UA would simply=20 > re-register, update the binding of its GRUU to its new IP=20 > address, and=20 > existing calls would be correctly routed. But if the ip actually changes, it would be necessary to send an updated SDP with the new ip in the c=3D line. So your idea won't save you from having to send a SIP request to the other end every time the ip changes in an INVITE session. For a non-INVITE session though the idea would save a lot of request from being sent if the session only contains signaling. / Christian Jansson _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Jan 28 20:26:48 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10722 for ; Wed, 28 Jan 2004 20:26:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am0wl-0001Sr-JL for sip-archive@odin.ietf.org; Wed, 28 Jan 2004 20:26:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0T1QJc3005569 for sip-archive@odin.ietf.org; Wed, 28 Jan 2004 20:26:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am0wU-0001Ne-NN; Wed, 28 Jan 2004 20:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am0wM-0001Mw-Il for sip@optimus.ietf.org; Wed, 28 Jan 2004 20:25:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10694 for ; Wed, 28 Jan 2004 20:25:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Am0wK-0006wa-00 for sip@ietf.org; Wed, 28 Jan 2004 20:25:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Am0vS-0006rn-00 for sip@ietf.org; Wed, 28 Jan 2004 20:24:58 -0500 Received: from lancelot.cit.uws.edu.au ([137.154.148.30]) by ietf-mx with esmtp (Exim 4.12) id 1Am0uu-0006ml-00 for sip@ietf.org; Wed, 28 Jan 2004 20:24:25 -0500 Received: from oberon.cit.uws.edu.au (oberon.cit.uws.edu.au [137.154.148.13]) by lancelot.cit.uws.edu.au (8.12.10/8.12.6) with ESMTP id i0T1ODOG326972 for ; Thu, 29 Jan 2004 12:24:13 +1100 (EST) Received: from 137.154.148.80 (astolat.cit.uws.edu.au [137.154.148.33]) by oberon.cit.uws.edu.au (8.12.10/8.12.5) with SMTP id i0T1ODN5066845 for ; Thu, 29 Jan 2004 12:24:13 +1100 (EST) Message-ID: X-Mailer: BasiliX 1.0.4b -- http://basilix.org X-SenderIP: 137.154.148.80 Date: Thu, 29 Jan 2004 12:24:13 +1000 (EST) From: Davinder S Bains To: sip@ietf.org X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=3.078, required 5, INVALID_MSGID, MSGID_NO_HOST) X-MailScanner-SpamScore: sss X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.1 required=5.0 tests=AWL,INVALID_MSGID, MSGID_NO_HOST autolearn=no version=2.60 Subject: [Sip] Multiple URIs in a Request Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi all, I am doing research on VoIP. I have not been able to find methods of doing conferencing in SIP in the RFC3261. As per my understanding it is not mentioned that a UA should only use one SIP URI in the request. The question I have is, 1) Is it possible for a UA to send INVITE request with multiple SIP URIs as in e-mail addresses separated with semi-columns. 2) If possible,what shall the proxy server do with that Invite request, request not valid or other response? 3) If not,then how a conference call is established and controlled ? Any comments and answers to help would be appreciated, thanks, Davinder S Bains Room: Y3-24, School of Computing and Information Technology University of Western Sydney Locked Bag 1797 Penrith South DC NSW 1797 Australia Ph : 61 2 4736 0862 Mob: 0425351960 Email : dbains@cit.uws.edu.au Scanned by SCIT E-Mail Gateway http://www.cit.uws.edu.au _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jan 29 02:05:54 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29070 for ; Thu, 29 Jan 2004 02:05:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am6Ev-0004XL-R6 for sip-archive@odin.ietf.org; Thu, 29 Jan 2004 02:05:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0T75P8N017382 for sip-archive@odin.ietf.org; Thu, 29 Jan 2004 02:05:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am6EZ-0004KY-DK; Thu, 29 Jan 2004 02:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am6De-0003zn-CP for sip@optimus.ietf.org; Thu, 29 Jan 2004 02:04:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27087 for ; Thu, 29 Jan 2004 02:04:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Am6Da-0002uD-00 for sip@ietf.org; Thu, 29 Jan 2004 02:04:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Am6Cf-0002pN-00 for sip@ietf.org; Thu, 29 Jan 2004 02:03:06 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1Am6CJ-0002k9-00 for sip@ietf.org; Thu, 29 Jan 2004 02:02:43 -0500 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i0T721bj001632; Thu, 29 Jan 2004 01:02:02 -0600 (CST) Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.31.36]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id CR573ALD; Thu, 29 Jan 2004 01:01:38 -0600 Message-ID: <4018AFEC.3040907@ericsson.com> Date: Thu, 29 Jan 2004 09:02:04 +0200 X-Sybari-Trust: 75159c87 76be5e0c 125231cb 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Davinder S Bains CC: sip@ietf.org Subject: Re: [Sip] Multiple URIs in a Request References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit You may want to read this draft: http://www.ietf.org/internet-drafts/draft-camarillo-sipping-uri-list-00.txt Gonzalo Davinder S Bains wrote: > Hi all, > I am doing research on VoIP. > I have not been able to find methods of doing conferencing in SIP in the RFC3261. > As per my understanding it is not mentioned that a UA should only use one SIP URI in the request. > The question I have is, > > 1) Is it possible for a UA to send INVITE request with multiple SIP URIs as in e-mail addresses separated with semi-columns. > 2) If possible,what shall the proxy server do with that Invite request, request not valid or other response? > 3) If not,then how a conference call is established and controlled ? > > Any comments and answers to help would be appreciated, > thanks, > > Davinder S Bains _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jan 29 08:17:55 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15938 for ; Thu, 29 Jan 2004 08:17:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmC2w-0005eX-1v for sip-archive@odin.ietf.org; Thu, 29 Jan 2004 08:17:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0TDHQ8p021726 for sip-archive@odin.ietf.org; Thu, 29 Jan 2004 08:17:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmC2X-0005bY-9c; Thu, 29 Jan 2004 08:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmC1t-0005ap-MX for sip@optimus.ietf.org; Thu, 29 Jan 2004 08:16:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15912 for ; Thu, 29 Jan 2004 08:16:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmC1s-0001sR-00 for sip@ietf.org; Thu, 29 Jan 2004 08:16:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmC0z-0001mc-00 for sip@ietf.org; Thu, 29 Jan 2004 08:15:26 -0500 Received: from pooh.ulticom.com ([208.255.120.2] helo=chuckie.dgms.com) by ietf-mx with esmtp (Exim 4.12) id 1AmC0f-0001gn-00 for sip@ietf.org; Thu, 29 Jan 2004 08:15:05 -0500 Received: from ulticom.com (localhost [127.0.0.1]) by chuckie.dgms.com (8.9.3/8.9.3) with ESMTP id IAA29534; Thu, 29 Jan 2004 08:15:00 -0500 (EST) Message-ID: <40190753.4020102@ulticom.com> Date: Thu, 29 Jan 2004 08:14:59 -0500 From: Steve Pellegrino User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Davinder S Bains CC: sip Subject: Re: [Sip] Multiple URIs in a Request References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit There are several internet drafts by the sipping WG that you may find useful, especially: http://www.ietf.org/internet-drafts/draft-ietf-sipping-conferencing-framework-01.txt You can find the rest here: http://www.ietf.org/html.charters/sipping-charter.html Regards, Steve Davinder S Bains wrote: >Hi all, >I am doing research on VoIP. >I have not been able to find methods of doing conferencing in SIP in the RFC3261. >As per my understanding it is not mentioned that a UA should only use one SIP URI in the request. >The question I have is, > >1) Is it possible for a UA to send INVITE request with multiple SIP URIs as in e-mail addresses separated with semi-columns. >2) If possible,what shall the proxy server do with that Invite request, request not valid or other response? >3) If not,then how a conference call is established and controlled ? > >Any comments and answers to help would be appreciated, >thanks, > >Davinder S Bains >Room: Y3-24, >School of Computing and Information Technology >University of Western Sydney >Locked Bag 1797 >Penrith South DC NSW 1797 >Australia > >Ph : 61 2 4736 0862 >Mob: 0425351960 >Email : dbains@cit.uws.edu.au > > >Scanned by SCIT E-Mail Gateway http://www.cit.uws.edu.au > > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Jan 30 00:24:43 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13455 for ; Fri, 30 Jan 2004 00:24:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmR8a-0001NR-FQ for sip-archive@odin.ietf.org; Fri, 30 Jan 2004 00:24:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0U5OG0B005289 for sip-archive@odin.ietf.org; Fri, 30 Jan 2004 00:24:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmR8L-0001MH-N5; Fri, 30 Jan 2004 00:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmR8C-0001Ld-WB for sip@optimus.ietf.org; Fri, 30 Jan 2004 00:23:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13336 for ; Fri, 30 Jan 2004 00:23:49 -0500 (EST) From: ranjit.avasarala@wipro.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmR8A-0005Re-00 for sip@ietf.org; Fri, 30 Jan 2004 00:23:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmR7D-0005Lr-00 for sip@ietf.org; Fri, 30 Jan 2004 00:22:52 -0500 Received: from wiproecmx1.wipro.com ([164.164.31.5]) by ietf-mx with esmtp (Exim 4.12) id 1AmR6X-00059L-00 for sip@ietf.org; Fri, 30 Jan 2004 00:22:14 -0500 Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx1.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i0U5LbvC018962 for ; Fri, 30 Jan 2004 10:51:38 +0530 (IST) Received: from blr-ec-bh2.wipro.com ([10.200.50.92]) by ec-vwall-wd with InterScan Messaging Security Suite; Fri, 30 Jan 2004 10:52:44 +0530 Received: from blr-ec-msg03.wipro.com ([10.200.52.99]) by blr-ec-bh2.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 30 Jan 2004 10:51:37 +0530 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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] SIP-T and BICC Date: Fri, 30 Jan 2004 10:51:37 +0530 Message-ID: Thread-Topic: [Sip] SIP-T and BICC Thread-Index: AcPldgUpljJf0HNBRc2F1DRdqcPH6ABeqgYA To: , X-OriginalArrivalTime: 30 Jan 2004 05:21:37.0189 (UTC) FILETIME=[EEF21D50:01C3E6F0] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi You can refer RFC 3372 for SIP-T Context and Architecture.=20 Ranjit Ph: 8520408/16 extn: 2173 -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Aarti Iyengar Sent: Wednesday, January 28, 2004 1:28 PM To: sip@ietf.org Subject: [Sip] SIP-T and BICC All, I am trying to understand SIP-T and BICC in detail. >From my initial reading, both are essentially to seamlessly interface the=20 PSTN to broadband networks. SIP-T is specifically for SIP based IP networks,=20 whereas BICC is bearer independent and can interface with IP/ATM networks=20 well. Apart from that, SIP-T deals with ISUP translation and encapsulation=20 while BICC deals with extensions with ISUP for additional bearer support. BICC CS3 will also enable SIP services to co-exist with BICC based networks. My questions are - Are these the only key differences between these protocols which essentially=20 are intended perform the same function? If there are others, what are they? Are there certain situations where one would fit in better than the other,=20 and if so what are these? How well would these interoperate with each other if they have to co-exist? Also, any pointers to urls/whitepapers on the above (BICC versus SIP-T)=20 would be appreciated. thanks Aarti _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*.=20 http://join.msn.com/?page=3Dfeatures/featuredemail _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Jan 30 10:32:46 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22131 for ; Fri, 30 Jan 2004 10:32:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amad0-00056i-Ay for sip-archive@odin.ietf.org; Fri, 30 Jan 2004 10:32:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UFWI9c019633 for sip-archive@odin.ietf.org; Fri, 30 Jan 2004 10:32:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amack-00054T-3o; Fri, 30 Jan 2004 10:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmacF-000533-V4 for sip@optimus.ietf.org; Fri, 30 Jan 2004 10:31:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22058 for ; Fri, 30 Jan 2004 10:31:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmacD-00034A-00 for sip@ietf.org; Fri, 30 Jan 2004 10:31:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmabA-0002vb-00 for sip@ietf.org; Fri, 30 Jan 2004 10:30:25 -0500 Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx with esmtp (Exim 4.12) id 1AmaaS-0002lP-00 for sip@ietf.org; Fri, 30 Jan 2004 10:29:40 -0500 Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0UFR6822491; Fri, 30 Jan 2004 10:27:06 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id D5AQ73WS; Fri, 30 Jan 2004 10:27:06 -0500 Received: from nortelnetworks.com (acart1mk.ca.nortel.com [47.129.130.72]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DBDZJCDX; Fri, 30 Jan 2004 10:27:06 -0500 Message-ID: <401A77C9.2000401@nortelnetworks.com> Date: Fri, 30 Jan 2004 10:27:05 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aarti Iyengar CC: sip@ietf.org Subject: Re: [Sip] SIP-T and BICC References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The BICC work was originally started to extend ISUP capabilities to ATM networks, and this was what BICC CS1 achieved. The work took on a life of its own, and BICC CS2 supports voice over IP networks. I'm not sure BICC CS3 will ever happen -- it seems to have bogged down. The specific advantage of BICC is that it can take advantage of already-installed SS7 infrastructure. One can use SIP to make connections across ATM networks, using the attributes and conventions defined in RFC 3108. Unfortunately some of the syntax in that document (for the m= line) does not conform to the latest SDP syntax as defined in draft-ietf-mmusic-sdp-new-15.txt. The key point of SIP-T is to provide a transition mechanism from a mixed legacy/SIP network to a pure SIP network. If you install a BICC network, you have to install a parallel SIP network to handle multimedia and new services. You face a problem when you eventually want to move voice services onto the SIP network to achieve savings through network and service integration. So the brief answer is that the two protocols overlap in functionality, but which to use is an interesting strategic decision depending on what you have in your network already and what services you plan to offer in the future. Aarti Iyengar wrote: > All, > I am trying to understand SIP-T and BICC in detail. > >> From my initial reading, both are essentially to seamlessly interface the > > PSTN to broadband networks. SIP-T is specifically for SIP based IP > networks, whereas BICC is bearer independent and can interface with > IP/ATM networks well. Apart from that, SIP-T deals with ISUP translation > and encapsulation while BICC deals with extensions with ISUP for > additional bearer support. > BICC CS3 will also enable SIP services to co-exist with BICC based > networks. > My questions are - > Are these the only key differences between these protocols which > essentially are intended perform the same function? If there are others, > what are they? > Are there certain situations where one would fit in better than the > other, and if so what are these? > How well would these interoperate with each other if they have to co-exist? > > Also, any pointers to urls/whitepapers on the above (BICC versus SIP-T) > would be appreciated. > > thanks > Aarti > > _________________________________________________________________ > Add photos to your e-mail with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Jan 30 11:29:38 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24832 for ; Fri, 30 Jan 2004 11:29:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmbW2-0005wE-KJ for sip-archive@odin.ietf.org; Fri, 30 Jan 2004 11:29:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UGTA9U022820 for sip-archive@odin.ietf.org; Fri, 30 Jan 2004 11:29:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmbVt-0005si-WF; Fri, 30 Jan 2004 11:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmbVB-0005qj-FR for sip@optimus.ietf.org; Fri, 30 Jan 2004 11:28:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24713 for ; Fri, 30 Jan 2004 11:28:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmbVA-0002YX-00 for sip@ietf.org; Fri, 30 Jan 2004 11:28:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmbUD-0002OS-00 for sip@ietf.org; Fri, 30 Jan 2004 11:27:18 -0500 Received: from smtp.dataconnection.com ([192.91.191.4] helo=coltrane.dataconnection.com) by ietf-mx with esmtp (Exim 4.12) id 1AmbTJ-00028q-00 for sip@ietf.org; Fri, 30 Jan 2004 11:26:21 -0500 Received: by coltrane.datcon.co.uk with Internet Mail Service (5.5.2656.59) id ; Fri, 30 Jan 2004 16:25:41 -0000 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F802620052@baker.datcon.co.uk> From: "Paul D.Smith" To: "'brett@broadsoft.com'" Cc: SIP WG Date: Fri, 30 Jan 2004 16:25:38 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Sip] RE: [Sip-implementors] Via: processing Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Brett, Arlie, RFC3261 clearly allows a response to be "rerouted" if it can be determined that the response did not reach the first-attempt target. For example, if the request is received over TCP, and the connection has gone and cannot be reestablished by the time the response is ready to be sent back, RFC3261 states the following --- from RFC3261, section 18.2.2, 1st bullet. If that connection attempt fails, the server SHOULD use the procedures in [4] for servers in order to determine the IP address and port to open the connection and send the response to. --- end of cut RFC3263 then gives an algorithm for attempting to determine alternate IP addresses to which the response might be sent. Clearly having an FQDN in the sent-by will give a chance of success which having an IP address will not, especially if the sent-by and received IP addresses are the same! Paul DS. Paul D.Smith Network Protocols Group Data Connection Ltd (DCL) Tel: +44 20 8366 1177 Email: paul.d.smith@dataconnection.com Fax: +44 20 8363 1039 Web: http://www.dataconnection.com -----Original Message----- From: Brett Tate [mailto:brett@broadsoft.com] Sent: 29 January 2004 00:27 To: SIP (E-mail) Subject: RE: [Sip-implementors] Via: processing > I'm looking at the spec for Via: processing. > RFC 3261 clearly shows that a Via: line can > contain DNS names, as well as textual > representations of network addresses. > > How many products actually implement support > for resolving DNS names provided in Via: lines? Not very many support DNS resolution of a Via entry. However many support the concept of adding the Via's received parameter when it does not match the Via's sent-by address. > This seems... well, it seems unnecessary, > potentially insecure (allowing for easy DDoS > and potentially amplification attacks), and > just a general nuisance. Is this kind of > thing ever actually used for a good purpose? Some people have toyed with the idea of advancing response addresses based upon rfc3263 during failure situations. > Does any product do anything *but* just put > real network addresses in Via: lines in > requests? Yes. _______________________________________________ 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