From mailman-bounces@ietf.org Mon Nov 1 08:04:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28373 for ; Mon, 1 Nov 2004 08:04:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COc6L-0006hI-5Z for sip-web-archive@ietf.org; Mon, 01 Nov 2004 08:20:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COZby-0001w5-2O for sip-web-archive@ietf.org; Mon, 01 Nov 2004 05:40:30 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: sip-web-archive@ietf.org X-No-Archive: yes Message-ID: Date: Mon, 01 Nov 2004 05:16:25 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for sip-web-archive@ietf.org: List Password // URL ---- -------- sip@ietf.org toufat https://www1.ietf.org/mailman/options/sip/sip-web-archive%40ietf.org From sip-bounces@ietf.org Mon Nov 1 11:02:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25321 for ; Mon, 1 Nov 2004 11:02:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COesf-00020F-7F for sip-web-archive@ietf.org; Mon, 01 Nov 2004 11:18:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COdNr-0007mW-6F; Mon, 01 Nov 2004 09:42:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COZv5-0000lB-6S for sip@megatron.ietf.org; Mon, 01 Nov 2004 06:00:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16302 for ; Mon, 1 Nov 2004 06:00:13 -0500 (EST) Received: from endor.rfc3261.net ([212.112.227.208]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COa9y-0004K4-0r for sip@ietf.org; Mon, 01 Nov 2004 06:15:38 -0500 Received: from localhost (localhost [127.0.0.1]) by endor.rfc3261.net (Postfix) with ESMTP id 2297D26000F; Mon, 1 Nov 2004 11:59:42 +0100 (CET) Received: from endor.rfc3261.net ([127.0.0.1]) by localhost (endor [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 31440-04; Mon, 1 Nov 2004 11:59:41 +0100 (CET) Received: from quickstep.intern.snom.de (pD9568A0D.dip.t-dialin.net [217.86.138.13]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by endor.rfc3261.net (Postfix) with ESMTP id 736E726000E; Mon, 1 Nov 2004 11:59:41 +0100 (CET) From: Nils Ohlmeier To: Robert Sparks Subject: Re: [Sip] LC on nit-actions and nit-problems Date: Mon, 1 Nov 2004 11:59:35 +0100 User-Agent: KMail/1.7 References: <7104FE6A-29D8-11D9-B9E5-000D93326732@xten.com> In-Reply-To: <7104FE6A-29D8-11D9-B9E5-000D93326732@xten.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200411011159.35876.lists@ohlmeier.org> X-Virus-Scanned: by amavisd-new (Debian) at endor.rfc3261.net X-Spam-Score: 0.2 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Hi Robert, as I did not found anything about that in the list archives: how about the UAC ignores the 100 Trying response for setting Timer E to T2? I mean the UAC should not set Timer E to T2 if it receives a 100 Trying while Timer E < T2. So the 100 Trying will be treated as "I'm alive" for the possible DNS cache, but Timer E will be increased normaly as if no response would have been received. I think that could improve the reliability and should not harm. Maybe I'm overseeing something here, so comments are welcome. Greetings Nils Ohlmeier On Friday 29 October 2004 20:29, Robert Sparks wrote: > Folks - > > WGLC for the nit actions and problems draft started Oct 20 and is > scheduled to > end November 3 (next Wednesday). > > So far I have received _no_ comments. > > I believe that's because these drafts have been thoroughly discussed, > are well > understood, and they are ready to go (the points where more discussion > is needed > have all been moved to nit-future). > > If you agree, please take a moment to send a note to the list saying "I > read this draft > and believe it is ready to be published". > > If you disagree - now is the time to comment! > > Thanks, > RjS > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 1 13:12:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12583 for ; Mon, 1 Nov 2004 13:12:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COguU-0006kb-Fp for sip-web-archive@ietf.org; Mon, 01 Nov 2004 13:28:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COg6Q-0001mz-B1; Mon, 01 Nov 2004 12:36:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COfoh-0005Vp-5A; Mon, 01 Nov 2004 12:18:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05464; Mon, 1 Nov 2004 12:18:01 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COg3c-0004je-Jt; Mon, 01 Nov 2004 12:33:30 -0500 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id iA1HGai14008; Mon, 1 Nov 2004 09:16:36 -0800 (PST) Message-Id: <200411011716.iA1HGai14008@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Mon, 01 Nov 2004 09:16:37 -0800 X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: sip@ietf.org, rfc-editor@rfc-editor.org Subject: [Sip] RFC 3903 on Session Initiation Protocol (SIP) Extension for Event State Publication X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3903 Title: Session Initiation Protocol (SIP) Extension for Event State Publication Author(s): A. Niemi, Ed. Status: Standards Track Date: October 2004 Mailbox: aki.niemi@nokia.com Pages: 32 Characters: 72062 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sip-publish-04.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3903.txt This document describes an extension to the Session Initiation Protocol (SIP) for publishing event state used within the SIP Events framework. The first application of this extension is for 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. This document is a product of the Session Initiation Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <041101091455.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3903 --OtherAccess Content-Type: Message/External-body; name="rfc3903.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <041101091455.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Mon Nov 1 14:25:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20098 for ; Mon, 1 Nov 2004 14:25:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COi2n-0000W6-Mw for sip-web-archive@ietf.org; Mon, 01 Nov 2004 14:40:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COhdy-0005Bq-TL; Mon, 01 Nov 2004 14:15:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COhSo-0007It-TT for sip@megatron.ietf.org; Mon, 01 Nov 2004 14:03:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18012 for ; Mon, 1 Nov 2004 14:03:32 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COhhl-0008Nc-EW for sip@ietf.org; Mon, 01 Nov 2004 14:19:02 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 01 Nov 2004 14:26:23 -0500 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iA1J2vv9026743; Mon, 1 Nov 2004 14:03:01 -0500 (EST) Received: from lookout.cisco.com (lookout.cisco.com [64.102.17.218]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BDB58808; Mon, 1 Nov 2004 11:02:56 -0800 (PST) Date: Mon, 1 Nov 2004 14:02:56 -0500 (EST) From: Sheetal Khemani To: sip@ietf.org, sip-implementors@cs.columbia.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Sip] SIP AMR Codec (RFC3267) out-of-band bitrate change X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Hi, I want to know if AMR mode changes are supported via SIP/SDP (possibly using a new off in a reINVITE). RFC3267 doesn't mention any parameter in the SDP to change the bitrate during the call using SIP. It allows the mode-set parameter that tells the encoder the subset of modes/bitrates it can use. It doesn't allow the specification of the bitrate the other end needs to use/switch-to. I came across some 3GPP docs (3GPP TS 26.236: Packet switched conversational multimedia applications; Transport protocols) that suggest using the bandwidth paramter, but that seems to be specific to QoS and I am not sure if this applies to the SIP standard per se. Please let me know if anyone has any insight on this topic. Thanks Sheetal _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 1 18:47:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22019 for ; Mon, 1 Nov 2004 18:47:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COm8O-0000Rj-Uh for sip-web-archive@ietf.org; Mon, 01 Nov 2004 19:02:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COlg4-0002kx-Nf; Mon, 01 Nov 2004 18:33:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COlPi-00024B-8o; Mon, 01 Nov 2004 18:16:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19353; Mon, 1 Nov 2004 18:16:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COlei-000890-4j; Mon, 01 Nov 2004 18:32:08 -0500 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1COlJ8-0001zU-29; Mon, 01 Nov 2004 18:09:50 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 01 Nov 2004 18:09:50 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: chair , Internet Architecture Board , sip chair , sip mailing list , sip, RFC Editor Subject: [Sip] Protocol Action: 'Update to the Session Initiation Protocol (SIP) Preconditions Framework' to Proposed Standard X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 The IESG has approved the following document: - 'Update to the Session Initiation Protocol (SIP) Preconditions Framework ' as a Proposed Standard This document is the product of the Session Initiation Protocol Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. Technical Summary This document updates the framework for preconditions in SIP. It clarifies RFC 3312; it does not obsolete RFC 3312, but just explains it better and adds some rules that update it. It provides guidelines for authors who plan to write new precondition types, beyond the qos precondition. In addition, this document describes and solves some issues concerning the interaction between session mobility and preconditions. Working Group Summary The working group supported advancement of this document. Protocol Quality The concerns about session mobility were identified in implementation experiences. The document was reviewed for the IESG by Allison Mankin and by Spencer Dawkins of the General Area Review Team. RFC Editor Notes Abstract: OLD: This document updates the framework for preconditions in SIP. NEW: This document updates RFC 3312, which defines the framework for preconditions in SIP. Add the following paragraph to the end of the Introduction: Specifically, we now allow answers to downgrade current status values (this was disallowed by RFC 3312). We consider moving an existing stream to a new location as equivalent to establishing a new stream. Therefore, answerers moving streams to new locations set all the current status values in their answers to "No" and start a new precondition negotiation from scratch. Section 4.1 OLD: Table 3 of RFC 3312 [3] needs to be updated to allow answers to downgrade current status values. NEW: Table 3 of RFC 3312 needs to be updated to allow answerers to downgrade current status values. Section 6 IANA Considerations OLD: This document has no IANA considerations. NEW: The IANA registration requirements for the preconditions framework are defined in RFC 3312. Any new preconditions are governed by the IANA Considerations there. Throughout the document: After the first reference to [3], omit the [3]. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 1 21:14:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03892 for ; Mon, 1 Nov 2004 21:14:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COoQt-0003sP-8z for sip-web-archive@ietf.org; Mon, 01 Nov 2004 21:30:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COnq3-0008Gv-0u; Mon, 01 Nov 2004 20:51:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COnVy-0000St-GS for sip@megatron.ietf.org; Mon, 01 Nov 2004 20:31:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00577 for ; Mon, 1 Nov 2004 20:31:11 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COnkx-00031s-Cl for sip@ietf.org; Mon, 01 Nov 2004 20:46:44 -0500 Received: from [10.89.20.16] ([12.5.186.26]) (authenticated bits=0) by nylon.softarmor.com (8.12.11/8.12.11) with ESMTP id iA21VSH4029019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 1 Nov 2004 19:31:29 -0600 Message-ID: <4186E354.1040701@softarmor.com> Date: Mon, 01 Nov 2004 19:31:00 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) 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-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Subject: [Sip] IPR disclosure on MESSAGE and related use of SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit I've just noticed that Nortel has recently been issued a patent for which they have made an IPR disclosure relative to RFC 3428, the SIP MESSAGE method. The disclosure document is listed at: http://www.ietf.org/ietf/IPR/nortel-ipr-rfc-3428.txt The issued patent is US patent number 6,757,732 and you can retrieve its full text from: http://patft.uspto.gov/netahtml/srchnum.htm -- Dean Willis SIP co-chair _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 1 21:54:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06253 for ; Mon, 1 Nov 2004 21:54:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COp3P-0004hn-RP for sip-web-archive@ietf.org; Mon, 01 Nov 2004 22:09:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COoT1-0003AA-Lz; Mon, 01 Nov 2004 21:32:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COoOO-0000KF-Fa for sip@megatron.ietf.org; Mon, 01 Nov 2004 21:27:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04835; Mon, 1 Nov 2004 21:27:25 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COodO-0004CT-Mz; Mon, 01 Nov 2004 21:43:00 -0500 Received: from [206.176.144.210] (206-176-144-210.waymark.net [206.176.144.210] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.12.11/8.12.11) with ESMTP id iA22RgCv029331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Nov 2004 20:27:43 -0600 Message-ID: <4186F074.8060801@softarmor.com> Date: Mon, 01 Nov 2004 20:27:00 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org, agenda@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: rohan@ekabal.com, "mank >> Allison Mankin" Subject: [Sip] SIP Agenda, IETF 61 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit The IETF agenda has not yet jelled, so times are relative. We're assuming two 2-hour sessions. Every slot has received slightly MORE time than requested by the topic leader. Consequently, discussion will be cut off WITH A GUILLOTINE if required . . . First Session +0 Agenda bash and Status Chairs +15 Connection Reuse Rohan Mahy, Cullen Jennings draft-ietf-sip-connect-reuse-03.txt +30 Identity Jon Peterson draft-ietf-sip-identity-03.txt +60 GRUU Jonathan Rosenberg draft-ietf-sip-gruu-02.txt +80 Content Indirection Eric Burger draft-ietf-sip-content-indirect-mech-05.txt +95 History Info Mary Barnes draft-ietf-sip-history-info-04.txt Second Session +0 Agenda Bash Chairs +5 Event List Adam Roach draft-ietf-simple-event-list-06 +30 REFER Without Subscriptions Orit Levin draft-ietf-sip-refer-with-norefersub-00 +40 REFER Feature Parameters Orit Levin draft-ietf-sip-refer-with-feature-param-00 +50 Resource Priority James Polk draft-ietf-sip-resource-priority-05.txt +70 Cert Usage Cullen jennings draft-ietf-sipping-certs-00.txt +100 SIP With SAML Hannes Tschofenig draft-tschofenig-sip-saml-01.txt _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 1 22:15:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14641 for ; Mon, 1 Nov 2004 22:15:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COpOE-0005An-PF for sip-web-archive@ietf.org; Mon, 01 Nov 2004 22:31:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COorI-0001nq-Bc; Mon, 01 Nov 2004 21:57:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COoU6-0003YM-Ro for sip@megatron.ietf.org; Mon, 01 Nov 2004 21:33:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05240 for ; Mon, 1 Nov 2004 21:33:19 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COoj7-0004KR-4F for sip@ietf.org; Mon, 01 Nov 2004 21:48:54 -0500 Received: from [206.176.144.210] (206-176-144-210.waymark.net [206.176.144.210] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.12.11/8.12.11) with ESMTP id iA22XcnR029368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Nov 2004 20:33:39 -0600 Message-ID: <4186F1D8.7030308@softarmor.com> Date: Mon, 01 Nov 2004 20:32:56 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22Egil_C=2E_=D8sthus=22?= Subject: Re: [Sip] SIP Extensions References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by nylon.softarmor.com id iA22XcnR029368 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Egil C. =D8sthus wrote: > Hi, >=20 > I have a question about section 8.1.1.9 in rfc3261. > It is said in this section that "The option tags listed MUST only refer= to > extensions defined in standards-track RFCs". Does this mean that the on= ly > legal extensions to SIP is those how are described in RFCs? If I would > like to define a method in SIP, is it possible to use this method some = way > and at the same time be 100% SIP compliant? Aboslutely. To make your extension 100% standards compliant, write a=20 standards-track RFC describing your extension. There's more discussion of this process in RFC 3427 ftp://ftp.rfc-editor.org/in-notes/rfc3427.txt The basic theory is that it is not standards-compliant to REQUIRE an=20 implementation manifest a non-standard extension. So, you can invent your own extension and use it to your heart's=20 content, but your implementation should work in such a way that if your=20 extension is not available, it must "fall back" in some fairly graceful=20 manner to standard behavior. That way, if somebody accidentally connects=20 using a "standard" client, the world doesn't self-destruct underneath the= m. -- Dean Willis co-chair, SIP Working Group _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 2 03:00:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23922 for ; Tue, 2 Nov 2004 03:00:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COtpo-0002mS-Ne for sip-web-archive@ietf.org; Tue, 02 Nov 2004 03:16:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COtX1-0004g2-4y; Tue, 02 Nov 2004 02:56:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COtPM-00013e-Vw for sip@megatron.ietf.org; Tue, 02 Nov 2004 02:48:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22928 for ; Tue, 2 Nov 2004 02:48:47 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COteR-0002X0-65 for sip@ietf.org; Tue, 02 Nov 2004 03:04:23 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id iA27oDnQ027522 for ; Tue, 2 Nov 2004 00:50:13 -0700 (MST) Received: from zin05exm02.corp.mot.com (zin05exm02.corp.mot.com [10.232.0.1]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id iA27miZX009505 for ; Tue, 2 Nov 2004 01:48:45 -0600 Received: by zin05exm02.corp.mot.com with Internet Mail Service (5.5.2657.72) id ; Tue, 2 Nov 2004 13:03:23 +0530 Message-ID: <653138C25D8AD6118292000347080A371202DC74@zin05exm02.corp.mot.com> From: Avasarala Ranjit-A20990 To: Sheetal Khemani , sip@ietf.org, sip-implementors@cs.columbia.edu Subject: RE: [Sip] SIP AMR Codec (RFC3267) out-of-band bitrate change Date: Tue, 2 Nov 2004 13:03:22 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Hi Can't the bandwidth attribute b= be used here? Regards Ranjit -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Sheetal Khemani Sent: Tuesday, November 02, 2004 12:33 AM To: sip@ietf.org; sip-implementors@cs.columbia.edu Subject: [Sip] SIP AMR Codec (RFC3267) out-of-band bitrate change Hi, I want to know if AMR mode changes are supported via SIP/SDP (possibly using a new off in a reINVITE). RFC3267 doesn't mention any parameter in the SDP to change the bitrate during the call using SIP. It allows the mode-set parameter that tells the encoder the subset of modes/bitrates it can use. It doesn't allow the specification of the bitrate the other end needs to use/switch-to. I came across some 3GPP docs (3GPP TS 26.236: Packet switched conversational multimedia applications; Transport protocols) that suggest using the bandwidth paramter, but that seems to be specific to QoS and I am not sure if this applies to the SIP standard per se. Please let me know if anyone has any insight on this topic. Thanks Sheetal _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 2 05:41:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05182 for ; Tue, 2 Nov 2004 05:41:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COwLy-00068r-5e for sip-web-archive@ietf.org; Tue, 02 Nov 2004 05:57:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COvvi-0006DD-99; Tue, 02 Nov 2004 05:30:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COvkm-0000nn-Ex for sip@megatron.ietf.org; Tue, 02 Nov 2004 05:19:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03590 for ; Tue, 2 Nov 2004 05:19:02 -0500 (EST) Received: from smtp.dataconnection.com ([192.91.191.4] helo=smtp.datcon.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COvzr-0005fF-VZ for sip@ietf.org; Tue, 02 Nov 2004 05:34:40 -0500 Received: by goodman.datcon.co.uk with Internet Mail Service (5.5.2657.72) id <49HBJMWX>; Tue, 2 Nov 2004 10:18:29 -0000 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F803E53191@baker.datcon.co.uk> From: "Paul D.Smith" To: "'Adam Roach'" Date: Tue, 2 Nov 2004 10:18:06 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: SIP WG Subject: [Sip] non-SUBSCRIBE subscriptions X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Adam, Can I please ask for some clarification on one aspect of RFC3265, Session Initiation Protocol (SIP)-Specific Event Notification"? Section 3.2 contains the following text. "If any non-SUBSCRIBE mechanisms are defined to create subscriptions..." I have always interpreted this as being the "window" required to allow REFER initiated subscriptions or (perish the thought) subscriptions created by a new and hitherto undefined SIP method. However, we have encountered customers who view this text as implying that a subscription can also be created using any out-of-band mechanism, and therefore that from a SIP perspective, a NOTIFY can arrive without any prior SIP exchanges. We see this as a major source of future interoperability problems as people create their own, ad-hoc out-of-band subscription creation systems so we want to clarify whether this was the intention. If it were not, we would like to see a clear statement on the WG and in future updates to RFC3265 clarifying this situation. Thanks, 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 sip-bounces@ietf.org Tue Nov 2 09:41:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24965 for ; Tue, 2 Nov 2004 09:41:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP06F-00035H-9K for sip-web-archive@ietf.org; Tue, 02 Nov 2004 09:57:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COzk0-0002LD-JN; Tue, 02 Nov 2004 09:34:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COzaX-0006Mt-Nd for sip@megatron.ietf.org; Tue, 02 Nov 2004 09:24:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23779 for ; Tue, 2 Nov 2004 09:24:44 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COzpe-0002kR-Hq for sip@ietf.org; Tue, 02 Nov 2004 09:40:23 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 02 Nov 2004 06:24:28 -0800 X-BrightmailFiltered: true Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iA2EO5om000549; Tue, 2 Nov 2004 06:24:06 -0800 (PST) Received: from [192.168.1.100] (sjc-vpn1-142.cisco.com [10.21.96.142]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFL89187; Tue, 2 Nov 2004 06:24:09 -0800 (PST) Message-ID: <41879888.5090302@cisco.com> Date: Tue, 02 Nov 2004 09:24:08 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] IPR disclosure on MESSAGE and related use of SIP References: <4186E354.1040701@softarmor.com> In-Reply-To: <4186E354.1040701@softarmor.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Suffice it to say, I am very unhappy about this. This patent was filed in 2000. I do not understand why the disclosure was only made just now, some four years after it was filed and two years after issuance of the RFC. The only reasons I can think of are not very nice. The licensing terms are also unclear. Does Nortel plan on extracting licensing revenues for this? I think some clarifications and explanations from participants from Nortel are in order. -Jonathan R. Dean Willis wrote: > > I've just noticed that Nortel has recently been issued a patent for > which they have made an IPR disclosure relative to RFC 3428, the SIP > MESSAGE method. > > The disclosure document is listed at: > > http://www.ietf.org/ietf/IPR/nortel-ipr-rfc-3428.txt > > The issued patent is US patent number 6,757,732 > > and you can retrieve its full text from: > > http://patft.uspto.gov/netahtml/srchnum.htm > > > -- > Dean Willis > SIP co-chair > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 2 10:30:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01041 for ; Tue, 2 Nov 2004 10:30:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP0rX-0004J0-8h for sip-web-archive@ietf.org; Tue, 02 Nov 2004 10:46:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP0K7-0004Et-2e; Tue, 02 Nov 2004 10:11:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP0A5-0005BP-5o for sip@megatron.ietf.org; Tue, 02 Nov 2004 10:01:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27075 for ; Tue, 2 Nov 2004 10:01:27 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP0P9-0003be-Ko for sip@ietf.org; Tue, 02 Nov 2004 10:17:07 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id iA2F2nnQ005362 for ; Tue, 2 Nov 2004 08:02:49 -0700 (MST) Received: from zin09exm01.corp.mot.com (zin09exm01.corp.mot.com [10.232.100.1]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id iA2F06Zl013813 for ; Tue, 2 Nov 2004 09:00:07 -0600 Received: by zin09exm01.corp.mot.com with Internet Mail Service (5.5.2657.72) id <33VBJCG5>; Tue, 2 Nov 2004 20:31:18 +0530 Message-ID: From: T Satyanarayana-A12694 To: "'Jonathan Rosenberg'" , Dean Willis Subject: RE: [Sip] IPR disclosure on MESSAGE and related use of SIP Date: Tue, 2 Nov 2004 20:31:16 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Jonathan etc, For the benefit of those unaware of IP content in SIP standards, can somebody send to this group the list of patented content in all SIP-related drafts/RFCs? I don't know if such a list exists. Or, should that be extracted from the respective RFCs/drafts? Regards Satya T -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Jonathan Rosenberg Sent: Tuesday, November 02, 2004 7:54 PM To: Dean Willis Cc: sip@ietf.org Subject: Re: [Sip] IPR disclosure on MESSAGE and related use of SIP Suffice it to say, I am very unhappy about this. This patent was filed in 2000. I do not understand why the disclosure was only made just now, some four years after it was filed and two years after issuance of the RFC. The only reasons I can think of are not very nice. The licensing terms are also unclear. Does Nortel plan on extracting licensing revenues for this? I think some clarifications and explanations from participants from Nortel are in order. -Jonathan R. Dean Willis wrote: > > I've just noticed that Nortel has recently been issued a patent for > which they have made an IPR disclosure relative to RFC 3428, the SIP > MESSAGE method. > > The disclosure document is listed at: > > http://www.ietf.org/ietf/IPR/nortel-ipr-rfc-3428.txt > > The issued patent is US patent number 6,757,732 > > and you can retrieve its full text from: > > http://patft.uspto.gov/netahtml/srchnum.htm > > > -- > Dean Willis > SIP co-chair > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 2 11:19:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05561 for ; Tue, 2 Nov 2004 11:19:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP1d4-0005VN-Lp for sip-web-archive@ietf.org; Tue, 02 Nov 2004 11:35:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP1B3-0003kc-N4; Tue, 02 Nov 2004 11:06:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP0x9-0007U2-W4 for sip@megatron.ietf.org; Tue, 02 Nov 2004 10:52:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03291 for ; Tue, 2 Nov 2004 10:52:10 -0500 (EST) Message-Id: <200411021552.KAA03291@ietf.org> Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP1CI-0004tQ-GO for sip@ietf.org; Tue, 02 Nov 2004 11:07:50 -0500 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CP0x6-000L4h-Sm; Tue, 02 Nov 2004 15:52:08 +0000 To: T Satyanarayana-A12694 Subject: Re: [Sip] IPR disclosure on MESSAGE and related use of SIP In-Reply-To: Message from T Satyanarayana-A12694 of "Tue, 02 Nov 2004 20:31:16 +0530." Date: Tue, 02 Nov 2004 07:52:08 -0800 From: Allison Mankin X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: sip@ietf.org, Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 FYI, It is now possible, as of about two weeks ago, to do a search of the IETF IPR claims by working group. Note that we hope that lots of you do not know of other IPR claims. Participants need to go back and re-study the Note Well: http://www.ietf.org/overview.html Below is the info on IPR Search, if you didn't see it. Allison P.S In the info below, the presentation of related documents in the search in no way implies that the IPR claim applies to them. IPR claims apply only to the specific i-d named in the claim, since a revision of the document often changes the technology. --------- To: IETF Announcement list From: IETF Secretariat Subject: Enhanced IETF IPR Disclosure Search Capability The IETF Secretariat is pleased to announce the deployment of an enhanced search capability for the "IETF IPR Disclosure Page" (https://datatracker.ietf.org/public/ipr_disclosure.cgi). With this new implementation, when a user searches on an I-D filename or an RFC number, the search will return all IPR disclosures associated with the document as well as all IPR disclosures associated with all related documents. For example, if the user searches on an RFC number, then the search will return all IPR disclosures associated with: o The RFC o Any version of the I-D that became the RFC o Any RFCs that replaced, updated, or obsoleted the RFC and their associated I-Ds o Any RFCs that were replaced by, updated by, or obsoleted by the RFC, and their associated I-Ds In addition, the new implementation will list all of the documents included in the search (by both title and RFC number or I-D filename) whether or not IPR disclosures have been submitted for those documents, and will indicate the relationship of each document to other documents on the list. If you require assistance in using this enhanced "Search" capability, or wish to report a bug, then please send a message to ietf-action@ietf.org. The IETF Secretariat _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 2 11:41:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08200 for ; Tue, 2 Nov 2004 11:41:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP1xZ-0006E5-M4 for sip-web-archive@ietf.org; Tue, 02 Nov 2004 11:56:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP1IC-0008Pa-Om; Tue, 02 Nov 2004 11:13:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP12O-0000Sg-2z for sip@megatron.ietf.org; Tue, 02 Nov 2004 10:57:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03637 for ; Tue, 2 Nov 2004 10:57:33 -0500 (EST) Received: from simmts5.bellnexxia.net ([206.47.199.163] helo=simmts5-srv.bellnexxia.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP1HL-0004yo-JQ for sip@ietf.org; Tue, 02 Nov 2004 11:13:14 -0500 Received: from IBM-7B137D96EC3.smtp1.ns.sympatico.ca ([142.177.140.33]) by simmts5-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20041102155646.XYE1799.simmts5-srv.bellnexxia.net@IBM-7B137D96EC3.smtp1.ns.sympatico.ca>; Tue, 2 Nov 2004 10:56:46 -0500 Message-Id: <6.1.2.0.2.20041102104651.02eb8eb0@pop3.zdsl.com> X-Sender: peter.macaulay%ZDSL.com@pop3.zdsl.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 02 Nov 2004 10:56:44 -0500 To: T Satyanarayana-A12694 From: Peter Macaulay Subject: RE: [Sip] IPR disclosure on MESSAGE and related use of SIP In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Internet Protocol (IP) is used extensively by SIP! :-) Intellectual Property Rights (IPR) can be found at; https://datatracker.ietf.org/public/ipr_disclosure.cgi You can search for the keyword SIP and find about 20 IPR disclosures; https://datatracker.ietf.org/public/ipr_list.cgi Regards, /PETER MACAULAY At 10:01 AM 11/2/2004, T Satyanarayana-A12694 wrote: >Jonathan etc, > >For the benefit of those unaware of IP content in SIP standards, can >somebody send to this group the list of patented content in all >SIP-related drafts/RFCs? I don't know if such a list exists. Or, should >that be extracted from the respective RFCs/drafts? > >Regards >Satya T > >-----Original Message----- >From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of >Jonathan Rosenberg >Sent: Tuesday, November 02, 2004 7:54 PM >To: Dean Willis >Cc: sip@ietf.org >Subject: Re: [Sip] IPR disclosure on MESSAGE and related use of SIP > > >Suffice it to say, I am very unhappy about this. > >This patent was filed in 2000. I do not understand why the disclosure >was only made just now, some four years after it was filed and two years >after issuance of the RFC. The only reasons I can think of are not very >nice. > >The licensing terms are also unclear. Does Nortel plan on extracting >licensing revenues for this? > >I think some clarifications and explanations from participants from >Nortel are in order. > >-Jonathan R. > > >Dean Willis wrote: > > > > > I've just noticed that Nortel has recently been issued a patent for > > which they have made an IPR disclosure relative to RFC 3428, the SIP > > MESSAGE method. > > > > The disclosure document is listed at: > > > > http://www.ietf.org/ietf/IPR/nortel-ipr-rfc-3428.txt > > > > The issued patent is US patent number 6,757,732 > > > > and you can retrieve its full text from: > > > > http://patft.uspto.gov/netahtml/srchnum.htm > > > > > > -- > > Dean Willis > > SIP co-chair > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip Use > > sipping@ietf.org for new developments on the application of sip > > > >-- >Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 >Cisco Systems >jdrosen@cisco.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.cisco.com > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip Use >sipping@ietf.org for new developments on the application of sip > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 2 11:52:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10475 for ; Tue, 2 Nov 2004 11:52:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP28F-0006hY-W9 for sip-web-archive@ietf.org; Tue, 02 Nov 2004 12:07:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP1mA-0005Ja-LK; Tue, 02 Nov 2004 11:44:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP1Li-0001TF-Dq for sip@megatron.ietf.org; Tue, 02 Nov 2004 11:17:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05419 for ; Tue, 2 Nov 2004 11:17:32 -0500 (EST) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP1ag-0005SD-3u for sip@ietf.org; Tue, 02 Nov 2004 11:33:13 -0500 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iA2GHLfM003162 for ; Tue, 2 Nov 2004 17:17:21 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 2 Nov 2004 17:17:21 +0100 Received: from ericsson.com (EFO9N000L5C7100 [153.88.41.88]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VJSN23HK; Tue, 2 Nov 2004 17:17:20 +0100 Message-ID: <4187B310.8090807@ericsson.com> Date: Tue, 02 Nov 2004 18:17:20 +0200 X-Sybari-Trust: 199577ef bfd556f1 fc586638 00000139 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: Colin Perkins Subject: Re: [Sip] Review request: draft-ietf-mmusic-connection-precon-00.txt References: <47A87ADB-220C-11D9-AB8E-000A957FC5F2@csperkins.org> In-Reply-To: <47A87ADB-220C-11D9-AB8E-000A957FC5F2@csperkins.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Nov 2004 16:17:21.0063 (UTC) FILETIME=[6E259B70:01C4C0F7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Joerg Ott X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Folks, FYI: this draft (draft-ietf-mmusic-connection-precon-00.txt) will be discussed in the MMUSIC meeting in Washington. Regards, Gonzalo Colin Perkins wrote: > Folks, > > The MMUSIC working group is considering a draft on > Connection-Establishment Preconditions in SIP > . As there are obvious > implications for SIP, this note is to solicit review by the SIP working > group before we advance this draft in MMUSIC. > > We'd be grateful to receive any comments - both for or against this > draft - in reply to this message. > > Thanks, > Colin > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 2 12:00:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11598 for ; Tue, 2 Nov 2004 12:00:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP2GT-0006wp-Q7 for sip-web-archive@ietf.org; Tue, 02 Nov 2004 12:16:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP1mh-0005QK-9e; Tue, 02 Nov 2004 11:45:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP1NX-0001gQ-Sm for sip@megatron.ietf.org; Tue, 02 Nov 2004 11:19:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05539 for ; Tue, 2 Nov 2004 11:19:25 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP1cg-0005Uz-JA for sip@ietf.org; Tue, 02 Nov 2004 11:35:07 -0500 Received: from [192.168.0.111] (adsl-209-30-35-14.dsl.rcsntx.swbell.net [209.30.35.14]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iA2GJ2T3005135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Nov 2004 10:19:03 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4187B371.5080406@nostrum.com> Date: Tue, 02 Nov 2004 10:18:57 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] IPR disclosure on MESSAGE and related use of SIP References: <4186E354.1040701@softarmor.com> In-Reply-To: <4186E354.1040701@softarmor.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, vektor@dumbterm.net X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit I want to make three observations of fact. * Patent 6,757,732 was filed March 16, 2000. * The MESSAGE method was used to exchange instant messages using SIP in August of 1999, and the source code to the client used to do so ("insipid," later renamed "kphone") was published on a publicly accessible web site at that time. A screen shot of the client performing instant messaging can be seen here: http://web.archive.org/web/20010624055115/http://www.billybiggs.com/screenshots/insipid-19-aug-99.gif * By April of 2000, there were enough implementations of the SIP MESSAGE method to have testing between multiple independent implementations at the 4th SIP bakeoff. I was a party to several of these tests. To be clear: I make no claims about the validity of this patent. I am simply stating facts that I believe may be of interest to this community. Draw your own conclusions. /a Dean Willis wrote: > > I've just noticed that Nortel has recently been issued a patent for > which they have made an IPR disclosure relative to RFC 3428, the SIP > MESSAGE method. > > The disclosure document is listed at: > > http://www.ietf.org/ietf/IPR/nortel-ipr-rfc-3428.txt > > The issued patent is US patent number 6,757,732 > > and you can retrieve its full text from: > > http://patft.uspto.gov/netahtml/srchnum.htm > > > -- > Dean Willis > SIP co-chair > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 2 12:10:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12877 for ; Tue, 2 Nov 2004 12:10:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP2Pr-0007Gc-Qy for sip-web-archive@ietf.org; Tue, 02 Nov 2004 12:25:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP1nQ-0006Gd-PF; Tue, 02 Nov 2004 11:46:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP1br-0008E5-Gr for sip@megatron.ietf.org; Tue, 02 Nov 2004 11:34:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07428 for ; Tue, 2 Nov 2004 11:34:13 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP1qx-0005yW-69 for sip@ietf.org; Tue, 02 Nov 2004 11:49:54 -0500 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id iA2GZUnQ024853 for ; Tue, 2 Nov 2004 09:35:30 -0700 (MST) Received: from il06exm13.corp.mot.com (il06exm13.corp.mot.com [10.0.111.13]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id iA2GWoJv000852 for ; Tue, 2 Nov 2004 10:32:50 -0600 Received: from bulb (bulb.corp.mot.com [10.14.25.99]) by il06exm13.corp.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id RKHAWSBG; Tue, 2 Nov 2004 10:34:02 -0600 Date: Tue, 2 Nov 2004 11:33:58 -0500 (EST) From: Srini Krishnamoorthy X-Sender: ksrini@bulb.corp.mot.com To: Jonathan Rosenberg Subject: Re: [Sip] IPR disclosure on MESSAGE and related use of SIP In-Reply-To: <41879888.5090302@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: sip@ietf.org, Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ksrini@motorola.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Jonathan et.al, Agree, and I think a LOT of people will be unhappy too .. Do we read this as specific to the use of "INFO + HTML body" or in general :- "communicating the text-based chat message includes embedding the text-based chat message" (which the the first claim states)?" How does this IPR affect the use of MESSAGE method with content-types other than text/html (say plain, xml) - what would be considered infringment? .. anybody Nortel?? Please help understand the detailed impact of this ... thanks. Or should I just wait to see what transpires?? -Srini On Tue, 2 Nov 2004, Jonathan Rosenberg wrote: jdrose>Suffice it to say, I am very unhappy about this. jdrose> jdrose>This patent was filed in 2000. I do not understand why the disclosure jdrose>was only made just now, some four years after it was filed and two years jdrose>after issuance of the RFC. The only reasons I can think of are not very jdrose>nice. jdrose> jdrose>The licensing terms are also unclear. Does Nortel plan on extracting jdrose>licensing revenues for this? jdrose> jdrose>I think some clarifications and explanations from participants from jdrose>Nortel are in order. jdrose> jdrose>-Jonathan R. jdrose> jdrose> jdrose>Dean Willis wrote: jdrose> jdrose>> jdrose>> I've just noticed that Nortel has recently been issued a patent for jdrose>> which they have made an IPR disclosure relative to RFC 3428, the SIP jdrose>> MESSAGE method. jdrose>> jdrose>> The disclosure document is listed at: jdrose>> jdrose>> http://www.ietf.org/ietf/IPR/nortel-ipr-rfc-3428.txt jdrose>> jdrose>> The issued patent is US patent number 6,757,732 jdrose>> jdrose>> and you can retrieve its full text from: jdrose>> jdrose>> http://patft.uspto.gov/netahtml/srchnum.htm jdrose>> jdrose>> jdrose>> -- jdrose>> Dean Willis jdrose>> SIP co-chair jdrose>> jdrose>> _______________________________________________ jdrose>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip jdrose>> This list is for NEW development of the core SIP Protocol jdrose>> Use sip-implementors@cs.columbia.edu for questions on current sip jdrose>> Use sipping@ietf.org for new developments on the application of sip jdrose>> jdrose> jdrose> -- Srini K ksrini at motorola Finger ksrini@bulb.corp.mot.com for pub key. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 2 12:13:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13236 for ; Tue, 2 Nov 2004 12:13:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP2T9-0007MC-DX for sip-web-archive@ietf.org; Tue, 02 Nov 2004 12:29:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP1nS-0006HS-90; Tue, 02 Nov 2004 11:46:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP1bu-0008Is-Rb for sip@megatron.ietf.org; Tue, 02 Nov 2004 11:34:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07440 for ; Tue, 2 Nov 2004 11:34:16 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP1r2-0005zW-LB for sip@ietf.org; Tue, 02 Nov 2004 11:49:58 -0500 Received: from [192.168.0.111] (adsl-209-30-35-14.dsl.rcsntx.swbell.net [209.30.35.14]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iA2GXw4D006349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Nov 2004 10:34:04 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4187B6F1.1060008@nostrum.com> Date: Tue, 02 Nov 2004 10:33:53 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Paul D.Smith" Subject: Re: [Sip] non-SUBSCRIBE subscriptions References: <53F74F5A7B94D511841C00B0D0AB16F803E53191@baker.datcon.co.uk> In-Reply-To: <53F74F5A7B94D511841C00B0D0AB16F803E53191@baker.datcon.co.uk> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: SIP WG X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Paul D.Smith wrote: >Adam, > >Can I please ask for some clarification on one aspect of RFC3265, Session >Initiation Protocol (SIP)-Specific Event Notification"? Section 3.2 >contains >the following text. > > "If any non-SUBSCRIBE mechanisms are defined to create subscriptions..." > >I have always interpreted this as being the "window" required to allow REFER >initiated subscriptions or (perish the thought) subscriptions created by a >new >and hitherto undefined SIP method. However, we have encountered customers >who >view this text as implying that a subscription can also be created using any >out-of-band mechanism, and therefore that from a SIP perspective, a NOTIFY >can >arrive without any prior SIP exchanges. > > Such was the intention. This text was a source of much contention during the development of this document, and it was repeatedly removed, re-added, and re-crafted to try to find a balance. The paragraph that you cite is the final compromise. It defines some very strict guidelines about how any such mechanisms must behave. In particular: > Designers of such mechanisms are also > warned to make a distinction between sending a NOTIFY message to a > subscriber who is aware of the subscription, and sending a NOTIFY > message to an unsuspecting node. The latter behavior is invalid, and > MUST receive a "481 Subscription does not exist" response.... > In other words, knowledge of a subscription must exist in both the > subscriber and the notifier to be valid, even if installed via a > non-SUBSCRIBE mechanism. > To be clear: * It is a violation of the specification to send a NOTIFY to a node that you do not know for a fact is expecting that NOTIFY. * It is a violation of the specification to send a 200-class response to a NOTIFY if you were not told, via some mechanism, in advance, that such a NOTIFY would be arriving. All of that is historical information at this point. For future revisions of the specification, it is highly likely that these provisions will be removed, as no published mechanisms have taken advantage of them (except for REFER, which will likely be revised to remove the implicit subscription in favor of an explicit subscription.) /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 2 15:15:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06072 for ; Tue, 2 Nov 2004 15:15:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP5JI-000486-CE for sip-web-archive@ietf.org; Tue, 02 Nov 2004 15:31:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP4qk-0006P6-8i; Tue, 02 Nov 2004 15:01:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP4gX-0007M5-0z for sip@megatron.ietf.org; Tue, 02 Nov 2004 14:51:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03258 for ; Tue, 2 Nov 2004 14:51:15 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP4vg-0003WX-Qj for sip@ietf.org; Tue, 02 Nov 2004 15:06:58 -0500 Received: from [10.1.11.198] (inetgate.teknekron.com [192.138.162.245] (may be forged)) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iA2Jo2S9023258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Nov 2004 13:50:07 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4187E4E5.5030505@nostrum.com> Date: Tue, 02 Nov 2004 13:49:57 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ksrini@motorola.com Subject: Re: [Sip] IPR disclosure on MESSAGE and related use of SIP References: In-Reply-To: X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Srini Krishnamoorthy wrote: > Please help understand the detailed impact of this ... thanks. > > Or should I just wait to see what transpires?? > > Well, as heinous as all of this is, I think the appropriate response would be to put your efforts into developing an MSRP client instead of a MESSAGE-based implementation. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 2 17:42:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24912 for ; Tue, 2 Nov 2004 17:42:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP7bo-0000Yn-2f for sip-web-archive@ietf.org; Tue, 02 Nov 2004 17:58:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP73x-0008SF-MP; Tue, 02 Nov 2004 17:23:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP6rK-0000Ce-L2 for sip@megatron.ietf.org; Tue, 02 Nov 2004 17:10:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22019 for ; Tue, 2 Nov 2004 17:10:32 -0500 (EST) Received: from qfe1.july.broomfield1.level3.net ([209.245.18.72] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP76V-0008D2-C4 for sip@ietf.org; Tue, 02 Nov 2004 17:26:16 -0500 Received: from scanner5.level3.com (qfe0.f10212-07.adc1.oss.level3.com [10.2.1.102]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id iA2MAT2J013414 for ; Tue, 2 Nov 2004 22:10:29 GMT Received: from scanner5.level3.com (localhost [127.0.0.1]) by localhost.level3.com (Postfix) with ESMTP id B418412480B for ; Tue, 2 Nov 2004 22:10:21 +0000 (GMT) Received: from idc1exc0001.corp.global.level3.com (idc1exc0001.corp.global.level3.com [10.1.7.194]) by scanner5.level3.com (Postfix) with SMTP id 72697124802 for ; Tue, 2 Nov 2004 22:10:21 +0000 (GMT) Received: from idc1exc0004.corp.global.level3.com ([10.1.8.20]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 2 Nov 2004 15:10:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] IPR disclosure on MESSAGE and related use of SIP Date: Tue, 2 Nov 2004 15:10:20 -0700 Message-ID: <3F75233A2E57CC468B35F3B1FAF71EC0129ABC@idc1exc0004.corp.global.level3.com> Thread-Topic: [Sip] IPR disclosure on MESSAGE and related use of SIP Thread-Index: AcTBGWDbeYlbqFwYTvi1r4tzT3IZhwADq99w From: "Hearty, John" To: X-OriginalArrivalTime: 02 Nov 2004 22:10:21.0153 (UTC) FILETIME=[BE76DD10:01C4C128] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Perhaps I'm missing something, but I looked over the patent quickly and all the examples in the text were around using the INFO method, not the MESSAGE method. It was of course laced with language making it sound rather general so perhaps it could be applied to other SIP methods. John Hearty Level3 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Adam Roach Sent: Tuesday, November 02, 2004 12:50 PM To: ksrini@motorola.com Cc: sip@ietf.org; Dean Willis Subject: Re: [Sip] IPR disclosure on MESSAGE and related use of SIP Srini Krishnamoorthy wrote: > Please help understand the detailed impact of this ... thanks. > > Or should I just wait to see what transpires??=20 > =20 > Well, as heinous as all of this is, I think the appropriate response=20 would be to put your efforts into developing an MSRP client instead of a MESSAGE-based implementation. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 2 19:23:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05375 for ; Tue, 2 Nov 2004 19:23:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP9BC-0003HO-6z for sip-web-archive@ietf.org; Tue, 02 Nov 2004 19:39:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP8gY-0007c0-WF; Tue, 02 Nov 2004 19:07:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP8Tk-0000Qb-3O for sip@megatron.ietf.org; Tue, 02 Nov 2004 18:54:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02345 for ; Tue, 2 Nov 2004 18:54:17 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP8iw-0002N1-PS for sip@ietf.org; Tue, 02 Nov 2004 19:10:03 -0500 Received: from [10.1.11.198] (inetgate.teknekron.com [192.138.162.245] (may be forged)) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iA2NsCSo041744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Nov 2004 17:54:17 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <41881E24.9000206@nostrum.com> Date: Tue, 02 Nov 2004 17:54:12 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hearty, John" Subject: Re: [Sip] IPR disclosure on MESSAGE and related use of SIP References: <3F75233A2E57CC468B35F3B1FAF71EC0129ABC@idc1exc0004.corp.global.level3.com> In-Reply-To: <3F75233A2E57CC468B35F3B1FAF71EC0129ABC@idc1exc0004.corp.global.level3.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit I'm nothing like a lawyer, so don't take this as legal advice. On the other hand, I've assisted with the IPR process (my own IPR and others') at two different companies, so I have some reasonable layperson background here. What /really/ matters in a patent are the /independent/ claims. That is, the ones that don't refer to any of the other claims. So, to evaluate the impact of this patent, look at claims 1, 9, 13, 22, 25, 28, and 32. In a vacuum. Ignore the entire rest of the document. The other claims are there just in case the independent claims are ruled to be too broad. They progressively narrow the scope so the patent can "fall back" to one of these narrower scopes. Unless the patent is challenged in court, they are just noise. Anything that's not a claim is there just to provide context for the claims; it doesn't affect what can be enforced. /a Hearty, John wrote: >Perhaps I'm missing something, but I looked over the patent quickly and >all the examples in the text were around using the INFO method, not the >MESSAGE method. It was of course laced with language making it sound >rather general so perhaps it could be applied to other SIP methods. > >John Hearty >Level3 > >-----Original Message----- >From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of >Adam Roach >Sent: Tuesday, November 02, 2004 12:50 PM >To: ksrini@motorola.com >Cc: sip@ietf.org; Dean Willis >Subject: Re: [Sip] IPR disclosure on MESSAGE and related use of SIP > >Srini Krishnamoorthy wrote: > > > >> Please help understand the detailed impact of this ... thanks. >> >> Or should I just wait to see what transpires?? >> >> >> >> > >Well, as heinous as all of this is, I think the appropriate response >would be to put your efforts into developing an MSRP client instead of a > >MESSAGE-based implementation. > >/a > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 3 01:19:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01829 for ; Wed, 3 Nov 2004 01:19:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPEkD-0002iR-Vz for sip-web-archive@ietf.org; Wed, 03 Nov 2004 01:35:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPEOY-0007oM-Tm; Wed, 03 Nov 2004 01:13:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPEJD-0004Xz-Ag for sip@megatron.ietf.org; Wed, 03 Nov 2004 01:07:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00883 for ; Wed, 3 Nov 2004 01:07:49 -0500 (EST) Received: from smtp-29.ig.com.br ([200.226.132.157]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CPEYS-0002Rr-L9 for sip@ietf.org; Wed, 03 Nov 2004 01:23:37 -0500 Received: (qmail 26510 invoked from network); 3 Nov 2004 06:04:20 -0000 Received: from unknown (HELO thigui) (201.12.70.202) by smtp-29.ig.com.br with SMTP; 3 Nov 2004 06:04:20 -0000 Message-ID: <009d01c4c169$ef5d1c00$ca460cc9@soc.virtua.com.br> From: =?iso-8859-1?Q?S=E9rgio_Yoshioka?= To: Date: Wed, 3 Nov 2004 03:56:59 -0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.9 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: [Sip] Security & Privacy in SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?iso-8859-1?Q?S=E9rgio_Yoshioka?= List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0584854851==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 This is a multi-part message in MIME format. --===============0584854851== Content-Type: multipart/alternative; boundary="----=_NextPart_000_009A_01C4C159.2B78BE80" This is a multi-part message in MIME format. ------=_NextPart_000_009A_01C4C159.2B78BE80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear friends, I have been studying security and privacy in general and I am interested = in features/works/papers to improve security and privacy in SIP. =20 Someone could give some more information, articles, papers, RFCs/drafts = related this topic, including something about lawful interception and = Spam over IP Telephony?? Really thanks in advance for any help. Sergio ------=_NextPart_000_009A_01C4C159.2B78BE80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear = friends,

I have been studying security and privacy in general and I am = interested in=20 features/works/papers to improve security and privacy in SIP. 

Someone could give some more information, articles, papers, = RFCs/drafts=20 related this topic, including something about lawful interception and = Spam over=20 IP Telephony??

Really thanks in advance for any help.

Sergio

------=_NextPart_000_009A_01C4C159.2B78BE80-- --===============0584854851== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0584854851==-- From sip-bounces@ietf.org Wed Nov 3 06:21:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24820 for ; Wed, 3 Nov 2004 06:21:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPJSK-0001Cu-Nx for sip-web-archive@ietf.org; Wed, 03 Nov 2004 06:37:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPIzL-0005E8-F8; Wed, 03 Nov 2004 06:07:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPITD-0004yk-L4 for sip@megatron.ietf.org; Wed, 03 Nov 2004 05:34:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19735 for ; Wed, 3 Nov 2004 05:34:25 -0500 (EST) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPIiW-00008i-A0 for sip@ietf.org; Wed, 03 Nov 2004 05:50:16 -0500 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 3 Nov 2004 11:33:59 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Sip] non-SUBSCRIBE subscriptions Date: Wed, 3 Nov 2004 11:33:57 +0100 Message-ID: Thread-Topic: [Sip] non-SUBSCRIBE subscriptions Thread-Index: AcTA/3jEFaaABekLSlOwkxla3DsMdQAkQU5A From: "MANSOOR Usama RD-ILAB-LON" To: "Adam Roach" , "Paul D.Smith" X-OriginalArrivalTime: 03 Nov 2004 10:33:59.0597 (UTC) FILETIME=[A1211DD0:01C4C190] X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable Cc: SIP WG X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: quoted-printable So will there no longer be such a thing as 'implicit subscriptions'? - Usama -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Adam Roach Sent: 02 November 2004 16:34 To: Paul D.Smith Cc: SIP WG Subject: Re: [Sip] non-SUBSCRIBE subscriptions Paul D.Smith wrote: >Adam, > >Can I please ask for some clarification on one aspect of RFC3265, Session >Initiation Protocol (SIP)-Specific Event Notification"? Section 3.2 >contains >the following text. > > "If any non-SUBSCRIBE mechanisms are defined to create subscriptions..." > >I have always interpreted this as being the "window" required to allow REFER >initiated subscriptions or (perish the thought) subscriptions created by a >new >and hitherto undefined SIP method. However, we have encountered customers >who >view this text as implying that a subscription can also be created using any >out-of-band mechanism, and therefore that from a SIP perspective, a NOTIFY >can >arrive without any prior SIP exchanges. > =20 > Such was the intention. This text was a source of much contention during the development of this document, and it was repeatedly removed,=20 re-added, and re-crafted to try to find a balance. The paragraph that you cite is the final compromise. It defines some=20 very strict guidelines about how any such mechanisms must behave. In=20 particular: > Designers of such mechanisms are also > warned to make a distinction between sending a NOTIFY message to a > subscriber who is aware of the subscription, and sending a NOTIFY > message to an unsuspecting node. The latter behavior is invalid, and > MUST receive a "481 Subscription does not exist" response....=20 > In other words, knowledge of a subscription must exist in both the > subscriber and the notifier to be valid, even if installed via a > non-SUBSCRIBE mechanism. > To be clear: * It is a violation of the specification to send a NOTIFY to a node that you do not know for a fact is expecting that NOTIFY. * It is a violation of the specification to send a 200-class response to a NOTIFY if you were not told, via some mechanism, in advance, that such a NOTIFY would be arriving. All of that is historical information at this point. For future=20 revisions of the specification, it is highly likely that these=20 provisions will be removed, as no published mechanisms have taken=20 advantage of them (except for REFER, which will likely be revised to=20 remove the implicit subscription in favor of an explicit subscription.) /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 3 09:29:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12768 for ; Wed, 3 Nov 2004 09:29:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPMO9-0006Cr-LD for sip-web-archive@ietf.org; Wed, 03 Nov 2004 09:45:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPM3Z-0008LG-DC; Wed, 03 Nov 2004 09:24:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPLxu-0007D7-H0 for sip@megatron.ietf.org; Wed, 03 Nov 2004 09:18:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11913 for ; Wed, 3 Nov 2004 09:18:20 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPMDE-0005x0-48 for sip@ietf.org; Wed, 03 Nov 2004 09:34:13 -0500 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iA3EHek08470; Wed, 3 Nov 2004 09:17:40 -0500 (EST) Received: from [47.130.17.132] (acart263.ca.nortel.com [47.130.17.132]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id W14F3BLR; Wed, 3 Nov 2004 09:17:41 -0500 Message-ID: <4188E883.1090807@nortelnetworks.com> Date: Wed, 03 Nov 2004 09:17:39 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] IPR disclosure on MESSAGE and related use of SIP References: <4186E354.1040701@softarmor.com> <41879888.5090302@cisco.com> In-Reply-To: <41879888.5090302@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit I'm probably going to get into trouble for responding, but I can't sit by and let you throw mud at my colleagues. Jonathan, you once worked for a large company. Now you do, again. Can you really say you know everything that's going on in Cisco that might relate to your ETF activities? It's getting tougher as we get slimmed down, but Nortel (and BNR before that) has had a long tradition of people in odd corners exploring the possibilities of technology and coming up with new ideas unrelated to their current products. And like it or not, Nortel views intellectual property as a source of value, so people are encouraged to take out patents on new ideas. Mary was unaware of the patent concerned until a week before the patent announcement. At that point she took the necessary steps to have it announced. And we who participate at the IETF are not patent lawyers -- we can only refer you to our own legal people for further advice. Jonathan Rosenberg wrote: > Suffice it to say, I am very unhappy about this. > > This patent was filed in 2000. I do not understand why the disclosure > was only made just now, some four years after it was filed and two years > after issuance of the RFC. The only reasons I can think of are not very > nice. > > The licensing terms are also unclear. Does Nortel plan on extracting > licensing revenues for this? > > I think some clarifications and explanations from participants from > Nortel are in order. > > -Jonathan R. > > -- Tom Taylor Carrier VoIP Standards Development Nortel Networks Phone +1 613 763 1496 (ESN 393-1496) E-mail: taylor@nortelnetworks.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 3 11:51:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26156 for ; Wed, 3 Nov 2004 11:51:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPOb7-0001DU-66 for sip-web-archive@ietf.org; Wed, 03 Nov 2004 12:07:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPOAv-00063Z-4H; Wed, 03 Nov 2004 11:39:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPO0q-0004Mf-EY for sip@megatron.ietf.org; Wed, 03 Nov 2004 11:29:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24243 for ; Wed, 3 Nov 2004 11:29:30 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPOGB-0000fQ-7t for sip@ietf.org; Wed, 03 Nov 2004 11:45:25 -0500 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iA3GSsN05166; Wed, 3 Nov 2004 11:28:54 -0500 (EST) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Nov 2004 11:28:55 -0500 Message-ID: From: "Mary Barnes" To: "'Takuya Sawada'" Subject: RE: FW: [Sip] I-D ACTION:draft-ietf-sip-history-info-04.txt Date: Wed, 3 Nov 2004 11:28:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.8 (/) X-Scan-Signature: 713965ef965c5660ee5d9a664a73ef4a Cc: "'sip@ietf.org'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1155176666==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: d1013c8bad83fa4e4ccb34a7376b19d5 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1155176666== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C1C2.2F3CA0DB" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4C1C2.2F3CA0DB Content-Type: text/plain Hi Takuya, I apologize if I missed this specific point in your previous postings. You are correct, that index of 2 should have been 1.1 and this actually affects the whole series and also affects the examples in 4.5.1 and 4.5.2. All the other entries are correct relative to the index of 2, it's just the 2 should have been a 1.1, unless of course that proxy had a good reason for starting at 2, which I don't explain so shouldn't use in the example. It looks like I introduced that error in the -01 version when I was updating the example to include the index for all entries (as the index was originally optional). I traced the change back to changes I made during the middle of the day, so I can't even blame late nite editting. I will definitely make a note of that and update that in the -05 version, which will hopefully be the one to go to the IESG. I'm also copying the SIP list, so that folks are aware of this as they review the document. Thanks for your careful review, Mary -----Original Message----- From: Takuya Sawada [mailto:tu-sawada@kddi.com] Sent: Tuesday, November 02, 2004 4:29 AM To: Barnes, Mary [NGC:B601:EXCH] Subject: Re: FW: [Sip] I-D ACTION:draft-ietf-sip-history-info-04.txt Hi Mary, Each example flow in section 4.5 begins with the following messages, UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5 | | | | | | | |--INVITE -->| | | | | | | |-INVITE->| | | | | Supported: Histinfo History-Info: ;index=1, ;index=2 I think this should be UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5 | | | | | | | |--INVITE -->| | | | | | | |-INVITE->| | | | | Supported: Histinfo History-Info: ;index=1, ;index=1.1 Note that the index of the second hi-entry is 1.1. I made the same comment to the list before, but no response to it. In Appendix C, it shows, UA1 Proxy ACDGRP1 Svr ACDGRP2 Svr UA2-ACDGRP2 | | | | | |--INVITE F1-->| | | | Supported:Histinfo | | | | | | |--INVITE F2-->| | | Supported:Histinfo History-Info: ; index=1 History-Info: ; index=1.1 I can not find what is the difference between the two. Are you saying that the former is "Retargeting within a Proxy" and the latter is "Basic Forwarding"? Am I missing something? Thanks. Regards, Takuya > > > Hi all, > > Since this version should be ready for WGLC, a very detailed list of the > changes is provided in the document, annotated as to the source, so I won't > repeat those details here. The majority of the changes were the issues > discussed at IETF-60, along with the agreements there to change the text to > non-normative in section 4 (Protocol structure) and to add some detail per > Rohan's comment on the necessary processing should TLS not be available. In > addition, I received some proposed changes on a marked up hardcopy at > IETF-61 from Eric Burger. > > The only items not discussed at IETF-60 were 2 items that came up on the > list (one posted by John Elwell on August 18th on handling of privacy in > responses) the other on Oct. 15th around the appropriate character format > for the escaped headers in the URI. And, as always, there are various minor > editorial changes here and there while I was "in the area". So, there > should be no surprises with any of the changes, although, it is possible > that there are still errors and nits that can be identified during WGLC. > > Thanks, > Mary > > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Monday, October 25, 2004 3:07 PM > To: i-d-announce@ietf.org > Cc: sip@ietf.org > Subject: [Sip] I-D ACTION:draft-ietf-sip-history-info-04.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 : An Extension to the Session Initiation Protocol > for Request History Information > Author(s) : M. Barnes > Filename : draft-ietf-sip-history-info-04.txt > Pages : 47 > Date : 2004-10-25 > > This draft defines a standard mechanism for capturing the history > information associated with a SIP request. This capability enables > many enhanced services by providing the information as to how and why > a call arrives at a specific application or user. This draft defines > a new optional SIP header, History-Info, for capturing the history > information in requests. A new option tag, Histinfo, to be included > in the Supported header, is defined to allow UAs to indicate whether > the History-Info should be returned in responses to a request which > has captured the history information. A new priv-value, history, is > added to the Privacy header to allow for privacy handling of the > History-Info header. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-history-info-04.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the > message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-sip-history-info-04.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-sip-history-info-04.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. > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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-0286 tu-sawada@kddi.com ------_=_NextPart_001_01C4C1C2.2F3CA0DB Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: FW: [Sip] I-D = ACTION:draft-ietf-sip-history-info-04.txt

Hi Takuya,

I apologize if I missed this specific point in your = previous postings. You are correct, that index of 2 should have been = 1.1 and this  actually affects the whole series and also affects = the examples in  4.5.1 and 4.5.2.  All the other entries are = correct relative to the index of 2, it's just the 2 should have been a = 1.1, unless of course that proxy had a good reason for starting at 2, = which I don't explain so shouldn't use in the example.  =

It looks like I introduced that error in the -01 = version when I was updating the example to include the index for all = entries (as the index was originally optional). I traced the change = back to changes I made during the middle of the day, so I can't even = blame late nite editting.   I will definitely make a note of = that and update that in the -05 version, which will hopefully be the = one to go to the IESG.

I'm also copying the SIP list, so that folks are = aware of this as they review the document.

Thanks for your careful review,
Mary


-----Original Message-----
From: Takuya Sawada [mailto:tu-sawada@kddi.com] =
Sent: Tuesday, November 02, 2004 4:29 AM
To: Barnes, Mary [NGC:B601:EXCH]
Subject: Re: FW: [Sip] I-D = ACTION:draft-ietf-sip-history-info-04.txt


Hi Mary,

Each example flow in section 4.5 begins with the = following messages,

   = UA1        Proxy1  = Proxy2     UA2      = UA3      UA4      UA5 =
          &nb= sp;    
   = |            = |         = |        = |        = |        = |        |
   |--INVITE = -->|         = |        = |        = |        = |        |
   = |            = |-INVITE->|        = |        = |        = |        |
          &nb= sp;      Supported: Histinfo
          &nb= sp;      History-Info: = <sip:Bob@P1.example.com>;index=3D1,
          &nb= sp;           &nb= sp;        = <sip:Bob@P2.example.com>;index=3D2

I think this should be

   = UA1        Proxy1  = Proxy2     UA2      = UA3      UA4      UA5 =
          &nb= sp;    
   = |            = |         = |        = |        = |        = |        |
   |--INVITE = -->|         = |        = |        = |        = |        |
   = |            = |-INVITE->|        = |        = |        = |        |
          &nb= sp;      Supported: Histinfo
          &nb= sp;      History-Info: = <sip:Bob@P1.example.com>;index=3D1,
          &nb= sp;           &nb= sp;        = <sip:Bob@P2.example.com>;index=3D1.1

Note that the index of the second hi-entry is = 1.1.
I made the same comment to the list before, but no = response to it.

In Appendix C, it shows,

   = UA1          = Proxy        ACDGRP1 Svr   = ACDGRP2 Svr = UA2-ACDGRP2          &= nbsp;  
          &nb= sp;    
   = |            = ;  = |            = ;  = |            = ; |          |
   |--INVITE = F1-->|          &nb= sp;   = |            = ; |          |
    Supported:Histinfo
   = |            = ;  = |            = ;  = |            = ; |          |
   = |            = ;  |--INVITE = F2-->|          &nb= sp;  |          | =
          &nb= sp;         Supported:Histinfo =
         = ;           = History-Info: <sip:Gold@example.com>; index=3D1 
          &nb= sp;         History-Info: = <sip:ACDGRP1@example.com>; index=3D1.1

I can not find what is the difference between the = two.
Are you saying that the former is "Retargeting = within a  Proxy" and the
latter is "Basic Forwarding"?
Am I missing something?

Thanks.

Regards,
Takuya

>
>
> Hi all,
>
> Since this version should be ready for WGLC, a = very detailed list of the
> changes is provided in the document, annotated = as to the source, so I won't
> repeat those details here.   The = majority of the changes were the issues
> discussed at IETF-60, along with the agreements = there to change the text to
> non-normative in section 4 (Protocol structure) = and to add some detail per
> Rohan's comment on the necessary processing = should TLS not be available.  In
> addition, I received some proposed changes on a = marked up hardcopy at
> IETF-61 from Eric Burger. 
>
> The only items not discussed at IETF-60 were 2 = items that came up on the
> list (one posted by John Elwell on August 18th = on handling of privacy in
> responses) the other on Oct. 15th around the = appropriate character format
> for the escaped headers in the URI. And, as = always, there are various minor
> editorial changes here and there while I was = "in the area".  So, there
> should be no surprises with any of the changes, = although, it is possible
> that there are still errors and nits that can = be identified during WGLC.  
>
> Thanks,
> Mary
>
>
> -----Original Message-----
> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] = On Behalf Of
> Internet-Drafts@ietf.org
> Sent: Monday, October 25, 2004 3:07 PM
> To: i-d-announce@ietf.org
> Cc: sip@ietf.org
> Subject: [Sip] I-D = ACTION:draft-ietf-sip-history-info-04.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           : An = Extension to the Session Initiation Protocol
> for Request History Information
>       = Author(s)       : M. Barnes
>       = Filename        : = draft-ietf-sip-history-info-04.txt
>       = Pages           : = 47
>       = Date            : = 2004-10-25
>      
> This draft defines a standard mechanism for = capturing the history
>    information associated with a = SIP request.  This capability enables
>    many enhanced services by = providing the information as to how and why
>    a call arrives at a specific = application or user.  This draft defines
>    a new optional SIP header, = History-Info, for capturing the history
>    information in requests. A = new option tag, Histinfo, to be included
>    in the Supported header, is = defined to allow UAs to indicate whether
>    the History-Info should be = returned in responses to a request which
>    has captured the history = information. A new priv-value, history, is
>    added to the Privacy header = to allow for privacy handling of the
>    History-Info header.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-sip-his= tory-info-04.txt
>
> To remove yourself from the I-D Announcement = list, send a message to
> i-d-announce-request@ietf.org with the word = unsubscribe in the body of the
> message. 
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous = FTP. Login with the username
> "anonymous" and a password of your = e-mail address. After logging in,
> type "cd internet-drafts" and = then
>       "get = draft-ietf-sip-history-info-04.txt".
>
> A list of Internet-Drafts directories can be = found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by = e-mail.
>
> Send a message to:
>       = mailserv@ietf.org.
> In the body type:
>       "FILE = /internet-drafts/draft-ietf-sip-history-info-04.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.
>
>
>
>
>
> = _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core = SIP 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-0286
tu-sawada@kddi.com

------_=_NextPart_001_01C4C1C2.2F3CA0DB-- --===============1155176666== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1155176666==-- From sip-bounces@ietf.org Wed Nov 3 12:35:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00479 for ; Wed, 3 Nov 2004 12:35:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPPHr-0002KZ-4U for sip-web-archive@ietf.org; Wed, 03 Nov 2004 12:51:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPOr4-0007M8-H0; Wed, 03 Nov 2004 12:23:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPObH-0002hG-Gf for sip@megatron.ietf.org; Wed, 03 Nov 2004 12:07:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27869 for ; Wed, 3 Nov 2004 12:07:09 -0500 (EST) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPOqU-0001e9-6q for sip@ietf.org; Wed, 03 Nov 2004 12:23:04 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iA3H6uWR029435 for ; Wed, 3 Nov 2004 18:06:56 +0100 (MET) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 3 Nov 2004 18:06:54 +0100 Received: from [147.214.34.66] (research-1fd0e1.ki.sw.ericsson.se [147.214.34.66]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id WFKZQ7L2; Wed, 3 Nov 2004 18:06:54 +0100 Message-ID: <418754FA.20102@ericsson.com> Date: Tue, 02 Nov 2004 10:35:54 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: Sheetal Khemani Subject: Re: [Sip] SIP AMR Codec (RFC3267) out-of-band bitrate change References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Nov 2004 17:06:54.0513 (UTC) FILETIME=[84DFD210:01C4C1C7] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, sip-implementors@cs.columbia.edu X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Hi, There is no explicit out-of-band signalling for mode changes defined for the RTP payload format for AMR. Mode changes within the active mode-set is expected to be made in two different ways. 1. The sender already posses the information that it needs to switch and simply does this. The main information source is expected to congestion control. Thus information from RTCP or DCCP can be used to allow the sender to determine the need for reducing or increasing the rate. 2. The inband Code Mode Request (CMR) field. This field is intended to be used in gateway cases. For example a session between a IP client and a circuit switched mobile client. The rules and recommendation on how the CMR field should be used are present in section 3.9 of RFC 3267. I would also like to clarify that a sender is able to at any point switch codec mode (within the active mode-set) during a session, no external signalling is needed. So to be able to change the bit-rate there is only the need to know that you need to change the rate. Do you have a need for indication that is based on external indication, and not based on available bit-rate? Cheers Magnus Sheetal Khemani wrote: > Hi, > > I want to know if AMR mode changes are supported via SIP/SDP (possibly > using a new off in a reINVITE). > > RFC3267 doesn't mention any parameter in the SDP to change the bitrate > during the call using SIP. It allows the mode-set parameter that tells the > encoder the subset of modes/bitrates it can use. It doesn't allow the > specification of the bitrate the other end needs to use/switch-to. > > I came across some 3GPP docs (3GPP TS 26.236: Packet switched > conversational multimedia applications; Transport protocols) that suggest > using the bandwidth paramter, but that seems to be specific to QoS and I > am not sure if this applies to the SIP standard per se. > > Please let me know if anyone has any insight on this topic. > > Thanks > Sheetal > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 3 16:56:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23825 for ; Wed, 3 Nov 2004 16:56:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPTMk-0000Vm-Kf for sip-web-archive@ietf.org; Wed, 03 Nov 2004 17:12:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPT3S-00075C-GG; Wed, 03 Nov 2004 16:52:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPSnL-00041X-Pp for sip@megatron.ietf.org; Wed, 03 Nov 2004 16:35:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21411 for ; Wed, 3 Nov 2004 16:35:53 -0500 (EST) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPT2k-00089O-7d for sip@ietf.org; Wed, 03 Nov 2004 16:51:50 -0500 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iA3LZGu20605; Wed, 3 Nov 2004 16:35:16 -0500 (EST) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Nov 2004 16:35:16 -0500 Message-ID: From: "Mary Barnes" To: "'Jonathan Rosenberg'" , Dean Willis Subject: RE: [Sip] IPR disclosure on MESSAGE and related use of SIP Date: Wed, 3 Nov 2004 16:35:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.5 (/) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1278425503==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1278425503== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C1EC.FDBFE801" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4C1EC.FDBFE801 Content-Type: text/plain After having consulted with Nortel's patent law group on an appropriate response within the bounds of Nortel corporate policy since I am not a lawyer and cannot legally represent Nortel's position, I'd like to make the following statement on this topic and hopefully, we can close the discussion of this topic. US patent number 6,757,732 issued on June 29, 2004. My understanding is that Nortel became aware of this patent's relevance through a routine periodic review of its newly issued patents shortly thereafter, informed me of the patent within a few weeks, and then worked with me to ensure the patent was properly disclosed to the IETF on July 23, 2004 in compliance with the applicable IETF policy. Nortel Networks considers responsibilities to make appropriate disclosures in accordance with the revised IETF policy seriously. Regards, Mary H. Barnes mary.barnes@nortelnetworks.com -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Jonathan Rosenberg Sent: Tuesday, November 02, 2004 8:24 AM To: Dean Willis Cc: sip@ietf.org Subject: Re: [Sip] IPR disclosure on MESSAGE and related use of SIP Suffice it to say, I am very unhappy about this. This patent was filed in 2000. I do not understand why the disclosure was only made just now, some four years after it was filed and two years after issuance of the RFC. The only reasons I can think of are not very nice. The licensing terms are also unclear. Does Nortel plan on extracting licensing revenues for this? I think some clarifications and explanations from participants from Nortel are in order. -Jonathan R. Dean Willis wrote: > > I've just noticed that Nortel has recently been issued a patent for > which they have made an IPR disclosure relative to RFC 3428, the SIP > MESSAGE method. > > The disclosure document is listed at: > > http://www.ietf.org/ietf/IPR/nortel-ipr-rfc-3428.txt > > The issued patent is US patent number 6,757,732 > > and you can retrieve its full text from: > > http://patft.uspto.gov/netahtml/srchnum.htm > > > -- > Dean Willis > SIP co-chair > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_001_01C4C1EC.FDBFE801 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sip] IPR disclosure on MESSAGE and related use of = SIP

After having consulted with Nortel's patent law group = on an appropriate response within the bounds of Nortel corporate policy = since I am not a lawyer and cannot legally represent Nortel's position, = I'd like to make the following statement on this topic and hopefully, = we can close the discussion of this topic.

US patent number 6,757,732 issued on June 29, 2004. = My understanding is that Nortel became aware of this patent's relevance = through a routine periodic review of its newly issued patents shortly = thereafter, informed me of the patent within a few weeks, and then = worked with me to ensure the patent was properly disclosed to the IETF = on July 23, 2004 in compliance with the applicable IETF policy. =

Nortel Networks considers responsibilities to make = appropriate disclosures in accordance with the revised IETF policy = seriously.


Regards,
Mary H. Barnes
mary.barnes@nortelnetworks.com

-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] = On Behalf Of Jonathan Rosenberg
Sent: Tuesday, November 02, 2004 8:24 AM
To: Dean Willis
Cc: sip@ietf.org
Subject: Re: [Sip] IPR disclosure on MESSAGE and = related use of SIP


Suffice it to say, I am very unhappy about = this.

This patent was filed in 2000. I do not understand = why the disclosure
was only made just now, some four years after it was = filed and two years
after issuance of the RFC. The only reasons I can = think of are not very
nice.

The licensing terms are also unclear. Does Nortel = plan on extracting
licensing revenues for this?

I think some clarifications and explanations from = participants from
Nortel are in order.

-Jonathan R.


Dean Willis wrote:

>
> I've just noticed that Nortel has recently been = issued a patent for
> which they have made an IPR disclosure relative = to RFC 3428, the SIP
> MESSAGE method.
>
> The disclosure document is listed at:
>
> http://www.ietf.org/ietf/IPR/nortel-ipr-rfc-3428.txt
>
> The issued patent is US patent number = 6,757,732
>
> and you can retrieve its full text from:
>
> http://patft.uspto.gov/netahtml/srchnum.htm=
>
>
> --
> Dean Willis
> SIP co-chair
>
> _______________________________________________<= /FONT>
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core = SIP 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.           &= nbsp;       600 Lanidex Plaza
Director, Service Provider VoIP = Architecture   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com       &nbs= p;           &nbs= p;          = FAX:   (973) 952-5050
http://www.jdrosen.net    &nbs= p;           &nbs= p;        PHONE: (973) = 952-5000
http://www.cisco.com

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

------_=_NextPart_001_01C4C1EC.FDBFE801-- --===============1278425503== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1278425503==-- From sip-bounces@ietf.org Wed Nov 3 17:13:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25240 for ; Wed, 3 Nov 2004 17:13:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPTcw-0000wu-8f for sip-web-archive@ietf.org; Wed, 03 Nov 2004 17:29:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPTHX-0002yA-2k; Wed, 03 Nov 2004 17:07:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPT9F-0000kV-51 for sip@megatron.ietf.org; Wed, 03 Nov 2004 16:58:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23997 for ; Wed, 3 Nov 2004 16:58:31 -0500 (EST) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPTOd-0000Xo-AP for sip@ietf.org; Wed, 03 Nov 2004 17:14:28 -0500 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iA3Lvmv24662; Wed, 3 Nov 2004 16:57:48 -0500 (EST) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Nov 2004 16:57:48 -0500 Message-ID: From: "Mary Barnes" To: "'Robert Sparks'" , sip@ietf.org Subject: RE: [Sip] LC on nit-actions and nit-problems Date: Wed, 3 Nov 2004 16:57:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.5 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0238330082==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0238330082== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C1F0.22E21647" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4C1F0.22E21647 Content-Type: text/plain Hi Robert, Other than the few "nits" on the drafts that I identify below, I think these drafts are ready to publish: nit-problems: ------------- - the term NIT isn't really defined before it's first use(obviously, it's clear from the document, but...). I would suggest add "(NIT)" right after the first occurrence of "non-INVITE transaction" in section 1. - even more obviously, you'll need to update your contact info. nit-actions: ------------ - ditto the two points above. Regards, Mary -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Robert Sparks Sent: Friday, October 29, 2004 1:29 PM To: sip@ietf.org Cc: Dean Willis Subject: [Sip] LC on nit-actions and nit-problems Folks - WGLC for the nit actions and problems draft started Oct 20 and is scheduled to end November 3 (next Wednesday). So far I have received _no_ comments. I believe that's because these drafts have been thoroughly discussed, are well understood, and they are ready to go (the points where more discussion is needed have all been moved to nit-future). If you agree, please take a moment to send a note to the list saying "I read this draft and believe it is ready to be published". If you disagree - now is the time to comment! Thanks, RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_001_01C4C1F0.22E21647 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sip] LC on nit-actions and nit-problems

Hi Robert,

Other than the few "nits" on the drafts = that I identify below, I think these drafts are ready to = publish:

nit-problems:
-------------
- the term NIT isn't really defined before it's = first use(obviously, it's clear from the document, but...).  I = would suggest add "(NIT)" right after the first occurrence of = "non-INVITE transaction" in section 1.

- even more obviously, you'll need to update your = contact info.

nit-actions:
------------
- ditto the two points above.

Regards,
Mary


-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] = On Behalf Of Robert Sparks
Sent: Friday, October 29, 2004 1:29 PM
To: sip@ietf.org
Cc: Dean Willis
Subject: [Sip] LC on nit-actions and = nit-problems


Folks -

WGLC for the nit actions and problems draft started = Oct 20 and is
scheduled to
end November 3 (next Wednesday).

So far I have received _no_ comments.

I believe that's because these drafts have been = thoroughly discussed,
are well
understood, and they are ready to go (the points = where more discussion
is needed
have all been moved to nit-future).

If you agree, please take a moment to send a note to = the list saying "I
read this draft
and believe it is ready to be = published".

If you disagree - now is the time to comment!

Thanks,
RjS



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

------_=_NextPart_001_01C4C1F0.22E21647-- --===============0238330082== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0238330082==-- From sip-bounces@ietf.org Wed Nov 3 17:40:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27915 for ; Wed, 3 Nov 2004 17:40:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPU36-0001ZP-6g for sip-web-archive@ietf.org; Wed, 03 Nov 2004 17:56:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPTeg-0007gZ-BE; Wed, 03 Nov 2004 17:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPTYq-0006b3-Vx for sip@megatron.ietf.org; Wed, 03 Nov 2004 17:25:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26360 for ; Wed, 3 Nov 2004 17:24:58 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPToF-0001FU-RM for sip@ietf.org; Wed, 03 Nov 2004 17:40:56 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 03 Nov 2004 14:35:00 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iA3MOQcp013168; Wed, 3 Nov 2004 14:24:27 -0800 (PST) Received: from [10.32.245.155] (stealth-10-32-245-155.cisco.com [10.32.245.155]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id iA3MPYi2021666; Wed, 3 Nov 2004 14:25:35 -0800 In-Reply-To: <4188E883.1090807@nortelnetworks.com> References: <4186E354.1040701@softarmor.com> <41879888.5090302@cisco.com> <4188E883.1090807@nortelnetworks.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1D81F2EB-2DE7-11D9-BDEB-000A95C73842@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [Sip] IPR disclosure on MESSAGE and related use of SIP Date: Wed, 3 Nov 2004 17:24:23 -0500 To: Tom Taylor X-Mailer: Apple Mail (2.619) IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1099520736.271886"; x:"432200"; a:"rsa-sha1"; b:"nofws:3099"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"NdFulKyppXNeipwWzpECaXfey+TIALhMtNgewAL4odZwbcI/qVklmH3AxXh8R" "RKpPYM4IUa/IZe6v9w0sVGFwoRAT/sit5yG64qs7bRsvYFd1R8useEdZ/Y2ee" "njFWZdICw3xtlodr7A+T5CK+qlF+R5rafGXZkiE0A559ldYpo="; c:"From: David R Oran "; c:"Subject: Re: [Sip] IPR disclosure on MESSAGE and related use of SIP"; c:"Date: Wed, 3 Nov 2004 17:24:23 -0500" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit On Nov 3, 2004, at 9:17 AM, Tom Taylor wrote: > I'm probably going to get into trouble for responding, but I can't sit > by and let you throw mud at my colleagues. > Don appropriate lead BVDs Tom. > Jonathan, you once worked for a large company. Now you do, again. > Can you really say you know everything that's going on in Cisco that > might relate to your ETF activities? > No, not for any single individual, but there is a process for IPR disclosures at Cisco, and it is followed rigorously and taken VERY seriously. In fact, you can't even file a Patent disclosure into our patent system without filling in a statement as to whether the IPR might apply to a standard and if so which one(s). As a check/balance, each of our patent committees has at least one member who is up to date on standardization activities in that technology area. It is particularly troubling when such disclosures appear on submarines. In order to support your point, I believe you have to demonstrate that none of the co-inventors, nor any of the internal reviewers in the line to filing and issuance, were aware of the ongoing IETF activities. > It's getting tougher as we get slimmed down, but Nortel (and BNR > before that) has had a long tradition of people in odd corners > exploring the possibilities of technology and coming up with new ideas > unrelated to their current products. And like it or not, Nortel views > intellectual property as a source of value, so people are encouraged > to take out patents on new ideas. > If that is the case here, 'll be happy to cut some slack. Could you ascertain, please? > Mary was unaware of the patent concerned until a week before the > patent announcement. At that point she took the necessary steps to > have it announced. > Thank you, Mary. What about the other Nortel IETF participants who work with SIP? > And we who participate at the IETF are not patent lawyers -- we can > only refer you to our own legal people for further advice. Thanks. Dave. > Jonathan Rosenberg wrote: >> Suffice it to say, I am very unhappy about this. >> This patent was filed in 2000. I do not understand why the disclosure >> was only made just now, some four years after it was filed and two >> years after issuance of the RFC. The only reasons I can think of are >> not very nice. >> The licensing terms are also unclear. Does Nortel plan on extracting >> licensing revenues for this? >> I think some clarifications and explanations from participants from >> Nortel are in order. >> -Jonathan R. > > > -- > Tom Taylor > Carrier VoIP Standards Development > Nortel Networks > Phone +1 613 763 1496 (ESN 393-1496) > E-mail: taylor@nortelnetworks.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 3 20:08:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09587 for ; Wed, 3 Nov 2004 20:08:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPWMu-0004hs-He for sip-web-archive@ietf.org; Wed, 03 Nov 2004 20:24:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPW4u-0005Ys-L3; Wed, 03 Nov 2004 20:06:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPW2d-0005AV-GY for sip@megatron.ietf.org; Wed, 03 Nov 2004 20:03:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09351 for ; Wed, 3 Nov 2004 20:03:53 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPWI3-0004bU-U6 for sip@ietf.org; Wed, 03 Nov 2004 20:19:52 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 03 Nov 2004 17:16:07 -0800 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iA4133om022058; Wed, 3 Nov 2004 17:03:04 -0800 (PST) Received: from cisco.com ([161.44.79.125]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMU04986; Wed, 3 Nov 2004 20:03:12 -0500 (EST) Message-ID: <41897FCF.8060602@cisco.com> Date: Wed, 03 Nov 2004 20:03: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: jon.peterson@neustar.biz Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org Subject: [Sip] Re: draft-ietf-sip-identity-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Jon, Just catching up on my reading. A few questions/comments about the draft: There is allusion to using this mechanism with redirect servers. But there are no examples of this. At least one small thing might not work great in such a case. The authentication service is required to add a Date header if not already present, and then use in in the signature. This won't work well for a redirect lacking Date. It may have need/requirement to use some other server as first hop, and may or may not even have way to know which one is the auth server.Requirement for UA to directly connect to auth server seems unrealistic. And requirement to send auth request over a tls connection seems insufficient if there are other hops. UA can't really be sure that the auth server with be the first hop. And it can't necessarily use sips to guarantee hop by hop security till it gets there. How about having the *UA* generate an identity header (or variant) signed somehow with its digest key to protect the message on the say to the auth server? (I'm not a crypto guy - maybe there is no way to make this work.) You strongly discourage use of tel: in from:. But there are advantages of tel: - that recipient can render it as a phone number, which isn't really kosher if it is a sip url, even with user=phone. And return calls to it are obligated to use sip via the stated domain, while with tel the caller has more options. Hash includes digit and method portions of CSeq. Digit portion could have leading zeros. As it passes thru other intermediate nodes it is possible this would be parsed and regenerated, losing the leading zeros. To avoid, value used here should drop redundant leading zeros. Above are really small stuff. This is looking quite feasible now. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 4 00:35:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27255 for ; Thu, 4 Nov 2004 00:35:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPaXM-0001b6-CO for sip-web-archive@ietf.org; Thu, 04 Nov 2004 00:51:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPaBF-00073v-UA; Thu, 04 Nov 2004 00:29:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPa5z-0006FP-V0 for sip@megatron.ietf.org; Thu, 04 Nov 2004 00:23:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25433 for ; Thu, 4 Nov 2004 00:23:36 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPaLS-0001Ar-Dc for sip@ietf.org; Thu, 04 Nov 2004 00:39:38 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 03 Nov 2004 21:23:14 -0800 X-BrightmailFiltered: true Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id iA45N5JZ029693; Wed, 3 Nov 2004 21:23:05 -0800 (PST) Received: from [10.6.60.52] (sjc-vpn5-161.cisco.com [10.21.88.161]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFN13512; Wed, 3 Nov 2004 21:23:03 -0800 (PST) Message-ID: <4189A865.8000701@cisco.com> Date: Wed, 03 Nov 2004 22:56:21 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Taylor Subject: Re: [Sip] IPR disclosure on MESSAGE and related use of SIP References: <4186E354.1040701@softarmor.com> <41879888.5090302@cisco.com> <4188E883.1090807@nortelnetworks.com> In-Reply-To: <4188E883.1090807@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Tom Taylor wrote: > I'm probably going to get into trouble for responding, but I can't sit > by and let you throw mud at my colleagues. Mud? Where is there mud? I have asked what I think are legitimate questions about this patent - why was the disclosure made only now, and what are the terms. I have no doubt that you would ask the same if our roles were reversed. > > And we who participate at the IETF are not patent lawyers -- we can only > refer you to our own legal people for further advice. One of the things that has driven success for SIP (and the resulting business for us all) has been its relatively IPR-free status for the core specifications (in terms of the known disclosures made to IETF; I can't say anything about patents we don't know about that might be out there). MESSAGE is fairly core to SIP, and I would hate to see its usage and deployment be derailed as people run from it due to very unclear IPR applicability and licensing terms. I suspect that any strong drive to extract revenue from it would just result in quicker abandonment and usage of MSRP instead. As such, in the end such an attempt would equate to an RF license. While at dynamicsoft, I pushed for us to adopt a "don't bug us and we won't bug you" stance (http://www.ietf.org/ietf/IPR/DYNAMICSOFT-SIP-UNIFY.txt), which brings some of the benefits of RF (doesn't scare folks off) but preserves the defensive value of the IPR. Cisco has made similar statements (http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-nemo-basic-support-03.txt). I hope you agree that this kind of stance is good for us all, and if you could help your legal folks understand this and make a similar statement, it would be outstanding. I'd be happy to help with that in any way that I can. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 4 01:26:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02862 for ; Thu, 4 Nov 2004 01:26:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPbKD-0002rq-Lo for sip-web-archive@ietf.org; Thu, 04 Nov 2004 01:42:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPb1K-00083E-ST; Thu, 04 Nov 2004 01:22:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPax5-0006wr-CN for sip@megatron.ietf.org; Thu, 04 Nov 2004 01:18:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02378 for ; Thu, 4 Nov 2004 01:18:30 -0500 (EST) Message-Id: <200411040618.BAA02378@ietf.org> Received: from smtp106.mail.sc5.yahoo.com ([66.163.169.226]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CPbCX-0002ht-Hm for sip@ietf.org; Thu, 04 Nov 2004 01:34:31 -0500 Received: from unknown (HELO cranberry) (seancolson@4.41.219.68 with login) by smtp106.mail.sc5.yahoo.com with SMTP; 4 Nov 2004 06:18:27 -0000 From: "Sean Olson" To: Subject: RE: [Sip] IPR disclosure on MESSAGE and related use of SIP Date: Wed, 3 Nov 2004 22:18:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: Thread-Index: AcTA/9cHA1TscCacRA2fWQw2248g0QBNdH4Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: seancolson@yahoo.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7bit For what it is worth, there may be prior art here. Billy Biggs demonstrated an implementation of MESSAGE based IM at the 4th SIP bake-off hosted by 3Com (April 17th-19th 2000) and had an even earlier implementation. -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Srini Krishnamoorthy Sent: Tuesday, November 02, 2004 8:34 AM To: Jonathan Rosenberg Cc: sip@ietf.org; Dean Willis Subject: Re: [Sip] IPR disclosure on MESSAGE and related use of SIP Jonathan et.al, Agree, and I think a LOT of people will be unhappy too .. Do we read this as specific to the use of "INFO + HTML body" or in general :- "communicating the text-based chat message includes embedding the text-based chat message" (which the the first claim states)?" How does this IPR affect the use of MESSAGE method with content-types other than text/html (say plain, xml) - what would be considered infringment? .. anybody Nortel?? Please help understand the detailed impact of this ... thanks. Or should I just wait to see what transpires?? -Srini On Tue, 2 Nov 2004, Jonathan Rosenberg wrote: jdrose>Suffice it to say, I am very unhappy about this. jdrose> jdrose>This patent was filed in 2000. I do not understand why the jdrose>disclosure was only made just now, some four years after it was jdrose>filed and two years after issuance of the RFC. The only reasons I jdrose>can think of are not very nice. jdrose> jdrose>The licensing terms are also unclear. Does Nortel plan on jdrose>extracting licensing revenues for this? jdrose> jdrose>I think some clarifications and explanations from participants jdrose>from Nortel are in order. jdrose> jdrose>-Jonathan R. jdrose> jdrose> jdrose>Dean Willis wrote: jdrose> jdrose>> jdrose>> I've just noticed that Nortel has recently been issued a patent jdrose>> for which they have made an IPR disclosure relative to RFC jdrose>> 3428, the SIP MESSAGE method. jdrose>> jdrose>> The disclosure document is listed at: jdrose>> jdrose>> http://www.ietf.org/ietf/IPR/nortel-ipr-rfc-3428.txt jdrose>> jdrose>> The issued patent is US patent number 6,757,732 jdrose>> jdrose>> and you can retrieve its full text from: jdrose>> jdrose>> http://patft.uspto.gov/netahtml/srchnum.htm jdrose>> jdrose>> jdrose>> -- jdrose>> Dean Willis jdrose>> SIP co-chair jdrose>> jdrose>> _______________________________________________ jdrose>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip jdrose>> This list is for NEW development of the core SIP Protocol Use jdrose>> sip-implementors@cs.columbia.edu for questions on current sip jdrose>> Use sipping@ietf.org for new developments on the application of jdrose>> sip jdrose>> jdrose> jdrose> -- Srini K ksrini at motorola Finger ksrini@bulb.corp.mot.com for pub key. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 4 05:35:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06970 for ; Thu, 4 Nov 2004 05:35:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPfDV-0000AO-Tg for sip-web-archive@ietf.org; Thu, 04 Nov 2004 05:51:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPeoM-0000el-CZ; Thu, 04 Nov 2004 05:25:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPeje-00080q-8n for sip@megatron.ietf.org; Thu, 04 Nov 2004 05:20:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05829 for ; Thu, 4 Nov 2004 05:20:52 -0500 (EST) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPez7-0008Eh-OA for sip@ietf.org; Thu, 04 Nov 2004 05:36:56 -0500 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id iA4AJK10018081; Thu, 4 Nov 2004 10:19:20 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Thu, 4 Nov 2004 05:19:20 -0500 Message-ID: <7927C67249E4AD43BC05B539AF0D129801AF4312@stntexch04.cis.neustar.com> From: "Peterson, Jon" To: "'Paul Kyzivat'" Date: Thu, 4 Nov 2004 05:19:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: sip@ietf.org Subject: [Sip] RE: draft-ietf-sip-identity-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Thanks for the close reading, Paul - I know you tend to unearth a lot of details that others miss, so I especially appreciate your taking a look at this. A few responses inline: > There is allusion to using this mechanism with redirect servers. But > there are no examples of this. At least one small thing might not work > great in such a case. The authentication service is required to add a > Date header if not already present, and then use in in the signature. > This won't work well for a redirect lacking Date. > Well, I've been roughly assuming that the RFC3261 19.1.5 procedures could be used to insert a Date header, if needed, but that hasn't been articulated in the draft. e.g.: sips:alice@atlanta.example.com?Date=... There's some ugly escaping that would be required to make that work, but I think it's doable. Of course, it isn't documented, but as you point out, there is merely an allusion to this today. Ultimately, I intended to take this up as future work, given some community interest. > It may have need/requirement to use some other server as first hop, > and may or may not even have way to know which one is the auth > server. Requirement for UA to directly connect to auth server seems > unrealistic. Personally, I have yet to use SIP in any environment in which I have been forced to go through some proxy as a first hop, where first hop wouldn't reasonably be the party that should provide identity services for me. What the draft says now, essentially, is that the mechanism is only applicable to scenarios where a UA can connect directly to an auth service. While long-term deployment experience may prove this scope wise or foolish, the design choice here hasn't been made capriciously - given the security tools available, if the UA cannot connect directly to the auth service, then we encounter serious questions about the efficacy of the mechanism (see below). The manner in which the UAC might determine that it is talking to an auth service is, however, pretty straightforward. Considering the Digest authentication case, from the UAC perspective, all it cares about is the challenge realm. If the challenge realm matches the domain of the UAC's AoR, and the cert acquired by TLS matches the challenge realm, then as far as the UAC is concerned, it should authenticate itself to the server (and this is all just standard RFC3261 behavior). Strictly speaking, there are architectures where these conditions might be satisfied, but the auth service would not actually be the first-hop proxy - in these cases, though, the auth service and the first-hop proxy would be components of a common administrative domain, and effectively would be acting as a distributed auth service (though this is undocumented today). This loophole arises because this mechanism is intended to be useful opportunistically - that is, without the UAC even being aware that it is talking to an auth service. Accordingly, the draft makes few assumptions about how UACs behave other than those already made in RFC3261. So, ultimately it is up to the auth service itself whether or not it adds an Identity header. Anyway, in many environments where I imagine one might be forced to go through a particular proxy as a first hop, that proxy is probably a good candidate to instantiate the auth service role. If the environment of the UAC forces a first-hop proxy, and doesn't provide auth services appropriate for the UAC, then the environment blocks the UAC from using an identity service. The fact that this is possible is not, I think, a strong argument to reconsider the mechanism; in some environments, this may be the desired effect, even. Of course, it is also the case the UAC can act as an auth service in the draft as written; in very constrained environments, this may be the best way to get an Identity header. > And requirement to send auth request over a tls connection > seems insufficient if there are other hops. UA can't really be sure that > the auth server with be the firs hopt. And it can't necessarily use sips > to guarantee hop by hop security till it gets there. Agreed, but I think it would be closer to the truth to say that the UA and auth service cannot authenticate one another unless they are one hop apart (I also don't think SIPS will help much). While the identity mechanism may not be applicable to all deployment possibilities, I think it is useful as it stands. > How about having > the *UA* generate an identity header (or variant) signed somehow with > its digest key to protect the message on the say to the auth server? > (I'm not a crypto guy - maybe there is no way to make this work.) > There is some merit to that idea. I mean, essentially that is what the Proxy-Authorization header can provide (though auth-int wouldn't guarantee integrity over the same set of headers). What you want to avoid is cases where the UAC cannot authenticate the auth service, and a rogue challenger launches some sort of dictionary attack to discover the Digest credentials once it has a Proxy-Authorization header in hand. I'm not sure there's a way to structure a UAC-generated digest for this purpose that wouldn't suffer from this concern. To get there, we'd certainly be reinventing the majority of what Proxy-Auth headers do. Hence the direct TLS, and the challenge-realm matching, which insures that the UAC can authenticate the auth service. Just handing out your digested password to any transitively-trusted proxy that challenges you is potentially risky. > You strongly discourage use of tel: in from:. But there are advantages > of tel: - that recipient can render it as a phone number, which isn't > really kosher if it is a sip url, even with user=phone. And return calls > to it are obligated to use sip via the stated domain, while with tel the > caller has more options. > The reasons for discouraging the use of tel are given in the draft, and are compelling, I think. As a recipient verifying the identity header, why should you trust, say, cisco.com to authorize the use of the telephone number '+15165551001'? There's certainly no a priori way for a recipient to determine whether or not cisco.com is entitled to make any such assertion. It is very clear, though, why you would trust cisco.com to authorize the use of the name paul.kyzviat@cisco.com. There's no question that it would be useful to provide identity services for telephone numbers. While the draft discourages their use, it doesn't forbid it, and it leaves the door open for subsequent work to define something here. A number of theories are circulating (like using ENUM in some fashion), but it'll take a while to shake out. > Hash includes digit and method portions of CSeq. Digit portion could > have leading zeros. As it passes thru other intermediate nodes it is > possible this would be parsed and regenerated, losing the leading zeros. > To avoid, value used here should drop redundant leading zeros. Good catch. Will incorporate it. > Above are really small stuff. This is looking quite feasible now. > Great! Jon Peterson NeuStar, Inc. > Paul > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 4 08:13:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17488 for ; Thu, 4 Nov 2004 08:13:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPhfv-0003YZ-Vh for sip-web-archive@ietf.org; Thu, 04 Nov 2004 08:29:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPhMP-0005bh-4R; Thu, 04 Nov 2004 08:09:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPhHw-0004Y0-RR for sip@megatron.ietf.org; Thu, 04 Nov 2004 08:04:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16394 for ; Thu, 4 Nov 2004 08:04:27 -0500 (EST) Received: from [69.55.225.91] (helo=www.implementers.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPhXI-0003Fx-KH for sip@ietf.org; Thu, 04 Nov 2004 08:20:32 -0500 Received: by www.implementers.org (Postfix, from userid 1006) id D5C612FFA292; Thu, 4 Nov 2004 05:04:13 -0800 (PST) Received: from [10.1.28.2] (localhost [127.0.0.1]) by www.implementers.org (Postfix) with ESMTP id 60BFE2FFA291 for ; Thu, 4 Nov 2004 05:04:06 -0800 (PST) Message-ID: <418A28DB.60206@acm.org> Date: Thu, 04 Nov 2004 05:04:27 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.3) Gecko/20041008 Debian/1.7.3-5 X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on www.implementers.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Subject: [Sip] reINVITE X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit I already asked this in sip-implementors, but I didn't received any conclusive answer. RFC3261 is not clear about when an UAS must be ready to receive a new reINVITE in a dialog. My reading of the RFC is that the UAS must be ready to receive a new INVITE in a dialog as soon a response was sent for the previous INVITE. More precisely, that the UAS must not wait for the ACK before accepting the next INVITE. Accepting in this case means that the INVITE is passed to the application - the INVITE can be rejected by the application because of the content of the SDP, but not because of a violation of the signalling protocol. My reasoning is based on the fact that RFC3261 section 14.1 says that "If there is an outgoing INVITE client transaction, the TU must wait until the transaction reaches the completed or terminated state before initiating the new INVITE." As an INVITE transaction reaches the completed or terminated state as soon a non-provisional response is received, the next INVITE can be sent at the same time the ACK for the 200 response is sent. As the packet ordering can change, the INVITE can arrive at the UAS before the ACK. So this mean that the server should be prepared to receive the next INVITE before receiving the ACK. Is it correct? Please note that my question is not about how SIP implementations work in this case, but really on what was RFC3261's authors intent. Thank you. -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: marc@8x8.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 4 09:15:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22960 for ; Thu, 4 Nov 2004 09:15:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPidx-00054B-L7 for sip-web-archive@ietf.org; Thu, 04 Nov 2004 09:31:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPiIL-0007qq-Iu; Thu, 04 Nov 2004 09:08:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPiEg-0007Hm-Fj for sip@megatron.ietf.org; Thu, 04 Nov 2004 09:05:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21929 for ; Thu, 4 Nov 2004 09:05:09 -0500 (EST) Received: from broadsoft.com ([204.200.197.133]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPiUD-0004mW-2D for sip@ietf.org; Thu, 04 Nov 2004 09:21:14 -0500 Received: from brett1 (host4.brodsoft.com [66.160.10.4]) (authenticated bits=0) by broadsoft.com (8.13.1/8.12.11) with ESMTP id iA4E4xsc008049 for ; Thu, 4 Nov 2004 09:05:03 -0500 (EST) From: "Brett Tate" To: Subject: RE: [Sip] reINVITE Date: Thu, 4 Nov 2004 09:05:10 -0500 Message-ID: <000201c4c277$4cab2d80$a601a8c0@brett1> 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.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <418A28DB.60206@acm.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit > So this mean that the server should > be prepared to receive the next > INVITE before receiving the ACK. > > Is it correct? It should be prepared; however the re-INVITE can be rejected. One of the reasons could be associated with the need of an SDP within the ACK. Other reasons could be associated service interactions or product limitations concerning race conditions. Thus the uac should be prepared to receive 500 response with a retry-after. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 4 09:23:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24049 for ; Thu, 4 Nov 2004 09:23:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPilw-0005Ku-Tu for sip-web-archive@ietf.org; Thu, 04 Nov 2004 09:39:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPiV5-0002lq-CY; Thu, 04 Nov 2004 09:22:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPiO4-0000PL-Tx for sip@megatron.ietf.org; Thu, 04 Nov 2004 09:14:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22900 for ; Thu, 4 Nov 2004 09:14:51 -0500 (EST) Received: from [204.57.52.4] (helo=iperia.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPidb-00051T-8X for sip@ietf.org; Thu, 04 Nov 2004 09:30:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] reINVITE Date: Thu, 4 Nov 2004 09:14:02 -0500 Message-ID: <8019F8581B5FC14DBD94BAF86844868E352DA3@viridis.IPeria.local> Thread-Topic: [Sip] reINVITE Thread-Index: AcTCcISncZynQY/sRMCV9igPqM+GpgABy13g From: "Gordon Ledgard" To: "Marc Petit-Huguenin" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: quoted-printable Perhaps someone will chime in and correct me if I'm wrong. I believe I ran into the same issue a while back, concluding that if another INVITE were accepted before the ACK to the previous invite arrived it could cause rather serious instability problems in session=20 negotiations, not to mention trying to align ACKS. The answer is that you should not accept a new INVITE until the previous INVITE transaction is complete. Complete means the ACK was seen. I agree the spec is a bit vague there. Gordon R. Ledgard IPeria, Inc. -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of Marc Petit-Huguenin Sent: Thursday, November 04, 2004 8:04 AM To: sip@ietf.org Subject: [Sip] reINVITE I already asked this in sip-implementors, but I didn't received any=20 conclusive answer. RFC3261 is not clear about when an UAS must be ready to receive a new=20 reINVITE in a dialog. My reading of the RFC is that the UAS must be ready to receive a new = INVITE=20 in a dialog as soon a response was sent for the previous INVITE. More=20 precisely, that the UAS must not wait for the ACK before accepting the = next=20 INVITE. Accepting in this case means that the INVITE is passed to the=20 application - the INVITE can be rejected by the application because of = the=20 content of the SDP, but not because of a violation of the signalling = protocol. My reasoning is based on the fact that RFC3261 section 14.1 says that = "If=20 there is an outgoing INVITE client transaction, the TU must wait until = the=20 transaction reaches the completed or terminated state before initiating = the=20 new INVITE." As an INVITE transaction reaches the completed or = terminated=20 state as soon a non-provisional response is received, the next INVITE = can=20 be sent at the same time the ACK for the 200 response is sent. As the=20 packet ordering can change, the INVITE can arrive at the UAS before the=20 ACK. So this mean that the server should be prepared to receive the next = INVITE before receiving the ACK. Is it correct? Please note that my question is not about how SIP implementations work = in=20 this case, but really on what was RFC3261's authors intent. Thank you. --=20 Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: marc@8x8.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 sip-bounces@ietf.org Thu Nov 4 10:25:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00364 for ; Thu, 4 Nov 2004 10:25:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPjkR-0006tM-Jo for sip-web-archive@ietf.org; Thu, 04 Nov 2004 10:42:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPjS1-0004ti-1G; Thu, 04 Nov 2004 10:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPjBp-0005nh-8K for sip@megatron.ietf.org; Thu, 04 Nov 2004 10:06:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27654 for ; Thu, 4 Nov 2004 10:06:15 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPjRM-0006NH-Re for sip@ietf.org; Thu, 04 Nov 2004 10:22:21 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 04 Nov 2004 07:18:35 -0800 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iA4F5com017917; Thu, 4 Nov 2004 07:05:38 -0800 (PST) Received: from cisco.com ([161.44.79.125]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMU32946; Thu, 4 Nov 2004 10:05:40 -0500 (EST) Message-ID: <418A4544.7020506@cisco.com> Date: Thu, 04 Nov 2004 10:05:40 -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: "Peterson, Jon" References: <7927C67249E4AD43BC05B539AF0D129801AF4312@stntexch04.cis.neustar.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org Subject: [Sip] Re: draft-ietf-sip-identity-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Content-Transfer-Encoding: 7bit Peterson, Jon wrote: > Thanks for the close reading, Paul - I know you tend to unearth a lot of > details that others miss, so I especially appreciate your taking a look at > this. A few responses inline >>There is allusion to using this mechanism with redirect servers. But >>there are no examples of this. At least one small thing might not work >>great in such a case. The authentication service is required to add a >>Date header if not already present, and then use in in the signature. >>This won't work well for a redirect lacking Date. > > Well, I've been roughly assuming that the RFC3261 19.1.5 procedures could be > used to insert a Date header, if needed, but that hasn't been articulated in > the draft. > > e.g.: sips:alice@atlanta.example.com?Date=... > > There's some ugly escaping that would be required to make that work, but I > think it's doable. Of course, it isn't documented, but as you point out, > there is merely an allusion to this today. Ultimately, I intended to take > this up as future work, given some community interest. OK. If the intent was simply to point the way for future work, then fine. That wasn't clear to me. >> It may have need/requirement to use some other server as first hop, >>and may or may not even have way to know which one is the auth >>server. Requirement for UA to directly connect to auth server seems >>unrealistic. > > Personally, I have yet to use SIP in any environment in which I have been > forced to go through some proxy as a first hop, where first hop wouldn't > reasonably be the party that should provide identity services for me. What about the IMS architecture, when you are connected to a visited network? The P-CSCF may be able to authenticate you, but it won't be able to sign your identity with credentials from your home domain. (That of course is just an example.) > What > the draft says now, essentially, is that the mechanism is only applicable to > scenarios where a UA can connect directly to an auth service. While > long-term deployment experience may prove this scope wise or foolish, the > design choice here hasn't been made capriciously - given the security tools > available, if the UA cannot connect directly to the auth service, then we > encounter serious questions about the efficacy of the mechanism (see below). > > The manner in which the UAC might determine that it is talking to an auth > service is, however, pretty straightforward. Considering the Digest > authentication case, from the UAC perspective, all it cares about is the > challenge realm. If the challenge realm matches the domain of the UAC's AoR, > and the cert acquired by TLS matches the challenge realm, then as far as the > UAC is concerned, it should authenticate itself to the server (and this is > all just standard RFC3261 behavior). Seems like the challenge realm is a red herring above. If the TLS cert matches the domain of my AOR then I know I am one hop away from something authoritative for my domain, regardless of the challenge. Since there could be many proxies in my domain, the challenge could be coming from a different one. In any case I have to forumulate the request before being challenged. > Strictly speaking, there are > architectures where these conditions might be satisfied, but the auth > service would not actually be the first-hop proxy - in these cases, though, > the auth service and the first-hop proxy would be components of a common > administrative domain, and effectively would be acting as a distributed auth > service (though this is undocumented today). This loophole arises because > this mechanism is intended to be useful opportunistically - that is, without > the UAC even being aware that it is talking to an auth service. Accordingly, > the draft makes few assumptions about how UACs behave other than those > already made in RFC3261. So, ultimately it is up to the auth service itself > whether or not it adds an Identity header. Yes, this certainly is a possibility. Maybe it would help to soften the stance in the document, by inserting some words like those above. > Anyway, in many environments where I imagine one might be forced to go > through a particular proxy as a first hop, that proxy is probably a good > candidate to instantiate the auth service role. If the environment of the > UAC forces a first-hop proxy, and doesn't provide auth services appropriate > for the UAC, then the environment blocks the UAC from using an identity > service. The fact that this is possible is not, I think, a strong argument > to reconsider the mechanism; in some environments, this may be the desired > effect, even. The IMS case I mentioned above fits this. The UAC is forced to use a first hop proxy with credentials for a different (visited) domain. But the home domain of the UAC has a business relationship with the visited domain and trusts it. But I don't see any way to exploit that relationship so that the home proxy could safely sign the request. I guess I agree that this might be a reason to find that connection mechanism to be suspect. > Of course, it is also the case the UAC can act as an auth service in the > draft as written; in very constrained environments, this may be the best way > to get an Identity header. Sure. But then you are back to needing UAs with certs. >>And requirement to send auth request over a tls connection >>seems insufficient if there are other hops. UA can't really be sure that >>the auth server with be the firs hopt. And it can't necessarily use sips >>to guarantee hop by hop security till it gets there. > > Agreed, but I think it would be closer to the truth to say that the UA and > auth service cannot authenticate one another unless they are one hop apart > (I also don't think SIPS will help much). While the identity mechanism may > not be applicable to all deployment possibilities, I think it is useful as > it stands. Well, if the identity mechanism can become sufficiently compelling, then it might rule out architectures that prevent its use. Perhaps this is the real motivation. :-) >>How about having >>the *UA* generate an identity header (or variant) signed somehow with >>its digest key to protect the message on the say to the auth server? >>(I'm not a crypto guy - maybe there is no way to make this work.) > > There is some merit to that idea. I mean, essentially that is what the > Proxy-Authorization header can provide (though auth-int wouldn't guarantee > integrity over the same set of headers). What you want to avoid is cases > where the UAC cannot authenticate the auth service, and a rogue challenger > launches some sort of dictionary attack to discover the Digest credentials > once it has a Proxy-Authorization header in hand. I'm not sure there's a way > to structure a UAC-generated digest for this purpose that wouldn't suffer > from this concern. To get there, we'd certainly be reinventing the majority > of what Proxy-Auth headers do. Hence the direct TLS, and the challenge-realm > matching, which insures that the UAC can authenticate the auth service. Just > handing out your digested password to any transitively-trusted proxy that > challenges you is potentially risky. As I said, I'm not a crypto guy. I was expecting that there would probably be some issue like this. >>You strongly discourage use of tel: in from:. But there are advantages >>of tel: - that recipient can render it as a phone number, which isn't >>really kosher if it is a sip url, even with user=phone. And return calls >>to it are obligated to use sip via the stated domain, while with tel the >>caller has more options. > > The reasons for discouraging the use of tel are given in the draft, and are > compelling, I think. As a recipient verifying the identity header, why > should you trust, say, cisco.com to authorize the use of the telephone > number '+15165551001'? There's certainly no a priori way for a recipient to > determine whether or not cisco.com is entitled to make any such assertion. I agree with the concern, but the need is still there. > It is very clear, though, why you would trust cisco.com to authorize the use > of the name paul.kyzviat@cisco.com. > > There's no question that it would be useful to provide identity services for > telephone numbers. While the draft discourages their use, it doesn't forbid > it, and it leaves the door open for subsequent work to define something > here. A number of theories are circulating (like using ENUM in some > fashion), but it'll take a while to shake out. Yes, enum does seem like it might provide a solution. Maybe this will have to do for now. >>Hash includes digit and method portions of CSeq. Digit portion could >>have leading zeros. As it passes thru other intermediate nodes it is >>possible this would be parsed and regenerated, losing the leading zeros. >>To avoid, value used here should drop redundant leading zeros. > > Good catch. Will incorporate it. I looked for other similar issues but didn't find any. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 4 10:53:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02991 for ; Thu, 4 Nov 2004 10:53:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPkB9-0007ZB-BX for sip-web-archive@ietf.org; Thu, 04 Nov 2004 11:09:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPjrk-0003Eo-0f; Thu, 04 Nov 2004 10:49:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPjlf-0001IJ-HI for sip@megatron.ietf.org; Thu, 04 Nov 2004 10:43:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02140 for ; Thu, 4 Nov 2004 10:43:17 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPk1B-0007ID-QY for sip@ietf.org; Thu, 04 Nov 2004 10:59:24 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 04 Nov 2004 07:53:25 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iA4Fghcp012007; Thu, 4 Nov 2004 07:42:44 -0800 (PST) Received: from cisco.com ([161.44.79.125]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMU36256; Thu, 4 Nov 2004 10:42:42 -0500 (EST) Message-ID: <418A4DF2.7030902@cisco.com> Date: Thu, 04 Nov 2004 10:42:42 -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: "Peterson, Jon" References: <7927C67249E4AD43BC05B539AF0D129801AF4312@stntexch04.cis.neustar.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org Subject: [Sip] Re: draft-ietf-sip-identity-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit One other thing occurred to me. You point out that there is some significant cost to the signing operation. I am thinking that this might be done on an as-needed basis. For instance, the proxy could first just pass the request along without signing it. If a 428 'Use Identity Header' is received in response the request could signed and retried. But I think there are problems with the proxy doing the retry on its own. It could be done under explicit control of the UAC, but then there would need to be a way for the UAC to request that signing be done, or not. This might be especially interesting in an environment where P-Asserted-Identity is often sufficient. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 4 11:00:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03691 for ; Thu, 4 Nov 2004 11:00:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPkHu-0007kV-Oy for sip-web-archive@ietf.org; Thu, 04 Nov 2004 11:16:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPjtq-0003gu-32; Thu, 04 Nov 2004 10:51:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPjpI-00025w-RG for sip@megatron.ietf.org; Thu, 04 Nov 2004 10:47:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02352 for ; Thu, 4 Nov 2004 10:47:00 -0500 (EST) Received: from figas.ekabal.com ([157.22.13.42]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPk4o-0007OA-6G for sip@ietf.org; Thu, 04 Nov 2004 11:03:06 -0500 Received: from [131.161.248.87] (open-131-161-248-87.cliq.com [131.161.248.87]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id iA4FkmC16729; Thu, 4 Nov 2004 07:46:48 -0800 Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Thu, 4 Nov 2004 07:46:22 -0800 To: sip@ietf.org X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: Rohan Mahy , "'Gonzalo Camarillo'" , Dean Willis Subject: [Sip] WGLC for App Interact X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Hi Folks, we would like to working group last call the following draft in SIP in parallel with SIPPING: http://www.ietf.org/internet-drafts/draft-ietf-sipping-app-interaction- framework-03.txt This WGLC will finish on December 3rd. Please, send you comments to the authors and to the *SIP* list. 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 sip-bounces@ietf.org Thu Nov 4 12:43:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15010 for ; Thu, 4 Nov 2004 12:43:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPltR-00029w-PG for sip-web-archive@ietf.org; Thu, 04 Nov 2004 12:59:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPlRa-0005ga-C4; Thu, 04 Nov 2004 12:30:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPlHP-0002TX-OR; Thu, 04 Nov 2004 12:20:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13012; Thu, 4 Nov 2004 12:20:08 -0500 (EST) Received: from email10.etsi.org ([212.234.161.112] helo=email10.etsihq.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPlWy-0001XV-DN; Thu, 04 Nov 2004 12:36:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Nov 2004 18:19:29 +0100 Message-ID: <4091553999CBE4409CC2B562152B5A33049540CF@email10.etsihq.org> Thread-Topic: Invitation to register to the 2nd ENUM Workshop at ETSI on Tuesday 30 November 2004 Thread-Index: AcTCknCnHO/O5WtOQUKnp/rs/zBcCQ== From: =?iso-8859-1?Q?Patrick_Ren=E9_Guillemin?= To: "Plugtests" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, sip@ietf.org, plugtests-enum@list.etsi.org, TISPAN_WG4 Subject: [Sip] Invitation to register to the 2nd ENUM Workshop at ETSI on Tuesday 30 November 2004 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable Invitation to register to the 2nd ENUM Workshop at ETSI on Tuesday 30 = November 2004 Dear All, 2nd ENUM Technical Workshop Event description & information www.etsi.org/plugtests/ENUM.htm Agenda www.etsi.org/plugtests/Upcoming/ENUM/ENUMAgenda.htm Registration webapp.etsi.org/meetingcalendar/MeetingDetails.asp?mid=3D24578=20 Please forward in your preferred lists. Best Regards Patrick GUILLEMIN=20 ETSI - Plugtests Technical Coordinator=20 www.etsi.org/plugtests _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 4 19:08:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25796 for ; Thu, 4 Nov 2004 19:08:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPruK-0003UK-Ep for sip-web-archive@ietf.org; Thu, 04 Nov 2004 19:24:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPrc5-0005Qk-G8; Thu, 04 Nov 2004 19:05:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPraR-00052Q-EP for sip@megatron.ietf.org; Thu, 04 Nov 2004 19:04:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25525 for ; Thu, 4 Nov 2004 19:04:10 -0500 (EST) Received: from [69.55.225.91] (helo=www.implementers.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPrpq-0003P5-Li for sip@ietf.org; Thu, 04 Nov 2004 19:20:22 -0500 Received: by www.implementers.org (Postfix, from userid 1006) id 60F402FFA1A6; Thu, 4 Nov 2004 16:03:58 -0800 (PST) Received: from [10.1.28.2] (localhost [127.0.0.1]) by www.implementers.org (Postfix) with ESMTP id 2E54A2FFA0EA; Thu, 4 Nov 2004 16:03:53 -0800 (PST) Message-ID: <418AC382.1060407@acm.org> Date: Thu, 04 Nov 2004 16:04:18 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.3) Gecko/20041008 Debian/1.7.3-5 X-Accept-Language: en MIME-Version: 1.0 To: Gordon Ledgard Subject: Re: [Sip] reINVITE References: <8019F8581B5FC14DBD94BAF86844868E352DA3@viridis.IPeria.local> In-Reply-To: <8019F8581B5FC14DBD94BAF86844868E352DA3@viridis.IPeria.local> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on www.implementers.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: 7bit As the offer/answer cannot overlap, there is 4 different cases: 1. UAC UAS --INVITE offer-> <---200 answer-- --ACK----------> --INVITE-------> <----200 offer-- --ACK answer---> 2. UAC UAS --INVITE offer-> <---200 answer-- --ACK----------> --INVITE offer-> <---200 answer-- --ACK----------> 3. UAC UAS --INVITE-------> <----200 offer-- --ACK answer---> --INVITE-------> <----200 offer-- --ACK answer---> 4. UAC UAS --INVITE-------> <----200 offer-- --ACK answer---> --INVITE offer-> <---200 answer-- --ACK----------> The only problem here is the fourth case, because the INVITE offer can arrive before the previous answer. Gordon Ledgard wrote: > > Perhaps someone will chime in and correct me if I'm wrong. I believe > I ran into the same issue a while back, concluding that if another > INVITE were accepted before the ACK to the previous invite arrived > it could cause rather serious instability problems in session > negotiations, not to mention trying to align ACKS. > > The answer is that you should not accept a new INVITE until the previous > INVITE transaction is complete. Complete means the ACK was seen. No, the ACK for the 2xx is not part of the INVITE transaction. The transaction is complete as soon the 2xx is sent. See Figure 7 in RFC3261. > I > agree the spec is a bit vague there. > > Gordon R. Ledgard > IPeria, Inc. > > > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > Marc Petit-Huguenin > Sent: Thursday, November 04, 2004 8:04 AM > To: sip@ietf.org > Subject: [Sip] reINVITE > > > I already asked this in sip-implementors, but I didn't received any > conclusive answer. > > RFC3261 is not clear about when an UAS must be ready to receive a new > reINVITE in a dialog. > > My reading of the RFC is that the UAS must be ready to receive a new INVITE > in a dialog as soon a response was sent for the previous INVITE. More > precisely, that the UAS must not wait for the ACK before accepting the next > INVITE. Accepting in this case means that the INVITE is passed to the > application - the INVITE can be rejected by the application because of the > content of the SDP, but not because of a violation of the signalling protocol. > > My reasoning is based on the fact that RFC3261 section 14.1 says that "If > there is an outgoing INVITE client transaction, the TU must wait until the > transaction reaches the completed or terminated state before initiating the > new INVITE." As an INVITE transaction reaches the completed or terminated > state as soon a non-provisional response is received, the next INVITE can > be sent at the same time the ACK for the 200 response is sent. As the > packet ordering can change, the INVITE can arrive at the UAS before the > ACK. So this mean that the server should be prepared to receive the next > INVITE before receiving the ACK. > > Is it correct? > > Please note that my question is not about how SIP implementations work in > this case, but really on what was RFC3261's authors intent. > > Thank you. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 5 05:11:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24883 for ; Fri, 5 Nov 2004 05:11:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ1Jp-0006xr-I7 for sip-web-archive@ietf.org; Fri, 05 Nov 2004 05:27:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ0Ss-00061W-Vx; Fri, 05 Nov 2004 04:33:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ0Re-0005fG-QS for sip@megatron.ietf.org; Fri, 05 Nov 2004 04:31:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19896 for ; Fri, 5 Nov 2004 04:31:43 -0500 (EST) Received: from smtp8.clb.oleane.net ([213.56.31.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ0hJ-0005tD-PX for sip@ietf.org; Fri, 05 Nov 2004 04:47:59 -0500 Received: from Pavillonquatre (upperside.rain.fr [194.206.151.59] (may be forged)) by smtp8.clb.oleane.net with ESMTP id iA59VB6a023150 for ; Fri, 5 Nov 2004 10:31:11 +0100 Message-Id: <200411050931.iA59VB6a023150@smtp8.clb.oleane.net> From: "Gunther Palmer" To: Date: Fri, 5 Nov 2004 10:31:08 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTDGi5Ks3sFzQC9Rji/r1JISsibdg== X-Spam-Score: 0.1 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Subject: [Sip] WiMAX Summit: Call for proposals X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0836391773==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 This is a multi-part message in MIME format. --===============0836391773== Content-Type: multipart/alternative; boundary="----=_NextPart_000_010A_01C4C322.908116E0" This is a multi-part message in MIME format. ------=_NextPart_000_010A_01C4C322.908116E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit . What is the business model for WiMAX? . What do we learn from earlier deployments? . What about the future extensions of the standard? . How is addressed the interoperability challenge? These questions, among others, will be addressed during the second edition of the WiMAX Summit, next April 5-8 2005, by distinguished experts and key players in the field. The call for proposal dead line has been extended to November 30. Details at: http://www.upperside.fr/wimax05/wimax2005intro.htm ------=_NextPart_000_010A_01C4C322.908116E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

• = What is the business model for WiMAX?
• = What do we learn from earlier deployments?
• = What about the future extensions of the standard?
• = How is addressed the interoperability challenge?

These questions, among others, will be addressed during the second = edition of the WiMAX Summit, next April 5-8 2005, by distinguished = experts and key players in the field.

 

The call for proposal dead line has been = extended to November 30.

 

Details at:

http://www.upperside.fr/wimax05/wimax2005intro.htm

 

------=_NextPart_000_010A_01C4C322.908116E0-- --===============0836391773== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0836391773==-- From sip-bounces@ietf.org Fri Nov 5 05:33:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27794 for ; Fri, 5 Nov 2004 05:33:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ1fB-0007i4-5D for sip-web-archive@ietf.org; Fri, 05 Nov 2004 05:49:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ18v-0004SF-4U; Fri, 05 Nov 2004 05:16:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ0hm-0008Ar-0Q for sip@megatron.ietf.org; Fri, 05 Nov 2004 04:48:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21949 for ; Fri, 5 Nov 2004 04:48:23 -0500 (EST) Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ0xS-0006Ks-Re for sip@ietf.org; Fri, 05 Nov 2004 05:04:40 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0I6P006019SLE1@siemenscomms.co.uk> for sip@ietf.org; Fri, 05 Nov 2004 09:45:57 +0000 (GMT) Received: from ntht206e.siemenscomms.co.uk ([137.223.247.52]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0I6P006129SGAE@siemenscomms.co.uk>; Fri, 05 Nov 2004 09:45:52 +0000 (GMT) Received: by ntht206e.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Fri, 05 Nov 2004 09:47:41 +0000 Content-return: allowed Date: Fri, 05 Nov 2004 09:47:33 +0000 From: "Elwell, John" To: "'jon.peterson@neustar.biz'" Message-id: <50B1CBA96870A34799A506B2313F26670252D549@ntht201e> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.5 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: "'sip@ietf.org'" Subject: [Sip] Comments on draft-ietf-sip-identity-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2112201988==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============2112201988== Content-return: allowed Content-type: multipart/alternative; boundary="Boundary_(ID_nnmwBfbqrqstUEKCdWJGIw)" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_nnmwBfbqrqstUEKCdWJGIw) Content-type: text/plain Content-Transfer-Encoding: 7BIT Jon, A couple of comments: 1. The last requirement "It must be possible, in cases where a request has been retargeted to a different AoR than the one designated in the To header field, for the UAC to ascertain the AoR to which the request has been sent" seems to a remnant from the previous draft. I believe it relates to identity in responses. 2. It would be useful to include some statements about how the new mechanism might be used in situations where the UAS is a gateway to a legacy network. Here the gateway may provide an authentication service for numbers supplied by the legacy network, e.g., for +441159434989@gateway.example.com. Alternatively a proxy that has authenticated the gateway might provide an authentication service, e.g., for +441159434989@example.com. John (john.elwell@siemens.com) --Boundary_(ID_nnmwBfbqrqstUEKCdWJGIw) Content-type: text/html Content-Transfer-Encoding: 7BIT Comments on draft-ietf-sip-identity-03

Jon,

A couple of comments:

1. The last requirement "It must be possible, in cases where a request has been retargeted to a different AoR than the one designated in the To header field, for the UAC to ascertain the AoR to which the request has been sent" seems to a  remnant from the previous draft. I believe it relates to identity in responses.

2. It would be useful to include some statements about how the new mechanism might be used in situations where the UAS is a gateway to a legacy network. Here the gateway may provide an authentication service for numbers supplied by the legacy network, e.g.,

for +441159434989@gateway.example.com.
Alternatively a proxy that has authenticated the gateway might provide an authentication service, e.g., for +441159434989@example.com.

John (john.elwell@siemens.com)

--Boundary_(ID_nnmwBfbqrqstUEKCdWJGIw)-- --===============2112201988== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2112201988==-- From sip-bounces@ietf.org Fri Nov 5 14:49:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10670 for ; Fri, 5 Nov 2004 14:49:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQALH-0002UR-14 for sip-web-archive@ietf.org; Fri, 05 Nov 2004 15:05:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQA2Z-0000tC-L0; Fri, 05 Nov 2004 14:46:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ9wA-0008TM-BQ for sip@megatron.ietf.org; Fri, 05 Nov 2004 14:39:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10176 for ; Fri, 5 Nov 2004 14:39:52 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQABn-0002IZ-Et for sip@ietf.org; Fri, 05 Nov 2004 14:56:13 -0500 Received: from [63.110.3.31] ([63.110.3.31]) (authenticated bits=0) by nylon.softarmor.com (8.12.11/8.12.11) with ESMTP id iA5Je43v024746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 5 Nov 2004 13:40:04 -0600 Message-ID: <418BD6E7.9060503@softarmor.com> Date: Fri, 05 Nov 2004 13:39:19 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Sip] Minor mod in SIP agenda X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0173757337==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.0 (+) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa --===============0173757337== Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Please note that the it is important to consider the "other half" of connection reuse, and I've added the Jenning's outbound draft to the readling list.

This modified the following agenda item:

+15      Connection Reuse
            Rohan Mahy, Cullen Jennings
            draft-ietf-sip-connect-reuse-03.txt
            draft-jennings-sipping-outbound-00.txt


--
Dean Willis
SIP co-chair
--===============0173757337== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0173757337==-- From sip-bounces@ietf.org Fri Nov 5 15:10:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12498 for ; Fri, 5 Nov 2004 15:10:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQAfN-0002u6-4m for sip-web-archive@ietf.org; Fri, 05 Nov 2004 15:26:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQAEg-0003KM-Qq; Fri, 05 Nov 2004 14:59:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQA81-0001xY-Al for sip@megatron.ietf.org; Fri, 05 Nov 2004 14:52:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10851 for ; Fri, 5 Nov 2004 14:52:07 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQANn-0002XN-Bk for sip@ietf.org; Fri, 05 Nov 2004 15:08:28 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 05 Nov 2004 14:51:35 -0500 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iA5JpW9D022520; Fri, 5 Nov 2004 14:51:33 -0500 (EST) Received: from cisco.com ([161.44.79.125]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMV44972; Fri, 5 Nov 2004 14:51:31 -0500 (EST) Message-ID: <418BD9C3.2090904@cisco.com> Date: Fri, 05 Nov 2004 14:51:31 -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: "Orit Levin" , sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Subject: [Sip] draft-ietf-sip-refer-with-feature-param-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit This draft seem innocuous enough, but why do you feel that it is necessary? RFC3840 was itself a backward compatible extension, in that all the paramters it defines fit the generic-parameter syntax. So it seems to me that the desired usage is already present without this proposed extension. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 5 15:32:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14875 for ; Fri, 5 Nov 2004 15:32:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQB0q-0003LM-L0 for sip-web-archive@ietf.org; Fri, 05 Nov 2004 15:48:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQAcq-0004uP-07; Fri, 05 Nov 2004 15:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQAav-0003TF-1g for sip@megatron.ietf.org; Fri, 05 Nov 2004 15:22:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14138 for ; Fri, 5 Nov 2004 15:21:57 -0500 (EST) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQAqc-00039x-HZ for sip@ietf.org; Fri, 05 Nov 2004 15:38:18 -0500 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id iA5KKM10000775; Fri, 5 Nov 2004 20:20:23 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Fri, 5 Nov 2004 15:20:22 -0500 Message-ID: <7927C67249E4AD43BC05B539AF0D129801AF431E@stntexch04.cis.neustar.com> From: "Peterson, Jon" To: "'Paul Kyzivat'" Date: Fri, 5 Nov 2004 15:20:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: sip@ietf.org Subject: [Sip] RE: draft-ietf-sip-identity-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Looks like we're on the same page about most of these matters. A few more notes. > > Personally, I have yet to use SIP in any environment in which I have been > > forced to go through some proxy as a first hop, where first hop wouldn't > > reasonably be the party that should provide identity services for me. > > What about the IMS architecture, when you are connected to a visited > network? The P-CSCF may be able to authenticate you, but it won't be > able to sign your identity with credentials from your home domain. > Well, I can't say that I've used SIP in an IMS environment yet, but, your point is taken. I have a further action item, just as an aside, to describe interworking between RFC3325 (PAI) environments and sip-identity-0x environments, once we've agreed on exactly what sip-identity-0x entails. I think that in many such cases, there might be some sort of edge gateway that provides the Identity header on behalf of the whole transitively-trusting federation. While I would love to see sip-identity-0x implemented for IMS, as you point out the whole concept of 'roaming' is somewhat antithetical to the idea that a user agent associates with their own domain. The fact that some entity outside your local domain is authenticating you is the first warning sign, the presence of transitive trust is the second. Roaming is based on transitive trust. sip-identity-0x is not. Gatewaying may be the best we can do. > > If the challenge realm matches the domain of the UAC's AoR, > > and the cert acquired by TLS matches the challenge realm, then as far as the > > UAC is concerned, it should authenticate itself to the server (and this is > > all just standard RFC3261 behavior). > > Seems like the challenge realm is a red herring above. If the TLS cert > matches the domain of my AOR then I know I am one hop away from > something authoritative for my domain, regardless of the challenge. > Since there could be many proxies in my domain, the challenge could be > coming from a different one. In any case I have to forumulate the > request before being challenged. The realm is significant because it is possible that your request will be proxied to some other server that issues a challenge for a realm other than your local domain. The realm tells you, essentially, which credentials you need to provide. So, the fact that you received a 407 over a TLS connection doesn't necessarily mean that you are being challenged by your local domain. Further to this point, you local domain could institute a policy to inspect the realm of challenges resulting from proxied requests in order to guard from malicious domains down the pike fishing for passwords in your domain. > > So, ultimately it is up to the auth service itself > > whether or not it adds an Identity header. > > Yes, this certainly is a possibility. Maybe it would help to soften the > stance in the document, by inserting some words like those above. Maybe you're right; it could be worthwhile incorporating a little language along these lines to explain that given the need to rely on opportunistic UAC behavior, authentication services necessarily have a bit of leeway. It may help in some architectures, though I'm not sure it'll help a great deal in others. > > While the identity mechanism may > > not be applicable to all deployment possibilities, I think it is useful as > > it stands. > > Well, if the identity mechanism can become sufficiently compelling, then > it might rule out architectures that prevent its use. > Perhaps this is the real motivation. :-) > In the Machiavellian sense of pulling a fast one on the community, this isn't the motivation. But there is a deeper sense in which genuine security for SIP is possible in some deployment architectures and not possible in others. We would do ourselves a disservice, from a security perspective, by building an identity mechanism that is applicable to every imaginable deployment, since in many imaginable deployments, identity cannot be asserted securely. I'd rather have the identity assertion when it's possible, and know that the assertion is meaningful, than allow the assertion to appear in absolutely every case, but never really know whether or not it is actually meaningful. Jon Peterson NeuStar, Inc. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 5 15:42:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15632 for ; Fri, 5 Nov 2004 15:42:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQBAt-0003Zl-Ji for sip-web-archive@ietf.org; Fri, 05 Nov 2004 15:59:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQAtV-0005Ib-DA; Fri, 05 Nov 2004 15:41:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQApx-0003U8-6Y for sip@megatron.ietf.org; Fri, 05 Nov 2004 15:37:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15210 for ; Fri, 5 Nov 2004 15:37:31 -0500 (EST) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQB5k-0003Ro-1I for sip@ietf.org; Fri, 05 Nov 2004 15:53:53 -0500 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id iA5Kb110001516; Fri, 5 Nov 2004 20:37:01 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Fri, 5 Nov 2004 15:37:01 -0500 Message-ID: <7927C67249E4AD43BC05B539AF0D129801AF431F@stntexch04.cis.neustar.com> From: "Peterson, Jon" To: "'Elwell, John'" Date: Fri, 5 Nov 2004 15:37:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.8 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: "'sip@ietf.org'" Subject: [Sip] RE: Comments on draft-ietf-sip-identity-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Thanks for the read, John. Agreed that the last requirement is left over from previous versions and should be removed. In terms of your second point, I agree that would be useful. I was planning, providing that sip-identity-0x passes, on doing yet still more further work to show how it could be used in PSTN interworking in a separate draft. Some details of the SIP-ISUP mapping, no doubt, are impacted by this. The focus of that draft would be on preventing Caller-ID spoofing from SIP-originated calls (which is the SIP->PSTN case), though I agree there are probably a few things to say there about the PSTN->SIP case. So, I don't specifically think we need that to be in this draft, but I agree it needs to be done at some point. Jon Peterson NeuStar, Inc. -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens.com] Sent: Friday, November 05, 2004 1:48 AM To: 'jon.peterson@neustar.biz' Cc: 'sip@ietf.org' Subject: Comments on draft-ietf-sip-identity-03 Jon, A couple of comments: 1. The last requirement "It must be possible, in cases where a request has been retargeted to a different AoR than the one designated in the To header field, for the UAC to ascertain the AoR to which the request has been sent" seems to a remnant from the previous draft. I believe it relates to identity in responses. 2. It would be useful to include some statements about how the new mechanism might be used in situations where the UAS is a gateway to a legacy network. Here the gateway may provide an authentication service for numbers supplied by the legacy network, e.g., for +441159434989@gateway.example.com. Alternatively a proxy that has authenticated the gateway might provide an authentication service, e.g., for +441159434989@example.com. John (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 sip-bounces@ietf.org Sat Nov 6 00:37:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26982 for ; Sat, 6 Nov 2004 00:37:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQJGM-0006td-PE for sip-web-archive@ietf.org; Sat, 06 Nov 2004 00:37:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQJ7B-0003UB-46; Sat, 06 Nov 2004 00:27:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQJ6g-0003KB-6S for sip@megatron.ietf.org; Sat, 06 Nov 2004 00:27:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26396 for ; Sat, 6 Nov 2004 00:27:18 -0500 (EST) Received: from amer-mta02.csc.com ([20.137.2.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQJ6j-0006l6-RM for sip@ietf.org; Sat, 06 Nov 2004 00:27:26 -0500 Received: from amer-gw02.de-wil.csc.com (amer-gw02.csc.com [20.6.39.235]) by amer-mta02.csc.com (Switch-3.1.6/Switch-3.1.0) with ESMTP id iA65R4UP006458; Sat, 6 Nov 2004 00:27:14 -0500 (EST) To: sip@ietf.org, jmpolk@cisco.com X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Janet P Gunn Date: Sat, 6 Nov 2004 00:25:23 -0500 X-MIMETrack: Serialize by Router on AMER-GW02/SRV/CSC(Release 6.0.3|September 26, 2003) at 11/06/2004 12:27:53 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: fonashp@ncs.gov, Darren E Pado , Saud Negash , mosleyv@ncs.gov, Richard F Kaczmarek , nyquetek@msn.com, a.ephrath@ieee.org, suracif@ncs.gov, KENNETH.R.ERNEY@saic.com, Dennis Q Berg Subject: [Sip] Strict, Semi-Strict and Loose mode in RPH - not a good fit for ets and wps X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 One of the changes in the draft-ietf-sip-resource-priority-05 is the definition of 3 modes, strict, semi-strict, and loose, and the assignment of each defined namespaces to a particular mode. The definition of the mode involves several distinct behaviors 1 RPH is mandatory vs RPH is optional. (In strict mode, every relevant SIP message must have the RPH, with the specific namespace. In semi-strict and loose mode, some messages may have the RPH, with the specific namespace, and other messages may have no RPH.) 2 Behavior of a SIP element when it receives an RPH with a namespace it does not recognize. (In strict and semi-strict mode, the SIP element returns a 417 error message if it gets a SIP message with an RPH namespace it does recognize (or a namespace it does recognize, but an invalid value). In loose mode, the SIP element simply ignores namespaces it doesn't recognize - treats it as if the RPH were not present. (In loose mode, it will return an error message if it receives a known namespace with an unknown, or invalid, value)) 3 Content of the error message. (In strict mode, if the error message contains the "Accept Resource Priority" Header (which indicates the namespaces and values that WOULD be accepted) that information is stripped off before it reaches the final user. In semi-strict mode and loose mode, it appears that the information is not stripped off.) 4 .Inclusion of authorization header (or equivalent functionality from Trait-Based Authorization). (In semi-strict mode, SIP messages that include the RPH must also include the authorization header. In strict and loose mode, there is no mention of the authorization header) 5 Preemption vs precedence (i.e., queueing) behavior (At an IP/PSTN gateway, with all PSTN -side circuits in use, in strict mode one of the lower priority circuits would be freed using pre-emption. In semi strict mode, the SIP request may be granted access to the next available circuit based on the header's presence, regardless of how many other "regular" requests are received at the gateway. The pre-emption vs. precedence behavior in loose mode is not described.) 6 Use of the "Require" header field ( in strict and semi-strict modes, a SIP message with the RPH also has the "Require" header with the "Resource-Priority" option tag. Loose mode does no include the Require header) Of the namespaces described in the document, dsn, drsn and q735 (all variants of "MLPP") are defined as "strict". ets and wps are defined as "semi-strict". None are defined as loose. Unfortunately, this (semi-strict) is NOT the behavior desired for the ets and wps namespaces. The behavior desired for the ets and wps namespaces are 1 RPH is optional (semi-strict and loose) 2 SIP element ignores a namespace it does not recognize (loose) 3 The content of the error message should not reveal (to the end user) the valid values for that namespace (strict) 4 SIP messages that include the RPH with the ets or wps namespaces should include the authorization header (or equivalent mechanism) (semi-strict) 5 Precedence (queueing) is generally the means of providing priority, but exemption from network management controls, for instance call admission within an IP domain, when a "regular" call would not be admitted, is also needed. Pre-emption is not used. (semi-strict "plus more") 6 There is no a priori requirement to use, or not use, the "Require" header field. So the desired behavior is a combination of what is defined for strict, semi-strict, and loose modes. It would be much better if one of the modes described the desired behavior for the ets and wps namespaces. Thanks, 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. ---------------------------------------------------------------------------------------- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Nov 6 00:58:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27986 for ; Sat, 6 Nov 2004 00:58:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQJbA-0007EG-Hz for sip-web-archive@ietf.org; Sat, 06 Nov 2004 00:58:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQJWH-0007FU-Mm; Sat, 06 Nov 2004 00:53:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQJPb-0006KO-Ln for sip@megatron.ietf.org; Sat, 06 Nov 2004 00:46:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27580 for ; Sat, 6 Nov 2004 00:46:52 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQJPf-00074C-Gg for sip@ietf.org; Sat, 06 Nov 2004 00:46:59 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 05 Nov 2004 21:57:22 -0800 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.10/8.12.6) with ESMTP id iA65jVnC014373 for ; Fri, 5 Nov 2004 21:45:31 -0800 (PST) Received: from [10.0.1.3] (sjc-vpn1-488.cisco.com [10.21.97.232]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id ATU14328; Fri, 5 Nov 2004 21:46:20 -0800 (PST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 05 Nov 2004 19:20:02 -0800 From: Cullen Jennings To: "sip@ietf.org" Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Subject: [Sip] mib-08 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit I tired to read this whole thing again and it made my head want to explode - I think getting a bunch of people to read it again would be really good. There has been some nice work done on it since the previous rev. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Nov 6 01:00:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28255 for ; Sat, 6 Nov 2004 01:00:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQJdB-0007J8-L7 for sip-web-archive@ietf.org; Sat, 06 Nov 2004 01:00:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQJWJ-0007H8-6b; Sat, 06 Nov 2004 00:53:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQJPd-0006KP-D7 for sip@megatron.ietf.org; Sat, 06 Nov 2004 00:46:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27583 for ; Sat, 6 Nov 2004 00:46:53 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQJPg-00074C-27 for sip@ietf.org; Sat, 06 Nov 2004 00:47:01 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 05 Nov 2004 21:57:23 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iA65kMcp028828; Fri, 5 Nov 2004 21:46:23 -0800 (PST) Received: from [10.0.1.3] (sjc-vpn1-488.cisco.com [10.21.97.232]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id ATU14326; Fri, 5 Nov 2004 21:46:19 -0800 (PST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 05 Nov 2004 19:06:53 -0800 From: Cullen Jennings To: "sip@ietf.org" Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: Orit Levin Subject: [Sip] refer-with-norefersub X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit I think I understand that often the subscriptions is of no use and what you want to do here. It seems like putting a tag in the uri of the refer like ";norefersub" could be used as a hint not to create the implicit subscription. It does not seem like the Supported Require stuff is needed. Would this work and do what you want? Cullen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Nov 6 01:03:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28466 for ; Sat, 6 Nov 2004 01:03:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQJfX-0007OW-9T for sip-web-archive@ietf.org; Sat, 06 Nov 2004 01:03:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQJWK-0007Hv-Bt; Sat, 06 Nov 2004 00:53:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQJPd-0006KQ-Fi for sip@megatron.ietf.org; Sat, 06 Nov 2004 00:46:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27588 for ; Sat, 6 Nov 2004 00:46:54 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQJPh-00074C-IJ for sip@ietf.org; Sat, 06 Nov 2004 00:47:01 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 05 Nov 2004 21:57:24 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iA65kMcr028828; Fri, 5 Nov 2004 21:46:24 -0800 (PST) Received: from [10.0.1.3] (sjc-vpn1-488.cisco.com [10.21.97.232]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id ATU14327; Fri, 5 Nov 2004 21:46:20 -0800 (PST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 05 Nov 2004 19:09:33 -0800 From: Cullen Jennings To: "sip@ietf.org" Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Cc: Orit Levin Subject: [Sip] refer-with-feature-param X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit I'm vague on all this stuff but ... Do you need anything normative for this at all - seems like this is already supported and perhaps we just need some example call flows demonstrating it. Cullen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Nov 6 01:07:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28834 for ; Sat, 6 Nov 2004 01:07:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQJjG-0007WF-BY for sip-web-archive@ietf.org; Sat, 06 Nov 2004 01:07:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQJWM-0007I8-4n; Sat, 06 Nov 2004 00:53:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQJPe-0006KW-EY for sip@megatron.ietf.org; Sat, 06 Nov 2004 00:46:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27594 for ; Sat, 6 Nov 2004 00:46:55 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQJPi-00074D-Eq for sip@ietf.org; Sat, 06 Nov 2004 00:47:02 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 05 Nov 2004 21:57:27 -0800 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.10/8.12.6) with ESMTP id iA65jXnG014379; Fri, 5 Nov 2004 21:45:36 -0800 (PST) Received: from [10.0.1.3] (sjc-vpn1-488.cisco.com [10.21.97.232]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id ATU14334; Fri, 5 Nov 2004 21:46:23 -0800 (PST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 05 Nov 2004 21:21:50 -0800 Subject: Re: [Sip] RE: draft-ietf-sip-identity-03 From: Cullen Jennings To: Jon Peterson , Paul H Kyzivat Message-ID: In-Reply-To: <7927C67249E4AD43BC05B539AF0D129801AF431E@stntexch04.cis.neustar.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit On 11/5/04 12:20 PM, "Peterson, Jon" wrote: >>> Personally, I have yet to use SIP in any environment in which I have > been >>> forced to go through some proxy as a first hop, where first hop wouldn't >>> reasonably be the party that should provide identity services for me. >> >> What about the IMS architecture, when you are connected to a visited >> network? The P-CSCF may be able to authenticate you, but it won't be >> able to sign your identity with credentials from your home domain. >> Thought I mostly agree, it might be possible that the roaming operator does have the private key from the home operator. Once you have theses operators that trust each other and delegate certain operations back and forth, something like this might work. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Nov 6 09:32:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10718 for ; Sat, 6 Nov 2004 09:32:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQRcb-0007xJ-QN for sip-web-archive@ietf.org; Sat, 06 Nov 2004 09:32:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQRZ6-00013H-GF; Sat, 06 Nov 2004 09:29:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQRYE-0000wn-I5 for sip@megatron.ietf.org; Sat, 06 Nov 2004 09:28:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10518 for ; Sat, 6 Nov 2004 09:28:20 -0500 (EST) Message-Id: <200411061428.JAA10518@ietf.org> Received: from phobos.simply.net ([81.3.64.11]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CQRYD-0007s7-5p for sip@ietf.org; Sat, 06 Nov 2004 09:28:31 -0500 Received: (qmail 22271 invoked from network); 6 Nov 2004 14:27:39 -0000 Received: from pcp08649708pcs.towson01.md.comcast.net (HELO albers) (69.137.47.20) by phobos.simply.net with SMTP; 6 Nov 2004 14:27:39 -0000 From: "Ken Carlberg" To: "'Janet P Gunn'" , , Subject: RE: [Sip] Strict, Semi-Strict and Loose mode in RPH - not a good fit for ets and wps Date: Sat, 6 Nov 2004 09:26:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: Thread-Index: AcTDwun9b+wqJHkwSYi9rqPrQwEdzgARdt0w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: fonashp@ncs.gov, "'Richard F Kaczmarek'" , "'Darren E Pado'" , "'Saud Negash'" , mosleyv@ncs.gov, a.ephrath@ieee.org, "'Dennis Q Berg'" , nyquetek@msn.com, suracif@ncs.gov, KENNETH.R.ERNEY@saic.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit > Unfortunately, this (semi-strict) is NOT the behavior desired for the ets > and wps namespaces. > > The behavior desired for the ets and wps namespaces are > 1 RPH is optional (semi-strict and loose) > 2 SIP element ignores a namespace it does not recognize (loose) I would prefer a strict or semi-strict mode because these provide feedback in case: a) a misconfigured UA sends the wrong namespace.priority, and/or b) initial selection of a server/proxy that does not support the desired namespace. The former is quite possible given an ability (and possibly, necessity) of the user to configure their own device to support the given namespace.value combination. > 3 The content of the error message should not reveal (to the end user) the > valid values for that namespace (strict) section 4.5 of the drafts states: If the UAS understands the resource value, but refuses to honor the request with elevated priority for this particular user, it returns the 403 (Forbidden) response code. It MAY include the list of resource values that the user is allowed to use in the 'Accept-Resource-Priority' response header field. The "MAY" is the critical term. My understanding would be that this decision is a local policy issue. Outside of that I personally don't see a problem with providing "hints" of accepted values under the context that they can only acted upon by authorized users. Informing the user of the acceptable set of priorities does not bypass or circumvent the need for proper authentication credentials. > 4 SIP messages that include the RPH with the ets or wps namespaces should > include the authorization header (or equivalent mechanism) (semi-strict) > 5 Precedence (queueing) is generally the means of providing priority, but > exemption from network management controls, for instance call admission > within an IP domain, when a "regular" call would not be admitted, is also > needed. Pre-emption is not used. (semi-strict "plus more") the "plus more" would seem to be a product of local policy > 6 There is no a priori requirement to use, or not use, the "Require" > header field. isn't this addressed in section 4.3.2 below? or am I missing something? If the request includes a 'Require' header field with the 'Resource-Priority' option tag, a UAS MUST follow the strict or semi-strict mode rules, otherwise UAS and proxies MUST operate in loose mode. -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 sip-bounces@ietf.org Sat Nov 6 14:34:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29743 for ; Sat, 6 Nov 2004 14:34:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQWKU-0004ug-Jf for sip-web-archive@ietf.org; Sat, 06 Nov 2004 14:34:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQWJF-0008QQ-PP; Sat, 06 Nov 2004 14:33:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQWEd-0007x4-Qz for sip@megatron.ietf.org; Sat, 06 Nov 2004 14:28:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29484 for ; Sat, 6 Nov 2004 14:28:26 -0500 (EST) From: Mpierce1@aol.com Received: from imo-m20.mx.aol.com ([64.12.137.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQWEp-0004of-9a for sip@ietf.org; Sat, 06 Nov 2004 14:28:39 -0500 Received: from Mpierce1@aol.com by imo-m20.mx.aol.com (mail_out_v37_r3.8.) id t.1db.2e5d585a (24895); Sat, 6 Nov 2004 14:27:53 -0500 (EST) Message-ID: <1db.2e5d585a.2ebe7fb8@aol.com> Date: Sat, 6 Nov 2004 14:27:52 EST Subject: Re: [Sip] Strict, Semi-Strict and Loose mode in RPH - not a good fit for ets ... To: jgunn6@csc.com, sip@ietf.org, jmpolk@cisco.com, carlberg@g11.org.uk MIME-Version: 1.0 X-Mailer: 6.0 for Windows XP sub 10500 X-Spam-Score: 0.3 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1397318568==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 --===============1397318568== Content-Type: multipart/alternative; boundary="part1_1db.2e5d585a.2ebe7fb8_boundary" --part1_1db.2e5d585a.2ebe7fb8_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 11/6/2004 12:38:18 AM Eastern Standard Time, jgunn6@csc.com writes: > Of the namespaces described in the document, dsn, drsn and q735 (all > variants of "MLPP") are defined as "strict". ets and wps are defined as > "semi-strict". None are defined as loose. > > Unfortunately, this (semi-strict) is NOT the behavior desired for the ets > and wps namespaces. > > Likewise, "strict" is not the behavior desired for dsn, drsn, or q735. "Strict" says that it requires the RP header in a bunch of messages. Since these three namespaces are based on Q.735 (MLPP), it is expected that the procedures should be based on that standard. Therefore, the RP header only goes in the INVITE. The procedures do not require it in any other messages. Further, DSN may choose to allow the absence of any RP header to mean to use the lowest (Routine), thus the purpose for specifying a "default level to be assumed in the absence of the priority value" as version -01 of this draft stated. I don't remember any discussion/agreement to remove this statement about "default", but maybe there was. The description of "Loose" mode in 4.3.5 still seems to require that there be a known default. This draft is going way beyond what is required to define a simple header to carry a simple piece of information. Where was the discussion on the list or elsewhere about adding the third mode? In the previous draft, as agreed in previous discussions, "strict" vs. "loose" modes only pertained to specifying "handling requests with unknown namespaces or priority values". This latest version greatly expands the meaning and use of this "mode" to specify other aspects of operation, such as relating "strict" mode with the use of preemption (section 4.5.1). The previous drafts stayed away from specifying the operation for specific cases, since this should be the subject of other documents. In 4.3.4 for Semi-Strict Mode, whether or not the messages "must" contain an authorization header or [something unknown from the Trait-based Authorization effort] depends on the security architecture of the network in which this is being used. There may be networks that use a different approach. It is inappropriate for this RP draft to require specific authorization methods. In any case, this reference to "trait-based authorization" is normative, not informative. The basic definitions of "strict" and "loose" modes in version -04 should be retained, not all this new material in -05. In fact, all of -04 should be accepted as the basis for further discussions, not -05. Mike Pierce --part1_1db.2e5d585a.2ebe7fb8_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message=20= dated 11/6/2004 12:38:18 AM Eastern Standard Time, jgunn6@csc.com writes:


Of the namespaces described= in the document, dsn, drsn and q735 (all
variants of "MLPP") are defined as "strict".  ets and wps are defin= ed as
"semi-strict".  None are defined as loose.

Unfortunately, this  (semi-strict) is NOT the behavior desired for=20= the ets
and wps namespaces.



Likewise, "strict" is not the behavior desired for dsn, drsn, or q735. "= Strict" says that it requires the RP header in a bunch of messages. Since th= ese three namespaces are based on Q.735 (MLPP), it is expected that the proc= edures should be based on that standard. Therefore, the RP header only goes=20= in the INVITE. The procedures do not require it in any other messages.

Further, DSN may choose to allow the absence of any RP header to mean to= use the lowest (Routine), thus the purpose for specifying a "default level=20= to be assumed in the absence of the priority value" as version -01 of this d= raft stated. I don't remember any discussion/agreement to remove this statem= ent about "default", but maybe there was. The description of "Loose" mode in= 4.3.5 still seems to require that there be a known default.

This draft is going way beyond what is required to define a simple heade= r to carry a simple piece of information.

Where was the discussion on the list or elsewhere about adding the third= mode? In the previous draft, as agreed in previous discussions, "strict" vs= . "loose" modes only pertained to specifying "handling requests with unknown= namespaces or priority values". This latest version greatly expands the mea= ning and use of this "mode" to specify other aspects of operation, such as r= elating "strict" mode with the use of preemption (section 4.5.1). The previo= us drafts stayed away from specifying the operation for specific cases, sinc= e this should be the subject of other documents.

In 4.3.4 for Semi-Strict Mode, whether or not the messages "must" contai= n an authorization header or [something unknown from the Trait-based Authori= zation effort] depends on the security architecture of the network in which=20= this is being used. There may be networks that use a different approach. It=20= is inappropriate for this RP draft to require specific authorization methods= . In any case, this reference to "trait-based authorization" is normative, n= ot informative.

The basic definitions of "strict" and "loose" modes in version -04 shoul= d be retained, not all this new material in -05. In fact, all of -04 should=20= be accepted as the basis for further discussions, not -05.

Mike Pierce
--part1_1db.2e5d585a.2ebe7fb8_boundary-- --===============1397318568== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1397318568==-- From sip-bounces@ietf.org Sat Nov 6 17:28:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11201 for ; Sat, 6 Nov 2004 17:28:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQZ3O-0008BR-NC for sip-web-archive@ietf.org; Sat, 06 Nov 2004 17:29:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQZ1q-0008F2-RS; Sat, 06 Nov 2004 17:27:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQYyB-0007BB-17 for sip@megatron.ietf.org; Sat, 06 Nov 2004 17:23:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10541 for ; Sat, 6 Nov 2004 17:23:36 -0500 (EST) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQYyM-0007xf-V8 for sip@ietf.org; Sat, 06 Nov 2004 17:23:52 -0500 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iA6MN0S00705; Sat, 6 Nov 2004 17:23:00 -0500 (EST) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sat, 6 Nov 2004 17:23:00 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCFF099B5@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "'Cullen Jennings'" , "'sip@ietf.org'" Subject: RE: [Sip] refer-with-feature-param Date: Sat, 6 Nov 2004 17:22:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.5 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: "'Orit Levin'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1871162487==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1871162487== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C44F.238E1815" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4C44F.238E1815 Content-Type: text/plain Do we need to distinguish the generic-param from the feature-param? Seems to me that the feature-param is IANA defined (we probably need to mention it in the IANA section), but the generic-param is not. So, for example, you can't really know if Refer-To: bof@example.com;audio is implying the IANA-registered audio as per 3840/this draft or anybody elses generic parameter which could mean something different. I'm not sure if it is an issue of not. (I guess it depends if we expect that the recipient of the REFER is supposed to look at the parameter or not.) If so, it might be better to have an explicit indication like ;feature-param=audio or something like that. If not, then I don't understand why we need to alter the ABNF, because feature-param is a generic-param in the first place. > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Cullen Jennings > Sent: Friday, November 05, 2004 19:10 > To: sip@ietf.org > Cc: Orit Levin > Subject: [Sip] refer-with-feature-param > > > > I'm vague on all this stuff but ... Do you need anything > normative for this at all - seems like this is already > supported and perhaps we just need some example call flows > demonstrating it. > > 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 > > ------_=_NextPart_001_01C4C44F.238E1815 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sip] refer-with-feature-param

Do we need to distinguish the generic-param from the = feature-param?

Seems to me that the feature-param is IANA defined = (we probably need
to mention it in the IANA section), but the = generic-param is not.

So, for example, you can't really know if Refer-To: = bof@example.com;audio
is implying the IANA-registered audio as per = 3840/this draft or
anybody elses generic parameter which could mean = something different.

I'm not sure if it is an issue of not. (I guess it = depends if we expect that
the recipient of the REFER is supposed to look at = the parameter or not.)

If so, it might be better to have an explicit = indication like ;feature-param=3Daudio or
something like that.

If not, then I don't understand why we need to alter = the ABNF, because feature-param is
a generic-param in the first place.

> -----Original Message-----
> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] = On
> Behalf Of Cullen Jennings
> Sent: Friday, November 05, 2004 19:10
> To: sip@ietf.org
> Cc: Orit Levin
> Subject: [Sip] refer-with-feature-param
>
>
>
> I'm vague on all this stuff but ... Do you need = anything
> normative for this at all - seems like this is = already
> supported and perhaps we just need some example = call flows
> demonstrating it.
>
> 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
>
>

------_=_NextPart_001_01C4C44F.238E1815-- --===============1871162487== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1871162487==-- From sip-bounces@ietf.org Sat Nov 6 19:18:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19103 for ; Sat, 6 Nov 2004 19:18:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQalh-0001tg-1g for sip-web-archive@ietf.org; Sat, 06 Nov 2004 19:18:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQajg-0000Jx-2u; Sat, 06 Nov 2004 19:16:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQagJ-0008Dd-HJ for sip@megatron.ietf.org; Sat, 06 Nov 2004 19:13:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18772 for ; Sat, 6 Nov 2004 19:13:15 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQagW-0001nh-E1 for sip@ietf.org; Sat, 06 Nov 2004 19:13:33 -0500 Received: from [206.176.144.210] (206-176-144-210.waymark.net [206.176.144.210] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.12.11/8.12.11) with ESMTP id iA70DSgT003472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Nov 2004 18:13:31 -0600 Message-ID: <418D7685.9000101@softarmor.com> Date: Sat, 06 Nov 2004 19:12:37 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Janet P Gunn Subject: Re: [Sip] Strict, Semi-Strict and Loose mode in RPH - not a good fit for ets and wps References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: fonashp@ncs.gov, Darren E Pado , mosleyv@ncs.gov, Saud Negash , a.ephrath@ieee.org, sip@ietf.org, nyquetek@msn.com, Richard F Kaczmarek , jmpolk@cisco.com, KENNETH.R.ERNEY@saic.com, suracif@ncs.gov, Dennis Q Berg X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Janet P Gunn wrote: > > > > One of the changes in the draft-ietf-sip-resource-priority-05 is the > definition of 3 modes, strict, semi-strict, and loose, and the assignment > of each defined namespaces to a particular mode. > > The definition of the mode involves several distinct behaviors > Would it be better to have each namespace definition fully define the behavior of that namesapce, rather than trying to have some "templates" that could be re-used by multiple namespaces? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Nov 6 19:33:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20319 for ; Sat, 6 Nov 2004 19:33:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQaze-0002B0-89 for sip-web-archive@ietf.org; Sat, 06 Nov 2004 19:33:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQatQ-0001aT-BX; Sat, 06 Nov 2004 19:26:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQak3-0000Kv-E2 for sip@megatron.ietf.org; Sat, 06 Nov 2004 19:17:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19007 for ; Sat, 6 Nov 2004 19:17:07 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQakH-0001sF-5l for sip@ietf.org; Sat, 06 Nov 2004 19:17:25 -0500 Received: from [206.176.144.210] (206-176-144-210.waymark.net [206.176.144.210] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.12.11/8.12.11) with ESMTP id iA70HUeJ003492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Nov 2004 18:17:30 -0600 Message-ID: <418D7776.9010907@softarmor.com> Date: Sat, 06 Nov 2004 19:16:38 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: Rohan Mahy , Gonzalo Camarillo Subject: [Sip] WGLC for Application Interaction X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit The WGLC that Gonzalo announced for this draft in SIPPING will run concurrently in SIP. Thanks, y'all. -- Dean Willis SIP cochair -------- Original Message -------- Subject: [Sipping] WGLC: Application Interaction Date: Wed, 03 Nov 2004 09:50:14 +0200 From: Gonzalo Camarillo To: sipping CC: Rohan Mahy , Dean Willis Folks, we would like to working group last call the following draft: http://www.ietf.org/internet-drafts/draft-ietf-sipping-app-interaction-framework-03.txt This WGLC will finish on December 3rd. Please, send you comments to the authors and to the list. As a suggestion, you may want to review this document and KPML, which is also under WGLC, together. Thanks, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Nov 6 20:21:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23373 for ; Sat, 6 Nov 2004 20:21:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQbl0-00037H-DH for sip-web-archive@ietf.org; Sat, 06 Nov 2004 20:22:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQbcI-0000qO-Sr; Sat, 06 Nov 2004 20:13:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQbXT-00070H-27 for sip@megatron.ietf.org; Sat, 06 Nov 2004 20:08:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22644 for ; Sat, 6 Nov 2004 20:08:13 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQbXh-0002r8-AH for sip@ietf.org; Sat, 06 Nov 2004 20:08:29 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 06 Nov 2004 17:21:00 -0800 X-BrightmailFiltered: true 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.10/8.12.6) with ESMTP id iA717ZnC018888; Sat, 6 Nov 2004 17:07:36 -0800 (PST) Received: from [10.0.1.3] (sjc-vpn4-496.cisco.com [10.21.81.240]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id ATU31347; Sat, 6 Nov 2004 17:07:36 -0800 (PST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sat, 06 Nov 2004 14:37:18 -0800 Subject: Re: [Sip] Re: GRUU and things that rewrite contacts From: Cullen Jennings To: Jonathan Rosenberg , Jon Peterson Message-ID: In-Reply-To: <414FD4B1.2040802@dynamicsoft.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" , Robert Sparks , Paul H Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: 7bit I was playing with a SBC from one of my favorite SBC vendors and don't see why GRUU will cause lots problems. They do muck with contact but they do it in a stateless and can pass instance and grid parameters right thought. They know how to map changes done in outgoing contact and apply them to an incoming request URI. Yes, SBC will need to be GRU aware, or already be transparent to this type of thing, but I guess I'm not seeing the issue. On 9/21/04 12:13 AM, "Jonathan Rosenberg" wrote: > Jon, > > I agree with you and Paul that we cannot, and should not, try here or > anywhere else to define an SBC and consider its impacts. I think we can > and should discuss the impact of contact-rewriting elements, and point > out, as you say, that the identity draft would detect such a case. > > From a practical matter, I will say that the fact that SBCs will likely > not work with GRUU is a real concern. It is going to make it hard to > deploy gruu, and generally I am a really big fan of easy-to-deploy > solutions. For better or worse, there ARE SBCs deployed in many existing > SIP networks, and in those networks, getting gruu deployed will be > harder. It will require coordination now between not just the client > vendor and SIP server vendor, but now also the SBC vendor. In my > experience, the more parts of the machine that all need to be > simultaneously upgraded for a new feature, the less likely, > exponentially I think, it is that such an upgrade will occur. If you > couple this with the fact that, while gruu is definitely a key part of > our specs, its an infrastructure improvement with no new features per > se, it becomes a hard sell. > > I still believe that the only alternative on the table - using a new > header field for conveying gruu in register and invite/200 - has an even > worse deployment path. > > So, absent a better suggestion, and I don't have one, I think our only > choice is to document the problems per above. > > -Jonathan R. > > > > Peterson, Jon wrote: > >> I agree with Paul that SBC behavior is probably defined too poorly to refer >> to it directly in the GRUU draft, and personally I'm very skeptical of >> taking on that definition as a deliverable for GRUU. At the risk of >> complicating a discussion about non-standard entities with standards: >> >> RFC3261, Table 2: >> >> Header field where proxy ACK BYE CAN INV OPT REG >> ___________________________________________________________ >> Contact R o - - m o o >> >> >> I don't see an "m" under "proxy" there... but of course we're not talking >> about proxy servers as such. That much said, if Contacts were something that >> an entity other than a user agent could safely set, there would be an "m" in >> the table up there. If an intermediary wants to request that it be in the >> path of further SIP transactions in a dialog in a safe way, well, there's >> another header for that. Furthermore, the GRUU acquisition mechanism >> inherently provides a way for intermediaries to give a Contact header to a >> user agent in order to strongly bind request routing to an intermediary. So, >> there are reasonable alternatives to rewriting the header in transit. >> >> Furthmore, I would like to point out that sip-identity provides integrity >> over the addr-spec of the Contact header field. If the Contact header field >> has been modified by an intermediary after integrity has been applied, it >> should be considered an integrity violation by the recipient. >> >> This is of course not to say that there are no architectures where SBCs and >> sip-identity might live together in harmony. The point is that SIP can't be >> expected to differentiate between friendly and unfriendly intermediaries >> that break the rules, and that we certainly can't enable arbitary entities >> to modify the Contact header or we open ourselves up to all sorts of nasty >> attacks. Whatever security gains people think they are getting from >> rewriting the Contact header at an intermediary, I'm sure they pale in >> comparison to the threats that the arise if Contact header can be arbitarily >> changed by anyone. If we want to prevent something from rewriting a header >> that shouldn't be rewritten, we should use some form of integrity to prevent >> that. >> >> So, I do think it is reasonable for the GRUU doc to discuss the impact of an >> intermediary rewriting the Contact header in general (without defining >> SBCs), and point out that integrity mechanisms like sip-identity could be >> used to detect a rewrite of a Contact header. But, on some level, I guess I >> feel rewriting Contacts at an intermediary is already acknowledged to be >> problematic by the core SIP standard. It'd also be a problem for GRUU if an >> SBC removed the Call-ID header field, or did any of a number of things it >> shouldn't do. >> >> Jon Peterson >> NeuStar, Inc. >> >> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> Sent: Thursday, September 16, 2004 4:32 PM >>> To: Jonathan Rosenberg >>> Cc: sip@ietf.org; Robert Sparks >>> Subject: Re: [Sip] Re: GRUU and things that rewrite contacts >>> >> >> [snip] >> >>> I don't want to comment on the above right now because we are clearly >>> have different assumptions here. >>> >>> I don't think we can meaningfully comment on the impact on SBCs when we >>> have no definition of such a beast. And trying to generalize to all >>> forms of B2BUA makes things worse - we repeatedly state that about all >>> you can say in general about a B2BUA is that it is two connected UAs - >>> you can't say anything about how the two calls are related. >>> >>> If this is an important problem for us to mention at all, (and I'm not >>> yet convinced it is), then I think the first step is to define an SBC, >>> along with the kinds of transformations it performs. Since that has >>> never been written down, when it is written it can deal >>> properly with GRUUs. >>> >>> Paul >>> >> >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Nov 6 23:19:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03201 for ; Sat, 6 Nov 2004 23:19:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQeX6-0006EQ-UR for sip-web-archive@ietf.org; Sat, 06 Nov 2004 23:20:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQeUH-0002JV-0n; Sat, 06 Nov 2004 23:17:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQeSo-00021g-Dz for sip@megatron.ietf.org; Sat, 06 Nov 2004 23:15:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02857 for ; Sat, 6 Nov 2004 23:15:34 -0500 (EST) Received: from marlborough.concentric.net ([207.155.248.14] helo=marlborough.cnchost.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQeT3-00069V-Jv for sip@ietf.org; Sat, 06 Nov 2004 23:15:54 -0500 Received: from MedhaviLT (pool-138-88-43-135.res.east.verizon.net [138.88.43.135]) by marlborough.cnchost.com id XAA13226; Sat, 6 Nov 2004 23:15:18 -0500 (EST) [ConcentricHost SMTP Relay 1.17] Message-ID: <200411070415.XAA13226@marlborough.cnchost.com> From: "Medhavi Bhatia" To: "'Paul Kyzivat'" , "'Jonathan Rosenberg'" Subject: RE: [Sip] Re: GRUU and things that rewrite contacts Date: Sat, 6 Nov 2004 23:15:22 -0500 Organization: NexTone Communications MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcSf4NDumA853CZmQ3G9PzmIK03bMwkndhJA In-Reply-To: <415028C7.6010207@cisco.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, "'Robert Sparks'" , "'Peterson, Jon'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mbhatia@nextone.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Content-Transfer-Encoding: 7bit I may have caught up to this discussion too late, but here are some thoughts. I probably need to dig deeper into the GRUU draft too. There seem to be two cases. 1) SBC sits between the UA and the proxy/registrar, where the UA sends requests for the proxy addressed to the SBC. In this case, I don't see much of a concern as contact parameters are not overwritten for REGISTER. For the INVITE, since the SBC knows that the Contact is a GRUU, it is not overwritten. The last part needs SBCs to understand the GRUUs. 2) The same as above, except the UA does not know who the Registrar is. This is a tricky application and I guess not part of the usual suspects. In this case, the SBC will need to be aware of GRUUs on the REGISTER also. The SBC also may have an option to create a GRUU and map one obtained from the Registrar to this one. -Medhavi. > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Tuesday, September 21, 2004 9:13 AM > To: Jonathan Rosenberg > Cc: sip@ietf.org; Robert Sparks; Peterson, Jon > Subject: Re: [Sip] Re: GRUU and things that rewrite contacts > > This would be a good time for those that build SBCs to take note and > action, and to speak up if they have difficulty with the deployment of > GRUUs. > > Paul > > Jonathan Rosenberg wrote: > > Jon, > > > > I agree with you and Paul that we cannot, and should not, try here or > > anywhere else to define an SBC and consider its impacts. I think we can > > and should discuss the impact of contact-rewriting elements, and point > > out, as you say, that the identity draft would detect such a case. > > > > From a practical matter, I will say that the fact that SBCs will likely > > not work with GRUU is a real concern. It is going to make it hard to > > deploy gruu, and generally I am a really big fan of easy-to-deploy > > solutions. For better or worse, there ARE SBCs deployed in many existing > > SIP networks, and in those networks, getting gruu deployed will be > > harder. It will require coordination now between not just the client > > vendor and SIP server vendor, but now also the SBC vendor. In my > > experience, the more parts of the machine that all need to be > > simultaneously upgraded for a new feature, the less likely, > > exponentially I think, it is that such an upgrade will occur. If you > > couple this with the fact that, while gruu is definitely a key part of > > our specs, its an infrastructure improvement with no new features per > > se, it becomes a hard sell. > > > > I still believe that the only alternative on the table - using a new > > header field for conveying gruu in register and invite/200 - has an even > > worse deployment path. > > > > So, absent a better suggestion, and I don't have one, I think our only > > choice is to document the problems per above. > > > > -Jonathan R. > > > > > > > > Peterson, Jon wrote: > > > >> I agree with Paul that SBC behavior is probably defined too poorly to > >> refer > >> to it directly in the GRUU draft, and personally I'm very skeptical of > >> taking on that definition as a deliverable for GRUU. At the risk of > >> complicating a discussion about non-standard entities with standards: > >> > >> RFC3261, Table 2: > >> > >> Header field where proxy ACK BYE CAN INV OPT REG > >> ___________________________________________________________ > >> Contact R o - - m o o > >> > >> > >> I don't see an "m" under "proxy" there... but of course we're not talking > >> about proxy servers as such. That much said, if Contacts were > >> something that > >> an entity other than a user agent could safely set, there would be an > >> "m" in > >> the table up there. If an intermediary wants to request that it be in the > >> path of further SIP transactions in a dialog in a safe way, well, there's > >> another header for that. Furthermore, the GRUU acquisition mechanism > >> inherently provides a way for intermediaries to give a Contact header > >> to a > >> user agent in order to strongly bind request routing to an > >> intermediary. So, > >> there are reasonable alternatives to rewriting the header in transit. > >> > >> Furthmore, I would like to point out that sip-identity provides integrity > >> over the addr-spec of the Contact header field. If the Contact header > >> field > >> has been modified by an intermediary after integrity has been applied, it > >> should be considered an integrity violation by the recipient. > >> > >> This is of course not to say that there are no architectures where > >> SBCs and > >> sip-identity might live together in harmony. The point is that SIP > >> can't be > >> expected to differentiate between friendly and unfriendly intermediaries > >> that break the rules, and that we certainly can't enable arbitary > >> entities > >> to modify the Contact header or we open ourselves up to all sorts of > >> nasty > >> attacks. Whatever security gains people think they are getting from > >> rewriting the Contact header at an intermediary, I'm sure they pale in > >> comparison to the threats that the arise if Contact header can be > >> arbitarily > >> changed by anyone. If we want to prevent something from rewriting a > >> header > >> that shouldn't be rewritten, we should use some form of integrity to > >> prevent > >> that. > >> > >> So, I do think it is reasonable for the GRUU doc to discuss the impact > >> of an > >> intermediary rewriting the Contact header in general (without defining > >> SBCs), and point out that integrity mechanisms like sip-identity could be > >> used to detect a rewrite of a Contact header. But, on some level, I > >> guess I > >> feel rewriting Contacts at an intermediary is already acknowledged to be > >> problematic by the core SIP standard. It'd also be a problem for GRUU > >> if an > >> SBC removed the Call-ID header field, or did any of a number of things it > >> shouldn't do. > >> > >> Jon Peterson > >> NeuStar, Inc. > >> > >> > >>> -----Original Message----- > >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>> Sent: Thursday, September 16, 2004 4:32 PM > >>> To: Jonathan Rosenberg > >>> Cc: sip@ietf.org; Robert Sparks > >>> Subject: Re: [Sip] Re: GRUU and things that rewrite contacts > >>> > >> > >> [snip] > >> > >>> I don't want to comment on the above right now because we are clearly > >>> have different assumptions here. > >>> > >>> I don't think we can meaningfully comment on the impact on SBCs when > >>> we have no definition of such a beast. And trying to generalize to > >>> all forms of B2BUA makes things worse - we repeatedly state that > >>> about all you can say in general about a B2BUA is that it is two > >>> connected UAs - you can't say anything about how the two calls are > >>> related. > >>> > >>> If this is an important problem for us to mention at all, (and I'm > >>> not yet convinced it is), then I think the first step is to define an > >>> SBC, along with the kinds of transformations it performs. Since that > >>> has never been written down, when it is written it can deal properly > >>> with GRUUs. > >>> > >>> Paul > >>> > >> > >> > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Nov 6 23:30:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04035 for ; Sat, 6 Nov 2004 23:30:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQehm-0006SI-Oo for sip-web-archive@ietf.org; Sat, 06 Nov 2004 23:31:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQeeb-0004B3-Np; Sat, 06 Nov 2004 23:27:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQedY-000407-KE for sip@megatron.ietf.org; Sat, 06 Nov 2004 23:26:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03696 for ; Sat, 6 Nov 2004 23:26:41 -0500 (EST) Received: from amer-mta02.csc.com ([20.137.2.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQedo-0006OE-Gt for sip@ietf.org; Sat, 06 Nov 2004 23:27:00 -0500 Received: from csc.com (va-fch34.csc.com [20.6.39.227]) by amer-mta02.csc.com (Switch-3.1.6/Switch-3.1.0) with ESMTP id iA74QOP6020101; Sat, 6 Nov 2004 23:26:25 -0500 (EST) Subject: Re: [Sip] Strict, Semi-Strict and Loose mode in RPH - not a good fit for ets and wps To: Dean Willis X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Janet P Gunn Date: Sat, 6 Nov 2004 23:24:39 -0500 X-MIMETrack: Serialize by Router on VA-FCH34/SRV/CSC(Release 6.0.3|September 26, 2003) at 11/06/2004 11:27:13 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: fonashp@ncs.gov, Darren E Pado , mosleyv@ncs.gov, Saud Negash , Richard F Kaczmarek , sip@ietf.org, nyquetek@msn.com, a.ephrath@ieee.org, jmpolk@cisco.com, KENNETH.R.ERNEY@saic.com, suracif@ncs.gov, Dennis Q Berg X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Yes, it would be better to have the namespace define the behaviors. However, I accept that there may be some general bounds on the behaviors. It is linking them together in fixed combinations that I object to. 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. ---------------------------------------------------------------------------------------- Dean Willis cc: sip@ietf.org, jmpolk@cisco.com, fonashp@ncs.gov, Darren E Pado/FED/CSC@CSC, Saud Negash/FED/CSC@CSC, mosleyv@ncs.gov, Richard F 11/06/2004 08:12 Kaczmarek/FED/SC/CSC@CSC, nyquetek@msn.com, a.ephrath@ieee.org, PM suracif@ncs.gov, KENNETH.R.ERNEY@saic.com, Dennis Q Berg/FED/CSC@CSC Subject: Re: [Sip] Strict, Semi-Strict and Loose mode in RPH - not a good fit for ets and wps Janet P Gunn wrote: > > > > One of the changes in the draft-ietf-sip-resource-priority-05 is the > definition of 3 modes, strict, semi-strict, and loose, and the assignment > of each defined namespaces to a particular mode. > > The definition of the mode involves several distinct behaviors > Would it be better to have each namespace definition fully define the behavior of that namesapce, rather than trying to have some "templates" that could be re-used by multiple namespaces? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Nov 6 23:53:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05639 for ; Sat, 6 Nov 2004 23:53:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQf40-0006ut-4Q for sip-web-archive@ietf.org; Sat, 06 Nov 2004 23:54:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQf1u-0008Jy-4v; Sat, 06 Nov 2004 23:51:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQezj-00080D-9f for sip@megatron.ietf.org; Sat, 06 Nov 2004 23:49:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05420 for ; Sat, 6 Nov 2004 23:49:35 -0500 (EST) Received: from amer-mta01.csc.com ([20.137.2.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQezw-0006qA-B1 for sip@ietf.org; Sat, 06 Nov 2004 23:49:55 -0500 Received: from csc.com (va-fch34.csc.com [20.6.39.227]) by amer-mta01.csc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id iA74nOYu028916; Sat, 6 Nov 2004 23:49:24 -0500 (EST) Subject: RE: [Sip] Strict, Semi-Strict and Loose mode in RPH - not a good fit for ets and wps To: "Ken Carlberg" X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Janet P Gunn Date: Sat, 6 Nov 2004 23:47:49 -0500 X-MIMETrack: Serialize by Router on VA-FCH34/SRV/CSC(Release 6.0.3|September 26, 2003) at 11/06/2004 11:50:13 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: fonashp@ncs.gov, Darren E Pado , mosleyv@ncs.gov, Saud Negash , Richard F Kaczmarek , sip@ietf.org, nyquetek@msn.com, a.ephrath@ieee.org, jmpolk@cisco.com, KENNETH.R.ERNEY@saic.com, suracif@ncs.gov, Dennis Q Berg X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab comments in line ---------------------------------------------------------------------------------------- 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: , Darren E Pado/FED/CSC@CSC, Saud Negash/FED/CSC@CSC, , Richard F Kaczmarek/FED/SC/CSC@CSC, , 11/06/2004 09:26 , , , Dennis Q AM Berg/FED/CSC@CSC Subject: RE: [Sip] Strict,Semi-Strict and Loose mode in RPH - not a good fit for ets and wps > Unfortunately, this (semi-strict) is NOT the behavior desired for the ets > and wps namespaces. > > The behavior desired for the ets and wps namespaces are > 1 RPH is optional (semi-strict and loose) > 2 SIP element ignores a namespace it does not recognize (loose) I would prefer a strict or semi-strict mode because these provide feedback in case: a) a misconfigured UA sends the wrong namespace.priority, and/or b) initial selection of a server/proxy that does not support the desired namespace. The former is quite possible given an ability (and possibly, necessity) of the user to configure their own device to support the given namespace.value combination. [JG] Before posting this, I checked with Dr. Fonash (head of NCS, which "owns" GETS and WPS). He was very clear about wanting "If the SIP element does not recognize the namespace (wps or ets) it should pass it on without acting on it, rather than rejecting it." > 3 The content of the error message should not reveal (to the end user) the > valid values for that namespace (strict) section 4.5 of the drafts states: If the UAS understands the resource value, but refuses to honor the request with elevated priority for this particular user, it returns the 403 (Forbidden) response code. It MAY include the list of resource values that the user is allowed to use in the 'Accept-Resource-Priority' response header field. The "MAY" is the critical term. My understanding would be that this decision is a local policy issue. Outside of that I personally don't see a problem with providing "hints" of accepted values under the context that they can only acted upon by authorized users. Informing the user of the acceptable set of priorities does not bypass or circumvent the need for proper authentication credentials. [JG]I am not as concerned about this case (valid namespace.valid value - just not authorized). I am more concerned about the error message when the namespace, or value are not recognized. But if ets and wps operate with the behavior "SIP element ignores a namespace it does not recognize", half of that goes away. [JG]I am still not entirely sure about the desired behavior for the other half- (valid namespace.invalid value). But I suspect that it would be better to a) Reject the message b) NOT return the list of valid values. [JG] I do not think that the full loose mode as defined (if the SIP element gets (valid namespace.invalid value) it processes the message as if it had no RPH) is the right approach. I think these messages should be rejected, and get an error message. [JG]But I am open to other approaches. > 4 SIP messages that include the RPH with the ets or wps namespaces should > include the authorization header (or equivalent mechanism) (semi-strict) > 5 Precedence (queueing) is generally the means of providing priority, but > exemption from network management controls, for instance call admission > within an IP domain, when a "regular" call would not be admitted, is also > needed. Pre-emption is not used. (semi-strict "plus more") the "plus more" would seem to be a product of local policy [JG] Agree. While it doesn't explicitly state it, the document leads you to believe that queueing is the only behavior permitted in semi-strict mode. > 6 There is no a priori requirement to use, or not use, the "Require" > header field. isn't this addressed in section 4.3.2 below? or am I missing something? If the request includes a 'Require' header field with the 'Resource-Priority' option tag, a UAS MUST follow the strict or semi-strict mode rules, otherwise UAS and proxies MUST operate in loose mode. [JG]I guess I wasn't clear. I simply meant that there wasn't a concern about the "require" header itself, independent of the strict/semi-strict/loose mode. Once that is "right", the approach to the "require" header will follow -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 sip-bounces@ietf.org Sun Nov 7 09:20:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21614 for ; Sun, 7 Nov 2004 09:20:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQnuf-00042s-Lp for sip-web-archive@ietf.org; Sun, 07 Nov 2004 09:21:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQnsV-0006at-0N; Sun, 07 Nov 2004 09:18:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQns8-0006Uy-Vf for sip@megatron.ietf.org; Sun, 07 Nov 2004 09:18:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21529 for ; Sun, 7 Nov 2004 09:18:22 -0500 (EST) Message-Id: <200411071418.JAA21529@ietf.org> Received: from phobos.simply.net ([81.3.64.11]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CQnsK-00040Z-Cv for sip@ietf.org; Sun, 07 Nov 2004 09:18:46 -0500 Received: (qmail 26821 invoked from network); 7 Nov 2004 14:17:42 -0000 Received: from pcp08649708pcs.towson01.md.comcast.net (HELO albers) (69.137.47.20) by phobos.simply.net with SMTP; 7 Nov 2004 14:17:42 -0000 From: "Ken Carlberg" To: "'Janet P Gunn'" Subject: RE: [Sip] Strict, Semi-Strict and Loose mode in RPH - not a good fit for ets and wps Date: Sun, 7 Nov 2004 09:16:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTEhSol66NE2u31RCy5G1PiSib6vwAS0vNQ In-Reply-To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: fonashp@ncs.gov, "'Darren E Pado'" , mosleyv@ncs.gov, "'Saud Negash'" , "'Richard F Kaczmarek'" , sip@ietf.org, nyquetek@msn.com, a.ephrath@ieee.org, jmpolk@cisco.com, KENNETH.R.ERNEY@saic.com, suracif@ncs.gov, "'Dennis Q Berg'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit > I would prefer a strict or semi-strict mode because these provide feedback in > case: a) a misconfigured UA sends the wrong namespace.priority, and/or b) > initial selection of a server/proxy that does not support the desired > namespace. The former is quite possible given an ability (and possibly, > necessity) of the user to configure their own device to support the given > namespace.value combination. > > [JG] Before posting this, I checked with Dr. Fonash (head of NCS, which > "owns" GETS and WPS). He was very clear about wanting "If the SIP element > does not recognize the namespace (wps or ets) it should pass it on without > acting on it, rather than rejecting it." ok. Dr Fonash now has additional input on the subject given my previous email; if there is no feedback, then the sender hopes everything is working fine. further, it will continue to use an R-P capable proxy with no feedback from the INVITE indicating that it does not support that particular namespace/value. Keep in mind that as it states earlier in the draft, the R-P header is ignored (assuming proper implementation) by those proxies (eg, the installed base) that do not support the new R-P header. As a sidenote, our current implementation of the R-P header follows the MAY portion of the draft and does not send back hints of what are acceptable priorities. Also, when you say the NCS "owns" GETS and WPS, are you refering to the systems or the namespace? If its both, then I have my doubts about the latter. I see no association of the NCS with WPS or GETS in the draft and it would seem that initial "ownership" of those namespaces, as well as the others like ETS, lies with the authors of the draft. (I'll be happy to be corrected on that assumption). -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 sip-bounces@ietf.org Sun Nov 7 09:48:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23599 for ; Sun, 7 Nov 2004 09:48:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQoLn-0004Xq-PW for sip-web-archive@ietf.org; Sun, 07 Nov 2004 09:49:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQoGx-0001QC-JO; Sun, 07 Nov 2004 09:44:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQoCc-0000yr-LS for sip@megatron.ietf.org; Sun, 07 Nov 2004 09:39:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23075 for ; Sun, 7 Nov 2004 09:39:32 -0500 (EST) Message-Id: <200411071439.JAA23075@ietf.org> Received: from phobos.simply.net ([81.3.64.11]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CQoCx-0004Nx-C1 for sip@ietf.org; Sun, 07 Nov 2004 09:39:56 -0500 Received: (qmail 10185 invoked from network); 7 Nov 2004 14:39:01 -0000 Received: from pcp08649708pcs.towson01.md.comcast.net (HELO albers) (69.137.47.20) by phobos.simply.net with SMTP; 7 Nov 2004 14:39:01 -0000 From: "Ken Carlberg" To: Date: Sun, 7 Nov 2004 09:37:50 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTE11safebIOYEtRNGtvU8Z+eTfTg== X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Subject: [Sip] private correspondance X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit my apologies for the non-technical comment, and perhaps this thread should go to the IETF list if there are responses. private comments to authors is as we all know a time honored tradition in the IETF. its very beneficial in lowering the signal-to-noise ratio for minor comments, word-smithing, and conveying the opinions of those people that are either shy or feel that privacy will help clarify things. however, private comments as a *primary and consistent* form of input to authors leading to *significant* changes is detrimental and contrary to the open process of the IETF. It contributes to confusion for those on the list and can be regressive and unnecesarily delays progression of a draft. I ask that people keep this in mind and not send private comments beyond clarification or word-smithing. cheers, -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 sip-bounces@ietf.org Sun Nov 7 10:56:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28889 for ; Sun, 7 Nov 2004 10:56:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQpPl-0005jy-N4 for sip-web-archive@ietf.org; Sun, 07 Nov 2004 10:57:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQpI4-0007OL-KR; Sun, 07 Nov 2004 10:49:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQpG3-0006sw-I4 for sip@megatron.ietf.org; Sun, 07 Nov 2004 10:47:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28189 for ; Sun, 7 Nov 2004 10:47:09 -0500 (EST) From: Mpierce1@aol.com Received: from imo-d06.mx.aol.com ([205.188.157.38]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQpGM-0005VJ-S8 for sip@ietf.org; Sun, 07 Nov 2004 10:47:34 -0500 Received: from Mpierce1@aol.com by imo-d06.mx.aol.com (mail_out_v37_r3.8.) id l.1d8.2fad9d47 (4340); Sun, 7 Nov 2004 10:46:32 -0500 (EST) Message-ID: <1d8.2fad9d47.2ebf9d57@aol.com> Date: Sun, 7 Nov 2004 10:46:31 EST Subject: Re: [Sip] Strict, Semi-Strict and Loose mode in RPH - not a good fit for ets ... To: sip@ietf.org MIME-Version: 1.0 X-Mailer: 6.0 for Windows XP sub 10500 X-Spam-Score: 0.3 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: jmpolk@cisco.com, jgunn6@csc.com, carlberg@g11.org.uk, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0696415664==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba --===============0696415664== Content-Type: multipart/alternative; boundary="part1_1d8.2fad9d47.2ebf9d57_boundary" --part1_1d8.2fad9d47.2ebf9d57_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 11/6/2004 7:21:20 PM Eastern Standard Time, dean.willis@softarmor.com writes: > Would it be better to have each namespace definition fully define the > behavior of that namesapce, rather than trying to have some "templates" > that could be re-used by multiple namespaces? > Absolutely, and as described in earlier versions of this draft, that documentation does not have to be in an RFC. That is also why I object to this new version -05. It requires an RFC for every new namespace. Future uses can not, nor should they have to, go through this excruciating process of producing an RFC just to register a new namespace. ------------------------------------------------------------------------------ --------------------- In a message dated 11/7/2004 9:24:23 AM Eastern Standard Time, carlberg@g11.org.uk writes: > Also, when you say the NCS "owns" GETS and WPS, are you refering to the > systems > or the namespace? If its both, then I have my doubts about the latter. I > see > no association of the NCS with WPS or GETS in the draft and it would seem > that > initial "ownership" of those namespaces, as well as the others like ETS, lies > with the authors of the draft. (I'll be happy to be corrected on that > assumption). > In the case of the DSN namespace, the previous version of this draft had the following for the definition of this namespace: 9.5.2 Namespace dsn Namespace: dsn Description: United States Defense Switched Network. The values are adopted from RFC 791 [RFC0791], omitting the levels "critic-ecp", "network control" and "internetwork control", as these are inappropriate here. Documentation: ANSI T1.619, Section B1 Organization: United States Department of Defense, Defense Information Systems Agency (DISA). So, in a way, DISA does "own" this namespace. At least, DISA is responsible for defining its operation within its own network. This material was removed from the latest version, which also is why I object to accepting version -05. And, no, the "ownership" of these namespaces does not lie with the "authors" at this point. It is a Working Group draft, meaning that the "ownership" currently lies with the WG as a whole, and changes to this draft should not be made unless agreed to by the WG. There was never any discussion about many of these changes in -05. Mike Pierce --part1_1d8.2fad9d47.2ebf9d57_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message=20= dated 11/6/2004 7:21:20 PM Eastern Standard Time, dean.willis@softarmor.com=20= writes:


Would it be better to have=20= each namespace definition fully define the=20
behavior of that namesapce, rather than trying to have some "templates"=20
that could be re-used by multiple namespaces?

Absolutely, and as described in earlier versions of this draft, that doc= umentation does not have to be in an RFC. That is also why I object to this=20= new version -05. It requires an RFC for every new namespace. Future uses can= not, nor should they have to, go through this excruciating process of produ= cing an RFC just to register a new namespace.


------------------------------------------------------------------------= ---------------------------
In a message dated 11/7/2004 9:24:23 AM Eastern Standard Time, carlberg@= g11.org.uk writes:


Also, when you say the NCS=20= "owns" GETS and WPS, are you refering to the systems
or the namespace?  If its both, then I have my doubts about the lat= ter.  I see
no association of the NCS with WPS or GETS in the draft and it would see= m that
initial "ownership" of those namespaces, as well as the others like ETS,= lies
with the authors of the draft.  (I'll be happy to be corrected on t= hat
assumption).

In the case of the DSN namespace, the previous version of this draft had= the following for the definition of this namespace:

9.5.2  Namespace dsn

  Namespace: dsn
  Description: United States Defense Switched Network.  = The values are
     adopted from RFC 791 [RFC0791], omitting=20= the levels "critic-ecp",
     "network control" and "internetwork contr= ol", as these are
     inappropriate here.
  Documentation: ANSI T1.619, Section B1
  Organization: United States Department of Defense, Defense
     Information Systems Agency (DISA).

So, in a way, DISA does "own" this namespace. At least, DISA is responsi= ble for defining its operation within its own network.
This material was removed from the latest version, which also is why I o= bject to accepting version -05.

And, no, the "ownership" of these namespaces does not lie with the "auth= ors" at this point. It is a Working Group draft, meaning that the "ownership= " currently lies with the WG as a whole, and changes to this draft should no= t be made unless agreed to by the WG. There was never any discussion about m= any of these changes in -05.

Mike Pierce

--part1_1d8.2fad9d47.2ebf9d57_boundary-- --===============0696415664== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0696415664==-- From sip-bounces@ietf.org Sun Nov 7 15:27:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21447 for ; Sun, 7 Nov 2004 15:27:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQte4-00032k-7W for sip-web-archive@ietf.org; Sun, 07 Nov 2004 15:28:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQtXB-0002fx-Ab; Sun, 07 Nov 2004 15:21:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQtSP-0007nr-4z for sip@megatron.ietf.org; Sun, 07 Nov 2004 15:16:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20106 for ; Sun, 7 Nov 2004 15:16:10 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQtSm-0002i4-F1 for sip@ietf.org; Sun, 07 Nov 2004 15:16:37 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-4.cisco.com with ESMTP; 07 Nov 2004 12:15:43 -0800 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iA7KFNnC008958; Sun, 7 Nov 2004 12:15:24 -0800 (PST) Received: from cisco.com ([161.44.79.125]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMW03932; Sun, 7 Nov 2004 15:15:34 -0500 (EST) Message-ID: <418E8266.9030106@cisco.com> Date: Sun, 07 Nov 2004 15:15:34 -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: mbhatia@nextone.com Subject: Re: [Sip] Re: GRUU and things that rewrite contacts References: <200411070415.XAA13226@marlborough.cnchost.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, "'Robert Sparks'" , "'Jonathan Rosenberg'" , "'Peterson, Jon'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df Content-Transfer-Encoding: 7bit Medhavi Bhatia wrote: > I may have caught up to this discussion too late, but here are some > thoughts. I probably need to dig deeper into the GRUU draft too. > > There seem to be two cases. > > 1) SBC sits between the UA and the proxy/registrar, where the UA sends > requests for the proxy addressed to the SBC. Can you clarify what you mean above - perhaps give an example? In general, the UA doesn't know much about what is going on. At best, it knows how to construct the To-uri and derive the request-uri from it, and then may have a loose route to insert in the message. Perhaps the loose route transits an SBC, and maybe it acts as a B2BUA. Or do you have something else in mind? > In this case, I don't see much > of a concern as contact parameters are not overwritten for REGISTER. You state this as fact. But this goes to the heart of the problem that we have no definition of what an SBC does. I guess yours must not overwrite contact parameters in a REGISTER. > For the > INVITE, since the SBC knows that the Contact is a GRUU, It does? How? I guess it can know in some cases, if it saw the register that requested the GRUU it might remember the returned gruu and recognize its use in future requests, but that would be a lot of work. And it won't work for gruu values that it didnt' see being assigned. In general you just can't recognize a gruu by inspection. > it is not > overwritten. The last part needs SBCs to understand the GRUUs. Please explain what kind of understanding you think you require, and how it is even theoretically possible to have it. > 2) The same as above, except the UA does not know who the Registrar is. This > is a tricky application and I guess not part of the usual suspects. In this > case, the SBC will need to be aware of GRUUs on the REGISTER also. I have no idea what you mean here. > The SBC also may have an option to create a GRUU and map one obtained from > the Registrar to this one. I think that was more or less what Jonathan was suggesting it might do in his original posting. It is pretty ugly. I have the distressing feeling that SBCs are just doing random stuff, which has lots of potential unintended consequences. Paul > -Medhavi. > > >>-----Original Message----- >>From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Paul > > Kyzivat > >>Sent: Tuesday, September 21, 2004 9:13 AM >>To: Jonathan Rosenberg >>Cc: sip@ietf.org; Robert Sparks; Peterson, Jon >>Subject: Re: [Sip] Re: GRUU and things that rewrite contacts >> >>This would be a good time for those that build SBCs to take note and >>action, and to speak up if they have difficulty with the deployment of >>GRUUs. >> >> Paul >> >>Jonathan Rosenberg wrote: >> >>>Jon, >>> >>>I agree with you and Paul that we cannot, and should not, try here or >>>anywhere else to define an SBC and consider its impacts. I think we can >>>and should discuss the impact of contact-rewriting elements, and point >>>out, as you say, that the identity draft would detect such a case. >>> >>> From a practical matter, I will say that the fact that SBCs will likely >>>not work with GRUU is a real concern. It is going to make it hard to >>>deploy gruu, and generally I am a really big fan of easy-to-deploy >>>solutions. For better or worse, there ARE SBCs deployed in many existing >>>SIP networks, and in those networks, getting gruu deployed will be >>>harder. It will require coordination now between not just the client >>>vendor and SIP server vendor, but now also the SBC vendor. In my >>>experience, the more parts of the machine that all need to be >>>simultaneously upgraded for a new feature, the less likely, >>>exponentially I think, it is that such an upgrade will occur. If you >>>couple this with the fact that, while gruu is definitely a key part of >>>our specs, its an infrastructure improvement with no new features per >>>se, it becomes a hard sell. >>> >>>I still believe that the only alternative on the table - using a new >>>header field for conveying gruu in register and invite/200 - has an even >>>worse deployment path. >>> >>>So, absent a better suggestion, and I don't have one, I think our only >>>choice is to document the problems per above. >>> >>>-Jonathan R. >>> >>> >>> >>>Peterson, Jon wrote: >>> >>> >>>>I agree with Paul that SBC behavior is probably defined too poorly to >>>>refer >>>>to it directly in the GRUU draft, and personally I'm very skeptical of >>>>taking on that definition as a deliverable for GRUU. At the risk of >>>>complicating a discussion about non-standard entities with standards: >>>> >>>>RFC3261, Table 2: >>>> >>>> Header field where proxy ACK BYE CAN INV OPT REG >>>> ___________________________________________________________ >>>> Contact R o - - m o o >>>> >>>> >>>>I don't see an "m" under "proxy" there... but of course we're not >>> > talking > >>>>about proxy servers as such. That much said, if Contacts were >>>>something that >>>>an entity other than a user agent could safely set, there would be an >>>>"m" in >>>>the table up there. If an intermediary wants to request that it be in >>> > the > >>>>path of further SIP transactions in a dialog in a safe way, well, >>> > there's > >>>>another header for that. Furthermore, the GRUU acquisition mechanism >>>>inherently provides a way for intermediaries to give a Contact header >>>>to a >>>>user agent in order to strongly bind request routing to an >>>>intermediary. So, >>>>there are reasonable alternatives to rewriting the header in transit. >>>> >>>>Furthmore, I would like to point out that sip-identity provides >>> > integrity > >>>>over the addr-spec of the Contact header field. If the Contact header >>>>field >>>>has been modified by an intermediary after integrity has been applied, >>> > it > >>>>should be considered an integrity violation by the recipient. >>>> >>>>This is of course not to say that there are no architectures where >>>>SBCs and >>>>sip-identity might live together in harmony. The point is that SIP >>>>can't be >>>>expected to differentiate between friendly and unfriendly >>> > intermediaries > >>>>that break the rules, and that we certainly can't enable arbitary >>>>entities >>>>to modify the Contact header or we open ourselves up to all sorts of >>>>nasty >>>>attacks. Whatever security gains people think they are getting from >>>>rewriting the Contact header at an intermediary, I'm sure they pale in >>>>comparison to the threats that the arise if Contact header can be >>>>arbitarily >>>>changed by anyone. If we want to prevent something from rewriting a >>>>header >>>>that shouldn't be rewritten, we should use some form of integrity to >>>>prevent >>>>that. >>>> >>>>So, I do think it is reasonable for the GRUU doc to discuss the impact >>>>of an >>>>intermediary rewriting the Contact header in general (without defining >>>>SBCs), and point out that integrity mechanisms like sip-identity could >>> > be > >>>>used to detect a rewrite of a Contact header. But, on some level, I >>>>guess I >>>>feel rewriting Contacts at an intermediary is already acknowledged to >>> > be > >>>>problematic by the core SIP standard. It'd also be a problem for GRUU >>>>if an >>>>SBC removed the Call-ID header field, or did any of a number of things >>> > it > >>>>shouldn't do. >>>> >>>>Jon Peterson >>>>NeuStar, Inc. >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>>Sent: Thursday, September 16, 2004 4:32 PM >>>>>To: Jonathan Rosenberg >>>>>Cc: sip@ietf.org; Robert Sparks >>>>>Subject: Re: [Sip] Re: GRUU and things that rewrite contacts >>>>> >>>> >>>>[snip] >>>> >>>> >>>>>I don't want to comment on the above right now because we are clearly >>>>>have different assumptions here. >>>>> >>>>>I don't think we can meaningfully comment on the impact on SBCs when >>>>>we have no definition of such a beast. And trying to generalize to >>>>>all forms of B2BUA makes things worse - we repeatedly state that >>>>>about all you can say in general about a B2BUA is that it is two >>>>>connected UAs - you can't say anything about how the two calls are >>>>>related. >>>>> >>>>>If this is an important problem for us to mention at all, (and I'm >>>>>not yet convinced it is), then I think the first step is to define an >>>>>SBC, along with the kinds of transformations it performs. Since that >>>>>has never been written down, when it is written it can deal properly >>>>>with GRUUs. >>>>> >>>>> Paul >>>>> >>>> >>>> >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Nov 7 15:57:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24326 for ; Sun, 7 Nov 2004 15:57:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQu7A-0003oQ-D5 for sip-web-archive@ietf.org; Sun, 07 Nov 2004 15:58:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQtu3-0004p9-D2; Sun, 07 Nov 2004 15:44:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQtoB-0002AF-Kz for sip@megatron.ietf.org; Sun, 07 Nov 2004 15:38:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22701 for ; Sun, 7 Nov 2004 15:38:41 -0500 (EST) Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQtoa-0003KZ-H7 for sip@ietf.org; Sun, 07 Nov 2004 15:39:08 -0500 Received: from pingtel.com (unknown[130.129.135.0]) by comcast.net (rwcrmhc11) with SMTP id <2004110720380601300b3pfie> (Authid: dgpetrie); Sun, 7 Nov 2004 20:38:06 +0000 Message-ID: <418E8783.C5F85793@pingtel.com> Date: Sun, 07 Nov 2004 15:37:23 -0500 From: "Daniel G. Petrie" Organization: Pingtel Corp. http://www.pingtel.com X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Eric Burger , sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Subject: [Sip] draft-ietf-sip-content-indirect-mech X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit URI scheme negotiation: Section 5.2 I am not sure I understand the URI scheme mechanizm. As I read the draft it seems the party providing the content gets to specify the alternative URI schemes. How does the retriever of the indirect content get to indicate what it supports. It is not always a UAS that is providing content indirection. In the configuration framework an event package is proposed where the NOTIFY request would use content indirection. So how does a subscriber indicate that it supports the FOO URI scheme. Can multipart/alternative be used by the notifier to provide alternative URI scheme URIs for content indirection (e.g. provide a FTP or XCAP alternative to the HTTP URI that is also included)? etag and content-id interaction: This draft describes a requirement for relating the HTTP etag to the content, but no binding is proposed. When using content indirection with XCAP it is very important that the content-id be somehow bound to the etag. Otherwise there is a race condition where the receiver of the content indirection URI does not know if the last retrived content (label by the content-id) corresponds to the etag advertised in a NOTIFY of content change. The simplest form of binding of the etag would be to simply use the etag as the content-id. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Nov 7 17:28:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05340 for ; Sun, 7 Nov 2004 17:28:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQvWu-0006Xi-1W for sip-web-archive@ietf.org; Sun, 07 Nov 2004 17:29:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQvPE-0003jB-Jd; Sun, 07 Nov 2004 17:21:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQvOU-0003Yx-OW for sip@megatron.ietf.org; Sun, 07 Nov 2004 17:20:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04639 for ; Sun, 7 Nov 2004 17:20:15 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQvOr-0006Mr-Dv for sip@ietf.org; Sun, 07 Nov 2004 17:20:44 -0500 Received: from [192.168.0.111] (adsl-209-30-35-14.dsl.rcsntx.swbell.net [209.30.35.14]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iA7MK5uY047383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Nov 2004 16:20:07 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <418D6AFE.4060605@nostrum.com> Date: Sat, 06 Nov 2004 18:23:26 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jon Peterson , Cullen Jennings References: <200409291930.PAA02227@ietf.org> In-Reply-To: <200409291930.PAA02227@ietf.org> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: sip@ietf.org Subject: [Sip] Re: I-D ACTION:draft-ietf-sip-identity-03.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit This looks really solid. In response to Dean's earlier query, I suspect this is quickly reaching "ready for WGLC" status. When looking over this, though, there are two issues that might need a bit more text (although one is really more of a nit). The first issue revolves around proxy validation of received requests which contain authenticated identity headers, and how these proxies communicate with the user who is the target of the request, and has two sub-issues. Primary among these is a question of how the proxies communicate discrepancies to the recipient. Section 7 requires: > Additionally, the Date, Contact and Call-ID headers MUST be analyzed > in the manner described in Section 14; recipients that wish to verify > Identity signatures MUST support all of the operations described > there. Any discrepancies or violations MUST be reported to the user. If I implement a proxy, it is not clear how I can satisfy this second MUST. A secondary sub-issue arises from the mechanism by which the proxy decides to trust certificates. There is nothing in the current draft that suggests, for example, that trusting self-signed domain certs for the purposes of user authentication might be a Really Bad Idea. (Obvious to security wonks, maybe not so much for your average implementor). The reason this ties into user interaction is that it becomes unclear how a proxy should react if it receives a request; that request has an authenticated identity asserted by a domain; and the root CA for the domain's certificate is not known. With user applications, this is typically handled by saying, "I don't know who blackhelicopers.org is, but they signed this certificate. Click here to examine the cert yourself, and let me know if I should accept this cert as invalid, temporarily valid, or permanently valid." When the check is performed by a proxy, such interaction is really quite difficult. The best a proxy can do is reject the request with a 428 (which seems a bit extreme), or let it through (in which case the proxy's check serves little to no purpose) So, I suggest that the draft probably needs a little more text around proxy handling of requests; further, given the all-or-nothing nature of proxy validation of authenticated identity, we might consider discouraging its use in favor of client validation. The second issue is a tiny nit in that the current draft doesn't specify what to do if you receive a request with an Identity-Info header which contains a URI with a scheme other than sips: or https:. Presumably, recipients should 428 such requests? 400? /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Nov 7 17:39:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06150 for ; Sun, 7 Nov 2004 17:39:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQvhO-0006mj-A5 for sip-web-archive@ietf.org; Sun, 07 Nov 2004 17:39:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQvbB-0005Zm-Gh; Sun, 07 Nov 2004 17:33:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQvPd-0003k4-JW for sip@megatron.ietf.org; Sun, 07 Nov 2004 17:21:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04724 for ; Sun, 7 Nov 2004 17:21:26 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQvQ3-0006OQ-4i for sip@ietf.org; Sun, 07 Nov 2004 17:21:55 -0500 Received: from [192.168.0.111] (adsl-209-30-35-14.dsl.rcsntx.swbell.net [209.30.35.14]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iA7MKD5l047387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Nov 2004 16:20:14 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <418D7220.80907@nostrum.com> Date: Sat, 06 Nov 2004 18:53:52 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] GRUU and sips References: <5.2.1.1.0.20040806093622.01542d40@pop.mcilink.com> <4113A68C.60704@cisco.com> In-Reply-To: <4113A68C.60704@cisco.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Content-Transfer-Encoding: 7bit Cc: Alan Johnston , Cullen Jennings , "sip@ietf.org" , Jonathan Rosenberg , Robert Sparks X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Content-Transfer-Encoding: 7bit I'm getting in a bit late on this thread (sorry), but I've been under the impression for quite some time that sip:foo and sips:foo are *defined* to be the same resource under all circumstances. Section 19.1 of 3261 seems rather clear on this point: > Any resource described by a SIP URI can be > "upgraded" to a SIPS URI by just changing the scheme, if it is > desired to communicate with that resource securely. So, if we just hand out sip: URIs, then full 3261 implementations *know* that they can use it with a sips: scheme and get the same resource. Perhaps it is worth reiterating this point in the GRUU document, but it seems like this is a non-problem. /a Paul Kyzivat wrote: > Alan, > > Did you see my later message on this subject? > > As far as bid down, that is only a problem if the UAS isn't aware that > it happened. Note that no matter what we say, bad guys can make the > change, so it isn't the change that matters, but how it is handled > along the path. > > In a direct connection, the UAS can see whether the r-uri is sip/sips. > If the r-uri is sip it may conclude that the session isn't secure. For > indirect connections it becomes the obligation of the proxies along > the path to use a sip r-uri if the connection can't be guaranteed > secure to them. > > My concern, beyond understanding how GRUU should work, is that a UAS > that wants to support both secure and insecure communication should > only need to make one registration. I have feeling people widely think > things should work this way, but the standard isn't clear if/how this > can be achieved. > > Paul > > Alan Johnston wrote: > >> At 10:35 AM 7/27/2004 -0400, Paul Kyzivat wrote: >> >> >>> Cullen Jennings wrote: >>> >>>> Sounds like a possibility. Can you think of a way where I do not >>>> have to >>>> Register twice to get both a sip and sips URL? >>>> Perhaps we should just say that is a proxy hands out a sip GRUU >>>> sip:foo then >>>> sips:foo MUST also be a valid GRUU with the contact moved to sips >>>> from sip. >>> >>> >>> >>> That would rule out proxies that support gruu but not TLS. >>> >>> I think the converse might make more sense - if the proxy hands out >>> sips:foo then sip:foo MUST also be a valid GRUU. >> >> >> >> Are you sure this is a good idea? Doesn't this open a bid down >> attack for the GRUU + grid dialog identifier described by Robert in >> his dialog reuse draft? >> >> Here's the example - I have a secure SIP dialog with you. You are >> using a secure SIP GRUU + grid dialog identifier. I pass this GRUU >> to another party, such as Robert with a Replaces header field in a >> REFER for the intent to transfer you to Robert. Robert changes the >> URI to a regular SIP GRUU and sends the INVITE with Replaces. If you >> accept this, you have replaced a secure SIP session with an insecure >> session - not a good idea. Better for this transfer to fail if >> Robert tries to downgrade the security on the connection. >> >> I would say a sips:foo GRUU MUST NOT be valid as sip:foo to avoid >> this kind of attack. >> >> Thanks, >> Alan Johnston >> >> >>> Paul >>> >>>> If I get a sip GRUU, others can still use TLS to contact it. I >>>> would like to >>>> make sure that the following case works: a UA only does UDP to >>>> it's proxy, >>>> however, it want communications from outside the domain to use TLS >>>> to the >>>> proxy. I think this works fine with what you are proposing. >>>> On 7/23/04 12:27 PM, "Jonathan Rosenberg" >>>> wrote: >>>> >>>>> The current GRUU spec says very little about interactions between >>>>> GRUU >>>>> and sips, and I think its sufficiently non-obvious that a >>>>> discussion is >>>>> warranted. >>>>> >>>>> Specifically, under what conditions would the registrar provide the >>>>> client with a gruu that is a sips URI? >>>>> >>>>> I think the right answer here is that if teh Contact URI is a sips >>>>> URI, >>>>> then the registrar MUST return a gruu which is a sips URI. If the >>>>> contact URI is not a sips URI, the registrar MUST NOT return a >>>>> sips URI. >>>>> >>>>> Other thoughts? >>>>> >>>>> Thanks, >>>>> Jonathan R. >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol >>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>> Use sipping@ietf.org for new developments on the application of sip >>> >>> >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >> >> >> >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Nov 7 17:41:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06438 for ; Sun, 7 Nov 2004 17:41:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQvjw-0006sf-Ft for sip-web-archive@ietf.org; Sun, 07 Nov 2004 17:42:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQvgX-00068C-41; Sun, 07 Nov 2004 17:38:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQvXi-0005HJ-9J for sip@megatron.ietf.org; Sun, 07 Nov 2004 17:29:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05491 for ; Sun, 7 Nov 2004 17:29:47 -0500 (EST) Received: from amer-mta02.csc.com ([20.137.2.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQvY8-0006aQ-1I for sip@ietf.org; Sun, 07 Nov 2004 17:30:16 -0500 Received: from csc.com (va-fch34.csc.com [20.6.39.227]) by amer-mta02.csc.com (Switch-3.1.6/Switch-3.1.0) with ESMTP id iA7MThsY019597; Sun, 7 Nov 2004 17:29:43 -0500 (EST) Subject: RE: [Sip] Strict, Semi-Strict and Loose mode in RPH - not a good fit for ets and wps To: "Ken Carlberg" X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Janet P Gunn Date: Sun, 7 Nov 2004 17:27:54 -0500 X-MIMETrack: Serialize by Router on VA-FCH34/SRV/CSC(Release 6.0.3|September 26, 2003) at 11/07/2004 05:30:33 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: fonashp@ncs.gov, Darren E Pado , mosleyv@ncs.gov, Saud Negash , Richard F Kaczmarek , sip@ietf.org, nyquetek@msn.com, a.ephrath@ieee.org, jmpolk@cisco.com, KENNETH.R.ERNEY@saic.com, suracif@ncs.gov, Dennis Q Berg X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 To clarify, NCS "owns" (and it is in quotes on purpose) the GETS and WPS programs. As such, it will presumably be the first user of the ets and wps namespaces. But, no, it doesn't "own" (either literally or figuratively) the namespaces. 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" cc: , Darren E Pado/FED/CSC@CSC, Dennis Q Berg/FED/CSC@CSC, , , 11/07/2004 09:16 , , , Richard F AM Kaczmarek/FED/SC/CSC@CSC, Saud Negash/FED/CSC@CSC, , Subject: RE: [Sip] Strict, Semi-Strict and Loose mode in RPH - not a good fit for ets and wps > I would prefer a strict or semi-strict mode because these provide feedback in > case: a) a misconfigured UA sends the wrong namespace.priority, and/or b) > initial selection of a server/proxy that does not support the desired > namespace. The former is quite possible given an ability (and possibly, > necessity) of the user to configure their own device to support the given > namespace.value combination. > > [JG] Before posting this, I checked with Dr. Fonash (head of NCS, which > "owns" GETS and WPS). He was very clear about wanting "If the SIP element > does not recognize the namespace (wps or ets) it should pass it on without > acting on it, rather than rejecting it." ok. Dr Fonash now has additional input on the subject given my previous email; if there is no feedback, then the sender hopes everything is working fine. further, it will continue to use an R-P capable proxy with no feedback from the INVITE indicating that it does not support that particular namespace/value. Keep in mind that as it states earlier in the draft, the R-P header is ignored (assuming proper implementation) by those proxies (eg, the installed base) that do not support the new R-P header. As a sidenote, our current implementation of the R-P header follows the MAY portion of the draft and does not send back hints of what are acceptable priorities. Also, when you say the NCS "owns" GETS and WPS, are you refering to the systems or the namespace? If its both, then I have my doubts about the latter. I see no association of the NCS with WPS or GETS in the draft and it would seem that initial "ownership" of those namespaces, as well as the others like ETS, lies with the authors of the draft. (I'll be happy to be corrected on that assumption). -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 sip-bounces@ietf.org Sun Nov 7 22:02:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26314 for ; Sun, 7 Nov 2004 22:02:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQzo1-0003bR-C5 for sip-web-archive@ietf.org; Sun, 07 Nov 2004 22:02:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQzf6-0007RI-Ij; Sun, 07 Nov 2004 21:53:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQzdm-0007Jx-8v for sip@megatron.ietf.org; Sun, 07 Nov 2004 21:52:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25643 for ; Sun, 7 Nov 2004 21:52:19 -0500 (EST) Received: from marlborough.concentric.net ([207.155.248.14] helo=marlborough.cnchost.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQzeD-0003Pq-PC for sip@ietf.org; Sun, 07 Nov 2004 21:52:50 -0500 Received: from MedhaviLT (pool-138-88-18-68.res.east.verizon.net [138.88.18.68]) by marlborough.cnchost.com id VAA27042; Sun, 7 Nov 2004 21:52:04 -0500 (EST) [ConcentricHost SMTP Relay 1.17] Message-ID: <200411080252.VAA27042@marlborough.cnchost.com> From: "Medhavi Bhatia" To: "'Paul Kyzivat'" Subject: RE: [Sip] Re: GRUU and things that rewrite contacts Date: Sun, 7 Nov 2004 21:52:00 -0500 Organization: NexTone Communications MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTFBpQyNmyoKdtWRpimgHisYY7m2wALqK1Q In-Reply-To: <418E8266.9030106@cisco.com> X-Spam-Score: 4.1 (++++) X-Scan-Signature: b360bd6cb019c35178e5cf9eeb747a5c Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, "'Robert Sparks'" , "'Jonathan Rosenberg'" , "'Peterson, Jon'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mbhatia@nextone.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 4.1 (++++) X-Scan-Signature: 4bb0e9e1ca9d18125bc841b2d8d77e24 Content-Transfer-Encoding: 7bit Paul, See inline. > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Sunday, November 07, 2004 3:16 PM > To: mbhatia@nextone.com > Cc: 'Jonathan Rosenberg'; sip@ietf.org; 'Robert Sparks'; 'Peterson, Jon' > Subject: Re: [Sip] Re: GRUU and things that rewrite contacts > > > > Medhavi Bhatia wrote: > > I may have caught up to this discussion too late, but here are some > > thoughts. I probably need to dig deeper into the GRUU draft too. > > > > There seem to be two cases. > > > > 1) SBC sits between the UA and the proxy/registrar, where the UA sends > > requests for the proxy addressed to the SBC. > > Can you clarify what you mean above - perhaps give an example? > In general, the UA doesn't know much about what is going on. At best, it > knows how to construct the To-uri and derive the request-uri from it, > and then may have a loose route to insert in the message. Perhaps the > loose route transits an SBC, and maybe it acts as a B2BUA. Or do you > have something else in mind? > [MB] I meant that the SBC was acting as an out-bound proxy to get to the proxy/registrar. Packets are destined (at the IP level) to the SBC. The To/request uri's are pointing to the proxy. > > In this case, I don't see much > > of a concern as contact parameters are not overwritten for REGISTER. > > You state this as fact. But this goes to the heart of the problem that > we have no definition of what an SBC does. I guess yours must not > overwrite contact parameters in a REGISTER. > [MB] I assume topology hiding (THIG) is the function of SBC we are talking about. In that case, not passing the parameters would not be the right thing to do. The THIG only alters IP addresses in the headers involved in routing SIP messages (like Via/Contact/Route etc). > > For the > > INVITE, since the SBC knows that the Contact is a GRUU, > > It does? How? I guess it can know in some cases, if it saw the register > that requested the GRUU it might remember the returned gruu and > recognize its use in future requests, but that would be a lot of work. > And it won't work for gruu values that it didnt' see being assigned. > > In general you just can't recognize a gruu by inspection. > [MB] I assume the supported header in the INVITE will contain the gruu option tag. The draft mentions somewhere about how a receiving UA can detect that the Contact is a GRUU. > > it is not > > overwritten. The last part needs SBCs to understand the GRUUs. > > Please explain what kind of understanding you think you require, and how > it is even theoretically possible to have it. > > > 2) The same as above, except the UA does not know who the Registrar is. This > > is a tricky application and I guess not part of the usual suspects. In this > > case, the SBC will need to be aware of GRUUs on the REGISTER also. > > I have no idea what you mean here. > [MB] Service providers, especially in broadband users have been deploying out-bound proxies which forward requests and responses between the client and the main server similar to the case I describe in (1). However there is one interesting variation. Consider that the registering UA does not know it is exchanging messages with an out-bound proxy. The To/req uri as well as the dest IP address are pointing to a proxy which then uses some other means to target the request to the UA's real proxy: (1) Request-uri/To point to the proxy (P) and dest IP points to the SBC. (2) Request-uri/To/dest IP all point to the SBC. SBC forwards request to P. In both cases, SBC is acting as an out-bound proxy in a functional sense. However in (2), the UA does not know about P. I assume that the GRUU which is assigned to the UA also cannot point to the proxy and the domain part must be changed by the SBC. > > The SBC also may have an option to create a GRUU and map one obtained from > > the Registrar to this one. > > I think that was more or less what Jonathan was suggesting it might do > in his original posting. It is pretty ugly. > [MB] I don't think it is necessary. I may be wrong of course. > I have the distressing feeling that SBCs are just doing random stuff, > which has lots of potential unintended consequences. > [MB] Yep. SBCs implement a lot of features. Some of the them were mentioned earlier on another thread. However there are clearly some things which must not be done (like re-writing contact parameters) and some things which it must be able to decipher when it processes packets (like media description for the message). These functions are provided today only via B2BUAs and most people designing SBCs or planning to make one don't always know the requirements clearly. Application Servers based on B2BUAs deal with the same problem. I know of core proxies manufactured by some major vendors which are based on B2BUAs. At minimal we need to see how requirements of intermediate elements and networks, like THIG and media relays are factored in when designing features. We need to look at requirements of service providers in greater detail. > Paul > > > -Medhavi. > > > > > >>-----Original Message----- > >>From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Paul > > > > Kyzivat > > > >>Sent: Tuesday, September 21, 2004 9:13 AM > >>To: Jonathan Rosenberg > >>Cc: sip@ietf.org; Robert Sparks; Peterson, Jon > >>Subject: Re: [Sip] Re: GRUU and things that rewrite contacts > >> > >>This would be a good time for those that build SBCs to take note and > >>action, and to speak up if they have difficulty with the deployment of > >>GRUUs. > >> > >> Paul > >> > >>Jonathan Rosenberg wrote: > >> > >>>Jon, > >>> > >>>I agree with you and Paul that we cannot, and should not, try here or > >>>anywhere else to define an SBC and consider its impacts. I think we can > >>>and should discuss the impact of contact-rewriting elements, and point > >>>out, as you say, that the identity draft would detect such a case. > >>> > >>> From a practical matter, I will say that the fact that SBCs will likely > >>>not work with GRUU is a real concern. It is going to make it hard to > >>>deploy gruu, and generally I am a really big fan of easy-to-deploy > >>>solutions. For better or worse, there ARE SBCs deployed in many existing > >>>SIP networks, and in those networks, getting gruu deployed will be > >>>harder. It will require coordination now between not just the client > >>>vendor and SIP server vendor, but now also the SBC vendor. In my > >>>experience, the more parts of the machine that all need to be > >>>simultaneously upgraded for a new feature, the less likely, > >>>exponentially I think, it is that such an upgrade will occur. If you > >>>couple this with the fact that, while gruu is definitely a key part of > >>>our specs, its an infrastructure improvement with no new features per > >>>se, it becomes a hard sell. > >>> > >>>I still believe that the only alternative on the table - using a new > >>>header field for conveying gruu in register and invite/200 - has an even > >>>worse deployment path. > >>> > >>>So, absent a better suggestion, and I don't have one, I think our only > >>>choice is to document the problems per above. > >>> > >>>-Jonathan R. > >>> > >>> > >>> > >>>Peterson, Jon wrote: > >>> > >>> > >>>>I agree with Paul that SBC behavior is probably defined too poorly to > >>>>refer > >>>>to it directly in the GRUU draft, and personally I'm very skeptical of > >>>>taking on that definition as a deliverable for GRUU. At the risk of > >>>>complicating a discussion about non-standard entities with standards: > >>>> > >>>>RFC3261, Table 2: > >>>> > >>>> Header field where proxy ACK BYE CAN INV OPT REG > >>>> ___________________________________________________________ > >>>> Contact R o - - m o o > >>>> > >>>> > >>>>I don't see an "m" under "proxy" there... but of course we're not > >>> > > talking > > > >>>>about proxy servers as such. That much said, if Contacts were > >>>>something that > >>>>an entity other than a user agent could safely set, there would be an > >>>>"m" in > >>>>the table up there. If an intermediary wants to request that it be in > >>> > > the > > > >>>>path of further SIP transactions in a dialog in a safe way, well, > >>> > > there's > > > >>>>another header for that. Furthermore, the GRUU acquisition mechanism > >>>>inherently provides a way for intermediaries to give a Contact header > >>>>to a > >>>>user agent in order to strongly bind request routing to an > >>>>intermediary. So, > >>>>there are reasonable alternatives to rewriting the header in transit. > >>>> > >>>>Furthmore, I would like to point out that sip-identity provides > >>> > > integrity > > > >>>>over the addr-spec of the Contact header field. If the Contact header > >>>>field > >>>>has been modified by an intermediary after integrity has been applied, > >>> > > it > > > >>>>should be considered an integrity violation by the recipient. > >>>> > >>>>This is of course not to say that there are no architectures where > >>>>SBCs and > >>>>sip-identity might live together in harmony. The point is that SIP > >>>>can't be > >>>>expected to differentiate between friendly and unfriendly > >>> > > intermediaries > > > >>>>that break the rules, and that we certainly can't enable arbitary > >>>>entities > >>>>to modify the Contact header or we open ourselves up to all sorts of > >>>>nasty > >>>>attacks. Whatever security gains people think they are getting from > >>>>rewriting the Contact header at an intermediary, I'm sure they pale in > >>>>comparison to the threats that the arise if Contact header can be > >>>>arbitarily > >>>>changed by anyone. If we want to prevent something from rewriting a > >>>>header > >>>>that shouldn't be rewritten, we should use some form of integrity to > >>>>prevent > >>>>that. > >>>> > >>>>So, I do think it is reasonable for the GRUU doc to discuss the impact > >>>>of an > >>>>intermediary rewriting the Contact header in general (without defining > >>>>SBCs), and point out that integrity mechanisms like sip-identity could > >>> > > be > > > >>>>used to detect a rewrite of a Contact header. But, on some level, I > >>>>guess I > >>>>feel rewriting Contacts at an intermediary is already acknowledged to > >>> > > be > > > >>>>problematic by the core SIP standard. It'd also be a problem for GRUU > >>>>if an > >>>>SBC removed the Call-ID header field, or did any of a number of things > >>> > > it > > > >>>>shouldn't do. > >>>> > >>>>Jon Peterson > >>>>NeuStar, Inc. > >>>> > >>>> > >>>> > >>>>>-----Original Message----- > >>>>>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>>>Sent: Thursday, September 16, 2004 4:32 PM > >>>>>To: Jonathan Rosenberg > >>>>>Cc: sip@ietf.org; Robert Sparks > >>>>>Subject: Re: [Sip] Re: GRUU and things that rewrite contacts > >>>>> > >>>> > >>>>[snip] > >>>> > >>>> > >>>>>I don't want to comment on the above right now because we are clearly > >>>>>have different assumptions here. > >>>>> > >>>>>I don't think we can meaningfully comment on the impact on SBCs when > >>>>>we have no definition of such a beast. And trying to generalize to > >>>>>all forms of B2BUA makes things worse - we repeatedly state that > >>>>>about all you can say in general about a B2BUA is that it is two > >>>>>connected UAs - you can't say anything about how the two calls are > >>>>>related. > >>>>> > >>>>>If this is an important problem for us to mention at all, (and I'm > >>>>>not yet convinced it is), then I think the first step is to define an > >>>>>SBC, along with the kinds of transformations it performs. Since that > >>>>>has never been written down, when it is written it can deal properly > >>>>>with GRUUs. > >>>>> > >>>>> Paul > >>>>> > >>>> > >>>> > >> > >>_______________________________________________ > >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>This list is for NEW development of the core SIP Protocol > >>Use sip-implementors@cs.columbia.edu for questions on current sip > >>Use sipping@ietf.org for new developments on the application of sip > > > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 8 00:24:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07118 for ; Mon, 8 Nov 2004 00:24:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CR220-0006Ro-KU for sip-web-archive@ietf.org; Mon, 08 Nov 2004 00:25:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR1wf-0003lw-3Y; Mon, 08 Nov 2004 00:20:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR1w5-0003bY-Tj for sip@megatron.ietf.org; Mon, 08 Nov 2004 00:19:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06753 for ; Mon, 8 Nov 2004 00:19:22 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CR1wZ-0006LJ-Gq for sip@ietf.org; Mon, 08 Nov 2004 00:19:55 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 07 Nov 2004 21:30:17 -0800 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.10/8.12.6) with ESMTP id iA85Iqom011496; Sun, 7 Nov 2004 21:18:52 -0800 (PST) Received: from [10.67.87.61] (sjc-vpn4-1194.cisco.com [10.21.84.169]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id ATU57705; Sun, 7 Nov 2004 21:18:51 -0800 (PST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sun, 07 Nov 2004 11:41:52 -0500 From: Cullen Jennings To: "sip@ietf.org" Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: Rohan Mahy Subject: [Sip] connect-reuse X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit This makes a lot of sense to me when we authorize using the TLS peer name. However, it seem like creating an alias using the name if the TLS peerName instead of the name in the Via is a better plan. Otherwise we need to describe what names in the via are legal for a given peerName in the TLS. The alias flag in the via would still be the hint that an alias should be created. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 8 01:24:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13212 for ; Mon, 8 Nov 2004 01:24:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CR2xM-0007uG-R2 for sip-web-archive@ietf.org; Mon, 08 Nov 2004 01:24:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR2tu-0006YT-Su; Mon, 08 Nov 2004 01:21:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR2mc-0004D0-Em for sip@megatron.ietf.org; Mon, 08 Nov 2004 01:13:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11967 for ; Mon, 8 Nov 2004 01:13:41 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CR2n5-0007d4-5R for sip@ietf.org; Mon, 08 Nov 2004 01:14:12 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 07 Nov 2004 22:24:31 -0800 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iA86D1om002752; Sun, 7 Nov 2004 22:13:02 -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 WAA06367; Sun, 7 Nov 2004 22:12:58 -0800 (PST) Message-Id: <4.3.2.7.2.20041107231501.027c5950@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 08 Nov 2004 00:13:01 -0600 To: Janet P Gunn , "Ken Carlberg" From: "James M. Polk" Subject: RE: [Sip] Strict, Semi-Strict and Loose mode in RPH - not a good fit for ets and wps In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: fonashp@ncs.gov, Darren E Pado , mosleyv@ncs.gov, Saud Negash , Richard F Kaczmarek , sip@ietf.org, nyquetek@msn.com, a.ephrath@ieee.org, KENNETH.R.ERNEY@saic.com, suracif@ncs.gov, Dennis Q Berg X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 comments in-line below At 11:47 PM 11/6/2004 -0500, Janet P Gunn wrote: >From: "Ken Carlberg" > > Unfortunately, this (semi-strict) is NOT the behavior desired for the >ets > > and wps namespaces. Janet - I like your list. It is quite valuable because it gives very good points for discussion. As Ken has stated already, a couple of issues from your list (I believe) are already addressed within this current version. > > > > The behavior desired for the ets and wps namespaces are > > 1 RPH is optional (semi-strict and loose) got it > > 2 SIP element ignores a namespace it does not recognize (loose) To this, remember the ID does not say to "fail" the call, just that Request. This is one way to inform the calling UAC to know it included a namespace or priority value that was not recognizable (meaning not ets.0/1/2/3/4 or wps.0/1/2/3/4). There is no way to inform the UAC of this issue within the SIP Request (with the bad namespace.priority-value) without failing the request. Meaning, there can be no preferential treatment without the sending element being told so. SIP doesn't have a "pass, but this wasn't a good choice" provisional response like other protocols. To the user, they might not notice several SIP Request failures, the person is merely waiting for the call to be set up (still under a second). >I would prefer a strict or semi-strict mode because these provide feedback >in >case: a) a misconfigured UA sends the wrong namespace.priority, and/or b) >initial selection of a server/proxy that does not support the desired >namespace. The former is quite possible given an ability (and possibly, >necessity) of the user to configure their own device to support the given >namespace.value combination. > >[JG] Before posting this, I checked with Dr. Fonash (head of NCS, which >"owns" GETS and WPS). He was very clear about wanting "If the SIP element >does not recognize the namespace (wps or ets) it should pass it on without >acting on it, rather than rejecting it." again - this doesn't mean the call attempt has failed and the user needs to dial again - which is one way to read what you wrote. The text in this doc clearly needs to not call for failing the call in the ets/wps use-case because of a bad namespace or priority-value. Ironically this is where the A-R-P header would be handy, if it didn't reveal to everyone who purposely or inadvertently included a bad or unknown RP header. > > 3 The content of the error message should not reveal (to the end user) >the > > valid values for that namespace (strict) > >section 4.5 of the drafts states: > > If the UAS understands the resource value, but refuses to honor the > request with elevated priority for this particular user, it returns > the 403 (Forbidden) response code. It MAY include the list of > resource values that the user is allowed to use in the > 'Accept-Resource-Priority' response header field. > >The "MAY" is the critical term. I feel this MAY answers your concern - as Ken points out. You may mandate vendor's equipment be able to be configured to *not* send the A-R-P in this case. That is a useful marketing requirement. >My understanding would be that this >decision >is a local policy issue. Outside of that I personally don't see a problem >with >providing "hints" of accepted values under the context that they can only >acted >upon by authorized users. Informing the user of the acceptable set of >priorities does not bypass or circumvent the need for proper authentication >credentials. > >[JG]I am not as concerned about this case (valid namespace.valid value - >just not authorized). I would think this is of concern - as anyone (literally) can be in this group. >I am more concerned about the error message when >the namespace, or value are not recognized. But if ets and wps operate >with the behavior "SIP element ignores a namespace it does not recognize", >half of that goes away. > >[JG]I am still not entirely sure about the desired behavior for the other >half- (valid namespace.invalid value). But I suspect that it would be >better to >a) Reject the message >b) NOT return the list of valid values. I consider this to be the case every time a message is not accurate, but want to discuss it with you to tease out any "ships in the night" scenarios we're missing >[JG] I do not think that the full loose mode as defined (if the SIP element >gets (valid namespace.invalid value) it processes the message as if it had >no RPH) is the right approach. nor do I >I think these messages should be rejected, >and get an error message. I agree >[JG]But I am open to other approaches. we have time to talk > > 4 SIP messages that include the RPH with the ets or wps namespaces should > > include the authorization header (or equivalent mechanism) (semi-strict) this should be self evident in public networks.... > > 5 Precedence (queueing) is generally the means of providing priority, but > > exemption from network management controls, for instance call admission > > within an IP domain, when a "regular" call would not be admitted, is also > > needed. Pre-emption is not used. (semi-strict "plus more") I do not understand what you have written above, can you rephrase please? >the "plus more" would seem to be a product of local policy > >[JG] Agree. While it doesn't explicitly state it, the document leads you >to believe that queueing is the only behavior permitted in semi-strict >mode. This is stated a couple of times in the doc, including in the IANA section in the table > > 6 There is no a priori requirement to use, or not use, the "Require" > > header field. > >isn't this addressed in section 4.3.2 below? or am I missing something? > > If the request includes a 'Require' header field with the > 'Resource-Priority' option tag, a UAS MUST follow the strict or > semi-strict mode rules, otherwise UAS and proxies MUST operate in > loose mode. > > >[JG]I guess I wasn't clear. I simply meant that there wasn't a concern >about the "require" header itself, independent of the >strict/semi-strict/loose mode. Once that is "right", the approach to the >"require" header will follow hmmmm The "Require" header is to mandate that SIP Responses use the header as is (copied from request to response without change). If ever there is a case needed in which preferential treatment is within the processing of SIP elements (such as Proxies), knowing there will always be more than one SIP message necessary to complete a transaction - meaning both Request and Response will need to be RP marked for preferential treatment for the session/transaction to be given priority over other transactions. To put this simply, if the INVITE is consistently moved to the head of the line in all SIP elements between UAs 1 & 2, and the 200 OK is slowed/delayed or lost in the congestion of one or more Proxies, the call will not be established. In this case, the INVITE, 200 OK and ACK will need the RP indication to gain the preferential treatment of that domain; and any other messages within that transaction will require it too (such as 183, PRACK and UPDATE messages if RFC 3312 Preconditions were to be required to set up, say RSVP between endpoints). >-ken 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 sip-bounces@ietf.org Mon Nov 8 09:44:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14054 for ; Mon, 8 Nov 2004 09:44:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRAlc-0002lz-Ms for sip-web-archive@ietf.org; Mon, 08 Nov 2004 09:45:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRAPE-0003Py-4Q; Mon, 08 Nov 2004 09:22:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRAGG-0001Id-FA for sip@megatron.ietf.org; Mon, 08 Nov 2004 09:12:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10415 for ; Mon, 8 Nov 2004 09:12:46 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRAGo-0001mw-31 for sip@ietf.org; Mon, 08 Nov 2004 09:13:22 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 08 Nov 2004 06:23:41 -0800 Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iA8EC8nC007241; Mon, 8 Nov 2004 06:12:09 -0800 (PST) Received: from [130.129.135.140] (sjc-vpn1-592.cisco.com [10.21.98.80]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFP06381; Mon, 8 Nov 2004 06:12:11 -0800 (PST) Message-ID: <418F7EBB.4040104@cisco.com> Date: Mon, 08 Nov 2004 09:12:11 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach Subject: Re: [Sip] GRUU and sips References: <5.2.1.1.0.20040806093622.01542d40@pop.mcilink.com> <4113A68C.60704@cisco.com> <418D7220.80907@nostrum.com> In-Reply-To: <418D7220.80907@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA10415 Cc: Alan Johnston , Cullen Jennings , Paul Kyzivat , "sip@ietf.org" , Robert Sparks X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Content-Transfer-Encoding: quoted-printable Adam Roach wrote: > I'm getting in a bit late on this thread (sorry), but I've been under=20 > the impression for quite some time that sip:foo and sips:foo are=20 > *defined* to be the same resource under all circumstances. Section 19.1= =20 > of 3261 seems rather clear on this point: >=20 >> Any resource described by a SIP URI can be >> "upgraded" to a SIPS URI by just changing the scheme, if it is >> desired to communicate with that resource securely. >=20 >=20 >=20 > So, if we just hand out sip: URIs, then full 3261 implementations *know= *=20 > that they can use it with a sips: scheme and get the same resource.=20 Thanks for pointing this out; I had forgotten this was in there. I think=20 this at least implies that the two URIs, if they exist, point to the=20 same resource. But, it doesnt address questions like whether both have=20 to exist, or more specific questions about sips URI in GRUU. > Perhaps it is worth reiterating this point in the GRUU document, but it= =20 > seems like this is a non-problem. I think we need to say the following: If a sip and sips URI exist, they should point to the same resource Existence of sip doesn=92t imply sips and vice a versa If contact is sip, gruu is a sip URI, but the server creates the sips resource (i.e., it will accept and handle sips if it can do a secure connection) If the contact is sips, the gruu is sips, but the server does not create the sip resource Allows for sips only resources I'll be talking about this today in sip Thanks, Jonathan R. >=20 > /a >=20 >=20 > Paul Kyzivat wrote: >=20 >> Alan, >> >> Did you see my later message on this subject? >> >> As far as bid down, that is only a problem if the UAS isn't aware that= =20 >> it happened. Note that no matter what we say, bad guys can make the=20 >> change, so it isn't the change that matters, but how it is handled=20 >> along the path. >> >> In a direct connection, the UAS can see whether the r-uri is sip/sips.= =20 >> If the r-uri is sip it may conclude that the session isn't secure. For= =20 >> indirect connections it becomes the obligation of the proxies along=20 >> the path to use a sip r-uri if the connection can't be guaranteed=20 >> secure to them. >> >> My concern, beyond understanding how GRUU should work, is that a UAS=20 >> that wants to support both secure and insecure communication should=20 >> only need to make one registration. I have feeling people widely think= =20 >> things should work this way, but the standard isn't clear if/how this=20 >> can be achieved. >> >> Paul >> >> Alan Johnston wrote: >> >>> At 10:35 AM 7/27/2004 -0400, Paul Kyzivat wrote: >>> >>> >>>> Cullen Jennings wrote: >>>> >>>>> Sounds like a possibility. Can you think of a way where I do not=20 >>>>> have to >>>>> Register twice to get both a sip and sips URL? >>>>> Perhaps we should just say that is a proxy hands out a sip GRUU=20 >>>>> sip:foo then >>>>> sips:foo MUST also be a valid GRUU with the contact moved to sips=20 >>>>> from sip. >>>> >>>> >>>> >>>> >>>> That would rule out proxies that support gruu but not TLS. >>>> >>>> I think the converse might make more sense - if the proxy hands out=20 >>>> sips:foo then sip:foo MUST also be a valid GRUU. >>> >>> >>> >>> >>> Are you sure this is a good idea? Doesn't this open a bid down=20 >>> attack for the GRUU + grid dialog identifier described by Robert in=20 >>> his dialog reuse draft? >>> >>> Here's the example - I have a secure SIP dialog with you. You are=20 >>> using a secure SIP GRUU + grid dialog identifier. I pass this GRUU=20 >>> to another party, such as Robert with a Replaces header field in a=20 >>> REFER for the intent to transfer you to Robert. Robert changes the=20 >>> URI to a regular SIP GRUU and sends the INVITE with Replaces. If you= =20 >>> accept this, you have replaced a secure SIP session with an insecure=20 >>> session - not a good idea. Better for this transfer to fail if=20 >>> Robert tries to downgrade the security on the connection. >>> >>> I would say a sips:foo GRUU MUST NOT be valid as sip:foo to avoid=20 >>> this kind of attack. >>> >>> Thanks, >>> Alan Johnston >>> >>> >>>> Paul >>>> >>>>> If I get a sip GRUU, others can still use TLS to contact it. I=20 >>>>> would like to >>>>> make sure that the following case works: a UA only does UDP to=20 >>>>> it's proxy, >>>>> however, it want communications from outside the domain to use TLS=20 >>>>> to the >>>>> proxy. I think this works fine with what you are proposing. >>>>> On 7/23/04 12:27 PM, "Jonathan Rosenberg" = =20 >>>>> wrote: >>>>> >>>>>> The current GRUU spec says very little about interactions between=20 >>>>>> GRUU >>>>>> and sips, and I think its sufficiently non-obvious that a=20 >>>>>> discussion is >>>>>> warranted. >>>>>> >>>>>> Specifically, under what conditions would the registrar provide th= e >>>>>> client with a gruu that is a sips URI? >>>>>> >>>>>> I think the right answer here is that if teh Contact URI is a sips= =20 >>>>>> URI, >>>>>> then the registrar MUST return a gruu which is a sips URI. If the >>>>>> contact URI is not a sips URI, the registrar MUST NOT return a=20 >>>>>> sips URI. >>>>>> >>>>>> Other thoughts? >>>>>> >>>>>> Thanks, >>>>>> Jonathan R. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>> This list is for NEW development of the core SIP Protocol >>>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>>> Use sipping@ietf.org for new developments on the application of sip >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP 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 >> >> >=20 >=20 --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 8 09:48:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14583 for ; Mon, 8 Nov 2004 09:48:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRApK-0002uA-8y for sip-web-archive@ietf.org; Mon, 08 Nov 2004 09:49:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRASU-0004TK-W3; Mon, 08 Nov 2004 09:25:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRAI8-0001ZC-3r for sip@megatron.ietf.org; Mon, 08 Nov 2004 09:14:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10616 for ; Mon, 8 Nov 2004 09:14:41 -0500 (EST) Received: from amer-mta02.csc.com ([20.137.2.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRAIf-0001rw-UF for sip@ietf.org; Mon, 08 Nov 2004 09:15:18 -0500 Received: from csc.com (va-fch34.csc.com [20.6.39.227]) by amer-mta02.csc.com (Switch-3.1.6/Switch-3.1.0) with ESMTP id iA8EEYJL017946; Mon, 8 Nov 2004 09:14:34 -0500 (EST) Subject: RE: [Sip] Strict, Semi-Strict and Loose mode in RPH - not a good fit for ets and wps To: "James M. Polk" X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Janet P Gunn Date: Mon, 8 Nov 2004 09:13:01 -0500 X-MIMETrack: Serialize by Router on VA-FCH34/SRV/CSC(Release 6.0.3|September 26, 2003) at 11/08/2004 09:15:24 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: fonashp@ncs.gov, Darren E Pado , Saud Negash , mosleyv@ncs.gov, Richard F Kaczmarek , sip@ietf.org, nyquetek@msn.com, a.ephrath@ieee.org, Ken Carlberg , KENNETH.R.ERNEY@saic.com, suracif@ncs.gov, Dennis Q Berg X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 James said, >[JG]I am not as concerned about this case (valid namespace.valid value - >just not authorized). I would think this is of concern - as anyone (literally) can be in this group. I was thinking that it was of less concern because it is someone who already knows the valid namespace and value. But you are right, if it is someone who is randomly or systematically trying namespace/value combinations, we just told them "you got a hit". So I take it back about being less concerned. 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. ---------------------------------------------------------------------------------------- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 8 10:11:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17095 for ; Mon, 8 Nov 2004 10:11:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRBC7-0003b3-TJ for sip-web-archive@ietf.org; Mon, 08 Nov 2004 10:12:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRAwS-0003Ba-Ed; Mon, 08 Nov 2004 09:56:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRApf-0001M8-6x for sip@megatron.ietf.org; Mon, 08 Nov 2004 09:49:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14688 for ; Mon, 8 Nov 2004 09:49:21 -0500 (EST) Received: from [62.119.82.41] (helo=mailserver.hotsip.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRAqD-0002ue-Db for sip@ietf.org; Mon, 08 Nov 2004 09:49:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: [Sip] Join header (draft-ietf-sip-join-03.txt) unnecessary? Second attempt. Date: Mon, 8 Nov 2004 15:45:58 +0100 Message-ID: Thread-Topic: [Sip] Join header (draft-ietf-sip-join-03.txt) unnecessary? Second attempt. Thread-Index: AcS3dqfKJkX6MDJCQd6VWtE6hauJPwOJG3aA From: "Christian Jansson" To: X-Spam-Score: 0.2 (/) X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e Cc: rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0027131194==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb This is a multi-part message in MIME format. --===============0027131194== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C5A1.A8E4AFC8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4C5A1.A8E4AFC8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I got no answers on this question last time so I try again. =20 Is the approach described below so naive that no one even has the energy point out its weaknesses? Maybe it has already been discussed and deemed inadequate? =20 / Christian =20 =20 _____ =20 From: Christian Jansson=20 Sent: den 21 oktober 2004 16:05 To: sip@ietf.org Subject: [Sip] Join header (draft-ietf-sip-join-03.txt) unnecessary? [html] =20 Why do we need a Join header to be able to indicate that we want to join an ongoing session? Wouldn't it be enough to, for the party that wants to join, actually use the call-id for the session when sending the join-INVITE? Suppose A and B are in a session with the dialog identified by call-id=3D12345;tag=3DA;tag=3DB. If C now wants to join the session = he sends an INVITE to A or B with call-id=3D12345, from-tag=3DC, and an = empty to-tag. Wouldn't it make more sense that the 2 dialog-ids had some parts in common, that is the call-id, and something that distinguished them, that is the to and from tags? It would be much easier to find the session related messages as they would share the same call-id. =20 Have I missed some essential part of the Join header, or are we just adding something that we could already express easily with what we already have? =20 =20 / Christian Jansson, Hotsip ------_=_NextPart_001_01C4C5A1.A8E4AFC8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I got no answers on this question = last time so I try again.

 

Is the approach described below so = naive that no one even has the energy point out its weaknesses? Maybe it has = already been discussed and deemed inadequate?

 

/ = Christian

 

 

From: Christian Jansson
Sent: den 21 oktober 2004 = 16:05
To: sip@ietf.org
Subject: [Sip] Join = header (draft-ietf-sip-join-03.txt) unnecessary? = [html]

 

Why do we need a Join = header to be able to indicate that we want to join an ongoing session? Wouldn’t = it be enough to, for the party that wants to join, actually use the call-id = for the session when sending the join-INVITE? Suppose A and B are in a session = with the dialog identified by call-id=3D12345;tag=3DA;tag=3DB. If C now wants to = join the session he sends an INVITE to A or B with call-id=3D12345, from-tag=3DC, = and an empty to-tag. Wouldn’t it make more sense that the 2 dialog-ids = had some parts in common, that is the call-id, and something that distinguished = them, that is the to and from tags? It would be much easier to find the = session related messages as they would share the same = call-id.

 

Have I missed some = essential part of the Join header, or are we just adding something that we could already = express easily with what we already have?

 

 

/ Christian Jansson, Hotsip

------_=_NextPart_001_01C4C5A1.A8E4AFC8-- --===============0027131194== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0027131194==-- From sip-bounces@ietf.org Mon Nov 8 10:48:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22733 for ; Mon, 8 Nov 2004 10:48:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRBlE-0004mr-MH for sip-web-archive@ietf.org; Mon, 08 Nov 2004 10:48:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRBdH-0005UL-M4; Mon, 08 Nov 2004 10:40:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRBKM-0007xv-Dq for sip@megatron.ietf.org; Mon, 08 Nov 2004 10:21:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18361 for ; Mon, 8 Nov 2004 10:21:04 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRBKs-0003rF-BH for sip@ietf.org; Mon, 08 Nov 2004 10:21:41 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 08 Nov 2004 07:31:58 -0800 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iA8FK9nC007320; Mon, 8 Nov 2004 07:20:22 -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 HAA18537; Mon, 8 Nov 2004 07:20:13 -0800 (PST) Message-Id: <4.3.2.7.2.20041108091826.02713548@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 08 Nov 2004 09:20:17 -0600 To: Janet P Gunn From: "James M. Polk" Subject: RE: [Sip] Strict, Semi-Strict and Loose mode in RPH - not a good fit for ets and wps In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: fonashp@ncs.gov, Darren E Pado , Saud Negash , mosleyv@ncs.gov, Richard F Kaczmarek , sip@ietf.org, nyquetek@msn.com, a.ephrath@ieee.org, Ken Carlberg , KENNETH.R.ERNEY@saic.com, suracif@ncs.gov, Dennis Q Berg X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 At 09:13 AM 11/8/2004 -0500, Janet P Gunn wrote: >James said, > > >[JG]I am not as concerned about this case (valid namespace.valid value - > >just not authorized). > >I would think this is of concern - as anyone (literally) can be in this >group. > >I was thinking that it was of less concern because it is someone who >already knows the valid namespace and value. the RPH document is in the public domain - and we are having a fairly public discussion about it (and its ramifications). Curious eyes are probably reading this too. ;-) >But you are right, if it is someone who is randomly or systematically >trying namespace/value combinations, we just told them "you got a hit". >So I take it back about being less concerned. > >Janet 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 sip-bounces@ietf.org Mon Nov 8 10:54:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23368 for ; Mon, 8 Nov 2004 10:54:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRBqz-0004yQ-Jg for sip-web-archive@ietf.org; Mon, 08 Nov 2004 10:54:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRBe1-0005nb-AV; Mon, 08 Nov 2004 10:41:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRBPf-0000Wg-JZ for sip@megatron.ietf.org; Mon, 08 Nov 2004 10:26:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19034 for ; Mon, 8 Nov 2004 10:26:33 -0500 (EST) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRBQE-0003zP-EQ for sip@ietf.org; Mon, 08 Nov 2004 10:27:10 -0500 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id iA8FP110018072; Mon, 8 Nov 2004 15:25:01 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Mon, 8 Nov 2004 10:25:01 -0500 Message-ID: <7927C67249E4AD43BC05B539AF0D129801AF433E@stntexch04.cis.neustar.com> From: "Peterson, Jon" To: "'Adam Roach'" , Cullen Jennings Date: Mon, 8 Nov 2004 10:24:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: sip@ietf.org Subject: [Sip] RE: I-D ACTION:draft-ietf-sip-identity-03.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Thanks for the read, Adam. Some responses: > > Any discrepancies or violations MUST be reported to the user. > > > If I implement a proxy, it is not clear how I can satisfy > this second MUST. Agreed, that should be clarified. Furthermore, this is normative behavior about authorization decisions that will be made given the presence/absence of identity in a message, and technically, such authorization is outside the scope of the document. > A secondary sub-issue arises from the mechanism by which the proxy > decides to trust certificates. There is nothing in the current draft > that suggests, for example, that trusting self-signed domain certs for > the purposes of user authentication might be a Really Bad Idea. (Obvious > to security wonks, maybe not so much for your average implementor). Really, the text should be more specific about this, and it will be. While we shouldn't go so far as to identify particular root CAs that need to be supported, we intend for these to be publicly-verifiable certificates. > The > reason this ties into user interaction is that it becomes unclear how a > proxy should react if it receives a request; that request has an > authenticated identity asserted by a domain; and the root CA for the > domain's certificate is not known. With user applications, this is > typically handled by saying, "I don't know who blackhelicopers.org is, > but they signed this certificate. Click here to examine the cert > yourself, and let me know if I should accept this cert as invalid, > temporarily valid, or permanently valid." When the check is performed by > a proxy, such interaction is really quite difficult. The best a proxy > can do is reject the request with a 428 (which seems a bit extreme), or > let it through (in which case the proxy's check serves little > to no purpose) > > So, I suggest that the draft probably needs a little more text around > proxy handling of requests; further, given the all-or-nothing nature of > proxy validation of authenticated identity, we might consider > discouraging its use in favor of client validation. > Clearly, client validation is a superior option, yes. But, I do think there are some authorization policies that are best implemented at a domain level, and it is reasonable for intermediaries to instantiate those policies rather than receiving user agents. We do need to solve for the case of how that authorization decision will be executed, but as I've said, authZ should be outside the scope of this draft for the most part. The only sort of authZ action that we could reasonably expect an intermediary to perform is to reject the request in some fashion, as you suggest. > The second issue is a tiny nit in that the current draft doesn't specify > what to do if you receive a request with an Identity-Info header which > contains a URI with a scheme other than sips: or https:. Presumably, > recipients should 428 such requests? 400? Yeah, I think I'm going to relax that restriction for other reasons (there is at least one other URI type, "cid:", that I think would be useful here). Ultimately, I think that if you can dereference the URI and acquire the necessary keying material, you shouldn't complain. There should be an error response that says, "I can't find dereference that URI" (maybe because I don't support the scheme, maybe because the link is broken, etc). We know we also want to describe the case where the root CA is unsupported (and subsumed under that, the possibility that the cert used to generate the identity digest sig is self-signed). Identifying response codes for these conditions is needed, I agree. Jon Peterson NeuStar, Inc. > /a > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 8 11:06:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24580 for ; Mon, 8 Nov 2004 11:06:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRC2T-0005J1-0J for sip-web-archive@ietf.org; Mon, 08 Nov 2004 11:06:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRBew-00066y-Om; Mon, 08 Nov 2004 10:42:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRBTy-0002DL-D7 for sip@megatron.ietf.org; Mon, 08 Nov 2004 10:31:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19806 for ; Mon, 8 Nov 2004 10:30:58 -0500 (EST) Received: from figas.ekabal.com ([157.22.13.42]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRBUS-00048U-Nm for sip@ietf.org; Mon, 08 Nov 2004 10:31:36 -0500 Received: from [130.129.134.12] ([130.129.134.12]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id iA8FUhC16830; Mon, 8 Nov 2004 07:30:43 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Message-Id: <1A4ED203-319B-11D9-B5BC-000D93C60450@ekabal.com> From: Rohan Mahy Subject: Re: [Sip] Join header (draft-ietf-sip-join-03.txt) unnecessary? Second attempt. Date: Mon, 8 Nov 2004 10:30:21 -0500 To: "Christian Jansson" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.5 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Cc: sip@ietf.org, Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1252610864==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 --===============1252610864== Content-Type: multipart/alternative; boundary=Apple-Mail-1--785946357 --Apple-Mail-1--785946357 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi, Sorry for the delayed response. Based on our experiences with Replaces, Dan Petrie, Alan Johnston,=20 Robert Sparks, myself and other members of the working group where able=20= to point out significant problems with reusing dialog identifiers for=20 multiple dialogs. The simplest example is that a Replaces header sent=20= to a locally mixed conference might match multiple dialogs. It is then=20= impossible to replace a single (specific) dialog. Also Join allows a=20 user agent to redirect a Join request to a conference in a much more=20 natural way. Hope this helps. In any case, Join is now RFC3911. thanks, -rohan On Nov 8, 2004, at 9:45, Christian Jansson wrote: > I got no answers on this question last time so I try again. > > =A0 > > Is the approach described below so naive that no one even has the=20 > energy point out its weaknesses? Maybe it has already been discussed=20= > and deemed inadequate? > > =A0 > > / Christian > > =A0 > > =A0 > > > From: Christian Jansson > Sent: den 21 oktober 2004 16:05 > To: sip@ietf.org > Subject: [Sip] Join header (draft-ietf-sip-join-03.txt) unnecessary?=20= > [html] > > =A0 > > Why do we need a Join header to be able to indicate that we want to=20 > join an ongoing session? Wouldn=92t it be enough to, for the party = that=20 > wants to join, actually use the call-id for the session when sending=20= > the join-INVITE? Suppose A and B are in a session with the dialog=20 > identified by call-id=3D12345;tag=3DA;tag=3DB. If C now wants to join = the=20 > session he sends an INVITE to A or B with call-id=3D12345, from-tag=3DC,= =20 > and an empty to-tag. Wouldn=92t it make more sense that the 2 = dialog-ids=20 > had some parts in common, that is the call-id, and something that=20 > distinguished them, that is the to and from tags? It would be much=20 > easier to find the session related messages as they would share the=20 > same call-id. > > =A0 > > Have I missed some essential part of the Join header, or are we just=20= > adding something that we could already express easily with what we=20 > already have? > > =A0 > > =A0 > > / Christian Jansson, Hotsip --Apple-Mail-1--785946357 Content-Type: text/enriched; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi, Sorry for the delayed response. Based on our experiences with Replaces, Dan Petrie, Alan Johnston, Robert Sparks, myself and other members of the working group where able to point out significant problems with reusing dialog identifiers for multiple dialogs. The simplest example is that a Replaces header sent to a locally mixed conference might match multiple dialogs. It is then impossible to replace a single (specific) dialog. Also Join allows a user agent to redirect a Join request to a conference in a much more natural way. Hope this helps. In any case, Join is now RFC3911. thanks, -rohan On Nov 8, 2004, at 9:45, Christian Jansson wrote: = Arial0000,0000,8080I got no answers on this question last time so I try = again. = Arial0000,0000,8080=A0 = Arial0000,0000,8080Is the approach described below so naive that no one even has the energy point out its weaknesses? Maybe it has already been discussed and deemed inadequate? = Arial0000,0000,8080=A0 = Arial0000,0000,8080/ Christian = Arial0000,0000,8080=A0 = Arial0000,0000,8080=A0 = TahomaFrom:<= /fontfamily>Tahoma Christian Jansson = TahomaSent:<= /fontfamily>Tahoma den 21 oktober 2004 16:05 = TahomaTo:Tahoma sip@ietf.org = TahomaSubject:Tahoma [Sip] Join header (draft-ietf-sip-join-03.txt) unnecessary? = [html] Times New = Roman=A0 ArialWhy do we need a Join header to be able to indicate that we want to join an ongoing session? Wouldn=92t it be enough to, for the party that wants to join, actually use the call-id for the session when sending the join-INVITE? Suppose A and B are in a session with the dialog identified by call-id=3D12345;tag=3DA;tag=3DB. If C now wants to join the session he = sends an INVITE to A or B with call-id=3D12345, from-tag=3DC, and an empty to-tag. Wouldn=92t it make more sense that the 2 dialog-ids had some parts in common, that is the call-id, and something that distinguished them, that is the to and from tags? It would be much easier to find the session related messages as they would share the same = call-id. = Arial=A0 ArialHave I missed some essential part of the Join header, or are we just adding something that we could already express easily with what we already = have? = Arial=A0 = Arial=A0 Arial/ Christian Jansson, Hotsip = --Apple-Mail-1--785946357-- --===============1252610864== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1252610864==-- From sip-bounces@ietf.org Mon Nov 8 11:06:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24710 for ; Mon, 8 Nov 2004 11:06:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRC3I-0005KI-R3 for sip-web-archive@ietf.org; Mon, 08 Nov 2004 11:07:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRBey-00067J-Gj; Mon, 08 Nov 2004 10:42:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRBUN-0002Jn-Rj for sip@megatron.ietf.org; Mon, 08 Nov 2004 10:31:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19872 for ; Mon, 8 Nov 2004 10:31:22 -0500 (EST) Received: from amer-mta01.csc.com ([20.137.2.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRBUs-00049u-PO for sip@ietf.org; Mon, 08 Nov 2004 10:32:00 -0500 Received: from csc.com (va-fch34.csc.com [20.6.39.227]) by amer-mta01.csc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id iA8FV7mQ019536; Mon, 8 Nov 2004 10:31:07 -0500 (EST) Subject: RE: [Sip] Strict, Semi-Strict and Loose mode in RPH - not a good fit for ets and wps To: "James M. Polk" X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Janet P Gunn Date: Mon, 8 Nov 2004 10:29:32 -0500 X-MIMETrack: Serialize by Router on VA-FCH34/SRV/CSC(Release 6.0.3|September 26, 2003) at 11/08/2004 10:31:56 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: fonashp@ncs.gov, Darren E Pado , Saud Negash , mosleyv@ncs.gov, Richard F Kaczmarek , sip@ietf.org, nyquetek@msn.com, a.ephrath@ieee.org, Ken Carlberg , KENNETH.R.ERNEY@saic.com, suracif@ncs.gov, Dennis Q Berg X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac OK, to turn it around. If "curious eyes" already can know the valid namespace/value combinations, simply by navigating the ietf site, why bother to hide it in the protocol messages? At least for the "published" namespaces. ---------------------------------------------------------------------------------------- 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. ---------------------------------------------------------------------------------------- "James M. Polk" cc: a.ephrath@ieee.org, "Ken Carlberg" , Darren E Pado/FED/CSC@CSC, Dennis Q Berg/FED/CSC@CSC, fonashp@ncs.gov, 11/08/2004 10:20 KENNETH.R.ERNEY@saic.com, mosleyv@ncs.gov, nyquetek@msn.com, Richard F AM Kaczmarek/FED/SC/CSC@CSC, Saud Negash/FED/CSC@CSC, sip@ietf.org, suracif@ncs.gov Subject: RE: [Sip] Strict, Semi-Strict and Loose mode in RPH - not a good fit for ets and wps At 09:13 AM 11/8/2004 -0500, Janet P Gunn wrote: >James said, > > >[JG]I am not as concerned about this case (valid namespace.valid value - > >just not authorized). > >I would think this is of concern - as anyone (literally) can be in this >group. > >I was thinking that it was of less concern because it is someone who >already knows the valid namespace and value. the RPH document is in the public domain - and we are having a fairly public discussion about it (and its ramifications). Curious eyes are probably reading this too. ;-) >But you are right, if it is someone who is randomly or systematically >trying namespace/value combinations, we just told them "you got a hit". >So I take it back about being less concerned. > >Janet 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 sip-bounces@ietf.org Mon Nov 8 12:08:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02215 for ; Mon, 8 Nov 2004 12:08:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRD0d-0007KF-8v for sip-web-archive@ietf.org; Mon, 08 Nov 2004 12:08:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRCqH-0006Uk-Iv; Mon, 08 Nov 2004 11:58:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRCVZ-000575-Pl for sip@megatron.ietf.org; Mon, 08 Nov 2004 11:36:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28092 for ; Mon, 8 Nov 2004 11:36:43 -0500 (EST) Received: from [62.119.82.41] (helo=mailserver.hotsip.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRCW8-0006Ey-Bd for sip@ietf.org; Mon, 08 Nov 2004 11:37:21 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Join header (draft-ietf-sip-join-03.txt) unnecessary? Second attempt. Date: Mon, 8 Nov 2004 17:33:28 +0100 Message-ID: Thread-Topic: [Sip] Join header (draft-ietf-sip-join-03.txt) unnecessary? Second attempt. Thread-Index: AcTFp5SjhMfP9/OBSTapWQQwo/5T0AAAOcaw From: "Christian Jansson" To: "Rohan Mahy" X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: quoted-printable I saw that the draft had made it to RFC so in some way I am too late, = but I still do not see the advantages with Join. "The simplest example is that a Replaces header sent to a locally mixed = conference might match multiple dialogs" Is that an advantage or disadvantage of Join vs the model I proposed?=20 "It is then impossible to replace a single (specific) dialog" But wouldn't that be possible with the proposal I wrote also? I think = so. Do you have any reference to mailing-list discussions where you = realized that what was in RFC3261 was not enough? I thought it would be good to reuse the elements that are in 3261. In a = way dialogs could be seen to be coupled to a call-id in a heretical = view. In the case below UA:A has a call containing 2 dialogs with dialog-ids = (1234:A1:BB) and (1234:A2:CC). If one would like to use Replaces to = replace one of the dialogs then simply target one of them using the = dialog id. To me Join seems to invent the wheel again. UA:A Call-id: 1234 | | local-tag=3DA1 local-tag=3DA2 remote-tag=3DBB remote-tag=3DCC In this model it is very easy to see that the two dialogs are connected, = as they both share the call-id part of their dialog-id. I think that is = a very attractive feature. Now if we use Join instead do the same thing, we would get some state = above this (conference?) that relates one dialog with another dialog = with a completely different set of identifiers. It also makes the = call-id identifier more or less useless except for the case when forking = gives back multiple answers, which probably won't happen under normal = operation. Does this state above dialogs and call-ids have a name = defined anywhere?=20 / Christian Jansson ________________________________________ From: Rohan Mahy [mailto:rohan@ekabal.com]=20 Sent: Monday, November 08, 2004 4:30 PM To: Christian Jansson Cc: Rohan Mahy; sip@ietf.org Subject: Re: [Sip] Join header (draft-ietf-sip-join-03.txt) unnecessary? = Second attempt. Hi,=20 Sorry for the delayed response.=20 Based on our experiences with Replaces, Dan Petrie, Alan Johnston, = Robert Sparks, myself and other members of the working group where able = to point out significant problems with reusing dialog identifiers for = multiple dialogs. The simplest example is that a Replaces header sent to = a locally mixed conference might match multiple dialogs. It is then = impossible to replace a single (specific) dialog. Also Join allows a = user agent to redirect a Join request to a conference in a much more = natural way. Hope this helps. In any case, Join is now RFC3911.=20 thanks,=20 -rohan=20 On Nov 8, 2004, at 9:45, Christian Jansson wrote:=20 I got no answers on this question last time so I try again.=20 =A0=20 Is the approach described below so naive that no one even has the energy = point out its weaknesses? Maybe it has already been discussed and deemed = inadequate?=20 =A0=20 / Christian=20 =A0=20 =A0=20 From: Christian Jansson=20 Sent: den 21 oktober 2004 16:05=20 To: sip@ietf.org=20 Subject: [Sip] Join header (draft-ietf-sip-join-03.txt) unnecessary? = [html]=20 =A0=20 Why do we need a Join header to be able to indicate that we want to join = an ongoing session? Wouldn't it be enough to, for the party that wants = to join, actually use the call-id for the session when sending the = join-INVITE? Suppose A and B are in a session with the dialog identified = by call-id=3D12345;tag=3DA;tag=3DB. If C now wants to join the session = he sends an INVITE to A or B with call-id=3D12345, from-tag=3DC, and an = empty to-tag. Wouldn't it make more sense that the 2 dialog-ids had some = parts in common, that is the call-id, and something that distinguished = them, that is the to and from tags? It would be much easier to find the = session related messages as they would share the same call-id.=20 =A0=20 Have I missed some essential part of the Join header, or are we just = adding something that we could already express easily with what we = already have?=20 =A0=20 =A0=20 / Christian Jansson, Hotsip=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 8 12:48:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06354 for ; Mon, 8 Nov 2004 12:48:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRDde-0008P5-C3 for sip-web-archive@ietf.org; Mon, 08 Nov 2004 12:49:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRDW1-0001Xk-RP; Mon, 08 Nov 2004 12:41:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRDIF-0006wt-F2 for sip@megatron.ietf.org; Mon, 08 Nov 2004 12:27:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04130 for ; Mon, 8 Nov 2004 12:27:00 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRDIf-0007om-Bc for sip@ietf.org; Mon, 08 Nov 2004 12:27:39 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 08 Nov 2004 12:26:22 -0500 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iA8HQK9D006810; Mon, 8 Nov 2004 12:26:21 -0500 (EST) Received: from cisco.com (dhcp-64-102-209-115.cisco.com [64.102.209.115]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BDF65831; Mon, 8 Nov 2004 09:26:18 -0800 (PST) Message-ID: <418FAC3A.5030802@cisco.com> Date: Mon, 08 Nov 2004 12:26:18 -0500 From: Kevin Lingle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] mib-08 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit hi cullen, we had a relatively small number of outstanding issues to still resolve and were trying to get a -09 rev out a couple of weeks back. we didn't make that target because while working the outstanding issues, we also tried to accommodate a request to enhance user agent information. i don't, think we should try and include that in the initial offering of the user agent mib module. i think jean-francois is possibly in agreement with that now. he was going to take a crack at the issue but didn't have time yet. thus we haven't published rev -09 but hope to soon. i don't have any time to devote to the new issue of additional user agent information. so i'd like to leave that for the future. the delta's between -08 and -09 shouldn't be vast.... relative to the deltas between -07 and -08 ;) i think the "bunch of people" you refer to should be the wglc reviewers. i don't mind others also reviewing, but i don't want this to become yet another wglc on this draft (we've had two in as many years!). we need to move the I-D forward so we can get a RFC that can get some implementation experience. kevin Cullen Jennings wrote: > I tired to read this whole thing again and it made my head want to explode - > I think getting a bunch of people to read it again would be really good. > There has been some nice work done on it since the previous rev. > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 8 13:06:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07711 for ; Mon, 8 Nov 2004 13:06:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRDug-0000Mg-MY for sip-web-archive@ietf.org; Mon, 08 Nov 2004 13:06:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRDnX-0004YN-Fl; Mon, 08 Nov 2004 12:59:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRDhE-0003ex-L9 for sip@megatron.ietf.org; Mon, 08 Nov 2004 12:52:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06795 for ; Mon, 8 Nov 2004 12:52:49 -0500 (EST) Received: from amer-mta02.csc.com ([20.137.2.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRDho-00005t-Se for sip@ietf.org; Mon, 08 Nov 2004 12:53:29 -0500 Received: from csc.com (va-fch34.csc.com [20.6.39.227]) by amer-mta02.csc.com (Switch-3.1.6/Switch-3.1.0) with ESMTP id iA8Hqktc018246; Mon, 8 Nov 2004 12:52:46 -0500 (EST) Subject: RE: [Sip] Strict, Semi-Strict and Loose mode in RPH - not a good fit for ets and wps To: "James M. Polk" X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Janet P Gunn Date: Mon, 8 Nov 2004 12:51:10 -0500 X-MIMETrack: Serialize by Router on VA-FCH34/SRV/CSC(Release 6.0.3|September 26, 2003) at 11/08/2004 12:53:35 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: fonashp@ncs.gov, Darren E Pado , Saud Negash , mosleyv@ncs.gov, Richard F Kaczmarek , sip@ietf.org, nyquetek@msn.com, a.ephrath@ieee.org, Ken Carlberg , KENNETH.R.ERNEY@saic.com, suracif@ncs.gov, Dennis Q Berg X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 James said --- > > 2 SIP element ignores a namespace it does not recognize (loose) To this, remember the ID does not say to "fail" the call, just that Request. This is one way to inform the calling UAC to know it included a namespace or priority value that was not recognizable (meaning not ets.0/1/2/3/4 or wps.0/1/2/3/4). There is no way to inform the UAC of this issue within the SIP Request (with the bad namespace.priority-value) without failing the request. Meaning, there can be no preferential treatment without the sending element being told so. SIP doesn't have a "pass, but this wasn't a good choice" provisional response like other protocols. To the user, they might not notice several SIP Request failures, the person is merely waiting for the call to be set up (still under a second). --- OK, please educate me. If it "fails" that request, but doesn't "fail" the call, does that mean that the UAC resends the request without the RPH? If that is what it means, then, for a call which originates in a SIP/IP domain, but goes to the PSTN, it would reach the PSTN gateway with no indication that it was entitled to special treatment in the PSTN. While that is better than failing the call, it still isn't the desired behavior. If there is a way that the SIP element can "fail the request but not the call", AND make sure that the appropriate RPH namespace and value (and authentication) get to the PSTN gateway, then it might be OK. 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. ---------------------------------------------------------------------------------------- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 8 13:36:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10592 for ; Mon, 8 Nov 2004 13:36:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRENr-000171-15 for sip-web-archive@ietf.org; Mon, 08 Nov 2004 13:36:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRECQ-0001Zk-SC; Mon, 08 Nov 2004 13:25:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRE6M-0007ua-M8 for sip@megatron.ietf.org; Mon, 08 Nov 2004 13:18:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08881 for ; Mon, 8 Nov 2004 13:18:47 -0500 (EST) Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRE6x-0000ib-2z for sip@ietf.org; Mon, 08 Nov 2004 13:19:27 -0500 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iA8IGwEr022567 for ; Mon, 8 Nov 2004 13:16:58 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iA8IElEr019730 for ; Mon, 8 Nov 2004 13:15:35 -0500 (EST) 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] mib-08 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Date: Mon, 8 Nov 2004 20:16:25 +0200 Message-ID: Thread-Topic: [Sip] mib-08 Thread-Index: AcTFu+9qv6mY+yCrQBmeiosoYksSNAAAsQYw From: "Romascanu, Dan \(Dan\)" To: "Kevin Lingle" , "Cullen Jennings" X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable I agree with Kevin. At this point in time we should not change the scope = of the SIP MIB work, but rather focus on completing this phase of the = work, in the framework already agreed. This does not mean that more eyes = to read and comment on the MIB would do harm, quite the contrary - but = changes should focus on fixing problems, not introducing new items.=20 After this phase is completed, the WG may be open to discussing possible = extensions which can be introduced in supplementary SIP MIB modules.=20 Regards, Dan > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On=20 > Behalf Of Kevin Lingle > Sent: 08 November, 2004 7:26 PM > To: Cullen Jennings > Cc: sip@ietf.org > Subject: Re: [Sip] mib-08 >=20 >=20 > hi cullen, >=20 > we had a relatively small number of outstanding issues to > still resolve and were trying to get a -09 rev out a couple > of weeks back. we didn't make that target because while working > the outstanding issues, we also tried to accommodate a request > to enhance user agent information. >=20 > i don't, think we should try and include that in the initial > offering of the user agent mib module. i think jean-francois > is possibly in agreement with that now. he was going to take > a crack at the issue but didn't have time yet. thus we haven't > published rev -09 but hope to soon. i don't have any time to > devote to the new issue of additional user agent information. > so i'd like to leave that for the future. >=20 > the delta's between -08 and -09 shouldn't be vast.... relative > to the deltas between -07 and -08 ;) i think the "bunch of people" > you refer to should be the wglc reviewers. i don't mind others > also reviewing, but i don't want this to become yet another wglc on > this draft (we've had two in as many years!). we need to move the > I-D forward so we can get a RFC that can get some implementation > experience. >=20 > kevin >=20 > Cullen Jennings wrote: > > I tired to read this whole thing again and it made my head=20 > want to explode - > > I think getting a bunch of people to read it again would be=20 > really good. > > There has been some nice work done on it since the previous rev. > >=20 > >=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 >=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 sip-bounces@ietf.org Mon Nov 8 14:10:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15435 for ; Mon, 8 Nov 2004 14:10:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CREuh-00029A-9p for sip-web-archive@ietf.org; Mon, 08 Nov 2004 14:10:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CREbX-0007b8-Id; Mon, 08 Nov 2004 13:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CREOZ-0004h0-L3 for sip@megatron.ietf.org; Mon, 08 Nov 2004 13:37:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10799 for ; Mon, 8 Nov 2004 13:37:36 -0500 (EST) Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CREP7-000198-1J for sip@ietf.org; Mon, 08 Nov 2004 13:38:16 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA8IbTF23108; Mon, 8 Nov 2004 20:37:29 +0200 (EET) X-Scanned: Mon, 8 Nov 2004 20:37:13 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id iA8IbDAD031455; Mon, 8 Nov 2004 20:37:13 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 000U0VfH; Mon, 08 Nov 2004 20:32:23 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA8IWNS12743; Mon, 8 Nov 2004 20:32:23 +0200 (EET) Received: from [130.129.134.192] ([10.241.59.18]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 8 Nov 2004 20:32:23 +0200 Message-ID: <418FBBB5.2090202@nokia.com> Date: Mon, 08 Nov 2004 13:32:21 -0500 From: Aki Niemi User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: SIP WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Nov 2004 18:32:23.0255 (UTC) FILETIME=[49E87E70:01C4C5C1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: jon.peterson@neustar.biz Subject: [Sip] Comments on sip-identity-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Hi, I read the draft and it looks reasonable. One comment though: in section 6 there is a recommended policy which instructs matching the username asserted in the Digest authentication to the From header field. I think this needs clarification. Someone might read it to mean the contents of the username param is being matched, which I'm assuming is not the intention. Rather, it should say that the account's URI for which the username/passwd is for is matched against the URI in the From. In addition, the section contains text about aliases and matching those usernames, where this passage was quite hard to parse: Accordingly, provided the authentication service is aware of the relationships between these accounts, it might allow a user providing credentials for one account to assert a username associated with another account controlled by the user name. I think I got the idea, but rephrasing it would be in order. 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 sip-bounces@ietf.org Mon Nov 8 14:14:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16094 for ; Mon, 8 Nov 2004 14:14:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CREyk-0002I2-1m for sip-web-archive@ietf.org; Mon, 08 Nov 2004 14:15:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CREbs-0007ma-QI; Mon, 08 Nov 2004 13:51:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRESa-0005Zf-Hs for sip@megatron.ietf.org; Mon, 08 Nov 2004 13:41:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11168 for ; Mon, 8 Nov 2004 13:41:47 -0500 (EST) Received: from amer-mta02.csc.com ([20.137.2.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRETB-0001Gx-7R for sip@ietf.org; Mon, 08 Nov 2004 13:42:25 -0500 Received: from csc.com (va-fch34.csc.com [20.6.39.227]) by amer-mta02.csc.com (Switch-3.1.6/Switch-3.1.0) with ESMTP id iA8IewWu007379; Mon, 8 Nov 2004 13:41:33 -0500 (EST) Subject: RE: [Sip] Strict, Semi-Strict and Loose mode in RPH - not a good fit for ets and wps To: "James M. Polk" X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Janet P Gunn Date: Mon, 8 Nov 2004 13:37:27 -0500 X-MIMETrack: Serialize by Router on VA-FCH34/SRV/CSC(Release 6.0.3|September 26, 2003) at 11/08/2004 01:42:22 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: fonashp@ncs.gov, Darren E Pado , Saud Negash , mosleyv@ncs.gov, Richard F Kaczmarek , sip@ietf.org, nyquetek@msn.com, a.ephrath@ieee.org, Ken Carlberg , KENNETH.R.ERNEY@saic.com, suracif@ncs.gov, Dennis Q Berg X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 James said: --- > > 4 SIP messages that include the RPH with the ets or wps namespaces should > > include the authorization header (or equivalent mechanism) (semi-strict) this should be self evident in public networks.... --- Agree- my point was that this is part of "semi-strict" that IS desirable, even if we want the treatment to be "loose" in terms of treatment of an unrecognized namespace. Consider this policy for a specific namespace - If the SIP element doesn't recognize the namespace , it ignores the header (doesn't give any special treatment here, but passes it on if appropriate- e.g., to a signalling gateway) - If the SIP element recognizes the namespace, but there is an invalid value, the request (and the call) are rejected - If the SIP element recognizes the namespace, and the value, but the authentication header doesn't pass muster, the request (and the call) are rejected - If the SIP element recognizes the namespace, and the value, AND authentication header is "good", then the request (and the call) get special treatment here, and the RPH is passed on if appropriate- e.g., to a signalling gateway. Is this policy permitted by the current draft? My reading is that this policy is not permitted. Section 4.3.2 says: "When handling requests with unknown namespaces or priority values, elements can operate in one of three modes, "strict", "semi-strict" and "loose"." and "If the request includes a 'Require' header field with the 'Resource-Priority' option tag, a UAS MUST follow the strict or semi-strict mode rules, otherwise UAS and proxies MUST operate in loose mode." Since the policy described above does not fit "strict", "semi-strict" or "loose", it would seem to be forbidden. Am I missing something? 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. ---------------------------------------------------------------------------------------- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 8 14:22:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17223 for ; Mon, 8 Nov 2004 14:22:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRF72-0002d4-0t for sip-web-archive@ietf.org; Mon, 08 Nov 2004 14:23:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRF1s-0006xR-Cx; Mon, 08 Nov 2004 14:18:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CREdU-0000Z9-9H for sip@megatron.ietf.org; Mon, 08 Nov 2004 13:53:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12389 for ; Mon, 8 Nov 2004 13:53:02 -0500 (EST) Received: from figas.ekabal.com ([157.22.13.42]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CREe1-0001bc-5J for sip@ietf.org; Mon, 08 Nov 2004 13:53:40 -0500 Received: from [130.129.134.12] ([130.129.134.12]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id iA8IqtC19921; Mon, 8 Nov 2004 10:52:55 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <58E43772-31B7-11D9-B5BC-000D93C60450@ekabal.com> Content-Transfer-Encoding: quoted-printable From: Rohan Mahy Subject: Re: [Sip] Join header (draft-ietf-sip-join-03.txt) unnecessary? Second attempt. Date: Mon, 8 Nov 2004 13:52:32 -0500 To: "Christian Jansson" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Content-Transfer-Encoding: quoted-printable On Nov 8, 2004, at 11:33, Christian Jansson wrote: > I saw that the draft had made it to RFC so in some way I am too late,=20= > but I still do not see the advantages with Join. At this point, we have a standard track document that was reviewed by=20 the WG, expresses a consensus approach, technically works, and has a=20 handful of implementations. I don't think there is much value=20 rehashing this issue. > "The simplest example is that a Replaces header sent to a locally=20 > mixed conference might match multiple dialogs" > Is that an advantage or disadvantage of Join vs the model I proposed? > > "It is then impossible to replace a single (specific) dialog" > But wouldn't that be possible with the proposal I wrote also? I think=20= > so. Do you have any reference to mailing-list discussions where you=20 > realized that what was in RFC3261 was not enough? > > I thought it would be good to reuse the elements that are in 3261. In=20= > a way dialogs could be seen to be coupled to a call-id in a heretical=20= > view. > > In the case below UA:A has a call containing 2 dialogs with dialog-ids=20= > (1234:A1:BB) and (1234:A2:CC). If one would like to use Replaces to=20 > replace one of the dialogs then simply target one of them using the=20 > dialog id. To me Join seems to invent the wheel again. You can't use the fact that the call-id is the same to assume that two=20= calls are part of the same conversation. For example, when forking an=20= INVITE for video or text, it is quite reasonable to get multiple 200s=20 (and multiple independent sessions) which stay up. These are most=20 likely not part of the same conversation. thanks, -rohan > UA:A > > Call-id: 1234 > | | > local-tag=3DA1 local-tag=3DA2 > remote-tag=3DBB remote-tag=3DCC > > In this model it is very easy to see that the two dialogs are=20 > connected, as they both share the call-id part of their dialog-id. I=20= > think that is a very attractive feature. > > Now if we use Join instead do the same thing, we would get some state=20= > above this (conference?) that relates one dialog with another dialog=20= > with a completely different set of identifiers. It also makes the=20 > call-id identifier more or less useless except for the case when=20 > forking gives back multiple answers, which probably won't happen under=20= > normal operation. Does this state above dialogs and call-ids have a=20 > name defined anywhere? > > > / Christian Jansson > > > ________________________________________ > From: Rohan Mahy [mailto:rohan@ekabal.com] > Sent: Monday, November 08, 2004 4:30 PM > To: Christian Jansson > Cc: Rohan Mahy; sip@ietf.org > Subject: Re: [Sip] Join header (draft-ietf-sip-join-03.txt)=20 > unnecessary? Second attempt. > > Hi, > > Sorry for the delayed response. > > Based on our experiences with Replaces, Dan Petrie, Alan Johnston,=20 > Robert Sparks, myself and other members of the working group where=20 > able to point out significant problems with reusing dialog identifiers=20= > for multiple dialogs. The simplest example is that a Replaces header=20= > sent to a locally mixed conference might match multiple dialogs. It is=20= > then impossible to replace a single (specific) dialog. Also Join=20 > allows a user agent to redirect a Join request to a conference in a=20 > much more natural way. Hope this helps. In any case, Join is now=20 > RFC3911. > > thanks, > -rohan > > On Nov 8, 2004, at 9:45, Christian Jansson wrote: > > I got no answers on this question last time so I try again. > > =A0 > > Is the approach described below so naive that no one even has the=20 > energy point out its weaknesses? Maybe it has already been discussed=20= > and deemed inadequate? > > =A0 > > / Christian > > =A0 > > =A0 > > From: Christian Jansson > Sent: den 21 oktober 2004 16:05 > To: sip@ietf.org > Subject: [Sip] Join header (draft-ietf-sip-join-03.txt) unnecessary?=20= > [html] > > =A0 > > Why do we need a Join header to be able to indicate that we want to=20 > join an ongoing session? Wouldn't it be enough to, for the party that=20= > wants to join, actually use the call-id for the session when sending=20= > the join-INVITE? Suppose A and B are in a session with the dialog=20 > identified by call-id=3D12345;tag=3DA;tag=3DB. If C now wants to join = the=20 > session he sends an INVITE to A or B with call-id=3D12345, from-tag=3DC,= =20 > and an empty to-tag. Wouldn't it make more sense that the 2 dialog-ids=20= > had some parts in common, that is the call-id, and something that=20 > distinguished them, that is the to and from tags? It would be much=20 > easier to find the session related messages as they would share the=20 > same call-id. > > =A0 > > Have I missed some essential part of the Join header, or are we just=20= > adding something that we could already express easily with what we=20 > already have? > > =A0 > > =A0 > > / Christian Jansson, Hotsip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 8 14:44:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19628 for ; Mon, 8 Nov 2004 14:44:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRFS7-0003Gw-M5 for sip-web-archive@ietf.org; Mon, 08 Nov 2004 14:45:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRF34-0007rh-Vl; Mon, 08 Nov 2004 14:19:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CREz9-0005mi-6i for sip@megatron.ietf.org; Mon, 08 Nov 2004 14:15:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16241 for ; Mon, 8 Nov 2004 14:15:25 -0500 (EST) Received: from amer-mta02.csc.com ([20.137.2.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CREzh-0002Km-8l for sip@ietf.org; Mon, 08 Nov 2004 14:16:04 -0500 Received: from csc.com (va-fch34.csc.com [20.6.39.227]) by amer-mta02.csc.com (Switch-3.1.6/Switch-3.1.0) with ESMTP id iA8JFHVE015080; Mon, 8 Nov 2004 14:15:17 -0500 (EST) Subject: RE: [Sip] Strict, Semi-Strict and Loose mode in RPH - not a good fit for ets and wps To: "James M. Polk" X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Janet P Gunn Date: Mon, 8 Nov 2004 14:13:43 -0500 X-MIMETrack: Serialize by Router on VA-FCH34/SRV/CSC(Release 6.0.3|September 26, 2003) at 11/08/2004 02:16:06 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: fonashp@ncs.gov, Darren E Pado , Saud Negash , mosleyv@ncs.gov, Richard F Kaczmarek , sip@ietf.org, nyquetek@msn.com, a.ephrath@ieee.org, Ken Carlberg , KENNETH.R.ERNEY@saic.com, suracif@ncs.gov, Dennis Q Berg X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 James said: ___ > > 5 Precedence (queueing) is generally the means of providing priority, but > > exemption from network management controls, for instance call admission > > within an IP domain, when a "regular" call would not be admitted, is also > > needed. Pre-emption is not used. (semi-strict "plus more") I do not understand what you have written above, can you rephrase please? ___ OK. I'll try again (and I combined two different cases, which didn't help the clarity). Section 7 says "The ets and wps namespaces operate with preferential treatment but without preemption. These namespaces operate under a policy of provide preferential treatment to higher relative priority requests instead of processing lower relative priority requests. Messages are not preempted, or deleted, except under extreme loads in which all available processing is taken up with higher priority messages. An example of this is at a IP/PSTN gateway with all of the PSTN side circuits utilized. In strict mode one of the lower priority circuits would be freed using preemption. In semi-strict mode, the SIP request May be granted access to the next available circuit based on this header's presence in the authorized message, regardless of how many other "regular" requests are received at that gateway." First, is that "May" supposed to be "MAY" or "may"? But more significantly, the desired behavior at the PSTN gateway is more complicated than what you describe; -At an IP/PSTN gateway with all of the PSTN side circuits utilized, not only would the request with the appropriate RPH be granted "the next available circuit" but if several requests with the appropriate RPH arrive, they would be queued for the next several circuits to become available. - At an IP/PSTN gateway, "restrictive network management controls" may be active, even if not all PSTN side circuits are utilized. (An example of a "restrictive network management control" is "call gapping" in which only one call every x seconds is accepted. "Call gapping" is usually made active as a response to overall network congestion, a bit like ECN in an IP network). If restrictive network management controls are active, a request with the appropriate RPH would be granted an available circuit, even if less than x seconds had passed since the last call was admitted. - At an IP/PSTN gateway, if the request has the appropriate RPH, certain parameters (CPC and/or Precedence) would be set in the ISUP IAM. I don't see anything in the RPH ID that prevents this "additional" functionality, so this comment doesn't necessarily mean anything needs to change. It was just that the current text is a little misleading in that it seems to imply that "access to the next available circuit" is all that is intended. 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. ---------------------------------------------------------------------------------------- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 8 15:09:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23723 for ; Mon, 8 Nov 2004 15:09:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRFq7-000472-IY for sip-web-archive@ietf.org; Mon, 08 Nov 2004 15:10:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRFem-0007bP-7H; Mon, 08 Nov 2004 14:58:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRFN7-0003Ar-5w for sip@megatron.ietf.org; Mon, 08 Nov 2004 14:40:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19025 for ; Mon, 8 Nov 2004 14:40:10 -0500 (EST) Received: from amer-mta01.csc.com ([20.137.2.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRFNh-00037S-Qp for sip@ietf.org; Mon, 08 Nov 2004 14:40:50 -0500 Received: from csc.com (va-fch34.csc.com [20.6.39.227]) by amer-mta01.csc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id iA8Je2Sc016398; Mon, 8 Nov 2004 14:40:02 -0500 (EST) Subject: RE: [Sip] Strict, Semi-Strict and Loose mode in RPH - not a good fit for ets and wps To: "James M. Polk" X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Janet P Gunn Date: Mon, 8 Nov 2004 14:38:27 -0500 X-MIMETrack: Serialize by Router on VA-FCH34/SRV/CSC(Release 6.0.3|September 26, 2003) at 11/08/2004 02:40:51 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: fonashp@ncs.gov, Darren E Pado , Saud Negash , mosleyv@ncs.gov, Richard F Kaczmarek , sip@ietf.org, nyquetek@msn.com, a.ephrath@ieee.org, Ken Carlberg , KENNETH.R.ERNEY@saic.com, suracif@ncs.gov, Dennis Q Berg X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 James said: ___ > > 6 There is no a priori requirement to use, or not use, the "Require" > > header field. > >isn't this addressed in section 4.3.2 below? or am I missing something? > > If the request includes a 'Require' header field with the > 'Resource-Priority' option tag, a UAS MUST follow the strict or > semi-strict mode rules, otherwise UAS and proxies MUST operate in > loose mode. > > >[JG]I guess I wasn't clear. I simply meant that there wasn't a concern >about the "require" header itself, independent of the >strict/semi-strict/loose mode. Once that is "right", the approach to the >"require" header will follow hmmmm The "Require" header is to mandate that SIP Responses use the header as is (copied from request to response without change). If ever there is a case needed in which preferential treatment is within the processing of SIP elements (such as Proxies), knowing there will always be more than one SIP message necessary to complete a transaction - meaning both Request and Response will need to be RP marked for preferential treatment for the session/transaction to be given priority over other transactions. To put this simply, if the INVITE is consistently moved to the head of the line in all SIP elements between UAs 1 & 2, and the 200 OK is slowed/delayed or lost in the congestion of one or more Proxies, the call will not be established. In this case, the INVITE, 200 OK and ACK will need the RP indication to gain the preferential treatment of that domain; and any other messages within that transaction will require it too (such as 183, PRACK and UPDATE messages if RFC 3312 Preconditions were to be required to set up, say RSVP between endpoints). ___ OK, I was definitely missing the point here. I was looking at it simply as the "require" header being the trigger for "strict, or semi-strict" mode (as opposed to loose mode). Now that you have explained that it ALSO triggers "setting RPH in the response, and other associated messages", I would have to say that I DO want the require header. In that case , I am unhappy with "'Strict' and 'semi-strict' are identified by the presence or absence of a 'Require' header field with the 'Resource- Priority' option tag. 'Loose' mode does not contain a Require header." Is there some reason we can't have "Loose" and"Require"? 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. ---------------------------------------------------------------------------------------- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 8 16:01:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01212 for ; Mon, 8 Nov 2004 16:01:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRGeI-0005c5-PL for sip-web-archive@ietf.org; Mon, 08 Nov 2004 16:02:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRGUA-0007cI-0e; Mon, 08 Nov 2004 15:51:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRGFq-0000pI-L0 for sip@megatron.ietf.org; Mon, 08 Nov 2004 15:36:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27434 for ; Mon, 8 Nov 2004 15:36:44 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRGGR-0004q5-5P for sip@ietf.org; Mon, 08 Nov 2004 15:37:24 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 08 Nov 2004 12:36:26 -0800 X-BrightmailFiltered: true Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id iA8KZuVB026228; Mon, 8 Nov 2004 12:36:07 -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 MAA12178; Mon, 8 Nov 2004 12:35:54 -0800 (PST) Message-Id: <4.3.2.7.2.20041108142736.02822440@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 08 Nov 2004 14:35:58 -0600 To: Janet P Gunn From: "James M. Polk" Subject: RE: [Sip] Strict, Semi-Strict and Loose mode in RPH - not a good fit for ets and wps In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: fonashp@ncs.gov, Darren E Pado , Saud Negash , mosleyv@ncs.gov, Richard F Kaczmarek , sip@ietf.org, nyquetek@msn.com, a.ephrath@ieee.org, Ken Carlberg , KENNETH.R.ERNEY@saic.com, suracif@ncs.gov, Dennis Q Berg X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 comments below At 12:51 PM 11/8/2004 -0500, Janet P Gunn wrote: >James said >--- > > > 2 SIP element ignores a namespace it does not recognize (loose) > >To this, remember the ID does not say to "fail" the call, just that >Request. This is one way to inform the calling UAC to know it included a >namespace or priority value that was not recognizable (meaning not >ets.0/1/2/3/4 or wps.0/1/2/3/4). > >There is no way to inform the UAC of this issue within the SIP Request >(with the bad namespace.priority-value) without failing the request. >Meaning, there can be no preferential treatment without the sending element > >being told so. SIP doesn't have a "pass, but this wasn't a good choice" >provisional response like other protocols. > >To the user, they might not notice several SIP Request failures, the person > >is merely waiting for the call to be set up (still under a second). >--- >OK, please educate me. > >If it "fails" that request, but doesn't "fail" the call, does that mean >that the UAC resends the request without the RPH? yep >If that is what it means, then, for a call which originates in a SIP/IP >domain, but goes to the PSTN, it would reach the PSTN gateway with no >indication that it was entitled to special treatment in the PSTN. > >While that is better than failing the call, it still isn't the desired >behavior. SIP has no mechanism other than failing the request to indicate something was wrong. SIP cannot at this time, allow a message to be processed by a SIP element (say a proxy) and have that proxy server send the packet towards the UAS *and* send some form of a provisional reply to the UAC telling it to correct some aspect of itself in future such messages. >If there is a way that the SIP element can "fail the request but not the >call", AND make sure that the appropriate RPH namespace and value (and >authentication) get to the PSTN gateway, then it might be OK. A proxy can replace the field in a header, in this case to a more appropriate namespace.value - but I do not believe you will want this to happen without authentication of the user at the UAC (which would be in the form of a 4XX failure - which you are objecting to.... hmmmm) >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. >---------------------------------------------------------------------------------------- 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 sip-bounces@ietf.org Mon Nov 8 16:24:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03187 for ; Mon, 8 Nov 2004 16:24:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRH0V-00068N-3b for sip-web-archive@ietf.org; Mon, 08 Nov 2004 16:25:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRGf3-0005su-Qo; Mon, 08 Nov 2004 16:02:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRGW2-0008Vy-CI for sip@megatron.ietf.org; Mon, 08 Nov 2004 15:53:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00538 for ; Mon, 8 Nov 2004 15:53:28 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRGWd-0005KM-Uy for sip@ietf.org; Mon, 08 Nov 2004 15:54:08 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 08 Nov 2004 13:04:27 -0800 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iA8KqSnC028785; Mon, 8 Nov 2004 12:52:29 -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 MAA13857; Mon, 8 Nov 2004 12:52:52 -0800 (PST) Message-Id: <4.3.2.7.2.20041108144108.03309830@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 08 Nov 2004 14:52:56 -0600 To: Janet P Gunn From: "James M. Polk" Subject: RE: [Sip] S-S-L mode in RPH for ets and wps (#5) In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: fonashp@ncs.gov, Darren E Pado , Saud Negash , mosleyv@ncs.gov, Richard F Kaczmarek , sip@ietf.org, nyquetek@msn.com, a.ephrath@ieee.org, Ken Carlberg , KENNETH.R.ERNEY@saic.com, suracif@ncs.gov, Dennis Q Berg X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 2086112c730e13d5955355df27e3074b comments in-line I shortened the subject line BTW At 02:13 PM 11/8/2004 -0500, Janet P Gunn wrote: >James said: >___ > > > > 5 Precedence (queueing) is generally the means of providing priority, >but > > > exemption from network management controls, for instance call admission > > > within an IP domain, when a "regular" call would not be admitted, is >also > > > needed. Pre-emption is not used. (semi-strict "plus more") > >I do not understand what you have written above, can you rephrase please? >___ > >OK. I'll try again (and I combined two different cases, which didn't help >the clarity). > >Section 7 says > "The ets and wps namespaces operate with preferential treatment but > without preemption. These namespaces operate under a policy of > provide preferential treatment to higher relative priority requests > instead of processing lower relative priority requests. Messages > are not preempted, or deleted, except under extreme loads in which > all available processing is taken up with higher priority messages. > > An example of this is at a IP/PSTN gateway with all of the PSTN side > circuits utilized. In strict mode one of the lower priority > circuits would be freed using preemption. In semi-strict mode, the > SIP request May be granted access to the next available circuit > based on this header's presence in the authorized message, > regardless of how many other "regular" requests are received at that > gateway." > >First, is that "May" supposed to be "MAY" or "may"? MAY I mistyped it Now, you could contract that this is a MUST within whoever you contract with for IP carrier. This is a big difference that should be pointed out here, the difference between market requirements and protocol requirements. A doc can say "MAY", but a customer can demand that aspect be a MUST in their network. If the doc says MUST (or even SHOULD in most cases), equipment vendors really don't have a choice but to code this feature into their products, even if 1 or more customers do not use it. This is a marketing decision. >But more significantly, the desired behavior at the PSTN gateway is more >complicated than what you describe; I could write a book about exactly how many behaviors are to be.... but I may have oversimplified things here. >-At an IP/PSTN gateway with all of the PSTN side circuits utilized, not >only would the request with the appropriate RPH be granted "the next >available circuit" but if several requests with the appropriate RPH arrive, >they would be queued for the next several circuits to become available. true, I didn't get into the multiple request scenario - I could add this here, but do not want to account for every permutation for each behavior every time. All documents would be very long in this philosophy. >- At an IP/PSTN gateway, "restrictive network management controls" may be >active, even if not all PSTN side circuits are utilized. (An example of >a "restrictive network management control" is "call gapping" in which only >one call every x seconds is accepted. "Call gapping" is usually made >active as a response to overall network congestion, a bit like ECN in an IP >network). If restrictive network management controls are active, a request >with the appropriate RPH would be granted an available circuit, even if >less than x seconds had passed since the last call was admitted. I will restate to "all available circuits are utilized" to account for this. but do not want to get into restrictive mgmt control. >- At an IP/PSTN gateway, if the request has the appropriate RPH, certain >parameters (CPC and/or Precedence) would be set in the ISUP IAM. this isn't a SIP issue, this is a translation issue that the GW vendor is to deal with. >I don't see anything in the RPH ID that prevents this "additional" >functionality, so this comment doesn't necessarily mean anything needs to >change. It was just that the current text is a little misleading in that >it seems to imply that "access to the next available circuit" is all that >is intended. I think I cleaned up the text appropriately to your above points >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. >---------------------------------------------------------------------------------------- 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 sip-bounces@ietf.org Mon Nov 8 16:27:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03520 for ; Mon, 8 Nov 2004 16:27:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRH3E-0006EN-VN for sip-web-archive@ietf.org; Mon, 08 Nov 2004 16:27:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRGng-0000yH-Ns; Mon, 08 Nov 2004 16:11:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRGZm-0001r4-Jl for sip@megatron.ietf.org; Mon, 08 Nov 2004 15:57:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00985 for ; Mon, 8 Nov 2004 15:57:20 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRGaO-0005Ot-4z for sip@ietf.org; Mon, 08 Nov 2004 15:58:00 -0500 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iA8Kuht02939; Mon, 8 Nov 2004 15:56:43 -0500 (EST) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Nov 2004 15:56:43 -0500 Message-ID: From: "Mary Barnes" To: "Mary Barnes" , "'GARCIN Sebastien RD-CORE-ISS'" , "'sip@ietf.org'" Subject: RE: [Sip] Privacy statements and History (draft-ietf-sip-history- info-04.txt) Date: Mon, 8 Nov 2004 15:56:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.9 (/) X-Scan-Signature: 55503977758b6a5197d8a2b5141eae86 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0354939101==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 4cbeb0f20efb229aa93fae1468d20275 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0354939101== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C5D5.6D1A97CE" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4C5D5.6D1A97CE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable My initial response is awaiting approval by moderator due to the size, = so I've snipped and am resending. =20 =20 Mary=20 -----Original Message----- From: Barnes, Mary [NGC:B601:EXCH]=20 Sent: Monday, November 08, 2004 1:43 PM To: 'GARCIN Sebastien RD-CORE-ISS'; sip@ietf.org Subject: RE: [Sip] Privacy statements and History (draft-ietf-sip-history-info-04.txt) S=E9bastien, =20 Thanks for reviewing the draft; my response to your comments is = embedded below [MB]. =20 Mary=20 -----Original Message----- From: GARCIN Sebastien RD-CORE-ISS [mailto:sebastien.garcin@francetelecom.com]=20 Sent: Monday, November 08, 2004 10:11 AM To: Barnes, Mary [NGC:B601:EXCH]; sip@ietf.org Subject: [Sip] Privacy statements and History (draft-ietf-sip-history-info-04.txt) Hi mary, all =20 When reading draft-ietf-sip-history-info-04.txt, I have trouble in understanding some of the statements which relate to the forwarding = rules for history-entries subject to privacy. It is an important requirement = that History-entrie(s) with a Privacy=3Dhistory, session, or header are = indeed forwarded to entities which belong to the same trust domain. The = removal of specific history-entries should only occur if the peer does not belong = to the trust domain. =20 In the current text (section 4.3.3.1.1) : If a request is being forwarded to a Request URI associated with a = domain for which the proxy is not responsible and there is a Privacy header in = the request with a priv-value of "session", "header" or "history", the = proxy MUST remove any hi-entry(s) prior to forwarding.=20 =20 The current wording is misleading since it gives the impression (maybe intentionnal) that it is not possible to forward history-entries with Privacy statements to domains under the responsability of e.g. another operator belonging to the same trust domain. =20 =20 [MB]: Current wording is consistent with terminology in RFC 3261 in = terms of describing who is able to change the Request URI in a specific request (based on section 16.5):=20 " A proxy MUST NOT add additional targets to the target set if the Request-URI of the original request does not indicate a resource = this proxy is responsible for. A proxy can only change the Request-URI of a request during forwarding if it is responsible for that URI. " Since History-Info (and associated privacy) are only added to the = request, when an entity that is allowed to change the Request-URI retargets the request, it seemed sensible to use consistent wording to explain that. = =20 [/MB] =20 The concept of "trust domain" should be used when discussing the = forwarding rules pertaining to information subject to privacy. Furthermore, the requirement for forwarding history-entries to trusted entities should = be stated more clearly in the draft.=20 [MB]: The whole concept of what defines privacy in terms of the proxy's = use of the privacy header is outside the scope of History-Info = functionality and really a matter of local policy. I think the functionality that you = want is a matter of local implementation and policy in terms of operators establishing this "trust domain" model to which you refer. = History-Info defines the mechanism to ensure the privacy of the requests, but it = doesn't explicitly define how the proxy knows whether it is responsible for = that resource. I don't think this is a matter of standardization. I = thought the use of the term "domain" rather than "resouce" would be helpful, = but perhaps changing it to the more general "resource" would resolve this concern and/or a statement clarifying what I've just described should = be added in the draft.=20 [/MB] =20 =20 Thank you for clarifying this point. =20 Best regards, s=E9bastien =20 =20 ------Remainder of non-related part of this thread has been deleted by Mary------------------ ------_=_NextPart_001_01C4C5D5.6D1A97CE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
My=20 initial response is awaiting approval by moderator due to the size, so = I've=20 snipped and am resending. 
 
Mary=20
-----Original Message-----
From: = Barnes, Mary=20 [NGC:B601:EXCH]
Sent: Monday, November 08, 2004 1:43=20 PM
To: 'GARCIN Sebastien RD-CORE-ISS';=20 sip@ietf.org
Subject: RE: [Sip] Privacy statements and = History=20 (draft-ietf-sip-history-info-04.txt)

S=E9bastien,
 
Thanks for reviewing the draft; my = response to your=20 comments is embedded below [MB].
 
Mary
-----Original Message-----
From: = GARCIN=20 Sebastien RD-CORE-ISS [mailto:sebastien.garcin@francetelecom.com]=20
Sent: Monday, November 08, 2004 10:11 AM
To: = Barnes,=20 Mary [NGC:B601:EXCH]; sip@ietf.org
Subject: [Sip] Privacy = statements and History=20 (draft-ietf-sip-history-info-04.txt)

Hi mary, all
 
When=20 reading draft-ietf-sip-history-info-04.txt, I have = trouble in=20 understanding some of the statements which relate to the forwarding = rules for history-entries subject to = privacy. It is=20 an important requirement that History-entrie(s) = with a=20 Privacy=3Dhistory, session, or header are indeed = forwarded to=20 entities which belong to the same trust domain. The = removal=20 of specific history-entries should only occur if the peer does = not=20 belong to the trust domain.
 
In = the current=20 text (section 4.3.3.1.1) :
If a request is  being = forwarded to a Request URI associated with a domain for which the = proxy is not=20 responsible and there is a Privacy header in=20 the request with = a=20 priv-value of "session", "header" or "history", the proxy MUST = remove=20 any hi-entry(s) prior to forwarding.
 
The current wording is = misleading since=20 it gives the impression (maybe intentionnal) that it is not = possible to=20 forward history-entries with Privacy statements to domains under = the=20 responsability of e.g. another operator belonging to the same = trust=20 domain.  
 
[MB]: = Current wording is=20 consistent with terminology in RFC 3261 in terms of describing who = is able=20 to change the Request URI in a specific request (based = on section=20 16.5): 
   " A = proxy MUST NOT=20 add additional targets to the target set if the
   = Request-URI=20 of the original request does not indicate a resource = this
  =20 proxy is responsible for.

      A = proxy can=20 only change the Request-URI of a request=20 during
      forwarding if it is = responsible for=20 that URI. "
Since = History-Info (and=20 associated privacy) are only added to the request, when=20 an entity that is allowed to change the Request-URI = retargets the=20 request, it seemed sensible to use consistent wording to explain = that. =20  
[/MB]
 
The concept of "trust = domain" should=20 be used when discussing the forwarding rules = pertaining to=20 information subject to privacy. Furthermore, the requirement = for=20 forwarding history-entries to trusted entities should = be stated more=20 clearly in the draft. 
[MB]: The whole concept of what defines = privacy in=20 terms of the proxy's use of the privacy header is outside the scope = of=20 History-Info functionality and really a matter of local policy. =   I=20 think the functionality that you want is a matter of local = implementation=20 and policy in terms of operators establishing this "trust = domain"=20 model to which you refer.  History-Info defines the = mechanism=20 to ensure the privacy of the requests, but it = doesn't explicitly=20 define how the proxy knows whether it is responsible for that=20 resource.    I don't think this is a matter of=20 standardization.  I thought the use of the term "domain" = rather than=20 "resouce" would be helpful, but perhaps changing it to the more = general=20 "resource" would resolve this concern and/or a statement clarifying = what=20 I've just described should be added in the draft. =
[/MB]
 =
 
Thank you for clarifying this=20 point.
 
Best regards,
s=E9bastien
 
 

------Remainder of non-related part of this thread has = been deleted=20 by=20 Mary------------------
------_=_NextPart_001_01C4C5D5.6D1A97CE-- --===============0354939101== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0354939101==-- From sip-bounces@ietf.org Mon Nov 8 16:42:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05640 for ; Mon, 8 Nov 2004 16:42:23 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRHHw-0006q1-Py for sip-web-archive@ietf.org; Mon, 08 Nov 2004 16:43:01 -0500 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1CRHGn-0001fI-AT for sip-web-archive@ietf.org; Mon, 08 Nov 2004 16:41:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRH0T-0006xy-FH; Mon, 08 Nov 2004 16:24:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRGgX-0006Xr-3H for sip@megatron.ietf.org; Mon, 08 Nov 2004 16:04:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01599 for ; Mon, 8 Nov 2004 16:04:18 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRGh7-0005hc-Mr for sip@ietf.org; Mon, 08 Nov 2004 16:04:59 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 08 Nov 2004 13:03:29 -0800 X-BrightmailFiltered: true Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id iA8L3BVB005890; Mon, 8 Nov 2004 13:03:12 -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 NAA03604; Mon, 8 Nov 2004 13:03:09 -0800 (PST) Message-Id: <4.3.2.7.2.20041108145447.025ef520@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 08 Nov 2004 15:03:13 -0600 To: Janet P Gunn From: "James M. Polk" Subject: RE: [Sip] S-S-L mode in RPH for ets and wps (#6) In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: fonashp@ncs.gov, Darren E Pado , Saud Negash , mosleyv@ncs.gov, Richard F Kaczmarek , sip@ietf.org, nyquetek@msn.com, a.ephrath@ieee.org, Ken Carlberg , KENNETH.R.ERNEY@saic.com, suracif@ncs.gov, Dennis Q Berg X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db comments in-line I changed the subject line BTW At 02:38 PM 11/8/2004 -0500, Janet P Gunn wrote: >James said: >___ > > > > > 6 There is no a priori requirement to use, or not use, the "Require" > > > header field. > > > >isn't this addressed in section 4.3.2 below? or am I missing something? > > > > If the request includes a 'Require' header field with the > > 'Resource-Priority' option tag, a UAS MUST follow the strict or > > semi-strict mode rules, otherwise UAS and proxies MUST operate in > > loose mode. > > > > > >[JG]I guess I wasn't clear. I simply meant that there wasn't a concern > >about the "require" header itself, independent of the > >strict/semi-strict/loose mode. Once that is "right", the approach to the > >"require" header will follow > >hmmmm > >The "Require" header is to mandate that SIP Responses use the header as is >(copied from request to response without change). If ever there is a case >needed in which preferential treatment is within the processing of SIP >elements (such as Proxies), knowing there will always be more than one SIP >message necessary to complete a transaction - meaning both Request and >Response will need to be RP marked for preferential treatment for the >session/transaction to be given priority over other transactions. > >To put this simply, if the INVITE is consistently moved to the head of the >line in all SIP elements between UAs 1 & 2, and the 200 OK is >slowed/delayed or lost in the congestion of one or more Proxies, the call >will not be established. In this case, the INVITE, 200 OK and ACK will need >the RP indication to gain the preferential treatment of that domain; and >any other messages within that transaction will require it too (such as >183, PRACK and UPDATE messages if RFC 3312 Preconditions were to be >required to set up, say RSVP between endpoints). >___ > >OK, I was definitely missing the point here. I was looking at it simply as >the "require" header being the trigger for "strict, or semi-strict" mode >(as opposed to loose mode). no, this Require header will have "Resource-Priority" as a field value stating that the RPH is to be expected in the Response. >Now that you have explained that it ALSO triggers "setting RPH in the >response, and other associated messages", I would have to say that I DO >want the require header. thanks, it really is needed >In that case , I am unhappy with > "'Strict' and 'semi-strict' are identified by the > presence or absence of a 'Require' header field with the 'Resource- > Priority' option tag. 'Loose' mode does not contain a Require > header." > >Is there some reason we can't have "Loose" and"Require"? no technical reason that I can think of right now >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. >---------------------------------------------------------------------------------------- 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 sip-bounces@ietf.org Mon Nov 8 16:55:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07148 for ; Mon, 8 Nov 2004 16:55:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRHUU-0007DT-57 for sip-web-archive@ietf.org; Mon, 08 Nov 2004 16:55:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRHNc-0007Qt-2b; Mon, 08 Nov 2004 16:48:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRH8D-0002mU-Mc for sip@megatron.ietf.org; Mon, 08 Nov 2004 16:32:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04220 for ; Mon, 8 Nov 2004 16:32:54 -0500 (EST) Received: from natsmtp00.rzone.de ([81.169.145.165]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRH8p-0006RU-Ag for sip@ietf.org; Mon, 08 Nov 2004 16:33:36 -0500 Received: from snom.de (pD9568738.dip.t-dialin.net [217.86.135.56]) by post.webmailer.de (8.13.1/8.13.1) with ESMTP id iA8LVHVn016439; Mon, 8 Nov 2004 22:31:18 +0100 (MET) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Mon, 8 Nov 2004 22:31:15 +0100 Message-ID: Thread-Topic: PING/PONG thread-index: AcTF2kbloPYnFtW7Qjah6sX+t0mDhg== From: "Christian Stredicke" To: X-Spam-Score: 1.0 (+) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: sip@ietf.org Subject: [Sip] PING/PONG X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0308069664==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 This is a multi-part message in MIME format. --===============0308069664== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C5DA.CC1FF8AA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4C5DA.CC1FF8AA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Cullen, =20 I think it is no harm if there is a PING message defined in SIP. I personally think it is overdue anyway. Implementors can then decide if they are using it or not. Lets leave that decision to the implementors! =20 But we have to consider who is sending keep-alive traffic. "IMHO" is it definitely better if the UA does this, because then e.g. usually it is ok to send CRLF keep alive or STUN. =20 We register with a header that incates (a) that the UA is able to do the refreshing and (b) what the proposed refresh time is. The UA can do all these tricky NAT measurement tricks and then propose the refresh time. Stupid UA may just propose a predefined value, e.g. 20 seconds. The registrar (or whatever is in the path) then can acknowlege the refresh role and leave the refreshing to the UA. Otherwise, it will send the refresh messages. In that case, it will probably use PING, cause it needs a response to keep the NAT alive in all cases - even if it is a "503 Not Implemented". =20 Christian =20 ------_=_NextPart_001_01C4C5DA.CC1FF8AA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello=20 Cullen,
 
I = think it is no=20 harm if there is a PING message defined in SIP. I personally think it is = overdue=20 anyway. Implementors can then decide if they are using it or not. Lets = leave=20 that decision to the implementors!
 
But = we have to=20 consider who is sending keep-alive traffic. "IMHO" is it definitely = better if=20 the UA does this, because then e.g. usually it is ok to send CRLF keep = alive or=20 STUN.
 
We = register with a=20 header that incates (a) that the UA is able to do the refreshing and (b) = what=20 the proposed refresh time is. The UA can do all these tricky NAT = measurement=20 tricks and then propose the refresh time. Stupid UA may just propose a=20 predefined value, e.g. 20 seconds. The registrar (or whatever is in the = path)=20 then can acknowlege the refresh role and leave the refreshing to the UA. = Otherwise, it will send the refresh messages. In that case, it will = probably use=20 PING, cause it needs a response to keep the NAT alive in all cases - = even if it=20 is a "503 Not Implemented".
 
Christian
 
------_=_NextPart_001_01C4C5DA.CC1FF8AA-- --===============0308069664== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0308069664==-- From sip-bounces@ietf.org Mon Nov 8 17:21:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09546 for ; Mon, 8 Nov 2004 17:21:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRHtn-0007rr-Fi for sip-web-archive@ietf.org; Mon, 08 Nov 2004 17:22:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRHd7-0003Qs-2d; Mon, 08 Nov 2004 17:04:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRHOa-0008KF-Nm for sip@megatron.ietf.org; Mon, 08 Nov 2004 16:49:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06410 for ; Mon, 8 Nov 2004 16:49:50 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRHPC-00071I-1X for sip@ietf.org; Mon, 08 Nov 2004 16:50:31 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 08 Nov 2004 14:02:56 -0800 X-BrightmailFiltered: true Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iA8Ln8om027162 for ; Mon, 8 Nov 2004 13:49: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 NAA00804 for ; Mon, 8 Nov 2004 13:49:17 -0800 (PST) Message-Id: <4.3.2.7.2.20041108154142.033a9f00@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 08 Nov 2004 15:49:20 -0600 To: sip@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Sip] Proposed, but not IANA Registered (yet), Response codes X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Is there a central repository for listing Response codes that are in IDs (meaning not IANA registered)? I'm looking for anywhere I can go, if I am willing to risk my life to suggest a new response code, and know that the number picked is not taken in any other current SIP/SIPPING draft document. This seems to me to be something on the softarmor site, but I do not see anything listing this. Searching in every SIP and SIPPING doc seems quite inefficient, time consuming and prone to error (though not life threatening ;-) 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 sip-bounces@ietf.org Mon Nov 8 17:24:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09958 for ; Mon, 8 Nov 2004 17:24:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRHwV-0007zg-Ga for sip-web-archive@ietf.org; Mon, 08 Nov 2004 17:24:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRHiY-0005S7-Iz; Mon, 08 Nov 2004 17:10:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRHVt-0002bv-DK for sip@megatron.ietf.org; Mon, 08 Nov 2004 16:57:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07365 for ; Mon, 8 Nov 2004 16:57:22 -0500 (EST) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRHWU-0007Gy-Vi for sip@ietf.org; Mon, 08 Nov 2004 16:58:04 -0500 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id iA8Luq10006131; Mon, 8 Nov 2004 21:56:53 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Mon, 8 Nov 2004 16:56:52 -0500 Message-ID: <7927C67249E4AD43BC05B539AF0D129801AF4347@stntexch04.cis.neustar.com> From: "Peterson, Jon" To: "'Aki Niemi'" , SIP WG Date: Mon, 8 Nov 2004 16:56:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.8 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: [Sip] RE: Comments on sip-identity-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Thanks Aki. You are correct that we are not suggesting that the Digest username match as a literal the username in the local-part of the URI in the >From header. I mean, I guess that's possible, but certainly not necessary. What we intend is that an authentication service might persist some mapping between a Digest username and one or more potential local-parts which are authorized to appear in the From header field value for that user. I will attempt to free to language you cite below from the shackles of confusion. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Aki Niemi [mailto:aki.niemi@nokia.com] > Sent: Monday, November 08, 2004 1:32 PM > To: SIP WG > Cc: jon.peterson@neustar.biz > Subject: Comments on sip-identity-03 > > > Hi, > > I read the draft and it looks reasonable. One comment though: in section > 6 there is a recommended policy which instructs matching the username > asserted in the Digest authentication to the From header field. > > I think this needs clarification. Someone might read it to mean the > contents of the username param is being matched, which I'm assuming is > not the intention. Rather, it should say that the account's URI for > which the username/passwd is for is matched against the URI > in the From. > > In addition, the section contains text about aliases and matching those > usernames, where this passage was quite hard to parse: > > Accordingly, provided > the authentication service is aware of the relationships between > these accounts, it might allow a user providing credentials for one > account to assert a username associated with another account > controlled by the user name. > > I think I got the idea, but rephrasing it would be in order. > > 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 sip-bounces@ietf.org Mon Nov 8 17:49:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12188 for ; Mon, 8 Nov 2004 17:49:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRIL0-0000Dp-Dj for sip-web-archive@ietf.org; Mon, 08 Nov 2004 17:50:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRI3x-00030u-FV; Mon, 08 Nov 2004 17:32:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRHm6-00065v-6F for sip@megatron.ietf.org; Mon, 08 Nov 2004 17:14:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08911 for ; Mon, 8 Nov 2004 17:14:07 -0500 (EST) Received: from dsl-dt-207-34-112-i195-cgy.nucleus.com ([207.34.112.195] helo=yyc.jasomi.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRHmh-0007ie-KI for sip@ietf.org; Mon, 08 Nov 2004 17:14:49 -0500 Received: from [127.0.0.1] (yyc.jasomi.com [207.34.112.195]) by yyc.jasomi.com (8.12.9/8.12.6) with ESMTP id iA8M0LiJ007244; Mon, 8 Nov 2004 15:00:22 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Alan Hawrylyshen Date: Mon, 8 Nov 2004 17:17:35 -0500 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , sip@ietf.org Subject: [Sip] GRUU Comments and interaction with outbound-connection X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Re: the Edge Proxy, Reg/Prox RR problems.... Johnathan; It strikes me that the EP can directly route the GRUU since it is (except in the 3GPP case) in the same administrative / security / policy domain as the registrar and SHOULD be capable of detecting the GRUU's applicability when the initial request hits the EP. An appropriately constructed (encoded) GRUU could be decoded and dealt with as soon as it reaches the UA's EP, no? And as I write this, Cullen has just proposed the same thing. Alan a l a n a t j a s o m i d o t c o m _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 8 18:20:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17142 for ; Mon, 8 Nov 2004 18:20:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRIpN-000198-DJ for sip-web-archive@ietf.org; Mon, 08 Nov 2004 18:21:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRIl7-0003Ti-HK; Mon, 08 Nov 2004 18:17:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRIYz-0005r5-HW for sip@megatron.ietf.org; Mon, 08 Nov 2004 18:04:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15021 for ; Mon, 8 Nov 2004 18:04:38 -0500 (EST) Received: from grads.ece.mcmaster.ca ([130.113.10.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRIZc-0000mr-AP for sip@ietf.org; Mon, 08 Nov 2004 18:05:20 -0500 Received: from power.eng.mcmaster.ca (PC-T13-Mohammed.Eng.McMaster.CA [130.113.184.38]) by grads.ece.mcmaster.ca (8.12.8/8.12.8) with ESMTP id iA8N47pQ017913 for ; Mon, 8 Nov 2004 18:04:07 -0500 Message-ID: <418FFB8C.3000804@power.eng.mcmaster.ca> Date: Mon, 08 Nov 2004 18:04:44 -0500 From: "m. smadi" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040115 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-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Content-Transfer-Encoding: 7bit Subject: [Sip] reinvite and refer methods X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit what is exactly the difference between the Re-Invite and Refer methods? thanks moe smadi _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 8 18:32:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18500 for ; Mon, 8 Nov 2004 18:32:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRJ0Q-0001Xo-8L for sip-web-archive@ietf.org; Mon, 08 Nov 2004 18:33:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRInq-0005os-Uw; Mon, 08 Nov 2004 18:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRIje-0002hM-8Q for sip@megatron.ietf.org; Mon, 08 Nov 2004 18:15:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16421 for ; Mon, 8 Nov 2004 18:15:39 -0500 (EST) Received: from grads.ece.mcmaster.ca ([130.113.10.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRIkE-000103-98 for sip@ietf.org; Mon, 08 Nov 2004 18:16:21 -0500 Received: from power.eng.mcmaster.ca (PC-T13-Mohammed.Eng.McMaster.CA [130.113.184.38]) by grads.ece.mcmaster.ca (8.12.8/8.12.8) with ESMTP id iA8NF8pQ018089 for ; Mon, 8 Nov 2004 18:15:08 -0500 Message-ID: <418FFE21.2010106@power.eng.mcmaster.ca> Date: Mon, 08 Nov 2004 18:15:45 -0500 From: "m. smadi" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040115 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Subject: [Sip] SIP reinvite X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit hello; my understanding of a SIP reinvite is that it modifies the media session. Is it capable of modifying the address of the send too? for example of A is talking to B, can A send a reinvite to B with C's address instead of its own address? Moe Smadi _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 8 20:35:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28993 for ; Mon, 8 Nov 2004 20:35:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRKvE-0004R2-Jh for sip-web-archive@ietf.org; Mon, 08 Nov 2004 20:35:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRKoi-0004WB-1c; Mon, 08 Nov 2004 20:29:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRKnS-0003me-3K for sip@megatron.ietf.org; Mon, 08 Nov 2004 20:27:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28143 for ; Mon, 8 Nov 2004 20:27:44 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRKo5-0004Fl-NR for sip@ietf.org; Mon, 08 Nov 2004 20:28:26 -0500 Received: from [130.129.135.89] ([130.129.135.89]) (authenticated bits=0) by nylon.softarmor.com (8.12.11/8.12.11) with ESMTP id iA91R2Jw005317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Nov 2004 19:27:02 -0600 Message-ID: <41901CC8.5000509@softarmor.com> Date: Mon, 08 Nov 2004 19:26:32 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [Sip] Proposed, but not IANA Registered (yet), Response codes References: <4.3.2.7.2.20041108154142.033a9f00@localhost> In-Reply-To: <4.3.2.7.2.20041108154142.033a9f00@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit James M. Polk wrote: > Is there a central repository for listing Response codes that are in > IDs (meaning not IANA registered)? > None that I know of, but if you want to be the editor, I'll happily host the web page. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 8 23:37:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25082 for ; Mon, 8 Nov 2004 23:37:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRNlW-00088c-Ib for sip-web-archive@ietf.org; Mon, 08 Nov 2004 23:37:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRNdx-0008Dn-1J; Mon, 08 Nov 2004 23:30:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRNZ8-0007ed-5S for sip@megatron.ietf.org; Mon, 08 Nov 2004 23:25:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24155 for ; Mon, 8 Nov 2004 23:25:07 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRNZm-0007tW-5W for sip@ietf.org; Mon, 08 Nov 2004 23:25:52 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 08 Nov 2004 20:36:09 -0800 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iA94OTnC017711; Mon, 8 Nov 2004 20:24:29 -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 UAA06883; Mon, 8 Nov 2004 20:24:33 -0800 (PST) Message-Id: <4.3.2.7.2.20041108222341.0339e368@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 08 Nov 2004 22:24:13 -0600 To: Dean Willis From: "James M. Polk" Subject: Re: [Sip] Proposed, but not IANA Registered (yet), Response codes In-Reply-To: <41901CC8.5000509@softarmor.com> References: <4.3.2.7.2.20041108154142.033a9f00@localhost> <4.3.2.7.2.20041108154142.033a9f00@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 At 07:26 PM 11/8/2004 -0600, Dean Willis wrote: >James M. Polk wrote: > >>Is there a central repository for listing Response codes that are in IDs >>(meaning not IANA registered)? >None that I know of, but if you want to be the editor, I'll happily host >the web page. well.... I did bring it up >-- >Dean > 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 sip-bounces@ietf.org Mon Nov 8 23:59:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27648 for ; Mon, 8 Nov 2004 23:59:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRO6x-0000Cc-5v for sip-web-archive@ietf.org; Tue, 09 Nov 2004 00:00:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRO1H-0003Wj-Em; Mon, 08 Nov 2004 23:54:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRNsw-0002yJ-1r for sip@megatron.ietf.org; Mon, 08 Nov 2004 23:45:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26048 for ; Mon, 8 Nov 2004 23:45:35 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRNtb-0008Lj-3z for sip@ietf.org; Mon, 08 Nov 2004 23:46:20 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 08 Nov 2004 20:58:45 -0800 X-BrightmailFiltered: true Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iA94j3cp019731; Mon, 8 Nov 2004 20:45:05 -0800 (PST) Received: from [130.129.133.34] (sjc-vpn4-1118.cisco.com [10.21.84.93]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id ATV50074; Mon, 8 Nov 2004 20:44:55 -0800 (PST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Mon, 08 Nov 2004 17:17:21 -0500 From: Cullen Jennings To: "sip@ietf.org" Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: 7bit Subject: [Sip] Multiple contacts per GRUU X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit As requested by chairs, I think I understand the issues and I think what Jonathan proposed sounds like it will work. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 9 00:03:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28081 for ; Tue, 9 Nov 2004 00:03:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CROAW-0000Sg-37 for sip-web-archive@ietf.org; Tue, 09 Nov 2004 00:03:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRO2f-0003oj-6n; Mon, 08 Nov 2004 23:55:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRNxQ-0003Lm-Ci for sip@megatron.ietf.org; Mon, 08 Nov 2004 23:50:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26678 for ; Mon, 8 Nov 2004 23:50:12 -0500 (EST) Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRNy2-0008To-Ao for sip@ietf.org; Mon, 08 Nov 2004 23:50:57 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id iA94oAZp025442 for ; Mon, 8 Nov 2004 21:50:10 -0700 (MST) Received: from zin05exm02.corp.mot.com (zin05exm02.corp.mot.com [10.232.0.1]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id iA94lXuh003300 for ; Mon, 8 Nov 2004 22:47:34 -0600 Received: by zin05exm02.corp.mot.com with Internet Mail Service (5.5.2657.72) id ; Tue, 9 Nov 2004 10:20:06 +0530 Message-ID: <653138C25D8AD6118292000347080A371244C4B9@zin05exm02.corp.mot.com> From: Avasarala Ranjit-A20990 To: "m. smadi" , sip@ietf.org Subject: RE: [Sip] SIP reinvite Date: Tue, 9 Nov 2004 10:20:05 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Hi For this you can use REFER with Refer-To header. So A can specify C's address in Refer-To header. Regards Ranjit -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of m. smadi Sent: Tuesday, November 09, 2004 4:46 AM To: sip@ietf.org Subject: [Sip] SIP reinvite hello; my understanding of a SIP reinvite is that it modifies the media session. Is it capable of modifying the address of the send too? for example of A is talking to B, can A send a reinvite to B with C's address instead of its own address? Moe Smadi _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 9 05:06:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07196 for ; Tue, 9 Nov 2004 05:06:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRSuC-0006xk-MB for sip-web-archive@ietf.org; Tue, 09 Nov 2004 05:07:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRSl5-0000Pp-A7; Tue, 09 Nov 2004 04:57:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRSj0-00008L-Gt for sip@megatron.ietf.org; Tue, 09 Nov 2004 04:55:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06695 for ; Tue, 9 Nov 2004 04:55:39 -0500 (EST) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRSji-0006mW-BA for sip@ietf.org; Tue, 09 Nov 2004 04:56:27 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 9 Nov 2004 10:52:39 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Sip] Privacy statements and History (draft-ietf-sip-history-info-04.txt) Date: Tue, 9 Nov 2004 10:52:38 +0100 Message-ID: <49E7012A614B024B80A7D175CB9A64EC86C8F3@ftrdmel1.rd.francetelecom.fr> Thread-Topic: [Sip] Privacy statements and History (draft-ietf-sip-history-info-04.txt) Thread-Index: AcTF2cPq8lAjcJZ6TCmqxsEhTxGqMQABboEwABStfEA= From: "GARCIN Sebastien RD-CORE-ISS" To: "Mary Barnes" , X-OriginalArrivalTime: 09 Nov 2004 09:52:39.0259 (UTC) FILETIME=[D93612B0:01C4C641] X-Spam-Score: 0.9 (/) X-Scan-Signature: fa183e2955b1d12e35b5783ab5b4f6df X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0212921545==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 426dd6ea860196690cb99367d860d19e This is a multi-part message in MIME format. --===============0212921545== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C641.D900A5A4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4C641.D900A5A4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mary, =20 Responses below marked [SG] =20 Best regards,=20 s=E9bastien=20 ________________________________ De : sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] De la part de = Mary Barnes Envoy=E9 : lundi 8 novembre 2004 21:57 =C0 : Mary Barnes; GARCIN Sebastien RD-CORE-ISS; 'sip@ietf.org' Objet : RE: [Sip] Privacy statements and History = (draft-ietf-sip-history-info-04.txt) My initial response is awaiting approval by moderator due to the size, = so I've snipped and am resending. =20 =20 Mary=20 -----Original Message----- From: Barnes, Mary [NGC:B601:EXCH]=20 Sent: Monday, November 08, 2004 1:43 PM To: 'GARCIN Sebastien RD-CORE-ISS'; sip@ietf.org Subject: RE: [Sip] Privacy statements and History = (draft-ietf-sip-history-info-04.txt) =09 =09 S=E9bastien, =20 Thanks for reviewing the draft; my response to your comments is = embedded below [MB]. =20 Mary=20 =09 -----Original Message----- From: GARCIN Sebastien RD-CORE-ISS = [mailto:sebastien.garcin@francetelecom.com]=20 Sent: Monday, November 08, 2004 10:11 AM To: Barnes, Mary [NGC:B601:EXCH]; sip@ietf.org Subject: [Sip] Privacy statements and History = (draft-ietf-sip-history-info-04.txt) =09 =09 Hi mary, all =20 When reading draft-ietf-sip-history-info-04.txt, I have trouble in = understanding some of the statements which relate to the forwarding = rules for history-entries subject to privacy. It is an important = requirement that History-entrie(s) with a Privacy=3Dhistory, session, or = header are indeed forwarded to entities which belong to the same trust = domain. The removal of specific history-entries should only occur if the = peer does not belong to the trust domain. =20 In the current text (section 4.3.3.1.1) : If a request is being forwarded to a Request URI associated with a = domain for which the proxy is not responsible and there is a Privacy = header in the request with a priv-value of "session", "header" or = "history", the proxy MUST remove any hi-entry(s) prior to forwarding.=20 =20 The current wording is misleading since it gives the impression (maybe = intentionnal) that it is not possible to forward history-entries with = Privacy statements to domains under the responsability of e.g. another = operator belonging to the same trust domain. =20 =20 [MB]: Current wording is consistent with terminology in RFC 3261 in = terms of describing who is able to change the Request URI in a specific = request (based on section 16.5):=20 " A proxy MUST NOT add additional targets to the target set if the Request-URI of the original request does not indicate a resource = this proxy is responsible for. =09 A proxy can only change the Request-URI of a request during forwarding if it is responsible for that URI. " Since History-Info (and associated privacy) are only added to the = request, when an entity that is allowed to change the Request-URI = retargets the request, it seemed sensible to use consistent wording to = explain that. =20 [/MB]=20 [SG] I have no problem with the statements above. My concern is that = if there is a hi-entry already embedded in the request with a Privacy = statement, then, it should be up to local policy to decide whether or = not a proxy shall pass on those hi-entries to a trusted domain. The = sentence in section 4.3.3.1.1 precludes this. I would propose to lighten = the strenght of the sentence as follows: =20 If a request is being forwarded to a Request URI associated with a = domain for which the proxy is not responsible and there is a Privacy = header in the request with a priv-value of "session", "header" or = "history", the proxy MAY remove any hi-entry(s) prior to forwarding.=20 =20 [SG] Another issue is the decision to add hi-entries in a privacy = context. A proxy changing the target (i.e. the proxy is responsible of = the resource reflected in the received Request-URI) of a request which = contained a "privacy=3Dhistory" header MAY add a history-entries = provided that it knows it can rely on other entities within the trust = domain to apply the requested privacy. This affect item 4 in the list on = conditions of section 4.3.3 and 4.3.3.1.=20 =20 The concept of "trust domain" should be used when discussing the = forwarding rules pertaining to information subject to privacy. = Furthermore, the requirement for forwarding history-entries to trusted = entities should be stated more clearly in the draft.=20 =09 [MB]: The whole concept of what defines privacy in terms of the = proxy's use of the privacy header is outside the scope of History-Info = functionality and really a matter of local policy. I think the = functionality that you want is a matter of local implementation and = policy in terms of operators establishing this "trust domain" model to = which you refer. History-Info defines the mechanism to ensure the = privacy of the requests, but it doesn't explicitly define how the proxy = knows whether it is responsible for that resource. I don't think this = is a matter of standardization. I thought the use of the term "domain" = rather than "resouce" would be helpful, but perhaps changing it to the = more general "resource" would resolve this concern and/or a statement = clarifying what I've just described should be added in the draft.=20 [/MB] [SG] Changing the term "domain" to "resource" does not solve the = problem I mentionned above. In order to reflect current operator = requirements, the draft should not PRECLUDE the fowarding of existing = history information towards trusted domains. =20 Thank you for clarifying this point. =20 Best regards, s=E9bastien =20 =20 ------Remainder of non-related part of this thread has been deleted by = Mary------------------ ------_=_NextPart_001_01C4C641.D900A5A4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Mary,
 
Responses below marked [SG]
 
Best regards, 
s=E9bastien 
De : sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] De la part de Mary=20 Barnes
Envoy=E9 : lundi 8 novembre 2004 = 21:57
=C0 :=20 Mary Barnes; GARCIN Sebastien RD-CORE-ISS; = 'sip@ietf.org'
Objet :=20 RE: [Sip] Privacy statements and History=20 (draft-ietf-sip-history-info-04.txt)

My=20 initial response is awaiting approval by moderator due to the size, so = I've=20 snipped and am resending. 
 
Mary=20
-----Original Message-----
From: = Barnes, Mary=20 [NGC:B601:EXCH]
Sent: Monday, November 08, 2004 1:43=20 PM
To: 'GARCIN Sebastien RD-CORE-ISS';=20 sip@ietf.org
Subject: RE: [Sip] Privacy statements and = History=20 (draft-ietf-sip-history-info-04.txt)

S=E9bastien,
 
Thanks for reviewing the draft; my response = to your=20 comments is embedded below [MB].
 
Mary
-----Original Message-----
From: = GARCIN=20 Sebastien RD-CORE-ISS [mailto:sebastien.garcin@francetelecom.com]=20
Sent: Monday, November 08, 2004 10:11 AM
To: = Barnes,=20 Mary [NGC:B601:EXCH]; sip@ietf.org
Subject: [Sip] Privacy=20 statements and History=20 (draft-ietf-sip-history-info-04.txt)

Hi mary, all
 
When=20 reading draft-ietf-sip-history-info-04.txt, I have trouble = in=20 understanding some of the statements which relate to the forwarding=20 rules for history-entries subject to = privacy. It is=20 an important requirement that History-entrie(s) = with a=20 Privacy=3Dhistory, session, or header are indeed = forwarded to=20 entities which belong to the same trust domain. The = removal=20 of specific history-entries should only occur if the peer does = not=20 belong to the trust domain.
 
In = the current=20 text (section 4.3.3.1.1) :
If a request is  being = forwarded to a=20 Request URI associated with a domain for which the = proxy is not=20 responsible and there is a Privacy header in=20 the request with a = priv-value of "session", "header" or "history", the proxy MUST = remove=20 any hi-entry(s) prior to forwarding.
 
The current wording is = misleading since=20 it gives the impression (maybe intentionnal) that it is not possible = to=20 forward history-entries with Privacy statements to domains under the = responsability of e.g. another operator belonging to the same = trust=20 domain.  
 
[MB]: = Current wording is=20 consistent with terminology in RFC 3261 in terms of describing who = is able=20 to change the Request URI in a specific request (based = on section=20 16.5): 
   " A = proxy MUST NOT=20 add additional targets to the target set if the
   = Request-URI=20 of the original request does not indicate a resource = this
  =20 proxy is responsible for.

      A = proxy can=20 only change the Request-URI of a request=20 during
      forwarding if it is = responsible for=20 that URI. "
Since = History-Info (and=20 associated privacy) are only added to the request, when=20 an entity that is allowed to change the Request-URI = retargets the=20 request, it seemed sensible to use consistent wording to explain = that. =20  
[/MB] 
 [SG] I have = no problem=20 with the statements above. My concern is that if there is=20 a hi-entry already embedded in the request with a = Privacy=20 statement, then, it should be up to local policy to decide = whether or=20 not a proxy shall pass on those hi-entries to a trusted domain. = The=20 sentence in section 4.3.3.1.1 precludes this. I would propose = to=20 lighten the strenght of the sentence as=20 follows:
 
If=20 a request is  being forwarded to a Request URI associated with=20 a domain for which the proxy is not = responsible and=20 there is a Privacy header in the request with a priv-value of "session", = "header" or=20 "history", the proxy MAY remove any hi-entry(s) prior to=20 forwarding.
 
[SG] Another = issue is the=20 decision to add hi-entries in a privacy context. A proxy = changing the=20 target (i.e. the proxy is responsible of the resource reflected in = the=20 received Request-URI) of a request which contained a=20 "privacy=3Dhistory" header MAY add a = history-entries provided=20 that it knows it can rely on other entities within = the trust=20 domain to apply the requested privacy. This affect item 4 in the = list on=20 conditions of section 4.3.3 and 4.3.3.1.=20
 
The concept of "trust = domain" should=20 be used when discussing the forwarding rules = pertaining to=20 information subject to privacy. Furthermore, the requirement = for=20 forwarding history-entries to trusted entities should be stated = more=20 clearly in the draft. 
[MB]: The whole concept of what defines = privacy in=20 terms of the proxy's use of the privacy header is outside the scope = of=20 History-Info functionality and really a matter of local policy. =   I=20 think the functionality that you want is a matter of local = implementation=20 and policy in terms of operators establishing this "trust = domain"=20 model to which you refer.  History-Info defines the = mechanism=20 to ensure the privacy of the requests, but it = doesn't explicitly=20 define how the proxy knows whether it is responsible for that=20 resource.    I don't think this is a matter of=20 standardization.  I thought the use of the term "domain" rather = than=20 "resouce" would be helpful, but perhaps changing it to the more = general=20 "resource" would resolve this concern and/or a statement clarifying = what=20 I've just described should be added in the draft. =
[/MB]
[SG]   Changing the=20 term "domain" to "resource" does not solve the problem I = mentionned=20 above. In order to reflect current operator requirements, = the=20 draft should not PRECLUDE the fowarding of existing history = information=20 towards trusted=20 = domains.
 
Thank you for clarifying this=20 point.
 
Best regards,
s=E9bastien
 
 

------Remainder of non-related part of this thread has been = deleted=20 by=20 Mary------------------
------_=_NextPart_001_01C4C641.D900A5A4-- --===============0212921545== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0212921545==-- From sip-bounces@ietf.org Tue Nov 9 07:04:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16114 for ; Tue, 9 Nov 2004 07:04:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRUkS-0000vL-Cx for sip-web-archive@ietf.org; Tue, 09 Nov 2004 07:05:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRUig-0007Ku-0x; Tue, 09 Nov 2004 07:03:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRUhD-0007EF-Js for sip@megatron.ietf.org; Tue, 09 Nov 2004 07:01:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15695 for ; Tue, 9 Nov 2004 07:01:56 -0500 (EST) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRUhn-0000qn-5K for sip@ietf.org; Tue, 09 Nov 2004 07:02:45 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iA9C1lR2021434 for ; Tue, 9 Nov 2004 13:01:47 +0100 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 9 Nov 2004 13:01:46 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 9 Nov 2004 13:01:46 +0100 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'Christian Stredicke'" , fluffy@cisco.com Subject: RE: [Sip] PING/PONG Date: Tue, 9 Nov 2004 12:36:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-OriginalArrivalTime: 09 Nov 2004 12:01:46.0789 (UTC) FILETIME=[E3195550:01C4C653] X-Spam-Score: 0.6 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1112080699==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1112080699== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C650.5C343A0E" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4C650.5C343A0E Content-Type: text/plain; charset="iso-8859-1" Hi, I don't have anything PING, but no matter how short and effective (in the number of SIP headers etc) we make it it is still pretty "heavy" on the network. I think we should, as I said yesterday, at least have a look at an option which "combines" CRLF and PING (or whatever method is used), ie a UA can send CRLF every X seconds, and PING every n*X seconds. Of course, using a combined mechanism would mean that it would take longer to detect a NAT failure, in case the NAT binding goes done while the UA sends CRLF. But, we also have to remember, that eventhough PING would have a response (which CRLC does not have), due to the transcation timeout- and re-transmission timers it would still take a while (until the transcation expires) to figure out that the NAT binding has been closed. Regards, Christer Holmberg Ericsson Finland -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of Christian Stredicke Sent: 8. marraskuuta 2004 23:31 To: fluffy@cisco.com Cc: sip@ietf.org Subject: [Sip] PING/PONG Hello Cullen, I think it is no harm if there is a PING message defined in SIP. I personally think it is overdue anyway. Implementors can then decide if they are using it or not. Lets leave that decision to the implementors! But we have to consider who is sending keep-alive traffic. "IMHO" is it definitely better if the UA does this, because then e.g. usually it is ok to send CRLF keep alive or STUN. We register with a header that incates (a) that the UA is able to do the refreshing and (b) what the proposed refresh time is. The UA can do all these tricky NAT measurement tricks and then propose the refresh time. Stupid UA may just propose a predefined value, e.g. 20 seconds. The registrar (or whatever is in the path) then can acknowlege the refresh role and leave the refreshing to the UA. Otherwise, it will send the refresh messages. In that case, it will probably use PING, cause it needs a response to keep the NAT alive in all cases - even if it is a "503 Not Implemented". Christian ------_=_NextPart_001_01C4C650.5C343A0E Content-Type: text/html; charset="iso-8859-1"
Hi,
 
I don't have anything PING, but no matter how short and effective (in the number of SIP headers etc) we make it it is still pretty "heavy" on the network.
 
I think we should, as I said yesterday, at least have a look at an option which "combines" CRLF and PING (or whatever method is used), ie a UA can send CRLF every X seconds, and PING every n*X seconds.
 
Of course, using a combined mechanism would mean that it would take longer to detect a NAT failure, in case the NAT binding goes done while the UA sends CRLF.
 
But, we also have to remember, that eventhough PING would have a response (which CRLC does not have), due to the transcation timeout- and re-transmission timers it would still take a while (until the transcation expires) to figure out that the NAT binding has been closed.
 
Regards,
 
Christer Holmberg
Ericsson Finland
 
 
 
 
 -----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of Christian Stredicke
Sent: 8. marraskuuta 2004 23:31
To: fluffy@cisco.com
Cc: sip@ietf.org
Subject: [Sip] PING/PONG

Hello Cullen,
 
I think it is no harm if there is a PING message defined in SIP. I personally think it is overdue anyway. Implementors can then decide if they are using it or not. Lets leave that decision to the implementors!
 
But we have to consider who is sending keep-alive traffic. "IMHO" is it definitely better if the UA does this, because then e.g. usually it is ok to send CRLF keep alive or STUN.
 
We register with a header that incates (a) that the UA is able to do the refreshing and (b) what the proposed refresh time is. The UA can do all these tricky NAT measurement tricks and then propose the refresh time. Stupid UA may just propose a predefined value, e.g. 20 seconds. The registrar (or whatever is in the path) then can acknowlege the refresh role and leave the refreshing to the UA. Otherwise, it will send the refresh messages. In that case, it will probably use PING, cause it needs a response to keep the NAT alive in all cases - even if it is a "503 Not Implemented".
 
Christian
 
------_=_NextPart_001_01C4C650.5C343A0E-- --===============1112080699== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1112080699==-- From sip-bounces@ietf.org Tue Nov 9 07:25:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18358 for ; Tue, 9 Nov 2004 07:25:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRV4m-0001Tn-OF for sip-web-archive@ietf.org; Tue, 09 Nov 2004 07:26:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRUwl-0001Dm-Lw; Tue, 09 Nov 2004 07:18:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRUwP-00015X-HJ for sip@megatron.ietf.org; Tue, 09 Nov 2004 07:17:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17605 for ; Tue, 9 Nov 2004 07:17:38 -0500 (EST) Received: from firewall.citel.com ([62.190.107.60] helo=ivor.citel.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CRUwz-0001GE-4h for sip@ietf.org; Tue, 09 Nov 2004 07:18:27 -0500 Content-Class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: [Sip] PING/PONG Date: Tue, 9 Nov 2004 12:14:44 -0000 Message-ID: Thread-Topic: [Sip] PING/PONG Thread-Index: AcTGVK9I0LqupMtPR4ePO2+jlFpEpgAAPYGA From: "Steve Langstaff" To: X-Spam-Score: 0.6 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0317071365==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798 This is a multi-part message in MIME format. --===============0317071365== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C655.B2DAD5F8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4C655.B2DAD5F8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Doesn't the OPTIONS message do this job (of keeping a link 'alive')? =20 --=20 Steve Langstaff.=20 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of = Christer Holmberg (JO/LMF) Sent: 09 November 2004 11:37 To: 'Christian Stredicke'; fluffy@cisco.com Cc: sip@ietf.org Subject: RE: [Sip] PING/PONG Hi, =20 I don't have anything PING, but no matter how short and effective (in = the number of SIP headers etc) we make it it is still pretty "heavy" on = the network. =20 I think we should, as I said yesterday, at least have a look at an = option which "combines" CRLF and PING (or whatever method is used), ie a = UA can send CRLF every X seconds, and PING every n*X seconds. =20 Of course, using a combined mechanism would mean that it would take = longer to detect a NAT failure, in case the NAT binding goes done while = the UA sends CRLF.=20 =20 But, we also have to remember, that eventhough PING would have a = response (which CRLC does not have), due to the transcation timeout- and = re-transmission timers it would still take a while (until the = transcation expires) to figure out that the NAT binding has been closed. =20 Regards, =20 Christer Holmberg Ericsson Finland =20 =20 =20 =20 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of = Christian Stredicke Sent: 8. marraskuuta 2004 23:31 To: fluffy@cisco.com Cc: sip@ietf.org Subject: [Sip] PING/PONG Hello Cullen, =20 I think it is no harm if there is a PING message defined in SIP. I = personally think it is overdue anyway. Implementors can then decide if = they are using it or not. Lets leave that decision to the implementors! =20 But we have to consider who is sending keep-alive traffic. "IMHO" is it = definitely better if the UA does this, because then e.g. usually it is = ok to send CRLF keep alive or STUN. =20 We register with a header that incates (a) that the UA is able to do the = refreshing and (b) what the proposed refresh time is. The UA can do all = these tricky NAT measurement tricks and then propose the refresh time. = Stupid UA may just propose a predefined value, e.g. 20 seconds. The = registrar (or whatever is in the path) then can acknowlege the refresh = role and leave the refreshing to the UA. Otherwise, it will send the = refresh messages. In that case, it will probably use PING, cause it = needs a response to keep the NAT alive in all cases - even if it is a = "503 Not Implemented". =20 Christian =20 ------_=_NextPart_001_01C4C655.B2DAD5F8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Doesn't the OPTIONS message do this job (of = keeping a=20 link 'alive')?
 

--
Steve=20 Langstaff.

-----Original Message-----
From: sip-bounces@ietf.org = [mailto:sip-bounces@ietf.org]On Behalf Of Christer Holmberg=20 (JO/LMF)
Sent: 09 November 2004 11:37
To: 'Christian = Stredicke'; fluffy@cisco.com
Cc: = sip@ietf.org
Subject: RE:=20 [Sip] PING/PONG

Hi,
 
I=20 don't have anything PING, but no matter how short and effective (in the = number=20 of SIP headers etc) we make it it is still pretty "heavy" on the=20 network.
 
I=20 think we should, as I said yesterday, at least have a look at an option = which=20 "combines" CRLF and PING (or whatever method is used), ie a UA can send = CRLF=20 every X seconds, and PING every n*X seconds.
 
Of=20 course, using a combined mechanism would mean that it would take longer = to=20 detect a NAT failure, in case the NAT binding goes done while the UA = sends CRLF.=20
 
But,=20 we also have to remember, that eventhough PING would have a = response (which=20 CRLC does not have), due to the transcation timeout- and re-transmission = timers=20 it would still take a while (until the transcation expires) to = figure out=20 that the NAT binding has been closed.
 
Regards,
 
Christer Holmberg
Ericsson Finland
 
 
 
 
 -----Original=20 Message-----
From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org]On Behalf Of Christian=20 Stredicke
Sent: 8. marraskuuta 2004 23:31
To:=20 fluffy@cisco.com
Cc: sip@ietf.org
Subject: [Sip]=20 PING/PONG

Hello=20 Cullen,
 
I = think it is no=20 harm if there is a PING message defined in SIP. I personally think it = is=20 overdue anyway. Implementors can then decide if they are using it or = not. Lets=20 leave that decision to the implementors!
 
But we have to=20 consider who is sending keep-alive traffic. "IMHO" is it definitely = better if=20 the UA does this, because then e.g. usually it is ok to send CRLF keep = alive=20 or STUN.
 
We = register with=20 a header that incates (a) that the UA is able to do the refreshing and = (b)=20 what the proposed refresh time is. The UA can do all these tricky NAT=20 measurement tricks and then propose the refresh time. Stupid UA may = just=20 propose a predefined value, e.g. 20 seconds. The registrar (or = whatever is in=20 the path) then can acknowlege the refresh role and leave the = refreshing to the=20 UA. Otherwise, it will send the refresh messages. In that case, it = will=20 probably use PING, cause it needs a response to keep the NAT alive in = all=20 cases - even if it is a "503 Not Implemented".
 
Christian
 
= ------_=_NextPart_001_01C4C655.B2DAD5F8-- --===============0317071365== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0317071365==-- From sip-bounces@ietf.org Tue Nov 9 07:42:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19842 for ; Tue, 9 Nov 2004 07:42:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRVLa-0001si-KQ for sip-web-archive@ietf.org; Tue, 09 Nov 2004 07:43:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRVJG-0004Gp-FE; Tue, 09 Nov 2004 07:41:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRVBJ-0003gM-NW for sip@megatron.ietf.org; Tue, 09 Nov 2004 07:33:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19117 for ; Tue, 9 Nov 2004 07:33:04 -0500 (EST) Received: from s-utl01-dcpop.stsn.com ([63.240.218.73]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CRVBu-0001g6-3x for sip@ietf.org; Tue, 09 Nov 2004 07:33:52 -0500 Received: from dcpop.smtp.stsn.com ([127.0.0.1]) by s-utl01-dcpop.stsn.com (SAVSMTP 3.1.0.29) with SMTP id M2004110907324811539 for ; Tue, 09 Nov 2004 07:32:48 -0500 Received: from BPenfield2 ([10.67.87.87]) by dcpop.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 9 Nov 2004 07:32:47 -0500 Message-ID: <00b001c4c658$4e32f2c0$5757430a@BPenfield2> From: "Bob Penfield" To: "Christer Holmberg \(JO/LMF\)" , "'Christian Stredicke'" , References: Subject: Re: [Sip] PING/PONG Date: Tue, 9 Nov 2004 07:33:23 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-OriginalArrivalTime: 09 Nov 2004 12:32:47.0889 (UTC) FILETIME=[3866A810:01C4C658] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Christer Holmberg (JO/LMF)" > But, we also have to remember, that eventhough PING would > have a response (which CRLC does not have), due to the > transcation timeout- and re-transmission timers it would > still take a while (until the transcation expires) to > figure out that the NAT binding has been closed. > With UDP, the PING will create a new NAT binding and the server can update its mapping for the UA. With TCP, if you want to be able to detect that the NAT binding is gone on the order of a transaction timeout, you would need to send a PING every 32 seconds or so. Given that NAT bindings for TCP live longer than that, I don't see what the CRLF buys you. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 9 08:02:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21559 for ; Tue, 9 Nov 2004 08:02:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRVdv-0002UI-EN for sip-web-archive@ietf.org; Tue, 09 Nov 2004 08:02:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRVWa-0006IT-ID; Tue, 09 Nov 2004 07:55:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRVV8-000656-Rl for sip@megatron.ietf.org; Tue, 09 Nov 2004 07:53:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20932 for ; Tue, 9 Nov 2004 07:53:29 -0500 (EST) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRVVe-0002Aq-Ul for sip@ietf.org; Tue, 09 Nov 2004 07:54:17 -0500 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iA9CrIh5001571 for ; Tue, 9 Nov 2004 13:53:18 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 9 Nov 2004 13:53:18 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 9 Nov 2004 13:53:17 +0100 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'Bob Penfield'" , "'Christian Stredicke'" , fluffy@cisco.com Subject: RE: [Sip] PING/PONG Date: Tue, 9 Nov 2004 13:52:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 09 Nov 2004 12:53:18.0660 (UTC) FILETIME=[15FF6840:01C4C65B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Hi, >With UDP, the PING will create a new NAT binding and the >server can update its mapping for the UA. So will CRLF, won't it? The difference is that the UA will not be informed that the message has reached the destination (since there is no response), but the question is if we really would need that information for every keep-nat-binding message that we send (ie we use CRLF most of the time, and every now and then we use a SIP request to make sure that everything really works). >With TCP, if you want to be able to detect that the NAT binding is gone on >the order of a transaction timeout, you would need to send a >PING every 32 seconds or so. Given that NAT bindings for TCP live longer >than that, I don't see what the CRLF buys you. My point was that using PING you will not be able to detect problems immediately, since you will have to wait for the transaction timeout before you can determine that something is wrong. What I do NOT want to do is to send SIP requests too often, and therefor I was wondering if it would be possible to also use CRLF :) Regards, Christer Holmberg Ericsson Finland > > cheers, > (-:bob > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > bpenfield@acmepacket.com > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 9 08:24:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24108 for ; Tue, 9 Nov 2004 08:24:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRVzh-0003FD-Fj for sip-web-archive@ietf.org; Tue, 09 Nov 2004 08:25:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRVwv-0002bT-N7; Tue, 09 Nov 2004 08:22:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRVmK-0000Ql-FR for sip@megatron.ietf.org; Tue, 09 Nov 2004 08:11:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22754 for ; Tue, 9 Nov 2004 08:11:18 -0500 (EST) Received: from natnoddy.rzone.de ([81.169.145.166]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRVn2-0002sF-D2 for sip@ietf.org; Tue, 09 Nov 2004 08:12:07 -0500 Received: from snom.de (pD95686F1.dip.t-dialin.net [217.86.134.241]) by post.webmailer.de (8.13.1/8.13.1) with ESMTP id iA9DBA9Q004666; Tue, 9 Nov 2004 14:11:11 +0100 (MET) Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] PING/PONG X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 9 Nov 2004 14:14:53 +0100 Message-ID: Thread-Topic: [Sip] PING/PONG thread-index: AcTGVeD72vlivuzXRNmVFA8//spI5wABZoOg From: "Christian Stredicke" To: "Christer Holmberg \(JO/LMF\)" , X-Spam-Score: 0.8 (/) X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0208285681==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: be922d419820e291bde1362184dc32fd This is a multi-part message in MIME format. --===============0208285681== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C65E.19ABB388" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4C65E.19ABB388 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All I am saying is lets define the tool "PING", if and how implementors are using it is up to them. =20 The other question is who sends the keep-alive. I would be good if the UA does that job, but it is not backward compatible with the specs that I know. There we need to specify something. =20 CS ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Christer Holmberg (JO/LMF) Sent: Tuesday, November 09, 2004 7:16 AM To: Christian Stredicke; fluffy@cisco.com Cc: sip@ietf.org Subject: RE: [Sip] PING/PONG =09 =09 Hi, =20 I don't have anything PING, but no matter how short and effective (in the number of SIP headers etc) we make it it is still pretty "heavy" on the network. =20 I think we should, as I said yesterday, at least have a look at an option which "combines" CRLF and PING (or whatever method is used), ie a UA can send CRLF every X seconds, and PING every n*X seconds. =20 Of course, using a combined mechanism would mean that it would take longer to detect a NAT failure, in case the NAT binding goes done while the UA sends CRLF.=20 =20 But, we also have to remember, that eventhough PING would have a response (which CRLC does not have), due to the transcation timeout- and re-transmission timers it would still take a while (until the transcation expires) to figure out that the NAT binding has been closed. =20 Regards, =20 Christer Holmberg Ericsson Finland =20 =20 =20 =20 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of Christian Stredicke Sent: 8. marraskuuta 2004 23:31 To: fluffy@cisco.com Cc: sip@ietf.org Subject: [Sip] PING/PONG =09 =09 Hello Cullen, =20 I think it is no harm if there is a PING message defined in SIP. I personally think it is overdue anyway. Implementors can then decide if they are using it or not. Lets leave that decision to the implementors! =20 But we have to consider who is sending keep-alive traffic. "IMHO" is it definitely better if the UA does this, because then e.g. usually it is ok to send CRLF keep alive or STUN. =20 We register with a header that incates (a) that the UA is able to do the refreshing and (b) what the proposed refresh time is. The UA can do all these tricky NAT measurement tricks and then propose the refresh time. Stupid UA may just propose a predefined value, e.g. 20 seconds. The registrar (or whatever is in the path) then can acknowlege the refresh role and leave the refreshing to the UA. Otherwise, it will send the refresh messages. In that case, it will probably use PING, cause it needs a response to keep the NAT alive in all cases - even if it is a "503 Not Implemented". =20 Christian =20 ------_=_NextPart_001_01C4C65E.19ABB388 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
All I am saying is lets define the tool "PING", = if and how implementors are using it = is up to=20 them.
 
The other question is who = sends the=20 keep-alive. I would be good if the UA does that job, but it is not = backward=20 compatible with the specs that I know. There we need to specify=20 something.
 
CS

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Christer Holmberg=20 (JO/LMF)
Sent: Tuesday, November 09, 2004 7:16 = AM
To:=20 Christian Stredicke; fluffy@cisco.com
Cc:=20 sip@ietf.org
Subject: RE: [Sip] = PING/PONG

Hi,
 
I=20 don't have anything PING, but no matter how short and effective (in = the number=20 of SIP headers etc) we make it it is still pretty "heavy" on the=20 network.
 
I=20 think we should, as I said yesterday, at least have a look at an = option which=20 "combines" CRLF and PING (or whatever method is used), ie a UA can = send CRLF=20 every X seconds, and PING every n*X seconds.
 
Of=20 course, using a combined mechanism would mean that it would take = longer to=20 detect a NAT failure, in case the NAT binding goes done while the UA = sends=20 CRLF.
 
But,=20 we also have to remember, that eventhough PING would have a = response=20 (which CRLC does not have), due to the transcation timeout- and=20 re-transmission timers it would still take a while (until the = transcation=20 expires) to figure out that the NAT binding has been=20 closed.
 
Regards,
 
Christer Holmberg
Ericsson Finland
 
 
 
 
 -----Original = Message-----
From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org]On Behalf Of Christian=20 Stredicke
Sent: 8. marraskuuta 2004 23:31
To:=20 fluffy@cisco.com
Cc: sip@ietf.org
Subject: [Sip] = PING/PONG

Hello=20 Cullen,
 
I think it is=20 no harm if there is a PING message defined in SIP. I personally = think it is=20 overdue anyway. Implementors can then decide if they are using it or = not.=20 Lets leave that decision to the implementors!
 
But we have to=20 consider who is sending keep-alive traffic. "IMHO" is it definitely = better=20 if the UA does this, because then e.g. usually it is ok to send CRLF = keep=20 alive or STUN.
 
We register=20 with a header that incates (a) that the UA is able to do the = refreshing and=20 (b) what the proposed refresh time is. The UA can do all these = tricky NAT=20 measurement tricks and then propose the refresh time. Stupid UA may = just=20 propose a predefined value, e.g. 20 seconds. The registrar (or = whatever is=20 in the path) then can acknowlege the refresh role and leave the = refreshing=20 to the UA. Otherwise, it will send the refresh messages. In that = case, it=20 will probably use PING, cause it needs a response to keep the NAT = alive in=20 all cases - even if it is a "503 Not = Implemented".
 
Christian
 
<= /BODY> ------_=_NextPart_001_01C4C65E.19ABB388-- --===============0208285681== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0208285681==-- From sip-bounces@ietf.org Tue Nov 9 08:36:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25238 for ; Tue, 9 Nov 2004 08:36:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRWB5-0003YT-MD for sip-web-archive@ietf.org; Tue, 09 Nov 2004 08:36:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRW8K-0004aB-2h; Tue, 09 Nov 2004 08:34:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRW0k-0003VI-Lz for sip@megatron.ietf.org; Tue, 09 Nov 2004 08:26:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24268 for ; Tue, 9 Nov 2004 08:26:13 -0500 (EST) From: hisham.khartabil@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRW1U-0003I8-Bu for sip@ietf.org; Tue, 09 Nov 2004 08:27:01 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA9DQ7v26233; Tue, 9 Nov 2004 15:26:07 +0200 (EET) X-Scanned: Tue, 9 Nov 2004 15:25:51 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id iA9DPpmP019394; Tue, 9 Nov 2004 15:25:51 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00FZXzzV; Tue, 09 Nov 2004 15:24:40 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA9DOUa17727; Tue, 9 Nov 2004 15:24:30 +0200 (EET) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 9 Nov 2004 15:24:29 +0200 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 9 Nov 2004 15:24:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] GRUU Comments and interaction with outbound-connection Date: Tue, 9 Nov 2004 15:24:29 +0200 Message-ID: <5816828233DEFA41807A6CFDFDF2343C3A8C39@esebe056.ntc.nokia.com> Thread-Topic: [Sip] GRUU Comments and interaction with outbound-connection Thread-Index: AcTF5Y3I4dx6sZ8iRdKBwr7XppTqmAAeaRmw To: , X-OriginalArrivalTime: 09 Nov 2004 13:24:29.0557 (UTC) FILETIME=[7123A250:01C4C65F] X-Spam-Score: 0.3 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Cc: fluffy@cisco.com, sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable That's exactly what I was thinking. The Proxy/registrar can add the = actual contact of the recipient as the first entry in the target set. = That gets placed in the request-URI. Proxy routes to first route header = (EP) in this case. EP routes to end point. /Hisham > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On=20 > Behalf Of ext > Alan Hawrylyshen > Sent: 09.November.2004 00:18 > To: Jonathan Rosenberg > Cc: Cullen Jennings; sip@ietf.org > Subject: [Sip] GRUU Comments and interaction with outbound-connection >=20 >=20 > Re: the Edge Proxy, Reg/Prox RR problems.... >=20 > Johnathan; >=20 > It strikes me that the EP can directly route the GRUU since it is=20 > (except in the 3GPP case) in the same administrative / security /=20 > policy domain as the registrar and SHOULD be capable of detecting the=20 > GRUU's applicability when the initial request hits the EP. An=20 > appropriately constructed (encoded) GRUU could be decoded and dealt=20 > with as soon as it reaches the UA's EP, no? >=20 > And as I write this, Cullen has just proposed the same thing. >=20 > Alan >=20 >=20 >=20 > a l a n a t j a s o m i d o t c o m >=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 sip-bounces@ietf.org Tue Nov 9 08:47:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26278 for ; Tue, 9 Nov 2004 08:47:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRWLd-0003pC-9x for sip-web-archive@ietf.org; Tue, 09 Nov 2004 08:47:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRW8X-0004ho-98; Tue, 09 Nov 2004 08:34:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRW6w-0004GV-25 for sip@megatron.ietf.org; Tue, 09 Nov 2004 08:32:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24828 for ; Tue, 9 Nov 2004 08:32:36 -0500 (EST) Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRW7f-0003QG-RG for sip@ietf.org; Tue, 09 Nov 2004 08:33:25 -0500 Received: from BPenfield2 [130.129.135.118] by acmepacket.com with ESMTP (SMTPD32-8.13) id A8CF50F0364; Tue, 09 Nov 2004 08:40:31 -0500 Message-ID: <002201c4c660$948f0ee0$ec25fea9@BPenfield2> From: "Bob Penfield" To: "Christer Holmberg \(JO/LMF\)" , "'Christian Stredicke'" , References: Subject: Re: [Sip] PING/PONG Date: Tue, 9 Nov 2004 08:32:28 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Christer Holmberg (JO/LMF)" > > Hi, > > >With UDP, the PING will create a new NAT binding and the > >server can update its mapping for the UA. > > So will CRLF, won't it? The difference is that the UA will not be informed > that the message has reached the destination (since there is no response), > but the question is if we really would need that information for every > keep-nat-binding message that we send (ie we use CRLF most of the time, > and every now and then we use a SIP request to make sure that everything > really works). The CRLF does not contain enough information for the server to update its mapping for the UA. There could be many UAs behind the same NAT, so the server has no way to know which one it is. The CRLF will keep an existing binding open in the NAT, but it does not cover the case of a NAT reset. So the it depends on how long you are willing to live without a valid binding in the server for the UA, and that would be how often you would need to send a PING. You would only send CRLF too if that was longer than the binding lifetime in the NAT. > > >With TCP, if you want to be able to detect that the NAT binding is gone on > >the order of a transaction timeout, you would need to send a > >PING every 32 seconds or so. Given that NAT bindings for TCP live longer > >than that, I don't see what the CRLF buys you. > > My point was that using PING you will not be able to detect problems immediately, since you will have to wait for the transaction timeout before you can determine that something is wrong. > > What I do NOT want to do is to send SIP requests too often, and therefor I was wondering if it would be possible to also use CRLF :) > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > > > cheers, > > (-:bob > > > > Robert F. Penfield > > Chief Software Architect > > Acme Packet, Inc. > > 130 New Boston Street > > Woburn, MA 01801 > > bpenfield@acmepacket.com > > > > > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 9 09:13:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29902 for ; Tue, 9 Nov 2004 09:13:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRWl7-0004Yd-VK for sip-web-archive@ietf.org; Tue, 09 Nov 2004 09:14:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRWeO-0006dt-A6; Tue, 09 Nov 2004 09:07:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRWUt-0000CE-Sf for sip@megatron.ietf.org; Tue, 09 Nov 2004 08:57:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27838 for ; Tue, 9 Nov 2004 08:57:22 -0500 (EST) Received: from cluster-b.mailcontrol.com ([217.68.146.190] helo=rly07b.srv.mailcontrol.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRWVb-00045F-9r for sip@ietf.org; Tue, 09 Nov 2004 08:58:11 -0500 Received: from GBNEWP0758M.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly07b.srv.mailcontrol.com (MailControl) with ESMTP id iA9DuPV3018006; Tue, 9 Nov 2004 13:56:25 GMT X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] PING/PONG Date: Tue, 9 Nov 2004 13:45:49 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE03118566@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Sip] PING/PONG Thread-Index: AcTGVeD72vlivuzXRNmVFA8//spI5wABZoOgAAGeqgA= From: "Chris Boulton" To: "Christian Stredicke" , "Christer Holmberg (JO/LMF)" , X-Scanned-By: MailControl A-05-00-00 (www.mailcontrol.com) X-Spam-Score: 0.2 (/) X-Scan-Signature: 8136d1e28e0aab8a4e130297ed2e1fc4 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1020041952==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 6217cd54077d488d29096a65a152105e This is a multi-part message in MIME format... --===============1020041952== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C662.6C06ADA0" This is a multi-part message in MIME format... ------_=_NextPart_001_01C4C662.6C06ADA0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =20 All I am saying is lets define the tool "PING", if and how implementors are using it is up to them. =20 [Chris Boulton] Sorry if I am missing something BUT was does this buy you (That say OPTIONs doesn't)? IMHO wither we should use existing methods to achieve this OR go with the STUN option for both transport protocols - to keep it consistent.=20 =20 The other question is who sends the keep-alive. I would be good if the UA does that job, but it is not backward compatible with the specs that I know. There we need to specify something. =20 [Chris Boulton] Whatever we decide we shouldn't restrict it to 'one-way'. In different deployments and scenarios it should be possible for either entity to keep a connection alive. =20 CS =09=20 =09 _____=20=20 From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Christer Holmberg (JO/LMF) Sent: Tuesday, November 09, 2004 7:16 AM To: Christian Stredicke; fluffy@cisco.com Cc: sip@ietf.org Subject: RE: [Sip] PING/PONG Hi, =09=20 I don't have anything PING, but no matter how short and effective (in the number of SIP headers etc) we make it it is still pretty "heavy" on the network. =09=20 I think we should, as I said yesterday, at least have a look at an option which "combines" CRLF and PING (or whatever method is used), ie a UA can send CRLF every X seconds, and PING every n*X seconds. =09=20 Of course, using a combined mechanism would mean that it would take longer to detect a NAT failure, in case the NAT binding goes done while the UA sends CRLF.=20 =09=20 But, we also have to remember, that eventhough PING would have a response (which CRLC does not have), due to the transcation timeout- and re-transmission timers it would still take a while (until the transcation expires) to figure out that the NAT binding has been closed. =09=20 Regards, =09=20 Christer Holmberg Ericsson Finland =09=20 =09=20 =09=20 =09=09=20 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of Christian Stredicke Sent: 8. marraskuuta 2004 23:31 To: fluffy@cisco.com Cc: sip@ietf.org Subject: [Sip] PING/PONG Hello Cullen, =09=09=20 I think it is no harm if there is a PING message defined in SIP. I personally think it is overdue anyway. Implementors can then decide if they are using it or not. Lets leave that decision to the implementors! =09=09=20 But we have to consider who is sending keep-alive traffic. "IMHO" is it definitely better if the UA does this, because then e.g. usually it is ok to send CRLF keep alive or STUN. =09=09=20 We register with a header that incates (a) that the UA is able to do the refreshing and (b) what the proposed refresh time is. The UA can do all these tricky NAT measurement tricks and then propose the refresh time. Stupid UA may just propose a predefined value, e.g. 20 seconds. The registrar (or whatever is in the path) then can acknowlege the refresh role and leave the refreshing to the UA. Otherwise, it will send the refresh messages. In that case, it will probably use PING, cause it needs a response to keep the NAT alive in all cases - even if it is a "503 Not Implemented". =09=09=20 Christian =09=09=20 This email and any attached files are confidential and copyright protected.= If you are not the addressee, any dissemination, distribution or copying = of this communication is strictly prohibited. Unless otherwise expressly a= greed in writing, nothing stated in this communication shall be legally bin= ding. ------_=_NextPart_001_01C4C662.6C06ADA0 Content-Type: text/html; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

 

All I am saying is lets define the tool "PING<= span style=3D'font-size:10.0pt;font-family:Verdana;color:blue'>", <= b>if and how= implementors are using it is up to them.

 =

[Chris Boulton= ] Sorry if I am missing something BUT was does this buy you (That say OPTIONs doesn’t)?  IMHO wither we should use existing methods to achieve this OR go with the S= TUN option for both transport protocols – to keep it consistent. <= /font>

 

The other question is who sends the keep-alive. I would be good if the UA does that job, but it is not backward compatible with the specs that I know. There we need to specify something.

 

[Chris Boulton= ] Whatever we decide we shou= ldn’t restrict it to ‘one-way’.  In different deployments and scenarios it should be possible for either entity to keep a connection aliv= e.

 

CS

 

From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Christer Holmberg (JO/LMF)
Sent: Tuesday, November 09, = 2004 7:16 AM
To: Christian Stredicke; fluffy@cisco.com
Cc: sip@ietf.org
Subject: RE: [Sip] PING/PONG=

= Hi,

 

= I don't have anything PING= , but no matter how short and effective (in the number of SIP headers etc) we make it it is still pretty "heavy" on the network= .

 

= I think we should, as I said yesterday, at least have a look at an option which "combines" CRLF and PING= (or whatever method is used), ie a UA can send CRLF every X seconds, and PING= every n*X seconds.

 

= Of course, using a combined mechanism would mean that it would take longer to detect a NAT failure, in case the NAT binding goes done while the UA sends CRLF.

 

= But, we also have to remember, that eventhough PING would have a respo= nse (which CRLC does not have), due to the transcation timeout- and re-transmis= sion timers it would still take a while (until the transcation expires) to figure out that the NAT binding has been closed.

 

= Regards,

 

= Christer Holmberg

= Ericsson Finland

 

 

 

 

 -----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf = Of Christian Stredicke
Sent: 8. marraskuuta 2004 23:31=
To: fluffy@cisco.com
Cc: sip@ietf.org
Subject: [Sip] PING/PONG

Hello Cullen,<= /p>

 

I think it is no harm if the= re is a PING message defined in SIP. I personally think it is overdue anyway. Implementors can then decide if they= are using it or not. Lets leave that decision to the implementors!

 

But we have to consider who = is sending keep-alive traffic. "IMHO" is it definitely better if the= UA does this, because then e.g. usually it is ok to send CRLF keep alive or ST= UN.

 

We register with a header th= at incates (a) that the UA is able to do the refreshing and (b) what the propo= sed refresh time is. The UA can do all these tricky NAT measurement tricks and = then propose the refresh time. Stupid UA may just propose a predefined value, e.= g. 20 seconds. The registrar (or whatever is in the path) then can acknowlege = the refresh role and leave the refreshing to the UA. Otherwise, it will send the refresh messages. In that case, it will probably use PING, cause it needs a response to keep the NAT alive in all cases - even if it is a "503 Not Implemented".

 

Christian

 



This email and any attac= hed files are confidential and copyright protected.  If you are not th= e addressee, any dissemination, distribution or copying of this communicati= on is strictly prohibited.  Unless otherwise expressly agreed in writi= ng, nothing stated in this communication shall be legally binding.
 ------_=_NextPart_001_01C4C662.6C06ADA0-- --===============1020041952== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1020041952==-- From sip-bounces@ietf.org Tue Nov 9 10:25:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08861 for ; Tue, 9 Nov 2004 10:25:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRXt3-0006N0-Uz for sip-web-archive@ietf.org; Tue, 09 Nov 2004 10:26:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRXiE-0004x6-4v; Tue, 09 Nov 2004 10:15:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRXb9-0001gn-84 for sip@megatron.ietf.org; Tue, 09 Nov 2004 10:07:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06019 for ; Tue, 9 Nov 2004 10:07:52 -0500 (EST) Received: from natnoddy.rzone.de ([81.169.145.166]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRXbu-0005w1-3U for sip@ietf.org; Tue, 09 Nov 2004 10:08:42 -0500 Received: from snom.de (pD95686F1.dip.t-dialin.net [217.86.134.241]) by post.webmailer.de (8.13.1/8.13.1) with ESMTP id iA9F6kQD002916; Tue, 9 Nov 2004 16:06:47 +0100 (MET) Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] PING/PONG X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 9 Nov 2004 16:06:42 +0100 Message-ID: Thread-Topic: [Sip] PING/PONG thread-index: AcTGVeD72vlivuzXRNmVFA8//spI5wABZoOgAAGeqgAAAsmPsA== From: "Christian Stredicke" To: "Chris Boulton" , "Christer Holmberg \(JO/LMF\)" , X-Spam-Score: 0.6 (/) X-Scan-Signature: d1013c8bad83fa4e4ccb34a7376b19d5 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1083694966==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 04ebe73024b6be81174765e91aced811 This is a multi-part message in MIME format. --===============1083694966== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C66E.3FE9FFFE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4C66E.3FE9FFFE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Chris Boulton Sent: Tuesday, November 09, 2004 9:31 AM To: Christian Stredicke; Christer Holmberg (JO/LMF); fluffy@cisco.com Cc: sip@ietf.org Subject: RE: [Sip] PING/PONG =20 All I am saying is lets define the tool "PING", if and how implementors are using it is up to them. =20 [Chris Boulton] Sorry if I am missing something BUT was does this buy you (That say OPTIONs doesn't)? IMHO wither we should use existing methods to achieve this OR go with the STUN option for both transport protocols - to keep it consistent. =20 =20 (CS) OPTIONS has the problem that it is relatively expensive (size and CPU) and might result in responses that exceed the UDP fragmentation limit (there are many DSL routers that treat UDP fragmentation as security problem including the one that I have at home). Therefore I think it would not hurt to have a specific message that is designed only for the keep-alive job. =20 The other question is who sends the keep-alive. I would be good if the UA does that job, but it is not backward compatible with the specs that I know. There we need to specify something. =20 [Chris Boulton] Whatever we decide we shouldn't restrict it to 'one-way'. In different deployments and scenarios it should be possible for either entity to keep a connection alive.=20 =20 (CS) Sure. But the role has to be negotiated. If possible, the UA should do that job. If it is not able to do this (e.g. because it does not support refreshing) the fall back solution will always be that the network side has to do the job.=20 =20 CS =20 =09 ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Christer Holmberg (JO/LMF) Sent: Tuesday, November 09, 2004 7:16 AM To: Christian Stredicke; fluffy@cisco.com Cc: sip@ietf.org Subject: RE: [Sip] PING/PONG Hi, =20 I don't have anything PING, but no matter how short and effective (in the number of SIP headers etc) we make it it is still pretty "heavy" on the network. =20 I think we should, as I said yesterday, at least have a look at an option which "combines" CRLF and PING (or whatever method is used), ie a UA can send CRLF every X seconds, and PING every n*X seconds. =20 Of course, using a combined mechanism would mean that it would take longer to detect a NAT failure, in case the NAT binding goes done while the UA sends CRLF.=20 =20 But, we also have to remember, that eventhough PING would have a response (which CRLC does not have), due to the transcation timeout- and re-transmission timers it would still take a while (until the transcation expires) to figure out that the NAT binding has been closed. =20 Regards, =20 Christer Holmberg Ericsson Finland =20 =20 =20 =20 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of Christian Stredicke Sent: 8. marraskuuta 2004 23:31 To: fluffy@cisco.com Cc: sip@ietf.org Subject: [Sip] PING/PONG Hello Cullen, =20 I think it is no harm if there is a PING message defined in SIP. I personally think it is overdue anyway. Implementors can then decide if they are using it or not. Lets leave that decision to the implementors! =20 But we have to consider who is sending keep-alive traffic. "IMHO" is it definitely better if the UA does this, because then e.g. usually it is ok to send CRLF keep alive or STUN. =20 We register with a header that incates (a) that the UA is able to do the refreshing and (b) what the proposed refresh time is. The UA can do all these tricky NAT measurement tricks and then propose the refresh time. Stupid UA may just propose a predefined value, e.g. 20 seconds. The registrar (or whatever is in the path) then can acknowlege the refresh role and leave the refreshing to the UA. Otherwise, it will send the refresh messages. In that case, it will probably use PING, cause it needs a response to keep the NAT alive in all cases - even if it is a "503 Not Implemented". =20 Christian =20 =09 This email and any attached files are confidential and copyright protected. If you are not the addressee, any dissemination, distribution or copying of this communication is strictly prohibited. Unless otherwise expressly agreed in writing, nothing stated in this communication shall be legally binding. ------_=_NextPart_001_01C4C66E.3FE9FFFE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Chris = Boulton
Sent:=20 Tuesday, November 09, 2004 9:31 AM
To: Christian Stredicke; = Christer=20 Holmberg (JO/LMF); fluffy@cisco.com
Cc:=20 sip@ietf.org
Subject: RE: [Sip] PING/PONG

 

All I=20 am saying is lets define the tool "PING", = if=20 and how = implementors are=20 using it is up to them.

 

[Chris=20 Boulton]=20 Sorry if I am missing something BUT was does this buy you (That say = OPTIONs=20 doesn’t)?  IMHO wither we should use existing methods to = achieve this OR=20 go with the STUN option for both transport protocols – to keep = it=20 consistent.  

 

(CS) = OPTIONS has the=20 problem that it is relatively expensive (size and CPU) and might = result in=20 responses that exceed the UDP fragmentation limit (there are many DSL = routers=20 that treat UDP fragmentation as security problem including the one = that I have=20 at home). Therefore I think it would not hurt to have a specific = message that=20 is designed only for the keep-alive = job.

 

The=20 other question is who sends = the=20 keep-alive. I would be good if the UA does that job, but it is not = backward=20 compatible with the specs that I know. There we need to specify=20 something.

 

[Chris=20 Boulton]=20 Whatever we decide we shouldn’t restrict it to = ‘one-way’.  In different=20 deployments and scenarios it should be possible for either entity to = keep a=20 connection alive. 

 

(CS) = Sure. But the=20 role has to be negotiated. If possible, the UA should do that job. If = it is=20 not able to do this (e.g. because it does not support refreshing) the = fall=20 back solution will always be that the network side has to do the job.=20

 

CS

 

From: sip-bounces@ietf.org = [mailto:sip-bounces@ietf.org] On Behalf=20 Of Christer Holmberg (JO/LMF)
Sent: Tuesday, November 09, = 2004 7:16=20 AM
To: Christian = Stredicke;=20 fluffy@cisco.com
Cc:=20 sip@ietf.org
Subject: RE:=20 [Sip] PING/PONG

Hi,

 

I=20 don't have anything PING, but no = matter how=20 short and effective (in the number of SIP headers etc) we make it it = is=20 still pretty "heavy" on the network.

 

I=20 think we should, as I said yesterday, at least have a look at an = option=20 which "combines" CRLF and PING (or = whatever=20 method is used), ie a UA can send CRLF every X seconds, and=20 PING every = n*X=20 seconds.

 

Of=20 course, using a combined mechanism would mean that it would take = longer to=20 detect a NAT failure, in case the NAT binding goes done while the UA = sends=20 CRLF.

 

But,=20 we also have to remember, that eventhough PING would = have a=20 response (which CRLC does not have), due to the transcation timeout- = and=20 re-transmission timers it would still take a while (until the = transcation=20 expires) to figure out that the NAT binding has been=20 closed.

 

Regards,

 

Christer=20 Holmberg

Ericsson=20 Finland

 

 

 

 

 -----Original = Message-----
From:=20 sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of Christian=20 Stredicke
Sent: = 8.=20 marraskuuta 2004 23:31
To: = fluffy@cisco.com
Cc: = sip@ietf.org
Subject: [Sip]=20 PING/PONG

Hello=20 Cullen,

 

I = think it is=20 no harm if there is a PING=20 message defined in SIP. I personally think it is overdue anyway.=20 Implementors can then decide if they are using it or not. Lets = leave that=20 decision to the implementors!

 

But = we have to=20 consider who is sending keep-alive traffic. "IMHO" is it = definitely better=20 if the UA does this, because then e.g. usually it is ok to send = CRLF keep=20 alive or STUN.

 

We = register=20 with a header that incates (a) that the UA is able to do the = refreshing=20 and (b) what the proposed refresh time is. The UA can do all these = tricky=20 NAT measurement tricks and then propose the refresh time. Stupid = UA may=20 just propose a predefined value, e.g. 20 seconds. The registrar = (or=20 whatever is in the path) then can acknowlege the refresh role and = leave=20 the refreshing to the UA. Otherwise, it will send the refresh = messages. In=20 that case, it will probably use PING,=20 cause it needs a response to keep the NAT alive in all cases - = even if it=20 is a "503 Not Implemented".

 

Christian

 


<= BR>
This email and any = attached files=20 are confidential and copyright protected.  If you are not the = addressee,=20 any dissemination, distribution or copying of this communication is = strictly=20 prohibited.  Unless otherwise expressly agreed in writing, = nothing stated=20 in this communication shall be legally=20 binding.
------_=_NextPart_001_01C4C66E.3FE9FFFE-- --===============1083694966== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1083694966==-- From sip-bounces@ietf.org Tue Nov 9 11:46:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18474 for ; Tue, 9 Nov 2004 11:46:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRZ9Z-0000Gr-Tq for sip-web-archive@ietf.org; Tue, 09 Nov 2004 11:47:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRZ2k-0002rV-Bq; Tue, 09 Nov 2004 11:40:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRYs9-0000hS-3x for sip@megatron.ietf.org; Tue, 09 Nov 2004 11:29:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16402 for ; Tue, 9 Nov 2004 11:29:30 -0500 (EST) Received: from [62.119.82.41] (helo=mailserver.hotsip.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRYse-00088q-Di for sip@ietf.org; Tue, 09 Nov 2004 11:30:18 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] PING/PONG [bcc][faked-from][heur] Date: Tue, 9 Nov 2004 17:25:51 +0100 Message-ID: Thread-Topic: [Sip] PING/PONG [bcc][faked-from][heur] Thread-Index: AcTGVeD72vlivuzXRNmVFA8//spI5wABZoOgAAGeqgAAAsmPsAACDlgg From: "Christian Jansson" To: "Christian Stredicke" , "Chris Boulton" , "Christer Holmberg (JO/LMF)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable >>[Chris Boulton] Whatever we decide we shouldn't restrict it to = 'one-way'.=A0 In different deployments and scenarios it should be = possible for either >>entity to keep a connection alive.=A0 >=A0 >(CS) Sure. But the role has to be negotiated. If possible, the UA = should do that job. If it is not able to do this (e.g. because it does = not support >refreshing) the fall back solution will always be that the = network side has to do the job.=20 =A0 Does it really have to be negotiated? If we all think that refreshes = should be handled by the UA, why not decide that that is the only = standardized way to do it. Given that things have worked without this = negotiation for quite some time now, things will not get any worse just = because we write down a standardized way for a UA to do keep-alives. If = some UAs did not take the keep-alive issue in consideration before this = discussion begun, it could only mean two things: 1) The UA did not work in the real world, and I guess they would have = noticed that.=20 2) They used STUN/CRLF, invented something else, or perhaps they sent = OPTIONS/PING/??? from the server, which they can continue to do even = though it is not the documented way of doing it. Either they update = their UA according to "standard" keep-alives or they keep the = proprietary solution, and I don't think the standard for keep-alives = should try to compensate for all those solutions.=20 / 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 sip-bounces@ietf.org Tue Nov 9 11:50:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18781 for ; Tue, 9 Nov 2004 11:50:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRZCn-0000Nq-NR for sip-web-archive@ietf.org; Tue, 09 Nov 2004 11:50:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRZ69-00043b-6t; Tue, 09 Nov 2004 11:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRZ1F-0002HV-Re for sip@megatron.ietf.org; Tue, 09 Nov 2004 11:38:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17329 for ; Tue, 9 Nov 2004 11:38:55 -0500 (EST) Received: from firewall.citel.com ([62.190.107.60] helo=ivor.citel.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CRZ21-0008OD-F1 for sip@ietf.org; Tue, 09 Nov 2004 11:39:46 -0500 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] mib-08 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Date: Tue, 9 Nov 2004 16:36:33 -0000 Message-ID: Thread-Topic: [Sip] mib-08 Thread-Index: AcTFuztQjOZqupnYSc6GBdQTgtqTFgAvpfcA From: "Steve Langstaff" To: "Kevin Lingle" X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, Cullen Jennings X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable KL: "we need to move the I-D forward so we can get a RFC that can get = some implementation experience." I thought that the I-D phase was the time to get the implementation = experience. Is it your intention that the RFC will be "Experimental" or = "Informational" before getting this implementation experience, and then = become a standard afterwards?=20 -- Steve Langstaff. -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of Kevin Lingle Sent: 08 November 2004 17:26 To: Cullen Jennings Cc: sip@ietf.org Subject: Re: [Sip] mib-08 [snip] we need to move the I-D forward so we can get a RFC that can get some implementation experience. kevin _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 9 13:38:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28443 for ; Tue, 9 Nov 2004 13:38:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRatd-00030X-1E for sip-web-archive@ietf.org; Tue, 09 Nov 2004 13:39:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRapU-0000Bb-9g; Tue, 09 Nov 2004 13:34:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRalB-0007wa-JO for sip@megatron.ietf.org; Tue, 09 Nov 2004 13:30:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27798 for ; Tue, 9 Nov 2004 13:30:26 -0500 (EST) Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRaly-0002rW-Vd for sip@ietf.org; Tue, 09 Nov 2004 13:31:19 -0500 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iA9ISbEr008207 for ; Tue, 9 Nov 2004 13:28:37 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iA9IRHEr006873 for ; Tue, 9 Nov 2004 13:27:50 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] mib-08 Date: Tue, 9 Nov 2004 20:28:52 +0200 Message-ID: Thread-Topic: [Sip] mib-08 Thread-Index: AcTFuztQjOZqupnYSc6GBdQTgtqTFgAvpfcAAAPCHUA= From: "Romascanu, Dan \(Dan\)" To: "Steve Langstaff" , "Kevin Lingle" X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, Cullen Jennings X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable Steve, Actually implementation experience and interoperability is required only = when time comes to advance a standards track Proposed Standard to Draft = Standard phase. Although 'pre-standard' implementations are not = discouraged in I-D phase, one cannot ensure interoperable versions = before the standard, because the OID allocation for the root of the MIB = module under mib-2 is being performed by IANA only very late, prior to = the RFC publication. Whether the document will be a standards track, or not, is an IESG = decision based on the WG recommendation. =20 Regards, Dan > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On=20 > Behalf Of Steve Langstaff > Sent: 09 November, 2004 6:37 PM > To: Kevin Lingle > Cc: sip@ietf.org; Cullen Jennings > Subject: RE: [Sip] mib-08 >=20 >=20 > KL: "we need to move the I-D forward so we can get a RFC that=20 > can get some implementation experience." >=20 > I thought that the I-D phase was the time to get the=20 > implementation experience. Is it your intention that the RFC=20 > will be "Experimental" or "Informational" before getting this=20 > implementation experience, and then become a standard afterwards?=20 >=20 > -- > Steve Langstaff. >=20 >=20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > Kevin Lingle > Sent: 08 November 2004 17:26 > To: Cullen Jennings > Cc: sip@ietf.org > Subject: Re: [Sip] mib-08 > [snip] >=20 > we need to move the > I-D forward so we can get a RFC that can get some implementation > experience. >=20 > kevin >=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 sip-bounces@ietf.org Tue Nov 9 16:07:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12748 for ; Tue, 9 Nov 2004 16:07:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRdDV-0006eE-TD for sip-web-archive@ietf.org; Tue, 09 Nov 2004 16:07:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRdAX-0002zz-Rp; Tue, 09 Nov 2004 16:04:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRd9Z-0002UG-DE for sip@megatron.ietf.org; Tue, 09 Nov 2004 16:03:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12492 for ; Tue, 9 Nov 2004 16:03:47 -0500 (EST) Received: from natsmtp00.rzone.de ([81.169.145.165]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRdAK-0006Z1-Vd for sip@ietf.org; Tue, 09 Nov 2004 16:04:40 -0500 Received: from snom.de (pD95686F1.dip.t-dialin.net [217.86.134.241]) by post.webmailer.de (8.13.1/8.13.1) with ESMTP id iA9L2RSB014548; Tue, 9 Nov 2004 22:02:31 +0100 (MET) 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] PING/PONG [bcc][faked-from][heur] X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 9 Nov 2004 22:06:12 +0100 Message-ID: Thread-Topic: [Sip] PING/PONG [bcc][faked-from][heur] thread-index: AcTGVeD72vlivuzXRNmVFA8//spI5wABZoOgAAGeqgAAAsmPsAACDlggAAoKK4A= From: "Christian Stredicke" To: "Christian Jansson" , "Chris Boulton" , "Christer Holmberg \(JO/LMF\)" , X-Spam-Score: 0.2 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: quoted-printable Well, the negotiation who refreshes is more or less the question if you = have a legacy device or not. I totally agree, if there is no legacy device, the UA should refresh. But currently, there are only legacy devices or proprietary = implementations.-) Lets agree on a standard, that's why were are here. My proposal: A new header "Keep-Alive" in the REGISTER request: (A) Propose refresh every 15 seconds, offer methods stun, register, crlf REGISTER sip:snom.com SIP/2.0 Via: SIP/2.0/UDP 10.67.87.210:4064;branch=3Dz9hG4bK-g1gkta5je1yq;rport From: "Christian Stredicke" ;tag=3Dl3rj6dvhfl To: "Christian Stredicke" Call-ID: e52d914160a1-8yd3fpzu59l7@snom220 CSeq: 1 REGISTER Max-Forwards: 70 Contact: ;q=3D1.0 Keep-Alive: 15;method=3D"stun,crlf,register" Expires: 3600 Content-Length: 0 (B) Other party acknowledges and selects stun refreshes: SIP/2.0 200 Ok Via: SIP/2.0/UDP = 10.67.87.210:4064;branch=3Dz9hG4bK-hypaxu2640zy;rport=3D4064;received=3D1= 30.129.97.54 From: "Christian Stredicke" ;tag=3Dl3rj6dvhfl To: "Christian Stredicke" ;tag=3D0zikcb2fzo Call-ID: e52d914160a1-8yd3fpzu59l7@snom220 CSeq: 1 REGISTER Contact: ;expires=3D3600 Keep-Alive: 15;method=3D"stun" Content-Length: 0 CS=20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Christian Jansson > Sent: Tuesday, November 09, 2004 12:01 PM > To: Christian Stredicke; Chris Boulton; Christer Holmberg=20 > (JO/LMF); fluffy@cisco.com > Cc: sip@ietf.org > Subject: RE: [Sip] PING/PONG [bcc][faked-from][heur] >=20 >=20 >=20 > >>[Chris Boulton] Whatever we decide we shouldn't restrict it to=20 > >>'one-way'.=A0 In different deployments and scenarios it=20 > should be possible for either >>entity to keep a connection alive. > >=A0 > >(CS) Sure. But the role has to be negotiated. If possible,=20 > the UA should do that job. If it is not able to do this (e.g.=20 > because it does not support >refreshing) the fall back=20 > solution will always be that the network side has to do the job.=20 > =A0 > Does it really have to be negotiated? If we all think that=20 > refreshes should be handled by the UA, why not decide that=20 > that is the only standardized way to do it. Given that things=20 > have worked without this negotiation for quite some time now,=20 > things will not get any worse just because we write down a=20 > standardized way for a UA to do keep-alives. If some UAs did=20 > not take the keep-alive issue in consideration before this=20 > discussion begun, it could only mean two things: > 1) The UA did not work in the real world, and I guess they=20 > would have noticed that.=20 > 2) They used STUN/CRLF, invented something else, or perhaps=20 > they sent OPTIONS/PING/??? from the server, which they can=20 > continue to do even though it is not the documented way of=20 > doing it. Either they update their UA according to "standard"=20 > keep-alives or they keep the proprietary solution, and I=20 > don't think the standard for keep-alives should try to=20 > compensate for all those solutions.=20 >=20 > / Christian Jansson >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > 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 From sip-bounces@ietf.org Tue Nov 9 17:02:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18618 for ; Tue, 9 Nov 2004 17:02:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRe5I-0007zr-Ao for sip-web-archive@ietf.org; Tue, 09 Nov 2004 17:03:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRdy3-0003OK-Ri; Tue, 09 Nov 2004 16:55:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRdrD-0000OP-2e for sip@megatron.ietf.org; Tue, 09 Nov 2004 16:48:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17152 for ; Tue, 9 Nov 2004 16:48:52 -0500 (EST) Received: from dsl-dt-207-34-112-i195-cgy.nucleus.com ([207.34.112.195] helo=yyc.jasomi.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRds2-0007dx-3X for sip@ietf.org; Tue, 09 Nov 2004 16:49:46 -0500 Received: from [127.0.0.1] (yyc.jasomi.com [207.34.112.195]) by yyc.jasomi.com (8.12.9/8.12.6) with ESMTP id iA9LYwiJ020566; Tue, 9 Nov 2004 14:34:58 -0700 (MST) In-Reply-To: <5816828233DEFA41807A6CFDFDF2343C3A8C39@esebe056.ntc.nokia.com> References: <5816828233DEFA41807A6CFDFDF2343C3A8C39@esebe056.ntc.nokia.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Alan Hawrylyshen Subject: Re: [Sip] GRUU Comments and interaction with outbound-connection Date: Tue, 9 Nov 2004 16:52:20 -0500 To: hisham.khartabil@nokia.com X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: fluffy@cisco.com, sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit On Nov 9, 2004, at 08:24, hisham.khartabil@nokia.com wrote: > That's exactly what I was thinking. The Proxy/registrar can add the > actual contact of the recipient as the first entry in the target set. > That gets placed in the request-URI. Proxy routes to first route > header (EP) in this case. EP routes to end point. > > /Hisham Johnathan pointed out (verbally to myself when I mentioned this) that there are problems with the EP routing the request instead of sending it back to the 'registrar / proxy' that affect separation of services and that having the EP route to the endpoint directly breaks one of the reasons that you would want to separate the EP role and registrar role in the first place. I have to admit that due to room noise and having not written it down at that moment; I no longer recall specifics, but it strikes me as plausible and I would request that Johnathan add some text to this thread to help raise awareness of what breaks when the EP forwards the request directly to the end UA instead of spiralling. Thanks Alan a l a n a t j a s o m i d o t c o m _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 9 17:17:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20273 for ; Tue, 9 Nov 2004 17:17:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CReJb-0008Qr-8Y for sip-web-archive@ietf.org; Tue, 09 Nov 2004 17:18:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CReFa-00072H-8D; Tue, 09 Nov 2004 17:14:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRC8e-00089x-PG for sip@megatron.ietf.org; Mon, 08 Nov 2004 11:13:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25558 for ; Mon, 8 Nov 2004 11:13:01 -0500 (EST) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRC9C-0005Zb-KI for sip@ietf.org; Mon, 08 Nov 2004 11:13:40 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 8 Nov 2004 17:11:20 +0100 Content-class: urn:content-classes:message Subject: [Sip] Privacy statements and History (draft-ietf-sip-history-info-04.txt) MIME-Version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Mon, 8 Nov 2004 17:11:19 +0100 Message-ID: <49E7012A614B024B80A7D175CB9A64EC86C3E5@ftrdmel1.rd.francetelecom.fr> Thread-Topic: [Sip] Privacy statements and History (draft-ietf-sip-history-info-04.txt) Thread-Index: AcTBxZhnwyDV9PvFT6S7Q8K4iPqXgQD1K/JQ From: "GARCIN Sebastien RD-CORE-ISS" To: "Mary Barnes" , X-OriginalArrivalTime: 08 Nov 2004 16:11:20.0004 (UTC) FILETIME=[956AE040:01C4C5AD] X-Spam-Score: 0.9 (/) X-Scan-Signature: b4f8b2857a7a1a95c927652b5e03785d X-Mailman-Approved-At: Tue, 09 Nov 2004 17:14:04 -0500 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1713656677==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: b92e72fc2b623ddd11e6d81413fb81b2 This is a multi-part message in MIME format. --===============1713656677== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C5AD.944FAAE3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4C5AD.944FAAE3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi mary, all =20 When reading draft-ietf-sip-history-info-04.txt, I have trouble in = understanding some of the statements which relate to the forwarding = rules for history-entries subject to privacy. It is an important = requirement that History-entrie(s) with a Privacy=3Dhistory, session, or = header are indeed forwarded to entities which belong to the same trust = domain. The removal of specific history-entries should only occur if the = peer does not belong to the trust domain. =20 In the current text (section 4.3.3.1.1) : If a request is being forwarded to a Request URI associated with a = domain for which the proxy is not responsible and there is a Privacy = header in the request with a priv-value of "session", "header" or = "history", the proxy MUST remove any hi-entry(s) prior to forwarding.=20 =20 The current wording is misleading since it gives the impression (maybe = intentionnal) that it is not possible to forward history-entries with = Privacy statements to domains under the responsability of e.g. another = operator belonging to the same trust domain.=20 =20 The concept of "trust domain" should be used when discussing the = forwarding rules pertaining to information subject to privacy. = Furthermore, the requirement for forwarding history-entries to trusted = entities should be stated more clearly in the draft. =20 Thank you for clarifying this point. =20 Best regards, s=E9bastien =20 =20 ________________________________ De : sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] De la part de = Mary Barnes Envoy=E9 : mercredi 3 novembre 2004 17:29 =C0 : 'Takuya Sawada' Cc : 'sip@ietf.org' Objet : RE: FW: [Sip] I-D ACTION:draft-ietf-sip-history-info-04.txt Hi Takuya,=20 I apologize if I missed this specific point in your previous postings. = You are correct, that index of 2 should have been 1.1 and this actually = affects the whole series and also affects the examples in 4.5.1 and = 4.5.2. All the other entries are correct relative to the index of 2, = it's just the 2 should have been a 1.1, unless of course that proxy had = a good reason for starting at 2, which I don't explain so shouldn't use = in the example. =20 It looks like I introduced that error in the -01 version when I was = updating the example to include the index for all entries (as the index = was originally optional). I traced the change back to changes I made = during the middle of the day, so I can't even blame late nite editting. = I will definitely make a note of that and update that in the -05 = version, which will hopefully be the one to go to the IESG. I'm also copying the SIP list, so that folks are aware of this as they = review the document.=20 Thanks for your careful review,=20 Mary=20 -----Original Message-----=20 From: Takuya Sawada [mailto:tu-sawada@kddi.com]=20 Sent: Tuesday, November 02, 2004 4:29 AM=20 To: Barnes, Mary [NGC:B601:EXCH]=20 Subject: Re: FW: [Sip] I-D ACTION:draft-ietf-sip-history-info-04.txt=20 Hi Mary,=20 Each example flow in section 4.5 begins with the following messages,=20 UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5=20 =20 | | | | | | |=20 |--INVITE -->| | | | | |=20 | |-INVITE->| | | | |=20 Supported: Histinfo=20 History-Info: ;index=3D1,=20 ;index=3D2=20 I think this should be=20 UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5=20 =20 | | | | | | |=20 |--INVITE -->| | | | | |=20 | |-INVITE->| | | | |=20 Supported: Histinfo=20 History-Info: ;index=3D1,=20 ;index=3D1.1=20 Note that the index of the second hi-entry is 1.1.=20 I made the same comment to the list before, but no response to it.=20 In Appendix C, it shows,=20 UA1 Proxy ACDGRP1 Svr ACDGRP2 Svr UA2-ACDGRP2 = =20 =20 | | | | |=20 |--INVITE F1-->| | | |=20 Supported:Histinfo=20 | | | | |=20 | |--INVITE F2-->| | |=20 Supported:Histinfo=20 History-Info: ; index=3D1 =20 History-Info: ; index=3D1.1 = I can not find what is the difference between the two.=20 Are you saying that the former is "Retargeting within a Proxy" and the=20 latter is "Basic Forwarding"?=20 Am I missing something?=20 Thanks.=20 Regards,=20 Takuya=20 >=20 >=20 > Hi all,=20 >=20 > Since this version should be ready for WGLC, a very detailed list of = the=20 > changes is provided in the document, annotated as to the source, so I = won't=20 > repeat those details here. The majority of the changes were the = issues=20 > discussed at IETF-60, along with the agreements there to change the = text to=20 > non-normative in section 4 (Protocol structure) and to add some detail = per=20 > Rohan's comment on the necessary processing should TLS not be = available. In=20 > addition, I received some proposed changes on a marked up hardcopy at=20 > IETF-61 from Eric Burger. =20 >=20 > The only items not discussed at IETF-60 were 2 items that came up on = the=20 > list (one posted by John Elwell on August 18th on handling of privacy = in=20 > responses) the other on Oct. 15th around the appropriate character = format=20 > for the escaped headers in the URI. And, as always, there are various = minor=20 > editorial changes here and there while I was "in the area". So, there = > should be no surprises with any of the changes, although, it is = possible=20 > that there are still errors and nits that can be identified during = WGLC. =20 >=20 > Thanks,=20 > Mary=20 >=20 >=20 > -----Original Message-----=20 > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of=20 > Internet-Drafts@ietf.org=20 > Sent: Monday, October 25, 2004 3:07 PM=20 > To: i-d-announce@ietf.org=20 > Cc: sip@ietf.org=20 > Subject: [Sip] I-D ACTION:draft-ietf-sip-history-info-04.txt=20 >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories.=20 > This draft is a work item of the Session Initiation Protocol Working = Group=20 > of the IETF.=20 >=20 > Title : An Extension to the Session Initiation = Protocol=20 > for Request History Information=20 > Author(s) : M. Barnes=20 > Filename : draft-ietf-sip-history-info-04.txt=20 > Pages : 47=20 > Date : 2004-10-25=20 > =20 > This draft defines a standard mechanism for capturing the history=20 > information associated with a SIP request. This capability enables = > many enhanced services by providing the information as to how and = why=20 > a call arrives at a specific application or user. This draft = defines=20 > a new optional SIP header, History-Info, for capturing the history=20 > information in requests. A new option tag, Histinfo, to be included = > in the Supported header, is defined to allow UAs to indicate = whether=20 > the History-Info should be returned in responses to a request which = > has captured the history information. A new priv-value, history, is = > added to the Privacy header to allow for privacy handling of the=20 > History-Info header.=20 >=20 > A URL for this Internet-Draft is:=20 > http://www.ietf.org/internet-drafts/draft-ietf-sip-history-info-04.txt = >=20 > To remove yourself from the I-D Announcement list, send a message to=20 > i-d-announce-request@ietf.org with the word unsubscribe in the body of = the=20 > message. =20 > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce = > to change your subscription settings.=20 >=20 >=20 > Internet-Drafts are also available by anonymous FTP. Login with the = username=20 > "anonymous" and a password of your e-mail address. After logging in,=20 > type "cd internet-drafts" and then=20 > "get draft-ietf-sip-history-info-04.txt".=20 >=20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html=20 > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt=20 >=20 >=20 > Internet-Drafts can also be obtained by e-mail.=20 >=20 > Send a message to:=20 > mailserv@ietf.org.=20 > In the body type:=20 > "FILE /internet-drafts/draft-ietf-sip-history-info-04.txt".=20 > =20 > NOTE: The mail server at ietf.org can return the document in=20 > MIME-encoded form by using the "mpack" utility. To use this=20 > feature, insert the command "ENCODING mime" before the "FILE"=20 > command. To decode the response(s), you will need "munpack" or=20 > a MIME-compliant mail reader. Different MIME-compliant mail = readers=20 > exhibit different behavior, especially when dealing with=20 > "multipart" MIME messages (i.e. documents which have been split=20 > up into multiple messages), so check your local documentation on = > how to manipulate these messages.=20 > =20 > =20 > Below is the data which will enable a MIME compliant mail reader=20 > implementation to automatically retrieve the ASCII version of the=20 > Internet-Draft.=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________=20 > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip=20 > This list is for NEW development of the core SIP Protocol=20 > Use sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip=20 >=20 --------=20 Takuya Sawada=20 KDDI Corporation (KDDI)=20 Garden Air Tower, 3-10-10, Iidabashi,=20 Chiyoda-ku, Tokyo 102-8460, Japan=20 Tel: +81-3-6678-2997=20 Fax: +81-3-6678-0286=20 tu-sawada@kddi.com=20 ------_=_NextPart_001_01C4C5AD.944FAAE3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: FW: [Sip] I-D = ACTION:draft-ietf-sip-history-info-04.txt
Hi mary, all
 
When = reading draft-ietf-sip-history-info-04.txt,=20 I have trouble in understanding some of the statements which relate = to the=20 forwarding rules for history-entries subject to=20 privacy. It is an important=20 requirement that History-entrie(s) with a = Privacy=3Dhistory,=20 session, or header are indeed forwarded to entities which=20 belong to the same trust domain. The removal of specific=20 history-entries should only occur if the peer does not belong to = the trust=20 domain.
 
In the current text (section=20 4.3.3.1.1) :
If a request is  being forwarded to a Request URI = associated=20 with a domain for which the proxy is not = responsible and=20 there is a Privacy header in the request with a priv-value of "session", = "header" or=20 "history", the proxy MUST remove any hi-entry(s) prior to = forwarding.=20
 
The current wording is misleading since it gives the = impression=20 (maybe intentionnal) that it is not possible to forward history-entries = with=20 Privacy statements to domains under the responsability of e.g. = another=20 operator belonging to the same trust domain.
 
The concept of "trust domain" should be used = when=20 discussing the forwarding rules pertaining to information = subject to=20 privacy. Furthermore, the requirement for forwarding = history-entries to=20 trusted entities should be stated more clearly in the=20 draft.
 
Thank=20 you for clarifying this point.
 
Best=20 regards,
s=E9bastien
 
 

De : sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] De la part de Mary=20 Barnes
Envoy=E9 : mercredi 3 novembre 2004 = 17:29
=C0 :=20 'Takuya Sawada'
Cc : = 'sip@ietf.org'
Objet : RE:=20 FW: [Sip] I-D = ACTION:draft-ietf-sip-history-info-04.txt

Hi Takuya,

I apologize if I missed this specific point in your = previous=20 postings. You are correct, that index of 2 should have been 1.1 and = this =20 actually affects the whole series and also affects the examples in  = 4.5.1=20 and 4.5.2.  All the other entries are correct relative to the index = of 2,=20 it's just the 2 should have been a 1.1, unless of course that proxy had = a good=20 reason for starting at 2, which I don't explain so shouldn't use in the=20 example. 

It looks like I introduced that error in the -01 = version when I=20 was updating the example to include the index for all entries (as the = index was=20 originally optional). I traced the change back to changes I made during = the=20 middle of the day, so I can't even blame late nite editting.   = I will=20 definitely make a note of that and update that in the -05 version, which = will=20 hopefully be the one to go to the IESG.

I'm also copying the SIP list, so that folks are aware = of this=20 as they review the document.

Thanks for your careful review,
Mary


-----Original Message-----
From: Takuya=20 Sawada [mailto:tu-sawada@kddi.com]=20
Sent: Tuesday, November 02, 2004 4:29 = AM=20
To: Barnes, Mary [NGC:B601:EXCH]
Subject: Re: FW: [Sip] I-D=20 ACTION:draft-ietf-sip-history-info-04.txt


Hi Mary,

Each example flow in section 4.5 begins with the = following=20 messages,

   = UA1       =20 Proxy1  Proxy2     = UA2     =20 UA3      UA4      UA5=20
          &nbs= p;    =20
  =20 |           =20 |        =20 |       =20 |       =20 |       =20 |        |
   |--INVITE=20 -->|        =20 |       =20 |       =20 |       =20 |        |
  =20 |           =20 |-INVITE->|       =20 |       =20 |       =20 |        |
          &nbs= p;     =20 Supported: Histinfo
          &nbs= p;     =20 History-Info: <sip:Bob@P1.example.com>;index=3D1,
          &nbs= p;            = ;       =20 <sip:Bob@P2.example.com>;index=3D2

I think this should be

   = UA1       =20 Proxy1  Proxy2     = UA2     =20 UA3      UA4      UA5=20
          &nbs= p;    =20
  =20 |           =20 |        =20 |       =20 |       =20 |       =20 |        |
   |--INVITE=20 -->|        =20 |       =20 |       =20 |       =20 |        |
  =20 |           =20 |-INVITE->|       =20 |       =20 |       =20 |        |
          &nbs= p;     =20 Supported: Histinfo
          &nbs= p;     =20 History-Info: <sip:Bob@P1.example.com>;index=3D1,
          &nbs= p;            = ;       =20 <sip:Bob@P2.example.com>;index=3D1.1

Note that the index of the second hi-entry is = 1.1.=20
I made the same comment to the list before, but no = response to=20 it.

In Appendix C, it shows,

  =20 UA1         =20 Proxy        ACDGRP1 Svr   = ACDGRP2=20 Svr=20 UA2-ACDGRP2          &n= bsp;  =20
          &nbs= p;    =20
  =20 |            =  =20 |            =  =20 |            = =20 |          | =
   |--INVITE=20 F1-->|          &nbs= p;  =20 |            = =20 |          | =
    Supported:Histinfo
  =20 |            =  =20 |            =  =20 |            = =20 |          | =
  =20 |            =  =20 |--INVITE=20 F2-->|          &nbs= p; =20 |          | =
          &nbs= p;        =20 Supported:Histinfo
          &nbs= p;        =20 History-Info: <sip:Gold@example.com>; index=3D1  =
          &nbs= p;        =20 History-Info: <sip:ACDGRP1@example.com>; index=3D1.1

I can not find what is the difference between the = two.=20
Are you saying that the former is "Retargeting within = a =20 Proxy" and the
latter is "Basic = Forwarding"?=20
Am I missing something?

Thanks.

Regards,
Takuya

>
>
>=20 Hi all,
>
> = Since this=20 version should be ready for WGLC, a very detailed list of the =
> changes is provided in the document, annotated as to the = source, so=20 I won't
> repeat those details = here.   The=20 majority of the changes were the issues
> = discussed=20 at IETF-60, along with the agreements there to change the text to =
> non-normative in section 4 (Protocol structure) = and to add=20 some detail per
> Rohan's comment on the = necessary=20 processing should TLS not be available.  In
>=20 addition, I received some proposed changes on a marked up hardcopy = at=20
> IETF-61 from Eric Burger. 
>
> The only items not = discussed at IETF-60=20 were 2 items that came up on the
> list = (one posted=20 by John Elwell on August 18th on handling of privacy in
> responses) the other on Oct. 15th around the appropriate = character=20 format
> for the escaped headers in the = URI. And, as=20 always, there are various minor
> editorial = changes=20 here and there while I was "in the area".  So, there =
> should be no surprises with any of the changes, although, = it is=20 possible
> that there are still errors and = nits that=20 can be identified during WGLC.  
>=20
> Thanks,
> = Mary=20
>
>
>=20 -----Original Message-----
> From:=20 sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On = Behalf=20 Of
> Internet-Drafts@ietf.org =
> Sent: Monday, October 25, 2004 3:07 PM
>=20 To: i-d-announce@ietf.org
> Cc: = sip@ietf.org=20
> Subject: [Sip] I-D=20 ACTION:draft-ietf-sip-history-info-04.txt
> =
>
> A New = Internet-Draft=20 is available from the on-line Internet-Drafts
>=20 directories.
> This draft is a work item of = the=20 Session Initiation Protocol Working Group
> = of the=20 IETF.
>
>=20       Title  =20         : An Extension to the Session = Initiation Protocol
> for Request History=20 Information
> =      =20 Author(s)       : M. Barnes =
>      =20 Filename        :=20 draft-ietf-sip-history-info-04.txt
>=20       Pages  =20         : 47
>=20       Date   =20         : 2004-10-25
>      
> This=20 draft defines a standard mechanism for capturing the history =
>    information associated with a SIP = request. =20 This capability enables
>    = many=20 enhanced services by providing the information as to how and why=20
>    a call arrives at a = specific=20 application or user.  This draft defines
>    a new optional SIP header, History-Info, = for=20 capturing the history
>    = information=20 in requests. A new option tag, Histinfo, to be included
>    in the Supported header, is defined to = allow UAs=20 to indicate whether
>    the = History-Info should be returned in responses to a request which =
>    has captured the history information. A = new=20 priv-value, history, is
>    = added to=20 the Privacy header to allow for privacy handling of the
>    History-Info header.
>=20
> A URL for this Internet-Draft is: =
> http://www.ietf.org/internet-drafts/draft-ietf-sip-histor= y-info-04.txt=20
>
> To remove = yourself from the=20 I-D Announcement list, send a message to
>=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of=20 the
> message. 
> You=20 can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20
> to change your subscription = settings.=20
>
>
>=20 Internet-Drafts are also available by anonymous FTP. Login with the=20 username
> "anonymous" and a password of = your e-mail=20 address. After logging in,
> type "cd=20 internet-drafts" and then
>=20       "get = draft-ietf-sip-history-info-04.txt".=20
>
> A list of = Internet-Drafts=20 directories can be found in
> http://www.ietf.org/shadow.html
>=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt =
>
>
>=20 Internet-Drafts can also be obtained by e-mail.
>=20
> Send a message to:
>=20       mailserv@ietf.org.
>=20 In the body type:
> =      =20 "FILE /internet-drafts/draft-ietf-sip-history-info-04.txt". =
>      
> NOTE:=20 The mail server at ietf.org can return the document in
>       MIME-encoded form by using = the=20 "mpack" utility.  To use this
>=20       feature, insert the command "ENCODING = mime"=20 before the "FILE"
> =      =20 command.  To decode the response(s), you will need "munpack" = or=20
>       a MIME-compliant = mail=20 reader.  Different MIME-compliant mail readers
>=20       exhibit different behavior, especially = when=20 dealing with
> =      =20 "multipart" MIME messages (i.e. documents which have been split =
>       up into multiple messages), = so check=20 your local documentation on
>=20       how to manipulate these messages.=20
>      =20        
>=20       =        =20
> Below is the data which will enable a = MIME=20 compliant mail reader
> implementation to=20 automatically retrieve the ASCII version of the
>=20 Internet-Draft.
>
>=20
>
> =
>
>=20 _______________________________________________
> Sip=20 mailing list  https://www1.ietf.org/mailman/listinfo/sip =
> This list is for NEW development of the core SIP = Protocol=20
> Use sip-implementors@cs.columbia.edu for = questions on=20 current sip
> Use sipping@ietf.org for new=20 developments on the application of sip
>=20


--------
Takuya = Sawada
KDDI Corporation (KDDI)
Garden Air = Tower,=20 3-10-10, Iidabashi,
Chiyoda-ku, Tokyo = 102-8460,=20 Japan
Tel: +81-3-6678-2997
Fax:=20 +81-3-6678-0286
tu-sawada@kddi.com=20

------_=_NextPart_001_01C4C5AD.944FAAE3-- --===============1713656677== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1713656677==-- From sip-bounces@ietf.org Tue Nov 9 17:25:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21048 for ; Tue, 9 Nov 2004 17:25:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CReR9-00009w-Os for sip-web-archive@ietf.org; Tue, 09 Nov 2004 17:26:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CReFc-00072W-7u; Tue, 09 Nov 2004 17:14:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRFQb-0004zH-4y for sip@megatron.ietf.org; Mon, 08 Nov 2004 14:43:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19495 for ; Mon, 8 Nov 2004 14:43:47 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRFRB-0003DZ-7Q for sip@ietf.org; Mon, 08 Nov 2004 14:44:26 -0500 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iA8JhCm24850; Mon, 8 Nov 2004 14:43:12 -0500 (EST) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Nov 2004 14:43:12 -0500 Message-ID: From: "Mary Barnes" To: "'GARCIN Sebastien RD-CORE-ISS'" , sip@ietf.org Subject: RE: [Sip] Privacy statements and History (draft-ietf-sip-history- info-04.txt) Date: Mon, 8 Nov 2004 14:42:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.9 (/) X-Scan-Signature: 8901a8a90c9d1a0e5c206e782197cab6 X-Mailman-Approved-At: Tue, 09 Nov 2004 17:14:03 -0500 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1242122896==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 871367014a9fe468a1d3cdefa3a481eb This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1242122896== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C5CB.26B989B3" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4C5CB.26B989B3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable S=E9bastien, =20 Thanks for reviewing the draft; my response to your comments is = embedded below [MB]. =20 Mary=20 -----Original Message----- From: GARCIN Sebastien RD-CORE-ISS [mailto:sebastien.garcin@francetelecom.com]=20 Sent: Monday, November 08, 2004 10:11 AM To: Barnes, Mary [NGC:B601:EXCH]; sip@ietf.org Subject: [Sip] Privacy statements and History (draft-ietf-sip-history-info-04.txt) Hi mary, all =20 When reading draft-ietf-sip-history-info-04.txt, I have trouble in understanding some of the statements which relate to the forwarding = rules for history-entries subject to privacy. It is an important requirement = that History-entrie(s) with a Privacy=3Dhistory, session, or header are = indeed forwarded to entities which belong to the same trust domain. The = removal of specific history-entries should only occur if the peer does not belong = to the trust domain. =20 In the current text (section 4.3.3.1.1) : If a request is being forwarded to a Request URI associated with a = domain for which the proxy is not responsible and there is a Privacy header in = the request with a priv-value of "session", "header" or "history", the = proxy MUST remove any hi-entry(s) prior to forwarding.=20 =20 The current wording is misleading since it gives the impression (maybe intentionnal) that it is not possible to forward history-entries with Privacy statements to domains under the responsability of e.g. another operator belonging to the same trust domain. =20 =20 [MB]: Current wording is consistent with terminology in RFC 3261 in = terms of describing who is able to change the Request URI in a specific request (based on section 16.5):=20 " A proxy MUST NOT add additional targets to the target set if the Request-URI of the original request does not indicate a resource = this proxy is responsible for. A proxy can only change the Request-URI of a request during forwarding if it is responsible for that URI. " Since History-Info (and associated privacy) are only added to the = request, when an entity that is allowed to change the Request-URI retargets the request, it seemed sensible to use consistent wording to explain that. = =20 [/MB] =20 The concept of "trust domain" should be used when discussing the = forwarding rules pertaining to information subject to privacy. Furthermore, the requirement for forwarding history-entries to trusted entities should = be stated more clearly in the draft.=20 [MB]: The whole concept of what defines privacy in terms of the proxy's = use of the privacy header is outside the scope of History-Info = functionality and really a matter of local policy. I think the functionality that you = want is a matter of local implementation and policy in terms of operators establishing this "trust domain" model to which you refer. = History-Info defines the mechanism to ensure the privacy of the requests, but it = doesn't explicitly define how the proxy knows whether it is responsible for = that resource. I don't think this is a matter of standardization. I = thought the use of the term "domain" rather than "resouce" would be helpful, = but perhaps changing it to the more general "resource" would resolve this concern and/or a statement clarifying what I've just described should = be added in the draft.=20 [/MB] =20 =20 Thank you for clarifying this point. =20 Best regards, s=E9bastien =20 =20 _____ =20 De : sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] De la part de = Mary Barnes Envoy=E9 : mercredi 3 novembre 2004 17:29 =C0 : 'Takuya Sawada' Cc : 'sip@ietf.org' Objet : RE: FW: [Sip] I-D ACTION:draft-ietf-sip-history-info-04.txt Hi Takuya,=20 I apologize if I missed this specific point in your previous postings. = You are correct, that index of 2 should have been 1.1 and this actually = affects the whole series and also affects the examples in 4.5.1 and 4.5.2. = All the other entries are correct relative to the index of 2, it's just the 2 = should have been a 1.1, unless of course that proxy had a good reason for = starting at 2, which I don't explain so shouldn't use in the example. =20 It looks like I introduced that error in the -01 version when I was = updating the example to include the index for all entries (as the index was originally optional). I traced the change back to changes I made during = the middle of the day, so I can't even blame late nite editting. I will definitely make a note of that and update that in the -05 version, = which will hopefully be the one to go to the IESG. I'm also copying the SIP list, so that folks are aware of this as they review the document.=20 Thanks for your careful review,=20 Mary=20 -----Original Message-----=20 From: Takuya Sawada [mailto:tu-sawada@kddi.com = ] Sent: Tuesday, November 02, 2004 4:29 AM=20 To: Barnes, Mary [NGC:B601:EXCH]=20 Subject: Re: FW: [Sip] I-D ACTION:draft-ietf-sip-history-info-04.txt=20 Hi Mary,=20 Each example flow in section 4.5 begins with the following messages,=20 UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5=20 =20 | | | | | | |=20 |--INVITE -->| | | | | |=20 | |-INVITE->| | | | |=20 Supported: Histinfo=20 History-Info: ;index=3D1,=20 ;index=3D2=20 I think this should be=20 UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5=20 =20 | | | | | | |=20 |--INVITE -->| | | | | |=20 | |-INVITE->| | | | |=20 Supported: Histinfo=20 History-Info: ;index=3D1,=20 ;index=3D1.1=20 Note that the index of the second hi-entry is 1.1.=20 I made the same comment to the list before, but no response to it.=20 In Appendix C, it shows,=20 UA1 Proxy ACDGRP1 Svr ACDGRP2 Svr UA2-ACDGRP2 =20 | | | | |=20 |--INVITE F1-->| | | |=20 Supported:Histinfo=20 | | | | |=20 | |--INVITE F2-->| | |=20 Supported:Histinfo=20 History-Info: ; index=3D1 =20 History-Info: ; = index=3D1.1=20 I can not find what is the difference between the two.=20 Are you saying that the former is "Retargeting within a Proxy" and the = latter is "Basic Forwarding"?=20 Am I missing something?=20 Thanks.=20 Regards,=20 Takuya=20 >=20 >=20 > Hi all,=20 >=20 > Since this version should be ready for WGLC, a very detailed list of = the=20 > changes is provided in the document, annotated as to the source, so I won't=20 > repeat those details here. The majority of the changes were the = issues=20 > discussed at IETF-60, along with the agreements there to change the = text to=20 > non-normative in section 4 (Protocol structure) and to add some = detail per > Rohan's comment on the necessary processing should TLS not be = available. In=20 > addition, I received some proposed changes on a marked up hardcopy at = > IETF-61 from Eric Burger. =20 >=20 > The only items not discussed at IETF-60 were 2 items that came up on = the=20 > list (one posted by John Elwell on August 18th on handling of privacy = in=20 > responses) the other on Oct. 15th around the appropriate character = format=20 > for the escaped headers in the URI. And, as always, there are various minor=20 > editorial changes here and there while I was "in the area". So, = there=20 > should be no surprises with any of the changes, although, it is = possible=20 > that there are still errors and nits that can be identified during = WGLC. >=20 > Thanks,=20 > Mary=20 >=20 >=20 > -----Original Message-----=20 > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org ] On Behalf Of=20 > Internet-Drafts@ietf.org=20 > Sent: Monday, October 25, 2004 3:07 PM=20 > To: i-d-announce@ietf.org=20 > Cc: sip@ietf.org=20 > Subject: [Sip] I-D ACTION:draft-ietf-sip-history-info-04.txt=20 >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories.=20 > This draft is a work item of the Session Initiation Protocol Working = Group > of the IETF.=20 >=20 > Title : An Extension to the Session Initiation = Protocol=20 > for Request History Information=20 > Author(s) : M. Barnes=20 > Filename : draft-ietf-sip-history-info-04.txt=20 > Pages : 47=20 > Date : 2004-10-25=20 > =20 > This draft defines a standard mechanism for capturing the history=20 > information associated with a SIP request. This capability = enables=20 > many enhanced services by providing the information as to how and = why=20 > a call arrives at a specific application or user. This draft = defines=20 > a new optional SIP header, History-Info, for capturing the history = > information in requests. A new option tag, Histinfo, to be = included=20 > in the Supported header, is defined to allow UAs to indicate = whether=20 > the History-Info should be returned in responses to a request = which=20 > has captured the history information. A new priv-value, history, = is=20 > added to the Privacy header to allow for privacy handling of the=20 > History-Info header.=20 >=20 > A URL for this Internet-Draft is:=20 > = http://www.ietf.org/internet-drafts/draft-ietf-sip-history-info-04.txt = =20 >=20 > To remove yourself from the I-D Announcement list, send a message to=20 > i-d-announce-request@ietf.org with the word unsubscribe in the body = of the > message. =20 > You can also visit = https://www1.ietf.org/mailman/listinfo/I-D-announce =20 > to change your subscription settings.=20 >=20 >=20 > Internet-Drafts are also available by anonymous FTP. Login with the username=20 > "anonymous" and a password of your e-mail address. After logging in,=20 > type "cd internet-drafts" and then=20 > "get draft-ietf-sip-history-info-04.txt".=20 >=20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html =20 > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt =20 >=20 >=20 > Internet-Drafts can also be obtained by e-mail.=20 >=20 > Send a message to:=20 > mailserv@ietf.org.=20 > In the body type:=20 > "FILE /internet-drafts/draft-ietf-sip-history-info-04.txt".=20 > =20 > NOTE: The mail server at ietf.org can return the document in=20 > MIME-encoded form by using the "mpack" utility. To use this=20 > feature, insert the command "ENCODING mime" before the "FILE"=20 > 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=20 > "multipart" MIME messages (i.e. documents which have been split = > up into multiple messages), so check your local documentation = on=20 > how to manipulate these messages.=20 > =20 > =20 > Below is the data which will enable a MIME compliant mail reader=20 > implementation to automatically retrieve the ASCII version of the=20 > Internet-Draft.=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________=20 > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip =20 > This list is for NEW development of the core SIP Protocol=20 > Use sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip=20 >=20 --------=20 Takuya Sawada=20 KDDI Corporation (KDDI)=20 Garden Air Tower, 3-10-10, Iidabashi,=20 Chiyoda-ku, Tokyo 102-8460, Japan=20 Tel: +81-3-6678-2997=20 Fax: +81-3-6678-0286=20 tu-sawada@kddi.com=20 ------_=_NextPart_001_01C4C5CB.26B989B3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
S=E9bastien,
 
Thanks=20 for reviewing the draft; my response to your comments is embedded below = [MB].
 
Mary
-----Original Message-----
From: = GARCIN Sebastien=20 RD-CORE-ISS [mailto:sebastien.garcin@francetelecom.com] =
Sent:=20 Monday, November 08, 2004 10:11 AM
To: Barnes, Mary = [NGC:B601:EXCH];=20 sip@ietf.org
Subject: [Sip] Privacy statements and History=20 (draft-ietf-sip-history-info-04.txt)

Hi mary, all
 
When = reading draft-ietf-sip-history-info-04.txt,=20 I have trouble in understanding some of the statements which = relate to=20 the forwarding rules for history-entries subject to=20 privacy. It is an important=20 requirement that History-entrie(s) with a = Privacy=3Dhistory,=20 session, or header are indeed forwarded to entities which=20 belong to the same trust domain. The removal of = specific=20 history-entries should only occur if the peer does not belong to = the=20 trust domain.
 
In the current text (section=20 4.3.3.1.1) :
If a request is  being forwarded = to a Request=20 URI associated with a domain for which the proxy is not=20 responsible and there is a Privacy header in=20 the request with a = priv-value=20 of "session", "header" or "history", the proxy MUST remove any=20 hi-entry(s) prior to forwarding.
 
The current wording is misleading since it gives = the=20 impression (maybe intentionnal) that it is not possible to forward=20 history-entries with Privacy statements to domains under the = responsability=20 of e.g. another operator belonging to the same trust = domain.  
 
[MB]: Current wording is = consistent with=20 terminology in RFC 3261 in terms of describing who is able = to change the=20 Request URI in a specific request (based on section=20 16.5): 
   " A proxy MUST NOT add = additional=20 targets to the target set if the
   Request-URI of the = original=20 request does not indicate a resource this
   proxy is = responsible=20 for.

      A proxy can only change = the=20 Request-URI of a request during
      = forwarding=20 if it is responsible for that URI. = "
Since History-Info (and = associated=20 privacy) are only added to the request, when an entity = that is=20 allowed to change the Request-URI retargets the request, it = seemed=20 sensible to use consistent wording to explain that. =20  
[/MB]
 
The concept of "trust domain" should be used = when=20 discussing the forwarding rules pertaining to information = subject to=20 privacy. Furthermore, the requirement for forwarding = history-entries to=20 trusted entities should be stated more clearly in the = draft. 
[MB]: The whole concept of what defines = privacy in=20 terms of the proxy's use of the privacy header is outside the scope = of=20 History-Info functionality and really a matter of local policy. =   I think=20 the functionality that you want is a matter of local implementation = and policy=20 in terms of operators establishing this "trust domain" = model to=20 which you refer.  History-Info defines the mechanism = to ensure the=20 privacy of the requests, but it doesn't explicitly define how=20 the proxy knows whether it is responsible for that=20 resource.    I don't think this is a matter of=20 standardization.  I thought the use of the term "domain" rather = than=20 "resouce" would be helpful, but perhaps changing it to the more = general=20 "resource" would resolve this concern and/or a statement clarifying = what I've=20 just described should be added in the draft.
[/MB]
 =
 
Thank you for clarifying this = point.
 
Best=20 regards,
s=E9bastien
 
 

De : sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] De la part de Mary=20 Barnes
Envoy=E9 : mercredi 3 novembre 2004=20 17:29
=C0 : 'Takuya Sawada'
Cc :=20 'sip@ietf.org'
Objet : RE: FW: [Sip] I-D=20 ACTION:draft-ietf-sip-history-info-04.txt

Hi Takuya,

I apologize if I missed this specific point in your = previous=20 postings. You are correct, that index of 2 should have been 1.1 and = this =20 actually affects the whole series and also affects the examples = in  4.5.1=20 and 4.5.2.  All the other entries are correct relative to the = index of 2,=20 it's just the 2 should have been a 1.1, unless of course that proxy = had a good=20 reason for starting at 2, which I don't explain so shouldn't use in = the=20 example. 

It looks like I introduced that error in the -01 = version when=20 I was updating the example to include the index for all entries (as = the index=20 was originally optional). I traced the change back to changes I made = during=20 the middle of the day, so I can't even blame late nite = editting.   I=20 will definitely make a note of that and update that in the -05 = version, which=20 will hopefully be the one to go to the IESG.

I'm also copying the SIP list, so that folks are = aware of this=20 as they review the document.

Thanks for your careful review,
Mary


-----Original Message-----
From:=20 Takuya Sawada [mailto:tu-sawada@kddi.com]=20
Sent: Tuesday, November 02, 2004 4:29 = AM=20
To: Barnes, Mary [NGC:B601:EXCH]
Subject: Re: FW: [Sip] I-D=20 ACTION:draft-ietf-sip-history-info-04.txt


Hi Mary,

Each example flow in section 4.5 begins with the = following=20 messages,

   = UA1       =20 Proxy1  Proxy2     = UA2     =20 UA3      UA4      = UA5=20
          &nb= sp;    =20
  =20 |           =20 |        =20 |       =20 |       =20 |       =20 |        |
   |--INVITE=20 -->|        =20 |       =20 |       =20 |       =20 |        |
  =20 |           =20 |-INVITE->|       =20 |       =20 |       =20 |        |
          &= nbsp;     =20 Supported: Histinfo
          &nb= sp;     =20 History-Info: <sip:Bob@P1.example.com>;index=3D1, =
          &nb= sp;           &nb= sp;       =20 <sip:Bob@P2.example.com>;index=3D2

I think this should be

   = UA1       =20 Proxy1  Proxy2     = UA2     =20 UA3      UA4      = UA5=20
          &nb= sp;    =20
  =20 |           =20 |        =20 |       =20 |       =20 |       =20 |        |
   |--INVITE=20 -->|        =20 |       =20 |       =20 |       =20 |        |
  =20 |           =20 |-INVITE->|       =20 |       =20 |       =20 |        |
          &nb= sp;     =20 Supported: Histinfo
          &nb= sp;     =20 History-Info: <sip:Bob@P1.example.com>;index=3D1, =
          &nb= sp;           &nb= sp;       =20 <sip:Bob@P2.example.com>;index=3D1.1

Note that the index of the second hi-entry is = 1.1.=20
I made the same comment to the list before, but no = response=20 to it.

In Appendix C, it shows,

  =20 UA1         =20 Proxy        ACDGRP1 = Svr  =20 ACDGRP2 Svr=20 = UA2-ACDGRP2          &= nbsp;  =20
          &nb= sp;    =20
  =20 = |            = ; =20 = |            = ; =20 = |            = ;=20 |          | =
   |--INVITE=20 = F1-->|          &nb= sp;  =20 = |            = ;=20 |          | =
    Supported:Histinfo
  =20 = |            = ; =20 |           &nb= sp; =20 = |            = ;=20 |          | =
  =20 = |            = ; =20 |--INVITE=20 = F2-->|          &nb= sp; =20 |          | =
          &nb= sp;        =20 Supported:Histinfo
          &nb= sp;        =20 History-Info: <sip:Gold@example.com>; index=3D1  =
          &nb= sp;        =20 History-Info: <sip:ACDGRP1@example.com>; index=3D1.1 =

I can not find what is the difference between the = two.=20
Are you saying that the former is "Retargeting = within a =20 Proxy" and the
latter is "Basic = Forwarding"?=20
Am I missing something?

Thanks.

Regards,
Takuya =

>
> =
>=20 Hi all,
>
> = Since this=20 version should be ready for WGLC, a very detailed list of the =
> changes is provided in the document, annotated as to = the source,=20 so I won't
> repeat those details = here.  =20 The majority of the changes were the issues
>=20 discussed at IETF-60, along with the agreements there to change the = text=20 to
> non-normative in section 4 = (Protocol=20 structure) and to add some detail per
> = Rohan's=20 comment on the necessary processing should TLS not be = available. =20 In
> addition, I received some proposed = changes on=20 a marked up hardcopy at
> IETF-61 from = Eric=20 Burger. 
>
> The=20 only items not discussed at IETF-60 were 2 items that came up on = the=20
> list (one posted by John Elwell on August = 18th on=20 handling of privacy in
> responses) the = other on=20 Oct. 15th around the appropriate character format
>=20 for the escaped headers in the URI. And, as always, there are various = minor
> editorial changes here and there = while I=20 was "in the area".  So, there
> = should be no=20 surprises with any of the changes, although, it is possible =
> that there are still errors and nits that can be = identified during=20 WGLC.  
>
>=20 Thanks,
> Mary
>=20
>
> = -----Original=20 Message-----
> From: = sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] = On Behalf=20 Of
> Internet-Drafts@ietf.org =
> Sent: Monday, October 25, 2004 3:07 PM
> To: i-d-announce@ietf.org
> Cc:=20 sip@ietf.org
> Subject: [Sip] I-D=20 ACTION:draft-ietf-sip-history-info-04.txt
>=20
>
> A New = Internet-Draft=20 is available from the on-line Internet-Drafts
>=20 directories.
> This draft is a work item = of the=20 Session Initiation Protocol Working Group
> of the=20 IETF.
>
>=20       Title  =20         : An Extension to the = Session=20 Initiation Protocol
> for Request = History=20 Information
> =      =20 Author(s)       : M. Barnes =
>      =20 Filename        :=20 draft-ietf-sip-history-info-04.txt
>=20       Pages  =20         : 47
>=20       Date   =20         : 2004-10-25 =
>      
> This=20 draft defines a standard mechanism for capturing the history =
>    information associated with a SIP = request. =20 This capability enables
>    many=20 enhanced services by providing the information as to how and why=20
>    a call arrives at a = specific=20 application or user.  This draft defines
>    a new optional SIP header, = History-Info, for=20 capturing the history
>   =20 information in requests. A new option tag, Histinfo, to be included=20
>    in the Supported = header, is=20 defined to allow UAs to indicate whether
>    the History-Info should be returned = in responses=20 to a request which
>    = has captured=20 the history information. A new priv-value, history, is =
>    added to the Privacy header to allow = for privacy=20 handling of the
>    = History-Info=20 header.
>
> = A URL for=20 this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-sip-histo= ry-info-04.txt=20
>
> To remove = yourself from the=20 I-D Announcement list, send a message to
>=20 i-d-announce-request@ietf.org with the word unsubscribe in the body = of=20 the
> message. 
>=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce =
> to change your subscription = settings.=20
>
> =
> Internet-Drafts are also available by anonymous FTP. = Login with=20 the username
> "anonymous" and a = password of your=20 e-mail address. After logging in,
> type = "cd=20 internet-drafts" and then
>=20       "get=20 draft-ietf-sip-history-info-04.txt".
>=20
> A list of Internet-Drafts directories = can be=20 found in
> http://www.ietf.org/shadow.html
>=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt =
>
>
>=20 Internet-Drafts can also be obtained by e-mail.
>=20
> Send a message to:
>=20       mailserv@ietf.org.
>=20 In the body type:
> =      =20 "FILE /internet-drafts/draft-ietf-sip-history-info-04.txt". =
>      
> NOTE:=20 The mail server at ietf.org can return the document in =
>       MIME-encoded form by = using the=20 "mpack" utility.  To use this
>=20       feature, insert the command "ENCODING = mime"=20 before the "FILE"
> =      =20 command.  To decode the response(s), you will need "munpack" = or=20
>       a = MIME-compliant mail=20 reader.  Different MIME-compliant mail readers
>       exhibit different = behavior,=20 especially when dealing with
>=20       "multipart" MIME messages (i.e. = documents which=20 have been split
> =       up=20 into multiple messages), so check your local documentation on =
>       how to manipulate these=20 messages.
> =      =20        
>=20       =        =20
> Below is the data which will enable a = MIME=20 compliant mail reader
> implementation = to=20 automatically retrieve the ASCII version of the
>=20 Internet-Draft.
>
>=20
>
> =
>
>=20 _______________________________________________
>=20 Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip =
> This list is for NEW development of the core SIP = Protocol=20
> Use sip-implementors@cs.columbia.edu for = questions on=20 current sip
> Use sipping@ietf.org for = new=20 developments on the application of sip
> =


--------
Takuya = Sawada=20
KDDI Corporation (KDDI)
Garden Air=20 Tower, 3-10-10, Iidabashi,
Chiyoda-ku, = Tokyo 102-8460,=20 Japan
Tel: +81-3-6678-2997
Fax: +81-3-6678-0286
tu-sawada@kddi.com=20

------_=_NextPart_001_01C4C5CB.26B989B3-- --===============1242122896== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1242122896==-- From sip-bounces@ietf.org Wed Nov 10 05:01:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17311 for ; Wed, 10 Nov 2004 05:01:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRpJ2-0005ug-Qk for sip-web-archive@ietf.org; Wed, 10 Nov 2004 05:02:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRp4j-0005UG-09; Wed, 10 Nov 2004 04:47:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRoxS-0004kW-QW for sip@megatron.ietf.org; Wed, 10 Nov 2004 04:40:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15270 for ; Wed, 10 Nov 2004 04:40:02 -0500 (EST) Received: from firewall.citel.com ([62.190.107.60] helo=ivor.citel.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CRoyM-0005Lh-0k for sip@ietf.org; Wed, 10 Nov 2004 04:41:02 -0500 Content-Class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: [Sip] PING/PONG Date: Wed, 10 Nov 2004 09:39:07 -0000 Message-ID: Thread-Topic: [Sip] PING/PONG Thread-Index: AcTGVeD72vlivuzXRNmVFA8//spI5wABZoOgAAGeqgAAAsmPsAAmuEDw From: "Steve Langstaff" To: "Christian Stredicke" , "Chris Boulton" , "Christer Holmberg \(JO/LMF\)" , X-Spam-Score: 0.3 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1075131135==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b This is a multi-part message in MIME format. --===============1075131135== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C709.1FB7A7F2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4C709.1FB7A7F2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable (CS) OPTIONS has the problem that it is relatively expensive (size and = CPU) and might result in responses that exceed the UDP fragmentation = limit (there are many DSL routers that treat UDP fragmentation as = security problem including the one that I have at home). Therefore I = think it would not hurt to have a specific message that is designed only = for the keep-alive job. =20 ...but if you want your keep alive message to be routed over the same = path and transports as your original INVITE (and hence keep them alive), = don't you need most of the "expensive" content of (say) the OPTIONS = message - e.g. the vias. --=20 Steve Langstaff.=20 ------_=_NextPart_001_01C4C709.1FB7A7F2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
(CS) = OPTIONS has the=20 problem that it is relatively expensive (size and CPU) and might result = in=20 responses that exceed the UDP fragmentation limit (there are many DSL = routers=20 that treat UDP fragmentation as security problem including the one that = I have=20 at home). Therefore I think it would not hurt to have a specific message = that is=20 designed only for the keep-alive job.
 
...but=20 if you want your keep alive message to be routed over the same path and=20 transports as your original INVITE (and hence keep them alive), don't = you need=20 most of the "expensive" content of (say) the OPTIONS message - e.g. = the=20 vias.

--
Steve=20 Langstaff.

------_=_NextPart_001_01C4C709.1FB7A7F2-- --===============1075131135== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1075131135==-- From sip-bounces@ietf.org Wed Nov 10 05:38:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20832 for ; Wed, 10 Nov 2004 05:38:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRpsz-0006kC-2K for sip-web-archive@ietf.org; Wed, 10 Nov 2004 05:39:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRpqd-0002VB-AB; Wed, 10 Nov 2004 05:37:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRpq5-0002Oo-Uq for sip@megatron.ietf.org; Wed, 10 Nov 2004 05:36:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20599 for ; Wed, 10 Nov 2004 05:36:31 -0500 (EST) Received: from natsmtp00.rzone.de ([81.169.145.165]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRpr1-0006h7-Sr for sip@ietf.org; Wed, 10 Nov 2004 05:37:32 -0500 Received: from snom.de (pD9516A46.dip.t-dialin.net [217.81.106.70]) by post.webmailer.de (8.13.1/8.13.1) with ESMTP id iAAAaLhH007586; Wed, 10 Nov 2004 11:36:24 +0100 (MET) Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] PING/PONG X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 10 Nov 2004 11:36:17 +0100 Message-ID: Thread-Topic: [Sip] PING/PONG thread-index: AcTGVeD72vlivuzXRNmVFA8//spI5wABZoOgAAGeqgAAAsmPsAAmuEDwAAIvsMA= From: "Christian Stredicke" To: "Steve Langstaff" , "Chris Boulton" , "Christer Holmberg \(JO/LMF\)" , X-Spam-Score: 0.8 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0775204233==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 This is a multi-part message in MIME format. --===============0775204233== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C711.A4201E1A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4C711.A4201E1A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable True. For that purpose, use e.g. INFO messages with no body. These messages keep the dialog "alive".=20 =20 However, the goal of the PING/PONG keep-alive messages is to keep the NAT-binding alive. So that you are able to receive the first INVITE! =20 CS ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Steve Langstaff Sent: Wednesday, November 10, 2004 5:16 AM To: Christian Stredicke; Chris Boulton; Christer Holmberg (JO/LMF); fluffy@cisco.com Cc: sip@ietf.org Subject: RE: [Sip] PING/PONG =09 =09 (CS) OPTIONS has the problem that it is relatively expensive (size and CPU) and might result in responses that exceed the UDP fragmentation limit (there are many DSL routers that treat UDP fragmentation as security problem including the one that I have at home). Therefore I think it would not hurt to have a specific message that is designed only for the keep-alive job. =20 ...but if you want your keep alive message to be routed over the same path and transports as your original INVITE (and hence keep them alive), don't you need most of the "expensive" content of (say) the OPTIONS message - e.g. the vias. --=20 Steve Langstaff.=20 ------_=_NextPart_001_01C4C711.A4201E1A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
True. For that purpose, use e.g. INFO messages = with no=20 body. These messages keep the dialog "alive".
 
However, the goal of the PING/PONG keep-alive = messages is=20 to keep the NAT-binding alive. So that you are able to receive the first = INVITE!
 
CS

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Steve=20 Langstaff
Sent: Wednesday, November 10, 2004 5:16 = AM
To:=20 Christian Stredicke; Chris Boulton; Christer Holmberg (JO/LMF);=20 fluffy@cisco.com
Cc: sip@ietf.org
Subject: RE: = [Sip]=20 PING/PONG

(CS) = OPTIONS has the=20 problem that it is relatively expensive (size and CPU) and might = result in=20 responses that exceed the UDP fragmentation limit (there are many DSL = routers=20 that treat UDP fragmentation as security problem including the one = that I have=20 at home). Therefore I think it would not hurt to have a specific = message that=20 is designed only for the keep-alive = job.
 
...but if you want your keep alive message to be routed over = the same=20 path and transports as your original INVITE (and hence keep them = alive), don't=20 you need most of the "expensive" content of (say) the = OPTIONS message -=20 e.g. the vias.

--
Steve=20 Langstaff.

------_=_NextPart_001_01C4C711.A4201E1A-- --===============0775204233== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0775204233==-- From sip-bounces@ietf.org Wed Nov 10 08:55:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08765 for ; Wed, 10 Nov 2004 08:55:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRsxK-0002Px-9g for sip-web-archive@ietf.org; Wed, 10 Nov 2004 08:56:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRsu3-0003jl-T0; Wed, 10 Nov 2004 08:52:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRst1-0003LL-QU for sip@megatron.ietf.org; Wed, 10 Nov 2004 08:51:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08221 for ; Wed, 10 Nov 2004 08:51:46 -0500 (EST) Received: from cluster-b.mailcontrol.com ([217.68.146.190] helo=rly11b.srv.mailcontrol.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRsty-0002Ke-GA for sip@ietf.org; Wed, 10 Nov 2004 08:52:48 -0500 Received: from GBNEWP0758M.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly11b.srv.mailcontrol.com (MailControl) with ESMTP id iAADp99N006073; Wed, 10 Nov 2004 13:51:10 GMT X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] PING/PONG Date: Wed, 10 Nov 2004 13:45:18 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE02BDF7EE@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Sip] PING/PONG Thread-Index: AcTGVeD72vlivuzXRNmVFA8//spI5wABZoOgAAGeqgAAAsmPsAAmuEDwAAIvsMAABqg1sA== From: "Chris Boulton" To: "Christian Stredicke" , "Steve Langstaff" , "Christer Holmberg (JO/LMF)" , X-Scanned-By: MailControl A-05-00-00 (www.mailcontrol.com) X-Spam-Score: 0.3 (/) X-Scan-Signature: abda3837e791065a13ac6f11cf8e625a Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0730944174==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: fac892abe0c719c7bb99f6e7c710cdae This is a multi-part message in MIME format... --===============0730944174== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C72B.83C663E0" This is a multi-part message in MIME format... ------_=_NextPart_001_01C4C72B.83C663E0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Yes - this has nothing to do with dialog's. The requirement is to keep bindings alive regardless. =20 Chris. =20 =20 -----Original Message----- From: Christian Stredicke [mailto:Christian.Stredicke@snom.de]=20 Sent: 10 November 2004 10:36 To: Steve Langstaff; Chris Boulton; Christer Holmberg (JO/LMF); fluffy@cisco.com Cc: sip@ietf.org Subject: RE: [Sip] PING/PONG =20 True. For that purpose, use e.g. INFO messages with no body. These messages keep the dialog "alive".=20 =20 However, the goal of the PING/PONG keep-alive messages is to keep the NAT-binding alive. So that you are able to receive the first INVITE! =20 CS =09=20 =09 _____=20=20 From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Steve Langstaff Sent: Wednesday, November 10, 2004 5:16 AM To: Christian Stredicke; Chris Boulton; Christer Holmberg (JO/LMF); fluffy@cisco.com Cc: sip@ietf.org Subject: RE: [Sip] PING/PONG (CS) OPTIONS has the problem that it is relatively expensive (size and CPU) and might result in responses that exceed the UDP fragmentation limit (there are many DSL routers that treat UDP fragmentation as security problem including the one that I have at home). Therefore I think it would not hurt to have a specific message that is designed only for the keep-alive job. =09=20 ...but if you want your keep alive message to be routed over the same path and transports as your original INVITE (and hence keep them alive), don't you need most of the "expensive" content of (say) the OPTIONS message - e.g. the vias. --=20 Steve Langstaff.=20 This email and any attached files are confidential and copyright protected.= If you are not the addressee, any dissemination, distribution or copying = of this communication is strictly prohibited. Unless otherwise expressly a= greed in writing, nothing stated in this communication shall be legally bin= ding. ------_=_NextPart_001_01C4C72B.83C663E0 Content-Type: text/html; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

Yes – this has nothing to do wit= h dialog’s.  The requirement is to keep bindings alive regardless.

 

Chris.

 

 

-----Original Message-----
From: Christian Stredicke [mailto:Christian.Stredicke@snom.de]
Sent: 10 November 2004 10:36=
To: Steve Langstaff; Chris Boulton; Christer Holmberg (JO/LMF); fluffy@cisco.com
Cc: sip@ietf.org
Subject: RE: [Sip] PING/PONG=

 

True. For that purpose, use e.g. INFO messages with no body. These messages keep = the dialog "alive".

 

However, the goal of the PING/PONG keep-alive messages is to keep the NAT-binding al= ive. So that you are able to receive the first INVITE!

 

CS

 

From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Steve Langstaff
Sent: Wednesday, November 10= , 2004 5:16 AM
To: Christian Stredicke; Chr= is Boulton; Christer Holmberg (JO/LMF); fluffy@cisco.com
Cc: sip@ietf.org
Subject: RE: [Sip] PING/PONG=

(CS) OPTIONS has the problem that it is relatively expensive (size and CPU) and might result in responses that exce= ed the UDP fragmentation limit (there are many DSL routers that treat UDP fragmentation as security problem including the one that I have at home). Therefore I think it would not hurt to have a specific message that is desi= gned only for the keep-alive job.

 

= ...but if you want your keep alive message to be routed over the same path and transports as your original INVITE (and hence keep them alive), don't you n= eed most of the "expensive" content of (say) the OPTIONS message= - e.g. the vias.

--
Steve Langstaff.



This email and any attac= hed files are confidential and copyright protected.  If you are not th= e addressee, any dissemination, distribution or copying of this communicati= on is strictly prohibited.  Unless otherwise expressly agreed in writi= ng, nothing stated in this communication shall be legally binding.
 ------_=_NextPart_001_01C4C72B.83C663E0-- --===============0730944174== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0730944174==-- From sip-bounces@ietf.org Wed Nov 10 09:15:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10459 for ; Wed, 10 Nov 2004 09:15:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRtGx-0002uk-DI for sip-web-archive@ietf.org; Wed, 10 Nov 2004 09:16:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRt8D-0005rr-Pr; Wed, 10 Nov 2004 09:07:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRt1D-0004di-97 for sip@megatron.ietf.org; Wed, 10 Nov 2004 09:00:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09170 for ; Wed, 10 Nov 2004 09:00:13 -0500 (EST) Received: from mail4.telekom.de ([195.243.210.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRt28-0002Vp-PE for sip@ietf.org; Wed, 10 Nov 2004 09:01:15 -0500 Received: from g8pbq.blf01.telekom.de by mail2.dmz.telekom.de with ESMTP; Wed, 10 Nov 2004 14:59:18 +0100 Received: by G8PBQ.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Nov 2004 14:59:31 +0100 Message-Id: From: "Jesske, R" To: sebastien.garcin@francetelecom.com, mary.barnes@nortelnetworks.com, sip@ietf.org Subject: AW: [Sip] Privacy statements and History (draft-ietf-sip-history- info-04.txt) Date: Wed, 10 Nov 2004 14:59:27 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.6 (/) X-Scan-Signature: e9051aca6d23a9cf6df09e1ef4738712 Cc: VL-T-Com-T-TE332@vli.telekom.de X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1679233635==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: ce2737a971e141e0457c8c1bf182367f This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1679233635== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C72D.7E16DDA0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4C72D.7E16DDA0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Dear Mary and Sebastien, here are my Comments to Sebastien's statements: =20 Your first proposal I can accept from my point of view. On you second issue my impression is that this issue must be seen with = regard to RFC3323 where privacy and the trust concept is described. = Perhaps a reference to this document should be included. On your last point, I think we can also refer to RFC 3323. =20 What are you thinking? =20 Best Regards =20 Roland =20 -----Urspr=FCngliche Nachricht----- Von: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]Im Auftrag von = GARCIN Sebastien RD-CORE-ISS Gesendet: Dienstag, 9. November 2004 10:53 An: Mary Barnes; sip@ietf.org Betreff: RE: [Sip] Privacy statements and History = (draft-ietf-sip-history-info-04.txt) Mary, =20 Responses below marked [SG] =20 Best regards,=20 s=E9bastien=20 _____ =20 De : sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] De la part de = Mary Barnes Envoy=E9 : lundi 8 novembre 2004 21:57 =C0 : Mary Barnes; GARCIN Sebastien RD-CORE-ISS; 'sip@ietf.org' Objet : RE: [Sip] Privacy statements and History = (draft-ietf-sip-history-info-04.txt) My initial response is awaiting approval by moderator due to the size, = so I've snipped and am resending. =20 =20 Mary=20 -----Original Message----- From: Barnes, Mary [NGC:B601:EXCH]=20 Sent: Monday, November 08, 2004 1:43 PM To: 'GARCIN Sebastien RD-CORE-ISS'; sip@ietf.org Subject: RE: [Sip] Privacy statements and History = (draft-ietf-sip-history-info-04.txt) S=E9bastien, =20 Thanks for reviewing the draft; my response to your comments is = embedded below [MB]. =20 Mary=20 -----Original Message----- From: GARCIN Sebastien RD-CORE-ISS = [mailto:sebastien.garcin@francetelecom.com]=20 Sent: Monday, November 08, 2004 10:11 AM To: Barnes, Mary [NGC:B601:EXCH]; sip@ietf.org Subject: [Sip] Privacy statements and History = (draft-ietf-sip-history-info-04.txt) Hi mary, all =20 When reading draft-ietf-sip-history-info-04.txt, I have trouble in = understanding some of the statements which relate to the forwarding = rules for history-entries subject to privacy. It is an important = requirement that History-entrie(s) with a Privacy=3Dhistory, session, = or header are indeed forwarded to entities which belong to the same = trust domain. The removal of specific history-entries should only occur = if the peer does not belong to the trust domain. =20 In the current text (section 4.3.3.1.1) : If a request is being forwarded to a Request URI associated with a = domain for which the proxy is not responsible and there is a Privacy = header in the request with a priv-value of "session", "header" or = "history", the proxy MUST remove any hi-entry(s) prior to forwarding.=20 =20 The current wording is misleading since it gives the impression (maybe = intentionnal) that it is not possible to forward history-entries with = Privacy statements to domains under the responsability of e.g. another = operator belonging to the same trust domain. =20 =20 [MB]: Current wording is consistent with terminology in RFC 3261 in = terms of describing who is able to change the Request URI in a specific = request (based on section 16.5):=20 " A proxy MUST NOT add additional targets to the target set if the Request-URI of the original request does not indicate a resource = this proxy is responsible for. A proxy can only change the Request-URI of a request during forwarding if it is responsible for that URI. " Since History-Info (and associated privacy) are only added to the = request, when an entity that is allowed to change the Request-URI = retargets the request, it seemed sensible to use consistent wording to = explain that. =20 [/MB]=20 [SG] I have no problem with the statements above. My concern is that = if there is a hi-entry already embedded in the request with a Privacy = statement, then, it should be up to local policy to decide whether or no= t a proxy shall pass on those hi-entries to a trusted domain. The = sentence in section 4.3.3.1.1 precludes this. I would propose to = lighten the strenght of the sentence as follows: =20 If a request is being forwarded to a Request URI associated with a = domain for which the proxy is not responsible and there is a Privacy = header in the request with a priv-value of "session", "header" or = "history", the proxy MAY remove any hi-entry(s) prior to forwarding.=20 =20 [SG] Another issue is the decision to add hi-entries in a privacy = context. A proxy changing the target (i.e. the proxy is responsible of = the resource reflected in the received Request-URI) of a request which = contained a "privacy=3Dhistory" header MAY add a history-entries = provided that it knows it can rely on other entities within the trust = domain to apply the requested privacy. This affect item 4 in the list = on conditions of section 4.3.3 and 4.3.3.1.=20 =20 The concept of "trust domain" should be used when discussing the = forwarding rules pertaining to information subject to privacy. = Furthermore, the requirement for forwarding history-entries to trusted = entities should be stated more clearly in the draft.=20 [MB]: The whole concept of what defines privacy in terms of the proxy's = use of the privacy header is outside the scope of History-Info = functionality and really a matter of local policy. I think the = functionality that you want is a matter of local implementation and = policy in terms of operators establishing this "trust domain" model to = which you refer. History-Info defines the mechanism to ensure the = privacy of the requests, but it doesn't explicitly define how the proxy = knows whether it is responsible for that resource. I don't think = this is a matter of standardization. I thought the use of the term = "domain" rather than "resouce" would be helpful, but perhaps changing = it to the more general "resource" would resolve this concern and/or a = statement clarifying what I've just described should be added in the = draft.=20 [/MB] [SG] Changing the term "domain" to "resource" does not solve the = problem I mentionned above. In order to reflect current operator = requirements, the draft should not PRECLUDE the fowarding of existing = history information towards trusted domains. =20 Thank you for clarifying this point. =20 Best regards, s=E9bastien =20 =20 ------Remainder of non-related part of this thread has been deleted by = Mary------------------ ------_=_NextPart_001_01C4C72D.7E16DDA0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Message
Dear=20 Mary and Sebastien,
here=20 are my Comments to Sebastien's statements:
 
Your=20 first proposal I can accept from my point of view.
On you=20 second issue my impression is that this issue must be seen with regard = to=20 RFC3323 where privacy and the trust concept is described. Perhaps a = reference to=20 this document should be included.
On=20 your last point, I think we can also refer to RFC = 3323.
 
What are you thinking?
 
Best=20 Regards
 
Roland
 
-----Urspr=FCngliche Nachricht-----
Von: = sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org]Im Auftrag von GARCIN Sebastien=20 RD-CORE-ISS
Gesendet: Dienstag, 9. November 2004 = 10:53
An:=20 Mary Barnes; sip@ietf.org
Betreff: RE: [Sip] Privacy = statements and=20 History (draft-ietf-sip-history-info-04.txt)

Mary,
 
Responses below marked [SG]
 
Best regards, 
s=E9bastien <= BR>
De : sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] De la part de Mary=20 Barnes
Envoy=E9 : lundi 8 novembre 2004 = 21:57
=C0 :=20 Mary Barnes; GARCIN Sebastien RD-CORE-ISS;=20 'sip@ietf.org'
Objet : RE: [Sip] Privacy statements = and History=20 (draft-ietf-sip-history-info-04.txt)

My initial response is awaiting approval by moderator due to = the size,=20 so I've snipped and am resending.  =
 
Mary=20
-----Original Message-----
From: = Barnes, Mary=20 [NGC:B601:EXCH]
Sent: Monday, November 08, 2004 1:43=20 PM
To: 'GARCIN Sebastien RD-CORE-ISS';=20 sip@ietf.org
Subject: RE: [Sip] Privacy statements and = History=20 (draft-ietf-sip-history-info-04.txt)

S=E9bastien,
 
Thanks for reviewing the draft; my = response to your=20 comments is embedded below [MB].
 
Mary
-----Original Message-----
From: = GARCIN=20 Sebastien RD-CORE-ISS [mailto:sebastien.garcin@francetelecom.com] =
Sent: Monday, November 08, 2004 10:11 AM
To: = Barnes,=20 Mary [NGC:B601:EXCH]; sip@ietf.org
Subject: [Sip] = Privacy=20 statements and History=20 (draft-ietf-sip-history-info-04.txt)

Hi mary, all
 
When=20 reading draft-ietf-sip-history-info-04.txt, I have = trouble in=20 understanding some of the statements which relate to the = forwarding=20 rules for history-entries subject to=20 privacy. It is an important=20 requirement that History-entrie(s) with a = Privacy=3Dhistory,=20 session, or header are indeed forwarded to entities = which=20 belong to the same trust domain. The removal of = specific=20 history-entries should only occur if the peer does not = belong to the=20 trust domain.
 
In the current=20 text (section 4.3.3.1.1) :
If a request is  being = forwarded to a=20 Request URI associated with a domain for which the = proxy is=20 not responsible and there is a Privacy header in=20 the request with a=20 priv-value of "session", "header" or "history", the proxy = MUST remove=20 any hi-entry(s) prior to forwarding.
 
The current wording is = misleading=20 since it gives the impression (maybe intentionnal) that it is not = possible=20 to forward history-entries with Privacy statements to domains = under the=20 responsability of e.g. another operator belonging to the = same trust=20 domain.  
 
[MB]: = Current wording=20 is consistent with terminology in RFC 3261 in terms of describing = who is=20 able to change the Request URI in a specific request (based=20 on section = 16.5): 
   " A = proxy MUST=20 NOT add additional targets to the target set if = the
  =20 Request-URI of the original request does not indicate a resource=20 this
   proxy is responsible=20 for.

      A proxy can only = change the=20 Request-URI of a request during
      = forwarding if it is responsible for that URI.=20 "
Since = History-Info=20 (and associated privacy) are only added to the = request, when=20 an entity that is allowed to change the Request-URI = retargets=20 the request, it seemed sensible to use consistent wording to = explain=20 that.   
[/MB] <= /DIV>
 [SG] I = have no=20 problem with the statements above. My concern is that if = there is=20 a hi-entry already embedded in the request with = a Privacy=20 statement, then, it should be up to local policy to decide = whether or=20 not a proxy shall pass on those hi-entries to a trusted = domain. The=20 sentence in section 4.3.3.1.1 precludes this. I would = propose to=20 lighten the strenght of the sentence as=20 follows:
 <= /DIV>
If a request is  being forwarded = to a=20 Request URI associated with a domain for which the = proxy is=20 not responsible and there is a Privacy header in=20 the request with a=20 priv-value of "session", "header" or "history", the proxy&nbs= p;MAY=20 remove any hi-entry(s) prior to forwarding. =
 <= /DIV>
[SG] Another issue is=20 the decision to add hi-entries in a privacy context. A proxy = changing=20 the target (i.e. the proxy is responsible of the resource = reflected in the=20 received Request-URI) of a request which contained a=20 "privacy=3Dhistory" header MAY add a = history-entries provided=20 that it knows it can rely on other entities within=20 the trust domain to apply the requested privacy. This affect = item 4=20 in the list on conditions of section 4.3.3 and 4.3.3.1.=20
 
The concept of "trust = domain" should=20 be used when discussing the forwarding rules = pertaining to=20 information subject to privacy. Furthermore, the requirement = for=20 forwarding history-entries to trusted entities should = be stated more=20 clearly in the draft. 
[MB]: The whole concept of what = defines privacy=20 in terms of the proxy's use of the privacy header is outside the = scope of=20 History-Info functionality and really a matter of local policy. =   I=20 think the functionality that you want is a matter of local = implementation=20 and policy in terms of operators establishing this "trust = domain"=20 model to which you refer.  History-Info defines the = mechanism=20 to ensure the privacy of the requests, but it = doesn't explicitly=20 define how the proxy knows whether it is responsible for = that=20 resource.    I don't think this is a matter = of=20 standardization.  I thought the use of the term "domain" = rather than=20 "resouce" would be helpful, but perhaps changing it to the more = general=20 "resource" would resolve this concern and/or a statement = clarifying what=20 I've just described should be added in the draft. =
[/MB]
[SG]   Changing the=20 term "domain" to "resource" does not solve the problem I = mentionned=20 above. In order to reflect = current operator requirements, the=20 draft should not PRECLUDE the fowarding of existing history = information=20 towards trusted=20 = domains.
=
 
Thank you for clarifying this=20 point.
 
Best regards,
s=E9bastien
 
 

------Remainder of non-related part of this thread has = been deleted=20 by=20 Mary------------------
------_=_NextPart_001_01C4C72D.7E16DDA0-- --===============1679233635== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1679233635==-- From sip-bounces@ietf.org Wed Nov 10 09:24:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11449 for ; Wed, 10 Nov 2004 09:24:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRtPs-0003AW-DR for sip-web-archive@ietf.org; Wed, 10 Nov 2004 09:25:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRtJt-00083z-BG; Wed, 10 Nov 2004 09:19:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRt8r-00067f-DI for sip@megatron.ietf.org; Wed, 10 Nov 2004 09:08:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09811 for ; Wed, 10 Nov 2004 09:08:07 -0500 (EST) Received: from firewall.citel.com ([62.190.107.60] helo=ivor.citel.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CRt9p-0002iC-8M for sip@ietf.org; Wed, 10 Nov 2004 09:09:09 -0500 Content-Class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: [Sip] PING/PONG Date: Wed, 10 Nov 2004 13:55:17 -0000 Message-ID: Thread-Topic: [Sip] PING/PONG Thread-Index: AcTGVeD72vlivuzXRNmVFA8//spI5wABZoOgAAGeqgAAAsmPsAAmuEDwAAIvsMAABwEG4A== From: "Steve Langstaff" To: "Christian Stredicke" , "Chris Boulton" , "Christer Holmberg \(JO/LMF\)" , X-Spam-Score: 0.6 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0607925403==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f This is a multi-part message in MIME format. --===============0607925403== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C72C.E8E25BAD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4C72C.E8E25BAD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Fair enough. =20 I must have missed the description of PING/PONG messages were for. =20 I apologise. --=20 Steve Langstaff.=20 -----Original Message----- From: Christian Stredicke [mailto:Christian.Stredicke@snom.de] Sent: 10 November 2004 10:36 To: Steve Langstaff; Chris Boulton; Christer Holmberg (JO/LMF); = fluffy@cisco.com Cc: sip@ietf.org Subject: RE: [Sip] PING/PONG True. For that purpose, use e.g. INFO messages with no body. These = messages keep the dialog "alive".=20 =20 However, the goal of the PING/PONG keep-alive messages is to keep the = NAT-binding alive. So that you are able to receive the first INVITE! =20 CS _____ =20 From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = Steve Langstaff Sent: Wednesday, November 10, 2004 5:16 AM To: Christian Stredicke; Chris Boulton; Christer Holmberg (JO/LMF); = fluffy@cisco.com Cc: sip@ietf.org Subject: RE: [Sip] PING/PONG (CS) OPTIONS has the problem that it is relatively expensive (size and = CPU) and might result in responses that exceed the UDP fragmentation = limit (there are many DSL routers that treat UDP fragmentation as = security problem including the one that I have at home). Therefore I = think it would not hurt to have a specific message that is designed only = for the keep-alive job. =20 ...but if you want your keep alive message to be routed over the same = path and transports as your original INVITE (and hence keep them alive), = don't you need most of the "expensive" content of (say) the OPTIONS = message - e.g. the vias. --=20 Steve Langstaff.=20 ------_=_NextPart_001_01C4C72C.E8E25BAD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Fair=20 enough.
 
I must=20 have missed the description of PING/PONG messages were=20 for.
 
I=20 apologise.

--
Steve=20 Langstaff.

-----Original Message-----
From: Christian Stredicke=20 [mailto:Christian.Stredicke@snom.de]
Sent: 10 November 2004=20 10:36
To: Steve Langstaff; Chris Boulton; Christer Holmberg = (JO/LMF);=20 fluffy@cisco.com
Cc: sip@ietf.org
Subject: RE: [Sip] = PING/PONG

True. For that purpose, use e.g. INFO messages = with no=20 body. These messages keep the dialog "alive".
 
However, the goal of the PING/PONG keep-alive = messages is=20 to keep the NAT-binding alive. So that you are able to receive the first = INVITE!
 
CS

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Steve=20 Langstaff
Sent: Wednesday, November 10, 2004 5:16 = AM
To:=20 Christian Stredicke; Chris Boulton; Christer Holmberg (JO/LMF);=20 fluffy@cisco.com
Cc: sip@ietf.org
Subject: RE: = [Sip]=20 PING/PONG

(CS) = OPTIONS has the=20 problem that it is relatively expensive (size and CPU) and might = result in=20 responses that exceed the UDP fragmentation limit (there are many DSL = routers=20 that treat UDP fragmentation as security problem including the one = that I have=20 at home). Therefore I think it would not hurt to have a specific = message that=20 is designed only for the keep-alive = job.
 
...but if you want your keep alive message to be routed over = the same=20 path and transports as your original INVITE (and hence keep them = alive), don't=20 you need most of the "expensive" content of (say) the = OPTIONS message -=20 e.g. the vias.

--
Steve=20 Langstaff.

------_=_NextPart_001_01C4C72C.E8E25BAD-- --===============0607925403== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0607925403==-- From sip-bounces@ietf.org Wed Nov 10 10:29:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20209 for ; Wed, 10 Nov 2004 10:29:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRuQu-00050R-3g for sip-web-archive@ietf.org; Wed, 10 Nov 2004 10:30:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRuOM-0003zP-Tg; Wed, 10 Nov 2004 10:28:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRuJG-0002kN-CC for sip@megatron.ietf.org; Wed, 10 Nov 2004 10:22:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19197 for ; Wed, 10 Nov 2004 10:22:56 -0500 (EST) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRuKE-0004pQ-EP for sip@ietf.org; Wed, 10 Nov 2004 10:23:59 -0500 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iAAFMKn17406; Wed, 10 Nov 2004 10:22:20 -0500 (EST) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Nov 2004 10:22:20 -0500 Message-ID: From: "Mary Barnes" To: "'Jesske, R'" , sebastien.garcin@francetelecom.com, sip@ietf.org Subject: RE: [Sip] Privacy statements and History (draft-ietf-sip-history- info-04.txt) Date: Wed, 10 Nov 2004 10:21:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.9 (/) X-Scan-Signature: eb4c5242518af073df6fe45f0d1cde3e Cc: VL-T-Com-T-TE332@vli.telekom.de X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1649367809==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: fba2f9e3429fd649356ecb87f3ef34a7 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1649367809== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C738.F0CCA79B" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4C738.F0CCA79B Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by zrtps0kp.nortelnetworks.com id iAAFMKn17406 Content-Transfer-Encoding: quoted-printable Roland and Sebastien, =20 I too agree with the proposal to change the strength of the referenced statement from section 4.3.3.1.1 from MUST to SHOULD. This change is consistent with the other normative statements in section 4.3.3.1.1, whic= h are SHOULDs rather than MUSTs. I'll make that change in the next rev unless someone raises concerns over that change.=20 =20 On the second concern, I'm not clear what the proposed change is for the following: [SG] Another issue is the decision to add hi-entries in a privacy context= . A proxy changing the target (i.e. the proxy is responsible of the resource reflected in the received Request-URI) of a request which contained a "privacy=3Dhistory" header MAY add a history-entries provided that it kno= ws it can rely on other entities within the trust domain to apply the requested privacy. This affect item 4 in the list on conditions of section 4.3.3 an= d 4.3.3.1.=20 =20 Item 4 in section 4.3.3 describes the general situation, thus the strengt= h (MAY) describes the general fact that the use of privacy is optional. Th= e normative text provided in 4.3.3.1, provides the general model for adding hi-entries, with the privacy specific considerations for adding the entri= es described in 4.3.3.1.1. I think what you're suggesting is changing the strength of the following statement in section 4.3.3.1: " The hi-entry MUST be added following any hi-entry received in the reque= st being forwarded." I can see that in the context of privacy considerations, this might seem misleading. That MUST was originally a SHOULD but was changed (as discus= sed on the list and at IETF-60) to MUST based on issue JRE- 4, so a simple change of MUST to MAY would not at all work. I thought it was clear from the statement at the beginning of 4.3.3.1, that this section is describin= g the scenario under which the general privacy considerations had been evaluated and the intention was to add an hi-entry, thus the statements should be read in the context that the general screening indicates that a= n hi-entry SHOULD be added and if one is added it MUST be added following a= ny entry that's already in the request to preserve the ordering. If you ha= ve explicit changes to the text that you think would further clarify the functionality, we can discuss.=20 =20 Roland, if you have specific text on how I could incorporate a reference = to RFC3323, we can consider that; fundamentally any discussion of privacy depends on RFC 3323, so it's not clear to me how you were suggesting we incorporate such a reference. The text in this document (history-info) should accurately describe the processing impact of the new "history" priv-value.=20 =20 Thanks for your input, Mary=20 -----Original Message----- From: Jesske, R [mailto:R.Jesske@t-com.net]=20 Sent: Wednesday, November 10, 2004 7:59 AM To: sebastien.garcin@francetelecom.com; Barnes, Mary [NGC:B601:EXCH]; sip@ietf.org Cc: VL-T-Com-T-TE332@vli.telekom.de Subject: AW: [Sip] Privacy statements and History (draft-ietf-sip-history-info-04.txt) Dear Mary and Sebastien, here are my Comments to Sebastien's statements: =20 Your first proposal I can accept from my point of view. On you second issue my impression is that this issue must be seen with regard to RFC3323 where privacy and the trust concept is described. Perha= ps a reference to this document should be included. On your last point, I think we can also refer to RFC 3323. =20 What are you thinking? =20 Best Regards =20 Roland =20 ---- Mary snipped forwarding info to keep message smaller----------- =20 -----Original Message----- From: GARCIN Sebastien RD-CORE-ISS [mailto:sebastien.garcin@francetelecom.com]=20 Sent: Monday, November 08, 2004 10:11 AM To: Barnes, Mary [NGC:B601:EXCH]; sip@ietf.org Subject: [Sip] Privacy statements and History (draft-ietf-sip-history-info-04.txt) Hi mary, all =20 When reading draft-ietf-sip-history-info-04.txt, I have trouble in understanding some of the statements which relate to the forwarding rules for history-entries subject to privacy. It is an important requirement th= at History-entrie(s) with a Privacy=3Dhistory, session, or header are indeed forwarded to entities which belong to the same trust domain. The removal = of specific history-entries should only occur if the peer does not belong to the trust domain. =20 In the current text (section 4.3.3.1.1) : If a request is being forwarded to a Request URI associated with a domai= n for which the proxy is not responsible and there is a Privacy header in t= he request with a priv-value of "session", "header" or "history", the proxy MUST remove any hi-entry(s) prior to forwarding.=20 =20 The current wording is misleading since it gives the impression (maybe intentionnal) that it is not possible to forward history-entries with Privacy statements to domains under the responsability of e.g. another operator belonging to the same trust domain. =20 =20 [MB]: Current wording is consistent with terminology in RFC 3261 in terms= of describing who is able to change the Request URI in a specific request (based on section 16.5):=20 " A proxy MUST NOT add additional targets to the target set if the Request-URI of the original request does not indicate a resource this proxy is responsible for. A proxy can only change the Request-URI of a request during forwarding if it is responsible for that URI. " Since History-Info (and associated privacy) are only added to the request= , when an entity that is allowed to change the Request-URI retargets the request, it seemed sensible to use consistent wording to explain that. =20 [/MB]=20 [SG] I have no problem with the statements above. My concern is that if there is a hi-entry already embedded in the request with a Privacy statement, then, it should be up to local policy to decide whether or not= a proxy shall pass on those hi-entries to a trusted domain. The sentence in section 4.3.3.1.1 precludes this. I would propose to lighten the strenght= of the sentence as follows: =20 If a request is being forwarded to a Request URI associated with a domai= n for which the proxy is not responsible and there is a Privacy header in t= he request with a priv-value of "session", "header" or "history", the proxy = MAY remove any hi-entry(s) prior to forwarding.=20 =20 [SG] Another issue is the decision to add hi-entries in a privacy context= . A proxy changing the target (i.e. the proxy is responsible of the resource reflected in the received Request-URI) of a request which contained a "privacy=3Dhistory" header MAY add a history-entries provided that it kno= ws it can rely on other entities within the trust domain to apply the requested privacy. This affect item 4 in the list on conditions of section 4.3.3 an= d 4.3.3.1.=20 =20 The concept of "trust domain" should be used when discussing the forwardi= ng rules pertaining to information subject to privacy. Furthermore, the requirement for forwarding history-entries to trusted entities should be stated more clearly in the draft.=20 [MB]: The whole concept of what defines privacy in terms of the proxy's u= se of the privacy header is outside the scope of History-Info functionality = and really a matter of local policy. I think the functionality that you wan= t is a matter of local implementation and policy in terms of operators establishing this "trust domain" model to which you refer. History-Info defines the mechanism to ensure the privacy of the requests, but it doesn= 't explicitly define how the proxy knows whether it is responsible for that resource. I don't think this is a matter of standardization. I though= t the use of the term "domain" rather than "resouce" would be helpful, but perhaps changing it to the more general "resource" would resolve this concern and/or a statement clarifying what I've just described should be added in the draft.=20 [/MB] [SG] Changing the term "domain" to "resource" does not solve the proble= m I mentionned above. In order to reflect current operator requirements, the draft should not PRECLUDE the fowarding of existing history information towards trusted domains. =20 Thank you for clarifying this point. =20 Best regards, s=E9bastien =20 =20 ------Remainder of non-related part of this thread has been deleted by Mary------------------ ------_=_NextPart_001_01C4C738.F0CCA79B Content-Type: text/html; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by zrtps0kp.nortelnetworks.com id iAAFMKn17406 Content-Transfer-Encoding: quoted-printable Message
Roland=20 and Sebastien,
 
I too=20 agree with the proposal to change the strength of the referenced statemen= t from=20 section 4.3.3.1.1  from MUST to SHOULD. This change is consiste= nt with=20 the other normative statements in section 4.3.3.1.1, which are SHOULDs ra= ther=20 than MUSTs.   I'll make that change in the next rev unless some= one=20 raises concerns over that change.
 
On the=20 second concern, I'm not clear what the proposed change is for the=20 following:
[SG] Another issue is the decisio= n to add=20 hi-entries in a privacy context. A proxy changing the target (i.e. t= he=20 proxy is responsible of the resource reflected in the received Request-UR= I) of a=20 request which contained a "privacy=3Dhistory" header MAY add a=20 history-entries provided that it knows it can rely on othe= r=20 entities within the trust domain to apply the requested privacy. Thi= s=20 affect item 4 in the list on conditions of section 4.3.3 and 4.3.3.1.=20
 
Item 4 in sec= tion 4.3.3=20 describes the general situation, thus the strength (MAY) describes the ge= neral=20 fact that the use of privacy is optional.  The normative text provid= ed in=20 4.3.3.1, provides the general model for adding hi-entries, with the priva= cy=20 specific considerations for adding the entries described in 4.3.3.1.1.&nb= sp; I=20 think what you're suggesting is changing the strength of the followi= ng=20 statement in section 4.3.3.1:
" The hi-entr= y MUST be=20 added following any hi-entry received in the request being=20 forwarded."
I=20 can see that in the context of privacy considerations, this might seem=20 misleading.  That MUST was originally a SHOULD but was changed (as=20 discussed on the list and at IETF-60) to MUST based on issue JRE- 4,= so a=20 simple change of MUST to MAY would not at all work.  I thought it wa= s clear=20 from the statement at the beginning of 4.3.3.1, that this section is desc= ribing=20 the scenario under which the general privacy considerations had been eval= uated=20 and the intention was to add an hi-entry, thus the statements should be r= ead in=20 the context that the general screening indicates that an hi-entry SHOULD = be=20 added and if one is added it MUST be added following any entry that's alr= eady in=20 the request to preserve the ordering.   If you have explicit changes= to the=20 text that you think would further clarify the functionality, we can discu= ss.=20
 
Roland, if you have specific text on how I cou= ld=20 incorporate a reference to RFC3323, we can consider that; fundamentally a= ny=20 discussion of privacy depends on RFC 3323, so it's not clear to me how yo= u were=20 suggesting we incorporate such a reference.  The text in this docume= nt=20 (history-info) should accurately describe the processing impact of the ne= w=20 "history" priv-value.
 
Thanks=20 for your input,
Mary
<= FONT=20 face=3DTahoma size=3D2>-----Original Message-----
From: Jessk= e, R=20 [mailto:R.Jesske@t-com.net]
Sent: Wednesday, November 10, 20= 04 7:59=20 AM
To: sebastien.garcin@francetelecom.com; Barnes, Mary=20 [NGC:B601:EXCH]; sip@ietf.org
Cc:=20 VL-T-Com-T-TE332@vli.telekom.de
Subject: AW: [Sip] Privacy=20 statements and History=20 (draft-ietf-sip-history-info-04.txt)

Dear=20 Mary and Sebastien,
here=20 are my Comments to Sebastien's statements:
 
Your=20 first proposal I can accept from my point of view.
On=20 you second issue my impression is that this issue must be seen with reg= ard to=20 RFC3323 where privacy and the trust concept is described. Perhaps a ref= erence=20 to this document should be included.
On=20 your last point, I think we can also refer to RFC 3323.
 
What are you thinking?
 
Best=20 Regards
 
Roland
 
 ---- = Mary snipped=20 forwarding info to keep message smaller----------- 
-----Original Message-----
From:= GARCIN=20 Sebastien RD-CORE-ISS [mailto:sebastien.garcin@francetelecom.com]= =20
Sent: Monday, November 08, 2004 10:11 AM
To:= =20 Barnes, Mary [NGC:B601:EXCH]; sip@ietf.org
Subject: [Si= p]=20 Privacy statements and History=20 (draft-ietf-sip-history-info-04.txt)

Hi mary, all
 
When=20 reading draft-ietf-sip-history-info-04.txt, I have trou= ble in=20 understanding some of the statements which relate to the forwardi= ng=20 rules for history-entries subject to=20 privacy. It is an important=20 requirement that History-entrie(s) with a=20 Privacy=3Dhistory, session, or header are indeed forwarded&n= bsp;to=20 entities which belong to the same trust domain. Th= e=20 removal of specific history-entries should only occur if the= peer=20 does not belong to the trust domain.
 
I= n the current=20 text (section 4.3.3.1.1) :
If a request is  being forwa= rded to a=20 Request URI associated with a domain for which the p= roxy is=20 not responsible and there is a Privacy header in=20 the request wit= h a=20 priv-value of "session", "header" or "history", the proxy MU= ST=20 remove any hi-entry(s) prior to forwarding.
 
The current wording is m= isleading=20 since it gives the impression (maybe intentionnal) that it is not= =20 possible to forward history-entries with Privacy statements to do= mains=20 under the responsability of e.g. another operator belonging = to the=20 same trust domain.  
&nb= sp;
[MB]: C= urrent=20 wording is consistent with terminology in RFC 3261 in terms of=20 describing who is able to change the Request URI in a specif= ic=20 request (based on section=20 16.5): 
   " A= proxy MUST=20 NOT add additional targets to the target set if the
 &nbs= p;=20 Request-URI of the original request does not indicate a resource=20 this
   proxy is responsible=20 for.

      A proxy can only chang= e the=20 Request-URI of a request during
     = =20 forwarding if it is responsible for that URI.=20 "
Since H= istory-Info=20 (and associated privacy) are only added to the request, = ;when=20 an entity that is allowed to change the Request-URI ret= argets=20 the request, it seemed sensible to use consistent wording to expl= ain=20 that.   
[/MB= ] <= /SPAN>
 [SG] I h= ave no=20 problem with the statements above. My concern is that if the= re is=20 a hi-entry already embedded in the request with = a=20 Privacy statement, then, it should be up to local policy to = decide=20 whether or not a proxy shall pass on those hi-entries to a t= rusted=20 domain. The sentence in section 4.3.3.1.1 precludes this. I = would=20 propose to lighten the strenght of the sentence as=20 follows:
=  
If a request is  being forwarded = to a=20 Request URI associated with a domain for which the p= roxy is=20 not responsible and there is a Privacy header in=20 the request wit= h a=20 priv-value of "session", "header" or "history", the proxy&nb= sp;MAY=20 remove any hi-entry(s) prior to forwarding. =
=  
[SG] Anoth= er issue is=20 the decision to add hi-entries in a privacy context. A proxy= =20 changing the target (i.e. the proxy is responsible of the resourc= e=20 reflected in the received Request-URI) of a request which contain= ed a=20 "privacy=3Dhistory" header MAY add a=20 history-entries provided that it knows it can rely= on=20 other entities within the trust domain to apply the requeste= d=20 privacy. This affect item 4 in the list on conditions of section = 4.3.3=20 and 4.3.3.1.
 
The concept of "trust=20 domain" should be used when discussing the forward= ing=20 rules pertaining to information subject to privacy.=20 Furthermore, the requirement for forwarding history-entries = to=20 trusted entities should be stated more clearly in the draft.=  
[MB]: The whole concept of what define= s privacy=20 in terms of the proxy's use of the privacy header is outside the = scope=20 of History-Info functionality and really a matter of local policy= .=20   I think the functionality that you want is a matter of loc= al=20 implementation and policy in terms of operators establishing= this=20 "trust domain" model to which you refer.  History-Info = defines=20 the mechanism to ensure the privacy of the requests, but it=20 doesn't explicitly define how the proxy knows whether i= t is=20 responsible for that resource.    I don't thi= nk this=20 is a matter of standardization.  I thought the use of the te= rm=20 "domain" rather than "resouce" would be helpful, but perhaps chan= ging it=20 to the more general "resource" would resolve this concern and/or = a=20 statement clarifying what I've just described should be added in = the=20 draft.
[/MB][SG]   Ch= anging the=20 term "domain" to "resource" does not solve the problem I men= tionned=20 above. In order to reflect current operator requirement= s, the=20 draft should not PRECLUDE the fowarding of existing history infor= mation=20 towards trusted=20 domains.
 
Thank you for clarifying this=20 point.
 
Best regards,
s=E9bastien
 
 

------Remainder of non-related part of this thread has b= een=20 deleted by=20 Mary------------------
<= /BLOCKQUOTE>
------_=_NextPart_001_01C4C738.F0CCA79B-- --===============1649367809== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1649367809==-- From sip-bounces@ietf.org Wed Nov 10 10:59:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23744 for ; Wed, 10 Nov 2004 10:59:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRutL-0005lC-M1 for sip-web-archive@ietf.org; Wed, 10 Nov 2004 11:00:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRueI-0007Ba-Tq; Wed, 10 Nov 2004 10:44:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRuar-0006bs-J7; Wed, 10 Nov 2004 10:41:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21525; Wed, 10 Nov 2004 10:41:07 -0500 (EST) Received: from amer-mta01.csc.com ([20.137.2.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRubo-0005H7-Pd; Wed, 10 Nov 2004 10:42:10 -0500 Received: from csc.com (va-fch34.csc.com [20.6.39.227]) by amer-mta01.csc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id iAAFf0qb017186; Wed, 10 Nov 2004 10:41:00 -0500 (EST) Subject: [Sip] More general question on S-S-L mode in RPH To: "James M. Polk" X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Janet P Gunn Date: Wed, 10 Nov 2004 10:39:28 -0500 X-MIMETrack: Serialize by Router on VA-FCH34/SRV/CSC(Release 6.0.3|September 26, 2003) at 11/10/2004 10:41:50 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: Richard F Kaczmarek , Darren E Pado , Saud Negash , sip@ietf.org, sip-bounces@ietf.org, nyquetek@msn.com, Dennis Q Berg X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 What do the S-S-L modes apply to? In this case, I am just looking just at the dimension of which messages are accepted, and which are rejected- ignoring the other features which have been associated with the mode. 4.3.2 says that "mode" is a characteristic of the SIP element: "When handling requests with unknown namespaces or priority values, elements can operate in one of three modes, "strict", "semi-strict" and "loose"." This makes some sense to me (comments below). There are other places that imply that the mode is a characteristic of the domain. 4.3.3 says: "Strict Mode is for administrative domains (or realms) that ..." But table 1 in section 7 says: " New New Error Namespace Levels Mode Operation Rej. code code Reference --------- ------ ---- --------- --------- ---- --------- dsn 5 strict preemption no 417 [This RFC] drsn 6 strict preemption no 417 [This RFC] q735 5 strict preemption no 417 [This RFC] ets 5 semi-strict preferential no 417 [This RFC] wps 5 semi-strict preferential no 417 [This RFC] Table 1. Namespace Parameters" Which makes "mode" a characteristic of the namespace. This makes less sense to me. If any of these namespaces appear in an RPH in a SIP message which is being processed by a SIP element operating in loose mode, they will NOT get the strict or semi-strict behavior specified in Table 1. It seems to me that the mode is/should be a function of the (SIP element, namespace) pair. For instance a SIP element could be "strict" for namespace A and "semi-strict" for namespace B. So a message with just A would succeed A message with just B would be rejected A message with A and B would succeed A message with just C would be rejected A message with A and C would be rejected Or the SIP element could be "strict" for namespace A, and "loose" for everything else. So a message with just A would succeed A message with just B would be rejected A message with A and B would succeed A message with just C would be rejected A message with A and C would be succeed. I don't think you could combine "semi-strict" and "loose" in the same SIP element. Am I missing something? 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. ---------------------------------------------------------------------------------------- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 10 11:57:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00612 for ; Wed, 10 Nov 2004 11:57:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRvo3-0007OY-FM for sip-web-archive@ietf.org; Wed, 10 Nov 2004 11:58:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRvhQ-0007pl-DK; Wed, 10 Nov 2004 11:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRvZJ-0006aU-PS; Wed, 10 Nov 2004 11:43:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28945; Wed, 10 Nov 2004 11:43:35 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRvaH-0006za-1t; Wed, 10 Nov 2004 11:44:39 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 10 Nov 2004 08:54:54 -0800 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iAAGgwnC005258; Wed, 10 Nov 2004 08:42:59 -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 IAA04318; Wed, 10 Nov 2004 08:42:56 -0800 (PST) Message-Id: <4.3.2.7.2.20041110101752.02604f00@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 10 Nov 2004 10:43:00 -0600 To: Janet P Gunn From: "James M. Polk" Subject: Re: [Sip] More general question on S-S-L mode in RPH In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: Richard F Kaczmarek , Darren E Pado , Saud Negash , sip@ietf.org, sip-bounces@ietf.org, nyquetek@msn.com, Dennis Q Berg X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Clearly this document needs to address the behaviors you want in a mode (if they remain in the document), and clearly semi-strict as defined is not exactly as you want it. Are you missing something...? Domains will operate their network as they see fit, and this document will not dictate how that is accomplished. This is a document that describes a header with several field values. Some field values can be used to prevent communications in known networks, so the expected behaviors of those field values should be articulated somewhere in a document where the header is defined (the IETF). A concern is 2 years from now someone operating a network will want to use this header in their network and want guidance as to which field values to use from a list of predefined values, or suggest a new one be created for unique conditions. Since SIP is an end-to-end protocol (not accounting for B2BUAs), a SIP message with this header may have one behavior in one network and a completely different (and potentially undesirable) behavior in another network. The modes articulated in this document are to explain usages that "can" (not must) be experienced in some networks when using specific namespaces created for specific purposes. Each are as much to caution as they are to define the behavior of usage. If a namespace has a general characteristic of preemption as a behavior in a known network(s) - that namespace should not be used by endpoints in another network that does not include the behavior of preemption. Undesirable consequences will occur when communicated between those networks. This is all guidance, it's not a law anywhere At 10:39 AM 11/10/2004 -0500, Janet P Gunn wrote: >What do the S-S-L modes apply to? > >In this case, I am just looking just at the dimension of which messages are >accepted, and which are rejected- ignoring the other features which have >been associated with the mode. > >4.3.2 says that "mode" is a characteristic of the SIP element: > >"When handling requests with unknown namespaces or priority values, > elements can operate in one of three modes, "strict", "semi-strict" > and "loose"." > >This makes some sense to me (comments below). > >There are other places that imply that the mode is a characteristic of the >domain. 4.3.3 says: > >"Strict Mode is for administrative domains (or realms) that ..." > >But table 1 in section 7 says: > >" New New Error >Namespace Levels Mode Operation Rej. code code Reference >--------- ------ ---- --------- --------- ---- --------- > dsn 5 strict preemption no 417 [This RFC] > > drsn 6 strict preemption no 417 [This RFC] > > q735 5 strict preemption no 417 [This RFC] > > ets 5 semi-strict preferential no 417 [This RFC] > > wps 5 semi-strict preferential no 417 [This RFC] > > Table 1. Namespace Parameters" > >Which makes "mode" a characteristic of the namespace. > >This makes less sense to me. If any of these namespaces appear in an RPH >in a SIP message which is being processed by a SIP element operating in >loose mode, they will NOT get the strict or semi-strict behavior specified >in Table 1. > >It seems to me that the mode is/should be a function of the (SIP element, >namespace) pair. > >For instance a SIP element could be "strict" for namespace A and >"semi-strict" for namespace B. > >So a message with just A would succeed >A message with just B would be rejected >A message with A and B would succeed >A message with just C would be rejected >A message with A and C would be rejected > >Or the SIP element could be "strict" for namespace A, and "loose" for >everything else. > >So a message with just A would succeed >A message with just B would be rejected >A message with A and B would succeed >A message with just C would be rejected >A message with A and C would be succeed. > >I don't think you could combine "semi-strict" and "loose" in the same SIP >element. > >Am I missing something? > >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. >---------------------------------------------------------------------------------------- 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 sip-bounces@ietf.org Wed Nov 10 13:47:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11867 for ; Wed, 10 Nov 2004 13:47:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRxWJ-0001YS-WF for sip-web-archive@ietf.org; Wed, 10 Nov 2004 13:48:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRxPK-0004dX-LK; Wed, 10 Nov 2004 13:41:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRxKh-0003lC-Rw; Wed, 10 Nov 2004 13:36:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10716; Wed, 10 Nov 2004 13:36:36 -0500 (EST) From: Mpierce1@aol.com Received: from imo-d20.mx.aol.com ([205.188.139.136]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRxLh-0001Iw-DO; Wed, 10 Nov 2004 13:37:42 -0500 Received: from Mpierce1@aol.com by imo-d20.mx.aol.com (mail_out_v37_r3.8.) id t.be.1b89d95a (3924); Wed, 10 Nov 2004 13:36:00 -0500 (EST) Message-ID: Date: Wed, 10 Nov 2004 13:36:00 EST Subject: Re: [Sip] More general question on S-S-L mode in RPH To: jgunn6@csc.com, jmpolk@cisco.com MIME-Version: 1.0 X-Mailer: 6.0 for Windows XP sub 10500 X-Spam-Score: 0.8 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: rkaczmarek@csc.com, dpado@csc.com, snegash@csc.com, sip@ietf.org, sip-bounces@ietf.org, nyquetek@msn.com, dberg3@csc.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1527209579==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 --===============1527209579== Content-Type: multipart/alternative; boundary="part1_be.1b89d95a.2ec3b990_boundary" --part1_be.1b89d95a.2ec3b990_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 11/10/2004 11:00:13 AM Eastern Standard Time, jgunn6@csc.com writes: > For instance a SIP element could be "strict" for namespace A and > "semi-strict" for namespace B. > This doesn't make sense. Part of the use of the mode still is to determine what to do when the receiving element does not understand the namespace, that is, it thinks it needs a namespace but doesn't see one it understands. (This was the only use of the mode in version -04.) Becasue of this, the mode must be a function of the domain, or rather, of every element in the domain. It is not associated with a namespace. Each element must know what mode it is supposed to operate in independent of what namespace is being used. Version -04 was based on an element or UAS operating in a specific mode and did not try to associate the mode with the namespace. This technical change is another reason why I believe that version -05 should be rejected. Mike --part1_be.1b89d95a.2ec3b990_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message=20= dated 11/10/2004 11:00:13 AM Eastern Standard Time, jgunn6@csc.com writes:


For instance a SIP element=20= could be "strict" for namespace A and
"semi-strict" for namespace B.



This doesn't make sense. Part of the use of the mode still is to determi= ne what to do when the receiving element does not understand the namespace,=20= that is, it thinks it needs a namespace but doesn't see one it understands.=20= (This was the only use of the mode in version -04.) Becasue of this, the mod= e must be a function of the domain, or rather, of every element in the domai= n. It is not associated with a namespace. Each element must know what mode i= t is supposed to operate in independent of what namespace is being used.

Version -04 was based on an element or UAS operating in a specific mode=20= and did not try to associate the mode with the namespace. This technical cha= nge is another reason why I believe that version -05 should be rejected.

Mike
--part1_be.1b89d95a.2ec3b990_boundary-- --===============1527209579== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1527209579==-- From sip-bounces@ietf.org Wed Nov 10 13:49:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12094 for ; Wed, 10 Nov 2004 13:49:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRxYJ-0001ci-SG for sip-web-archive@ietf.org; Wed, 10 Nov 2004 13:50:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRxPj-0004jS-LU; Wed, 10 Nov 2004 13:41:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRxOE-0004QC-J2 for sip@megatron.ietf.org; Wed, 10 Nov 2004 13:40:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10980 for ; Wed, 10 Nov 2004 13:40:17 -0500 (EST) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRxPB-0001Of-G6 for sip@ietf.org; Wed, 10 Nov 2004 13:41:21 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 10 Nov 2004 19:27:35 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Sip] Privacy statements and History (draft-ietf-sip-history-info-04.txt) Date: Wed, 10 Nov 2004 19:27:34 +0100 Message-ID: <49E7012A614B024B80A7D175CB9A64EC8A0B6E@ftrdmel1.rd.francetelecom.fr> Thread-Topic: [Sip] Privacy statements and History (draft-ietf-sip-history-info-04.txt) Thread-Index: AcTHORYP2JVBhFc9QaK//OB7bdk51AACvm3A From: "GARCIN Sebastien RD-CORE-ISS" To: "Mary Barnes" , "Jesske, R" , X-OriginalArrivalTime: 10 Nov 2004 18:27:35.0240 (UTC) FILETIME=[F3106480:01C4C752] X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Content-Transfer-Encoding: quoted-printable Cc: VL-T-Com-T-TE332@vli.telekom.de X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Content-Transfer-Encoding: quoted-printable Mary and roland, Actually, the statement regarding the forwarding of hi-entries beyond = the domain for which the proxy is responsible should rather be a matter = of local policy and thus a MAY should be used instead of SHOULD. We are = potentially dealing with network boundaries where agreements for = forwarding such kind information can be reached.=20 Section 4.3.3.1.1 This section should be re-reworded in accordance with the statement = above (I can provide some text is we can agree). Section 4.3.3.1 is ok (apologies for not being explicit) Best regards, s=E9bastien ________________________________ De : Mary Barnes [mailto:mary.barnes@nortelnetworks.com]=20 Envoy=E9 : mercredi 10 novembre 2004 16:21 =C0 : 'Jesske, R'; GARCIN Sebastien RD-CORE-ISS; sip@ietf.org Cc : VL-T-Com-T-TE332@vli.telekom.de Objet : RE: [Sip] Privacy statements and History = (draft-ietf-sip-history-info-04.txt) Roland and Sebastien, =20 I too agree with the proposal to change the strength of the referenced = statement from section 4.3.3.1.1 from MUST to SHOULD. This change is = consistent with the other normative statements in section 4.3.3.1.1, = which are SHOULDs rather than MUSTs. I'll make that change in the next = rev unless someone raises concerns over that change.=20 =20 On the second concern, I'm not clear what the proposed change is for the = following: [SG] Another issue is the decision to add hi-entries in a privacy = context. A proxy changing the target (i.e. the proxy is responsible of = the resource reflected in the received Request-URI) of a request which = contained a "privacy=3Dhistory" header MAY add a history-entries = provided that it knows it can rely on other entities within the trust = domain to apply the requested privacy. This affect item 4 in the list on = conditions of section 4.3.3 and 4.3.3.1.=20 =20 Item 4 in section 4.3.3 describes the general situation, thus the = strength (MAY) describes the general fact that the use of privacy is = optional. The normative text provided in 4.3.3.1, provides the general = model for adding hi-entries, with the privacy specific considerations = for adding the entries described in 4.3.3.1.1. I think what you're = suggesting is changing the strength of the following statement in = section 4.3.3.1: " The hi-entry MUST be added following any hi-entry received in the = request being forwarded." I can see that in the context of privacy considerations, this might seem = misleading. That MUST was originally a SHOULD but was changed (as = discussed on the list and at IETF-60) to MUST based on issue JRE- 4, so = a simple change of MUST to MAY would not at all work. I thought it was = clear from the statement at the beginning of 4.3.3.1, that this section = is describing the scenario under which the general privacy = considerations had been evaluated and the intention was to add an = hi-entry, thus the statements should be read in the context that the = general screening indicates that an hi-entry SHOULD be added and if one = is added it MUST be added following any entry that's already in the = request to preserve the ordering. If you have explicit changes to the = text that you think would further clarify the functionality, we can = discuss.=20 =20 Roland, if you have specific text on how I could incorporate a reference = to RFC3323, we can consider that; fundamentally any discussion of = privacy depends on RFC 3323, so it's not clear to me how you were = suggesting we incorporate such a reference. The text in this document = (history-info) should accurately describe the processing impact of the = new "history" priv-value.=20 =20 Thanks for your input, Mary=20 -----Original Message----- From: Jesske, R [mailto:R.Jesske@t-com.net]=20 Sent: Wednesday, November 10, 2004 7:59 AM To: sebastien.garcin@francetelecom.com; Barnes, Mary [NGC:B601:EXCH]; = sip@ietf.org Cc: VL-T-Com-T-TE332@vli.telekom.de Subject: AW: [Sip] Privacy statements and History = (draft-ietf-sip-history-info-04.txt) =09 =09 Dear Mary and Sebastien, here are my Comments to Sebastien's statements: =20 Your first proposal I can accept from my point of view. On you second issue my impression is that this issue must be seen with = regard to RFC3323 where privacy and the trust concept is described. = Perhaps a reference to this document should be included. On your last point, I think we can also refer to RFC 3323. =20 What are you thinking? =20 Best Regards =20 Roland =20 ---- Mary snipped forwarding info to keep message smaller----------- = =09 -----Original Message----- From: GARCIN Sebastien RD-CORE-ISS = [mailto:sebastien.garcin@francetelecom.com]=20 Sent: Monday, November 08, 2004 10:11 AM To: Barnes, Mary [NGC:B601:EXCH]; sip@ietf.org Subject: [Sip] Privacy statements and History = (draft-ietf-sip-history-info-04.txt) =09 =09 Hi mary, all =20 When reading draft-ietf-sip-history-info-04.txt, I have trouble in = understanding some of the statements which relate to the forwarding = rules for history-entries subject to privacy. It is an important = requirement that History-entrie(s) with a Privacy=3Dhistory, session, or = header are indeed forwarded to entities which belong to the same trust = domain. The removal of specific history-entries should only occur if the = peer does not belong to the trust domain. =20 In the current text (section 4.3.3.1.1) : If a request is being forwarded to a Request URI associated with a = domain for which the proxy is not responsible and there is a Privacy = header in the request with a priv-value of "session", "header" or = "history", the proxy MUST remove any hi-entry(s) prior to forwarding.=20 =20 The current wording is misleading since it gives the impression = (maybe intentionnal) that it is not possible to forward history-entries = with Privacy statements to domains under the responsability of e.g. = another operator belonging to the same trust domain. =20 =20 [MB]: Current wording is consistent with terminology in RFC 3261 in = terms of describing who is able to change the Request URI in a specific = request (based on section 16.5):=20 " A proxy MUST NOT add additional targets to the target set if = the Request-URI of the original request does not indicate a resource = this proxy is responsible for. =09 A proxy can only change the Request-URI of a request during forwarding if it is responsible for that URI. " Since History-Info (and associated privacy) are only added to the = request, when an entity that is allowed to change the Request-URI = retargets the request, it seemed sensible to use consistent wording to = explain that. =20 [/MB]=20 [SG] I have no problem with the statements above. My concern is = that if there is a hi-entry already embedded in the request with a = Privacy statement, then, it should be up to local policy to decide = whether or not a proxy shall pass on those hi-entries to a trusted = domain. The sentence in section 4.3.3.1.1 precludes this. I would = propose to lighten the strenght of the sentence as follows: =20 If a request is being forwarded to a Request URI associated with a = domain for which the proxy is not responsible and there is a Privacy = header in the request with a priv-value of "session", "header" or = "history", the proxy MAY remove any hi-entry(s) prior to forwarding.=20 =20 [SG] Another issue is the decision to add hi-entries in a privacy = context. A proxy changing the target (i.e. the proxy is responsible of = the resource reflected in the received Request-URI) of a request which = contained a "privacy=3Dhistory" header MAY add a history-entries = provided that it knows it can rely on other entities within the trust = domain to apply the requested privacy. This affect item 4 in the list on = conditions of section 4.3.3 and 4.3.3.1.=20 =20 The concept of "trust domain" should be used when discussing the = forwarding rules pertaining to information subject to privacy. = Furthermore, the requirement for forwarding history-entries to trusted = entities should be stated more clearly in the draft.=20 [MB]: The whole concept of what defines privacy in terms of the = proxy's use of the privacy header is outside the scope of History-Info = functionality and really a matter of local policy. I think the = functionality that you want is a matter of local implementation and = policy in terms of operators establishing this "trust domain" model to = which you refer. History-Info defines the mechanism to ensure the = privacy of the requests, but it doesn't explicitly define how the proxy = knows whether it is responsible for that resource. I don't think this = is a matter of standardization. I thought the use of the term "domain" = rather than "resouce" would be helpful, but perhaps changing it to the = more general "resource" would resolve this concern and/or a statement = clarifying what I've just described should be added in the draft.=20 [/MB] [SG] Changing the term "domain" to "resource" does not solve the = problem I mentionned above. In order to reflect current operator = requirements, the draft should not PRECLUDE the fowarding of existing = history information towards trusted domains. =20 Thank you for clarifying this point. =20 Best regards, s=E9bastien =20 =20 ------Remainder of non-related part of this thread has been deleted = by Mary------------------ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 10 14:11:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14688 for ; Wed, 10 Nov 2004 14:11:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRxtE-0002Hb-BC for sip-web-archive@ietf.org; Wed, 10 Nov 2004 14:12:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRxp8-0001nS-WD; Wed, 10 Nov 2004 14:08:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRxcP-0007Uc-Bh for sip@megatron.ietf.org; Wed, 10 Nov 2004 13:54:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12686 for ; Wed, 10 Nov 2004 13:54:55 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRxdP-0001lK-0W for sip@ietf.org; Wed, 10 Nov 2004 13:56:00 -0500 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iAAIsGh05155; Wed, 10 Nov 2004 13:54:16 -0500 (EST) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Nov 2004 13:54:17 -0500 Message-ID: From: "Mary Barnes" To: "'GARCIN Sebastien RD-CORE-ISS'" , "Jesske, R" , sip@ietf.org Subject: RE: [Sip] Privacy statements and History (draft-ietf-sip-history- info-04.txt) Date: Wed, 10 Nov 2004 13:53:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.8 (/) X-Scan-Signature: a569a4168062bb63d79812a50c918a82 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1545549844==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 1069eb5b3f212f2b9b575eaf2aff5119 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1545549844== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C756.9EEA5C02" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4C756.9EEA5C02 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I still contend that the SHOULD is sufficient. SHOULD means that in = general processing, if the hi-entry has a privacy header, then the usual = processing would be that it would be removed (i.e it was added for a specific = reason and in general should be used to remove the entries based on well = defined criteria). If there are reasons, such as local policy, that would = allow the forwarding in specific cases, then it's okay that it is forwarded. I = think the use of MAY results in less precision and I think the value and = critera for associating and removing the privacy header with the hi-entry = becomes much less clear. =20 I'd like to hear more opinions on this topic, prior to agreeing to = making the change (from the MUST to MAY rather than MUST to SHOULD).=20 Regards,=20 Mary -----Original Message----- From: GARCIN Sebastien RD-CORE-ISS [mailto:sebastien.garcin@francetelecom.com]=20 Sent: Wednesday, November 10, 2004 12:28 PM To: Barnes, Mary [NGC:B601:EXCH]; Jesske, R; sip@ietf.org Cc: VL-T-Com-T-TE332@vli.telekom.de Subject: RE: [Sip] Privacy statements and History (draft-ietf-sip-history-info-04.txt) Mary and roland, Actually, the statement regarding the forwarding of hi-entries beyond = the domain for which the proxy is responsible should rather be a matter of = local policy and thus a MAY should be used instead of SHOULD. We are = potentially dealing with network boundaries where agreements for forwarding such = kind information can be reached.=20 Section 4.3.3.1.1 This section should be re-reworded in accordance with the statement = above (I can provide some text is we can agree). Section 4.3.3.1 is ok (apologies for not being explicit) Best regards, s=E9bastien ________________________________ De : Mary Barnes [mailto:mary.barnes@nortelnetworks.com]=20 Envoy=E9 : mercredi 10 novembre 2004 16:21 =C0 : 'Jesske, R'; GARCIN Sebastien RD-CORE-ISS; sip@ietf.org Cc : VL-T-Com-T-TE332@vli.telekom.de Objet : RE: [Sip] Privacy statements and History (draft-ietf-sip-history-info-04.txt) Roland and Sebastien, =20 I too agree with the proposal to change the strength of the referenced statement from section 4.3.3.1.1 from MUST to SHOULD. This change is consistent with the other normative statements in section 4.3.3.1.1, = which are SHOULDs rather than MUSTs. I'll make that change in the next rev unless someone raises concerns over that change.=20 =20 On the second concern, I'm not clear what the proposed change is for = the following: [SG] Another issue is the decision to add hi-entries in a privacy = context. A proxy changing the target (i.e. the proxy is responsible of the = resource reflected in the received Request-URI) of a request which contained a "privacy=3Dhistory" header MAY add a history-entries provided that it = knows it can rely on other entities within the trust domain to apply the = requested privacy. This affect item 4 in the list on conditions of section 4.3.3 = and 4.3.3.1.=20 =20 Item 4 in section 4.3.3 describes the general situation, thus the = strength (MAY) describes the general fact that the use of privacy is optional. = The normative text provided in 4.3.3.1, provides the general model for = adding hi-entries, with the privacy specific considerations for adding the = entries described in 4.3.3.1.1. I think what you're suggesting is changing the strength of the following statement in section 4.3.3.1: " The hi-entry MUST be added following any hi-entry received in the = request being forwarded." I can see that in the context of privacy considerations, this might = seem misleading. That MUST was originally a SHOULD but was changed (as = discussed on the list and at IETF-60) to MUST based on issue JRE- 4, so a simple change of MUST to MAY would not at all work. I thought it was clear = from the statement at the beginning of 4.3.3.1, that this section is = describing the scenario under which the general privacy considerations had been evaluated and the intention was to add an hi-entry, thus the statements should be read in the context that the general screening indicates that = an hi-entry SHOULD be added and if one is added it MUST be added following = any entry that's already in the request to preserve the ordering. If you = have explicit changes to the text that you think would further clarify the functionality, we can discuss.=20 =20 Roland, if you have specific text on how I could incorporate a = reference to RFC3323, we can consider that; fundamentally any discussion of privacy depends on RFC 3323, so it's not clear to me how you were suggesting we incorporate such a reference. The text in this document (history-info) should accurately describe the processing impact of the new "history" priv-value.=20 =20 Thanks for your input, Mary=20 -----Original Message----- From: Jesske, R [mailto:R.Jesske@t-com.net]=20 Sent: Wednesday, November 10, 2004 7:59 AM To: sebastien.garcin@francetelecom.com; Barnes, Mary [NGC:B601:EXCH]; sip@ietf.org Cc: VL-T-Com-T-TE332@vli.telekom.de Subject: AW: [Sip] Privacy statements and History (draft-ietf-sip-history-info-04.txt) =09 =09 Dear Mary and Sebastien, here are my Comments to Sebastien's statements: =20 Your first proposal I can accept from my point of view. On you second issue my impression is that this issue must be seen with regard to RFC3323 where privacy and the trust concept is = described. Perhaps a reference to this document should be included. On your last point, I think we can also refer to RFC 3323. =20 What are you thinking? =20 Best Regards =20 Roland =20 ---- Mary snipped forwarding info to keep message smaller----------- =20 =09 =09 -----Original Message----- From: GARCIN Sebastien RD-CORE-ISS [mailto:sebastien.garcin@francetelecom.com]=20 Sent: Monday, November 08, 2004 10:11 AM To: Barnes, Mary [NGC:B601:EXCH]; sip@ietf.org Subject: [Sip] Privacy statements and History (draft-ietf-sip-history-info-04.txt) =09 =09 Hi mary, all =20 When reading draft-ietf-sip-history-info-04.txt, I have trouble in understanding = some of the statements which relate to the forwarding rules for history-entries subject to privacy. It is an important requirement that = History-entrie(s) with a Privacy=3Dhistory, session, or header are indeed forwarded to = entities which belong to the same trust domain. The removal of specific history-entries should only occur if the peer does not belong to the = trust domain. =20 In the current text (section 4.3.3.1.1) : If a request is being forwarded to a Request URI associated with a domain for which the proxy is not = responsible and there is a Privacy header in the request with a priv-value of = "session", "header" or "history", the proxy MUST remove any hi-entry(s) prior to forwarding.=20 =20 The current wording is misleading since it gives the impression (maybe intentionnal) that it is not possible to = forward history-entries with Privacy statements to domains under the = responsability of e.g. another operator belonging to the same trust domain. =20 =20 [MB]: Current wording is consistent with terminology in RFC 3261 in terms of describing who is able to change = the Request URI in a specific request (based on section 16.5):=20 " A proxy MUST NOT add additional targets to the target set if the Request-URI of the original request does not indicate a resource this proxy is responsible for. =09 A proxy can only change the Request-URI of a request during forwarding if it is responsible for that URI. " Since History-Info (and associated privacy) are only added to the request, when an entity that is allowed to change = the Request-URI retargets the request, it seemed sensible to use consistent wording to explain that. =20 [/MB]=20 [SG] I have no problem with the statements above. My concern is that if there is a hi-entry already embedded in = the request with a Privacy statement, then, it should be up to local policy = to decide whether or not a proxy shall pass on those hi-entries to a = trusted domain. The sentence in section 4.3.3.1.1 precludes this. I would = propose to lighten the strenght of the sentence as follows: =20 If a request is being forwarded to a Request URI associated with a domain for which the proxy is not = responsible and there is a Privacy header in the request with a priv-value of = "session", "header" or "history", the proxy MAY remove any hi-entry(s) prior to forwarding.=20 =20 [SG] Another issue is the decision to add hi-entries in a privacy context. A proxy changing the target (i.e. the = proxy is responsible of the resource reflected in the received Request-URI) = of a request which contained a "privacy=3Dhistory" header MAY add a = history-entries provided that it knows it can rely on other entities within the trust = domain to apply the requested privacy. This affect item 4 in the list on = conditions of section 4.3.3 and 4.3.3.1.=20 =20 The concept of "trust domain" should be used when discussing the forwarding rules pertaining to information subject = to privacy. Furthermore, the requirement for forwarding history-entries to trusted entities should be stated more clearly in the draft.=20 [MB]: The whole concept of what defines privacy in terms of the proxy's use of = the privacy header is outside the scope of History-Info functionality and = really a matter of local policy. I think the functionality that you want is = a matter of local implementation and policy in terms of operators = establishing this "trust domain" model to which you refer. History-Info defines the mechanism to ensure the privacy of the requests, but it doesn't = explicitly define how the proxy knows whether it is responsible for that resource. = I don't think this is a matter of standardization. I thought the use of = the term "domain" rather than "resouce" would be helpful, but perhaps = changing it to the more general "resource" would resolve this concern and/or a statement clarifying what I've just described should be added in the = draft.=20 [/MB] [SG] Changing the term "domain" to "resource" does not solve the problem I mentionned above. In order to reflect current operator requirements, the draft should not PRECLUDE = the fowarding of existing history information towards trusted domains. =20 Thank you for clarifying this point. =20 Best regards, s=E9bastien =20 =20 ------Remainder of non-related part of this thread has been deleted by Mary------------------ ------_=_NextPart_001_01C4C756.9EEA5C02 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Privacy statements and History = (draft-ietf-sip-history-info-04.txt)

I still contend that the SHOULD is sufficient.  = SHOULD means that in general processing, if the hi-entry has a privacy = header, then the usual processing would be that it would be removed = (i.e it was added for a specific reason and in general should be used = to remove the entries based on well defined criteria).  If there = are reasons, such as local policy, that would allow the forwarding in = specific cases, then it's okay that it is forwarded.  I think the = use of MAY results in less precision and I think the value and critera = for associating and removing the privacy header with the hi-entry = becomes much less clear. 

I'd like to hear more opinions on this topic, prior = to agreeing to making the change (from the MUST to MAY rather than MUST = to SHOULD).

Regards,
Mary


-----Original Message-----
From: GARCIN Sebastien RD-CORE-ISS [mailto:sebastien.garc= in@francetelecom.com]
Sent: Wednesday, November 10, 2004 12:28 PM
To: Barnes, Mary [NGC:B601:EXCH]; Jesske, R; = sip@ietf.org
Cc: VL-T-Com-T-TE332@vli.telekom.de
Subject: RE: [Sip] Privacy statements and History = (draft-ietf-sip-history-info-04.txt)


Mary and roland,

Actually, the statement regarding the forwarding of = hi-entries beyond the domain for which the proxy is responsible should = rather be a matter of local policy and thus a MAY should be used = instead of SHOULD. We are potentially dealing with network boundaries = where agreements for forwarding such kind information can be reached. =

Section 4.3.3.1.1
This section should be re-reworded in accordance = with the statement above (I can provide some text is we can = agree).

Section 4.3.3.1 is ok (apologies for not being = explicit)

Best regards,
s=E9bastien



________________________________

De : Mary Barnes [mailto:mary.barnes@nortel= networks.com]
Envoy=E9 : mercredi 10 novembre 2004 16:21
=C0 : 'Jesske, R'; GARCIN Sebastien RD-CORE-ISS; = sip@ietf.org
Cc : VL-T-Com-T-TE332@vli.telekom.de
Objet : RE: [Sip] Privacy statements and History = (draft-ietf-sip-history-info-04.txt)


Roland and Sebastien,
 
I too agree with the proposal to change the strength = of the referenced statement from section 4.3.3.1.1  from MUST to = SHOULD. This change is consistent with the other normative statements = in section 4.3.3.1.1, which are SHOULDs rather than MUSTs.   = I'll make that change in the next rev unless someone raises concerns = over that change.

 
On the second concern, I'm not clear what the = proposed change is for the following:
[SG] Another issue is the decision to add hi-entries = in a privacy context. A proxy changing the target (i.e. the proxy is = responsible of the resource reflected in the received Request-URI) of a = request which contained a "privacy=3Dhistory" header MAY add = a history-entries provided that it knows it can rely on other entities = within the trust domain to apply the requested privacy. This affect = item 4 in the list on conditions of section 4.3.3 and 4.3.3.1. =

 
Item 4 in section 4.3.3 describes the general = situation, thus the strength (MAY) describes the general fact that the = use of privacy is optional.  The normative text provided in = 4.3.3.1, provides the general model for adding hi-entries, with the = privacy specific considerations for adding the entries described in = 4.3.3.1.1.  I think what you're suggesting is changing the = strength of the following statement in section 4.3.3.1:

" The hi-entry MUST be added following any = hi-entry received in the request being forwarded."
I can see that in the context of privacy = considerations, this might seem misleading.  That MUST was = originally a SHOULD but was changed (as discussed on the list and at = IETF-60) to MUST based on issue JRE- 4, so a simple change of MUST to = MAY would not at all work.  I thought it was clear from the = statement at the beginning of 4.3.3.1, that this section is describing = the scenario under which the general privacy considerations had been = evaluated and the intention was to add an hi-entry, thus the statements = should be read in the context that the general screening indicates that = an hi-entry SHOULD be added and if one is added it MUST be added = following any entry that's already in the request to preserve the = ordering.   If you have explicit changes to the text that you = think would further clarify the functionality, we can discuss. =

 
Roland, if you have specific text on how I could = incorporate a reference to RFC3323, we can consider that; fundamentally = any discussion of privacy depends on RFC 3323, so it's not clear to me = how you were suggesting we incorporate such a reference.  The text = in this document (history-info) should accurately describe the = processing impact of the new "history" priv-value. =

 
Thanks for your input,
Mary

        =         -----Original = Message-----
        From: = Jesske, R [mailto:R.Jesske@t-com.net] =
        Sent: = Wednesday, November 10, 2004 7:59 AM
        To: = sebastien.garcin@francetelecom.com; Barnes, Mary [NGC:B601:EXCH]; = sip@ietf.org
        Cc: = VL-T-Com-T-TE332@vli.telekom.de
        Subject: = AW: [Sip] Privacy statements and History = (draft-ietf-sip-history-info-04.txt)
       =20
       =20
        Dear Mary = and Sebastien,
        here are = my Comments to Sebastien's statements:
         =
        Your = first proposal I can accept from my point of view.
        On you = second issue my impression is that this issue must be seen with regard = to RFC3323 where privacy and the trust concept is described. Perhaps a = reference to this document should be included.

        On your = last point, I think we can also refer to RFC 3323.
         =
        What are = you thinking?
         =
        Best = Regards
         =
        Roland
         =

        =          ---- = Mary snipped forwarding info to keep message smaller-----------  =
        =        =20
        =         =         =         =         =         =         =         -----Original = Message-----
        =         =         =         From: GARCIN = Sebastien RD-CORE-ISS [mailto:sebastien.garc= in@francetelecom.com]
        =         =         =         Sent: Monday, = November 08, 2004 10:11 AM
        =         =         =         To: Barnes, = Mary [NGC:B601:EXCH]; sip@ietf.org
        =         =         =         Subject: = [Sip] Privacy statements and History = (draft-ietf-sip-history-info-04.txt)
        =         =         =        =20
        =         =         =        =20
        =         =         =         Hi mary, = all
        =         =         =         
        =         =         =         When reading = draft-ietf-sip-history-info-04.txt, I have trouble in understanding = some of the statements which relate to the forwarding rules for = history-entries subject to privacy. It is an important requirement that = History-entrie(s) with a Privacy=3Dhistory, session, or header are = indeed forwarded to entities which belong to the same trust domain. The = removal of specific history-entries should only occur if the peer does = not belong to the trust domain.

        =         =         =         
        =         =         =         In the = current text (section 4.3.3.1.1) :
        =         =         =         If a request = is  being forwarded to a Request URI associated with a domain for = which the proxy is not responsible and there is a Privacy header in the = request with a priv-value of "session", "header" or = "history", the proxy MUST remove any hi-entry(s) prior to = forwarding.

        =         =         =         
        =         =         =         The current = wording is misleading since it gives the impression (maybe = intentionnal) that it is not possible to forward history-entries with = Privacy statements to domains under the responsability of e.g. another = operator belonging to the same trust domain. 

        =         =         =         
        =         =         =         [MB]: Current = wording is consistent with terminology in RFC 3261 in terms of = describing who is able to change the Request URI in a specific request = (based on section 16.5):

        =         =         =            = " A proxy MUST NOT add additional targets to the target set if = the
        =         =         =            = Request-URI of the original request does not indicate a resource = this
        =         =         =            = proxy is responsible for.
        =         =         =        =20
        =         =         =               A proxy can only change the = Request-URI of a request during
        =         =         =               forwarding if it is responsible = for that URI. "
        =         =         =         Since = History-Info (and associated privacy) are only added to the request, = when an entity that is allowed to change the Request-URI retargets the = request, it seemed sensible to use consistent wording to explain = that.  

        =         =         =         [/MB]
        =         =         =          [SG] I = have no problem with the statements above. My concern is that if there = is a hi-entry already embedded in the request with a Privacy statement, = then, it should be up to local policy to decide whether or not a proxy = shall pass on those hi-entries to a trusted domain. The sentence in = section 4.3.3.1.1 precludes this. I would propose to lighten the = strenght of the sentence as follows:

        =         =         =         
        =         =         =         If a request = is  being forwarded to a Request URI associated with a domain for = which the proxy is not responsible and there is a Privacy header in the = request with a priv-value of "session", "header" or = "history", the proxy MAY remove any hi-entry(s) prior to = forwarding.

        =         =         =         
        =         =         =         [SG] Another = issue is the decision to add hi-entries in a privacy context. A proxy = changing the target (i.e. the proxy is responsible of the resource = reflected in the received Request-URI) of a request which contained a = "privacy=3Dhistory" header MAY add a history-entries provided = that it knows it can rely on other entities within the trust domain to = apply the requested privacy. This affect item 4 in the list on = conditions of section 4.3.3 and 4.3.3.1.

        =         =         =         
        =         =         =         The concept = of "trust domain" should be used when discussing the = forwarding rules pertaining to information subject to privacy. = Furthermore, the requirement for forwarding history-entries to trusted = entities should be stated more clearly in the draft.

        =         =         =         =         =         =         =         [MB]: The = whole concept of what defines privacy in terms of the proxy's use of = the privacy header is outside the scope of History-Info functionality = and really a matter of local policy.   I think the = functionality that you want is a matter of local implementation and = policy in terms of operators establishing this "trust domain" = model to which you refer.  History-Info defines the mechanism to = ensure the privacy of the requests, but it doesn't explicitly define = how the proxy knows whether it is responsible for that = resource.    I don't think this is a matter of = standardization.  I thought the use of the term "domain" = rather than "resouce" would be helpful, but perhaps changing = it to the more general "resource" would resolve this concern = and/or a statement clarifying what I've just described should be added = in the draft.

        =         =         =         [/MB]
        =         =         =         [SG]   Changing the term "domain" to = "resource" does not solve the problem I mentionned above. In = order to reflect current operator requirements, the draft should not = PRECLUDE the fowarding of existing history information towards trusted = domains.

        =         =         =         
        =         =         =         Thank you for = clarifying this point.
        =         =         =         
        =         =         =         Best = regards,
        =         =         =         s=E9bastien
        =         =         =         
        =         =         =         

        =         =         =         ------Remainder of non-related part of this thread has been = deleted by Mary------------------


------_=_NextPart_001_01C4C756.9EEA5C02-- --===============1545549844== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1545549844==-- From sip-bounces@ietf.org Wed Nov 10 16:44:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08150 for ; Wed, 10 Nov 2004 16:44:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS0HZ-0008JF-HZ for sip-web-archive@ietf.org; Wed, 10 Nov 2004 16:45:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS09W-0004Mz-Lh; Wed, 10 Nov 2004 16:37:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRzxB-00070z-Gf for sip@megatron.ietf.org; Wed, 10 Nov 2004 16:24:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05931 for ; Wed, 10 Nov 2004 16:24:31 -0500 (EST) Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRzyD-0007rU-Df for sip@ietf.org; Wed, 10 Nov 2004 16:25:37 -0500 Received: from dfnjgl21 (unknown[130.129.135.144]) by comcast.net (rwcrmhc12) with SMTP id <2004111021235501400put39e> (Authid: sdawkins@comcast.net); Wed, 10 Nov 2004 21:23:56 +0000 Message-ID: <062c01c4c76b$b4043820$90878182@DFNJGL21> From: "Spencer Dawkins" To: References: <00b001c4c658$4e32f2c0$5757430a@BPenfield2> Subject: Re: [Sip] PING/PONG Date: Wed, 10 Nov 2004 16:24:42 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Spencer Dawkins List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Call me old-fashioned, but I'm requesting a point of clarification about PING/PONG. As I should have said in the working group session when we discussed this, I have no interest in chatting about UDP versus TCP. If you choose UDP, I assume you did it for a reason, and the discussion at the working group session makes sense to me. Having said that, > With UDP, the PING will create a new NAT binding and the server can > update > its mapping for the UA. > > With TCP, if you want to be able to detect that the NAT binding is > gone on > the order of a transaction timeout, you would need to send a PING > every 32 > seconds or so. Given that NAT bindings for TCP live longer than > that, I > don't see what the CRLF buys you. it seems to me that if you have chosen to use TCP for some reason, you need to at least consider living with TCP behavior on retries. The TCP protocol is extremely persistent, uses exponential backoff (typically to a maximum of 60-64 seconds per retry), and in most vanilla implementations will not declare a connection unusable for something like 10-15 minutes. If a path is lost, for any reason, TCP will use this behavior (the behavior that allows the Internet to survive the World Wide Web today). If you are using TCP and you don't like this behavior, and you don't get a response back when you wanted to get a response back, the application choices are: - sit on your hands and wait for the TCP connection to fail, - close the TCP connection and open another one, or - close the TCP connection, sit on your hands for some period of time, and open another one. The second choice (immediate retry) requires that you reset the TCP connection (one packet), send a SYN to open a second TCP connection (one packet), and potentially ACK an incoming SYN/ACK (one packet), and then resend your application message (could be piggybacked but most TCP stacks will use a separate packet). Immediately sending up to four new packets when you detect loss of one packet, with the possibility that the single-packet loss is due to network congestion, seems too aggressive. Sitting on your hands and letting TCP retry doesn't seem much worse than sitting on your hands and then setting up a new TCP connection. Are we assuming that network congestion is not an issue any more? Thanks for any guidance you can provide! Spencer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 10 18:07:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15384 for ; Wed, 10 Nov 2004 18:07:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS1Zg-0001fn-49 for sip-web-archive@ietf.org; Wed, 10 Nov 2004 18:08:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS1Vc-0003Fn-Et; Wed, 10 Nov 2004 18:04:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS1Us-0002qY-QO for sip@megatron.ietf.org; Wed, 10 Nov 2004 18:03:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14917 for ; Wed, 10 Nov 2004 18:03:23 -0500 (EST) Received: from natnoddy.rzone.de ([81.169.145.166]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS1Vv-0001bD-BO for sip@ietf.org; Wed, 10 Nov 2004 18:04:31 -0500 Received: from snom.de (pD9516A46.dip.t-dialin.net [217.81.106.70]) by post.webmailer.de (8.13.1/8.13.1) with ESMTP id iAAN3Mj7000938; Thu, 11 Nov 2004 00:03:22 +0100 (MET) 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] PING/PONG X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 11 Nov 2004 00:07:07 +0100 Message-ID: Thread-Topic: [Sip] PING/PONG thread-index: AcTHcMo5CP2b5eryTiy5Nl/L8i5PrAABvRvg From: "Christian Stredicke" To: "Spencer Dawkins" X-Spam-Score: 0.2 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: quoted-printable Hi Spencer! You just mentioned another way of keeping TCP connections alive. Thats good!=20 So far we have: - CRLF (frequenly used today, but not indicated by user agent) - STUN (same as CRLF) - PING/PONG or whatever (tbd, maybe superflous) - OPTIONS (big overhead, but compatible) - REGISTER (same as OPTIONS, but even bigger overhead) - TCP low-level (how can this be addressed by the application?) - No refreshing ("legacy device") Lets have a way to indicate these options and let the SBC decide what method it likes/supports. CS > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Spencer Dawkins > Sent: Wednesday, November 10, 2004 5:01 PM > To: sip@ietf.org > Subject: Re: [Sip] PING/PONG >=20 > Call me old-fashioned, but I'm requesting a point of clarification=20 > about PING/PONG. >=20 > As I should have said in the working group session when we discussed=20 > this, I have no interest in chatting about UDP versus TCP. If you=20 > choose UDP, I assume you did it for a reason, and the discussion at=20 > the working group session makes sense to me. >=20 > Having said that, >=20 > > With UDP, the PING will create a new NAT binding and the server can=20 > > update > > its mapping for the UA. > > > > With TCP, if you want to be able to detect that the NAT binding is=20 > > gone on > > the order of a transaction timeout, you would need to send a PING=20 > > every 32 > > seconds or so. Given that NAT bindings for TCP live longer than=20 > > that, I > > don't see what the CRLF buys you. >=20 > it seems to me that if you have chosen to use TCP for some=20 > reason, you=20 > need to at least consider living with TCP behavior on retries. >=20 > The TCP protocol is extremely persistent, uses exponential backoff=20 > (typically to a maximum of 60-64 seconds per retry), and in most=20 > vanilla implementations will not declare a connection unusable for=20 > something like 10-15 minutes. >=20 > If a path is lost, for any reason, TCP will use this behavior (the=20 > behavior that allows the Internet to survive the World Wide Web=20 > today). >=20 > If you are using TCP and you don't like this behavior, and you don't=20 > get a response back when you wanted to get a response back, the=20 > application choices are: >=20 > - sit on your hands and wait for the TCP connection to fail, >=20 > - close the TCP connection and open another one, or >=20 > - close the TCP connection, sit on your hands for some period=20 > of time,=20 > and open another one. >=20 > The second choice (immediate retry) requires that you reset the TCP=20 > connection (one packet), send a SYN to open a second TCP connection=20 > (one packet), and potentially ACK an incoming SYN/ACK (one packet),=20 > and then resend your application message (could be piggybacked but=20 > most TCP stacks will use a separate packet). >=20 > Immediately sending up to four new packets when you detect=20 > loss of one=20 > packet, with the possibility that the single-packet loss is due to=20 > network congestion, seems too aggressive. >=20 > Sitting on your hands and letting TCP retry doesn't seem much worse=20 > than sitting on your hands and then setting up a new TCP connection. >=20 > Are we assuming that network congestion is not an issue any more? >=20 > Thanks for any guidance you can provide! >=20 > Spencer=20 >=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 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 11 01:49:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22120 for ; Thu, 11 Nov 2004 01:49:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS8nQ-00028Z-HJ for sip-web-archive@ietf.org; Thu, 11 Nov 2004 01:51:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS8ii-0004rM-0H; Thu, 11 Nov 2004 01:46:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS8i7-0004jU-Jg for sip@megatron.ietf.org; Thu, 11 Nov 2004 01:45:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21910 for ; Thu, 11 Nov 2004 01:45:34 -0500 (EST) Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS8jD-00024W-Rj for sip@ietf.org; Thu, 11 Nov 2004 01:46:44 -0500 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iAB6hgEr022606 for ; Thu, 11 Nov 2004 01:43:42 -0500 (EST) Received: from nj7001avexu1.global.avaya.com (h135-11-150-101.avaya.com [135.11.150.101]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iAB6hfEr022580 for ; Thu, 11 Nov 2004 01:43:41 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 11 Nov 2004 01:45:31 -0500 Message-ID: Thread-Topic: Identity Update Thread-Index: AcTHugi213TxC2u2R2m3k2zOs+IWAw== From: "Mataga, Peter Andrew \(Peter\)" To: X-Spam-Score: 0.8 (/) X-Scan-Signature: 7d38eb86565b1a4d8c3dba35af39014d Subject: [Sip] Identity Update X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0442375853==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: f251f249fc9a04067ce354aa0943ab98 This is a multi-part message in MIME format. --===============0442375853== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C7BA.09905E00" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4C7BA.09905E00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There has been a lot of discussion in the past on the method of indicating a change of identity to a UA, as an explicit user action at the remote UA, because of transfer within a legacy network or by 3PCC in a B2BUA, or even because of aliasing, forwarding or redirection+recursion within a target domain when there is no mechanism to indicate identity in a response. At San Diego the topic was revisited with 3 options on the table: 1) Use of INVITE/Replaces as a kind of self-transfer 2) Changing the From header during a dialog 3) Inventing a new header Based on the arguments put forward during that session, there was a hum in favor of INVITE/Replaces as the only mechanism supported.=20 =20 On reflection, I don't think all the issues were aired at the time or in the small amount of subsequent list discussion. The INVITE/Replaces mechanism certainly has some appealing similarities to other scenarios (particularly the pure SIP transfer case, of course). I don't know that these are compelling when the application is to update information about a single session, and it seems to me there are going to be cases where it is not the most efficient or convenient way of doing so. Some specific issues: =20 1) How does the SDP in the INVITE/Replaces relate to the media session for the original dialog? There are more possibilities than normal because the new dialog has the same participants as the old: a) Same SDP session ID and version b) Same SDP session ID, new version c) New SDP session I personally would find a) and b) a bit odd because they mean that the media session migrates from one SIP dialog to another. Not mentioned in the Replaces spec as far as I can see, though not ruled out either, I suppose. I'm not sure what everyone involved in the discussions had in mind (or what implementations might do in cases a) and b) ...). =20 2) I seem to recall claims that INVITE/Replaces would not introduce significant loss of efficiency compared with UPDATE (or re-INVITE). If case c) is the only reasonable one above, this may not be so, since QoS and media encryption negotiation could be necessary. (It might even be the case that the new request fails call admission, even though the intent is to reuse the resources already allocated to the original call, because the entity making the decision does not know this is a replacement.) An in-dialog update mechanism might be able to avoid this. Indeed, with John Elwell's proposed amendments to the relevant RFCs, there might be no mention of media session parameters at all. I think this more lightweight procedure should at least be possible. =20 3) INVITE/Replaces does not necessarily pass through the same intermediaries as the original dialog. While this has to be dealt with in other scenarios (and some in the WG appear to regard this as a Good Thing), applications that like to "misuse" dialog stickiness will surely find it at least convenient to be in the path of the post-identity-change session. Presumably the answer to this is for such an application to be a B2BUA that provides GRUU+crypto-grid Contacts such that an INV/R from either side will pass through the application - but such a B2BUA is not transparent to the mechanism proposed in draft-ietf-sip-identity. =20 4) The hum preference for INVITE/Replaces seemed in large part to be motivated by difficulties with the From header. Since there may be other state information that will need updating in the future, it would be a bad idea if the adoption of INVITE/Replaces for updating From were to be taken as a precedent for any other state update, which would not be bound by this restriction. A consistent and efficient way of updating state information is required, and INVITE/Replaces doesn't meet the efficiency criterion. The second hum choice was to introduce another header. This would work, at the cost of a certain amount of redundancy with From. In particular, draft-ietf-sip-identity would need enhancing to allow authentication of the new header as well as (or instead of) the >From header. =20 5) All of which leads back to the least-favorite hum choice, which I feel is the best - to allow From to change. The motivation in 3261 for keeping the From URI immutable was (temporary) 2543-compatibility, and there is pretty clear language about not depending on that feature. I question whether there are 2543-only endpoints out there that are capable of deployment in realistic environments (that require SIPS and GRUU support for INVITE/Replaces authorization, for example). As pointed out in San Diego, the worst that would happen would be that a 2543-compliant UA would reject the re-INVITE or UPDATE with a 481. If the intent is at some point to follow through on the threat in 3261 to allow From to be changed, why not do it now, and allow Identity to be used for update within a dialog? =20 Peter. =20 Peter Mataga Converged Systems Division Avaya, Inc. =20 =20 ------_=_NextPart_001_01C4C7BA.09905E00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There has been a = lot of discussion in the past on the method of indicating a change of identity = to a UA, as an explicit user action at the remote UA, because of transfer = within a legacy network or by 3PCC in a B2BUA, or even because of aliasing, = forwarding or redirection+recursion within a target domain when there is no = mechanism to indicate identity in a response. At San Diego the topic was revisited with 3 options on = the table:

      1) Use of INVITE/Replaces as a kind of = self-transfer

      2) Changing the From header during a dialog

      3) Inventing a new header

Based on the = arguments put forward during that session, there was a hum in favor of INVITE/Replaces = as the only mechanism supported.

 

On reflection, I = don't think all the issues were aired at the time or in the small amount of = subsequent list discussion. The INVITE/Replaces mechanism certainly has some appealing similarities to other scenarios (particularly the pure SIP transfer = case, of course). I don’t know that these are compelling when the = application is to update information about a single session, and it seems to me there = are going to be cases where it is not the most efficient or convenient way = of doing so. Some specific issues:

 

1) How does the SDP = in the INVITE/Replaces relate to the media session for the original dialog? = There are more possibilities than normal because the new dialog has the same = participants as the old:

      a) Same SDP session ID and version

      b) Same SDP session ID, new version

      c) New SDP session

I personally would = find a) and b) a bit odd because they mean that the media session migrates from = one SIP dialog to another. Not mentioned in the Replaces spec as far as I can = see, though not ruled out either, I suppose. I'm not sure what everyone = involved in the discussions had in mind (or what implementations might do in cases = a) and b) ...).

 

2) I seem to recall = claims that INVITE/Replaces would not introduce significant loss of efficiency compared with UPDATE (or re-INVITE). If case c) is the only reasonable = one above, this may not be so, since QoS and media encryption negotiation = could be necessary. (It might even be the case that the new request fails call admission, even though the intent is to reuse the resources already = allocated to the original call, because the entity making the decision does not = know this is a replacement.) An in-dialog update mechanism might be able to avoid = this. Indeed, with John Elwell's proposed amendments to the relevant RFCs, = there might be no mention of media session parameters at all. I think this = more lightweight procedure should at least be = possible.

 

3) INVITE/Replaces = does not necessarily pass through the same intermediaries as the original dialog. = While this has to be dealt with in other scenarios (and some in the WG appear = to regard this as a Good Thing), applications that like to = “misuse” dialog stickiness will surely find it at least convenient to be in the = path of the post-identity-change session. Presumably the answer to this is for = such an application to be a B2BUA that provides GRUU+crypto-grid Contacts such = that an INV/R from either side will pass through the application – but = such a B2BUA is not transparent to the mechanism proposed in = draft-ietf-sip-identity.

 

4) The hum = preference for INVITE/Replaces seemed in large part to be motivated by difficulties = with the >From header. Since there may be other state information that will need = updating in the future, it would be a bad idea if the adoption of INVITE/Replaces = for updating From were to be taken as a precedent for any other state = update, which would not be bound by this restriction. A consistent and efficient way = of updating state information is required, and INVITE/Replaces doesn't meet = the efficiency criterion. The second hum choice was to introduce another = header. This would work, at the cost of a certain amount of redundancy with From. In particular, draft-ietf-sip-identity would need enhancing to allow authentication of the new header as well as (or instead of) the From = header.

 

5) All of which = leads back to the least-favorite hum choice, which I feel is the best – to = allow >From to change. The motivation in 3261 for keeping the From URI = immutable was (temporary) 2543-compatibility, and there is pretty clear language about = not depending on that feature. I question whether there are 2543-only endpoints out = there that are capable of deployment in realistic environments (that require = SIPS and GRUU support for INVITE/Replaces authorization, for example). As pointed = out in San = Diego, the worst that would happen would be that a 2543-compliant UA would reject = the re-INVITE or UPDATE with a 481. If the intent is at some point to follow through on the threat in 3261 to allow From to be changed, why not do it = now, and allow Identity to be used for update within a = dialog?

 

Peter.

 

Peter = Mataga

Converged Systems = Division

Avaya, = Inc.

 

 

------_=_NextPart_001_01C4C7BA.09905E00-- --===============0442375853== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0442375853==-- From sip-bounces@ietf.org Thu Nov 11 04:10:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15814 for ; Thu, 11 Nov 2004 04:10:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSAzC-0004i5-P5 for sip-web-archive@ietf.org; Thu, 11 Nov 2004 04:11:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSAuT-0006CD-WB; Thu, 11 Nov 2004 04:06:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSAqm-0005ra-UA for sip@megatron.ietf.org; Thu, 11 Nov 2004 04:02:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15247 for ; Thu, 11 Nov 2004 04:02:39 -0500 (EST) Received: from [62.119.82.41] (helo=mailserver.hotsip.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSAru-0004Yh-VP for sip@ietf.org; Thu, 11 Nov 2004 04:03:51 -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: [Sip] PING/PONG [bcc][faked-from][heur] Date: Thu, 11 Nov 2004 09:59:11 +0100 Message-ID: Thread-Topic: [Sip] PING/PONG [bcc][faked-from][heur] Thread-Index: AcTHcMo5CP2b5eryTiy5Nl/L8i5PrAABvRvgABRo7WA= From: "Christian Jansson" To: "Christian Stredicke" , "Spencer Dawkins" X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable >Lets have a way to indicate these options and let the SBC decide what >method it likes/supports. So, this discussion is about how to make UAs interop with SBCs? That was new to me. As SBC are not even well defined does it make sense to try to make UAs interop with them? Don't get me wrong, I do think it is very good to get a standardized way of handling the keep-alive problem, but putting a SBC as the focus of the requirements before it is well defined seems strange. >You just mentioned another way of keeping TCP connections alive. Thats >good!=20 > So far we have: >- CRLF (frequenly used today, but not indicated by user agent) My gut feeling was that could be done without any indication/negotiation, but now I understand why you want this feature, you have a SBC in mind. If that had been written somewhere in this thread, at least I would have understood your motivation. >- STUN (same as CRLF) Just checking, STUN over TCP? >- PING/PONG or whatever (tbd, maybe superflous) >- OPTIONS (big overhead, but compatible) >- REGISTER (same as OPTIONS, but even bigger overhead) >- TCP low-level (how can this be addressed by the application?) >- No refreshing ("legacy device") REGISTER without a contact header, would that make it light enough? Bad to overload REGISTER? Backwards compatible? Perhaps the response would still need to include all registered contacts for the AOR, so the registrar still has to access the DB. My opinion is that none of the OPTIONS, REGISTER, TCP low-level fiddling, no refreshing at all, is the right method for solving the problem, exactly because of the problems you stated with each method. / Christian Jansson =20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 11 05:51:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24370 for ; Thu, 11 Nov 2004 05:51:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSCYr-0006nO-Ql for sip-web-archive@ietf.org; Thu, 11 Nov 2004 05:52:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSCVb-0003G6-D9; Thu, 11 Nov 2004 05:48:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSCUp-00038U-58 for sip@megatron.ietf.org; Thu, 11 Nov 2004 05:48:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24205 for ; Thu, 11 Nov 2004 05:48:05 -0500 (EST) Received: from natsmtp00.rzone.de ([81.169.145.165]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSCVx-0006kC-VL for sip@ietf.org; Thu, 11 Nov 2004 05:49:18 -0500 Received: from snom.de (pD9516905.dip.t-dialin.net [217.81.105.5]) by post.webmailer.de (8.13.1/8.13.1) with ESMTP id iABAltkw009694; Thu, 11 Nov 2004 11:47:56 +0100 (MET) 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] PING/PONG [bcc][faked-from][heur] X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 11 Nov 2004 11:47:52 +0100 Message-ID: Thread-Topic: [Sip] PING/PONG [bcc][faked-from][heur] thread-index: AcTHcMo5CP2b5eryTiy5Nl/L8i5PrAABvRvgABRo7WAABIYsQA== From: "Christian Stredicke" To: "Christian Jansson" , "Spencer Dawkins" X-Spam-Score: 0.2 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Christian Jansson > Sent: Thursday, November 11, 2004 4:32 AM > To: Christian Stredicke; Spencer Dawkins > Cc: sip@ietf.org > Subject: RE: [Sip] PING/PONG [bcc][faked-from][heur] >=20 >=20 > >Lets have a way to indicate these options and let the SBC decide what > >method it likes/supports. >=20 > So, this discussion is about how to make UAs interop with=20 > SBCs? That was > new to me. As SBC are not even well defined does it make=20 > sense to try to > make UAs interop with them? Don't get me wrong, I do think it is very > good to get a standardized way of handling the keep-alive problem, but > putting a SBC as the focus of the requirements before it is=20 > well defined > seems strange. Lets say a SBC is an example. I dont want to be pulled into the SBC discussion. >=20 > >You just mentioned another way of keeping TCP connections=20 > alive. Thats > >good!=20 > > So far we have: >=20 > >- CRLF (frequenly used today, but not indicated by user agent) >=20 > My gut feeling was that could be done without any > indication/negotiation, but now I understand why you want=20 > this feature, > you have a SBC in mind. If that had been written somewhere in this > thread, at least I would have understood your motivation. Well the [refreshing device] needs to know if it has to do something or not (eg. send OPTIONS periodically). This needs to be indicated. Looking at the User-Agent header is surely not a good way... >=20 > >- STUN (same as CRLF) >=20 > Just checking, STUN over TCP? Why not? >=20 > >- PING/PONG or whatever (tbd, maybe superflous) > >- OPTIONS (big overhead, but compatible) > >- REGISTER (same as OPTIONS, but even bigger overhead) > >- TCP low-level (how can this be addressed by the application?) > >- No refreshing ("legacy device") >=20 > REGISTER without a contact header, would that make it light=20 > enough? Bad > to overload REGISTER? Backwards compatible? Perhaps the response would > still need to include all registered contacts for the AOR, so the > registrar still has to access the DB. >=20 > My opinion is that none of the OPTIONS, REGISTER, TCP low-level > fiddling, no refreshing at all, is the right method for solving the > problem, exactly because of the problems you stated with each method. STUN sounds like a very good method to me... >=20 > / Christian Jansson >=20 > =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 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 11 11:14:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26936 for ; Thu, 11 Nov 2004 11:14:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSHbt-0005pg-9Y for sip-web-archive@ietf.org; Thu, 11 Nov 2004 11:15:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSHVo-0007T4-Sy; Thu, 11 Nov 2004 11:09:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSHPA-0006CT-AL for sip@megatron.ietf.org; Thu, 11 Nov 2004 11:02:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25902 for ; Thu, 11 Nov 2004 11:02:34 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSHQK-0005ZD-9W for sip@ietf.org; Thu, 11 Nov 2004 11:03:50 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 11 Nov 2004 08:16:08 -0800 X-BrightmailFiltered: true Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iABG1wom012857; Thu, 11 Nov 2004 08:01:58 -0800 (PST) Received: from [130.129.135.140] (sjc-vpn4-736.cisco.com [10.21.82.224]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFR25164; Thu, 11 Nov 2004 08:01:59 -0800 (PST) Message-ID: <41938CF6.60008@cisco.com> Date: Thu, 11 Nov 2004 11:01:58 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach Subject: Re: [Sip] Event Lists: Back-End Credentials References: <5816828233DEFA41807A6CFDFDF2343C3A8BD7@esebe056.ntc.nokia.com> <418101FF.9030506@nostrum.com> In-Reply-To: <418101FF.9030506@nostrum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Its worth noting that this issue has come up in the context of 3gpp, where it is actually even harder of a problem than it is here. I suggest folks read section 12.1 of RFC 3725. Basically, what is says is that delegation is a hard problem, we don't have a solution for it. So, in the interim, the 3pcc controller set the From in a specific way in order to be usable in applications which (perhaps sadly) don't authenticate. And that's it. I'm not sure if precedent of past acceptability of this kind of statement can help us, but at least there is a precedent. -Jonathan R. Adam Roach wrote: > hisham.khartabil@nokia.com wrote: > >> >>> A consequence of this is that, lacking any other mechanism, the >>> resources in a resource list for which the RLS is not authoritative >>> will contain only the information that their notifier is willing to >>> reveal to the RLS -- which is generally the same information they >>> would render to unauthenticated users. In some cases, this might >>> result in no useful information being transferred. >>> >> >> >> This limitation by itself kills the idea, IMO. Most presence lists >> will rely on the event list, and if its gonna mean that no useful >> information will come to the watcher, then the whole mecahnism is >> useless. >> >> > > That's a bit of a strong characterization, and it seems to ignore the > remainder of the mail that I sent out; specifically: > > 1. Users have the ability to subscribe to any resources that the RLS > marks itself as non-authoritative, and > 2. (More Importantly) Provisions for delegation of authority are > included -- they're just not in-scope for this document. > > /a > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 11 11:53:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00936 for ; Thu, 11 Nov 2004 11:53:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSIDX-0006ru-3b for sip-web-archive@ietf.org; Thu, 11 Nov 2004 11:54:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSI7H-0007VB-Mz; Thu, 11 Nov 2004 11:48:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSI0W-000684-IR for sip@megatron.ietf.org; Thu, 11 Nov 2004 11:41:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29418 for ; Thu, 11 Nov 2004 11:41:10 -0500 (EST) Received: from [62.119.82.41] (helo=mailserver.hotsip.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSI1V-0006Ss-Qz for sip@ietf.org; Thu, 11 Nov 2004 11:42:27 -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: [Sip] PING/PONG [bcc][faked-from][heur] [mx][spf] Date: Thu, 11 Nov 2004 17:40:23 +0100 Message-ID: Thread-Topic: [Sip] PING/PONG [bcc][faked-from][heur] [mx][spf] Thread-Index: AcTHcMo5CP2b5eryTiy5Nl/L8i5PrAABvRvgABRo7WAABIYsQAAHn+PQ From: "Christian Jansson" To: "Christian Stredicke" , "Spencer Dawkins" X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable Let's step back and look at the requirements.=20 We have a problem that UAs are placed behind NATs and FWs. Those NATs and FWs give us two big problems: Problem1. Machines from the outside cannot easily connect/communicate with the UAs on the inside, at least not without initiative from the UAs on the inside. Problem2. Even though the UAs on the inside open up for communication through the NAT/FW, the NAT/FW doesn't keep the state for as long as we would wish. This gives us two requirements: Req1. Open up for two way communication through the NAT/FW Req2. Ensure req1 for as long as it is needed for the UA on the inside. There are also some facts: Fact1. In almost all normal situations it will only be the UA that can open up the NAT/FW for two way communication. Fact2. It is the UA that knows for how long the two way communication through the NAT/FW is needed. Fact3. It is generally good to put less work on servers and let the UAs do as much of the work as possible.=20 >From fact1 I draw the conclusion that the UA must open up the two way communication because it will be the only reliable solution. Fact2 and fact3 together with the conclusion that the UA must fulfill fact1 gives me a strong feeling that the UA should be the only one that should do the job of fulfilling the requirements. I understand that there could be other solutions where machines on the outer side of the NAT/FW could partly fulfill req2, that is, they could try to keep the communication path open. But such a machine cannot be sure exactly when to stop, and, this is the big one, it can't do anything if it detects that the communication path fails ... nothing! If the UA on the other hand fulfilled req2 and detected a problem, it could open up a new communication path and everything would start working again. I do not think we should fool UA implementers into thinking that they can solve the NAT/FW problem by negotiating with another device on the outside of the NAT/FW. I think it is better to write down how to open, use, and maintain a two way SIP signaling path through NATs and FWs. My suggested solution: Follow what's in draft-jennings-sipping-outbound-00: - Keep-alives should be sent by the UA. - Keep-alives for TCP should be CRLF (default-interval TBD).=20 - Keep-alives for UDP could be the SIP methods REGISTER, or a new light-weight SIP PING method, to be able to get the rport and received from the response, or STUN. Frequent REGISTERs seems to heavy-weight for the servers. That leaves us with PING or STUN. PING advantage, it is SIP, disadvantage, it is new. STUN advantage, have been around for a while, disadvantage, it is not SIP. / 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 sip-bounces@ietf.org Thu Nov 11 12:09:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02680 for ; Thu, 11 Nov 2004 12:09:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSISr-0007JP-JV for sip-web-archive@ietf.org; Thu, 11 Nov 2004 12:10:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSIGl-0001Vh-3A; Thu, 11 Nov 2004 11:57:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSIBl-0000Ed-Ry for sip@megatron.ietf.org; Thu, 11 Nov 2004 11:52:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00874 for ; Thu, 11 Nov 2004 11:52:47 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSICx-0006q7-Py for sip@ietf.org; Thu, 11 Nov 2004 11:54:04 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 11 Nov 2004 08:52:17 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Thu, 11 Nov 2004 08:52:17 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C4C80E.CDA3C5ED" Date: Thu, 11 Nov 2004 08:52:22 -0800 Message-ID: X-MS-Has-Attach: yes Thread-Topic: draft-ietf-sip-refer-with-norefersub-00.txt and draft-ietf-sip-refer-with-feature-param-00 Thread-Index: AcTIDtBlSX21/uW3SMih61RiWJ8s9Q== X-Priority: 1 Priority: Urgent Importance: high From: "Orit Levin" To: X-OriginalArrivalTime: 11 Nov 2004 16:52:17.0443 (UTC) FILETIME=[CD678F30:01C4C80E] X-Spam-Score: 2.7 (++) X-Scan-Signature: 10e6cb90de4fe268e7150fb24857273b Subject: [Sip] draft-ietf-sip-refer-with-norefersub-00.txt and draft-ietf-sip-refer-with-feature-param-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 2.7 (++) X-Scan-Signature: d67762704726a1bed57e7f4595960d34 This is a multi-part message in MIME format. ------_=_NextPart_001_01C4C80E.CDA3C5ED Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C4C80E.CDA3C5ED" ------_=_NextPart_002_01C4C80E.CDA3C5ED Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Guys, The attached drafts, submitted on time, haven't made their way to the IETF repository. Please, take a look at them before the meeting today. There have been no changes since the previous version draft-olson-sipping-refer-extensions-02 rather than splitting the draft into two and submitting them as SIP WG items. =20 Thanks a lot, Orit. ------_=_NextPart_002_01C4C80E.CDA3C5ED Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Guys,

The attached drafts, submitted on time, haven’t = made their way to the IETF repository. Please, take a look at them before the meeting today. There have been no changes since the previous version = draft-olson-sipping-refer-extensions-02 rather than splitting the draft into two and submitting them as SIP WG = items.

 

Thanks a lot,

Orit.

------_=_NextPart_002_01C4C80E.CDA3C5ED-- ------_=_NextPart_001_01C4C80E.CDA3C5ED Content-Type: text/plain; name="draft-ietf-sip-refer-with-norefersub-00.txt" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-sip-refer-with-norefersub-00.txt Content-Disposition: attachment; filename="draft-ietf-sip-refer-with-norefersub-00.txt" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 DQoNCg0KU0lQICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIE8uIExldmluDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBNaWNyb3NvZnQgQ29ycG9yYXRpb24NCkV4cGlyZXM6IEFwcmlsIDE3 LCAyMDA1ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgT2N0b2JlciAxNywgMjAwNA0K DQoNCiAgICAgICAgICAgICAgIFN1cHByZXNzaW9uIG9mIFJFRkVSIEltcGxpY2l0IFN1YnNjcmlw dGlvbg0KICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtc2lwLXJlZmVyLXdpdGgtbm9yZWZlcnN1 Yi0wMA0KDQpTdGF0dXMgb2YgdGhpcyBNZW1vDQoNCiAgIFRoaXMgZG9jdW1lbnQgaXMgYW4gSW50 ZXJuZXQtRHJhZnQgYW5kIGlzIHN1YmplY3QgdG8gYWxsIHByb3Zpc2lvbnMNCiAgIG9mIHNlY3Rp b24gMyBvZiBSRkMgMzY2Ny4gIEJ5IHN1Ym1pdHRpbmcgdGhpcyBJbnRlcm5ldC1EcmFmdCwgZWFj aA0KICAgYXV0aG9yIHJlcHJlc2VudHMgdGhhdCBhbnkgYXBwbGljYWJsZSBwYXRlbnQgb3Igb3Ro ZXIgSVBSIGNsYWltcyBvZg0KICAgd2hpY2ggaGUgb3Igc2hlIGlzIGF3YXJlIGhhdmUgYmVlbiBv ciB3aWxsIGJlIGRpc2Nsb3NlZCwgYW5kIGFueSBvZg0KICAgd2hpY2ggaGUgb3Igc2hlIGJlY29t ZSBhd2FyZSB3aWxsIGJlIGRpc2Nsb3NlZCwgaW4gYWNjb3JkYW5jZSB3aXRoDQogICBSRkMgMzY2 OC4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50 ZXJuZXQgRW5naW5lZXJpbmcNCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBp dHMgd29ya2luZyBncm91cHMuICBOb3RlIHRoYXQNCiAgIG90aGVyIGdyb3VwcyBtYXkgYWxzbyBk aXN0cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFzDQogICBJbnRlcm5ldC1EcmFmdHMuDQoNCiAg IEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0g b2Ygc2l4IG1vbnRocw0KICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xl dGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkNCiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJp YXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlDQogICBtYXRlcmlhbCBvciB0 byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iDQoNCiAgIFRoZSBs aXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0 cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0Lg0KDQogICBUaGUgbGlzdCBv ZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vzc2VkIGF0DQog ICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sLg0KDQogICBUaGlzIEludGVybmV0LURy YWZ0IHdpbGwgZXhwaXJlIG9uIEFwcmlsIDE3LCAyMDA1Lg0KDQpDb3B5cmlnaHQgTm90aWNlDQoN CiAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKDIwMDQpLg0KDQpBYnN0cmFj dA0KDQogICBUaGlzIHNwZWNpZmljYXRpb24gZGVmaW5lcyB0aGUgd2F5IHRvIHN1cHByZXNzIGFu IGltcGxpY2l0DQogICBzdWJzY3JpcHRpb24gd2l0aCBSRUZFUiBtZXRob2QgaW4gU0lQLg0KDQoN Cg0KDQoNCg0KDQoNCg0KTGV2aW4gICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXByaWwgMTcs IDIwMDUgICAgICAgICAgICAgICAgIFtQYWdlIDFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgUkVGRVIgd2l0aCBub3JlZmVyc3ViICAgICAgICAgICAgICBPY3RvYmVyIDIwMDQNCg0KDQpU YWJsZSBvZiBDb250ZW50cw0KDQogICAxLiAgIFRlcm1pbm9sb2d5ICAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDMNCiAgIDIuICAgSW50cm9kdWN0aW9u IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNA0KICAg My4gICBNb3RpdmF0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gICA1DQogICA0LiAgIERlZmluaXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDYNCiAgIDUuICAgUHJldmVudGluZyBGb3JraW5n IG9mIFJFRkVSIFJlcXVlc3RzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNw0KICAgNi4gICBF eGFtcGxlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gICA4DQogICA3LiAgIElBTkEgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgIDkNCiAgIDguICAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMA0KICAgOS4gICBBY2tub3ds ZWRnZW1lbnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEx DQogICAxMC4gIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgMTINCiAgIDEwLjEgICBOb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMg0KICAgMTAuMiAgIEluZm9ybWF0aW9u YWwgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEyDQogICAg ICAgIEF1dGhvcidzIEFkZHJlc3MgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgMTINCiAgICAgICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IGFuZCBDb3B5cmlnaHQg U3RhdGVtZW50cyAuIC4gLiAuIC4gLiAuICAxMw0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkxldmluICAgICAgICAg ICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDE3LCAyMDA1ICAgICAgICAgICAgICAgICBbUGFnZSAy XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgIFJFRkVSIHdpdGggbm9yZWZlcnN1YiAgICAg ICAgICAgICAgT2N0b2JlciAyMDA0DQoNCg0KMS4gIFRlcm1pbm9sb2d5DQoNCiAgIFRoZSBrZXkg d29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9U IiwNCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICAiTUFZIiwgYW5k ICJPUFRJT05BTCIgaW4gdGhpcw0KICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFz IGRlc2NyaWJlZCBpbiBSRkMgMjExOSBbMV0uDQoNCiAgIFRvIHNpbXBsaWZ5IGRpc2N1c3Npb25z IG9mIHRoZSBSRUZFUiBtZXRob2QgYW5kIGl0cyBleHRlbnNpb25zLCB0aHJlZQ0KICAgbmV3IHRl cm1zIGFyZSBiZWluZyB1c2VkIHRocm91Z2hvdXQgdGhlIGRvY3VtZW50Og0KICAgbyAgUkVGRVIt SXNzdWVyOiB0aGUgVUEgaXNzdWluZyB0aGUgUkVGRVIgcmVxdWVzdA0KICAgbyAgUkVGRVItUmVj aXBpZW50OiB0aGUgVUEgcmVjZWl2aW5nIHRoZSBSRUZFUiByZXF1ZXN0DQogICBvICBSRUZFUi1U YXJnZXQ6IHRoZSBVQSBkZXNpZ25hdGVkIGluIHRoZSBSZWZlci1UbyBVUkkNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KTGV2aW4gICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXByaWwgMTcsIDIw MDUgICAgICAgICAgICAgICAgIFtQYWdlIDNdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg UkVGRVIgd2l0aCBub3JlZmVyc3ViICAgICAgICAgICAgICBPY3RvYmVyIDIwMDQNCg0KDQoyLiAg SW50cm9kdWN0aW9uDQoNCiAgIFRoZSBSRUZFUiBzcGVjaWZpY2F0aW9uIHNwZWNpZmllcyB0aGF0 IGV2ZXJ5IFJFRkVSIGNyZWF0ZXMgYW4NCiAgIGltcGxpY2l0IHN1YnNjcmlwdGlvbiBiZXR3ZWVu IHRoZSBSRUZFUi1Jc3N1ZXIgYW5kIHRoZQ0KICAgUkVGRVItUmVjaXBpZW50LiAgVGhpcyBkb2N1 bWVudCBkZWZpbmVzIGEgbmV3IG9wdGlvbiB0YWcsDQogICAibm9yZWZlcnN1YiIsIHdoaWNoIHNw ZWNpZmllcyB0aGF0IGFuIGltcGxpY2l0IHN1YnNjcmlwdGlvbiBmb3IgZXZlbnQNCiAgIHBhY2th Z2UgcmVmZXIgc2hvdWxkIG5vdCBiZSBjcmVhdGVkIGFzIGEgcmVzdWx0IG9mIGFjY2VwdGluZyB0 aGlzDQogICBSRUZFUiByZXF1ZXN0Lg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpMZXZp biAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAxNywgMjAwNSAgICAgICAgICAgICAg ICAgW1BhZ2UgNF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICBSRUZFUiB3aXRoIG5vcmVm ZXJzdWIgICAgICAgICAgICAgIE9jdG9iZXIgMjAwNA0KDQoNCjMuICBNb3RpdmF0aW9uDQoNCiAg IFRoZSBSRUZFUiBzcGVjaWZpY2F0aW9uIG1hbmRhdGVzIHRoYXQgZXZlcnkgUkVGRVIgY3JlYXRl cyBhbiBpbXBsaWNpdA0KICAgc3Vic2NyaXB0aW9uIGJldHdlZW4gdGhlIFJFRkVSLUlzc3VlciBh bmQgdGhlIFJFRkVSLVJlY2lwaWVudC4gIFRoaXMNCiAgIHN1YnNjcmlwdGlvbiByZXN1bHRzIGlu IGF0IGxlYXN0IG9uZSBOT1RJRlkgYmVpbmcgc2VudCBmcm9tIHRoZQ0KICAgUkVGRVItUmVjaXBp ZW50IHRvIHRoZSBSRUZFUi1Jc3N1ZXIuICBUaGUgUkVGRVItUmVjaXBpZW50IG1heSBjaG9vc2UN CiAgIHRvIGNhbmNlbCB0aGUgaW1wbGljaXQgc3Vic2NyaXB0aW9uIHdpdGggdGhpcyBOT1RJRlku ICBUaGUNCiAgIFJFRkVSLUlzc3VlciBtYXkgY2hvb3NlIHRvIGNhbmNlbCB0aGlzIGltcGxpY2l0 IHN1YnNjcmlwdGlvbiB3aXRoIGFuDQogICBleHBsaWNpdCBTVUJTQ1JJQkUgKEV4cGlyZXM6IDAp IGFmdGVyIHJlY2VpcHQgb2YgdGhlIGluaXRpYWwgTk9USUZZDQogICBvciBieSBzZW5kaW5nIGEg NDgxIHJlc3BvbnNlIHRvIHRoaXMgaW5pdGlhbCBOT1RJRlkgcmVxdWVzdC4NCg0KICAgT25lIHB1 cnBvc2Ugb2YgcmVxdWlyaW5nIHRoZSBpbXBsaWNpdCBzdWJzY3JpcHRpb24gYW5kIGluaXRpYWwg Tk9USUZZDQogICBpcyB0byBhbGxvdyBmb3IgdGhlIHNpdHVhdGlvbiB3aGVyZSB0aGUgUkVGRVIg cmVxdWVzdCBnZXRzIGZvcmtlZCBhbmQNCiAgIHRoZSBSRUZFUi1Jc3N1ZXIgbmVlZHMgYSB3YXkg dG8gc2VlIHRoZSBtdWx0aXBsZSBkaWFsb2dzIHRoYXQgbWF5IGJlDQogICBlc3RhYmxpc2hlZCBh cyBhIHJlc3VsdCBvZiB0aGUgZm9ya2VkIFJFRkVSLiAgVGhpcyBpcyB0aGUgc2FtZQ0KICAgYXBw cm9hY2ggdXNlZCB0byBoYW5kbGUgZm9ya2luZyBvZiBTVUJTQ1JJQkUgWzRdIHJlcXVlc3RzLiAg V2hlcmUgdGhlDQogICBSRUZFUi1Jc3N1ZXIgZXhwbGljaXRseSBzcGVjaWZpZXMgdGhhdCBmb3Jr aW5nIG5vdCBvY2N1ciwgdGhlDQogICByZXF1aXJlbWVudCB0aGF0IGFuIGltcGxpY2l0IHN1YnNj cmlwdGlvbiBiZSBlc3RhYmxpc2hlZCBpcw0KICAgdW5uZWNlc3NhcnkuDQoNCiAgIEFub3RoZXIg cHVycG9zZSBvZiB0aGUgTk9USUZZIGlzIHRvIGluZm9ybSB0aGUgUkVGRVItSXNzdWVyIG9mIHRo ZQ0KICAgcHJvZ3Jlc3Mgb2YgdGhlIFNJUCB0cmFuc2FjdGlvbiB0aGF0IHJlc3VsdHMgZnJvbSB0 aGUgUkVGRVIgYXQgdGhlDQogICBSRUZFUi1SZWNpcGllbnQuICBJbiB0aGUgY2FzZSB3aGVyZSB0 aGUgUkVGRVItSXNzdWVyIGlzIGFscmVhZHkgYXdhcmUNCiAgIG9mIHRoZSBwcm9ncmVzcyBvZiB0 aGUgcmVxdWVzdGVkIG9wZXJhdGlvbiwgc3VjaCBhcyB3aGVuIHRoZQ0KICAgUkVGRVItSXNzdWVy IGhhcyBhbiBleHBsaWNpdCBzdWJzY3JpcHRpb24gdG8gdGhlIGRpYWxvZyBldmVudCBwYWNrYWdl DQogICBhdCB0aGUgUkVGRVItUmVjaXBpZW50LCB0aGUgaW1wbGljaXQgc3Vic2NyaXB0aW9uIGFu ZCByZXN1bHRhbnQNCiAgIE5PVElGWSB0cmFmZmljIHJlbGF0ZWQgdG8gdGhlIFJFRkVSIGNhbiBj cmVhdGUgYW4gdW5uZWNlc3NhcnkgbmV0d29yaw0KICAgb3ZlcmhlYWQuDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KTGV2aW4gICAgICAgICAgICAgICAgICAg IEV4cGlyZXMgQXByaWwgMTcsIDIwMDUgICAgICAgICAgICAgICAgIFtQYWdlIDVdDQoMDQpJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgUkVGRVIgd2l0aCBub3JlZmVyc3ViICAgICAgICAgICAgICBP Y3RvYmVyIDIwMDQNCg0KDQo0LiAgRGVmaW5pdGlvbg0KDQogICBUaGlzIGRvY3VtZW50IGRlZmlu ZXMgYSBuZXcgb3B0aW9uIHRhZywgIm5vcmVmZXJzdWIiLCB3aGljaCBzcGVjaWZpZXMNCiAgIHRo YXQgYW4gaW1wbGljaXQgc3Vic2NyaXB0aW9uIGZvciBldmVudCBwYWNrYWdlIHJlZmVyIHNob3Vs ZCBub3QgYmUNCiAgIGNyZWF0ZWQgYXMgYSByZXN1bHQgb2YgYWNjZXB0aW5nIHRoaXMgUkVGRVIg cmVxdWVzdC4NCg0KICAgVGhlICJub3JlZmVyc3ViIiBvcHRpb24gdGFnIE1VU1QgYmUgdXNlZCBi eSB0aGUgUkVGRVItSXNzdWVyIG9ubHkNCiAgIHdoZW4gdGhlIFJFRkVSLUlzc3VlciBjYW4gYmUg Y2VydGFpbiB0aGF0IHRoZSBSRUZFUiByZXF1ZXN0IHdpbGwgbm90DQogICBiZSBmb3JrZWQuDQoN CiAgIFRoZSBSRUZFUi1Jc3N1ZXIgY2FuIHBsYWNlIHRoZSAibm9yZWZlcnN1YiIgb3B0aW9uIHRh ZyBlaXRoZXIgaW4gdGhlDQogICBSZXF1aXJlIGhlYWRlciBvciBpbiB0aGUgU3VwcG9ydGVkIGhl YWRlciBvZiB0aGUgUkVGRVIgcmVxdWVzdCwNCiAgIHN1YmplY3QgdG8gYXBwbGljYXRpb24gcmVx dWlyZW1lbnRzLg0KDQogICBJZiB0aGUgUkVGRVItSXNzdWVyIGluc2VydHMgdGhlIG9wdGlvbiB0 YWcgaW4gdGhlIFN1cHBvcnRlZCBoZWFkZXINCiAgIGJ1dCB0aGUgUkVGRVItUmVjaXBpZW50IGRv ZXNuJ3QgZ3JhbnQgdGhlIHN1Z2dlc3Rpb24sIGFuIGltcGxpY2l0DQogICBzdWJzY3JpcHRpb24g aXMgY3JlYXRlZCBhcyBpbiBkZWZhdWx0IGNhc2UuDQoNCiAgIElmIHRoZSBSRUZFUi1Jc3N1ZXIg aW5zZXJ0cyB0aGUgb3B0aW9uIHRhZyBpbiB0aGUgUmVxdWlyZSBoZWFkZXIgYnV0DQogICB0aGUg UkVGRVItUmVjaXBpZW50IGlzIG5vdCB3aWxsaW5nIHRvIGdyYW50IHRoZSByZXF1ZXN0LCB0aGUg UkVGRVINCiAgIHJlcXVlc3QgaXMgcmVqZWN0ZWQuDQoNCiAgIElmIHRoZSBSRUZFUi1SZWNpcGll bnQgaXMgd2lsbGluZyB0byBncmFudCB0aGUgIm5vcmVmZXJzdWIiIGJlaGF2aW9yDQogICBmb3Ig dGhlIGlzc3VlZCBSRUZFUiByZXF1ZXN0LCBpdCBNVVNUIGluc2VydCBhIFN1cHBvcnRlZDogbm9y ZWZlcnN1Yg0KICAgaGVhZGVyIGluIHRoZSAyeHggcmVzcG9uc2UgdG8gdGhlIFJFRkVSLUlzc3Vl ci4gIEluIHRoaXMgY2FzZSBubw0KICAgZGlhbG9nIGlzIGNyZWF0ZWQuDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkxldmluICAgICAgICAgICAgICAg ICAgICBFeHBpcmVzIEFwcmlsIDE3LCAyMDA1ICAgICAgICAgICAgICAgICBbUGFnZSA2XQ0KDA0K SW50ZXJuZXQtRHJhZnQgICAgICAgICAgIFJFRkVSIHdpdGggbm9yZWZlcnN1YiAgICAgICAgICAg ICAgT2N0b2JlciAyMDA0DQoNCg0KNS4gIFByZXZlbnRpbmcgRm9ya2luZyBvZiBSRUZFUiBSZXF1 ZXN0cw0KDQogICBUaGUgUkVGRVIgc3BlY2lmaWNhdGlvbiBhbGxvd3MgZm9yIHRoZSBwb3NzaWJp bGl0eSBvZiBmb3JraW5nIGEgUkVGRVINCiAgIHJlcXVlc3Qgd2hpY2ggaXMgc2VudCBvdXRzaWRl IG9mIGFuIGV4aXN0aW5nIGRpYWxvZy4gIFRoZQ0KICAgUkVGRVItSXNzdWVyIGNhbiBlbnN1cmUg dGhhdCBSRUZFUiBkb2Vzbid0IGdldCBmb3JrZWQgYnkgc2VuZGluZw0KICAgUkVGRVIgdG8gYSBS RUZFUi1SZWNpcGllbnQgd2hpY2ggaGFzIEdSVVUgcHJvcGVydGllcyBhY2NvcmRpbmcgdG8NCiAg IGRlZmluaXRpb25zIG9mIFs1XS4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpMZXZp biAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAxNywgMjAwNSAgICAgICAgICAgICAg ICAgW1BhZ2UgN10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICBSRUZFUiB3aXRoIG5vcmVm ZXJzdWIgICAgICAgICAgICAgIE9jdG9iZXIgMjAwNA0KDQoNCjYuICBFeGFtcGxlDQoNCiAgIEFu IGV4YW1wbGUgb2YgUkVGRVIgd2hpY2ggc3VwcHJlc3NlcyB0aGUgaW1wbGljaXQgc3Vic2NyaXB0 aW9uIGlzDQogICBzaG93biBiZWxvdzoNCg0KICAgUkVGRVIgc2lwOnBjLWJAdHJhZGV3aW5kLmNv bSBTSVAvMi4wDQogICBWaWE6IFNJUC8yLjAvVENQIGlzc3Vlci50cmFkZXdpbmQuY29tO2JyYW5j aD16OWhHNGJLLWEtMQ0KICAgRnJvbTogPHNpcDphQHRyYWRld2luZC5jb20+O3RhZz0xYQ0KICAg VG86IDxzaXA6cGMtYkB0cmFkZXdpbmQuY29tPg0KICAgQ2FsbC1JRDogMUBpc3N1ZXIudHJhZGV3 aW5kLmNvbQ0KICAgQ1NlcTogMjM0MjM0IFJFRkVSDQogICBNYXgtRm9yd2FyZHM6IDcwDQogICBS ZWZlci1UbzogPHNpcDpjQHRyYWRld2luZC5jb207bWV0aG9kPUlOVklURT4NCiAgIFJlcXVpcmU6 IG5vcmVmZXJzdWINCiAgIEFjY2VwdC1Db250YWN0OiAqO2F1ZGlvO3JlcXVpcmUNCiAgIENvbnRh Y3Q6IHNpcDphQGlzc3Vlci50cmFkZXdpbmQuY29tDQogICBDb250ZW50LVR5cGU6IG1lc3NhZ2Uv c2lwZnJhZw0KICAgQ29udGVudC1JZDogPDEyMzkxMDM5MTIwMzlAaXNzdWVyLnRyYWRld2luZC5j b20+DQogICBDb250ZW50LUxlbmd0aDogLi4uDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KTGV2aW4gICAgICAgICAgICAgICAg ICAgIEV4cGlyZXMgQXByaWwgMTcsIDIwMDUgICAgICAgICAgICAgICAgIFtQYWdlIDhdDQoMDQpJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgUkVGRVIgd2l0aCBub3JlZmVyc3ViICAgICAgICAgICAg ICBPY3RvYmVyIDIwMDQNCg0KDQo3LiAgSUFOQSBDb25zaWRlcmF0aW9ucw0KDQogICBUaGlzIGRv Y3VtZW50IGRlZmluZXMgYSBuZXcgb3B0aW9uIHRhZywgIm5vcmVmZXJzdWIiLCB3aGljaCBzcGVj aWZpZXMNCiAgIHRoYXQgbm8gaW1wbGljaXQgc3Vic2NyaXB0aW9uIHNob3VsZCBiZSBjcmVhdGVk IGFzIGEgcmVzdWx0IG9mDQogICBhY2NlcHRpbmcgdGhlIFJFRkVSIHJlcXVlc3QuICBUaGlzIG9w dGlvbiB0YWcgaXMgb25seSBtZWFuaW5nZnVsIGZvcg0KICAgdGhlIFJFRkVSIHJlcXVlc3QgZGVm aW5lZCBpbiBSRkMzNTE1Lg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KTGV2aW4g ICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXByaWwgMTcsIDIwMDUgICAgICAgICAgICAgICAg IFtQYWdlIDldDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgUkVGRVIgd2l0aCBub3JlZmVy c3ViICAgICAgICAgICAgICBPY3RvYmVyIDIwMDQNCg0KDQo4LiAgU2VjdXJpdHkgQ29uc2lkZXJh dGlvbnMNCg0KICAgVGhpcyBleHRlbnNpb24gZG9lc24ndCBpbnRyb2R1Y2UgbmV3IHNlY3VyaXR5 IHRocmVhZHMgYmV5b25kIHRob3NlDQogICBpZGVudGlmaWVkIGFuZCBhZGRyZXNzZWQgaW4gdGhl IGNvcmUgU0lQIHNwZWNpZmljYXRpb25zLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCkxldmluICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDE3LCAyMDA1ICAg ICAgICAgICAgICAgIFtQYWdlIDEwXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgIFJFRkVS IHdpdGggbm9yZWZlcnN1YiAgICAgICAgICAgICAgT2N0b2JlciAyMDA0DQoNCg0KOS4gIEFja25v d2xlZGdlbWVudHMNCg0KICAgVGhlIFNJUCBjb21tdW5pdHkgd291bGQgbGlrZSB0byB0aGFuayBT cmlyYW0gUGFyYW1lc3dhciBmb3IgaGlzIGlkZWFzDQogICBiZWluZyBvcmlnaW5hbGx5IHByZXNl bnRlZCBpbiBkcmFmdC1wYXJhbWVzd2FyLXNpcHBpbmctbm9yZWZlcnN1Yi0wMA0KICAgYW5kIGlu Y29ycG9yYXRlZCBpbiB0aGlzIGRvY3VtZW50Lg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQpMZXZpbiAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAxNywgMjAwNSAg ICAgICAgICAgICAgICBbUGFnZSAxMV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICBSRUZF UiB3aXRoIG5vcmVmZXJzdWIgICAgICAgICAgICAgIE9jdG9iZXIgMjAwNA0KDQoNCjEwLiAgUmVm ZXJlbmNlcw0KDQoxMC4xICBOb3JtYXRpdmUgUmVmZXJlbmNlcw0KDQogICBbMV0gIEJyYWRuZXIs IFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZSBSZXF1aXJlbWVudA0K ICAgICAgICBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAxOTk3Lg0KDQogICBbMl0g IFJvc2VuYmVyZywgSi4sIFNjaHVsenJpbm5lLCBILiwgQ2FtYXJpbGxvLCBHLiwgSm9obnN0b24s IEEuLA0KICAgICAgICBQZXRlcnNvbiwgSi4sIFNwYXJrcywgUi4sIEhhbmRsZXksIE0uIGFuZCBF LiBTY2hvb2xlciwgIlNJUDoNCiAgICAgICAgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIiwg UkZDIDMyNjEsIEp1bmUgMjAwMi4NCg0KICAgWzNdICBTcGFya3MsIFIuLCAiVGhlIFNlc3Npb24g SW5pdGlhdGlvbiBQcm90b2NvbCAoU0lQKSBSZWZlcg0KICAgICAgICBNZXRob2QiLCBSRkMgMzUx NSwgQXByaWwgMjAwMy4NCg0KICAgWzRdICBSb2FjaCwgQS4sICJTZXNzaW9uIEluaXRpYXRpb24g UHJvdG9jb2wgKFNJUCktU3BlY2lmaWMgRXZlbnQNCiAgICAgICAgTm90aWZpY2F0aW9uIiwgUkZD IDMyNjUsIEp1bmUgMjAwMi4NCg0KMTAuMiAgSW5mb3JtYXRpb25hbCBSZWZlcmVuY2VzDQoNCiAg IFs1XSAgUm9zZW5iZXJnLCBKLiwgIk9idGFpbmluZyBhbmQgVXNpbmcgR2xvYmFsbHkgUm91dGFi bGUgVXNlciBBZ2VudA0KICAgICAgICAoVUEpIFVSSXMgKEdSVVUpIGluIHRoZSAgU2Vzc2lvbiBJ bml0aWF0aW9uIFByb3RvY29sIChTSVApIiwNCiAgICAgICAgZHJhZnQtaWV0Zi1zaXAtZ3J1dS0w MiAod29yayBpbiBwcm9ncmVzcyksIEp1bHkgMjAwNC4NCg0KDQpBdXRob3IncyBBZGRyZXNzDQoN CiAgIE9yaXQgTGV2aW4NCiAgIE1pY3Jvc29mdCBDb3Jwb3JhdGlvbg0KICAgT25lIE1pY3Jvc29m dCBXYXkNCiAgIFJlZG1vbmQsIFdBICA5ODA1Mg0KICAgVVNBDQoNCiAgIFBob25lOiArMS00MjUt NzIyLTIyMjUNCiAgIEVNYWlsOiBvcml0bEBtaWNyb3NvZnQuY29tDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KTGV2aW4gICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXByaWwg MTcsIDIwMDUgICAgICAgICAgICAgICAgW1BhZ2UgMTJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgUkVGRVIgd2l0aCBub3JlZmVyc3ViICAgICAgICAgICAgICBPY3RvYmVyIDIwMDQNCg0K DQpJbnRlbGxlY3R1YWwgUHJvcGVydHkgU3RhdGVtZW50DQoNCiAgIFRoZSBJRVRGIHRha2VzIG5v IHBvc2l0aW9uIHJlZ2FyZGluZyB0aGUgdmFsaWRpdHkgb3Igc2NvcGUgb2YgYW55DQogICBJbnRl bGxlY3R1YWwgUHJvcGVydHkgUmlnaHRzIG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0IGJlIGNs YWltZWQgdG8NCiAgIHBlcnRhaW4gdG8gdGhlIGltcGxlbWVudGF0aW9uIG9yIHVzZSBvZiB0aGUg dGVjaG5vbG9neSBkZXNjcmliZWQgaW4NCiAgIHRoaXMgZG9jdW1lbnQgb3IgdGhlIGV4dGVudCB0 byB3aGljaCBhbnkgbGljZW5zZSB1bmRlciBzdWNoIHJpZ2h0cw0KICAgbWlnaHQgb3IgbWlnaHQg bm90IGJlIGF2YWlsYWJsZTsgbm9yIGRvZXMgaXQgcmVwcmVzZW50IHRoYXQgaXQgaGFzDQogICBt YWRlIGFueSBpbmRlcGVuZGVudCBlZmZvcnQgdG8gaWRlbnRpZnkgYW55IHN1Y2ggcmlnaHRzLiAg SW5mb3JtYXRpb24NCiAgIG9uIHRoZSBwcm9jZWR1cmVzIHdpdGggcmVzcGVjdCB0byByaWdodHMg aW4gUkZDIGRvY3VtZW50cyBjYW4gYmUNCiAgIGZvdW5kIGluIEJDUCA3OCBhbmQgQkNQIDc5Lg0K DQogICBDb3BpZXMgb2YgSVBSIGRpc2Nsb3N1cmVzIG1hZGUgdG8gdGhlIElFVEYgU2VjcmV0YXJp YXQgYW5kIGFueQ0KICAgYXNzdXJhbmNlcyBvZiBsaWNlbnNlcyB0byBiZSBtYWRlIGF2YWlsYWJs ZSwgb3IgdGhlIHJlc3VsdCBvZiBhbg0KICAgYXR0ZW1wdCBtYWRlIHRvIG9idGFpbiBhIGdlbmVy YWwgbGljZW5zZSBvciBwZXJtaXNzaW9uIGZvciB0aGUgdXNlIG9mDQogICBzdWNoIHByb3ByaWV0 YXJ5IHJpZ2h0cyBieSBpbXBsZW1lbnRlcnMgb3IgdXNlcnMgb2YgdGhpcw0KICAgc3BlY2lmaWNh dGlvbiBjYW4gYmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBvbi1saW5lIElQUiByZXBvc2l0b3J5 IGF0DQogICBodHRwOi8vd3d3LmlldGYub3JnL2lwci4NCg0KICAgVGhlIElFVEYgaW52aXRlcyBh bnkgaW50ZXJlc3RlZCBwYXJ0eSB0byBicmluZyB0byBpdHMgYXR0ZW50aW9uIGFueQ0KICAgY29w eXJpZ2h0cywgcGF0ZW50cyBvciBwYXRlbnQgYXBwbGljYXRpb25zLCBvciBvdGhlciBwcm9wcmll dGFyeQ0KICAgcmlnaHRzIHRoYXQgbWF5IGNvdmVyIHRlY2hub2xvZ3kgdGhhdCBtYXkgYmUgcmVx dWlyZWQgdG8gaW1wbGVtZW50DQogICB0aGlzIHN0YW5kYXJkLiAgUGxlYXNlIGFkZHJlc3MgdGhl IGluZm9ybWF0aW9uIHRvIHRoZSBJRVRGIGF0DQogICBpZXRmLWlwckBpZXRmLm9yZy4NCg0KDQpE aXNjbGFpbWVyIG9mIFZhbGlkaXR5DQoNCiAgIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1h dGlvbiBjb250YWluZWQgaGVyZWluIGFyZSBwcm92aWRlZCBvbiBhbg0KICAgIkFTIElTIiBiYXNp cyBhbmQgVEhFIENPTlRSSUJVVE9SLCBUSEUgT1JHQU5JWkFUSU9OIEhFL1NIRSBSRVBSRVNFTlRT DQogICBPUiBJUyBTUE9OU09SRUQgQlkgKElGIEFOWSksIFRIRSBJTlRFUk5FVCBTT0NJRVRZIEFO RCBUSEUgSU5URVJORVQNCiAgIEVOR0lORUVSSU5HIFRBU0sgRk9SQ0UgRElTQ0xBSU0gQUxMIFdB UlJBTlRJRVMsIEVYUFJFU1MgT1IgSU1QTElFRCwNCiAgIElOQ0xVRElORyBCVVQgTk9UIExJTUlU RUQgVE8gQU5ZIFdBUlJBTlRZIFRIQVQgVEhFIFVTRSBPRiBUSEUNCiAgIElORk9STUFUSU9OIEhF UkVJTiBXSUxMIE5PVCBJTkZSSU5HRSBBTlkgUklHSFRTIE9SIEFOWSBJTVBMSUVEDQogICBXQVJS QU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBPUiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVS UE9TRS4NCg0KDQpDb3B5cmlnaHQgU3RhdGVtZW50DQoNCiAgIENvcHlyaWdodCAoQykgVGhlIElu dGVybmV0IFNvY2lldHkgKDIwMDQpLiAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0DQogICB0byB0 aGUgcmlnaHRzLCBsaWNlbnNlcyBhbmQgcmVzdHJpY3Rpb25zIGNvbnRhaW5lZCBpbiBCQ1AgNzgs IGFuZA0KICAgZXhjZXB0IGFzIHNldCBmb3J0aCB0aGVyZWluLCB0aGUgYXV0aG9ycyByZXRhaW4g YWxsIHRoZWlyIHJpZ2h0cy4NCg0KDQpBY2tub3dsZWRnbWVudA0KDQogICBGdW5kaW5nIGZvciB0 aGUgUkZDIEVkaXRvciBmdW5jdGlvbiBpcyBjdXJyZW50bHkgcHJvdmlkZWQgYnkgdGhlDQogICBJ bnRlcm5ldCBTb2NpZXR5Lg0KDQoNCg0KDQpMZXZpbiAgICAgICAgICAgICAgICAgICAgRXhwaXJl cyBBcHJpbCAxNywgMjAwNSAgICAgICAgICAgICAgICBbUGFnZSAxM10NCgwNCg0K ------_=_NextPart_001_01C4C80E.CDA3C5ED Content-Type: text/plain; name="draft-ietf-sip-refer-with-feature-param-00.txt" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-sip-refer-with-feature-param-00.txt Content-Disposition: attachment; filename="draft-ietf-sip-refer-with-feature-param-00.txt" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 DQoNCg0KU0lQICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIE8uIExldmluDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBNaWNyb3NvZnQgQ29ycG9yYXRpb24NCkV4cGlyZXM6IEFwcmlsIDE3 LCAyMDA1ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgT2N0b2JlciAxNywgMjAwNA0K DQoNCiAgICAgICAgICAgICBVc2luZyBvZiBGZWF0dXJlIFRhZ3Mgd2l0aCBSRUZFUiBtZXRob2Qg aW4gU0lQDQogICAgICAgICAgICAgICBkcmFmdC1pZXRmLXNpcC1yZWZlci13aXRoLWZlYXR1cmUt cGFyYW0tMDANCg0KU3RhdHVzIG9mIHRoaXMgTWVtbw0KDQogICBUaGlzIGRvY3VtZW50IGlzIGFu IEludGVybmV0LURyYWZ0IGFuZCBpcyBzdWJqZWN0IHRvIGFsbCBwcm92aXNpb25zDQogICBvZiBz ZWN0aW9uIDMgb2YgUkZDIDM2NjcuICBCeSBzdWJtaXR0aW5nIHRoaXMgSW50ZXJuZXQtRHJhZnQs IGVhY2gNCiAgIGF1dGhvciByZXByZXNlbnRzIHRoYXQgYW55IGFwcGxpY2FibGUgcGF0ZW50IG9y IG90aGVyIElQUiBjbGFpbXMgb2YNCiAgIHdoaWNoIGhlIG9yIHNoZSBpcyBhd2FyZSBoYXZlIGJl ZW4gb3Igd2lsbCBiZSBkaXNjbG9zZWQsIGFuZCBhbnkgb2YNCiAgIHdoaWNoIGhlIG9yIHNoZSBi ZWNvbWUgYXdhcmUgd2lsbCBiZSBkaXNjbG9zZWQsIGluIGFjY29yZGFuY2Ugd2l0aA0KICAgUkZD IDM2NjguDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhl IEludGVybmV0IEVuZ2luZWVyaW5nDQogICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBh bmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0DQogICBvdGhlciBncm91cHMgbWF5IGFs c28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcw0KICAgSW50ZXJuZXQtRHJhZnRzLg0K DQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhp bXVtIG9mIHNpeCBtb250aHMNCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9i c29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55DQogICB0aW1lLiAgSXQgaXMgaW5hcHBy b3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQ0KICAgbWF0ZXJpYWwg b3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg0KDQogICBU aGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAg IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dC4NCg0KICAgVGhlIGxp c3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBh dA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC4NCg0KICAgVGhpcyBJbnRlcm5l dC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBBcHJpbCAxNywgMjAwNS4NCg0KQ29weXJpZ2h0IE5vdGlj ZQ0KDQogICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDA0KS4NCg0KQWJz dHJhY3QNCg0KICAgVGhpcyBkb2N1bWVudCBleHRlbmRzIHRoZSBSRUZFUiBtZXRob2QsIGRlZmlu ZWQgaW4gUkZDLTM1MTUsIHRvIGJlDQogICB1c2VkIHdpdGggZmVhdHVyZSBwYXJhbWV0ZXJzIGRl ZmluZWQgaW4gUkZDLTM4NDAuDQoNCg0KDQoNCg0KDQoNCg0KDQpMZXZpbiAgICAgICAgICAgICAg ICAgICAgRXhwaXJlcyBBcHJpbCAxNywgMjAwNSAgICAgICAgICAgICAgICAgW1BhZ2UgMV0NCgwN CkludGVybmV0LURyYWZ0ICAgICAgICAgIFJFRkVSIHdpdGggRmVhdHVyZSBQYXJhbSAgICAgICAg ICAgIE9jdG9iZXIgMjAwNA0KDQoNClRhYmxlIG9mIENvbnRlbnRzDQoNCiAgIDEuICBUZXJtaW5v bG9neSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg Mw0KICAgMi4gIEludHJvZHVjdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICA0DQogICAzLiAgRGVmaW5pdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDUNCiAgIDQuICBFeGFtcGxlcyAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNg0KICAg ICA0LjEgICBpc2ZvY3VzIEZlYXR1cmUgVGFnIFVzYWdlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICA2DQogICAgIDQuMiAgIFZvaWNlIGFuZCBWaWRlbyBGZWF0dXJlIFRhZ3MgVXNh Z2UgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDYNCiAgIDUuICBJQU5BIENvbnNpZGVyYXRpb25z ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNw0KICAgNi4gIFNl Y3VyaXR5IENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICA4DQogICA3LiAgQWNrbm93bGVkZ2VtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDkNCiAgIDguICBOb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOQ0KICAgICAgIEF1dGhvcidz IEFkZHJlc3MgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA5 DQogICAgICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IGFuZCBDb3B5cmlnaHQgU3RhdGVtZW50cyAu IC4gLiAuIC4gLiAuIC4gMTANCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KTGV2aW4gICAgICAgICAgICAgICAg ICAgIEV4cGlyZXMgQXByaWwgMTcsIDIwMDUgICAgICAgICAgICAgICAgIFtQYWdlIDJdDQoMDQpJ bnRlcm5ldC1EcmFmdCAgICAgICAgICBSRUZFUiB3aXRoIEZlYXR1cmUgUGFyYW0gICAgICAgICAg ICBPY3RvYmVyIDIwMDQNCg0KDQoxLiAgVGVybWlub2xvZ3kNCg0KICAgVGhlIGtleSB3b3JkcyAi TVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLA0KICAg IlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgICJNQVkiLCBhbmQgIk9QVElP TkFMIiBpbiB0aGlzDQogICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3Jp YmVkIGluIFJGQyAyMTE5IFsxXS4NCg0KICAgVG8gc2ltcGxpZnkgZGlzY3Vzc2lvbnMgb2YgdGhl IFJFRkVSIG1ldGhvZCBhbmQgaXRzIGV4dGVuc2lvbnMsIHRocmVlDQogICBuZXcgdGVybXMgYXJl IGJlaW5nIHVzZWQgdGhyb3VnaG91dCB0aGUgZG9jdW1lbnQ6DQogICBvICBSRUZFUi1Jc3N1ZXI6 IHRoZSBVQSBpc3N1aW5nIHRoZSBSRUZFUiByZXF1ZXN0DQogICBvICBSRUZFUi1SZWNpcGllbnQ6 IHRoZSBVQSByZWNlaXZpbmcgdGhlIFJFRkVSIHJlcXVlc3QNCiAgIG8gIFJFRkVSLVRhcmdldDog dGhlIFVBIGRlc2lnbmF0ZWQgaW4gdGhlIFJlZmVyLVRvIFVSSQ0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQpMZXZpbiAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAxNywgMjAwNSAgICAg ICAgICAgICAgICAgW1BhZ2UgM10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgIFJFRkVSIHdp dGggRmVhdHVyZSBQYXJhbSAgICAgICAgICAgIE9jdG9iZXIgMjAwNA0KDQoNCjIuICBJbnRyb2R1 Y3Rpb24NCg0KICAgVGhpcyBkb2N1bWVudCBleHRlbmRzIFJFRkVSIG1ldGhvZCBkZWZpbmVkIGlu IFJGQy0zNTE1IFszXSB0byBiZSB1c2VkDQogICB3aXRoIGZlYXR1cmUgcGFyYW1ldGVycyBkZWZp bmVkIGluIFJGQy0zODQwIFs0XSAuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KTGV2aW4gICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXByaWwgMTcsIDIwMDUgICAgICAg ICAgICAgICAgIFtQYWdlIDRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICBSRUZFUiB3aXRo IEZlYXR1cmUgUGFyYW0gICAgICAgICAgICBPY3RvYmVyIDIwMDQNCg0KDQozLiAgRGVmaW5pdGlv bg0KDQogICBUaGUgUmVmZXItVG8gQk5GIGZyb20gUkZDLTM1MTU6DQoNCiAgIFJlZmVyLVRvID0g KCJSZWZlci1UbyIgLyAiciIpIEhDT0xPTiAoIG5hbWUtYWRkciAvIGFkZHItc3BlYyApICogKFNF TUkgZ2VuZXJpYy1wYXJhbSkNCg0KICAgaXMgZXh0ZW5kZWQgdG86DQoNCiAgIFJlZmVyLVRvID0g KCJSZWZlci1UbyIgLyAiciIpIEhDT0xPTiAoIG5hbWUtYWRkciAvIGFkZHItc3BlYyApICogKFNF TUkgcmVmZXItcGFyYW0pDQogICByZWZlci1wYXJhbSA9IGdlbmVyaWMtcGFyYW0gLyBmZWF0dXJl LXBhcmFtDQoNCiAgIHdoZXJlIGZlYXR1cmUtcGFyYW0gaXMgZGVmaW5lZCBpbiBTZWN0aW9uIDkg b2YgUkZDLTM4NDAgWzRdLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KTGV2aW4gICAgICAgICAgICAg ICAgICAgIEV4cGlyZXMgQXByaWwgMTcsIDIwMDUgICAgICAgICAgICAgICAgIFtQYWdlIDVdDQoM DQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICBSRUZFUiB3aXRoIEZlYXR1cmUgUGFyYW0gICAgICAg ICAgICBPY3RvYmVyIDIwMDQNCg0KDQo0LiAgRXhhbXBsZXMNCg0KNC4xICBpc2ZvY3VzIEZlYXR1 cmUgVGFnIFVzYWdlDQoNCiAgIFRoZSBzeW50YXggYmVsb3cgc2hvd3MgaG93IHRoZSAiaXNmb2N1 cyIgZmVhdHVyZSB0YWcgY2FuIGJlIHVzZWQgYnkNCiAgIFJFRkVSLUlzc3VlciB0byB0ZWxsIHRo ZSBSRUZFUi1SZWNpcGllbnQgdGhhdCB0aGUgUkVGRVItVGFyZ2V0IGlzIGENCiAgIGNvbmZlcmVu Y2UgZm9jdXMgYW5kLCBjb25zZXF1ZW50bHksIHNlbmRpbmcgYW4gSU5WSVRFIHdpbGwgYnJpbmcg dGhlDQogICBSRUZFUi1SZWNpcGllbnQgaW50byB0aGUgY29uZmVyZW5jZToNCg0KICAgUmVmZXIt VG86IHNpcDpjb25mNDRAZXhhbXBsZS5jb207aXNmb2N1cw0KDQo0LjIgIFZvaWNlIGFuZCBWaWRl byBGZWF0dXJlIFRhZ3MgVXNhZ2UNCg0KICAgVGhlIHN5bnRheCBiZWxvdyBzaG93cyBob3cgYSBS RUZFUi1Jc3N1ZXIgY2FuIHRlbGwgdGhlDQogICBSRUZFUi1SZWNpcGllbnQgdGhhdCB0aGUgUkVG RVItVGFyZ2V0IHN1cHBvcnRzIGF1ZGlvIGFuZCB2aWRlbyBhbmQsDQogICBjb25zZXF1ZW50bHks IHRoYXQgYSB2aWRlbyBhbmQgYXVkaW8gc2Vzc2lvbiBjYW4gYmUgZXN0YWJsaXNoZWQgYnkNCiAg IHNlbmRpbmcgYW4gSU5WSVRFIHRvIHRoZSBSRUZFUi1UYXJnZXQ6DQoNCiAgIFJlZmVyLVRvOiBz aXA6dmlkZW9waG9uZUBleGFtcGxlLmNvbTthdWRpbzt2aWRlbw0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkxldmluICAgICAg ICAgICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDE3LCAyMDA1ICAgICAgICAgICAgICAgICBbUGFn ZSA2XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgUkVGRVIgd2l0aCBGZWF0dXJlIFBhcmFt ICAgICAgICAgICAgT2N0b2JlciAyMDA0DQoNCg0KNS4gIElBTkEgQ29uc2lkZXJhdGlvbnMNCg0K ICAgTm9uZS4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkxldmluICAg ICAgICAgICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDE3LCAyMDA1ICAgICAgICAgICAgICAgICBb UGFnZSA3XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgUkVGRVIgd2l0aCBGZWF0dXJlIFBh cmFtICAgICAgICAgICAgT2N0b2JlciAyMDA0DQoNCg0KNi4gIFNlY3VyaXR5IENvbnNpZGVyYXRp b25zDQoNCiAgIFRoaXMgZXh0ZW5zaW9uIGRvZXNuJ3QgaW50cm9kdWNlIG5ldyBzZWN1cml0eSB0 aHJlYWRzIGJleW9uZCB0aG9zZQ0KICAgaWRlbnRpZmllZCBhbmQgYWRkcmVzc2VkIGluIHRoZSBj b3JlIFNJUCBzcGVjaWZpY2F0aW9ucy4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQpMZXZpbiAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAxNywgMjAwNSAgICAg ICAgICAgICAgICAgW1BhZ2UgOF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgIFJFRkVSIHdp dGggRmVhdHVyZSBQYXJhbSAgICAgICAgICAgIE9jdG9iZXIgMjAwNA0KDQoNCjcuICBBY2tub3ds ZWRnZW1lbnRzDQoNCiAgIFRoZSBhdXRob3Igd291bGQgbGlrZSB0byB0aGFuayBKb25hdGhhbiBS b3NlbmJlcmcgYW5kIEFsYW4gSm9obnN0b24NCiAgIGZvciBwcm92aWRpbmcgaGVscGZ1bCBndWlk YW5jZSB0byB0aGlzIHdvcmsuDQoNCjggIE5vcm1hdGl2ZSBSZWZlcmVuY2VzDQoNCiAgIFsxXSAg QnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlIFJlcXVp cmVtZW50DQogICAgICAgIExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuDQoN CiAgIFsyXSAgUm9zZW5iZXJnLCBKLiwgU2NodWx6cmlubmUsIEguLCBDYW1hcmlsbG8sIEcuLCBK b2huc3RvbiwgQS4sDQogICAgICAgIFBldGVyc29uLCBKLiwgU3BhcmtzLCBSLiwgSGFuZGxleSwg TS4gYW5kIEUuIFNjaG9vbGVyLCAiU0lQOg0KICAgICAgICBTZXNzaW9uIEluaXRpYXRpb24gUHJv dG9jb2wiLCBSRkMgMzI2MSwgSnVuZSAyMDAyLg0KDQogICBbM10gIFNwYXJrcywgUi4sICJUaGUg U2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIChTSVApIFJlZmVyDQogICAgICAgIE1ldGhvZCIs IFJGQyAzNTE1LCBBcHJpbCAyMDAzLg0KDQogICBbNF0gIFJvc2VuYmVyZywgSi4sIFNjaHVsenJp bm5lLCBILiBhbmQgUC4gS3l6aXZhdCwgIkluZGljYXRpbmcgVXNlcg0KICAgICAgICBBZ2VudCBD YXBhYmlsaXRpZXMgaW4gdGhlIFNlc3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbCAoU0lQKSIsDQog ICAgICAgIFJGQyAzODQwLCBBdWd1c3QgMjAwNC4NCg0KDQpBdXRob3IncyBBZGRyZXNzDQoNCiAg IE9yaXQgTGV2aW4NCiAgIE1pY3Jvc29mdCBDb3Jwb3JhdGlvbg0KICAgT25lIE1pY3Jvc29mdCBX YXkNCiAgIFJlZG1vbmQsIFdBICA5ODA1Mg0KICAgVVNBDQoNCiAgIFBob25lOiArMS00MjUtNzIy LTIyMjUNCiAgIEVNYWlsOiBvcml0bEBtaWNyb3NvZnQuY29tDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCkxldmluICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEFwcmls IDE3LCAyMDA1ICAgICAgICAgICAgICAgICBbUGFnZSA5XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgUkVGRVIgd2l0aCBGZWF0dXJlIFBhcmFtICAgICAgICAgICAgT2N0b2JlciAyMDA0DQoN Cg0KSW50ZWxsZWN0dWFsIFByb3BlcnR5IFN0YXRlbWVudA0KDQogICBUaGUgSUVURiB0YWtlcyBu byBwb3NpdGlvbiByZWdhcmRpbmcgdGhlIHZhbGlkaXR5IG9yIHNjb3BlIG9mIGFueQ0KICAgSW50 ZWxsZWN0dWFsIFByb3BlcnR5IFJpZ2h0cyBvciBvdGhlciByaWdodHMgdGhhdCBtaWdodCBiZSBj bGFpbWVkIHRvDQogICBwZXJ0YWluIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBvciB1c2Ugb2YgdGhl IHRlY2hub2xvZ3kgZGVzY3JpYmVkIGluDQogICB0aGlzIGRvY3VtZW50IG9yIHRoZSBleHRlbnQg dG8gd2hpY2ggYW55IGxpY2Vuc2UgdW5kZXIgc3VjaCByaWdodHMNCiAgIG1pZ2h0IG9yIG1pZ2h0 IG5vdCBiZSBhdmFpbGFibGU7IG5vciBkb2VzIGl0IHJlcHJlc2VudCB0aGF0IGl0IGhhcw0KICAg bWFkZSBhbnkgaW5kZXBlbmRlbnQgZWZmb3J0IHRvIGlkZW50aWZ5IGFueSBzdWNoIHJpZ2h0cy4g IEluZm9ybWF0aW9uDQogICBvbiB0aGUgcHJvY2VkdXJlcyB3aXRoIHJlc3BlY3QgdG8gcmlnaHRz IGluIFJGQyBkb2N1bWVudHMgY2FuIGJlDQogICBmb3VuZCBpbiBCQ1AgNzggYW5kIEJDUCA3OS4N Cg0KICAgQ29waWVzIG9mIElQUiBkaXNjbG9zdXJlcyBtYWRlIHRvIHRoZSBJRVRGIFNlY3JldGFy aWF0IGFuZCBhbnkNCiAgIGFzc3VyYW5jZXMgb2YgbGljZW5zZXMgdG8gYmUgbWFkZSBhdmFpbGFi bGUsIG9yIHRoZSByZXN1bHQgb2YgYW4NCiAgIGF0dGVtcHQgbWFkZSB0byBvYnRhaW4gYSBnZW5l cmFsIGxpY2Vuc2Ugb3IgcGVybWlzc2lvbiBmb3IgdGhlIHVzZSBvZg0KICAgc3VjaCBwcm9wcmll dGFyeSByaWdodHMgYnkgaW1wbGVtZW50ZXJzIG9yIHVzZXJzIG9mIHRoaXMNCiAgIHNwZWNpZmlj YXRpb24gY2FuIGJlIG9idGFpbmVkIGZyb20gdGhlIElFVEYgb24tbGluZSBJUFIgcmVwb3NpdG9y eSBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pcHIuDQoNCiAgIFRoZSBJRVRGIGludml0ZXMg YW55IGludGVyZXN0ZWQgcGFydHkgdG8gYnJpbmcgdG8gaXRzIGF0dGVudGlvbiBhbnkNCiAgIGNv cHlyaWdodHMsIHBhdGVudHMgb3IgcGF0ZW50IGFwcGxpY2F0aW9ucywgb3Igb3RoZXIgcHJvcHJp ZXRhcnkNCiAgIHJpZ2h0cyB0aGF0IG1heSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQgbWF5IGJlIHJl cXVpcmVkIHRvIGltcGxlbWVudA0KICAgdGhpcyBzdGFuZGFyZC4gIFBsZWFzZSBhZGRyZXNzIHRo ZSBpbmZvcm1hdGlvbiB0byB0aGUgSUVURiBhdA0KICAgaWV0Zi1pcHJAaWV0Zi5vcmcuDQoNCg0K RGlzY2xhaW1lciBvZiBWYWxpZGl0eQ0KDQogICBUaGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3Jt YXRpb24gY29udGFpbmVkIGhlcmVpbiBhcmUgcHJvdmlkZWQgb24gYW4NCiAgICJBUyBJUyIgYmFz aXMgYW5kIFRIRSBDT05UUklCVVRPUiwgVEhFIE9SR0FOSVpBVElPTiBIRS9TSEUgUkVQUkVTRU5U Uw0KICAgT1IgSVMgU1BPTlNPUkVEIEJZIChJRiBBTlkpLCBUSEUgSU5URVJORVQgU09DSUVUWSBB TkQgVEhFIElOVEVSTkVUDQogICBFTkdJTkVFUklORyBUQVNLIEZPUkNFIERJU0NMQUlNIEFMTCBX QVJSQU5USUVTLCBFWFBSRVNTIE9SIElNUExJRUQsDQogICBJTkNMVURJTkcgQlVUIE5PVCBMSU1J VEVEIFRPIEFOWSBXQVJSQU5UWSBUSEFUIFRIRSBVU0UgT0YgVEhFDQogICBJTkZPUk1BVElPTiBI RVJFSU4gV0lMTCBOT1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElFRA0KICAgV0FS UkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBV UlBPU0UuDQoNCg0KQ29weXJpZ2h0IFN0YXRlbWVudA0KDQogICBDb3B5cmlnaHQgKEMpIFRoZSBJ bnRlcm5ldCBTb2NpZXR5ICgyMDA0KS4gIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdA0KICAgdG8g dGhlIHJpZ2h0cywgbGljZW5zZXMgYW5kIHJlc3RyaWN0aW9ucyBjb250YWluZWQgaW4gQkNQIDc4 LCBhbmQNCiAgIGV4Y2VwdCBhcyBzZXQgZm9ydGggdGhlcmVpbiwgdGhlIGF1dGhvcnMgcmV0YWlu IGFsbCB0aGVpciByaWdodHMuDQoNCg0KQWNrbm93bGVkZ21lbnQNCg0KICAgRnVuZGluZyBmb3Ig dGhlIFJGQyBFZGl0b3IgZnVuY3Rpb24gaXMgY3VycmVudGx5IHByb3ZpZGVkIGJ5IHRoZQ0KICAg SW50ZXJuZXQgU29jaWV0eS4NCg0KDQoNCg0KTGV2aW4gICAgICAgICAgICAgICAgICAgIEV4cGly ZXMgQXByaWwgMTcsIDIwMDUgICAgICAgICAgICAgICAgW1BhZ2UgMTBdDQoMDQoNCg== ------_=_NextPart_001_01C4C80E.CDA3C5ED Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_001_01C4C80E.CDA3C5ED-- From sip-bounces@ietf.org Thu Nov 11 14:05:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12772 for ; Thu, 11 Nov 2004 14:05:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSKHO-0001Xu-70 for sip-web-archive@ietf.org; Thu, 11 Nov 2004 14:06:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSK99-00030U-AY; Thu, 11 Nov 2004 13:58:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSK5j-0002J2-75 for sip@megatron.ietf.org; Thu, 11 Nov 2004 13:54:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11927 for ; Thu, 11 Nov 2004 13:54:42 -0500 (EST) Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSK6m-0001Iu-QO for sip@ietf.org; Thu, 11 Nov 2004 13:55:59 -0500 Received: from dfnjgl21 (unknown[130.129.135.144]) by comcast.net (rwcrmhc12) with SMTP id <2004111118535301400nkpgce> (Authid: sdawkins@comcast.net); Thu, 11 Nov 2004 18:53:54 +0000 Message-ID: <07ba01c4c81f$e92872a0$90878182@DFNJGL21> From: "Spencer Dawkins" To: "Christian Jansson" , "Christian Stredicke" References: Subject: Re: [Sip] PING/PONG [bcc][faked-from][heur] [mx][spf] Date: Thu, 11 Nov 2004 13:54:43 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Spencer Dawkins List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit OK, I'm still confused here. Please help me. The apparent choices include "Keep-alives for TCP should be CRLF (default-interval TBD)". Sending keep-alives over TCP may be interesting, but I'm really confused about what you think is a reasonable action when you send a PING over TCP and don't get a PONG back. If you change a status indicator on a user display that says "may have lost connectivity", that's fine. If you try to retransmit requests, I'm concerned. My definition of "reasonable" includes "don't send multiple new packets into a network path that is not returning PONGs, when the problem may be that the network path is losing packets because it is already congested." Retransmitting requests requires exactly this (tear down existing TCP connection, because it's still retransmitting, open a new TCP connection, and then retransmit the request at the application level). There is no way for the endpoints to know that loss is NOT due to congestion, and putting TCP-based "lost packet multipliers" in place in end systems that can't know they aren't facing congestion is not something I'm comfortable with. If TCP isn't the right answer, using TCP and sending multiple new TCP packets when a connection won't PING/PONG isn't helpful. Spencer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 11 16:17:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29007 for ; Thu, 11 Nov 2004 16:17:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSMKv-0005Nk-Dp for sip-web-archive@ietf.org; Thu, 11 Nov 2004 16:18:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSMAp-0008KO-Vs; Thu, 11 Nov 2004 16:08:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSM4i-0004kB-IO for sip@megatron.ietf.org; Thu, 11 Nov 2004 16:01:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27459 for ; Thu, 11 Nov 2004 16:01:46 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSM5w-0004wo-7g for sip@ietf.org; Thu, 11 Nov 2004 16:03:05 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 11 Nov 2004 13:15:23 -0800 X-BrightmailFiltered: true Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iABL1Aom010501; Thu, 11 Nov 2004 13:01:11 -0800 (PST) Received: from [130.129.135.140] (sjc-vpn5-601.cisco.com [10.21.90.89]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFR48240; Thu, 11 Nov 2004 13:01:11 -0800 (PST) Message-ID: <4193D317.5000604@cisco.com> Date: Thu, 11 Nov 2004 16:01:11 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] Event Lists: Back-End Credentials References: <5816828233DEFA41807A6CFDFDF2343C3A8BD7@esebe056.ntc.nokia.com> <418101FF.9030506@nostrum.com> <41938CF6.60008@cisco.com> In-Reply-To: <41938CF6.60008@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Adam Roach X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Its worth noting that this issue has come up in the context of 3gpp, Oops - s/3gpp/3pcc > where it is actually even harder of a problem than it is here. I suggest > folks read section 12.1 of RFC 3725. > > Basically, what is says is that delegation is a hard problem, we don't > have a solution for it. So, in the interim, the 3pcc controller set the > From in a specific way in order to be usable in applications which > (perhaps sadly) don't authenticate. And that's it. > > I'm not sure if precedent of past acceptability of this kind of > statement can help us, but at least there is a precedent. > > -Jonathan R. > > > > Adam Roach wrote: > >> hisham.khartabil@nokia.com wrote: >> >>> >>>> A consequence of this is that, lacking any other mechanism, the >>>> resources in a resource list for which the RLS is not authoritative >>>> will contain only the information that their notifier is willing to >>>> reveal to the RLS -- which is generally the same information they >>>> would render to unauthenticated users. In some cases, this might >>>> result in no useful information being transferred. >>>> >>> >>> >>> >>> This limitation by itself kills the idea, IMO. Most presence lists >>> will rely on the event list, and if its gonna mean that no useful >>> information will come to the watcher, then the whole mecahnism is >>> useless. >>> >>> >> >> That's a bit of a strong characterization, and it seems to ignore the >> remainder of the mail that I sent out; specifically: >> >> 1. Users have the ability to subscribe to any resources that the RLS >> marks itself as non-authoritative, and >> 2. (More Importantly) Provisions for delegation of authority are >> included -- they're just not in-scope for this document. >> >> /a >> > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 11 16:52:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02676 for ; Thu, 11 Nov 2004 16:52:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSMtK-0006Lq-9e for sip-web-archive@ietf.org; Thu, 11 Nov 2004 16:54:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSMoY-0001Gh-Dq; Thu, 11 Nov 2004 16:49:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSMaK-0005YI-Df for sip@megatron.ietf.org; Thu, 11 Nov 2004 16:34:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00891 for ; Thu, 11 Nov 2004 16:34:26 -0500 (EST) Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSMbW-0005s0-8t for sip@ietf.org; Thu, 11 Nov 2004 16:35:45 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iABLY7F22621; Thu, 11 Nov 2004 23:34:10 +0200 (EET) X-Scanned: Thu, 11 Nov 2004 23:35:10 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id iABLZAt1007477; Thu, 11 Nov 2004 23:35:10 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00DBfelA; Thu, 11 Nov 2004 23:35:08 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iABLXca00111; Thu, 11 Nov 2004 23:33:38 +0200 (EET) Received: from [130.129.134.192] ([10.241.59.134]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 11 Nov 2004 23:33:34 +0200 Message-ID: <4193DAAC.3020609@nokia.com> Date: Thu, 11 Nov 2004 16:33:32 -0500 From: Aki Niemi User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: SIP WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Nov 2004 21:33:34.0631 (UTC) FILETIME=[18FE1370:01C4C836] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Cc: Adam Roach Subject: [Sip] RLS and identity X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Hi, Just a minor note on this: if/when mandating the support for asserted identity in the event-list draft, please remember to say that p-asserted identities also count (to some extent). 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 sip-bounces@ietf.org Thu Nov 11 17:40:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07750 for ; Thu, 11 Nov 2004 17:40:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSNdY-0007jS-0p for sip-web-archive@ietf.org; Thu, 11 Nov 2004 17:41:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSNPD-0002we-A8; Thu, 11 Nov 2004 17:27:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSGEz-0001XR-Mx for sip@megatron.ietf.org; Thu, 11 Nov 2004 09:48:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16653 for ; Thu, 11 Nov 2004 09:47:59 -0500 (EST) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSGG9-0003jq-Ip for sip@ietf.org; Thu, 11 Nov 2004 09:49:15 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 11 Nov 2004 15:44:13 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Sip] Privacy statements and History (draft-ietf-sip-history-info-04.txt) Date: Thu, 11 Nov 2004 15:44:12 +0100 Message-ID: Thread-Topic: [Sip] Privacy statements and History (draft-ietf-sip-history-info-04.txt) Thread-Index: AcTHWWbHffS/1yaGQlWaIsqeA8xm8QAmrxyA From: "PROUVOST Sebastien RD-CORE-ISS" To: "Mary Barnes" , "GARCIN Sebastien RD-CORE-ISS" , "Jesske, R" , X-OriginalArrivalTime: 11 Nov 2004 14:44:13.0630 (UTC) FILETIME=[E97EBDE0:01C4C7FC] X-Spam-Score: 0.9 (/) X-Scan-Signature: 0f40296e255daed48e331f1ce8479531 X-Mailman-Approved-At: Thu, 11 Nov 2004 17:27:01 -0500 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1025062005==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 06d482d1c72628b52d66564c4b21944e This is a multi-part message in MIME format. --===============1025062005== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C7FC.E9411EA2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4C7FC.E9411EA2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mary, Sebastien, Roland,=20 =20 I agree that we should let the possibility for a proxy not to remove the = hi-entry even if privacy is requested and even if the request is = forwarded to a Request-URI associated with a domain for which the proxy = is not responsible (if there is an agreement between the domains that = ensures the proxy that privacy will be applied to the request).=20 I suggest a text that would look like (in case privacy is requested): = "the hi-entry SHOULD be removed by the proxy unless it knows that it can = rely on a downstream privacy service to apply the requested privacy ". =20 Sebastien. ________________________________ De : sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] De la part de = Mary Barnes Envoy=E9 : mercredi 10 novembre 2004 19:54 =C0 : GARCIN Sebastien RD-CORE-ISS; Jesske, R; sip@ietf.org Objet : RE: [Sip] Privacy statements and History = (draft-ietf-sip-history-info-04.txt) I still contend that the SHOULD is sufficient. SHOULD means that in = general processing, if the hi-entry has a privacy header, then the usual = processing would be that it would be removed (i.e it was added for a = specific reason and in general should be used to remove the entries = based on well defined criteria). If there are reasons, such as local = policy, that would allow the forwarding in specific cases, then it's = okay that it is forwarded. I think the use of MAY results in less = precision and I think the value and critera for associating and removing = the privacy header with the hi-entry becomes much less clear. =20 I'd like to hear more opinions on this topic, prior to agreeing to = making the change (from the MUST to MAY rather than MUST to SHOULD).=20 Regards,=20 Mary=20 -----Original Message-----=20 From: GARCIN Sebastien RD-CORE-ISS = [mailto:sebastien.garcin@francetelecom.com]=20 Sent: Wednesday, November 10, 2004 12:28 PM=20 To: Barnes, Mary [NGC:B601:EXCH]; Jesske, R; sip@ietf.org=20 Cc: VL-T-Com-T-TE332@vli.telekom.de=20 Subject: RE: [Sip] Privacy statements and History = (draft-ietf-sip-history-info-04.txt)=20 Mary and roland,=20 Actually, the statement regarding the forwarding of hi-entries beyond = the domain for which the proxy is responsible should rather be a matter = of local policy and thus a MAY should be used instead of SHOULD. We are = potentially dealing with network boundaries where agreements for = forwarding such kind information can be reached.=20 Section 4.3.3.1.1=20 This section should be re-reworded in accordance with the statement = above (I can provide some text is we can agree).=20 Section 4.3.3.1 is ok (apologies for not being explicit)=20 Best regards,=20 s=E9bastien=20 ________________________________=20 De : Mary Barnes [mailto:mary.barnes@nortelnetworks.com]=20 Envoy=E9 : mercredi 10 novembre 2004 16:21=20 =C0 : 'Jesske, R'; GARCIN Sebastien RD-CORE-ISS; sip@ietf.org=20 Cc : VL-T-Com-T-TE332@vli.telekom.de=20 Objet : RE: [Sip] Privacy statements and History = (draft-ietf-sip-history-info-04.txt)=20 Roland and Sebastien,=20 =20 I too agree with the proposal to change the strength of the referenced = statement from section 4.3.3.1.1 from MUST to SHOULD. This change is = consistent with the other normative statements in section 4.3.3.1.1, = which are SHOULDs rather than MUSTs. I'll make that change in the next = rev unless someone raises concerns over that change.=20 On the second concern, I'm not clear what the proposed change is for the = following:=20 [SG] Another issue is the decision to add hi-entries in a privacy = context. A proxy changing the target (i.e. the proxy is responsible of = the resource reflected in the received Request-URI) of a request which = contained a "privacy=3Dhistory" header MAY add a history-entries = provided that it knows it can rely on other entities within the trust = domain to apply the requested privacy. This affect item 4 in the list on = conditions of section 4.3.3 and 4.3.3.1.=20 Item 4 in section 4.3.3 describes the general situation, thus the = strength (MAY) describes the general fact that the use of privacy is = optional. The normative text provided in 4.3.3.1, provides the general = model for adding hi-entries, with the privacy specific considerations = for adding the entries described in 4.3.3.1.1. I think what you're = suggesting is changing the strength of the following statement in = section 4.3.3.1: " The hi-entry MUST be added following any hi-entry received in the = request being forwarded."=20 I can see that in the context of privacy considerations, this might seem = misleading. That MUST was originally a SHOULD but was changed (as = discussed on the list and at IETF-60) to MUST based on issue JRE- 4, so = a simple change of MUST to MAY would not at all work. I thought it was = clear from the statement at the beginning of 4.3.3.1, that this section = is describing the scenario under which the general privacy = considerations had been evaluated and the intention was to add an = hi-entry, thus the statements should be read in the context that the = general screening indicates that an hi-entry SHOULD be added and if one = is added it MUST be added following any entry that's already in the = request to preserve the ordering. If you have explicit changes to the = text that you think would further clarify the functionality, we can = discuss.=20 Roland, if you have specific text on how I could incorporate a reference = to RFC3323, we can consider that; fundamentally any discussion of = privacy depends on RFC 3323, so it's not clear to me how you were = suggesting we incorporate such a reference. The text in this document = (history-info) should accurately describe the processing impact of the = new "history" priv-value.=20 Thanks for your input,=20 Mary=20 -----Original Message-----=20 From: Jesske, R [mailto:R.Jesske@t-com.net]=20 Sent: Wednesday, November 10, 2004 7:59 AM=20 To: sebastien.garcin@francetelecom.com; Barnes, Mary = [NGC:B601:EXCH]; sip@ietf.org=20 Cc: VL-T-Com-T-TE332@vli.telekom.de=20 Subject: AW: [Sip] Privacy statements and History = (draft-ietf-sip-history-info-04.txt)=20 =20 =20 Dear Mary and Sebastien,=20 here are my Comments to Sebastien's statements:=20 =20 Your first proposal I can accept from my point of view.=20 On you second issue my impression is that this issue must be = seen with regard to RFC3323 where privacy and the trust concept is = described. Perhaps a reference to this document should be included. On your last point, I think we can also refer to RFC 3323.=20 =20 What are you thinking?=20 =20 Best Regards=20 =20 Roland=20 =20 ---- Mary snipped forwarding info to keep message = smaller----------- =20 =20 = -----Original Message-----=20 From: GARCIN Sebastien RD-CORE-ISS = [mailto:sebastien.garcin@francetelecom.com]=20 Sent: Monday, November 08, 2004 10:11 AM = To: Barnes, Mary [NGC:B601:EXCH]; = sip@ietf.org=20 Subject: [Sip] Privacy statements and = History (draft-ietf-sip-history-info-04.txt)=20 =20 =20 Hi mary, all=20 =20 When reading = draft-ietf-sip-history-info-04.txt, I have trouble in understanding some = of the statements which relate to the forwarding rules for = history-entries subject to privacy. It is an important requirement that = History-entrie(s) with a Privacy=3Dhistory, session, or header are = indeed forwarded to entities which belong to the same trust domain. The = removal of specific history-entries should only occur if the peer does = not belong to the trust domain. =20 In the current text (section 4.3.3.1.1) = :=20 If a request is being forwarded to a = Request URI associated with a domain for which the proxy is not = responsible and there is a Privacy header in the request with a = priv-value of "session", "header" or "history", the proxy MUST remove = any hi-entry(s) prior to forwarding.=20 =20 The current wording is misleading since = it gives the impression (maybe intentionnal) that it is not possible to = forward history-entries with Privacy statements to domains under the = responsability of e.g. another operator belonging to the same trust = domain. =20 =20 [MB]: Current wording is consistent with = terminology in RFC 3261 in terms of describing who is able to change the = Request URI in a specific request (based on section 16.5):=20 " A proxy MUST NOT add additional = targets to the target set if the=20 Request-URI of the original request = does not indicate a resource this=20 proxy is responsible for.=20 =20 A proxy can only change the = Request-URI of a request during=20 forwarding if it is responsible = for that URI. "=20 Since History-Info (and associated = privacy) are only added to the request, when an entity that is allowed = to change the Request-URI retargets the request, it seemed sensible to = use consistent wording to explain that. =20 [/MB]=20 [SG] I have no problem with the = statements above. My concern is that if there is a hi-entry already = embedded in the request with a Privacy statement, then, it should be up = to local policy to decide whether or not a proxy shall pass on those = hi-entries to a trusted domain. The sentence in section 4.3.3.1.1 = precludes this. I would propose to lighten the strenght of the sentence = as follows: =20 If a request is being forwarded to a = Request URI associated with a domain for which the proxy is not = responsible and there is a Privacy header in the request with a = priv-value of "session", "header" or "history", the proxy MAY remove any = hi-entry(s) prior to forwarding.=20 =20 [SG] Another issue is the decision to = add hi-entries in a privacy context. A proxy changing the target (i.e. = the proxy is responsible of the resource reflected in the received = Request-URI) of a request which contained a "privacy=3Dhistory" header = MAY add a history-entries provided that it knows it can rely on other = entities within the trust domain to apply the requested privacy. This = affect item 4 in the list on conditions of section 4.3.3 and 4.3.3.1.=20 =20 The concept of "trust domain" should be = used when discussing the forwarding rules pertaining to information = subject to privacy. Furthermore, the requirement for forwarding = history-entries to trusted entities should be stated more clearly in the = draft.=20 [MB]: = The whole concept of what defines privacy in terms of the proxy's use of = the privacy header is outside the scope of History-Info functionality = and really a matter of local policy. I think the functionality that = you want is a matter of local implementation and policy in terms of = operators establishing this "trust domain" model to which you refer. = History-Info defines the mechanism to ensure the privacy of the = requests, but it doesn't explicitly define how the proxy knows whether = it is responsible for that resource. I don't think this is a matter = of standardization. I thought the use of the term "domain" rather than = "resouce" would be helpful, but perhaps changing it to the more general = "resource" would resolve this concern and/or a statement clarifying what = I've just described should be added in the draft.=20 [/MB]=20 [SG] Changing the term "domain" to = "resource" does not solve the problem I mentionned above. In order to = reflect current operator requirements, the draft should not PRECLUDE the = fowarding of existing history information towards trusted domains. =20 Thank you for clarifying this point.=20 =20 Best regards,=20 s=E9bastien=20 =20 =20 ------Remainder of non-related part of = this thread has been deleted by Mary------------------ ------_=_NextPart_001_01C4C7FC.E9411EA2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Privacy statements and History = (draft-ietf-sip-history-info-04.txt)
Mary, Sebastien, Roland,
 
I agree that we should let the possibility for = a proxy not=20 to remove the hi-entry even if privacy is requested and even if the = request is=20 forwarded to a Request-URI associated with a domain for which the proxy = is not=20 responsible (if there is an agreement between = the domains=20 that ensures the proxy that privacy will be applied to the request).=20
I suggest a text that would look = like (in case=20 privacy is requested): "the hi-entry SHOULD be removed by the proxy = unless it=20 knows that it can rely on a downstream privacy service to apply the = requested=20 privacy ".
 
Sebastien.

De : sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] De la part de Mary=20 Barnes
Envoy=E9 : mercredi 10 novembre 2004=20 19:54
=C0 : GARCIN Sebastien RD-CORE-ISS; Jesske, R;=20 sip@ietf.org
Objet : RE: [Sip] Privacy statements and = History=20 (draft-ietf-sip-history-info-04.txt)

I still contend that the SHOULD is sufficient.  = SHOULD=20 means that in general processing, if the hi-entry has a privacy header, = then the=20 usual processing would be that it would be removed (i.e it was added for = a=20 specific reason and in general should be used to remove the entries = based on=20 well defined criteria).  If there are reasons, such as local = policy, that=20 would allow the forwarding in specific cases, then it's okay that it is=20 forwarded.  I think the use of MAY results in less precision and I = think=20 the value and critera for associating and removing the privacy header = with the=20 hi-entry becomes much less clear. 

I'd like to hear more opinions on this topic, prior to = agreeing=20 to making the change (from the MUST to MAY rather than MUST to SHOULD).=20

Regards,
Mary =


-----Original Message-----
From: GARCIN=20 Sebastien RD-CORE-ISS [mailto:sebastien.garci= n@francetelecom.com]=20
Sent: Wednesday, November 10, 2004 12:28 = PM=20
To: Barnes, Mary [NGC:B601:EXCH]; Jesske, R;=20 sip@ietf.org
Cc: = VL-T-Com-T-TE332@vli.telekom.de=20
Subject: RE: [Sip] Privacy statements and History=20 (draft-ietf-sip-history-info-04.txt)


Mary and roland,

Actually, the statement regarding the forwarding of = hi-entries=20 beyond the domain for which the proxy is responsible should rather be a = matter=20 of local policy and thus a MAY should be used instead of SHOULD. We are=20 potentially dealing with network boundaries where agreements for = forwarding such=20 kind information can be reached.

Section 4.3.3.1.1
This = section should be=20 re-reworded in accordance with the statement above (I can provide some = text is=20 we can agree).

Section 4.3.3.1 is ok (apologies for not being = explicit)=20

Best regards,
s=E9bastien=20



________________________________

De : Mary Barnes [mailto:mary.barnes@norteln= etworks.com]=20
Envoy=E9 : mercredi 10 novembre 2004 = 16:21=20
=C0 : 'Jesske, R'; GARCIN Sebastien RD-CORE-ISS;=20 sip@ietf.org
Cc : = VL-T-Com-T-TE332@vli.telekom.de=20
Objet : RE: [Sip] Privacy statements and History=20 (draft-ietf-sip-history-info-04.txt)


Roland and Sebastien,
 =20
I too agree with the proposal to change the strength = of the=20 referenced statement from section 4.3.3.1.1  from MUST to SHOULD. = This=20 change is consistent with the other normative statements in section = 4.3.3.1.1,=20 which are SHOULDs rather than MUSTs.   I'll make that change = in the=20 next rev unless someone raises concerns over that change.


On the second concern, I'm = not clear=20 what the proposed change is for the following:
[SG]=20 Another issue is the decision to add hi-entries in a privacy context. A = proxy=20 changing the target (i.e. the proxy is responsible of the resource = reflected in=20 the received Request-URI) of a request which contained a = "privacy=3Dhistory"=20 header MAY add a history-entries provided that it knows it can rely on = other=20 entities within the trust domain to apply the requested privacy. This = affect=20 item 4 in the list on conditions of section 4.3.3 and 4.3.3.1. =


Item 4 in section 4.3.3 = describes the=20 general situation, thus the strength (MAY) describes the general fact = that the=20 use of privacy is optional.  The normative text provided in = 4.3.3.1,=20 provides the general model for adding hi-entries, with the privacy = specific=20 considerations for adding the entries described in 4.3.3.1.1.  I = think what=20 you're suggesting is changing the strength of the following statement in = section=20 4.3.3.1:

" The hi-entry MUST be added following any hi-entry = received in=20 the request being forwarded."
I can see that = in the=20 context of privacy considerations, this might seem misleading.  = That MUST=20 was originally a SHOULD but was changed (as discussed on the list and at = IETF-60) to MUST based on issue JRE- 4, so a simple change of MUST to = MAY would=20 not at all work.  I thought it was clear from the statement at the=20 beginning of 4.3.3.1, that this section is describing the scenario under = which=20 the general privacy considerations had been evaluated and the intention = was to=20 add an hi-entry, thus the statements should be read in the context that = the=20 general screening indicates that an hi-entry SHOULD be added and if one = is added=20 it MUST be added following any entry that's already in the request to = preserve=20 the ordering.   If you have explicit changes to the text that = you=20 think would further clarify the functionality, we can discuss. =


Roland, if you have = specific text on=20 how I could incorporate a reference to RFC3323, we can consider that;=20 fundamentally any discussion of privacy depends on RFC 3323, so it's not = clear=20 to me how you were suggesting we incorporate such a reference.  The = text in=20 this document (history-info) should accurately describe the processing = impact of=20 the new "history" priv-value.


Thanks for your = input,
Mary

       =20         -----Original=20 Message-----
        From: Jesske, R [mailto:R.Jesske@t-com.net]=20
        Sent:=20 Wednesday, November 10, 2004 7:59 AM=20
        To:=20 sebastien.garcin@francetelecom.com; Barnes, Mary [NGC:B601:EXCH];=20 sip@ietf.org
        Cc: VL-T-Com-T-TE332@vli.telekom.de=20
        Subject: = AW: [Sip]=20 Privacy statements and History = (draft-ietf-sip-history-info-04.txt)=20
       =20
       =20
        Dear Mary = and=20 Sebastien,
        here are my Comments to Sebastien's statements:=20
        =20
        Your first=20 proposal I can accept from my point of view.=20
        On you = second issue=20 my impression is that this issue must be seen with regard to RFC3323 = where=20 privacy and the trust concept is described. Perhaps a reference to this = document=20 should be included.

        On your = last point, I=20 think we can also refer to RFC 3323.=20
        =20
        What are you=20 thinking? =
        
        Best=20 Regards
        =20
        Roland=20
         =

       =20          ---- = Mary snipped=20 forwarding info to keep message smaller----------- =20
       =20        =20
       =20        =20        =20        =20        =20        =20        =20         -----Original=20 Message-----
       =20        =20        =20         From: GARCIN = Sebastien=20 RD-CORE-ISS [mailto:sebastien.garci= n@francetelecom.com]=20
       =20        =20        =20         Sent: Monday, = November=20 08, 2004 10:11 AM
       =20        =20        =20         To: Barnes, = Mary=20 [NGC:B601:EXCH]; sip@ietf.org=20
       =20        =20        =20         Subject: [Sip] = Privacy=20 statements and History (draft-ietf-sip-history-info-04.txt)=20
       =20        =20        =20        =20
       =20        =20        =20        =20
       =20        =20        =20         Hi mary, = all=20
       =20        =20        =20         =20
       =20        =20        =20         When reading=20 draft-ietf-sip-history-info-04.txt, I have trouble in understanding some = of the=20 statements which relate to the forwarding rules for history-entries = subject to=20 privacy. It is an important requirement that History-entrie(s) with a=20 Privacy=3Dhistory, session, or header are indeed forwarded to entities = which=20 belong to the same trust domain. The removal of specific history-entries = should=20 only occur if the peer does not belong to the trust domain.

       =20        =20        =20         =20
       =20        =20        =20         In the current = text=20 (section 4.3.3.1.1) : =
       =20        =20        =20         If a request = is =20 being forwarded to a Request URI associated with a domain for which the = proxy is=20 not responsible and there is a Privacy header in the request with a = priv-value=20 of "session", "header" or "history", the proxy MUST remove any = hi-entry(s) prior=20 to forwarding.

       =20        =20        =20         =20
       =20        =20        =20         The current = wording is=20 misleading since it gives the impression (maybe intentionnal) that it is = not=20 possible to forward history-entries with Privacy statements to domains = under the=20 responsability of e.g. another operator belonging to the same trust=20 domain. 

       =20        =20        =20         =20
       =20        =20        =20         [MB]: Current = wording is=20 consistent with terminology in RFC 3261 in terms of describing who is = able to=20 change the Request URI in a specific request (based on section 16.5):=20

       =20        =20        =20            " = A proxy=20 MUST NOT add additional targets to the target set if the=20
       =20        =20        =20            = Request-URI=20 of the original request does not indicate a resource this=20
       =20        =20        =20            = proxy is=20 responsible for.
       =20        =20        =20        =20
       =20        =20        =20               A proxy can only change the = Request-URI of=20 a request during
       =20        =20        =20               forwarding if it is responsible = for that=20 URI. "
       =20        =20        =20         Since = History-Info (and=20 associated privacy) are only added to the request, when an entity that = is=20 allowed to change the Request-URI retargets the request, it seemed = sensible to=20 use consistent wording to explain that.  

       =20        =20        =20         [/MB]=20
       =20        =20        =20          [SG] I = have no=20 problem with the statements above. My concern is that if there is a = hi-entry=20 already embedded in the request with a Privacy statement, then, it = should be up=20 to local policy to decide whether or not a proxy shall pass on those = hi-entries=20 to a trusted domain. The sentence in section 4.3.3.1.1 precludes this. I = would=20 propose to lighten the strenght of the sentence as follows:

       =20        =20        =20         =20
       =20        =20        =20         If a request = is =20 being forwarded to a Request URI associated with a domain for which the = proxy is=20 not responsible and there is a Privacy header in the request with a = priv-value=20 of "session", "header" or "history", the proxy MAY remove any = hi-entry(s) prior=20 to forwarding.

       =20        =20        =20         =20
       =20        =20        =20         [SG] Another = issue is=20 the decision to add hi-entries in a privacy context. A proxy changing = the target=20 (i.e. the proxy is responsible of the resource reflected in the received = Request-URI) of a request which contained a "privacy=3Dhistory" header = MAY add a=20 history-entries provided that it knows it can rely on other entities = within the=20 trust domain to apply the requested privacy. This affect item 4 in the = list on=20 conditions of section 4.3.3 and 4.3.3.1.

       =20        =20        =20         =20
       =20        =20        =20         The concept of = "trust=20 domain" should be used when discussing the forwarding rules pertaining = to=20 information subject to privacy. Furthermore, the requirement for = forwarding=20 history-entries to trusted entities should be stated more clearly in the = draft.=20

       =20        =20        =20        =20        =20        =20        =20         [MB]: The = whole concept=20 of what defines privacy in terms of the proxy's use of the privacy = header is=20 outside the scope of History-Info functionality and really a matter of = local=20 policy.   I think the functionality that you want is a matter = of local=20 implementation and policy in terms of operators establishing this "trust = domain"=20 model to which you refer.  History-Info defines the mechanism to = ensure the=20 privacy of the requests, but it doesn't explicitly define how the proxy = knows=20 whether it is responsible for that resource.    I don't = think=20 this is a matter of standardization.  I thought the use of the term = "domain" rather than "resouce" would be helpful, but perhaps changing it = to the=20 more general "resource" would resolve this concern and/or a statement = clarifying=20 what I've just described should be added in the draft.

       =20        =20        =20         [/MB]=20
       =20        =20        =20         [SG]  =20 Changing the term "domain" to "resource" does not solve the problem I = mentionned=20 above. In order to reflect current operator requirements, the draft = should not=20 PRECLUDE the fowarding of existing history information towards trusted=20 domains.

       =20        =20        =20         =20
       =20        =20        =20         Thank you for = clarifying=20 this point.
       =20        =20        =20         =20
       =20        =20        =20         Best = regards,=20
       =20        =20        =20         s=E9bastien=20
       =20        =20        =20         =20
       =20        =20        =20          =

       =20        =20        =20         ------Remainder of=20 non-related part of this thread has been deleted by=20 Mary------------------


------_=_NextPart_001_01C4C7FC.E9411EA2-- --===============1025062005== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1025062005==-- From sip-bounces@ietf.org Thu Nov 11 17:48:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08460 for ; Thu, 11 Nov 2004 17:48:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSNle-0007xX-8t for sip-web-archive@ietf.org; Thu, 11 Nov 2004 17:50:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSNhu-0000tq-Sz; Thu, 11 Nov 2004 17:46:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSNWf-0005Zk-VR for sip@megatron.ietf.org; Thu, 11 Nov 2004 17:34:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07121 for ; Thu, 11 Nov 2004 17:34:43 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSNXv-0007Z5-Bc for sip@ietf.org; Thu, 11 Nov 2004 17:36:03 -0500 Received: from [130.129.132.245] ([130.129.132.245]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iABMYh7e006813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Nov 2004 16:34:44 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4193E902.7010206@nostrum.com> Date: Thu, 11 Nov 2004 16:34:42 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi References: <4193DAAC.3020609@nokia.com> In-Reply-To: <4193DAAC.3020609@nokia.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: SIP WG Subject: [Sip] Re: RLS and identity X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Aki Niemi wrote: > > Just a minor note on this: if/when mandating the support for asserted > identity in the event-list draft, please remember to say that > p-asserted identities also count (to some extent). Based on Rohan's suggestion, the text will effectively say: - Jon's Identity draft will be mandatory to implement, optional to use. - Other mechanisms that have properties such that they can adequately convey the identity of the subscriber and the permission of the RLS to subscribe on the user's behalf can also be used. If you think that your architecture, in combination with P-Asserted-Identity, satisfies the second bullet, then you're probably fine. However, I think it is a really bad idea to specifically include any mention of P-Asserted-Identity in the draft. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 11 17:58:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09320 for ; Thu, 11 Nov 2004 17:58:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSNuy-0008BH-5O for sip-web-archive@ietf.org; Thu, 11 Nov 2004 17:59:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSNjg-0001p4-1n; Thu, 11 Nov 2004 17:48:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSNff-0008UY-H6 for sip@megatron.ietf.org; Thu, 11 Nov 2004 17:44:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08090 for ; Thu, 11 Nov 2004 17:44:01 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSNgv-0007nv-2G for sip@ietf.org; Thu, 11 Nov 2004 17:45:21 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 11 Nov 2004 14:43:46 -0800 X-BrightmailFiltered: true Received: from vtg-um-e2k1.sj21ad.cisco.com (vtg-um-e2k1.cisco.com [171.70.93.55]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id iABMhQ9C019889; Thu, 11 Nov 2004 14:43:29 -0800 (PST) Received: from [128.107.171.12] ([128.107.171.12]) by vtg-um-e2k1.sj21ad.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 11 Nov 2004 14:43:28 -0800 Message-ID: <4193EB0F.1090003@cisco.com> Date: Thu, 11 Nov 2004 14:43:27 -0800 From: Charles Eckel Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" Subject: Re: [Sip] mib-08 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Nov 2004 22:43:28.0322 (UTC) FILETIME=[DCA08A20:01C4C83F] X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Cullen Jennings , Kevin Lingle , Steve Langstaff X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7bit Just a few recommended clarifications: sipStatsInbounds OBJECT-TYPE Description: should state excludes retransmissions sipStatsRetries OBJECT-TYPE Description: should replace "total number of INVITE retries" with "total number of request retransmissions, could be multiple per request" sipStatsRetryFinalResponses Description: should state there could be multiple per response Cheers, Charles Romascanu, Dan (Dan) wrote: > Steve, > > Actually implementation experience and interoperability is required only > when time comes to advance a standards track Proposed Standard to Draft > Standard phase. Although 'pre-standard' implementations are not > discouraged in I-D phase, one cannot ensure interoperable versions > before the standard, because the OID allocation for the root of the MIB > module under mib-2 is being performed by IANA only very late, prior to > the RFC publication. > > Whether the document will be a standards track, or not, is an IESG > decision based on the WG recommendation. > > Regards, > > Dan > > > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On > > Behalf Of Steve Langstaff > > Sent: 09 November, 2004 6:37 PM > > To: Kevin Lingle > > Cc: sip@ietf.org; Cullen Jennings > > Subject: RE: [Sip] mib-08 > > > > > > KL: "we need to move the I-D forward so we can get a RFC that > > can get some implementation experience." > > > > I thought that the I-D phase was the time to get the > > implementation experience. Is it your intention that the RFC > > will be "Experimental" or "Informational" before getting this > > implementation experience, and then become a standard afterwards? > > > > -- > > Steve Langstaff. > > > > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > > Kevin Lingle > > Sent: 08 November 2004 17:26 > > To: Cullen Jennings > > Cc: sip@ietf.org > > Subject: Re: [Sip] mib-08 > > [snip] > > > > we need to move the > > I-D forward so we can get a RFC that can get some implementation > > experience. > > > > kevin > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 11 18:11:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10935 for ; Thu, 11 Nov 2004 18:11:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSO75-0008Uc-6y for sip-web-archive@ietf.org; Thu, 11 Nov 2004 18:12:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSNxR-0002vJ-3n; Thu, 11 Nov 2004 18:02:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSNlY-0002l7-Js for sip@megatron.ietf.org; Thu, 11 Nov 2004 17:50:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08573 for ; Thu, 11 Nov 2004 17:50:06 -0500 (EST) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSNmo-0007yl-4R for sip@ietf.org; Thu, 11 Nov 2004 17:51:26 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iABMnZ907106 for ; Thu, 11 Nov 2004 17:49:35 -0500 (EST) Received: from [47.102.176.111] (archt0b1.us.nortel.com [47.102.176.111]) by zrtpd0jn.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id WKK5BMPD; Thu, 11 Nov 2004 17:49:35 -0500 Message-ID: <4193EC7C.8020009@nortelnetworks.com> Date: Thu, 11 Nov 2004 17:49:32 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Corey W. Alexander" User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: 7bit Subject: [Sip] -resource-priority-05.txt: Comments and Recommendations X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: 7bit This should spur some discussion... I'd rather send this directly to the authors, but to keep everything out in the open... I spoke briefly with Mr. Polk following the IEPREP session on Tuesday. I had three general questions. I'm paraphrasing the responses, and so invite James to correct me if I'm misrepresenting him here. 1. Why support multiple namespace/priority (n-p) values in a single message, in one or more R-P headers? And if supported, should not the n-p values in the message equate to the same priority level (for example, dsn.flash and q735.1 would be equal)? Would it not be better to support only one n-p value per message, and recommend that a proxy/gateway between networks supporting two different namespaces handle mapping n-p values? ---- There may be/are networks which would support multiple levels. The draft is not dictating that there must be multiple levels. ---- As for having the n-p levels be "equal", James cited a GETS call with a specific precedence which becomes a Routine call on the DSN. ---- Having a proxy/gateway mapped between namespaces is an viable alternative. 2. Is it wise or valid to explicitly allow a proxy to "upgrade" or "downgrade" the n-p values in a message? ---- I'm coming at this from the DSN perspective, but wps and/or ets may allow this kind of thing. While the DSN/DSRN/(Q735) would not, that does not invalidate the concept. 3. With "preferential treatment" of messages based on R-P content, should not scenarios be considered and listed in which a lower priority message would need to be handled before a higher priority message? My example: it would be wise to handle a BYE message with dsn.routine before an INVITE with dsn.flash-override... At least in certain situations, say when the BYE is sent as a result of a preemption event (which the Reason header should likely indicate). ---- Certainly something to consider, especially for DSN. Having witnessed the majority of the discussion on this draft in the final SIP session, and stepping back from the questions I had, it occurs to me that, while the information presented is not invalid, it is certainly confusing, to a varying degree. In my opinion, the confusion comes from trying to define (describe/outline, whatever) the behavior of the various namespaces, while at the same time intending to keep draft general, and the use of the R-P header open to those who implement it. Right before the comments on this draft were brought to a close, the thread was leading to there ultimately being independent documents which would describe the overall behavior of networks which implement one or more of these namespaces. RECOMMENDATION: Any namespace-specific behaviors should be relegated to documents specific to the namespaces themselves. For instance, there are currently a number of documents, and certainly other to come, dealing with the requirements/architecture/implementation of Assured Service (MLPP in IP): draft-baker-tsvwg-mlpp-that-works-02.txt draft-pierce-tsvwg-assured-service-req-01.txt draft-pierce-tsvwg-assured-service-arch-01.txt draft-pierce-tsvwg-pref-treat-examples-01.txt It is in documents like these - more specifically, documents specific to expected behaviors - where the use of the R-P header should ultimately be laid out. I would like to see the R-P draft limited to - a general description of what the header is: What is a namespace? What is the priority values mean? Why is it needed? Basically, background and definitions, but NOT explicit behaviors. - the format of the Resource-Priority header - 417 response code - error conditions --- If the R-P header is not supported: 420 --- If the n-p value is not supported or unknown: 417 *** This document does not have to define those circumstances in which each defined namespace considers the n-p value unsupported. - A MINIMUM number of namespaces. *** I would recommend providing only a single generic namespace, with 5, 6, whatever, priority values, and leave the actual namespace definitions (dsn, dsrn, ets, wps; and q735, if necessary) to documents specific to those namespaces/architectures. This would remove all of the confusion. No need to describe the behaviors expected with the current namespaces, let applications specific to the namespaces to that. Further, the document could then keep the strict, semi-strict, and loose mode concepts intact (or with modification) without interfering with existing behaviors in the current namespaces. New namespaces, when defined, can align themselves with these modes, or define their own behaviors. Finally, since preferential treatment of messages would likely find greater use outside of a private network than preemption, I would also recommend one more thing. If the suggestion of a single generic namespace in this draft is taken, behaviors surrounding the concept of preferential treatment should be included for this namespace. Digest and comment. -- Corey W. Alexander _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 12 04:03:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12339 for ; Fri, 12 Nov 2004 04:03:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSXM9-0002wa-1J for sip-web-archive@ietf.org; Fri, 12 Nov 2004 04:04:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSXJ7-0004Pj-JT; Fri, 12 Nov 2004 04:01:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSXIS-0004Hm-Tl for sip@megatron.ietf.org; Fri, 12 Nov 2004 04:00:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12210 for ; Fri, 12 Nov 2004 04:00:42 -0500 (EST) Received: from [62.119.82.41] (helo=mailserver.hotsip.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSXJc-0002m8-UW for sip@ietf.org; Fri, 12 Nov 2004 04:02:08 -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: [Sip] PING/PONG [bcc][faked-from][heur] [mx][spf] Date: Fri, 12 Nov 2004 10:00:01 +0100 Message-ID: Thread-Topic: [Sip] PING/PONG [bcc][faked-from][heur] [mx][spf] Thread-Index: AcTIH87aZFb0zvfKRHqmLOtBrFfPOwAcdlfw From: "Christian Jansson" To: "Spencer Dawkins" , "Christian Stredicke" X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable >From: Spencer Dawkins [mailto:spencer@mcsr-labs.org] > >OK, I'm still confused here. Please help me. > >The apparent choices include "Keep-alives for TCP should be CRLF >(default-interval TBD)". > >Sending keep-alives over TCP may be interesting, but I'm really >confused about what you think is a reasonable action when you send a >PING over TCP and don't get a PONG back. When sending the CRLF over TCP you should not get anything back if the connection is still there. If the TCP connection is down or fails while sending the CRLF on the other hand you will get a notice from your IP stack of the failure. Then that socket should be closed, and the UA may try to set up a new connection if wants to. > >If you change a status indicator on a user display that says "may have >lost connectivity", that's fine. If you try to retransmit requests, >I'm concerned. > >My definition of "reasonable" includes "don't send multiple new >packets into a network path that is not returning PONGs, when the >problem may be that the network path is losing packets because it is >already congested." Retransmitting requests requires exactly this >(tear down existing TCP connection, because it's still retransmitting, >open a new TCP connection, and then retransmit the request at the >application level). > >There is no way for the endpoints to know that loss is NOT due to >congestion, and putting TCP-based "lost packet multipliers" in place >in end systems that can't know they aren't facing congestion is not >something I'm comfortable with. I'm not sure how often keep-alives have to be sent over TCP to ensure that NAT/FWs do not remove the state. Preferabely NAT/FWs never remove the state, but I have heard that it happens. Does anyone have a reference to test statistics of NAT/FWs behavior? The keep-alive default interval should probably be set just below the shortest of all detected values. My guess is that the value will be around 5 minutes. Sending a TCP packet with CRLF every 5 minutes can't really be a big source for congestion. The keep-alives would also not be sent if any other traffic had been sent to or from the UA.=20 > >If TCP isn't the right answer, using TCP and sending multiple new TCP >packets when a connection won't PING/PONG isn't helpful. Given that the keep-alives are spaced with a couple of minutes, and that this interval is much greater than the TCP error timeouts, I do not see the problem. If those keep-alives would have been sent every 10 seconds I would have agreed on the problems you describe. / 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 sip-bounces@ietf.org Fri Nov 12 08:19:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29539 for ; Fri, 12 Nov 2004 08:19:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSbM6-00083A-8m for sip-web-archive@ietf.org; Fri, 12 Nov 2004 08:20:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSbGQ-0000td-6H; Fri, 12 Nov 2004 08:14:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSbBO-0000Gi-Dd for sip@megatron.ietf.org; Fri, 12 Nov 2004 08:09:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28704 for ; Fri, 12 Nov 2004 08:09:40 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSbCj-0007pS-TR for sip@ietf.org; Fri, 12 Nov 2004 08:11:08 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 12 Nov 2004 05:21:20 -0800 Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iACD95n0010403; Fri, 12 Nov 2004 05:09:05 -0800 (PST) Received: from [130.129.135.140] (sjc-vpn1-252.cisco.com [10.21.96.252]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFR86543; Fri, 12 Nov 2004 05:08:59 -0800 (PST) Message-ID: <4194B5EC.1050202@cisco.com> Date: Fri, 12 Nov 2004 08:09:00 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings , Jon Peterson , sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ba0ec39a747b7612d6a8ae66d1a873c Content-Transfer-Encoding: 7bit Subject: [Sip] comments on sipping-certs X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10dcc25e55b9b5f7d6ded516404bdc4c Content-Transfer-Encoding: 7bit Cullen, Jon Some comments on the sipping-certs draft. The document is in need of a picture that shows the overall architecture - something along the lines of a protocol model as described in: http://www.ietf.org/internet-drafts/draft-iab-model-02.txt I'd suggest that the picture show the credential server, identity service, and clients on both sides, along with a single section overviewing operation. One technical aspect of this bothered me. My understanding is that the NOTIFY from the credential server containing the cert has to be signed by an identity service in order to provide an indentity binding to the cert. However, in this case, the notification is *not* sent by the user in the From/identity field! It is sent by an entity which is authorized to send requests for that identity, and is going to have a tight trust relationship with the authentication service. The spec is quite loose with terminology; I point out some of these below, but it needs a careful scrub in this area. You need to formally define the various event packages you are using. I would suggest aligning the package names with the terminology you are using (i.e., a credential and certificate package). Generally, a lot of details are needed in various places. It reads much like a proposal and needs to move on to become a protocol specification. I think section 7 and 10.2 are out of scope. This is a fairly orthogonal piece of work that treats how offer/answers are done using s/mime. It does not appear to depend at all on the fact that the certificates were obtain through the mechanism in this draft. section 11.1 is out of place. It belongs in a section that defines client behavior for obtained a cert. also, thinking about this, it seems to me that the mechanism is susceptible to SBCs, which would be able to tap into the media stream. They would do this by handing out a different cert to subcsribers than the one you hand it. Then, any encrypted media for you comes to the SBC, which decrypts and re-encrypts with your key. Badness. Might want to mention this in the security considerations section, and recommend that a UA subscribe to its own cert using a different identity in order to verify that the proper cert is being handed out. detailed comments: > SIP provides a mechanism for end to end encryption and integrity > using S/MIME, s/end to end/end-to-end > S/MIME has not been widely implemented or deployed due to the > complexity of providing a reasonable certificate distribution > infrastructure. This is a bold statement; there are many reasons, of which this is one. > Combined with the Identity [2] work, this work allows users to have > certificates that are not signed by any well known certificate s/work/specification > This mechanism allows UAs such as IP phones to enroll > and get their credentials without any more configuration information > than they commonly have today, without any extra effort or key clicks > by the end user, and without any extra expense for the end user. this is one long run on sentence > This mechanism also lets the UA discover and retrieve the public > certificate for any other user and find out about certificate > revocations. worth noting that it actually provides more than this; its not just users, but any resource associated with an AOR. > The general approach is to provide a new SIP service referred to as a > Credential Server that allows UAs to subscribe to some other user's > certificate. a server provides a service, it isn't a service > The identity of the certificate can be vouched for > using Identity [2] work, which uses the domain's certificate to sign > that the NOTIFY really is from the Credential server for the request > user in that domain. This is not true. The signature does not verify this; the signature verifies that the request came from a server that has access to the domain keys. > The Credential Service can manage public > certificates as well as credentials that include the user's private you sometimes use credential service, sometimes credential server also, this text is confusing since credentials apparently contain certificates according to your definition. So, saying that they manage certifications *as well as* private keys is redundant > The Credential Server authenticates UAs that > are changing credentials or requesting private keys using a shared > secret that both the UA and the Server know. in this sentence, it is not obvious that "using a shared secret" applies to both changing credentials and requesting private keys. Also, my understanding is that you would request credentials as well, not just the private key (i.e., there is no way to get just one) > Typically this will be > the same shared secret that is used in Register with the Registrar > for the domain. s/Register/REGISTER > The mechanism described in this document works for both self signed > certificates and certificates signed by a well known certificate > authority; you just said that in the preceding paragraph > Previous versions of this work proposed using HTTP instead of SIP for > communicating with the Credential Server. this needs to be changed now generally, on its way to an rfc, it needs to become less conversational, statements like "this work" and "previous versions" need to go > The key difference with > using SIP is that a certificate can be revoked by sending a new > NOTIFY; in the HTTP based scheme, the certificates were cached for a > predefined period of time, typically one day, so that a revocation > could take effect only after the cache had expired. there are other differences too, i mentioned some of the benefits of presence integration. Its a good idea to compare the pros and cons now that http becomes optional. also the text is confusing because the certificate can also be revoked in sip by having it expire > 2. Conventions change to definitions > The certificates discussed in this draft are generally self signed > and use the mechanisms in the Identity work [2] to vouch for their > validity. the "work" thing again > 3. Goals > > This work allows S/MIME to be used to meet the following goals and > requirements: I think this section needs to become the introduction. Furthermore, much of the introduction is sort of a weak overview of operation. You should move that text into a stronger overview of operation section. > Not require any efforts (zero clicks) on behalf of an end user to > acquire and start using end to end security. s/efforts/effort s/end to end/end-to-end > Not require any extra cost on a per user basis in deploying > systems that support this. It does require that the domain have a > web server style certificate that is either self signed or signed > by a well known CA. this is clearly false; I'll require incremental CPU for each user to process subscriptions for their cert, and incremental storage. > Allow negotiation of E2E encrypted SRTP sessions. please use end-to-end consistently > Allow end to end encryption and integrity of SIP bodies that may > be delivered in SIP signaling, such as page mode MESSAGEs or > NOTIFY bodies in presence. integrity? i usually think of signature as the way we provide integrity, and the certs mechanism isn't used for that hmm. if you want to encrypt presence documents in NOTIFY, what uri do you use to get the certificate? is it the identity used in the subscription, or the gruu in the contact? should a credential server support subscriptiosn to gruu to get certificates? > Allow end to end encryption and integrity of SIP bodies that may > be delivered in SIP signaling, such as page mode MESSAGEs or > NOTIFY bodies in presence. i had to read this a few times to realize you were talking about the case where a user wants to discover someone elses certificate; since a certificate is included in the credential i initially found this confusing > If the identity asserted by the Authentication Service > does not match the identity requests, t what are "identitiy requests"? in this section, you need to say more. discuss when a ua might initiate the subscription, how long it will hold it. Need ot mention the keepalive issue. Also mention that these subscriptions won't generally be challenged. > which will result in a message containing both an > application/pkix-cert body and an application/pkcs8 body that has the > associated private key information for the certificate. I think you mean that the notifications will contain bodies of this type. > credential that contains both an > application/pkix-cert and an application/pkcs8 body. MUST contain > may be configured with a specific name for the Credential Server; > otherwise it defaults to the name of the domain in the User's AOR. is this a new dns usage? I think you mean that we do rfc3263 resolutionon a sip uri > The TLS connection MUST present a certificate that matches the > expected name for the credential server, so that the UA knows it is > talking to the correct server. this is not detailed enough. anyway i think it is covered in rfc3261, you should reference that section 6 blends together a discussion of handling of credentials and certs. For example, it is unclear from the last paragraph on page 5 whether or not the server digest challenges requests for certs (it should not) > Otherwise it sets up a subscription and forms a NOTIFY with the > certificate in the body and the From header field value set to the > request URI of the SUBSCRIBE. how does this work if the request is proxied or retargeted in any way? > It MUST send this NOTIFY through an > Authentication Service (as described in Identity [2]) or implement an > Authentication Service itself. it can't just do that; the notifies are sent within the dialog. The subscribe request has to be routed through the authentication service. > When a Credential Server receives a SUBSCRIBE for a credential, the > Server has to authenticate and authorize the UA and validate that > adequate transport security is being used. how is authorization done? > Once the UA has authenticated with the Server, the Server can set up > a subscription and send a Notify message that MUST contain the > credentials. This NOTIFY message is sent thought an Authorization > Service in the same way as the certificate subscriptions. s/thought/through authorization service? perhaps authentication > Next Alice sends a SIP MESSAGE message to Bob and can encrypt the > body using Bob's public key as shown below. Thought outside the > scope of this document, it is worth noting that IM messages often s/thought/though > Likewise, the authentication > of the user submitting the private key should be equivalent to or > higher than the key being transmitted. its going to be digest; i'm not sure what this means > If a UA receives a > certificate in a TLS connection that it cannot chain back to a well > known CA but is otherwise valid (i.e. a self signed certificate), it > MAY ask the user if it wishes to allow this certificate to be used, why should we allow this? seems like a recipe for trouble > If a particular credential needs to be revoked, the new credential is > simply published to the Credential Server. Every device keeping this > current in its cache will have a subscription to the credential and this current? i think you mean the credential that was just revoked > certificate for the identity in the Original URI. This means that > the certificate should only be indexed in the certificate cache by > the value of the original URI, not by the value of all the > identities found in the SubjectAltName list. that said, i think the cert should be a valid standalone cert. i think we should require, at should or possibly must, that the subjectaltname match the identity that the authentication service will assert for that user. You need a section on generating self-signed certs, i think. > The Authentication Service validates > that this message did come from the identity claimed in the From and it won't though; it will come from the credential service which cannot claim it is the identity in the from > Only the UA that can authenticate as this user can tamper with this > body, so the owner of the identity can provide a false public key but > other users cannot. or the authentication service itself, or anything with the private domain keys -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 12 10:08:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09769 for ; Fri, 12 Nov 2004 10:08:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSd3X-00029K-Kq for sip-web-archive@ietf.org; Fri, 12 Nov 2004 10:09:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CScsy-0005gM-TN; Fri, 12 Nov 2004 09:58:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CScop-0004m2-Lv for sip@megatron.ietf.org; Fri, 12 Nov 2004 09:54:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08183 for ; Fri, 12 Nov 2004 09:54:29 -0500 (EST) From: Mpierce1@aol.com Received: from imo-m26.mx.aol.com ([64.12.137.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CScqD-0001po-Ph for sip@ietf.org; Fri, 12 Nov 2004 09:55:58 -0500 Received: from Mpierce1@aol.com by imo-m26.mx.aol.com (mail_out_v37_r3.8.) id d.84.3854d538 (4340); Fri, 12 Nov 2004 09:53:52 -0500 (EST) Message-ID: <84.3854d538.2ec62880@aol.com> Date: Fri, 12 Nov 2004 09:53:52 EST Subject: Re: [Sip] -resource-priority-05.txt: Comments and Recommendations (1) To: coreya@nortelnetworks.com, sip@ietf.org MIME-Version: 1.0 X-Mailer: 6.0 for Windows XP sub 10500 X-Spam-Score: 0.3 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0563813796==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 --===============0563813796== Content-Type: multipart/alternative; boundary="part1_84.3854d538.2ec62880_boundary" --part1_84.3854d538.2ec62880_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Corey, Thanks for the great analysis of the situation and the suggestions. I agree almost completely with what you suggested. I'll follow this up with a few minor points on your suggestions. But first, some comments on your questions, which might help understand why this approach was taken. In a message dated 11/11/2004 6:12:39 PM Eastern Standard Time, coreya@nortelnetworks.com writes: > 1. Why support multiple namespace/priority (n-p) values in a single > message, in one or more R-P headers? And if supported, should not the > n-p values in the message equate to the same priority level (for > example, dsn.flash and q735.1 would be equal)? Would it not be better > to support only one n-p value per message, and recommend that a > proxy/gateway between networks supporting two different namespaces > handle mapping n-p values? > ---- There may be/are networks which would support multiple levels. The > draft is not dictating that there must be multiple levels. > ---- As for having the n-p levels be "equal", James cited a GETS call > with a specific precedence which becomes a Routine call on the DSN. > ---- Having a proxy/gateway mapped between namespaces is an viable > alternative. > While it is a little hard to describe specific cases for the use of multiple namespaces, I believe it could be used, such as a GETS call originated in a military network that normally uses only the dsn namespace. The caller, knowing that the call will likely go outside the dsn, might be able to specify both dsn=flash and ETS=3. It is not possible to say that they "equal", since they are two separately defined lists of priorities which have no direct relationship. In one application, only the dsn namespace would have an effect while the call remains within the private network (DOD) for which it was defined. When the call gets to a PSTN gateway to jump into the "public" network, the dsn namespace/priority is discarded, since the "public" network does not support it. At the GW, the ETS namespace/priority is converted to the appropriate PSTN signaling which that netwrok supports. Note that in this case, the PSTN signaling does not have any further signaling of this value beyond the initial call setup message, which is why the SIP signaling would not include this R-P header in anything beyond the INVITE. When an ETS call from the public network enters the dsn, it could be mapped to Routine or to some higher priority level if the PSTN signaling provided that information. That will be determine by the administrator of the network and what the GW is told to do. It certainly can't be defined in the R-P header draft. Another application is a gateway between two networks which each use the R-P header but with different definitions. Lets say between the US DOD network with 5 values and another country's military network when that other country uses only 3 levels. The GW must map between the two sets according to a mutually agreed mapping. In each network, only one R-P header is used. I believe it was agreed long ago that the R-P header draft should not try to define the interoperation/mapping between different namespaces. I think this approach should remain, since any attempt to define relationships would be overly complex and may conflict with what network operators want to do. The first example above, with two namespaces being carried, is the reason why the required mode of operation in the dsn is that unknown namespaces are simply ignored and passed on. Known namespaces with unknown priorities need to be treated as errors, but not necessarily by failing a call. Mike Pierce Artel --part1_84.3854d538.2ec62880_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Corey,

Thanks for the great analysis of the situation and the suggestions. I ag= ree almost completely with what you suggested. I'll follow this up with a fe= w minor points on your suggestions. But first, some comments on your questio= ns, which might help understand why this approach was taken.

In a message dated 11/11/2004 6:12:39 PM Eastern Standard Time, coreya@n= ortelnetworks.com writes:


1. Why support multiple nam= espace/priority (n-p) values in a single=20
message, in one or more R-P headers?  And if supported, should not=20= the=20
n-p values in the message equate to the same priority level (for=20
example, dsn.flash and q735.1 would be equal)?  Would it not be bet= ter=20
to support only one n-p value per message, and recommend that a=20
proxy/gateway between networks supporting two different namespaces=20
handle mapping n-p values?
---- There may be/are networks which would support multiple levels. &nbs= p;The=20
draft is not dictating that there must be multiple levels.
---- As for having the n-p levels be "equal", James cited a GETS call=20
with a specific precedence which becomes a Routine call on the DSN.
---- Having a proxy/gateway mapped between namespaces is an viable=20
alternative.



While it is a little hard to describe specific cases for the use of mult= iple namespaces, I believe it could be used, such as a GETS call originated=20= in a military network that normally uses only the dsn namespace. The caller,= knowing that the call will likely go outside the dsn, might be able to spec= ify both dsn=3Dflash and ETS=3D3. It is not possible to say that they "equal= ", since they are two separately defined lists of priorities which have no d= irect relationship. In one application, only the dsn namespace would have an= effect while the call remains within the private network (DOD) for which it= was defined. When the call gets to a PSTN gateway to jump into the "public"= network, the dsn namespace/priority is discarded, since the "public" networ= k does not support it. At the GW, the ETS namespace/priority is converted to= the appropriate PSTN signaling which that netwrok supports. Note that in th= is case, the PSTN signaling does not have any further signaling of this valu= e beyond the initial call setup message, which is why the SIP signaling woul= d not include this R-P header in anything beyond the INVITE.

When an ETS call from the public network enters the dsn, it could be map= ped to Routine or to some higher priority level if the PSTN signaling provid= ed that information. That will be determine by the administrator of the netw= ork and what the GW is told to do. It certainly can't be defined in the R-P=20= header draft.

Another application is a gateway between two networks which each use the= R-P header but with different definitions. Lets say between the US DOD netw= ork with 5 values and another country's military network when that other cou= ntry uses only 3 levels. The GW must map between the two sets according to a= mutually agreed mapping. In each network, only one R-P header is used.

I believe it was agreed long ago that the R-P header draft should not tr= y to define the interoperation/mapping between different namespaces. I think= this approach should remain, since any attempt to define relationships woul= d be overly complex and may conflict with what network operators want to do.

The first example above, with two namespaces being carried, is the reaso= n why the required mode of operation in the dsn is that unknown namespaces a= re simply ignored and passed on. Known namespaces with unknown priorities ne= ed to be treated as errors, but not necessarily by failing a call.

Mike Pierce
Artel
--part1_84.3854d538.2ec62880_boundary-- --===============0563813796== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0563813796==-- From sip-bounces@ietf.org Fri Nov 12 10:17:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11422 for ; Fri, 12 Nov 2004 10:17:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSdCd-0002Ps-RF for sip-web-archive@ietf.org; Fri, 12 Nov 2004 10:19:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSd50-0003ob-Sa; Fri, 12 Nov 2004 10:11:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSd0I-0001Ww-5f for sip@megatron.ietf.org; Fri, 12 Nov 2004 10:06:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09501 for ; Fri, 12 Nov 2004 10:06:19 -0500 (EST) Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSd1g-000260-7j for sip@ietf.org; Fri, 12 Nov 2004 10:07:48 -0500 Received: from dfnjgl21 (unknown[130.129.135.144]) by comcast.net (rwcrmhc11) with SMTP id <2004111215054001300rnabbe>; Fri, 12 Nov 2004 15:05:41 +0000 Message-ID: <08c101c4c8c9$31df8390$90878182@DFNJGL21> From: "Spencer Dawkins" To: "Christian Jansson" , "Christian Stredicke" References: Subject: Re: [Sip] PING/PONG [bcc][faked-from][heur] [mx][spf] Date: Fri, 12 Nov 2004 10:06:30 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Spencer Dawkins List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: 7bit Hi, Christian (J), Ah, your note was very helpful. thank you for continuing to follow up when we weren't together yet. I've been responding to a vague uneasy feeling, and this note helped me understand my own concerns. The behavior of applications potentially attempting to set up TCP connections very aggressively is what concerns me. Think, "close the connection, wait some minimal period of time before trying to reopen it, what's the minimum period of time, and is there a backoff at the application level?" I would be concerned about large numbers of clients reopening TCP connections through a NAT (for instance) trying to restart. I agree with the rest of what we're talking about here. Spencer ----- Original Message ----- From: "Christian Jansson" To: "Spencer Dawkins" ; "Christian Stredicke" Cc: Sent: Friday, November 12, 2004 4:00 AM Subject: RE: [Sip] PING/PONG [bcc][faked-from][heur] [mx][spf] >From: Spencer Dawkins [mailto:spencer@mcsr-labs.org] > >OK, I'm still confused here. Please help me. > >The apparent choices include "Keep-alives for TCP should be CRLF >(default-interval TBD)". > >Sending keep-alives over TCP may be interesting, but I'm really >confused about what you think is a reasonable action when you send a >PING over TCP and don't get a PONG back. When sending the CRLF over TCP you should not get anything back if the connection is still there. If the TCP connection is down or fails while sending the CRLF on the other hand you will get a notice from your IP stack of the failure. Then that socket should be closed, and the UA may try to set up a new connection if wants to. > >If you change a status indicator on a user display that says "may >have >lost connectivity", that's fine. If you try to retransmit requests, >I'm concerned. > >My definition of "reasonable" includes "don't send multiple new >packets into a network path that is not returning PONGs, when the >problem may be that the network path is losing packets because it is >already congested." Retransmitting requests requires exactly this >(tear down existing TCP connection, because it's still >retransmitting, >open a new TCP connection, and then retransmit the request at the >application level). > >There is no way for the endpoints to know that loss is NOT due to >congestion, and putting TCP-based "lost packet multipliers" in place >in end systems that can't know they aren't facing congestion is not >something I'm comfortable with. I'm not sure how often keep-alives have to be sent over TCP to ensure that NAT/FWs do not remove the state. Preferabely NAT/FWs never remove the state, but I have heard that it happens. Does anyone have a reference to test statistics of NAT/FWs behavior? The keep-alive default interval should probably be set just below the shortest of all detected values. My guess is that the value will be around 5 minutes. Sending a TCP packet with CRLF every 5 minutes can't really be a big source for congestion. The keep-alives would also not be sent if any other traffic had been sent to or from the UA. > >If TCP isn't the right answer, using TCP and sending multiple new TCP >packets when a connection won't PING/PONG isn't helpful. Given that the keep-alives are spaced with a couple of minutes, and that this interval is much greater than the TCP error timeouts, I do not see the problem. If those keep-alives would have been sent every 10 seconds I would have agreed on the problems you describe. / 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 sip-bounces@ietf.org Fri Nov 12 10:55:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14459 for ; Fri, 12 Nov 2004 10:55:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSdne-0003D8-8L for sip-web-archive@ietf.org; Fri, 12 Nov 2004 10:57:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSdf6-0005i3-B8; Fri, 12 Nov 2004 10:48:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSdRo-0002oQ-Ot; Fri, 12 Nov 2004 10:34:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13033; Fri, 12 Nov 2004 10:34:46 -0500 (EST) Received: from amer-mta02.csc.com ([20.137.2.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSdTB-0002ni-9b; Fri, 12 Nov 2004 10:36:15 -0500 Received: from csc.com (va-fch34.csc.com [20.6.39.227]) by amer-mta02.csc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id iACFYTrR003410; Fri, 12 Nov 2004 10:34:35 -0500 (EST) Subject: Re: [Sip] -resource-priority-05.txt: Comments and Recommendations (1) To: Mpierce1@aol.com X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Janet P Gunn Date: Fri, 12 Nov 2004 10:32:59 -0500 X-MIMETrack: Serialize by Router on VA-FCH34/SRV/CSC(Release 6.0.3|September 26, 2003) at 11/12/2004 10:35:26 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: sip@ietf.org, sip-bounces@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Multiple namespaces. It is highly likely that an NS/EP (National Security/Emergency Preparedness) call will carry both the ets and wps namespaces. This is because you can not determine ahead of time whether the call will progress to a WIRELINE gateway (in which case the mapping associated with the ets namespace is needed) or to a WIRELESS gateway (in which case the mapping associated with the wps namespace is needed). We initially tired to define a single namespace that would work for both situations, but were unable to, given the constraints on namespace structure. There is also the POSSIBILITY of a call (within one of the military networks) carrying both the ets namespace and one of the MLPP based namespaces (especially a call that is expected to terminate on the Public network where the MLPP based namespace could be dropped while the ets namespace is retained). But this situation is still hypothetical. 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. ---------------------------------------------------------------------------------------- Mpierce1 @aol.com To: coreya@nortelnetworks.com, sip@ietf.org Sent by: cc: sip-bounces Subject: Re: [Sip] -resource-priority-05.txt: Comments and Recommendations (1) 11/12/2004 09:53 AM Corey, Thanks for the great analysis of the situation and the suggestions. I agree almost completely with what you suggested. I'll follow this up with a few minor points on your suggestions. But first, some comments on your questions, which might help understand why this approach was taken. In a message dated 11/11/2004 6:12:39 PM Eastern Standard Time, coreya@nortelnetworks.com writes: 1. Why support multiple namespace/priority (n-p) values in a single message, in one or more R-P headers? And if supported, should not the n-p values in the message equate to the same priority level (for example, dsn.flash and q735.1 would be equal)? Would it not be better to support only one n-p value per message, and recommend that a proxy/gateway between networks supporting two different namespaces handle mapping n-p values? ---- There may be/are networks which would support multiple levels. The draft is not dictating that there must be multiple levels. ---- As for having the n-p levels be "equal", James cited a GETS call with a specific precedence which becomes a Routine call on the DSN. ---- Having a proxy/gateway mapped between namespaces is an viable alternative. While it is a little hard to describe specific cases for the use of multiple namespaces, I believe it could be used, such as a GETS call originated in a military network that normally uses only the dsn namespace. The caller, knowing that the call will likely go outside the dsn, might be able to specify both dsn=flash and ETS=3. It is not possible to say that they "equal", since they are two separately defined lists of priorities which have no direct relationship. In one application, only the dsn namespace would have an effect while the call remains within the private network (DOD) for which it was defined. When the call gets to a PSTN gateway to jump into the "public" network, the dsn namespace/priority is discarded, since the "public" network does not support it. At the GW, the ETS namespace/priority is converted to the appropriate PSTN signaling which that netwrok supports. Note that in this case, the PSTN signaling does not have any further signaling of this value beyond the initial call setup message, which is why the SIP signaling would not include this R-P header in anything beyond the INVITE. When an ETS call from the public network enters the dsn, it could be mapped to Routine or to some higher priority level if the PSTN signaling provided that information. That will be determine by the administrator of the network and what the GW is told to do. It certainly can't be defined in the R-P header draft. Another application is a gateway between two networks which each use the R-P header but with different definitions. Lets say between the US DOD network with 5 values and another country's military network when that other country uses only 3 levels. The GW must map between the two sets according to a mutually agreed mapping. In each network, only one R-P header is used. I believe it was agreed long ago that the R-P header draft should not try to define the interoperation/mapping between different namespaces. I think this approach should remain, since any attempt to define relationships would be overly complex and may conflict with what network operators want to do. The first example above, with two namespaces being carried, is the reason why the required mode of operation in the dsn is that unknown namespaces are simply ignored and passed on. Known namespaces with unknown priorities need to be treated as errors, but not necessarily by failing a call. Mike Pierce Artel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 12 16:13:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24734 for ; Fri, 12 Nov 2004 16:13:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSilD-0006KS-Af for sip-web-archive@ietf.org; Fri, 12 Nov 2004 16:15:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSiUQ-00021b-OZ; Fri, 12 Nov 2004 15:57:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CShwt-0001dC-2w for sip@megatron.ietf.org; Fri, 12 Nov 2004 15:23:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11258 for ; Fri, 12 Nov 2004 15:23:09 -0500 (EST) From: Mpierce1@aol.com Received: from imo-d05.mx.aol.com ([205.188.157.37]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CShyH-0001nK-DL for sip@ietf.org; Fri, 12 Nov 2004 15:24:40 -0500 Received: from Mpierce1@aol.com by imo-d05.mx.aol.com (mail_out_v37_r3.8.) id c.1ca.2ca0df9e (4552); Fri, 12 Nov 2004 15:22:31 -0500 (EST) Message-ID: <1ca.2ca0df9e.2ec67586@aol.com> Date: Fri, 12 Nov 2004 15:22:30 EST Subject: Re: [Sip] -resource-priority-05.txt: Comments and Recommendations (1) To: An.Nguyen@ncs.gov, coreya@nortelnetworks.com, sip@ietf.org MIME-Version: 1.0 X-Mailer: 6.0 for Windows XP sub 10500 X-Spam-Score: 0.9 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0710082319==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da --===============0710082319== Content-Type: multipart/alternative; boundary="part1_1ca.2ca0df9e.2ec67586_boundary" --part1_1ca.2ca0df9e.2ec67586_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 11/12/2004 11:58:14 AM Eastern Standard Time, An.Nguyen@ncs.gov writes: > Can we just add a sentence to the draft saying mapping between namespaces > is out of scope and it should be addressed separately? Yes, such a statement would be fine, but it should be along with a statement that all interrelationship between namespaces is out of scope. Mike --part1_1ca.2ca0df9e.2ec67586_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message=20= dated 11/12/2004 11:58:14 AM Eastern Standard Time, An.Nguyen@ncs.gov writes= :


Can we just add a senten= ce to the draft saying mapping between namespaces is out of scope and it sho= uld be addressed separately?
Yes, such a statement would be fine, but it should be along with a state= ment that all interrelationship between namespaces is out of scope.

Mike
--part1_1ca.2ca0df9e.2ec67586_boundary-- --===============0710082319== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0710082319==-- From sip-bounces@ietf.org Fri Nov 12 19:35:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15478 for ; Fri, 12 Nov 2004 19:35:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSluD-0000tZ-2V for sip-web-archive@ietf.org; Fri, 12 Nov 2004 19:36:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSlqh-0006Dp-Lc; Fri, 12 Nov 2004 19:33:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSlp8-0005nQ-EV for sip@megatron.ietf.org; Fri, 12 Nov 2004 19:31:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15308 for ; Fri, 12 Nov 2004 19:31:22 -0500 (EST) From: Mpierce1@aol.com Received: from imo-m27.mx.aol.com ([64.12.137.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSlqa-0000kH-St for sip@ietf.org; Fri, 12 Nov 2004 19:32:58 -0500 Received: from Mpierce1@aol.com by imo-m27.mx.aol.com (mail_out_v37_r3.8.) id d.19d.2bd091f1 (16335); Fri, 12 Nov 2004 19:30:47 -0500 (EST) Message-ID: <19d.2bd091f1.2ec6afb7@aol.com> Date: Fri, 12 Nov 2004 19:30:47 EST Subject: Re: [Sip] -resource-priority-05.txt: Comments and Recommendations (2) To: coreya@nortelnetworks.com, sip@ietf.org MIME-Version: 1.0 X-Mailer: 6.0 for Windows XP sub 10500 X-Spam-Score: 0.8 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0517376043==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 --===============0517376043== Content-Type: multipart/alternative; boundary="part1_19d.2bd091f1.2ec6afb7_boundary" --part1_19d.2bd091f1.2ec6afb7_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 11/11/2004 6:12:39 PM Eastern Standard Time, coreya@nortelnetworks.com writes: > 2. Is it wise or valid to explicitly allow a proxy to "upgrade" or > "downgrade" the n-p values in a message? > ---- I'm coming at this from the DSN perspective, but wps and/or ets may > allow this kind of thing. While the DSN/DSRN/(Q735) would not, that > does not invalidate the concept. > If one understands the "proxy" to be the entity which provides call processing logic and which validates the calling party's authority to use the priority level which they signaled in the INVITE (see draft-pierce-tsvwg-assured-service-arch-01), then it should be valid for that proxy to "downgrade" the signaled value to the level allowed for that user before forwarding the INVITE rather than blocking the call. This behavior should not be disallowed by the R-P header draft for any namespace. I can't think of any "upgrading" case, but there is not reason for the R-P header draft to disallow it. Mike Pierce Artel --part1_19d.2bd091f1.2ec6afb7_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message=20= dated 11/11/2004 6:12:39 PM Eastern Standard Time, coreya@nortelnetworks.com= writes:


2. Is it wise or valid to e= xplicitly allow a proxy to "upgrade" or=20
"downgrade" the  n-p values in a message?
---- I'm coming at this from the DSN perspective, but wps and/or ets may= =20
allow this kind of thing.  While the DSN/DSRN/(Q735) would not, tha= t=20
does not invalidate the concept.



If one understands the "proxy" to be the entity which provides call proc= essing logic and which validates the calling party's authority to use the pr= iority level which they signaled in the INVITE (see draft-pierce-tsvwg-assur= ed-service-arch-01), then it should be valid for that proxy to "downgrade" t= he signaled value to the level allowed for that user before forwarding the I= NVITE rather than blocking the call. This behavior should not be disallowed=20= by the R-P header draft for any namespace.

I can't think of any "upgrading" case, but there is not reason for the R= -P header draft to disallow it.

Mike Pierce
Artel --part1_19d.2bd091f1.2ec6afb7_boundary-- --===============0517376043== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0517376043==-- From sip-bounces@ietf.org Sat Nov 13 11:24:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15509 for ; Sat, 13 Nov 2004 11:24:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CT0id-00072t-BB for sip-web-archive@ietf.org; Sat, 13 Nov 2004 11:25:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CT0a2-0004Rq-1e; Sat, 13 Nov 2004 11:16:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CT0Tg-0003V9-R6 for sip@megatron.ietf.org; Sat, 13 Nov 2004 11:10:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14778 for ; Sat, 13 Nov 2004 11:10:15 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CT0VI-0006T3-O6 for sip@ietf.org; Sat, 13 Nov 2004 11:11:57 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 13 Nov 2004 08:24:12 -0800 X-BrightmailFiltered: true Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iADG9hKU018458; Sat, 13 Nov 2004 08:09:43 -0800 (PST) Received: from [10.32.245.156] (stealth-10-32-245-156.cisco.com [10.32.245.156]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id iADGAFaZ022976; Sat, 13 Nov 2004 08:10:16 -0800 In-Reply-To: <19d.2bd091f1.2ec6afb7@aol.com> References: <19d.2bd091f1.2ec6afb7@aol.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <6A965F36-358E-11D9-97C5-000A95C73842@cisco.com> Content-Transfer-Encoding: quoted-printable From: David R Oran Subject: Re: [Sip] -resource-priority-05.txt: Comments and Recommendations (2) Date: Sat, 13 Nov 2004 11:09:37 -0500 To: Mpierce1@aol.com X-Mailer: Apple Mail (2.619) IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1100362216.643056"; x:"432200"; a:"rsa-sha1"; b:"nofws:2164"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"qCkUOjXsuVolwwWRA987ZTFE3qQA/txGHRg21HxtJYhXnutXvzkgt96XYT/3A" "W2ljsvKMsPGYxYZpqYnk5zmdSEhgdH6WGG4CuRBNZWf1VjufXnjbkCi2AQH4v" "hY3nBiNhzcUnWkPer7YAypO7T1cghIPXWfGU+mjUHp/cIYbq8="; c:"From: David R Oran "; c:"Subject: Re: [Sip] -resource-priority-05.txt: Comments and Recommendat" "ions (2)"; c:"Date: Sat, 13 Nov 2004 11:09:37 -0500" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable On Nov 12, 2004, at 7:30 PM, Mpierce1@aol.com wrote: > In a message dated 11/11/2004 6:12:39 PM Eastern Standard Time,=20 > coreya@nortelnetworks.com writes: > > > 2. Is it wise or valid to explicitly allow a proxy to "upgrade" or > "downgrade" the =A0n-p values in a message? > ---- I'm coming at this from the DSN perspective, but wps and/or ets=20= > may > allow this kind of thing. =A0While the DSN/DSRN/(Q735) would not, = that > does not invalidate the concept. > > > > If one understands the "proxy" to be the entity which provides call=20 > processing logic and which validates the calling party's authority to=20= > use the priority level which they signaled in the INVITE (see=20 > draft-pierce-tsvwg-assured-service-arch-01), then it should be valid=20= > for that proxy to "downgrade" the signaled value to the level allowed=20= > for that user before forwarding the INVITE rather than blocking the=20 > call. This behavior should not be disallowed by the R-P header draft=20= > for any namespace. > As long as you have the concept of namespaces, with different policies=20= for different namespaces, it follows logically to allow such policies.=20= If someone wants a namespace that has a "reject call rather than=20 downgrade" as its policy, why prohibit it? Or are you arguing that the=20= R-P draft should be silent on upgrade/downgrade/reject other than to=20 point out that the allowed behaviors are part of the namespace policy=20 definition? If that's what you're saying, I'm ok with that. Dave. > I can't think of any "upgrading" case, but there is not reason for the=20= > R-P header draft to disallow it. > > Mike Pierce > Artel_______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran@cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Nov 13 14:02:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23831 for ; Sat, 13 Nov 2004 14:02:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CT3CJ-0005Rx-9X for sip-web-archive@ietf.org; Sat, 13 Nov 2004 14:04:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CT30C-00006V-4C; Sat, 13 Nov 2004 13:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CT2vh-000816-W4 for sip@megatron.ietf.org; Sat, 13 Nov 2004 13:47:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23331 for ; Sat, 13 Nov 2004 13:47:21 -0500 (EST) From: Mpierce1@aol.com Received: from imo-d20.mx.aol.com ([205.188.139.136]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CT2xK-0004pa-Df for sip@ietf.org; Sat, 13 Nov 2004 13:49:03 -0500 Received: from Mpierce1@aol.com by imo-d20.mx.aol.com (mail_out_v37_r3.8.) id c.9b.526d64fc (4340); Sat, 13 Nov 2004 13:46:39 -0500 (EST) Message-ID: <9b.526d64fc.2ec7b08f@aol.com> Date: Sat, 13 Nov 2004 13:46:39 EST Subject: Re: [Sip] -resource-priority-05.txt: Comments and Recommendations (2) To: oran@cisco.com MIME-Version: 1.0 X-Mailer: 6.0 for Windows XP sub 10500 X-Spam-Score: 0.8 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0937479078==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 --===============0937479078== Content-Type: multipart/alternative; boundary="part1_9b.526d64fc.2ec7b08f_boundary" --part1_9b.526d64fc.2ec7b08f_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 11/13/2004 11:09:54 AM Eastern Standard Time, oran@cisco.com writes: > If someone wants a namespace that has a "reject call rather than > downgrade" as its policy, why prohibit it? Or are you arguing that the > R-P draft should be silent on upgrade/downgrade/reject other than to > point out that the allowed behaviors are part of the namespace policy > definition? If that's what you're saying, I'm ok with that. > Absolutely. Rejecting a call for this reason is perfectly okay. The R-P document should be silent on these types of issues, or, at the most, can mention the different types of behavior which "MAY" be used, but not attempt to associate each possible behavior with various namespaces. Mike --part1_9b.526d64fc.2ec7b08f_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message=20= dated 11/13/2004 11:09:54 AM Eastern Standard Time, oran@cisco.com writes:


If someone wants a namespac= e that has a "reject call rather than=20
downgrade" as its policy, why prohibit it? Or are you arguing that the=20
R-P draft should be silent on upgrade/downgrade/reject other than to=20
point out that the allowed behaviors are part of the namespace policy=20
definition? If that's what you're saying, I'm ok with that.



Absolutely. Rejecting a call for this reason is perfectly okay. The R-P=20= document should be silent on these types of issues, or, at the most, can men= tion the different types of behavior which "MAY" be used, but not attempt to= associate each possible behavior with various namespaces.

Mike
--part1_9b.526d64fc.2ec7b08f_boundary-- --===============0937479078== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0937479078==-- From sip-bounces@ietf.org Mon Nov 15 10:00:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29700 for ; Mon, 15 Nov 2004 10:00:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTiNU-0000KM-MQ for sip-web-archive@ietf.org; Mon, 15 Nov 2004 10:02:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTiDg-0002Y9-JS; Mon, 15 Nov 2004 09:52:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTi78-0001NF-Ui; Mon, 15 Nov 2004 09:45:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28611; Mon, 15 Nov 2004 09:45:53 -0500 (EST) Received: from amer-mta01.csc.com ([20.137.2.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTi99-0008Tc-Pa; Mon, 15 Nov 2004 09:48:00 -0500 Received: from csc.com (va-fch34.csc.com [20.6.39.227]) by amer-mta01.csc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id iAFEjWce007612; Mon, 15 Nov 2004 09:45:32 -0500 (EST) Subject: Re: [Sip] -resource-priority-05.txt: Comments and Recommendations (2) To: David R Oran X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Janet P Gunn Date: Mon, 15 Nov 2004 09:47:06 -0500 X-MIMETrack: Serialize by Router on VA-FCH34/SRV/CSC(Release 6.0.3|September 26, 2003) at 11/15/2004 09:46:25 AM MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, sip-bounces@ietf.org, Mpierce1@aol.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Content-Transfer-Encoding: quoted-printable As I understand it, the proxy would only be allowed to upgrade or downg= rade the value if that were the behavior specifically identified for THAT namespace. As far as I know, neither ets nor wps have current requirements to do t= hat. But the circuit switched versions DO have the concept of a "default priority value" under certain circumstances. If that concept were appl= ied to the IP side, it MIGHT involve upgrading or downgrading to the defaul= t level. I am comfortable with it being left in as a possible behavior, if and o= nly if that behavior is explicitly specified for that namespace. Janet -----------------------------------------------------------------------= ----------------- This is a PRIVATE message. If you are not the intended recipient, pleas= e 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 wri= tten agreement or government initiative expressly permitting the use of e-ma= il for such purpose. -----------------------------------------------------------------------= ----------------- = David R Oran = cc: sip@ietf.org = Sent by: Subject: Re: [Sip] -reso= urce-priority-05.txt: Comments and sip-bounces Recommendations (2) = = = 11/13/2004 11:09 = AM = = = On Nov 12, 2004, at 7:30 PM, Mpierce1@aol.com wrote: > In a message dated 11/11/2004 6:12:39 PM Eastern Standard Time, > coreya@nortelnetworks.com writes: > > > 2. Is it wise or valid to explicitly allow a proxy to "upgrade" or > "downgrade" the =A0n-p values in a message? > ---- I'm coming at this from the DSN perspective, but wps and/or ets > may > allow this kind of thing. =A0While the DSN/DSRN/(Q735) would not, th= at > does not invalidate the concept. > > > > If one understands the "proxy" to be the entity which provides call > processing logic and which validates the calling party's authority to= > use the priority level which they signaled in the INVITE (see > draft-pierce-tsvwg-assured-service-arch-01), then it should be valid > for that proxy to "downgrade" the signaled value to the level allowed= > for that user before forwarding the INVITE rather than blocking the > call. This behavior should not be disallowed by the R-P header draft > for any namespace. > As long as you have the concept of namespaces, with different policies for different namespaces, it follows logically to allow such policies. If someone wants a namespace that has a "reject call rather than downgrade" as its policy, why prohibit it? Or are you arguing that the R-P draft should be silent on upgrade/downgrade/reject other than to point out that the allowed behaviors are part of the namespace policy definition? If that's what you're saying, I'm ok with that. Dave. > I can't think of any "upgrading" case, but there is not reason for th= e > R-P header draft to disallow it. > > Mike Pierce > Artel_______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran@cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip = _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 15 14:03:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21074 for ; Mon, 15 Nov 2004 14:03:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTmAK-0005OH-SL for sip-web-archive@ietf.org; Mon, 15 Nov 2004 14:05:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTm1F-0003ee-Mu; Mon, 15 Nov 2004 13:56:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTlyI-0003Cx-2I for sip@megatron.ietf.org; Mon, 15 Nov 2004 13:53:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19952 for ; Mon, 15 Nov 2004 13:53:00 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTm0J-00058K-Tp for sip@ietf.org; Mon, 15 Nov 2004 13:55:09 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 15 Nov 2004 11:07:13 -0800 X-BrightmailFiltered: true Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iAFIqKOx013827; Mon, 15 Nov 2004 10:52:21 -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 KAA19688; Mon, 15 Nov 2004 10:52:20 -0800 (PST) Message-Id: <4.3.2.7.2.20041115125111.03e88d48@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 15 Nov 2004 12:52:26 -0600 To: Mpierce1@aol.com, coreya@nortelnetworks.com, sip@ietf.org From: "James M. Polk" Subject: Re: [Sip] -resource-priority-05.txt: Comments and Recommendations (2) In-Reply-To: <19d.2bd091f1.2ec6afb7@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 specifying which proxy does any header changes is a market requirement - not a protocol requirement - therefore will not be included in the document At 07:30 PM 11/12/2004 -0500, Mpierce1@aol.com wrote: >In a message dated 11/11/2004 6:12:39 PM Eastern Standard Time, >coreya@nortelnetworks.com writes: > > >>2. Is it wise or valid to explicitly allow a proxy to "upgrade" or >>"downgrade" the n-p values in a message? >>---- I'm coming at this from the DSN perspective, but wps and/or ets may >>allow this kind of thing. While the DSN/DSRN/(Q735) would not, that >>does not invalidate the concept. > > > >If one understands the "proxy" to be the entity which provides call >processing logic and which validates the calling party's authority to use >the priority level which they signaled in the INVITE (see >draft-pierce-tsvwg-assured-service-arch-01), then it should be valid for >that proxy to "downgrade" the signaled value to the level allowed for that >user before forwarding the INVITE rather than blocking the call. This >behavior should not be disallowed by the R-P header draft for any namespace. > >I can't think of any "upgrading" case, but there is not reason for the R-P >header draft to disallow it. > >Mike Pierce >Artel >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip 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 sip-bounces@ietf.org Mon Nov 15 14:10:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21874 for ; Mon, 15 Nov 2004 14:10:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTmHK-0005Zm-NC for sip-web-archive@ietf.org; Mon, 15 Nov 2004 14:12:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTmD4-0006WP-As; Mon, 15 Nov 2004 14:08:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTm70-00054T-Qi for sip@megatron.ietf.org; Mon, 15 Nov 2004 14:02:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20952 for ; Mon, 15 Nov 2004 14:02:01 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTm92-0005L6-R6 for sip@ietf.org; Mon, 15 Nov 2004 14:04:10 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 15 Nov 2004 11:16:18 -0800 X-BrightmailFiltered: true Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iAFJ1Iw0027660; Mon, 15 Nov 2004 11:01:19 -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 LAA07200; Mon, 15 Nov 2004 11:01:19 -0800 (PST) Message-Id: <4.3.2.7.2.20041115125332.03798ee8@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 15 Nov 2004 13:01:25 -0600 To: Mpierce1@aol.com, An.Nguyen@ncs.gov, coreya@nortelnetworks.com, sip@ietf.org From: "James M. Polk" Subject: Re: [Sip] -resource-priority-05.txt: Comments and Recommendations (1) In-Reply-To: <1ca.2ca0df9e.2ec67586@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Where is "mapping between namespaces" specified in the document now? I do not believe there is such a sentence/comment/statement, and there should not be one, so why was this brought up? At 03:22 PM 11/12/2004 -0500, Mpierce1@aol.com wrote: >In a message dated 11/12/2004 11:58:14 AM Eastern Standard Time, >An.Nguyen@ncs.gov writes: > > >>Can we just add a sentence to the draft saying mapping between namespaces >>is out of scope and it should be addressed separately? > > >Yes, such a statement would be fine, but it should be along with a >statement that all interrelationship between namespaces is out of scope. > >Mike >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 15 14:40:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24574 for ; Mon, 15 Nov 2004 14:40:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTmkf-0006L5-Rv for sip-web-archive@ietf.org; Mon, 15 Nov 2004 14:43:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTmfp-0002tl-Js; Mon, 15 Nov 2004 14:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTmay-00025y-L6 for sip@megatron.ietf.org; Mon, 15 Nov 2004 14:33:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23868 for ; Mon, 15 Nov 2004 14:32:59 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTmd0-00068w-JJ for sip@ietf.org; Mon, 15 Nov 2004 14:35:08 -0500 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iAFJWNk22261; Mon, 15 Nov 2004 14:32:23 -0500 (EST) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Nov 2004 14:32:23 -0500 Message-ID: <7A3E36B3528ED04A880178D337F30C9A01C4828E@zrc2hxm1.corp.nortel.com> From: "Corey Alexander" To: "'James M. Polk'" , "'Mpierce1@aol.com'" , "'An.Nguyen@ncs.gov'" , "'sip@ietf.org'" Subject: RE: [Sip] -resource-priority-05.txt: Comments and Recommendation s (1) Date: Mon, 15 Nov 2004 14:32:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.5 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0527853555==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0527853555== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4CB49.D1CC9AB0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4CB49.D1CC9AB0 Content-Type: text/plain It's not. This was one of my questions to you Tuesday, which I shared in my post. Given my perspective at the time, I saw this as an alternative to passing multiple namespace/priority values in a single message. After speaking with you, I understood that there may be instances where multiple values are perfectly acceptable. This does not rule out such a mapping - I'd argue that they will have to be defined when implementing this header, if it will be able to pass across namespace boundaries - but as everyone is stating, such mappings should not be defined with the header. Corey W. Alexander -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com] Sent: Monday, November 15, 2004 1:01 PM To: Mpierce1@aol.com; An.Nguyen@ncs.gov; Alexander, Corey [NGD:X262:EXCH]; sip@ietf.org Subject: Re: [Sip] -resource-priority-05.txt: Comments and Recommendations (1) Where is "mapping between namespaces" specified in the document now? I do not believe there is such a sentence/comment/statement, and there should not be one, so why was this brought up? At 03:22 PM 11/12/2004 -0500, Mpierce1@aol.com wrote: >In a message dated 11/12/2004 11:58:14 AM Eastern Standard Time, >An.Nguyen@ncs.gov writes: > > >>Can we just add a sentence to the draft saying mapping between >>namespaces >>is out of scope and it should be addressed separately? > > >Yes, such a statement would be fine, but it should be along with a >statement that all interrelationship between namespaces is out of scope. > >Mike >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip Use >sipping@ietf.org for new developments on the application of sip cheers, James ******************* Truth is not to be argued... it is to be presented ------_=_NextPart_001_01C4CB49.D1CC9AB0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sip] -resource-priority-05.txt: Comments and = Recommendations (1)

It's not.  This was one of my questions to you = Tuesday, which I shared in my post.  Given my perspective at the = time, I saw this as an alternative to passing multiple = namespace/priority values in a single message.  After speaking = with you, I understood that there may be instances where multiple = values are perfectly acceptable.  This does not rule out such a = mapping - I'd argue that they will have to be defined when implementing = this header, if it will be able to pass across namespace boundaries - = but as everyone is stating, such mappings should not be defined with = the header.

Corey W. Alexander

-----Original Message-----
From: James M. Polk [mailto:jmpolk@cisco.com]
Sent: Monday, November 15, 2004 1:01 PM
To: Mpierce1@aol.com; An.Nguyen@ncs.gov; Alexander, = Corey [NGD:X262:EXCH]; sip@ietf.org
Subject: Re: [Sip] -resource-priority-05.txt: = Comments and Recommendations (1)


Where is "mapping between namespaces" = specified in the document now?

I do not believe there is such a = sentence/comment/statement, and there
should not be one, so why was this brought = up?

At 03:22 PM 11/12/2004 -0500, Mpierce1@aol.com = wrote:
>In a message dated 11/12/2004 11:58:14 AM = Eastern Standard Time,
>An.Nguyen@ncs.gov writes:
>
>
>>Can we just add a sentence to the draft = saying mapping between
>>namespaces
>>is out of scope and it should be addressed = separately?
>
>
>Yes, such a statement would be fine, but it = should be along with a
>statement that all interrelationship between = namespaces is out of scope.
>
>Mike
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP = Protocol
>Use sip-implementors@cs.columbia.edu for = questions on current sip Use
>sipping@ietf.org for new developments on the = application of sip


cheers,
James

          &nb= sp;           &nb= sp;         = *******************
          &nb= sp;      Truth is not to be argued... it is to = be presented


------_=_NextPart_001_01C4CB49.D1CC9AB0-- --===============0527853555== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0527853555==-- From sip-bounces@ietf.org Mon Nov 15 14:54:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25543 for ; Mon, 15 Nov 2004 14:54:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTmy4-0006cs-Eu for sip-web-archive@ietf.org; Mon, 15 Nov 2004 14:56:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTmq4-0004lR-9Z; Mon, 15 Nov 2004 14:48:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTmly-0003ka-3N for sip@megatron.ietf.org; Mon, 15 Nov 2004 14:44:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24846 for ; Mon, 15 Nov 2004 14:44:20 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTmnx-0006Os-Bh for sip@ietf.org; Mon, 15 Nov 2004 14:46:30 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 15 Nov 2004 11:58:33 -0800 X-BrightmailFiltered: true Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iAFJhcOx017098; Mon, 15 Nov 2004 11:43:39 -0800 (PST) Received: from [10.32.245.156] (stealth-10-32-245-156.cisco.com [10.32.245.156]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id iAFJi3ip002639; Mon, 15 Nov 2004 11:44:04 -0800 In-Reply-To: <4.3.2.7.2.20041115125332.03798ee8@localhost> References: <4.3.2.7.2.20041115125332.03798ee8@localhost> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [Sip] -resource-priority-05.txt: Comments and Recommendations (1) Date: Mon, 15 Nov 2004 14:43:34 -0500 To: "James M. Polk" X-Mailer: Apple Mail (2.619) IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1100547844.763217"; x:"432200"; a:"rsa-sha1"; b:"nofws:2233"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"YmlDSla9F6H+1XCIjXofKsKCDnZM6BCpYjnDHmR8CS9D6ecpyIihrZhUeIPFu" "HrT6aFRFz7gpdzJZ9VJGtbRp95JJ6Zv7+AQFhkdH7u4Lc3pW7oIKkdUOIH57H" "1p47rmsN4mys9Mhb9kVTHoFAigkajzVtAkkwZx8hHPRSRox3w="; c:"From: David R Oran "; c:"Subject: Re: [Sip] -resource-priority-05.txt: Comments and Recommendat" "ions (1)"; c:"Date: Mon, 15 Nov 2004 14:43:34 -0500" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: An.Nguyen@ncs.gov, sip@ietf.org, Mpierce1@aol.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit On Nov 15, 2004, at 2:01 PM, James M. Polk wrote: > Where is "mapping between namespaces" specified in the document now? > > I do not believe there is such a sentence/comment/statement, and there > should not be one, so why was this brought up? > If somebody reads the doc expecting to see something and it isn't there, two possibilities obtain: (a) they don't "get it" (b) a reasonable person might think that function a natural one to be handled, but that's not the approach we took in designing this beastie. The case at hand seems closer to (b) than (a), so I see no harm in saying that namespaces are orthogonal as far as the specification is concerned, and while it may be possible to map behavior between namespaces, this document doesn't tell you how, and that's intentional. Dave. > At 03:22 PM 11/12/2004 -0500, Mpierce1@aol.com wrote: >> In a message dated 11/12/2004 11:58:14 AM Eastern Standard Time, >> An.Nguyen@ncs.gov writes: >> >> >>> Can we just add a sentence to the draft saying mapping between >>> namespaces is out of scope and it should be addressed separately? >> >> >> Yes, such a statement would be fine, but it should be along with a >> statement that all interrelationship between namespaces is out of >> scope. >> >> Mike >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > > cheers, > James > > ******************* > Truth is not to be argued... it is to be presented > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran@cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 15 15:39:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00557 for ; Mon, 15 Nov 2004 15:39:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTnfV-0007Uo-LK for sip-web-archive@ietf.org; Mon, 15 Nov 2004 15:41:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTnbW-0007yt-7j; Mon, 15 Nov 2004 15:37:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTnXI-0006sq-2W; Mon, 15 Nov 2004 15:33:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29898; Mon, 15 Nov 2004 15:33:11 -0500 (EST) Received: from amer-mta02.csc.com ([20.137.2.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTnZI-0007NG-IY; Mon, 15 Nov 2004 15:35:21 -0500 Received: from csc.com (va-fch34.csc.com [20.6.39.227]) by amer-mta02.csc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id iAFKWs3D008384; Mon, 15 Nov 2004 15:33:02 -0500 (EST) Subject: Re: [Sip] -resource-priority-05.txt: Comments and Recommendations (1) To: David R Oran X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Janet P Gunn Date: Mon, 15 Nov 2004 15:33:28 -0500 X-MIMETrack: Serialize by Router on VA-FCH34/SRV/CSC(Release 6.0.3|September 26, 2003) at 11/15/2004 03:33:55 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: An.Nguyen@ncs.gov, sip@ietf.org, "James M. Polk" , sip-bounces@ietf.org, Mpierce1@aol.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 The .03 draft (and I think also the .04 draft) had a paragraph that said "Namespaces do not describe how they relate to other existing namespaces, as each namespace is independent of other registrations." It doesn't seem to be in .05 Maybe it, or something like it, should be put back in. 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. ---------------------------------------------------------------------------------------- David R Oran @cisco.com> cc: An.Nguyen@ncs.gov, sip@ietf.org, Mpierce1@aol.com Sent by: Subject: Re: [Sip] -resource-priority-05.txt: Comments and sip-bounces Recommendations (1) 11/15/2004 02:43 PM On Nov 15, 2004, at 2:01 PM, James M. Polk wrote: > Where is "mapping between namespaces" specified in the document now? > > I do not believe there is such a sentence/comment/statement, and there > should not be one, so why was this brought up? > If somebody reads the doc expecting to see something and it isn't there, two possibilities obtain: (a) they don't "get it" (b) a reasonable person might think that function a natural one to be handled, but that's not the approach we took in designing this beastie. The case at hand seems closer to (b) than (a), so I see no harm in saying that namespaces are orthogonal as far as the specification is concerned, and while it may be possible to map behavior between namespaces, this document doesn't tell you how, and that's intentional. Dave. > At 03:22 PM 11/12/2004 -0500, Mpierce1@aol.com wrote: >> In a message dated 11/12/2004 11:58:14 AM Eastern Standard Time, >> An.Nguyen@ncs.gov writes: >> >> >>> Can we just add a sentence to the draft saying mapping between >>> namespaces is out of scope and it should be addressed separately? >> >> >> Yes, such a statement would be fine, but it should be along with a >> statement that all interrelationship between namespaces is out of >> scope. >> >> Mike >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > > cheers, > James > > ******************* > Truth is not to be argued... it is to be presented > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran@cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 15 16:35:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12731 for ; Mon, 15 Nov 2004 16:35:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CToXD-0002dc-Ci for sip-web-archive@ietf.org; Mon, 15 Nov 2004 16:37:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CToKb-0003HN-Gs; Mon, 15 Nov 2004 16:24:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTnlU-0002IQ-Fq for sip@megatron.ietf.org; Mon, 15 Nov 2004 15:47:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01212 for ; Mon, 15 Nov 2004 15:47:52 -0500 (EST) Received: from viefep15-int.chello.at ([213.46.255.19]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTnnL-0007fh-Ro for sip@ietf.org; Mon, 15 Nov 2004 15:50:02 -0500 Received: from [192.168.2.21] (really [62.178.216.203]) by viefep15-int.chello.at (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20041115204658.YUJU4582.viefep15-int.chello.at@[192.168.2.21]>; Mon, 15 Nov 2004 21:46:58 +0100 Message-ID: <419915BE.2060703@pernau.at> Date: Mon, 15 Nov 2004 21:46:54 +0100 From: Klaus Darilion User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Stredicke Subject: Re: [Sip] PING/PONG References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: 7bit You should also consider the guidelines in the draft http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-00.txt which will hopefully soon implemented in NAT routers. regards, klaus Christian Stredicke wrote: > Hi Spencer! > > You just mentioned another way of keeping TCP connections alive. Thats > good! > > So far we have: > > - CRLF (frequenly used today, but not indicated by user agent) > - STUN (same as CRLF) > - PING/PONG or whatever (tbd, maybe superflous) > - OPTIONS (big overhead, but compatible) > - REGISTER (same as OPTIONS, but even bigger overhead) > - TCP low-level (how can this be addressed by the application?) > - No refreshing ("legacy device") > > Lets have a way to indicate these options and let the SBC decide what > method it likes/supports. > > CS > > >>-----Original Message----- >>From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >>Behalf Of Spencer Dawkins >>Sent: Wednesday, November 10, 2004 5:01 PM >>To: sip@ietf.org >>Subject: Re: [Sip] PING/PONG >> >>Call me old-fashioned, but I'm requesting a point of clarification >>about PING/PONG. >> >>As I should have said in the working group session when we discussed >>this, I have no interest in chatting about UDP versus TCP. If you >>choose UDP, I assume you did it for a reason, and the discussion at >>the working group session makes sense to me. >> >>Having said that, >> >> >>>With UDP, the PING will create a new NAT binding and the server can >>>update >>>its mapping for the UA. >>> >>>With TCP, if you want to be able to detect that the NAT binding is >>>gone on >>>the order of a transaction timeout, you would need to send a PING >>>every 32 >>>seconds or so. Given that NAT bindings for TCP live longer than >>>that, I >>>don't see what the CRLF buys you. >> >>it seems to me that if you have chosen to use TCP for some >>reason, you >>need to at least consider living with TCP behavior on retries. >> >>The TCP protocol is extremely persistent, uses exponential backoff >>(typically to a maximum of 60-64 seconds per retry), and in most >>vanilla implementations will not declare a connection unusable for >>something like 10-15 minutes. >> >>If a path is lost, for any reason, TCP will use this behavior (the >>behavior that allows the Internet to survive the World Wide Web >>today). >> >>If you are using TCP and you don't like this behavior, and you don't >>get a response back when you wanted to get a response back, the >>application choices are: >> >>- sit on your hands and wait for the TCP connection to fail, >> >>- close the TCP connection and open another one, or >> >>- close the TCP connection, sit on your hands for some period >>of time, >>and open another one. >> >>The second choice (immediate retry) requires that you reset the TCP >>connection (one packet), send a SYN to open a second TCP connection >>(one packet), and potentially ACK an incoming SYN/ACK (one packet), >>and then resend your application message (could be piggybacked but >>most TCP stacks will use a separate packet). >> >>Immediately sending up to four new packets when you detect >>loss of one >>packet, with the possibility that the single-packet loss is due to >>network congestion, seems too aggressive. >> >>Sitting on your hands and letting TCP retry doesn't seem much worse >>than sitting on your hands and then setting up a new TCP connection. >> >>Are we assuming that network congestion is not an issue any more? >> >>Thanks for any guidance you can provide! >> >>Spencer >> >> >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip >> >> >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 15 17:36:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20475 for ; Mon, 15 Nov 2004 17:36:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTpUp-0004Uw-3R for sip-web-archive@ietf.org; Mon, 15 Nov 2004 17:38:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTpK2-0008IT-LW; Mon, 15 Nov 2004 17:27:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTpD5-0005qT-OW; Mon, 15 Nov 2004 17:20:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18858; Mon, 15 Nov 2004 17:20:29 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTpFA-00049k-LJ; Mon, 15 Nov 2004 17:22:41 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 15 Nov 2004 14:34:49 -0800 X-BrightmailFiltered: true Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iAFMJpw0009253; Mon, 15 Nov 2004 14:19:51 -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 OAA23156; Mon, 15 Nov 2004 14:19:54 -0800 (PST) Message-Id: <4.3.2.7.2.20041115161910.03709ef0@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 15 Nov 2004 16:20:00 -0600 To: Janet P Gunn , David R Oran From: "James M. Polk" Subject: Re: [Sip] -resource-priority-05.txt: Comments and Recommendations (1) In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: An.Nguyen@ncs.gov, sip@ietf.org, sip-bounces@ietf.org, Mpierce1@aol.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f At 03:33 PM 11/15/2004 -0500, Janet P Gunn wrote: >The .03 draft (and I think also the .04 draft) had a paragraph that said > "Namespaces do not describe how they relate to other existing > namespaces, as each namespace is independent of other registrations." > >It doesn't seem to be in .05 see (the new) section 7.1 about the warnings of multiple namespaces >Maybe it, or something like it, should be put back in. see above >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. >---------------------------------------------------------------------------------------- > > > > > > > David R > Oran > > > @cisco.com> cc: > An.Nguyen@ncs.gov, sip@ietf.org, Mpierce1@aol.com > Sent by: Subject: Re: [Sip] > -resource-priority-05.txt: Comments and > sip-bounces Recommendations > (1) > > > > > 11/15/2004 > 02:43 > > PM > > > > > > > > > > >On Nov 15, 2004, at 2:01 PM, James M. Polk wrote: > > > Where is "mapping between namespaces" specified in the document now? > > > > I do not believe there is such a sentence/comment/statement, and there > > should not be one, so why was this brought up? > > >If somebody reads the doc expecting to see something and it isn't >there, two possibilities obtain: >(a) they don't "get it" >(b) a reasonable person might think that function a natural one to be >handled, but that's not the approach we took in designing this beastie. > >The case at hand seems closer to (b) than (a), so I see no harm in >saying that namespaces are orthogonal as far as the specification is >concerned, and while it may be possible to map behavior between >namespaces, this document doesn't tell you how, and that's intentional. > >Dave. > > > At 03:22 PM 11/12/2004 -0500, Mpierce1@aol.com wrote: > >> In a message dated 11/12/2004 11:58:14 AM Eastern Standard Time, > >> An.Nguyen@ncs.gov writes: > >> > >> > >>> Can we just add a sentence to the draft saying mapping between > >>> namespaces is out of scope and it should be addressed separately? > >> > >> > >> Yes, such a statement would be fine, but it should be along with a > >> statement that all interrelationship between namespaces is out of > >> scope. > >> > >> Mike > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of sip > > > > > > cheers, > > James > > > > ******************* > > Truth is not to be argued... it is to be presented > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > >David R. Oran >Cisco Fellow >Cisco Systems >7 Ladyslipper Lane >Acton, MA 01720 USA >Tel: +1 978 264 2048 >Email: oran@cisco.com > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip 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 sip-bounces@ietf.org Mon Nov 15 18:00:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22545 for ; Mon, 15 Nov 2004 18:00:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTprV-00051b-42 for sip-web-archive@ietf.org; Mon, 15 Nov 2004 18:02:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTpnP-00075k-4y; Mon, 15 Nov 2004 17:58:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTpmq-00070M-M3; Mon, 15 Nov 2004 17:57:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22396; Mon, 15 Nov 2004 17:57:23 -0500 (EST) Received: from amer-mta01.csc.com ([20.137.2.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTpos-0004yT-Jc; Mon, 15 Nov 2004 17:59:35 -0500 Received: from csc.com (va-fch34.csc.com [20.6.39.227]) by amer-mta01.csc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id iAFMvKf7023823; Mon, 15 Nov 2004 17:57:20 -0500 (EST) Subject: Re: [Sip] -resource-priority-05.txt: Comments and Recommendations (1) To: "James M. Polk" X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Janet P Gunn Date: Mon, 15 Nov 2004 17:57:51 -0500 X-MIMETrack: Serialize by Router on VA-FCH34/SRV/CSC(Release 6.0.3|September 26, 2003) at 11/15/2004 05:58:13 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Cc: An.Nguyen@ncs.gov, sip@ietf.org, David R Oran , sip-bounces@ietf.org, Mpierce1@aol.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 7.1 starts with "The only rules stipulated here regarding more than one namespace in a SIP message are:" followed by a bulleted list.. May be it could be made stronger by saying, after the list, "Except for these rules, namespaces do not describe how they relate to other existing namespaces." "Only" should cover it, but if it isn't clear to some readers... 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. ---------------------------------------------------------------------------------------- "James M. Polk" @cisco.com> cc: An.Nguyen@ncs.gov, sip@ietf.org, sip-bounces@ietf.org, Sent by: Mpierce1@aol.com sip-bounces Subject: Re: [Sip] -resource-priority-05.txt: Comments and Recommendations (1) 11/15/2004 05:20 PM At 03:33 PM 11/15/2004 -0500, Janet P Gunn wrote: >The .03 draft (and I think also the .04 draft) had a paragraph that said > "Namespaces do not describe how they relate to other existing > namespaces, as each namespace is independent of other registrations." > >It doesn't seem to be in .05 see (the new) section 7.1 about the warnings of multiple namespaces >Maybe it, or something like it, should be put back in. see above >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. >---------------------------------------------------------------------------------------- > > > > > > > David R > Oran > > > @cisco.com> cc: > An.Nguyen@ncs.gov, sip@ietf.org, Mpierce1@aol.com > Sent by: Subject: Re: [Sip] > -resource-priority-05.txt: Comments and > sip-bounces Recommendations > (1) > > > > > 11/15/2004 > 02:43 > > PM > > > > > > > > > > >On Nov 15, 2004, at 2:01 PM, James M. Polk wrote: > > > Where is "mapping between namespaces" specified in the document now? > > > > I do not believe there is such a sentence/comment/statement, and there > > should not be one, so why was this brought up? > > >If somebody reads the doc expecting to see something and it isn't >there, two possibilities obtain: >(a) they don't "get it" >(b) a reasonable person might think that function a natural one to be >handled, but that's not the approach we took in designing this beastie. > >The case at hand seems closer to (b) than (a), so I see no harm in >saying that namespaces are orthogonal as far as the specification is >concerned, and while it may be possible to map behavior between >namespaces, this document doesn't tell you how, and that's intentional. > >Dave. > > > At 03:22 PM 11/12/2004 -0500, Mpierce1@aol.com wrote: > >> In a message dated 11/12/2004 11:58:14 AM Eastern Standard Time, > >> An.Nguyen@ncs.gov writes: > >> > >> > >>> Can we just add a sentence to the draft saying mapping between > >>> namespaces is out of scope and it should be addressed separately? > >> > >> > >> Yes, such a statement would be fine, but it should be along with a > >> statement that all interrelationship between namespaces is out of > >> scope. > >> > >> Mike > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of sip > > > > > > cheers, > > James > > > > ******************* > > Truth is not to be argued... it is to be presented > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > >David R. Oran >Cisco Fellow >Cisco Systems >7 Ladyslipper Lane >Acton, MA 01720 USA >Tel: +1 978 264 2048 >Email: oran@cisco.com > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 15 19:07:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28817 for ; Mon, 15 Nov 2004 19:07:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTqv0-0006M6-08 for sip-web-archive@ietf.org; Mon, 15 Nov 2004 19:10:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTqrd-0006Z2-DN; Mon, 15 Nov 2004 19:06:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTqkM-0005KG-Vz for sip@megatron.ietf.org; Mon, 15 Nov 2004 18:58:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27937 for ; Mon, 15 Nov 2004 18:58:56 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTqmR-00066z-U1 for sip@ietf.org; Mon, 15 Nov 2004 19:01:09 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 15 Nov 2004 15:58:56 -0800 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id iAFNwNYr011585; Mon, 15 Nov 2004 15:58:23 -0800 (PST) Received: from cisco.com ([161.44.79.125]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ANB17430; Mon, 15 Nov 2004 18:58:22 -0500 (EST) Message-ID: <4199429E.4090109@cisco.com> Date: Mon, 15 Nov 2004 18:58:22 -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: "Peterson, Jon" , Cullen Jennings , sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Subject: [Sip] Identity after reinvite X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Jon, After the meetings last week a question came to mind re the identity draft. First, I want to double check on usage in dialogs. The draft doesn't say, but I presume that every message in a dialog needs to be signed, not just the one that initiates a dialog. If that is a bad assumption, it would be good to hear why. Assuming that, what happens when the initial invite was from Alice to Bob, and later a reinvite is sent from Bob to Alice? Initially Bob knew that Alice had called, while Alice had no assurance about who she had reached with her call. The reinvite is from Bob, so if his identity is blessed, then Alice will know she is talking to Bob, but Bob will no longer have any assurance that he is still talking to Alice. This could even manifest itself in the UI presented to Alice and Bob. Initially Bob would have a "callerid" display showing Alice as a certified caller. But after putting Alice on hold and back off hold the display might stop showing Alice, or at least might show the identity as suspect. (There may be strong temptations to avoid this via some sort of hack.) I don't see any good solution for this other than solving the connected party id problem as well. Just checking my understanding, Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 16 01:45:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09211 for ; Tue, 16 Nov 2004 01:45:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTx7f-00056i-FO for sip-web-archive@ietf.org; Tue, 16 Nov 2004 01:47:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTx3q-0006nw-Ol; Tue, 16 Nov 2004 01:43:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTx20-0006YT-GC for sip@megatron.ietf.org; Tue, 16 Nov 2004 01:41:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08904 for ; Tue, 16 Nov 2004 01:41:35 -0500 (EST) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTx49-00050O-ON for sip@ietf.org; Tue, 16 Nov 2004 01:43:50 -0500 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id iAG6f210026137; Tue, 16 Nov 2004 06:41:02 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Tue, 16 Nov 2004 01:41:02 -0500 Message-ID: <7927C67249E4AD43BC05B539AF0D129801AF4372@stntexch04.cis.neustar.com> From: "Peterson, Jon" To: "'Paul Kyzivat'" , Cullen Jennings , sip@ietf.org Date: Tue, 16 Nov 2004 01:40:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Subject: [Sip] RE: Identity after reinvite X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Well, yes, now one begins to appreciate why we originally coupled the request identity problem with the response identity problem. :) In the next revision of the identity draft, which will incorporate the list comments up to date, I do intend to include some text about dialogs. I agree that the draft should apply to requests regardless of the dialog context. Moreover, I don't think the problem you raise below is limited merely to re-INVITEs within a dialog. I believe it applies equally to BYE requests sent in the backwards direction in a dialog. Ideally, the originator of the dialog should have some assurance that requests sent in the backwards direction come from the same identity that positively responded to the dialog (i.e., the sender of the 200 and any provisional responses). In the absence of response identity, though, it is difficult for Alice to have any such assurance. Equally, as you point out below, Bob can have no assurance that his BYE or re-INVITE has been fielded by Alice if he is unable to get a cryptographically-assured 200 response to his own requests. Alice can't even be certain that she actually connected to Bob, thanks to retargeting; this is the essence of the connected-ID/response identity problem, and threatens to drag us back into the morass of retargeting restrictions and so on that populated the sip-identity-02 draft. A lack of such a strong binding of backwards-direction BYE requests to the dialog is a significant limitation; if BYE can be spoofed, then an attacker can terminate existing dialogs. However, I'm not sure that the situation is so dire as you suggest below. Without identity, it is trivial for any attacker to impersonate a dialog-forming request. It is harder, though, for an attacker to impersonate a response or mid-dialog request; this requires the attacker to gather dialog state through eavesdropping or some similar means. There is a very important distinction in sophistication between an attacker who can merely formulate a plausible dialog-forming request with an inappropriate From header field versus an attacker who can capture dialog-forming requests and improvise appropriate responses (with correct tags, correct Call-ID/CSeq, etc). Ultimately, request identity can protect against the former but not the latter. While it is imperfect, I feel that this is an improvement over the current situation. In cases where retargeting has not occurred, Alice will see a re-INVITE or BYE from the expected URI (blessed, as you say); in cases where retargeting has occurred, Alice may receive a warning from her UI that an unexpected but assured URI has responded. Likewise, Bob will have to trust, given the signature over the Contact header field in the dialog-forming INVITE request, that his request in the backwards direction is forwarded to the appropriate UA instance. In terms of what Bob's UI should display, well, that really depends on the sophistication of attacks you are willing to consider plausible. Personally, I don't think Bob's UI should suggest any uncertainty about the matter. To improve on all this, we will ultimately need to solve the response identity problem; however, I maintain that sip-identity as it stands will have addressed the simplest and most common variety of impersonation, the one that does not require any eavesdropping whatsoever. Once we feel we have the right answer to request identity, we can revisit the response identity problem and try to eliminate the remaining attacks. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, November 15, 2004 3:58 PM > To: Peterson, Jon; Cullen Jennings; sip@ietf.org > Subject: Identity after reinvite > > > Jon, > > After the meetings last week a question came to mind re the > identity draft. > > First, I want to double check on usage in dialogs. The draft doesn't > say, but I presume that every message in a dialog needs to be signed, > not just the one that initiates a dialog. If that is a bad assumption, > it would be good to hear why. > > Assuming that, what happens when the initial invite was from Alice to > Bob, and later a reinvite is sent from Bob to Alice? Initially Bob knew > that Alice had called, while Alice had no assurance about who she had > reached with her call. The reinvite is from Bob, so if his identity is > blessed, then Alice will know she is talking to Bob, but Bob will no > longer have any assurance that he is still talking to Alice. > > This could even manifest itself in the UI presented to Alice and Bob. > Initially Bob would have a "callerid" display showing Alice as a > certified caller. But after putting Alice on hold and back off hold the > display might stop showing Alice, or at least might show the identity as > suspect. (There may be strong temptations to avoid this via some sort of > hack.) > > I don't see any good solution for this other than solving the connected > party id problem as well. > > Just checking my understanding, > Paul > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 16 03:11:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02384 for ; Tue, 16 Nov 2004 03:11:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTySs-00073B-Hw for sip-web-archive@ietf.org; Tue, 16 Nov 2004 03:13:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTyMv-0008Ae-Jy; Tue, 16 Nov 2004 03:07:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTyLu-0007yM-Iq for sip@megatron.ietf.org; Tue, 16 Nov 2004 03:06:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01660 for ; Tue, 16 Nov 2004 03:06:12 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTyO2-0006ti-KG for sip@ietf.org; Tue, 16 Nov 2004 03:08:28 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 16 Nov 2004 00:18:36 -0800 Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAG85S3O009948; Tue, 16 Nov 2004 00:05:28 -0800 (PST) Received: from [192.168.1.100] (sjc-vpn4-1387.cisco.com [10.21.85.106]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFT54216; Tue, 16 Nov 2004 00:05:36 -0800 (PST) Message-ID: <4199B4D0.30606@cisco.com> Date: Tue, 16 Nov 2004 03:05:36 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peterson, Jon" Subject: Re: [Sip] RE: Identity after reinvite References: <7927C67249E4AD43BC05B539AF0D129801AF4372@stntexch04.cis.neustar.com> In-Reply-To: <7927C67249E4AD43BC05B539AF0D129801AF4372@stntexch04.cis.neustar.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , sip@ietf.org, "'Paul Kyzivat'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7bit Peterson, Jon wrote: > Well, yes, now one begins to appreciate why we originally coupled the > request identity problem with the response identity problem. :) > > In the next revision of the identity draft, which will incorporate the list > comments up to date, I do intend to include some text about dialogs. I agree > that the draft should apply to requests regardless of the dialog context. I do believe there are issues related to mid-dialog requests, but I'm not sure I agree that Paul's characterization is the problem. The problem is that, due to retargeting, the URI in the To field of the INVITE may not identify the user that was eventually reached. In RFC 3261, requests from the called party to the caller carry the value from the original To field in the From. As a result, the requests will have a From field value which does not actually correspond to the originator of the reuqest. The identity service will then reject these requests. The solution, which rfc3261 warns of, is that a UA has to put its actual identity in the From field URI, not what it saw in the To field of the original request. This will break all compatibility with rfc2543, but will work with other rfc3261 compliant endpoints, since the URI is no longer used for dialog identification. > > Moreover, I don't think the problem you raise below is limited merely to > re-INVITEs within a dialog. I believe it applies equally to BYE requests > sent in the backwards direction in a dialog. Ideally, the originator of the > dialog should have some assurance that requests sent in the backwards > direction come from the same identity that positively responded to the > dialog (i.e., the sender of the 200 and any provisional responses). Useful, yes, but a different problem. I like the current scope of the identity draft - to provide the identity of the sender of a request. That is not a panacea for all of our security problems, of course. > > In the absence of response identity, though, it is difficult for Alice to > have any such assurance. Equally, as you point out below, Bob can have no > assurance that his BYE or re-INVITE has been fielded by Alice if he is > unable to get a cryptographically-assured 200 response to his own requests. > Alice can't even be certain that she actually connected to Bob, thanks to > retargeting; this is the essence of the connected-ID/response identity > problem, and threatens to drag us back into the morass of retargeting > restrictions and so on that populated the sip-identity-02 draft. > > A lack of such a strong binding of backwards-direction BYE requests to the > dialog is a significant limitation; if BYE can be spoofed, then an attacker > can terminate existing dialogs. Doesn't sips prevent that? With sips, you won't be able to identify the called party from the 200 OK, but it will guarantee that no one except the party you reach can terminate the call. Indeed, it occurs to me that one can "simulate" response identity by having the called party send an UPDATE or nearly any other request in the reverse direction immediately upon receipt of the ACK. If you structure the From field of that request as I have proposed above, the net result provides a form of response identity - it tells you who was reached. This doesnt tell you *why* it was reached (as redirection would), but it seems valuable nonetheless. However, I'm not sure that the situation is > so dire as you suggest below. Without identity, it is trivial for any > attacker to impersonate a dialog-forming request. It is harder, though, for > an attacker to impersonate a response or mid-dialog request; this requires > the attacker to gather dialog state through eavesdropping or some similar > means. There is a very important distinction in sophistication between an > attacker who can merely formulate a plausible dialog-forming request with an > inappropriate From header field versus an attacker who can capture > dialog-forming requests and improvise appropriate responses (with correct > tags, correct Call-ID/CSeq, etc). sips, of course, prevents this fully. > > Ultimately, request identity can protect against the former but not the > latter. But, its not supposed to. Its not supposed to provide all of the security functions for sip - just the function which identifies the originator of a request. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 16 07:16:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21673 for ; Tue, 16 Nov 2004 07:16:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU2IB-0003l5-Rh for sip-web-archive@ietf.org; Tue, 16 Nov 2004 07:18:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU2Dj-0001SP-3B; Tue, 16 Nov 2004 07:14:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU279-00008z-Nm for sip@megatron.ietf.org; Tue, 16 Nov 2004 07:07:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21040 for ; Tue, 16 Nov 2004 07:07:13 -0500 (EST) Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU29K-0003Yg-G0 for sip@ietf.org; Tue, 16 Nov 2004 07:09:32 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0I7900501TK3H6@siemenscomms.co.uk> for sip@ietf.org; Tue, 16 Nov 2004 12:04:51 +0000 (GMT) Received: from ntht206e.siemenscomms.co.uk ([137.223.247.52]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0I790053CTK393@siemenscomms.co.uk>; Tue, 16 Nov 2004 12:04:51 +0000 (GMT) Received: by ntht206e.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 16 Nov 2004 12:06:41 +0000 Content-return: allowed Date: Tue, 16 Nov 2004 12:06:40 +0000 From: "Elwell, John" Subject: RE: [Sip] Identity Update To: "'Mataga, Peter Andrew (Peter)'" , sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F26670252D57E@ntht201e> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: 7BIT X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Content-Transfer-Encoding: 7BIT Peter, Picking up on your last point (allowing From to change and allowing Identity to be used for update within a dialog), this would avoid the need to enhance Identity to cover an identity in a response (at least as far as dialogs are concerned). As I write this, I see some discussion from Jon and Jonathan on this same topic. Sounds like a good thing to explore. John (john.elwell@siemens.com) ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Mataga, Peter Andrew (Peter) Sent: 11 November 2004 06:46 To: sip@ietf.org Subject: [Sip] Identity Update There has been a lot of discussion in the past on the method of indicating a change of identity to a UA, as an explicit user action at the remote UA, because of transfer within a legacy network or by 3PCC in a B2BUA, or even because of aliasing, forwarding or redirection+recursion within a target domain when there is no mechanism to indicate identity in a response. At San Diego the topic was revisited with 3 options on the table: 1) Use of INVITE/Replaces as a kind of self-transfer 2) Changing the From header during a dialog 3) Inventing a new header Based on the arguments put forward during that session, there was a hum in favor of INVITE/Replaces as the only mechanism supported. On reflection, I don't think all the issues were aired at the time or in the small amount of subsequent list discussion. The INVITE/Replaces mechanism certainly has some appealing similarities to other scenarios (particularly the pure SIP transfer case, of course). I don't know that these are compelling when the application is to update information about a single session, and it seems to me there are going to be cases where it is not the most efficient or convenient way of doing so. Some specific issues: 1) How does the SDP in the INVITE/Replaces relate to the media session for the original dialog? There are more possibilities than normal because the new dialog has the same participants as the old: a) Same SDP session ID and version b) Same SDP session ID, new version c) New SDP session I personally would find a) and b) a bit odd because they mean that the media session migrates from one SIP dialog to another. Not mentioned in the Replaces spec as far as I can see, though not ruled out either, I suppose. I'm not sure what everyone involved in the discussions had in mind (or what implementations might do in cases a) and b) ...). 2) I seem to recall claims that INVITE/Replaces would not introduce significant loss of efficiency compared with UPDATE (or re-INVITE). If case c) is the only reasonable one above, this may not be so, since QoS and media encryption negotiation could be necessary. (It might even be the case that the new request fails call admission, even though the intent is to reuse the resources already allocated to the original call, because the entity making the decision does not know this is a replacement.) An in-dialog update mechanism might be able to avoid this. Indeed, with John Elwell's proposed amendments to the relevant RFCs, there might be no mention of media session parameters at all. I think this more lightweight procedure should at least be possible. 3) INVITE/Replaces does not necessarily pass through the same intermediaries as the original dialog. While this has to be dealt with in other scenarios (and some in the WG appear to regard this as a Good Thing), applications that like to "misuse" dialog stickiness will surely find it at least convenient to be in the path of the post-identity-change session. Presumably the answer to this is for such an application to be a B2BUA that provides GRUU+crypto-grid Contacts such that an INV/R from either side will pass through the application - but such a B2BUA is not transparent to the mechanism proposed in draft-ietf-sip-identity. 4) The hum preference for INVITE/Replaces seemed in large part to be motivated by difficulties with the >From header. Since there may be other state information that will need updating in the future, it would be a bad idea if the adoption of INVITE/Replaces for updating From were to be taken as a precedent for any other state update, which would not be bound by this restriction. A consistent and efficient way of updating state information is required, and INVITE/Replaces doesn't meet the efficiency criterion. The second hum choice was to introduce another header. This would work, at the cost of a certain amount of redundancy with From. In particular, draft-ietf-sip-identity would need enhancing to allow authentication of the new header as well as (or instead of) the From header. 5) All of which leads back to the least-favorite hum choice, which I feel is the best - to allow >From to change. The motivation in 3261 for keeping the >From URI immutable was (temporary) 2543-compatibility, and there is pretty clear language about not depending on that feature. I question whether there are 2543-only endpoints out there that are capable of deployment in realistic environments (that require SIPS and GRUU support for INVITE/Replaces authorization, for example). As pointed out in San Diego, the worst that would happen would be that a 2543-compliant UA would reject the re-INVITE or UPDATE with a 481. If the intent is at some point to follow through on the threat in 3261 to allow From to be changed, why not do it now, and allow Identity to be used for update within a dialog? Peter. Peter Mataga Converged Systems Division Avaya, Inc. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 16 07:22:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22230 for ; Tue, 16 Nov 2004 07:22:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU2OH-0003uZ-6x for sip-web-archive@ietf.org; Tue, 16 Nov 2004 07:24:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU2Dl-0001UT-I0; Tue, 16 Nov 2004 07:14:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU27b-00009z-Hl for sip@megatron.ietf.org; Tue, 16 Nov 2004 07:07:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21167 for ; Tue, 16 Nov 2004 07:07:41 -0500 (EST) Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU29n-0003Zs-V0 for sip@ietf.org; Tue, 16 Nov 2004 07:10:00 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0I7900501TKONE@siemenscomms.co.uk> for sip@ietf.org; Tue, 16 Nov 2004 12:05:14 +0000 (GMT) Received: from ntht206e.siemenscomms.co.uk ([137.223.247.52]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0I790053WTKJ93@siemenscomms.co.uk>; Tue, 16 Nov 2004 12:05:07 +0000 (GMT) Received: by ntht206e.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 16 Nov 2004 12:06:57 +0000 Content-return: allowed Date: Tue, 16 Nov 2004 12:06:57 +0000 From: "Elwell, John" Subject: RE: [Sip] SIP reinvite To: "'m. smadi'" , sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F26670252D57F@ntht201e> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7BIT X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7BIT This has long been a subject of discussion, most recently the message from Peter Mataga on 11th November. John (john.elwell@siemens.com) -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of m. smadi Sent: 08 November 2004 23:16 To: sip@ietf.org Subject: [Sip] SIP reinvite hello; my understanding of a SIP reinvite is that it modifies the media session. Is it capable of modifying the address of the send too? for example of A is talking to B, can A send a reinvite to B with C's address instead of its own address? Moe Smadi _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 16 09:50:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03855 for ; Tue, 16 Nov 2004 09:50:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU4hE-00076e-Ay for sip-web-archive@ietf.org; Tue, 16 Nov 2004 09:52:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU4Yu-0006N0-7o; Tue, 16 Nov 2004 09:44:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU4PV-0004Sh-VV for sip@megatron.ietf.org; Tue, 16 Nov 2004 09:34:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02592 for ; Tue, 16 Nov 2004 09:34:20 -0500 (EST) From: Mpierce1@aol.com Received: from imo-d04.mx.aol.com ([205.188.157.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU4Rj-0006i7-9M for sip@ietf.org; Tue, 16 Nov 2004 09:36:39 -0500 Received: from Mpierce1@aol.com by imo-d04.mx.aol.com (mail_out_v37_r3.8.) id d.b8.66a7d290 (4238); Tue, 16 Nov 2004 09:33:45 -0500 (EST) Message-ID: Date: Tue, 16 Nov 2004 09:33:45 EST Subject: Re: [Sip] -resource-priority-05.txt: Comments and Recommendations (3) To: coreya@nortelnetworks.com, sip@ietf.org MIME-Version: 1.0 X-Mailer: 6.0 for Windows XP sub 10500 X-Spam-Score: 0.3 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0964403507==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de --===============0964403507== Content-Type: multipart/alternative; boundary="part1_b8.66a7d290.2ecb69c9_boundary" --part1_b8.66a7d290.2ecb69c9_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 11/11/2004 6:12:39 PM Eastern Standard Time, coreya@nortelnetworks.com writes: > 3. With "preferential treatment" of messages based on R-P content, > should not scenarios be considered and listed in which a lower priority > message would need to be handled before a higher priority message? My > example: it would be wise to handle a BYE message with dsn.routine > before an INVITE with dsn.flash-override... At least in certain > situations, say when the BYE is sent as a result of a preemption event > (which the Reason header should likely indicate). > ---- Certainly something to consider, especially for DSN. > Yes, this is an interesting idea. However, as in the SS7 world, it is a bad idea to intentionally do things that might change the sequence of messages. In the example you mention, I would expect that some entity controlling preemption would simply send the BYE for the routine call before it sends the INVITE for the new flash-override call. If two different entities send these two messages, it is a virtually non-existent case that both messages would happen to be in the same queue waiting to be sent to even allow some entity to reorder them. What sometimes confuses this issue is what is done in SS7 (see draft-pierce-tsvwg-pref-treat-examples-01). SS7 has a "congestion priority level" associated with each signaling message, which is really a discard priority. Some (including me) have been confused into thinking that it changed the order to transmission, by sending the higher priority messages first. It does not. For the SS7 messages corresponding to BYE and INVITE and for routine and high priority calls, the congestion priority leveI defined for SS7 (and the corresponding SIP message) are as follows: IAM (INVITE) (routine) 0 IAM (INVITE (priority) 1 or 2 REL (BYE) (all) 1 This means that, if the signaling system 7 network gets congested, the new call setup messages (IAM) for routine calls are the first to be discarded (which helps to prevent catastrophic overload). The draft mentioned about only raised this issue as something to consider to provide "preferential treatment" for the various signaling messages, as you suggested in your question. But I would only see it as being similar to the SS7 implementation - determining which messages to discard when you have to discard something, not changing the order. It could use AF behavior with 3 drop probabilities. My initial belief is that such a mechanism is not needed, presuming that other techniques can ensure the the SIP signaling traffic will never get to the congestion point. If not, then I think we need to consider such a mechanism, but it's not something that needs to be described in the R-P header draft. Mike Pierce Artel --part1_b8.66a7d290.2ecb69c9_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message dated 11/11/2004 6:12:39 PM E= astern Standard Time, coreya@nortelnetworks.com writes:


3. With "preferential treat= ment" of messages based on R-P content,=20
should not scenarios be considered and listed in which a lower priority=20
message  would need to be handled before a higher priority message?=  My=20
example: it would be wise to handle a BYE message with dsn.routine=20
before an INVITE with dsn.flash-override...  At least in certain=20
situations, say when the BYE is sent as a result of a preemption event=20
(which the Reason header should likely indicate).
---- Certainly something to consider, especially for DSN.




Yes, this is an interesting idea. However, as in the SS7 world, it is a=20= bad idea to intentionally do things that might change the sequence of messag= es. In the example you mention, I would expect that some entity controlling=20= preemption would simply send the BYE for the routine call before it sends th= e INVITE for the new flash-override call. If two different entities send the= se two messages, it is a virtually non-existent case that both messages woul= d happen to be in the same queue waiting to be sent to even allow some entit= y to reorder them.

What sometimes confuses this issue is what is done in SS7 (see draft-pie= rce-tsvwg-pref-treat-examples-01). SS7 has a "congestion priority level" ass= ociated with each signaling message, which is really a discard priority. Som= e (including me) have been confused into thinking that it changed the order=20= to transmission, by sending the higher priority messages first. It does not.= For the SS7 messages corresponding to BYE and INVITE and for routine and hi= gh priority calls, the congestion priority leveI defined for SS7 (and the co= rresponding SIP message) are as follows:

IAM (INVITE) (routine)  0
IAM (INVITE  (priority) 1 or 2
REL (BYE)    (all)      1

This means that, if the signaling system 7 network gets congested, th= e new call setup messages (IAM) for routine calls are the first to be discar= ded (which helps to prevent catastrophic overload).

The draft mentioned about only raised this issue as something to conside= r to provide "preferential treatment" for the various signaling messages, as= you suggested in your question. But I would only see it as being similar to= the SS7 implementation - determining which messages to discard when you hav= e to discard something, not changing the order. It could use AF behavior wit= h 3 drop probabilities.

My initial belief is that such a mechanism is not needed, presuming that= other techniques can ensure the the SIP signaling traffic will never get to= the congestion point. If not, then I think we need to consider such a mecha= nism, but it's not something that needs to be described in the R-P header dr= aft.

Mike Pierce
Artel
--part1_b8.66a7d290.2ecb69c9_boundary-- --===============0964403507== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0964403507==-- From sip-bounces@ietf.org Tue Nov 16 10:01:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04827 for ; Tue, 16 Nov 2004 10:01:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU4sD-0007RI-Mq for sip-web-archive@ietf.org; Tue, 16 Nov 2004 10:04:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU4ec-0007AO-6z; Tue, 16 Nov 2004 09:49:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU4YN-0006KG-KP for sip@megatron.ietf.org; Tue, 16 Nov 2004 09:43:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03376 for ; Tue, 16 Nov 2004 09:43:30 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU4ab-0006x7-6v for sip@ietf.org; Tue, 16 Nov 2004 09:45:49 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 16 Nov 2004 06:55:59 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAGEgj3O010184; Tue, 16 Nov 2004 06:42:45 -0800 (PST) Received: from cisco.com ([161.44.79.125]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ANB49111; Tue, 16 Nov 2004 09:42:56 -0500 (EST) Message-ID: <419A11F0.2000601@cisco.com> Date: Tue, 16 Nov 2004 09:42:56 -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: "Peterson, Jon" References: <7927C67249E4AD43BC05B539AF0D129801AF4372@stntexch04.cis.neustar.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , sip@ietf.org Subject: [Sip] Re: Identity after reinvite X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Content-Transfer-Encoding: 7bit Jon, I generally agree with what you say. I wasn't trying to suggest that we hold up identity for connected-party support. I just wanted to get a clear understanding of the issues remaining. It seems that they are a bit more than just not getting confirmation of who you connected to. Paul Peterson, Jon wrote: > Well, yes, now one begins to appreciate why we originally coupled the > request identity problem with the response identity problem. :) > > In the next revision of the identity draft, which will incorporate the list > comments up to date, I do intend to include some text about dialogs. I agree > that the draft should apply to requests regardless of the dialog context. > > Moreover, I don't think the problem you raise below is limited merely to > re-INVITEs within a dialog. I believe it applies equally to BYE requests > sent in the backwards direction in a dialog. Ideally, the originator of the > dialog should have some assurance that requests sent in the backwards > direction come from the same identity that positively responded to the > dialog (i.e., the sender of the 200 and any provisional responses). > > In the absence of response identity, though, it is difficult for Alice to > have any such assurance. Equally, as you point out below, Bob can have no > assurance that his BYE or re-INVITE has been fielded by Alice if he is > unable to get a cryptographically-assured 200 response to his own requests. > Alice can't even be certain that she actually connected to Bob, thanks to > retargeting; this is the essence of the connected-ID/response identity > problem, and threatens to drag us back into the morass of retargeting > restrictions and so on that populated the sip-identity-02 draft. > > A lack of such a strong binding of backwards-direction BYE requests to the > dialog is a significant limitation; if BYE can be spoofed, then an attacker > can terminate existing dialogs. However, I'm not sure that the situation is > so dire as you suggest below. Without identity, it is trivial for any > attacker to impersonate a dialog-forming request. It is harder, though, for > an attacker to impersonate a response or mid-dialog request; this requires > the attacker to gather dialog state through eavesdropping or some similar > means. There is a very important distinction in sophistication between an > attacker who can merely formulate a plausible dialog-forming request with an > inappropriate From header field versus an attacker who can capture > dialog-forming requests and improvise appropriate responses (with correct > tags, correct Call-ID/CSeq, etc). > > Ultimately, request identity can protect against the former but not the > latter. While it is imperfect, I feel that this is an improvement over the > current situation. In cases where retargeting has not occurred, Alice will > see a re-INVITE or BYE from the expected URI (blessed, as you say); in cases > where retargeting has occurred, Alice may receive a warning from her UI that > an unexpected but assured URI has responded. Likewise, Bob will have to > trust, given the signature over the Contact header field in the > dialog-forming INVITE request, that his request in the backwards direction > is forwarded to the appropriate UA instance. In terms of what Bob's UI > should display, well, that really depends on the sophistication of attacks > you are willing to consider plausible. Personally, I don't think Bob's UI > should suggest any uncertainty about the matter. > > To improve on all this, we will ultimately need to solve the response > identity problem; however, I maintain that sip-identity as it stands will > have addressed the simplest and most common variety of impersonation, the > one that does not require any eavesdropping whatsoever. Once we feel we have > the right answer to request identity, we can revisit the response identity > problem and try to eliminate the remaining attacks. > > Jon Peterson > NeuStar, Inc. > > >>-----Original Message----- >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: Monday, November 15, 2004 3:58 PM >>To: Peterson, Jon; Cullen Jennings; sip@ietf.org >>Subject: Identity after reinvite >> >> >>Jon, >> >>After the meetings last week a question came to mind re the >>identity draft. >> >>First, I want to double check on usage in dialogs. The draft doesn't >>say, but I presume that every message in a dialog needs to be signed, >>not just the one that initiates a dialog. If that is a bad assumption, >>it would be good to hear why. >> >>Assuming that, what happens when the initial invite was from Alice to >>Bob, and later a reinvite is sent from Bob to Alice? Initially Bob knew >>that Alice had called, while Alice had no assurance about who she had >>reached with her call. The reinvite is from Bob, so if his identity is >>blessed, then Alice will know she is talking to Bob, but Bob will no >>longer have any assurance that he is still talking to Alice. >> >>This could even manifest itself in the UI presented to Alice and Bob. >>Initially Bob would have a "callerid" display showing Alice as a >>certified caller. But after putting Alice on hold and back off hold the >>display might stop showing Alice, or at least might show the identity as >>suspect. (There may be strong temptations to avoid this via some sort of >>hack.) >> >>I don't see any good solution for this other than solving the connected >>party id problem as well. >> >> Just checking my understanding, >> Paul >> > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 16 10:17:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07025 for ; Tue, 16 Nov 2004 10:17:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU576-0007ou-8b for sip-web-archive@ietf.org; Tue, 16 Nov 2004 10:19:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU4vw-0004oi-Mn; Tue, 16 Nov 2004 10:07:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU4ps-0001I8-QC for sip@megatron.ietf.org; Tue, 16 Nov 2004 10:01:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04807 for ; Tue, 16 Nov 2004 10:01:35 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU4s6-0007QB-C2 for sip@ietf.org; Tue, 16 Nov 2004 10:03:54 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 16 Nov 2004 07:16:03 -0800 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAGF0n3O020147; Tue, 16 Nov 2004 07:00:49 -0800 (PST) Received: from cisco.com ([161.44.79.125]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ANB50650; Tue, 16 Nov 2004 10:01:00 -0500 (EST) Message-ID: <419A162C.9060600@cisco.com> Date: Tue, 16 Nov 2004 10:01:00 -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 Subject: Re: [Sip] RE: Identity after reinvite References: <7927C67249E4AD43BC05B539AF0D129801AF4372@stntexch04.cis.neustar.com> <4199B4D0.30606@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , sip@ietf.org, "Peterson, Jon" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > > Peterson, Jon wrote: > >> Well, yes, now one begins to appreciate why we originally coupled the >> request identity problem with the response identity problem. :) >> >> In the next revision of the identity draft, which will incorporate the >> list >> comments up to date, I do intend to include some text about dialogs. I >> agree >> that the draft should apply to requests regardless of the dialog context. > > > I do believe there are issues related to mid-dialog requests, but I'm > not sure I agree that Paul's characterization is the problem. > > The problem is that, due to retargeting, the URI in the To field of the > INVITE may not identify the user that was eventually reached. In RFC > 3261, requests from the called party to the caller carry the value from > the original To field in the From. As a result, the requests will have a > From field value which does not actually correspond to the originator of > the reuqest. Very good point! > The identity service will then reject these requests. Hmm. Will the request be rejected, or will it just not get a authentication that it is valid? I suppose that is local policy. It may be necessary to permit this, without authentication, just to avoid breaking these common scenarios. > The solution, which rfc3261 warns of, is that a UA has to put its actual > identity in the From field URI, not what it saw in the To field of the > original request. Yes, this would be a good solution, if we can sort out the compatibility issues getting to it. > This will break all compatibility with rfc2543, but > will work with other rfc3261 compliant endpoints, since the URI is no > longer used for dialog identification. If we were going to switch to this, then it could begin with the first response to the invite. That would be the first step to really solving the connected-partiy-id problem. >> Moreover, I don't think the problem you raise below is limited merely to >> re-INVITEs within a dialog. I believe it applies equally to BYE requests >> sent in the backwards direction in a dialog. Yes, that is true. >> Ideally, the originator >> of the >> dialog should have some assurance that requests sent in the backwards >> direction come from the same identity that positively responded to the >> dialog (i.e., the sender of the 200 and any provisional responses). > > Useful, yes, but a different problem. I like the current scope of the > identity draft - to provide the identity of the sender of a request. > That is not a panacea for all of our security problems, of course. > >> In the absence of response identity, though, it is difficult for Alice to >> have any such assurance. Equally, as you point out below, Bob can have no >> assurance that his BYE or re-INVITE has been fielded by Alice if he is >> unable to get a cryptographically-assured 200 response to his own >> requests. >> Alice can't even be certain that she actually connected to Bob, thanks to >> retargeting; this is the essence of the connected-ID/response identity >> problem, and threatens to drag us back into the morass of retargeting >> restrictions and so on that populated the sip-identity-02 draft. >> >> A lack of such a strong binding of backwards-direction BYE requests to >> the >> dialog is a significant limitation; if BYE can be spoofed, then an >> attacker >> can terminate existing dialogs. This of course is considered a feature by some, who want a proxy to morph into a B2BUA just to send a BYE. > Doesn't sips prevent that? With sips, you won't be able to identify the > called party from the 200 OK, but it will guarantee that no one except > the party you reach can terminate the call. Well, if there are multiple hops that isn't proof against every possible attack. But it certainly makes it harder. And the kinds of attacks that would work here could probably just as well compromise the authentication server itself. > Indeed, it occurs to me that one can "simulate" response identity by > having the called party send an UPDATE or nearly any other request in > the reverse direction immediately upon receipt of the ACK. If you > structure the From field of that request as I have proposed above, the > net result provides a form of response identity - it tells you who was > reached. This doesnt tell you *why* it was reached (as redirection > would), but it seems valuable nonetheless. As I mention above, if the To were changed in responses, then the caller would know right away, without the extra request. But it wouldn't be signed. However then the way forward would be clear - have a callee suthentiation server sign the To header of responses. > However, I'm not sure that the situation is > >> so dire as you suggest below. Without identity, it is trivial for any >> attacker to impersonate a dialog-forming request. It is harder, >> though, for >> an attacker to impersonate a response or mid-dialog request; this >> requires >> the attacker to gather dialog state through eavesdropping or some similar >> means. There is a very important distinction in sophistication between an >> attacker who can merely formulate a plausible dialog-forming request >> with an >> inappropriate From header field versus an attacker who can capture >> dialog-forming requests and improvise appropriate responses (with correct >> tags, correct Call-ID/CSeq, etc). > > sips, of course, prevents this fully. > >> Ultimately, request identity can protect against the former but not the >> latter. > > But, its not supposed to. Its not supposed to provide all of the > security functions for sip - just the function which identifies the > originator of a request. Agreed. But is helpful to put it in its place in the bigger context. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 16 12:04:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19536 for ; Tue, 16 Nov 2004 12:04:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU6ms-00023j-KY for sip-web-archive@ietf.org; Tue, 16 Nov 2004 12:06:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU6g0-0000Uy-7O; Tue, 16 Nov 2004 11:59:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU6eo-0000Md-RX for sip@megatron.ietf.org; Tue, 16 Nov 2004 11:58:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18890 for ; Tue, 16 Nov 2004 11:58:16 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU6h0-0001t8-PL for sip@ietf.org; Tue, 16 Nov 2004 12:00:36 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 16 Nov 2004 09:12:41 -0800 X-BrightmailFiltered: true 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.10/8.12.6) with ESMTP id iAGGvd3O026792; Tue, 16 Nov 2004 08:57:40 -0800 (PST) Received: from [10.32.131.85] ([10.32.131.85]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AUA65106; Tue, 16 Nov 2004 08:57:38 -0800 (PST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 16 Nov 2004 07:59:16 -0800 Subject: Re: [Sip] mib-08 From: Cullen Jennings To: Steve Langstaff , Kevin Lingle Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit It's probably better not to ask exactly how much implementation there is going to be off this :-) On 11/9/04 11:36 AM, "Steve Langstaff" wrote: > KL: "we need to move the I-D forward so we can get a RFC that can get some > implementation experience." > > I thought that the I-D phase was the time to get the implementation > experience. Is it your intention that the RFC will be "Experimental" or > "Informational" before getting this implementation experience, and then become > a standard afterwards? > > -- > Steve Langstaff. > > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > Kevin Lingle > Sent: 08 November 2004 17:26 > To: Cullen Jennings > Cc: sip@ietf.org > Subject: Re: [Sip] mib-08 > [snip] > > we need to move the > I-D forward so we can get a RFC that can get some implementation > experience. > > kevin _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 16 12:08:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19983 for ; Tue, 16 Nov 2004 12:08:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU6qy-0002B1-Rz for sip-web-archive@ietf.org; Tue, 16 Nov 2004 12:10:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU6g1-0000VG-Kz; Tue, 16 Nov 2004 11:59:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU6ep-0000Mk-1A for sip@megatron.ietf.org; Tue, 16 Nov 2004 11:58:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18892 for ; Tue, 16 Nov 2004 11:58:16 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU6h2-0001tC-4j for sip@ietf.org; Tue, 16 Nov 2004 12:00:37 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 16 Nov 2004 09:12:43 -0800 X-BrightmailFiltered: true 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.10/8.12.6) with ESMTP id iAGGvd3Q026792; Tue, 16 Nov 2004 08:57:42 -0800 (PST) Received: from [10.32.131.85] ([10.32.131.85]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AUA65107; Tue, 16 Nov 2004 08:57:39 -0800 (PST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 16 Nov 2004 08:01:13 -0800 Subject: Re: [Sip] mib-08 From: Cullen Jennings To: "Romascanu, Dan (Dan)" , Kevin Lingle Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit Completely agree with what you guys are saying and we should not be expanding scope - it would just be good to get a few people to actually read it to make sure it makes sense (in a WGLC is fine). On 11/8/04 1:16 PM, "Romascanu, Dan (Dan)" wrote: > I agree with Kevin. At this point in time we should not change the scope of > the SIP MIB work, but rather focus on completing this phase of the work, in > the framework already agreed. This does not mean that more eyes to read and > comment on the MIB would do harm, quite the contrary - but changes should > focus on fixing problems, not introducing new items. > > After this phase is completed, the WG may be open to discussing possible > extensions which can be introduced in supplementary SIP MIB modules. > > Regards, > > Dan > > > >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On >> Behalf Of Kevin Lingle >> Sent: 08 November, 2004 7:26 PM >> To: Cullen Jennings >> Cc: sip@ietf.org >> Subject: Re: [Sip] mib-08 >> >> >> hi cullen, >> >> we had a relatively small number of outstanding issues to >> still resolve and were trying to get a -09 rev out a couple >> of weeks back. we didn't make that target because while working >> the outstanding issues, we also tried to accommodate a request >> to enhance user agent information. >> >> i don't, think we should try and include that in the initial >> offering of the user agent mib module. i think jean-francois >> is possibly in agreement with that now. he was going to take >> a crack at the issue but didn't have time yet. thus we haven't >> published rev -09 but hope to soon. i don't have any time to >> devote to the new issue of additional user agent information. >> so i'd like to leave that for the future. >> >> the delta's between -08 and -09 shouldn't be vast.... relative >> to the deltas between -07 and -08 ;) i think the "bunch of people" >> you refer to should be the wglc reviewers. i don't mind others >> also reviewing, but i don't want this to become yet another wglc on >> this draft (we've had two in as many years!). we need to move the >> I-D forward so we can get a RFC that can get some implementation >> experience. >> >> kevin >> >> Cullen Jennings wrote: >>> I tired to read this whole thing again and it made my head >> want to explode - >>> I think getting a bunch of people to read it again would be >> really good. >>> There has been some nice work done on it since the previous rev. >>> >>> >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 16 12:33:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22416 for ; Tue, 16 Nov 2004 12:33:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU7F1-0002nz-2e for sip-web-archive@ietf.org; Tue, 16 Nov 2004 12:35:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU754-0006kq-V9; Tue, 16 Nov 2004 12:25:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU6qV-0002Hd-5M for sip@megatron.ietf.org; Tue, 16 Nov 2004 12:10:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20226 for ; Tue, 16 Nov 2004 12:10:21 -0500 (EST) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU6sj-0002Dx-Uq for sip@ietf.org; Tue, 16 Nov 2004 12:12:42 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id iAGHAGaH022139 for ; Tue, 16 Nov 2004 11:10:17 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <4M325LCL>; Tue, 16 Nov 2004 18:10:16 +0100 Message-ID: <5160DD6EC1C0D41196D700508B5C1671051BA376@it2020exch001u.it.lucent.com> From: "Pianigiani, Jacopo (Jacopo)" To: "'sip@ietf.org'" Date: Tue, 16 Nov 2004 18:09:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Subject: [Sip] Boss-Secretary functionalities over SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Hi all, I am looking for an overview on SIP of the classic PABX Boss-Secretary functionality from the high level call flow perspective. Does anyone know where I could find this ? thanks in advance and kind regards _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 16 12:41:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23085 for ; Tue, 16 Nov 2004 12:41:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU7N3-00030Y-6m for sip-web-archive@ietf.org; Tue, 16 Nov 2004 12:44:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU75F-0006x0-CO; Tue, 16 Nov 2004 12:25:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU6xv-0004IC-PQ; Tue, 16 Nov 2004 12:18:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20991; Tue, 16 Nov 2004 12:18:01 -0500 (EST) From: Mpierce1@aol.com Received: from imo-d06.mx.aol.com ([205.188.157.38]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU709-0002Oq-TL; Tue, 16 Nov 2004 12:20:23 -0500 Received: from Mpierce1@aol.com by imo-d06.mx.aol.com (mail_out_v37_r3.8.) id c.1e6.2ef6420a (3924); Tue, 16 Nov 2004 12:17:19 -0500 (EST) Message-ID: <1e6.2ef6420a.2ecb901f@aol.com> Date: Tue, 16 Nov 2004 12:17:19 EST Subject: Re: [Sip] -resource-priority-05.txt: Comments and Recommendations (1) To: jmpolk@cisco.com, jgunn6@csc.com, oran@cisco.com MIME-Version: 1.0 X-Mailer: 6.0 for Windows XP sub 10500 X-Spam-Score: 0.3 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: An.Nguyen@ncs.gov, sip@ietf.org, sip-bounces@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1307579861==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c --===============1307579861== Content-Type: multipart/alternative; boundary="part1_1e6.2ef6420a.2ecb901f_boundary" --part1_1e6.2ef6420a.2ecb901f_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 11/15/2004 11:39:06 PM W. Europe Standard Time, jmpolk@cisco.com writes: > >The .03 draft (and I think also the .04 draft) had a paragraph that said > > "Namespaces do not describe how they relate to other existing > > namespaces, as each namespace is independent of other registrations." > > > >It doesn't seem to be in .05 > > see (the new) section 7.1 about the warnings of multiple namespaces > I don't read anything in 7.1 as saying what the previous versions said. What I think is needed is a very clear statement something like "neither this document nor namespaces specify the interrelationship or interworking between namespaces, such as mapping from one namespace to another at domain boundaries". That was my understanding of the previous agreement. As a result, the first bullet in Section 7.1, which states "There MUST be one order of priorities a SIP element has to process to", while talking about multiple namespaces in a message, seems to be wrong (or misunderstood), since it seems to require something about the relationship. In fact the example following this bullet list is trying to say something about the "acceptable" ways that the SIP element may process multiple namespaces. The part about what is "not acceptable" is not needed. The examples of incorrect order within each individual namespace are not allowed even without multiple namespaces. Since the document should say that it does not address interworking between namespaces, it should not contain this material. I don't know what the second bullet is trying to say. The third bullet is obvious, I thought, according to the rules of SIP. If not, this statement could be worded better. Section 7.1 should be deleted completely and replaced with a single statement something like I proposed above. ( I guess this will start a long series of e-mails on what I find wrong in -05.) Mike Pierce --part1_1e6.2ef6420a.2ecb901f_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message=20= dated 11/15/2004 11:39:06 PM W. Europe Standard Time, jmpolk@cisco.com write= s:


>The .03 draft (and I th= ink also the .04 draft) had a paragraph that said
>    "Namespaces do not describe how they relate to ot= her existing
>    namespaces, as each namespace is independent of o= ther registrations."
>
>It doesn't seem to be in .05

see (the new) section 7.1 about the warnings of multiple namespaces




I don't read anything in 7.1 as saying what the previous versions said.=20= What I think is needed is a very clear statement something like "neither thi= s document nor namespaces specify the interrelationship or interworking betw= een namespaces, such as mapping from one namespace to another at domain boun= daries". That was my understanding of the previous agreement.

As a result, the first bullet in Section 7.1, which states "There MUST b= e one order of priorities a SIP element has to process to", while talking ab= out multiple namespaces in a message, seems to be wrong (or misunderstood),=20= since it seems to require something about the relationship. In fact the exam= ple following this bullet list is trying to say something about the "accepta= ble" ways that the SIP element may process multiple namespaces. The part abo= ut what is "not acceptable" is not needed. The examples of incorrect order w= ithin each individual namespace are not allowed even without multiple namesp= aces.

Since the document should say that it does not address interworking betw= een namespaces, it should not contain this material.

I don't know what the second bullet is trying to say.

The third bullet is obvious, I thought, according to the rules of SIP. I= f not, this statement could be worded better.

Section 7.1 should be deleted completely and replaced with a single stat= ement something like I proposed above.

( I guess this will start a long series of e-mails on what I find wrong=20= in -05.)

Mike Pierce
--part1_1e6.2ef6420a.2ecb901f_boundary-- --===============1307579861== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1307579861==-- From sip-bounces@ietf.org Tue Nov 16 12:52:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24274 for ; Tue, 16 Nov 2004 12:52:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU7XI-0003La-TQ for sip-web-archive@ietf.org; Tue, 16 Nov 2004 12:54:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU7Qk-0003PZ-Ax; Tue, 16 Nov 2004 12:47:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU79h-0008Gq-Gv for sip@megatron.ietf.org; Tue, 16 Nov 2004 12:30:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22160 for ; Tue, 16 Nov 2004 12:30:11 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU7Bu-0002jJ-O7 for sip@ietf.org; Tue, 16 Nov 2004 12:32:33 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 16 Nov 2004 09:42:40 -0800 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.10/8.12.6) with ESMTP id iAGHTb3O014620; Tue, 16 Nov 2004 09:29:37 -0800 (PST) Received: from [10.32.131.85] ([10.32.131.85]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AUA67998; Tue, 16 Nov 2004 09:29:36 -0800 (PST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 16 Nov 2004 09:29:38 -0800 Subject: Re: [Sip] RE: Identity after reinvite From: Cullen Jennings To: Jonathan Rosenberg , Jon Peterson Message-ID: In-Reply-To: <4199B4D0.30606@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" , Paul H Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit On 11/16/04 12:05 AM, "Jonathan Rosenberg" wrote: > The solution, which rfc3261 warns of, is that a UA has to put its actual > identity in the From field URI, not what it saw in the To field of the > original request. This will break all compatibility with rfc2543, but > will work with other rfc3261 compliant endpoints, since the URI is no > longer used for dialog identification. At this point, I really see two paths forward for the connected party problem. 1) We do as suggested above and allow everything in the From and To other than the tags to be changed in a Re-INVITE or UPDATE. 2) We create a new thing that is like invite with replaces but add a new tag that is called say "subsumes". So if A and B have a dialog, or early dialog, and one of them wants to change a From. The UA sends an INVITE for a new dialog, indicates it replaces the old dialog, and indicates that it subsumes it. The subsumes flag would mean that any existing media session, qos reservations, etc did not change and got moved to the new dialog. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 16 12:54:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24417 for ; Tue, 16 Nov 2004 12:54:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU7Z1-0003PN-8T for sip-web-archive@ietf.org; Tue, 16 Nov 2004 12:56:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU7Qy-0003aU-AB; Tue, 16 Nov 2004 12:48:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU7GR-0001Du-Iy; Tue, 16 Nov 2004 12:37:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22742; Tue, 16 Nov 2004 12:37:08 -0500 (EST) Received: from amer-mta01.csc.com ([20.137.2.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU7Ic-0002u1-IK; Tue, 16 Nov 2004 12:39:30 -0500 Received: from csc.com (va-fch34.csc.com [20.6.39.227]) by amer-mta01.csc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id iAGHasgT009577; Tue, 16 Nov 2004 12:36:54 -0500 (EST) Subject: Re: [Sip] -resource-priority-05.txt: Comments and Recommendations (1) To: Mpierce1@aol.com X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Janet P Gunn Date: Tue, 16 Nov 2004 12:36:25 -0500 X-MIMETrack: Serialize by Router on VA-FCH34/SRV/CSC(Release 6.0.3|September 26, 2003) at 11/16/2004 12:37:48 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: An.Nguyen@ncs.gov, sip@ietf.org, jmpolk@cisco.com, oran@cisco.com, sip-bounces@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 05 is being rewritten as 06. The point about independance of namespaces has been made. Let's see what comes out in 06 before spending time on dissecting the fine points of 05, which will almost certainly be OBE. 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. ---------------------------------------------------------------------------------------- Mpierce1 @aol.com To: jmpolk@cisco.com, Janet P Gunn/FED/CSC@CSC, oran@cisco.com 11/16/2004 12:17 cc: An.Nguyen@ncs.gov, sip@ietf.org, sip-bounces@ietf.org PM Subject: Re: [Sip] -resource-priority-05.txt: Comments and Recommendations (1) In a message dated 11/15/2004 11:39:06 PM W. Europe Standard Time, jmpolk@cisco.com writes: >The .03 draft (and I think also the .04 draft) had a paragraph that said > "Namespaces do not describe how they relate to other existing > namespaces, as each namespace is independent of other registrations." > >It doesn't seem to be in .05 see (the new) section 7.1 about the warnings of multiple namespaces I don't read anything in 7.1 as saying what the previous versions said. What I think is needed is a very clear statement something like "neither this document nor namespaces specify the interrelationship or interworking between namespaces, such as mapping from one namespace to another at domain boundaries". That was my understanding of the previous agreement. As a result, the first bullet in Section 7.1, which states "There MUST be one order of priorities a SIP element has to process to", while talking about multiple namespaces in a message, seems to be wrong (or misunderstood), since it seems to require something about the relationship. In fact the example following this bullet list is trying to say something about the "acceptable" ways that the SIP element may process multiple namespaces. The part about what is "not acceptable" is not needed. The examples of incorrect order within each individual namespace are not allowed even without multiple namespaces. Since the document should say that it does not address interworking between namespaces, it should not contain this material. I don't know what the second bullet is trying to say. The third bullet is obvious, I thought, according to the rules of SIP. If not, this statement could be worded better. Section 7.1 should be deleted completely and replaced with a single statement something like I proposed above. ( I guess this will start a long series of e-mails on what I find wrong in -05.) 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 sip-bounces@ietf.org Tue Nov 16 13:39:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28162 for ; Tue, 16 Nov 2004 13:39:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU8HB-0004SZ-DU for sip-web-archive@ietf.org; Tue, 16 Nov 2004 13:42:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU855-00037i-5n; Tue, 16 Nov 2004 13:29:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU7ud-0001Lo-IW for sip@megatron.ietf.org; Tue, 16 Nov 2004 13:18:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26473 for ; Tue, 16 Nov 2004 13:18:41 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU7ws-000402-5i for sip@ietf.org; Tue, 16 Nov 2004 13:21:03 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 16 Nov 2004 10:33:06 -0800 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iAGII2P1012402; Tue, 16 Nov 2004 10:18:04 -0800 (PST) Received: from cisco.com ([161.44.79.125]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ANB69655; Tue, 16 Nov 2004 13:18:00 -0500 (EST) Message-ID: <419A4458.6030504@cisco.com> Date: Tue, 16 Nov 2004 13:18:00 -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: Cullen Jennings Subject: Re: [Sip] RE: Identity after reinvite References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" , Jon Peterson X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > On 11/16/04 12:05 AM, "Jonathan Rosenberg" wrote: > >>The solution, which rfc3261 warns of, is that a UA has to put its actual >>identity in the From field URI, not what it saw in the To field of the >>original request. This will break all compatibility with rfc2543, but >>will work with other rfc3261 compliant endpoints, since the URI is no >>longer used for dialog identification. > > At this point, I really see two paths forward for the connected party > problem. > > 1) We do as suggested above and allow everything in the From and To other > than the tags to be changed in a Re-INVITE or UPDATE. > > 2) We create a new thing that is like invite with replaces but add a new tag > that is called say "subsumes". So if A and B have a dialog, or early dialog, > and one of them wants to change a From. The UA sends an INVITE for a new > dialog, indicates it replaces the old dialog, and indicates that it subsumes > it. The subsumes flag would mean that any existing media session, qos > reservations, etc did not change and got moved to the new dialog. I vote for biting the bullet and changing From/To. It will initially cause some pain, but it will solve a number of problems in a clean way. We could define an option to be announced in Supported that indicates ability to do this. Could end up with: INVITE ... To: sip:bob@biloxi.com From: sip:alice@atlanta.com;tag=alice Supported: to-from-change Identity: aaaaaaaa (signed over From) Identity-Info: https://atlanta.com/cert ... 180 ... To: sip:charlie@chicago.com;tag=charlie From: sip:alice@atlanta.com;tag=alice Supported: to-from-change Identity: cccccccc (signed over To) Identity-Info: https://chicago.com/cert ... 200 ... To: sip:charlie@chicago.com;tag=charlie From: sip:alice@atlanta.com;tag=alice Supported: to-from-change Identity: cccccccc (signed over To) Identity-Info: https://chicago.com/cert ... ACK ... To: sip:charlie@chicago.com;tag=charlie From: sip:alice@atlanta.com;tag=alice Supported: to-from-change Identity: aaaaaaaa (signed over From) Identity-Info: https://atlanta.com/cert ... UPDATE ... To: sip:alice@atlanta.com;tag=alice From: sip:charlie@chicago.com;tag=charlie Supported: to-from-change Identity: cccccccc (signed over From) Identity-Info: https://chicago.com/cert ... 200 ... To: sip:alice@atlanta.com;tag=alice From: sip:charlie@chicago.com;tag=charlie Supported: to-from-change Identity: aaaaaaaa (signed over To) Identity-Info: https://atlanta.com/cert ... (Above shown as they look to receiving UA.) Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 16 13:56:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29391 for ; Tue, 16 Nov 2004 13:56:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU8Wz-0004qH-AP for sip-web-archive@ietf.org; Tue, 16 Nov 2004 13:58:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU8Ml-00068q-Mg; Tue, 16 Nov 2004 13:47:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU89Q-0003xF-BQ for sip@megatron.ietf.org; Tue, 16 Nov 2004 13:34:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27814 for ; Tue, 16 Nov 2004 13:33:59 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU8Bf-0004L8-KF for sip@ietf.org; Tue, 16 Nov 2004 13:36:19 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 16 Nov 2004 10:33:36 -0800 X-BrightmailFiltered: true Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id iAGIXQVx029210 for ; Tue, 16 Nov 2004 10:33:26 -0800 (PST) Received: from [10.32.245.156] (stealth-10-32-245-156.cisco.com [10.32.245.156]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id iAGIXmw4010544 for ; Tue, 16 Nov 2004 10:33:48 -0800 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [Sip] RE: Identity after reinvite Date: Tue, 16 Nov 2004 13:33:21 -0500 To: sip X-Mailer: Apple Mail (2.619) IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1100630029.305808"; x:"432200"; a:"rsa-sha1"; b:"nofws:2362"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"bQPaq80oQFjqTRjGRg659T1MgFu4ocYutGn1d6NaRF//ZeXL7r2IxMAKQ/NU4" "2aA9yZaHAcmXnqEbnLBlhEf/5xVUkIWMCoSgJgSHPWwnQvJz2O6xgTmeFnSad" "AXBhJM8fyfh/fcHhDwJ6QHzou2MRWpH8okkkQ+Dsl6kV0sy5M="; c:"From: David R Oran "; c:"Subject: Re: [Sip] RE: Identity after reinvite"; c:"Date: Tue, 16 Nov 2004 13:33:21 -0500" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit I have a strong preference for (1). I intensely dislike accumulated hacks and entropy in a protocol. Backward compatibility is an important property, but 2543 compatibility is fast becoming a a concrete block chained to our legs. We should declare a day that 2543 SIP implementations don't have to work right any more. I suggest we make that when 3261 goes to draft standard. We can couple that to decreasing entropy in another way - don't make more entropic stuff proposed standard until SIP itself gets to draft. Then we'll see what existing junk gets pulled from SIP because nobody implements it and be moving forward from a stable common base. Donning flame-retardant BVDs... Dave. On Nov 16, 2004, at 12:29 PM, Cullen Jennings wrote: > On 11/16/04 12:05 AM, "Jonathan Rosenberg" wrote: > >> The solution, which rfc3261 warns of, is that a UA has to put its >> actual >> identity in the From field URI, not what it saw in the To field of the >> original request. This will break all compatibility with rfc2543, but >> will work with other rfc3261 compliant endpoints, since the URI is no >> longer used for dialog identification. > > At this point, I really see two paths forward for the connected party > problem. > > 1) We do as suggested above and allow everything in the From and To > other > than the tags to be changed in a Re-INVITE or UPDATE. > > 2) We create a new thing that is like invite with replaces but add a > new tag > that is called say "subsumes". So if A and B have a dialog, or early > dialog, > and one of them wants to change a From. The UA sends an INVITE for a > new > dialog, indicates it replaces the old dialog, and indicates that it > subsumes > it. The subsumes flag would mean that any existing media session, qos > reservations, etc did not change and got moved to the new dialog. > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran@cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 16 13:58:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29632 for ; Tue, 16 Nov 2004 13:58:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU8ZN-0004v5-9I for sip-web-archive@ietf.org; Tue, 16 Nov 2004 14:00:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU8NJ-0006It-Ms; Tue, 16 Nov 2004 13:48:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU8Hr-00052g-6m; Tue, 16 Nov 2004 13:42:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28447; Tue, 16 Nov 2004 13:42:41 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU8K4-0004WZ-Us; Tue, 16 Nov 2004 13:45:02 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 16 Nov 2004 10:57:08 -0800 X-BrightmailFiltered: true Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iAGIfqw0022526; Tue, 16 Nov 2004 10:41:52 -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 KAA24435; Tue, 16 Nov 2004 10:42:04 -0800 (PST) Message-Id: <4.3.2.7.2.20041116120434.03868770@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Nov 2004 12:42:11 -0600 To: Mpierce1@aol.com, jgunn6@csc.com, oran@cisco.com From: "James M. Polk" Subject: Re: [Sip] -resource-priority-05.txt: Comments and Recommendations (1) In-Reply-To: <1e6.2ef6420a.2ecb901f@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: An.Nguyen@ncs.gov, sip@ietf.org, sip-bounces@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 comments in-line At 12:17 PM 11/16/2004 -0500, Mpierce1@aol.com wrote: >In a message dated 11/15/2004 11:39:06 PM W. Europe Standard Time, >jmpolk@cisco.com writes: > > >> >The .03 draft (and I think also the .04 draft) had a paragraph that said >> > "Namespaces do not describe how they relate to other existing >> > namespaces, as each namespace is independent of other registrations." >> > >> >It doesn't seem to be in .05 >> >>see (the new) section 7.1 about the warnings of multiple namespaces > >I don't read anything in 7.1 as saying what the previous versions said. correct I removed any comment about dependency because there may be a dependency in a domain - based on local policy, and this document should not make any comment that could contradict local policy. >What I think is needed is a very clear statement something like "neither >this document nor namespaces specify the interrelationship or interworking >between namespaces, such as mapping from one namespace to another at >domain boundaries". What you have above is unnecessary. If the document does not state a dependency, there is not one defined. >That was my understanding of the previous agreement. what previous agreement? >As a result, the first bullet in Section 7.1, which states "There MUST be >one order of priorities a SIP element has to process to", while talking >about multiple namespaces in a message, seems to be wrong (or misunderstood), It is not wrong, and I'm sorry if it is misunderstood. The section is about *ordering* of namespaces, and gives clear examples of ordering that is in line with this specification (to be) and clear examples of ordering that is not allowed in this specification (to be). > since it seems to require something about the relationship. no it does not. It either does, or it does not - there is no "seems". >In fact the example following this bullet list is trying to say something >about the "acceptable" ways that the SIP element may process multiple >namespaces. That it does, as it is a violation to reorder priority values just because another namespace is introduced. It primarily gives examples of how multiple namespaces can be interleaved in acceptable and unacceptable orders. >The part about what is "not acceptable" is not needed. I do not agree >The examples of incorrect order within each individual namespace are not >allowed even without multiple namespaces. Well, how many coders have you spoken or emailed with that understood this from the previous version(s)? I'll bet none. I have fielded many such communications - and in each given them an explanation just like what is in 7.1 and it becomes clear fairly quickly what was meant in previous versions (that was not explained well enough). >Since the document should say that it does not address interworking >between namespaces, it should not contain this material. giving examples to clarify a known area of confusion is a good thing - and will stay in the document. >I don't know what the second bullet is trying to say. that there can be more than one namespace in a message, and have 1 or more of these additional namespaces ignored >The third bullet is obvious, I thought, according to the rules of SIP. If >not, this statement could be worded better. Again, fielded a lot of questions about this, and put it in to clarify to coders that the order of RP headers in a message does not determine which matter. I reworded it already for the next version. >Section 7.1 should be deleted completely and replaced with a single >statement something like I proposed above. it will not be deleted, though it might be modified to add or clarify meaning >( I guess this will start a long series of e-mails on what I find wrong in >-05.) You, have an opinion? tell me it isn't so ;-) >Mike Pierce 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 sip-bounces@ietf.org Tue Nov 16 14:30:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02615 for ; Tue, 16 Nov 2004 14:30:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU93x-0005fC-VL for sip-web-archive@ietf.org; Tue, 16 Nov 2004 14:32:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU8s8-0003EI-LO; Tue, 16 Nov 2004 14:20:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU8rR-00032r-KG for sip@megatron.ietf.org; Tue, 16 Nov 2004 14:19:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01582 for ; Tue, 16 Nov 2004 14:19:28 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU8tg-0005Os-FR for sip@ietf.org; Tue, 16 Nov 2004 14:21:49 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 16 Nov 2004 11:31:58 -0800 Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iAGJIaw0019699; Tue, 16 Nov 2004 11:18:36 -0800 (PST) Received: from [192.168.1.100] (sjc-vpn4-1387.cisco.com [10.21.85.106]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFT83507; Tue, 16 Nov 2004 11:18:41 -0800 (PST) Message-ID: <419A5291.20002@cisco.com> Date: Tue, 16 Nov 2004 14:18:41 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David R Oran Subject: Re: [Sip] RE: Identity after reinvite References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: 7bit Cc: sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: 7bit David R Oran wrote: > I have a strong preference for (1). I intensely dislike accumulated > hacks and entropy in a protocol. Backward compatibility is an important > property, but 2543 compatibility is fast becoming a a concrete block > chained to our legs. > > We should declare a day that 2543 SIP implementations don't have to work > right any more. I suggest we make that when 3261 goes to draft standard. Cough... cough... [clutching chest as heart attack ensues] Draft standard? After the pain we went through to get rfc3261 issued I can't imagine doing that again... Practically speaking, based on the current rules for normative references, we are never going to be able to get to draft because RFC3261 has too many normative dependencies on protocols that are not at draft standard. I agree we should take approach (1). We could spec it in a backwards compatible way, too. If you change the From field in a request you send mid-dialog, and you get a 481, you know that something along the way got confused about the dialog identifiers. You can then retry, using the From URI from the original INVITE, and include some kind of flag to signal to the identity service not to try and insert the Identity header. Paul wrote: > We could define an option to be announced in Supported that indicates ability to do this. Could end up with: > > INVITE ... > To: sip:bob@biloxi.com > From: sip:alice@atlanta.com;tag=alice > Supported: to-from-change > Identity: aaaaaaaa (signed over From) > Identity-Info: https://atlanta.com/cert > ... > > 180 ... > To: sip:charlie@chicago.com;tag=charlie > From: sip:alice@atlanta.com;tag=alice > Supported: to-from-change > Identity: cccccccc (signed over To) > Identity-Info: https://chicago.com/cert > ... > > 200 ... > To: sip:charlie@chicago.com;tag=charlie > From: sip:alice@atlanta.com;tag=alice > Supported: to-from-change > Identity: cccccccc (signed over To) > Identity-Info: https://chicago.com/cert > ... > > ACK ... > To: sip:charlie@chicago.com;tag=charlie > From: sip:alice@atlanta.com;tag=alice > Supported: to-from-change > Identity: aaaaaaaa (signed over From) > Identity-Info: https://atlanta.com/cert > ... > > UPDATE ... > To: sip:alice@atlanta.com;tag=alice > From: sip:charlie@chicago.com;tag=charlie > Supported: to-from-change > Identity: cccccccc (signed over From) > Identity-Info: https://chicago.com/cert > ... > > 200 ... > To: sip:alice@atlanta.com;tag=alice > From: sip:charlie@chicago.com;tag=charlie > Supported: to-from-change > Identity: aaaaaaaa (signed over To) > Identity-Info: https://atlanta.com/cert > ... > > (Above shown as they look to receiving UA.) This helps only if you assume that the problem lies in the UA; I would be worred about other nasties along the way. In any case, I don't see a need for a Supported header field. The feature is supposed to work with any rfc3261 client out there. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 16 14:48:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04705 for ; Tue, 16 Nov 2004 14:48:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU9Lg-0006Cl-K2 for sip-web-archive@ietf.org; Tue, 16 Nov 2004 14:50:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU9Bt-0006Ed-Tc; Tue, 16 Nov 2004 14:40:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU96d-0005BT-UO for sip@megatron.ietf.org; Tue, 16 Nov 2004 14:35:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03242 for ; Tue, 16 Nov 2004 14:35:11 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU98u-0005oJ-BG for sip@ietf.org; Tue, 16 Nov 2004 14:37:32 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 16 Nov 2004 11:35:19 -0800 X-BrightmailFiltered: true Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id iAGJYaYt012386; Tue, 16 Nov 2004 11:34:38 -0800 (PST) Received: from [192.168.1.100] (sjc-vpn4-1387.cisco.com [10.21.85.106]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFT85026; Tue, 16 Nov 2004 11:34:29 -0800 (PST) Message-ID: <419A5645.4080507@cisco.com> Date: Tue, 16 Nov 2004 14:34:29 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Stredicke Subject: Re: [Sip] PING/PONG References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7bit inline. Christian Stredicke wrote: > Hi Spencer! > > You just mentioned another way of keeping TCP connections alive. Thats > good! > > So far we have: > > - CRLF (frequenly used today, but not indicated by user agent) > - STUN (same as CRLF) It is not the same. STUN solicits a response, which allows the client to determine if the NAT binding has changed, and if the server is still alive. > - PING/PONG or whatever (tbd, maybe superflous) I am very much against SIP-based keepalives. This turns into a huge scalability nightmare. It ends up being the dominant processing cost for proxies along with the dominant percentage of the signaling bandwidth, and it buys you nothing. > - OPTIONS (big overhead, but compatible) > - REGISTER (same as OPTIONS, but even bigger overhead) > - TCP low-level (how can this be addressed by the application?) > - No refreshing ("legacy device") > > Lets have a way to indicate these options and let the SBC decide what > method it likes/supports. Generally speaking, having multiple choices reduces interoperability. I think we should pick a solution, and only describe multiple ones if there is a compelling reason why multiple ones need to exist. Its worth pointing out that there are several functions these various keepalvies provide: 1. they keep nat bindings fresh 2. they allow the client to detect if its nat binding as seen by the server has changed 3. they allow the client to determine if the server is still alive and responding to messages 4. they allow the client to determine if the nat has dropped its binding altogether, so that packets are just going into the ether I *think* Bob is proposing another usage: 5. they allow the server to determine that the nat binding for the client has changed, so it can update its registration to reflect the new address Using the keepalive to update the binding on the server introduces security risks. If the keepalive is not authenticated, an attacker can inject the keepalives with a falsified source IP address, and as a result force incoming calls to be directed towards it. This is not acceptable. Thus, any request which causes the server to update any kind of bindings MUST be authenticated. I would rather not require the keepalives to be authenticated, as this substantially increases the cost of processing them. If you use unauthenticated STUN packets, the client detects that its nat binding has changed, and then it can re-register with a proper REGISTER, which can be authenticated and that can be used to update the binding, thus avoiding the attack. It is possible to use different mechanisms to address each of the 4 different issues above. An empty UDP packet or a CRLF on the TCP connection can address the binding keepalive issue but not any of the liveness checks. I strongly prefer a single solution that addresses all of these. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 16 15:17:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08090 for ; Tue, 16 Nov 2004 15:17:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU9nc-0006tk-8o for sip-web-archive@ietf.org; Tue, 16 Nov 2004 15:19:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU9jL-0004a4-EC; Tue, 16 Nov 2004 15:15:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU9eb-0002lT-PH for sip@megatron.ietf.org; Tue, 16 Nov 2004 15:10:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06988 for ; Tue, 16 Nov 2004 15:10:17 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU9gs-0006hV-4v for sip@ietf.org; Tue, 16 Nov 2004 15:12:39 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 16 Nov 2004 12:22:48 -0800 Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iAGK9Kw0028306 for ; Tue, 16 Nov 2004 12:09:21 -0800 (PST) Received: from [192.168.1.100] (sjc-vpn4-1387.cisco.com [10.21.85.106]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFT88318; Tue, 16 Nov 2004 12:09:43 -0800 (PST) Message-ID: <419A5E86.7030009@cisco.com> Date: Tue, 16 Nov 2004 15:09:42 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit Subject: [Sip] target topology in connect-reuse X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit During the sip meeting, we had a lot of discussion about the interactions between connect-reuse and the RFC 3263 mechanisms for load balancing. The current mechanism in connect-reuse will, I believe, create a single connection between a proxy in one domain and one of the servers in another domain. I think the objective of the connect-reuse mechanism is to produce a topology that looks like this: Please view in a fixed-width font such as Courier. +---------+ | | | | | Proxy | --- | | ------ +---------+ | |\ ----- | | +---------+ \\ --- | | \ | Proxy | \ -- | | \\ ---- | | +---------+ \ --- / +---------+ | | -\\ / | | ---- \ // | Proxy | -- \ / | | \X | | -- / \ +---------+ ---- / \ ---/ \\ +---------+ / ---- \ | | / -- | | / -- | Proxy | +---------+ / --- | | | | // ---- | | | | / --- +---------+ | Proxy | / --- | | -- | | +---------+ That is, between each proxy in domain A and each proxy in domain B, there is a single connection used for traffic in each direction. The transaction load is distributed across those connections proportiaonlly to the weight factors in the SRV records. This effect can be achieved if a connection is aliased to to an IP address, so that the connection reuse takes place *after* the DNS operations have occurred. This means that, when one proxy (A) opens a connection to another (B), A has to tell B that, when B wants to send requests to a particular IP address, it can use this connection instead. This needs to be done securely. I'd suggest the following. A opens a TCP connection to a server in B (based on the DNS lookup of B's domain). There is a TLS exhcange. A indicates to B an IP address for which it is an alias. B takes the domain from the subjectAltName in the cert presented by A, looks up the domain in DNS, and verifies that the offered IP address is listed in the DNS record. If so, it is accepted as an alias. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 16 15:27:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09225 for ; Tue, 16 Nov 2004 15:27:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU9xp-00078S-HL for sip-web-archive@ietf.org; Tue, 16 Nov 2004 15:30:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU9rz-0002Ej-AO; Tue, 16 Nov 2004 15:24:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU9nG-0007FV-I7 for sip@megatron.ietf.org; Tue, 16 Nov 2004 15:19:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08395 for ; Tue, 16 Nov 2004 15:19:12 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU9pW-0006wV-Ls for sip@ietf.org; Tue, 16 Nov 2004 15:21:35 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 16 Nov 2004 12:31:44 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iAGKIfOx006162; Tue, 16 Nov 2004 12:18:41 -0800 (PST) Received: from cisco.com ([161.44.79.125]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ANB81995; Tue, 16 Nov 2004 15:18:39 -0500 (EST) Message-ID: <419A609E.2070406@cisco.com> Date: Tue, 16 Nov 2004 15:18:38 -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 Subject: Re: [Sip] RE: Identity after reinvite References: <419A5291.20002@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: 7bit Cc: sip , David R Oran X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > > David R Oran wrote: > >> I have a strong preference for (1). I intensely dislike accumulated >> hacks and entropy in a protocol. Backward compatibility is an >> important property, but 2543 compatibility is fast becoming a a >> concrete block chained to our legs. >> >> We should declare a day that 2543 SIP implementations don't have to >> work right any more. I suggest we make that when 3261 goes to draft >> standard. > > Cough... cough... [clutching chest as heart attack ensues] > > Draft standard? After the pain we went through to get rfc3261 issued I > can't imagine doing that again... > > Practically speaking, based on the current rules for normative > references, we are never going to be able to get to draft because > RFC3261 has too many normative dependencies on protocols that are not at > draft standard. > > I agree we should take approach (1). We could spec it in a backwards > compatible way, too. If you change the From field in a request you send > mid-dialog, and you get a 481, you know that something along the way got > confused about the dialog identifiers. You can then retry, using the > From URI from the original INVITE, and include some kind of flag to > signal to the identity service not to try and insert the Identity header. The situation is a little more difficult to detect if you change the To in the response to the INVITE, which I was suggesting. Error responses don't help in this case. The to-from-change option would however help to know you could do this. But as you point out below, that doesn't help if the proxies on the path get upset. To get around that problem we could use Proxy-Require, but that is pretty heavy handed. Or we could use some more cooperative option negotiation, where all the proxies must concur before the UAS can use the feature. > Paul wrote: > >> We could define an option to be announced in Supported that indicates >> ability to do this. Could end up with: >> >> INVITE ... >> To: sip:bob@biloxi.com >> From: sip:alice@atlanta.com;tag=alice >> Supported: to-from-change >> Identity: aaaaaaaa (signed over From) >> Identity-Info: https://atlanta.com/cert >> ... >> >> 180 ... >> To: sip:charlie@chicago.com;tag=charlie >> From: sip:alice@atlanta.com;tag=alice >> Supported: to-from-change >> Identity: cccccccc (signed over To) >> Identity-Info: https://chicago.com/cert >> ... >> >> 200 ... >> To: sip:charlie@chicago.com;tag=charlie >> From: sip:alice@atlanta.com;tag=alice >> Supported: to-from-change >> Identity: cccccccc (signed over To) >> Identity-Info: https://chicago.com/cert >> ... >> >> ACK ... >> To: sip:charlie@chicago.com;tag=charlie >> From: sip:alice@atlanta.com;tag=alice >> Supported: to-from-change >> Identity: aaaaaaaa (signed over From) >> Identity-Info: https://atlanta.com/cert >> ... >> >> UPDATE ... >> To: sip:alice@atlanta.com;tag=alice >> From: sip:charlie@chicago.com;tag=charlie >> Supported: to-from-change >> Identity: cccccccc (signed over From) >> Identity-Info: https://chicago.com/cert >> ... >> >> 200 ... >> To: sip:alice@atlanta.com;tag=alice >> From: sip:charlie@chicago.com;tag=charlie >> Supported: to-from-change >> Identity: aaaaaaaa (signed over To) >> Identity-Info: https://atlanta.com/cert >> ... >> >> (Above shown as they look to receiving UA.) > > > This helps By "this" I assume you mean the to-from-change option? > only if you assume that the problem lies in the UA; I would > be worred about other nasties along the way. For changing on subsequent requests within the dialog, what nasties are you thinking of? I think only a call stateful proxy would notice, and it seems there aren't many of those. Of course there are B2BUAs, but they at least *ought* to be UAs and behave as such. Maybe there would be problems with SBCs, and with "transparent" B2BUAs that normally act as proxy but morph into UAs on occasion. But I think these nasties will have other problems with Identity too. I suppose we must however confront these. > In any case, I don't see a need for a Supported header field. The > feature is supposed to work with any rfc3261 client out there. Other than just hoping for the best, why would we expect existing 3261 clients to work with this change? Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 16 17:39:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03732 for ; Tue, 16 Nov 2004 17:39:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUC12-0005a3-6U for sip-web-archive@ietf.org; Tue, 16 Nov 2004 17:41:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUBky-0005NN-3h; Tue, 16 Nov 2004 17:25:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUBA7-0003Jl-C8 for sip@megatron.ietf.org; Tue, 16 Nov 2004 16:46:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20766 for ; Tue, 16 Nov 2004 16:46:53 -0500 (EST) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUBCO-0001Xp-KC for sip@ietf.org; Tue, 16 Nov 2004 16:49:17 -0500 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id iAGLkN10031069; Tue, 16 Nov 2004 21:46:23 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Tue, 16 Nov 2004 16:46:23 -0500 Message-ID: <7927C67249E4AD43BC05B539AF0D129801AF4377@stntexch04.cis.neustar.com> From: "Peterson, Jon" To: "'Paul Kyzivat'" , Jonathan Rosenberg Subject: RE: [Sip] RE: Identity after reinvite Date: Tue, 16 Nov 2004 16:46:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: Cullen Jennings , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd > > The problem is that, due to retargeting, the URI in the To field of the > > INVITE may not identify the user that was eventually reached. In RFC > > 3261, requests from the called party to the caller carry the value from > > the original To field in the From. As a result, the requests will have a > > From field value which does not actually correspond to the originator of > > the reuqest. > > Very good point! This is a more significant problem with mid-dialog requests and the request identity system, agreed. > > The identity service will then reject these requests. > > Hmm. Will the request be rejected, or will it just not get a > authentication that it is valid? I suppose that is local policy. It may > be necessary to permit this, without authentication, just to avoid > breaking these common scenarios. Yes, this is the crux of the matter. The text in Section 6 of sip-identity-03 says the following: If the identity field contains a SIP or SIPS URI, the authentication service MUST extract the hostname portion of the identity field and compare it to the domain(s) for which it is responsible... If the authentication service is not responsible for the identity in question, it MAY handle the request normally, but it MUST NOT add an Identity header; see below for more information on authentication service handling of an existing Identity header. So it isn't that the auth service will reject the request; it MAY just forward the request normally. What will happen in that instance? Well, if the auth service role is instantiated by a proxy server, it will forward the request in accordance with the URI without adding an Identity header; it won't challenge the request, or what have you. > > The solution, which rfc3261 warns of, is that a UA has to put its actual > > identity in the From field URI, not what it saw in the To field of the > > original request. > > Yes, this would be a good solution, if we can sort out the compatibility > issues getting to it. I am extremely wary of predicating request identity on solving the connected-party problem, in part because I believe doing so will dictate a direction for the response identity problem. If we go down this path here (changing the From header field value), we will be forced to do the same for response identity. I think this is the wrong approach, as sip-identity-02 suggested; I think we are sacrificing certain valuable security properties for the long term if we go down this path. I have a number of arguments about this, but here are just three: - Identity will succeed in the marketplace if it can be used opportunistically. Requiring UAs to change the From header field in this fashion forces them to become identity-aware, which is an impediment to adoption. Basically, we force UAs to be either backwards-compliant with RFC2543 or compliant with Identity. Tough choice, especially given that the UA might not be aware of its need to be either of those things. - I also question whether or not the callee UA will even know which identity it needs to stick in the From header of requests in the backwards direction: after all, if the UA is registered under multiple AoRs, what exactly about the dialog-forming request will tell it definitively which identity it is supposed to use? While in some cases, this could be inferred from the Request-URI of the dialog-forming requests, it won't be sufficient in all cases, I think. The previous hop (last proxy server to handle the request) might also be a hint. Now, it could be that there's a good answer to this question, but if so, we need to know that answer. - Retargeting is inherently insecure, and no amount of wiggling with the sip-identity mechanism will repair this. If Alice sent a request to Bob, and a new request in the backwards direction comes from Edgar, I think there is -no- circumstance in which Alice should not view this as a potential security risk, regardless of the presence or absence of an Identity header, SIPS, or what have you. Trying to explain this aware flies in the face of common sense, and will be incomprehensible to actual users who will need to make security decisions based on the evidence collected from the protocol by their user agent. > > This will break all compatibility with rfc2543, but > > will work with other rfc3261 compliant endpoints, since the URI is no > > longer used for dialog identification. > > If we were going to switch to this, then it could begin with the first > response to the invite. That would be the first step to really solving > the connected-partiy-id problem. Not just 'could begin' but 'should begin'. If the identity you see in the response to the INVITE does not equal the identity you see in requests in the backwards direction, I believe that is extremely problematic. Yes, this is what I mean by solving the response identity problem. > > Doesn't sips prevent that? With sips, you won't be able to identify the > > called party from the 200 OK, but it will guarantee that no one except > > the party you reach can terminate the call. > > Well, if there are multiple hops that isn't proof against every possible > attack. But it certainly makes it harder. And the kinds of attacks that > would work here could probably just as well compromise the > authentication server itself. > Don't forget, for example, that SIPS does not apply after the domain indicated by the Request-URI of the request, and so on. SIPS is not a powerful mechanism. Until we all acknowledge that we were mistaken in our formulation in RFC3261, and that SIPS, when present, signifies unambiguously that TLS should be used end-to-end, I do not think SIPS can be said to solve any of our problems. Once we have the connect-reuse mechanism nailed down firmly, I think it will be possible to shift to that understanding of SIPS, if we want to. > > Indeed, it occurs to me that one can "simulate" response identity by > > having the called party send an UPDATE or nearly any other request in > > the reverse direction immediately upon receipt of the ACK. If you > > structure the From field of that request as I have proposed above, the > > net result provides a form of response identity - it tells you who was > > reached. This doesnt tell you *why* it was reached (as redirection > > would), but it seems valuable nonetheless. > > As I mention above, if the To were changed in responses, then the caller > would know right away, without the extra request. But it wouldn't be > signed. However then the way forward would be clear - have a callee > suthentiation server sign the To header of responses. > Yet more justification for the idea that this solution must share its core with our longer-term response identity mechanism. > >> There is a very important distinction in sophistication between an > >> attacker who can merely formulate a plausible dialog-forming request with an > >> inappropriate From header field versus an attacker who can capture > >> dialog-forming requests and improvise appropriate responses (with correct > >> tags, correct Call-ID/CSeq, etc). > > > > sips, of course, prevents this fully. SIPS would be sufficient if it were not crippled by restrictions about the final administrative domain, and the ambiguity about finality in the context of retargeting. Jon Peterson NeuStar, Inc. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 16 17:47:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04754 for ; Tue, 16 Nov 2004 17:47:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUC8v-0005qM-8a for sip-web-archive@ietf.org; Tue, 16 Nov 2004 17:49:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUBvh-0003Ry-2U; Tue, 16 Nov 2004 17:36:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUBUp-0004jh-Kl for sip@megatron.ietf.org; Tue, 16 Nov 2004 17:08:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26816 for ; Tue, 16 Nov 2004 17:08:17 -0500 (EST) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUBX7-0003KU-7o for sip@ietf.org; Tue, 16 Nov 2004 17:10:41 -0500 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id iAGM7l10032325; Tue, 16 Nov 2004 22:07:47 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Tue, 16 Nov 2004 17:07:47 -0500 Message-ID: <7927C67249E4AD43BC05B539AF0D129801AF4379@stntexch04.cis.neustar.com> From: "Peterson, Jon" To: "'Cullen Jennings'" , Jonathan Rosenberg Subject: third alternative (was RE: [Sip] RE: Identity after reinvite) Date: Tue, 16 Nov 2004 17:07:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: sip@ietf.org, Paul H Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 I would like to suggest a third alternative: 3) Change nothing about in To/From. Requests in the backwards direction in a dialog may go through the authentication service of the domain indicated in the host portion of the From header of the request. If that is not possible, do not supply request identity for such messages. While this seem like a non-starter in retargeting cases, requests get retargeted for a reason. If the dialog-forming request was appropriately delivered to the domain indicated in the Request-URI (biloxi.example.com), and that domain chose to forward the request to another domain (chicago.example.com), it did so because some entity was authorized to add the chicago URI as a contact for the biloxi URI. In other words, this approach views retargeting as if the callee's UA were actually registered at biloxi "through" chicago, and that when the UA receives a dialog-forming request, it is the To header that determines who should assert identity for new requests in the backwards direction. In cases where the user contacted at chicago does not possess credentials to authenticate themselves to biloxi, I think it would be fair to say that requests in the backwards direction should not get an Identity header. To go any further, I think, requires us to solve the response identity problem. This approach is, I think, forward-compatible with any reasonable solution to the response identity problem, though. The primary challenge of this approach is insuring that requests in the backwards direction will actually go through the authentication service of biloxi.com, since in many cases they ordinarily might not. If biloxi.com Record-Routes its auth service in the dialog-forming request, this would provide the right assurance (and seems plausible from a deployment perspective); however, if chicago.com also Record-Routes itself, for example, then the callee will not be able to form a direct TLS connection to biloxi.com. It is also possible that the callee's UA could force a Route header to connect to biloxi.com first, but this requires the callee's UA to be identity-aware, which is undesirable when sip-identity is applied opportunistically. But it isn't immediately clear how this is any different from normal cases of request identity outside the scope of a dialog. There are any number of possible reasons why the calling UA might not be able to connect directly via TLS to its auth service (including interposing intermediaries and/or the inability of the UA to force a Route through their auth service), and the draft currently just says that we shouldn't provide Identity when we cannot get the needed relationship between the UA and auth service. I've gotten a lot of feedback (from Paul, Kumiko and others) that we should try to weaken the requirement for direct TLS, and I intend to add some text to the next version about some specific ways in which it is still acceptable to provide identity even if a direct TLS connection cannot be formed. Certain forms of weakness there could be beneficial to this approach. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Tuesday, November 16, 2004 9:30 AM > To: Jonathan Rosenberg; Jon Peterson > Cc: Paul H Kyzivat; sip@ietf.org > Subject: Re: [Sip] RE: Identity after reinvite > > > On 11/16/04 12:05 AM, "Jonathan Rosenberg" wrote: > > > The solution, which rfc3261 warns of, is that a UA has to > put its actual > > identity in the From field URI, not what it saw in the To > field of the > > original request. This will break all compatibility with > rfc2543, but > > will work with other rfc3261 compliant endpoints, since the > URI is no > > longer used for dialog identification. > > At this point, I really see two paths forward for the connected party > problem. > > 1) We do as suggested above and allow everything in the From > and To other > than the tags to be changed in a Re-INVITE or UPDATE. > > 2) We create a new thing that is like invite with replaces > but add a new tag > that is called say "subsumes". So if A and B have a dialog, > or early dialog, > and one of them wants to change a From. The UA sends an > INVITE for a new > dialog, indicates it replaces the old dialog, and indicates > that it subsumes > it. The subsumes flag would mean that any existing media session, qos > reservations, etc did not change and got moved to the new dialog. > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 16 18:18:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08994 for ; Tue, 16 Nov 2004 18:18:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUCdX-0006qn-3N for sip-web-archive@ietf.org; Tue, 16 Nov 2004 18:21:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUCVZ-0003yv-35; Tue, 16 Nov 2004 18:13:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUCOp-0000I8-8C for sip@megatron.ietf.org; Tue, 16 Nov 2004 18:06:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07169 for ; Tue, 16 Nov 2004 18:06:08 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUCR6-0006Vj-2b for sip@ietf.org; Tue, 16 Nov 2004 18:08:33 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 16 Nov 2004 15:20:54 -0800 X-BrightmailFiltered: true Received: from flask.cisco.com (flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iAGN5nOx013626; Tue, 16 Nov 2004 15:05:50 -0800 (PST) Received: from cisco.com ([161.44.79.125]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ANB98489; Tue, 16 Nov 2004 18:05:47 -0500 (EST) Message-ID: <419A87CB.3030505@cisco.com> Date: Tue, 16 Nov 2004 18:05:47 -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: "Peterson, Jon" Subject: Re: [Sip] RE: Identity after reinvite References: <7927C67249E4AD43BC05B539AF0D129801AF4377@stntexch04.cis.neustar.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Content-Transfer-Encoding: 7bit Jon, One of your key points below seems to be to resist tying any of these remedies to the identity draft itself. I have no problem with that - despite the remaining problems the identity feature does add value and need not wait for solution of the other problems. I didn't intend to imply otherwise. More comments below. Paul Peterson, Jon wrote: >>>The problem is that, due to retargeting, the URI in the To field of the >>>INVITE may not identify the user that was eventually reached. In RFC >>>3261, requests from the called party to the caller carry the value from >>>the original To field in the From. As a result, the requests will have a > >>>From field value which does not actually correspond to the originator of >>>the reuqest. >> >>Very good point! > > This is a more significant problem with mid-dialog requests and the request > identity system, agreed. > >> > The identity service will then reject these requests. >> >>Hmm. Will the request be rejected, or will it just not get a >>authentication that it is valid? I suppose that is local policy. It may >>be necessary to permit this, without authentication, just to avoid >>breaking these common scenarios. > > Yes, this is the crux of the matter. The text in Section 6 of > sip-identity-03 says the following: > > If the identity field contains a SIP or SIPS URI, > the authentication service MUST extract the hostname portion of the > identity field and compare it to the domain(s) for which it is > responsible... > If the authentication service is not responsible for the identity in > question, it MAY handle the request normally, but it MUST NOT add an > Identity header; see below for more information on authentication > service handling of an existing Identity header. > > So it isn't that the auth service will reject the request; it MAY just > forward the request normally. What will happen in that instance? Well, if > the auth service role is instantiated by a proxy server, it will forward the > request in accordance with the URI without adding an Identity header; it > won't challenge the request, or what have you. Good. You confirm what I was assuming. >>>The solution, which rfc3261 warns of, is that a UA has to put its actual >>>identity in the From field URI, not what it saw in the To field of the >>>original request. >> >>Yes, this would be a good solution, if we can sort out the compatibility >>issues getting to it. > > I am extremely wary of predicating request identity on solving the > connected-party problem, in part because I believe doing so will dictate a > direction for the response identity problem. If we go down this path here > (changing the From header field value), we will be forced to do the same for > response identity. I think this is the wrong approach, as sip-identity-02 > suggested; I think we are sacrificing certain valuable security properties > for the long term if we go down this path. I agree the basic request identity problem is separable from the others. But it does seem that connected-party, response-identity, and reverse direction requests in dialog are all entangled, and that changing to/from may be a single solution good for all of them. > I have a number of arguments about this, but here are just three: > > - Identity will succeed in the marketplace if it can be used > opportunistically. Requiring UAs to change the From header field in this > fashion forces them to become identity-aware, which is an impediment to > adoption. Basically, we force UAs to be either backwards-compliant with > RFC2543 or compliant with Identity. Tough choice, especially given that the > UA might not be aware of its need to be either of those things. Agree. > - I also question whether or not the callee UA will even know which identity > it needs to stick in the From header of requests in the backwards direction: > after all, if the UA is registered under multiple AoRs, what exactly about > the dialog-forming request will tell it definitively which identity it is > supposed to use? While in some cases, this could be inferred from the > Request-URI of the dialog-forming requests, it won't be sufficient in all > cases, I think. The previous hop (last proxy server to handle the request) > might also be a hint. Now, it could be that there's a good answer to this > question, but if so, we need to know that answer. There are many reasons why a UA with multiple registrations needs to know which one was the source of an incoming call. And the UA can easily achieve this by using distinct contacts in the registrations. I don't think we need to lose sleep over those that choose not to do so. > - Retargeting is inherently insecure, and no amount of wiggling with the > sip-identity mechanism will repair this. If Alice sent a request to Bob, and > a new request in the backwards direction comes from Edgar, I think there is > -no- circumstance in which Alice should not view this as a potential > security risk, regardless of the presence or absence of an Identity header, > SIPS, or what have you. Trying to explain this aware flies in the face of > common sense, and will be incomprehensible to actual users who will need to > make security decisions based on the evidence collected from the protocol by > their user agent. Of course it is a potential security risk, which is why it is good to report that it happened. (A good UA will hopefully note that the connected party is not the called party and make a big fuss at its UI.) But it is still good to know who in fact you ended up talking to. This is however not in any way a surprising event. It happens all the time for a variety of reasons. Usually it is detected because the voice you hear isn't the one you expected to hear. The fact that we can do better than that is itself of value. But I don't think we need to deprecate the call any further. While it would be good to know more about why the retargetting occured, in most cases people will do fine without that. >>>This will break all compatibility with rfc2543, but >>>will work with other rfc3261 compliant endpoints, since the URI is no >>>longer used for dialog identification. >> >>If we were going to switch to this, then it could begin with the first >>response to the invite. That would be the first step to really solving >>the connected-partiy-id problem. > > Not just 'could begin' but 'should begin'. If the identity you see in the > response to the INVITE does not equal the identity you see in requests in > the backwards direction, I believe that is extremely problematic. Yes, this > is what I mean by solving the response identity problem. The 'could' was a response to Jonathan, who didn't seem to have that in mind. Re having the identity in a subsequent request differ from the one in the response to the invite: I'm not sure it is so problematic. The identity can change in mid call, and that will then probably first manifest itself in the first message sent following the identity change. This could happen if one party is a B2BUA or gateway. Perhaps it would be more problematic if the change was first seen in some random message (e.g. INFO or OPTIONS) rather than in a message intended to change dialog state (e.g. INVITE or UPDATE). But it is only problematic if we enact some rule that says changes in identity must be formally announced. >>>Doesn't sips prevent that? With sips, you won't be able to identify the >>>called party from the 200 OK, but it will guarantee that no one except >>>the party you reach can terminate the call. >> >>Well, if there are multiple hops that isn't proof against every possible >>attack. But it certainly makes it harder. And the kinds of attacks that >>would work here could probably just as well compromise the >>authentication server itself. > > Don't forget, for example, that SIPS does not apply after the domain > indicated by the Request-URI of the request, and so on. SIPS is not a > powerful mechanism. Until we all acknowledge that we were mistaken in our > formulation in RFC3261, and that SIPS, when present, signifies unambiguously > that TLS should be used end-to-end, I do not think SIPS can be said to solve > any of our problems. Once we have the connect-reuse mechanism nailed down > firmly, I think it will be possible to shift to that understanding of SIPS, > if we want to. > >>>Indeed, it occurs to me that one can "simulate" response identity by >>>having the called party send an UPDATE or nearly any other request in >>>the reverse direction immediately upon receipt of the ACK. If you >>>structure the From field of that request as I have proposed above, the >>>net result provides a form of response identity - it tells you who was >>>reached. This doesnt tell you *why* it was reached (as redirection >>>would), but it seems valuable nonetheless. >> >>As I mention above, if the To were changed in responses, then the caller >>would know right away, without the extra request. But it wouldn't be >>signed. However then the way forward would be clear - have a callee >>suthentiation server sign the To header of responses. > > Yet more justification for the idea that this solution must share its core > with our longer-term response identity mechanism. > >>>>There is a very important distinction in sophistication between an >>>>attacker who can merely formulate a plausible dialog-forming request >>>>with an >>>>inappropriate From header field versus an attacker who can capture >>>>dialog-forming requests and improvise appropriate responses (with >>>>correct >>>>tags, correct Call-ID/CSeq, etc). >>> >>>sips, of course, prevents this fully. > > SIPS would be sufficient if it were not crippled by restrictions about the > final administrative domain, and the ambiguity about finality in the context > of retargeting. > > Jon Peterson > NeuStar, Inc. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 16 19:45:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16497 for ; Tue, 16 Nov 2004 19:45:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUDzF-0000UV-4G for sip-web-archive@ietf.org; Tue, 16 Nov 2004 19:47:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUDtH-0001IP-D7; Tue, 16 Nov 2004 19:41:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUDnw-00007B-MV for sip@megatron.ietf.org; Tue, 16 Nov 2004 19:36:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15433 for ; Tue, 16 Nov 2004 19:36:09 -0500 (EST) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUDqF-0000ID-DN for sip@ietf.org; Tue, 16 Nov 2004 19:38:36 -0500 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id iAH0Zb10005663; Wed, 17 Nov 2004 00:35:37 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Tue, 16 Nov 2004 19:35:37 -0500 Message-ID: <7927C67249E4AD43BC05B539AF0D129801AF437D@stntexch04.cis.neustar.com> From: "Peterson, Jon" To: "'Paul Kyzivat'" Subject: RE: [Sip] RE: Identity after reinvite Date: Tue, 16 Nov 2004 19:35:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: Cullen Jennings , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Paul, I think we're mostly agreed here, but a couple of small points. > > - I also question whether or not the callee UA will even know which identity > > it needs to stick in the From header of requests in the backwards direction: > > after all, if the UA is registered under multiple AoRs, what exactly about > > the dialog-forming request will tell it definitively which identity it is > > supposed to use? While in some cases, this could be inferred from the > > Request-URI of the dialog-forming requests, it won't be sufficient in all > > cases, I think. The previous hop (last proxy server to handle the request) > > might also be a hint. Now, it could be that there's a good answer to this > > question, but if so, we need to know that answer. > > There are many reasons why a UA with multiple registrations needs to > know which one was the source of an incoming call. And the UA can easily > achieve this by using distinct contacts in the registrations. I don't > think we need to lose sleep over those that choose not to do so. I agree that what you say above is the right overall strategy for SIP deployments, but I also believe that retargeting would not occur in the case you describe above. Retargeting occurs when some circumstance like this prevails: My AoR is jon@biloxi.example.com, and for some reason my current UA can only register at, say, chicago.example.com, and accordingly I am forced to put a contact in biloxi.example.com for jon@chicago.example.com. In that case, I can't differentiate whether a request I receive had originally been sent through biloxi.example.com or chicago.example.com from anything other than the To header. In that case, it's not clear what the "actual" identity of the UA would be, other than just what it sees in the To header. This is significant, given the original proposal on which I was commenting: >>>The solution, which rfc3261 warns of, is that a UA has to put its actual >>>identity in the From field URI, not what it saw in the To field of the >>>original request. My point is that this is less useful, if not circular, in cases of retargeting, and the retargeting cases are the ones we are trying to solve. There's no reason, just because of some transitive registrations, that the chicago URI is any more "actual" than the biloxi URI; I see an equally good argument that the biloxi URI is my actual AoR. UAs and their users don't have unique "actual" identities in SIP. > > - Retargeting is inherently insecure, and no amount of wiggling with the > > sip-identity mechanism will repair this. If Alice sent a request to Bob, and > > a new request in the backwards direction comes from Edgar, I think there is > > -no- circumstance in which Alice should not view this as a potential > > security risk, regardless of the presence or absence of an Identity header, > > SIPS, or what have you. Trying to explain this aware flies in the face of > > common sense, and will be incomprehensible to actual users who will need to > > make security decisions based on the evidence collected from the protocol by > > their user agent. > > Of course it is a potential security risk, which is why it is good to > report that it happened. (A good UA will hopefully note that the > connected party is not the called party and make a big fuss at its UI.) > But it is still good to know who in fact you ended up talking to. Speaking strictly to request identity for a moment, it is of course possible that a dialog will pass without any requests being sent in the backwards direction. So certainly we can't rely on request identity to tell you who you ended up talking to. If connected-party is a property we want, we should be getting it from responses - well, more to the point, I think we should be getting it by eliminating retargeting in favor of redirection, but let's not go there now. :) > This is however not in any way a surprising event. It happens all the > time for a variety of reasons. Usually it is detected because the voice > you hear isn't the one you expected to hear. The fact that we can do > better than that is itself of value. But I don't think we need to > deprecate the call any further. While it would be good to know more > about why the retargetting occured, in most cases people will do fine > without that. I have never found this line of argument very persuasive, but perhaps that's because I'm less concerned about success cases than failure cases. It's useful to look at this for a moment as a response identity problem: if the response you receive does not lead to you hearing a voice (i.e., it's a 604, or a 301, or something), then you want to know at a protocol level who sent that response. The reason why we need to do better than the PSTN is not because the success case is very different from a security perspective (after all, in the PSTN we just throw calls over the wall and have no insight into retargeting/security whatsoever, and rely on human voice identitification as you suggest), it's because the failure case is very different from a security perspective (because the untrusted Internet is delivering us these responses rather than a private telephony signaling network). Now, all that said, I don't think this is limited to response identity, in the sense that new requests in the backwards direction (like BYE) have a serious denial-of-service potential comparable to the use of something like 604 in response identity. So I think there is a clear motivation to do better than the PSTN. In order to make a reasonable authorization decision about handling a BYE request in the backwards direction, Alice needs to be able to anticipate who should be authorized to send such a request. My gut tells me that Bob should be the person so authorized, and that anyone else sending such requests should be extremely suspect, if not discarded out of hand without human oversight. > >>>This will break all compatibility with rfc2543, but > >>>will work with other rfc3261 compliant endpoints, since the URI is no > >>>longer used for dialog identification. > >> > >>If we were going to switch to this, then it could begin with the first > >>response to the invite. That would be the first step to really solving > >>the connected-partiy-id problem. > > > > Not just 'could begin' but 'should begin'. If the identity you see in the > > response to the INVITE does not equal the identity you see in requests in > > the backwards direction, I believe that is extremely problematic. Yes, this > > is what I mean by solving the response identity problem. > > The 'could' was a response to Jonathan, who didn't seem to have that in > mind. > > Re having the identity in a subsequent request differ from the one in > the response to the invite: I'm not sure it is so problematic. The > identity can change in mid call, and that will then probably first > manifest itself in the first message sent following the identity change. > This could happen if one party is a B2BUA or gateway. So far, I haven't incorporated the idea that the identity can change mid-call into my requirements space. I am extremely skeptical that this is an achievable requirement if we cast it as something that the originating user and the original target don't explicitly sanction. It brings Alice back to the case of wondering if this guy Edgar can actually tell her to tear down her call with Bob or not. I really don't see how we can expect users to understand this. Now, with some kind of explicit Replaces-style operation that Alice must authorize, originating from Bob, telling her that Edgar is now in charge, I believe Alice can make a reasonable decision, and an identity can change mid-call. But the idea that she is just going to start receiving BYE messages from some guy named Edgar and just assume that he's in charge; well, that's tough for me to swallow. Hence I support roughly the strawman you sketch in the following sentence, and that's why I see this idea of dissonance between the identities in requests and responses as a problem. > Perhaps it would be more problematic if the change was first seen in > some random message (e.g. INFO or OPTIONS) rather than in a message > intended to change dialog state (e.g. INVITE or UPDATE). But it is only > problematic if we enact some rule that says changes in identity must be > formally announced. > Jon Peterson NeuStar, Inc. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 16 20:07:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18697 for ; Tue, 16 Nov 2004 20:07:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUEKE-00011L-LP for sip-web-archive@ietf.org; Tue, 16 Nov 2004 20:09:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUECu-0004ju-P1; Tue, 16 Nov 2004 20:02:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUEA8-0003mD-O6 for sip@megatron.ietf.org; Tue, 16 Nov 2004 19:59:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17703 for ; Tue, 16 Nov 2004 19:59:08 -0500 (EST) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUECS-0000nc-Hx for sip@ietf.org; Tue, 16 Nov 2004 20:01:32 -0500 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id iAH0wW10006357; Wed, 17 Nov 2004 00:58:32 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Tue, 16 Nov 2004 19:58:32 -0500 Message-ID: <7927C67249E4AD43BC05B539AF0D129801AF4382@stntexch04.cis.neustar.com> From: "Peterson, Jon" To: "'Cullen Jennings'" , "'Jonathan Rosenberg'" Subject: third alternative (was RE: [Sip] RE: Identity after reinvite) Date: Tue, 16 Nov 2004 19:58:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: "'sip@ietf.org'" , "'Paul H Kyzivat'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 I would like to suggest a third alternative: 3) Change nothing about in To/From. Requests in the backwards direction in a dialog may go through the authentication service of the domain indicated in the host portion of the From header of the request. If that is not possible, do not supply request identity for such messages. While this seem like a non-starter in retargeting cases, requests get retargeted for a reason. If the dialog-forming request was appropriately delivered to the domain indicated in the Request-URI (biloxi.example.com), and that domain chose to forward the request to another domain (chicago.example.com), it did so because some entity was authorized to add the chicago URI as a contact for the biloxi URI. In other words, this approach views retargeting as if the callee's UA were actually registered at biloxi "through" chicago, and that when the UA receives a dialog-forming request, it is the To header that determines who should assert identity for new requests in the backwards direction. In cases where the user contacted at chicago does not possess credentials to authenticate themselves to biloxi, I think it would be fair to say that requests in the backwards direction should not get an Identity header. To go any further, I think, requires us to solve the response identity problem. This approach is, I think, forward-compatible with any reasonable solution to the response identity problem, though. The primary challenge of this approach is insuring that requests in the backwards direction will actually go through the authentication service of biloxi.com, since in many cases they ordinarily might not. If biloxi.com Record-Routes its auth service in the dialog-forming request, this would provide the right assurance (and seems plausible from a deployment perspective); however, if chicago.com also Record-Routes itself, for example, then the callee will not be able to form a direct TLS connection to biloxi.com. It is also possible that the callee's UA could force a Route header to connect to biloxi.com first, but this requires the callee's UA to be identity-aware, which is undesirable when sip-identity is applied opportunistically. But it isn't immediately clear how this is any different from normal cases of request identity outside the scope of a dialog. There are any number of possible reasons why the calling UA might not be able to connect directly via TLS to its auth service (including interposing intermediaries and/or the inability of the UA to force a Route through their auth service), and the draft currently just says that we shouldn't provide Identity when we cannot get the needed relationship between the UA and auth service. I've gotten a lot of feedback (from Paul, Kumiko and others) that we should try to weaken the requirement for direct TLS, and I intend to add some text to the next version about some specific ways in which it is still acceptable to provide identity even if a direct TLS connection cannot be formed. Certain forms of weakness there could be beneficial to this approach. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Tuesday, November 16, 2004 9:30 AM > To: Jonathan Rosenberg; Jon Peterson > Cc: Paul H Kyzivat; sip@ietf.org > Subject: Re: [Sip] RE: Identity after reinvite > > > On 11/16/04 12:05 AM, "Jonathan Rosenberg" wrote: > > > The solution, which rfc3261 warns of, is that a UA has to > put its actual > > identity in the From field URI, not what it saw in the To > field of the > > original request. This will break all compatibility with > rfc2543, but > > will work with other rfc3261 compliant endpoints, since the > URI is no > > longer used for dialog identification. > > At this point, I really see two paths forward for the connected party > problem. > > 1) We do as suggested above and allow everything in the From > and To other > than the tags to be changed in a Re-INVITE or UPDATE. > > 2) We create a new thing that is like invite with replaces > but add a new tag > that is called say "subsumes". So if A and B have a dialog, > or early dialog, > and one of them wants to change a From. The UA sends an > INVITE for a new > dialog, indicates it replaces the old dialog, and indicates > that it subsumes > it. The subsumes flag would mean that any existing media session, qos > reservations, etc did not change and got moved to the new dialog. > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 17 01:05:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14626 for ; Wed, 17 Nov 2004 01:05:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUIz9-0007kj-O3 for sip-web-archive@ietf.org; Wed, 17 Nov 2004 01:08:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUIvO-0000eX-Rq; Wed, 17 Nov 2004 01:04:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUIqM-0008V6-Pj for sip@megatron.ietf.org; Wed, 17 Nov 2004 00:59:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14161 for ; Wed, 17 Nov 2004 00:59:00 -0500 (EST) Received: from rproxy.gmail.com ([64.233.170.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUIsh-0007d7-Ng for sip@ietf.org; Wed, 17 Nov 2004 01:01:28 -0500 Received: by rproxy.gmail.com with SMTP id b11so890114rne for ; Tue, 16 Nov 2004 21:59:00 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=Mdvlh1OJX9ZewFZKYr5eBYJc8esvnSlguGDNJE0BlwioksT5Yh+TaVgO0qes6yQRbiok7NZYmhuxuIaA+kgNiGo49DA269kT0BSfHFdrk9tECpSA4oKkUMvyrkuxYONJmRCMtIWTGQdPxIyMyR27aiyDnKMQ1MaEImAhlSvCfEY= Received: by 10.38.149.67 with SMTP id w67mr84155rnd; Tue, 16 Nov 2004 21:59:00 -0800 (PST) Received: by 10.38.149.43 with HTTP; Tue, 16 Nov 2004 21:59:00 -0800 (PST) Message-ID: <98697c990411162159dc71673@mail.gmail.com> Date: Wed, 17 Nov 2004 13:59:00 +0800 From: Bo Liu To: sip@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.9 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Subject: [Sip] SIP open source for Win CE platform X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bo Liu List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit I would like to implement VoIP(SIP based) on Win CE platform. Any open source available? which commercial product is more suitable for this embedded platform? Thanks a lot, Bob _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 17 02:35:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19592 for ; Wed, 17 Nov 2004 02:35:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUKOR-00015O-9K for sip-web-archive@ietf.org; Wed, 17 Nov 2004 02:38:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUKHi-0006fv-OR; Wed, 17 Nov 2004 02:31:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUKCB-0004Vc-Te for sip@megatron.ietf.org; Wed, 17 Nov 2004 02:25:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11686 for ; Wed, 17 Nov 2004 02:25:38 -0500 (EST) Received: from mailserv.intranet.gr ([146.124.14.106]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUKEU-0000sh-Qz for sip@ietf.org; Wed, 17 Nov 2004 02:28:06 -0500 Received: from mailserv.intranet.gr (localhost [127.0.0.1]) by mailserv.intranet.gr (8.13.1/8.13.1) with ESMTP id iAH7QOvE003995 for ; Wed, 17 Nov 2004 09:26:25 +0200 (EET) Received: from hal.intranet.gr (hal.intranet.GR [146.124.2.254]) by mailserv.intranet.gr (8.13.1/8.13.1) with ESMTP id iAH7QL6W003968; Wed, 17 Nov 2004 09:26:21 +0200 (EET) Received: from Computer (pcdpd217 [146.124.2.204]) by hal.intranet.gr (8.11.7p1+Sun/8.10.2) with ESMTP id iAH7CZk19955; Wed, 17 Nov 2004 09:12:35 +0200 (EET) Message-Id: <200411170712.iAH7CZk19955@hal.intranet.gr> From: "F.S.Salloum" To: "'Bo Liu'" , Subject: RE: [Sip] SIP open source for Win CE platform Date: Wed, 17 Nov 2004 09:19:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-reply-to: <98697c990411162159dc71673@mail.gmail.com> Thread-Index: AcTMasNlX7CQt1OfRQeACfuRDh4GXAACfymw X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Hi, I have tested, Microsoft Potrait http://research.microsoft.com/~jiangli/portrait/ and SJPhone http://www.sjlabs.com/ which work fine with SIP Express Router. www.iptel.org and Asterisk www.asterisk.org over WLAN I'm also trying to make a simple SIP client for WinCE based on open source stuff, which will be based on libOSIP and jrtplib modified to work on WinCE Embedded VC4++, or if this doesn't work with Java and JMF (mobile edition) I will let you know when I will have the first version.. Regards Sotiris -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Bo Liu Sent: Wednesday, November 17, 2004 7:59 AM To: sip@ietf.org Subject: [Sip] SIP open source for Win CE platform I would like to implement VoIP(SIP based) on Win CE platform. Any open source available? which commercial product is more suitable for this embedded platform? Thanks a lot, Bob _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 17 03:21:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26499 for ; Wed, 17 Nov 2004 03:21:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUL6l-000252-Ec for sip-web-archive@ietf.org; Wed, 17 Nov 2004 03:24:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUKzE-00083f-Rg; Wed, 17 Nov 2004 03:16:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUKxd-0007WC-Ax for sip@megatron.ietf.org; Wed, 17 Nov 2004 03:14:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25854 for ; Wed, 17 Nov 2004 03:14:39 -0500 (EST) From: Mpierce1@aol.com Received: from imo-m24.mx.aol.com ([64.12.137.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUL00-0001uP-IX for sip@ietf.org; Wed, 17 Nov 2004 03:17:08 -0500 Received: from Mpierce1@aol.com by imo-m24.mx.aol.com (mail_out_v37_r3.8.) id l.1ea.2fbc8541 (3850) for ; Wed, 17 Nov 2004 03:14:06 -0500 (EST) Message-ID: <1ea.2fbc8541.2ecc624e@aol.com> Date: Wed, 17 Nov 2004 03:14:06 EST To: sip@ietf.org MIME-Version: 1.0 X-Mailer: 6.0 for Windows XP sub 10500 X-Spam-Score: 0.5 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Subject: [Sip] Comments on Resource-priority-05 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0100863864==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 --===============0100863864== Content-Type: multipart/alternative; boundary="part1_1ea.2fbc8541.2ecc624e_boundary" --part1_1ea.2fbc8541.2ecc624e_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Based on the contents of previous versions of this draft, and comments I and others have made, I believe that the following are essential for the next version of this draft. The only normative information included per namespace should be: - name of the namespace - names of the priority levels - order of the priority values - default priority level (may be used if the receiving end does not recognize a valid priority value) While the draft could detail various procedures which might be applied, such as "modes", it should not associate any specific procedure with any specific namespace. There should not be any other normative, mandatory behavior associated with the use of the Resoure-priority header, such as specific authorization procedures. In general, the draft can be made much shorter by deletion of irrelevant material. For example, Section 7 describes procedures for "move to the head of the line" scenarios for processing of messages in SIP servers or UAs. It has been proposed in draft-pierce-tsvwg-pref-treat-examples since April 2002 (and never commented on) that there is no need to do such a thing. In fact, it is not a good idea to intentionally change the order of messages.. Mike Pierce --part1_1ea.2fbc8541.2ecc624e_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Based on the=20= contents of previous versions of this draft, and comments I and others have=20= made, I believe that the following are essential for the next version of thi= s draft.

The only normative information included per namespace should be:

- name of the namespace
- names of the priority levels
- order of the priority values
- default priority level (may be used if the receiving end does not reco= gnize a valid priority value)

While the draft could detail various procedures which might be applied,=20= such as "modes", it should not associate any specific procedure with any spe= cific namespace.

There should not be any other normative, mandatory behavior associated w= ith the use of the Resoure-priority header, such as specific authorization p= rocedures.

In general, the draft can be made much shorter by deletion of irrelevant= material. For example, Section 7 describes procedures for "move to the head= of the line" scenarios for processing of messages in SIP servers or UAs. It= has been proposed in draft-pierce-tsvwg-pref-treat-examples since April 200= 2 (and never commented on) that there is no need to do such a thing. In fact= , it is not a good idea to intentionally change the order of messages..

Mike Pierce
--part1_1ea.2fbc8541.2ecc624e_boundary-- --===============0100863864== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0100863864==-- From sip-bounces@ietf.org Wed Nov 17 04:02:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00784 for ; Wed, 17 Nov 2004 04:02:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CULkU-000351-2q for sip-web-archive@ietf.org; Wed, 17 Nov 2004 04:05:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CULgo-000797-5T; Wed, 17 Nov 2004 04:01:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSNd5-0007tP-0P for sip@megatron.ietf.org; Thu, 11 Nov 2004 17:41:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07867 for ; Thu, 11 Nov 2004 17:41:20 -0500 (EST) Received: from 206-169-193-40.gen.twtelecom.net ([206.169.193.40] helo=ProgressiveComputingLLC.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSNeK-0007jp-FU for sip@ietf.org; Thu, 11 Nov 2004 17:42:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 11 Nov 2004 14:40:49 -0800 Message-ID: <2D0CA64CDC33E14DA7AB043B8CC4D2BB02213EAA@svr-exc.domain.com> Thread-Topic: meeting minutes from SIP session 2 at IETF 61 Thread-Index: AcTIP1dVnmH9F2D2RGu7cwA4a4p8Bw== From: "Thomas Gal" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 X-Mailman-Approved-At: Wed, 17 Nov 2004 04:01:19 -0500 Cc: sip@ietf.org Subject: [Sip] meeting minutes from SIP session 2 at IETF 61 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0060397208==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 --===============0060397208== Content-Class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIG1pbnV0ZXMgd2lsbCBiZSBhdCBodHRwOi8vbmF0dXJhbC5zYWxrLmVkdS9+dGdhbC9pZXRm NjEvaW5kZXguaHRtbCBzaG9ydGx5Lg0KIA0KVG9tDQo= --===============0060397208== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0060397208==-- From sip-bounces@ietf.org Wed Nov 17 04:07:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01391 for ; Wed, 17 Nov 2004 04:07:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CULp6-0003DA-Lg for sip-web-archive@ietf.org; Wed, 17 Nov 2004 04:09:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CULgq-00079l-3l; Wed, 17 Nov 2004 04:01:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSekC-0005W2-Oy for sip@megatron.ietf.org; Fri, 12 Nov 2004 11:57:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20085 for ; Fri, 12 Nov 2004 11:57:49 -0500 (EST) Received: from mtassp3.ncr.disa.mil ([164.117.82.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSelb-0004jV-VF for sip@ietf.org; Fri, 12 Nov 2004 11:59:20 -0500 Received: from mtassp3.ncr.disa.mil by mtassp3.ncr.disa.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Fri, 12 Nov 2004 11:55:03 -0500 Received: by mtassp3.ncr.disa.mil with Internet Mail Service (5.5.2657.72) id ; Fri, 12 Nov 2004 11:56:09 -0500 Message-ID: <7F18415E4D63CB45BB9B3A591F68D12D07651622@emshqs1.ncr.disa.mil> From: "Nguyen, An" To: "'Mpierce1@aol.com'" , coreya@nortelnetworks.com, sip@ietf.org Subject: RE: [Sip] -resource-priority-05.txt: Comments and Recommendations (1) Date: Fri, 12 Nov 2004 11:55:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.1 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 X-Mailman-Approved-At: Wed, 17 Nov 2004 04:01:19 -0500 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1272685628==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1272685628== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C8D8.5A63AF30" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4C8D8.5A63AF30 Content-Type: text/plain; charset="iso-8859-1" Mike, I agree with you that it would be overly complex to address all possible mappings between namespaces in this draft. Mappings between namespaces issues should be specifically addressed in different documents. Can we just add a sentence to the draft saying mapping between namespaces is out of scope and it should be addressed separately? Otherwise, we would never get this draft published. An [Nguyen, An] From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] Sent: Friday, November 12, 2004 9:54 AM To: coreya@nortelnetworks.com; sip@ietf.org Subject: Re: [Sip] -resource-priority-05.txt: Comments and Recommendations (1) Corey, Thanks for the great analysis of the situation and the suggestions. I agree almost completely with what you suggested. I'll follow this up with a few minor points on your suggestions. But first, some comments on your questions, which might help understand why this approach was taken. In a message dated 11/11/2004 6:12:39 PM Eastern Standard Time, coreya@nortelnetworks.com writes: 1. Why support multiple namespace/priority (n-p) values in a single message, in one or more R-P headers? And if supported, should not the n-p values in the message equate to the same priority level (for example, dsn.flash and q735.1 would be equal)? Would it not be better to support only one n-p value per message, and recommend that a proxy/gateway between networks supporting two different namespaces handle mapping n-p values? ---- There may be/are networks which would support multiple levels. The draft is not dictating that there must be multiple levels. ---- As for having the n-p levels be "equal", James cited a GETS call with a specific precedence which becomes a Routine call on the DSN. ---- Having a proxy/gateway mapped between namespaces is an viable alternative. While it is a little hard to describe specific cases for the use of multiple namespaces, I believe it could be used, such as a GETS call originated in a military network that normally uses only the dsn namespace. The caller, knowing that the call will likely go outside the dsn, might be able to specify both dsn=flash and ETS=3. It is not possible to say that they "equal", since they are two separately defined lists of priorities which have no direct relationship. In one application, only the dsn namespace would have an effect while the call remains within the private network (DOD) for which it was defined. When the call gets to a PSTN gateway to jump into the "public" network, the dsn namespace/priority is discarded, since the "public" network does not support it. At the GW, the ETS namespace/priority is converted to the appropriate PSTN signaling which that netwrok supports. Note that in this case, the PSTN signaling does not have any further signaling of this value beyond the initial call setup message, which is why the SIP signaling would not include this R-P header in anything beyond the INVITE. When an ETS call from the public network enters the dsn, it could be mapped to Routine or to some higher priority level if the PSTN signaling provided that information. That will be determine by the administrator of the network and what the GW is told to do. It certainly can't be defined in the R-P header draft. Another application is a gateway between two networks which each use the R-P header but with different definitions. Lets say between the US DOD network with 5 values and another country's military network when that other country uses only 3 levels. The GW must map between the two sets according to a mutually agreed mapping. In each network, only one R-P header is used. I believe it was agreed long ago that the R-P header draft should not try to define the interoperation/mapping between different namespaces. I think this approach should remain, since any attempt to define relationships would be overly complex and may conflict with what network operators want to do. The first example above, with two namespaces being carried, is the reason why the required mode of operation in the dsn is that unknown namespaces are simply ignored and passed on. Known namespaces with unknown priorities need to be treated as errors, but not necessarily by failing a call. Mike Pierce Artel ------_=_NextPart_001_01C4C8D8.5A63AF30 Content-Type: text/html; charset="iso-8859-1"
Mike,
 
I agree with you that it would be overly complex to address all possible mappings between namespaces in this draft. Mappings between namespaces issues should be specifically addressed in different documents. Can we just add a sentence to the draft saying mapping between namespaces is out of scope and it should be addressed separately? Otherwise, we would never get this draft published.
 
An

[Nguyen, An]  From: Mpierce1@aol.com [mailto:Mpierce1@aol.com]
Sent: Friday, November 12, 2004 9:54 AM
To: coreya@nortelnetworks.com; sip@ietf.org
Subject: Re: [Sip] -resource-priority-05.txt: Comments and Recommendations (1)
Corey,

Thanks for the great analysis of the situation and the suggestions. I agree almost completely with what you suggested. I'll follow this up with a few minor points on your suggestions. But first, some comments on your questions, which might help understand why this approach was taken.

In a message dated 11/11/2004 6:12:39 PM Eastern Standard Time, coreya@nortelnetworks.com writes:


1. Why support multiple namespace/priority (n-p) values in a single
message, in one or more R-P headers?  And if supported, should not the
n-p values in the message equate to the same priority level (for
example, dsn.flash and q735.1 would be equal)?  Would it not be better
to support only one n-p value per message, and recommend that a
proxy/gateway between networks supporting two different namespaces
handle mapping n-p values?
---- There may be/are networks which would support multiple levels.  The
draft is not dictating that there must be multiple levels.
---- As for having the n-p levels be "equal", James cited a GETS call
with a specific precedence which becomes a Routine call on the DSN.
---- Having a proxy/gateway mapped between namespaces is an viable
alternative.



While it is a little hard to describe specific cases for the use of multiple namespaces, I believe it could be used, such as a GETS call originated in a military network that normally uses only the dsn namespace. The caller, knowing that the call will likely go outside the dsn, might be able to specify both dsn=flash and ETS=3. It is not possible to say that they "equal", since they are two separately defined lists of priorities which have no direct relationship. In one application, only the dsn namespace would have an effect while the call remains within the private network (DOD) for which it was defined. When the call gets to a PSTN gateway to jump into the "public" network, the dsn namespace/priority is discarded, since the "public" network does not support it. At the GW, the ETS namespace/priority is converted to the appropriate PSTN signaling which that netwrok supports. Note that in this case, the PSTN signaling does not have any further signaling of this value beyond the initial call setup message, which is why the SIP signaling would not include this R-P header in anything beyond the INVITE.

When an ETS call from the public network enters the dsn, it could be mapped to Routine or to some higher priority level if the PSTN signaling provided that information. That will be determine by the administrator of the network and what the GW is told to do. It certainly can't be defined in the R-P header draft.

Another application is a gateway between two networks which each use the R-P header but with different definitions. Lets say between the US DOD network with 5 values and another country's military network when that other country uses only 3 levels. The GW must map between the two sets according to a mutually agreed mapping. In each network, only one R-P header is used.

I believe it was agreed long ago that the R-P header draft should not try to define the interoperation/mapping between different namespaces. I think this approach should remain, since any attempt to define relationships would be overly complex and may conflict with what network operators want to do.

The first example above, with two namespaces being carried, is the reason why the required mode of operation in the dsn is that unknown namespaces are simply ignored and passed on. Known namespaces with unknown priorities need to be treated as errors, but not necessarily by failing a call.

Mike Pierce
Artel


------_=_NextPart_001_01C4C8D8.5A63AF30-- --===============1272685628== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1272685628==-- From sip-bounces@ietf.org Wed Nov 17 04:10:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01966 for ; Wed, 17 Nov 2004 04:10:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CULsV-0003Kp-1l for sip-web-archive@ietf.org; Wed, 17 Nov 2004 04:13:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CULgs-0007A4-7o; Wed, 17 Nov 2004 04:01:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUIbv-0005Da-B4 for sip@megatron.ietf.org; Wed, 17 Nov 2004 00:44:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12961 for ; Wed, 17 Nov 2004 00:44:04 -0500 (EST) Received: from mtassp3.ncr.disa.mil ([164.117.82.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUIeG-0007Hi-TX for sip@ietf.org; Wed, 17 Nov 2004 00:46:33 -0500 Received: from mtassp3.ncr.disa.mil by mtassp3.ncr.disa.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Wed, 17 Nov 2004 00:41:16 -0500 Received: by mtassp3.ncr.disa.mil with Internet Mail Service (5.5.2657.72) id ; Tue, 16 Nov 2004 23:40:28 -0500 Message-ID: <7F18415E4D63CB45BB9B3A591F68D12D07651622@emshqs1.ncr.disa.mil> From: "Nguyen, An" To: "'Mpierce1@aol.com'" , coreya@nortelnetworks.com, sip@ietf.org Subject: RE: [Sip] -resource-priority-05.txt: Comments and Recommendations (1) Date: Fri, 12 Nov 2004 11:55:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 1.3 (+) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 X-Mailman-Approved-At: Wed, 17 Nov 2004 04:01:19 -0500 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1602173489==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.3 (+) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1602173489== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C8D8.5A63AF30" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4C8D8.5A63AF30 Content-Type: text/plain; charset="iso-8859-1" Mike, I agree with you that it would be overly complex to address all possible mappings between namespaces in this draft. Mappings between namespaces issues should be specifically addressed in different documents. Can we just add a sentence to the draft saying mapping between namespaces is out of scope and it should be addressed separately? Otherwise, we would never get this draft published. An [Nguyen, An] From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] Sent: Friday, November 12, 2004 9:54 AM To: coreya@nortelnetworks.com; sip@ietf.org Subject: Re: [Sip] -resource-priority-05.txt: Comments and Recommendations (1) Corey, Thanks for the great analysis of the situation and the suggestions. I agree almost completely with what you suggested. I'll follow this up with a few minor points on your suggestions. But first, some comments on your questions, which might help understand why this approach was taken. In a message dated 11/11/2004 6:12:39 PM Eastern Standard Time, coreya@nortelnetworks.com writes: 1. Why support multiple namespace/priority (n-p) values in a single message, in one or more R-P headers? And if supported, should not the n-p values in the message equate to the same priority level (for example, dsn.flash and q735.1 would be equal)? Would it not be better to support only one n-p value per message, and recommend that a proxy/gateway between networks supporting two different namespaces handle mapping n-p values? ---- There may be/are networks which would support multiple levels. The draft is not dictating that there must be multiple levels. ---- As for having the n-p levels be "equal", James cited a GETS call with a specific precedence which becomes a Routine call on the DSN. ---- Having a proxy/gateway mapped between namespaces is an viable alternative. While it is a little hard to describe specific cases for the use of multiple namespaces, I believe it could be used, such as a GETS call originated in a military network that normally uses only the dsn namespace. The caller, knowing that the call will likely go outside the dsn, might be able to specify both dsn=flash and ETS=3. It is not possible to say that they "equal", since they are two separately defined lists of priorities which have no direct relationship. In one application, only the dsn namespace would have an effect while the call remains within the private network (DOD) for which it was defined. When the call gets to a PSTN gateway to jump into the "public" network, the dsn namespace/priority is discarded, since the "public" network does not support it. At the GW, the ETS namespace/priority is converted to the appropriate PSTN signaling which that netwrok supports. Note that in this case, the PSTN signaling does not have any further signaling of this value beyond the initial call setup message, which is why the SIP signaling would not include this R-P header in anything beyond the INVITE. When an ETS call from the public network enters the dsn, it could be mapped to Routine or to some higher priority level if the PSTN signaling provided that information. That will be determine by the administrator of the network and what the GW is told to do. It certainly can't be defined in the R-P header draft. Another application is a gateway between two networks which each use the R-P header but with different definitions. Lets say between the US DOD network with 5 values and another country's military network when that other country uses only 3 levels. The GW must map between the two sets according to a mutually agreed mapping. In each network, only one R-P header is used. I believe it was agreed long ago that the R-P header draft should not try to define the interoperation/mapping between different namespaces. I think this approach should remain, since any attempt to define relationships would be overly complex and may conflict with what network operators want to do. The first example above, with two namespaces being carried, is the reason why the required mode of operation in the dsn is that unknown namespaces are simply ignored and passed on. Known namespaces with unknown priorities need to be treated as errors, but not necessarily by failing a call. Mike Pierce Artel ------_=_NextPart_001_01C4C8D8.5A63AF30 Content-Type: text/html; charset="iso-8859-1"
Mike,
 
I agree with you that it would be overly complex to address all possible mappings between namespaces in this draft. Mappings between namespaces issues should be specifically addressed in different documents. Can we just add a sentence to the draft saying mapping between namespaces is out of scope and it should be addressed separately? Otherwise, we would never get this draft published.
 
An

[Nguyen, An]  From: Mpierce1@aol.com [mailto:Mpierce1@aol.com]
Sent: Friday, November 12, 2004 9:54 AM
To: coreya@nortelnetworks.com; sip@ietf.org
Subject: Re: [Sip] -resource-priority-05.txt: Comments and Recommendations (1)
Corey,

Thanks for the great analysis of the situation and the suggestions. I agree almost completely with what you suggested. I'll follow this up with a few minor points on your suggestions. But first, some comments on your questions, which might help understand why this approach was taken.

In a message dated 11/11/2004 6:12:39 PM Eastern Standard Time, coreya@nortelnetworks.com writes:


1. Why support multiple namespace/priority (n-p) values in a single
message, in one or more R-P headers?  And if supported, should not the
n-p values in the message equate to the same priority level (for
example, dsn.flash and q735.1 would be equal)?  Would it not be better
to support only one n-p value per message, and recommend that a
proxy/gateway between networks supporting two different namespaces
handle mapping n-p values?
---- There may be/are networks which would support multiple levels.  The
draft is not dictating that there must be multiple levels.
---- As for having the n-p levels be "equal", James cited a GETS call
with a specific precedence which becomes a Routine call on the DSN.
---- Having a proxy/gateway mapped between namespaces is an viable
alternative.



While it is a little hard to describe specific cases for the use of multiple namespaces, I believe it could be used, such as a GETS call originated in a military network that normally uses only the dsn namespace. The caller, knowing that the call will likely go outside the dsn, might be able to specify both dsn=flash and ETS=3. It is not possible to say that they "equal", since they are two separately defined lists of priorities which have no direct relationship. In one application, only the dsn namespace would have an effect while the call remains within the private network (DOD) for which it was defined. When the call gets to a PSTN gateway to jump into the "public" network, the dsn namespace/priority is discarded, since the "public" network does not support it. At the GW, the ETS namespace/priority is converted to the appropriate PSTN signaling which that netwrok supports. Note that in this case, the PSTN signaling does not have any further signaling of this value beyond the initial call setup message, which is why the SIP signaling would not include this R-P header in anything beyond the INVITE.

When an ETS call from the public network enters the dsn, it could be mapped to Routine or to some higher priority level if the PSTN signaling provided that information. That will be determine by the administrator of the network and what the GW is told to do. It certainly can't be defined in the R-P header draft.

Another application is a gateway between two networks which each use the R-P header but with different definitions. Lets say between the US DOD network with 5 values and another country's military network when that other country uses only 3 levels. The GW must map between the two sets according to a mutually agreed mapping. In each network, only one R-P header is used.

I believe it was agreed long ago that the R-P header draft should not try to define the interoperation/mapping between different namespaces. I think this approach should remain, since any attempt to define relationships would be overly complex and may conflict with what network operators want to do.

The first example above, with two namespaces being carried, is the reason why the required mode of operation in the dsn is that unknown namespaces are simply ignored and passed on. Known namespaces with unknown priorities need to be treated as errors, but not necessarily by failing a call.

Mike Pierce
Artel


------_=_NextPart_001_01C4C8D8.5A63AF30-- --===============1602173489== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1602173489==-- From sip-bounces@ietf.org Wed Nov 17 04:56:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06454 for ; Wed, 17 Nov 2004 04:56:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUMam-0004QP-Fj for sip-web-archive@ietf.org; Wed, 17 Nov 2004 04:59:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUMPb-0008Q0-23; Wed, 17 Nov 2004 04:47:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUMKs-0007S1-LV for sip@megatron.ietf.org; Wed, 17 Nov 2004 04:42:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05273 for ; Wed, 17 Nov 2004 04:42:44 -0500 (EST) Received: from [67.15.60.3] (helo=mail.aftek.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUMND-00047e-2e for sip@ietf.org; Wed, 17 Nov 2004 04:45:14 -0500 Received: (qmail 7042 invoked by uid 510); 17 Nov 2004 02:50:11 -0600 Received: from vikramb@aftek.com by plain.ev1servers.net by uid 508 with qmail-scanner-1.22-st-qms (clamdscan: 0.75.1. spamassassin: 2.63. Clear:RC:0(203.129.224.106):SA:0(-104.9/3.0):. Processed in 8.423568 secs); 17 Nov 2004 08:50:11 -0000 X-Spam-Status: No, hits=-104.9 required=3.0 X-Antivirus-MYDOMAIN-Mail-From: vikramb@aftek.com via plain.ev1servers.net X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:0(203.129.224.106):SA:0(-104.9/3.0):. Processed in 8.423568 secs Process 7021) Received: from unknown (HELO vikram) (vikramb@aftek.com@203.129.224.106) by mail.aftek.com with SMTP; 17 Nov 2004 02:50:03 -0600 Message-ID: <002001c4cc8a$f58fed60$9100000a@vikram> From: "vikram bhuskute" To: References: <419915BE.2060703@pernau.at> Date: Wed, 17 Nov 2004 15:21:04 +0530 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.1437 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Subject: [Sip] How to get old messages on archives!! X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Hello , I am an active member of this work group. It so happened that i deleted some old mails. Earlier i Use to see Old mails on the Archives link. But now if i open ,it give today's and yesterday's mail. I am force to go to link http://www1.ietf.org/mail-archive/web/sip/current/index.html and there is no other link there :( Please help !! Vikram _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 17 08:12:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26782 for ; Wed, 17 Nov 2004 08:12:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUPdt-0000ev-SA for sip-web-archive@ietf.org; Wed, 17 Nov 2004 08:14:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUPY4-00059G-6w; Wed, 17 Nov 2004 08:08:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUPUA-0003pE-42 for sip@megatron.ietf.org; Wed, 17 Nov 2004 08:04:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25552 for ; Wed, 17 Nov 2004 08:04:32 -0500 (EST) From: Mpierce1@aol.com Received: from imo-m25.mx.aol.com ([64.12.137.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUPWZ-0000Mk-QN for sip@ietf.org; Wed, 17 Nov 2004 08:07:04 -0500 Received: from Mpierce1@aol.com by imo-m25.mx.aol.com (mail_out_v37_r3.8.) id c.12c.51049647 (14374); Wed, 17 Nov 2004 08:03:57 -0500 (EST) Message-ID: <12c.51049647.2ecca63d@aol.com> Date: Wed, 17 Nov 2004 08:03:57 EST Subject: Re: [Sip] -resource-priority-05.txt: Comments and Recommendations (1) To: jmpolk@cisco.com, jgunn6@csc.com, oran@cisco.com MIME-Version: 1.0 X-Mailer: 6.0 for Windows XP sub 10500 X-Spam-Score: 0.3 (/) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af Cc: An.Nguyen@ncs.gov, sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0394264048==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 --===============0394264048== Content-Type: multipart/alternative; boundary="part1_12c.51049647.2ecca63d_boundary" --part1_12c.51049647.2ecca63d_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 11/16/2004 7:42:29 PM W. Europe Standard Time, jmpolk@cisco.com writes: > > > I removed any comment about dependency because there may be a dependency in > a domain - based on local policy, and this document should not make any > comment that could contradict local policy. > > >[MAP] What I think is needed is a very clear statement something like > "neither > >this document nor namespaces specify the interrelationship or interworking > >between namespaces, such as mapping from one namespace to another at > >domain boundaries". > > What you have above is unnecessary. If the document does not state a > dependency, there is not one defined. > > > >[MAP] As a result, the first bullet in Section 7.1, which states "There > MUST be > >one order of priorities a SIP element has to process to", while talking > >about multiple namespaces in a message, seems to be wrong (or > misunderstood), > > It is not wrong, and I'm sorry if it is misunderstood. > > The section is about *ordering* of namespaces, and gives clear examples of > ordering that is in line with this specification (to be) and clear examples > of ordering that is not allowed in this specification (to be). > > > [MAP] since it seems to require something about the relationship. > > no it does not. It either does, or it does not - there is no "seems". > > >[MAP] In fact the example following this bullet list is trying to say > something > >about the "acceptable" ways that the SIP element may process multiple > >namespaces. > > That it does, as it is a violation to reorder priority values just because > another namespace is introduced. It primarily gives examples of how > multiple namespaces can be interleaved in acceptable and unacceptable orders. > > >[MAP] The part about what is "not acceptable" is not needed. > > I do not agree > > >[MAP] The examples of incorrect order within each individual namespace are > not > >allowed even without multiple namespaces. > > Well, how many coders have you spoken or emailed with that understood this > from the previous version(s)? I'll bet none. I have fielded many such > communications - and in each given them an explanation just like what is in > 7.1 and it becomes clear fairly quickly what was meant in previous versions > (that was not explained well enough). > > > >[MAP] Since the document should say that it does not address interworking > >between namespaces, it should not contain this material. > > giving examples to clarify a known area of confusion is a good thing - and > will stay in the document. > > [MAP] The above results in a serious contradiction. You agree that the document should not describe dependencies, then include material that certainly describes dependencies (what combinations are and are not allowed). This will confuse more readers into thinking that there are some dependencies. > > > it will not be deleted, though it might be modified to add or clarify meaning > > [MAP] It's too bad that you're taking the position that you have the final say on what is and is not included in the document regardless of the comments and results of any e-mail discussion. As far as I'm concerned, you must get the WG consensus for anything that you added in -05 in order to retain it in -06. Contrary to what Jon Peterson stated at the meeting, RFC2418 defines the responsibilities of the editor as follows: Most IETF working groups focus their efforts on a document, or set of documents, that capture the results of the group's work. A working group generally designates a person or persons to serve as the Editor for a particular document. The Document Editor is responsible for ensuring that the contents of the document accurately reflect the decisions that have been made by the working group. Mike --part1_12c.51049647.2ecca63d_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message=20= dated 11/16/2004 7:42:29 PM W. Europe Standard Time, jmpolk@cisco.com writes= :




I removed any comment about dependency because there may be a dependency= in=20
a domain - based on local policy, and this document should not make any=20
comment that could contradict local policy.

>[MAP] What I think is needed is a very clear statement something lik= e "neither=20
>this document nor namespaces specify the interrelationship or interw= orking=20
>between namespaces, such as mapping from one namespace to another at= =20
>domain boundaries".

What you have above is unnecessary. If the document does not state a=20
dependency, there is not one defined.


>[MAP] As a result, the first bullet in Section 7.1, which states "Th= ere MUST be=20
>one order of priorities a SIP element has to process to", while talk= ing=20
>about multiple namespaces in a message, seems to be wrong (or misund= erstood),

It is not wrong, and I'm sorry if it is misunderstood.

The section is about *ordering* of namespaces, and gives clear examples=20= of=20
ordering that is in line with this specification (to be) and clear examp= les=20
of ordering that is not allowed in this specification (to be).

>  [MAP] since it seems to require something about the relations= hip.

no it does not. It either does, or it does not - there is no "seems".

>[MAP] In fact the example following this bullet list is trying to sa= y something=20
>about the "acceptable" ways that the SIP element may process multipl= e=20
>namespaces.

That it does, as it is a violation to reorder priority values just becau= se=20
another namespace is introduced. It primarily gives examples of how=20
multiple namespaces can be interleaved in acceptable and unacceptable or= ders.

>[MAP] The part about what is "not acceptable" is not needed.

I do not agree

>[MAP] The examples of incorrect order within each individual namespa= ce are not=20
>allowed even without multiple namespaces.

Well, how many coders have you spoken or emailed with that understood th= is=20
from the previous version(s)? I'll bet none. I have fielded many such=20
communications - and in each given them an explanation just like what is= in=20
7.1 and it becomes clear fairly quickly what was meant in previous versi= ons=20
(that was not explained well enough).


>[MAP] Since the document should say that it does not address interwo= rking=20
>between namespaces, it should not contain this material.

giving examples to clarify a known area of confusion is a good thing - a= nd=20
will stay in the document.





[MAP] The above results in a serious contradiction. You agree that the d= ocument should not describe dependencies, then include material that certain= ly describes dependencies (what combinations are and are not allowed). This=20= will confuse more readers into thinking that there are some dependencies.



it will not be deleted, though it might be modified to add or clarify me= aning




[MAP] It's too bad that you're taking the position that you have the fin= al say on what is and is not included in the document regardless of the comm= ents and results of any e-mail discussion. As far as I'm concerned, you must= get the WG consensus for anything that you added in -05 in order to retain=20= it in -06. Contrary to what Jon Peterson stated at the meeting, RFC2418 defi= nes the responsibilities of the editor as follows:

  Most IETF working groups focus their efforts on a document,= or set of
  documents, that capture the results of the group's work. &n= bsp;A working
  group generally designates a person or persons to serve as=20= the Editor
  for a particular document.  The Document Editor is res= ponsible for
  ensuring that the contents of the document accurately refle= ct the
  decisions that have been made by the working group.


Mike
--part1_12c.51049647.2ecca63d_boundary-- --===============0394264048== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0394264048==-- From sip-bounces@ietf.org Wed Nov 17 10:08:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06050 for ; Wed, 17 Nov 2004 10:08:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CURSp-00034M-TL for sip-web-archive@ietf.org; Wed, 17 Nov 2004 10:11:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CURN7-00044j-50; Wed, 17 Nov 2004 10:05:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CURDv-0008NS-2E for sip@megatron.ietf.org; Wed, 17 Nov 2004 09:55:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04727 for ; Wed, 17 Nov 2004 09:55:52 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CURGL-0002nE-La for sip@ietf.org; Wed, 17 Nov 2004 09:58:26 -0500 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iAHEtKj23414; Wed, 17 Nov 2004 09:55:20 -0500 (EST) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Nov 2004 09:55:20 -0500 Message-ID: From: "Mary Barnes" To: "'PROUVOST Sebastien RD-CORE-ISS'" Date: Wed, 17 Nov 2004 09:55:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.6 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: sip@ietf.org Subject: [Sip] RE: Comments regarding the reason in draft-ietf-sip-history-info- 04 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0113581853==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0113581853== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4CCB5.6DFDA226" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4CCB5.6DFDA226 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Sebastien, =20 I think the need for these specific reasons depends upon how you = implement your voicemail service. I think what you perhaps might need in these situations, such as the "call forwarding immediate", is extensions to = the Reason header as discussed in = draft-elwell-sipping-redirection-reason-01. =20 I don't think this is something that should at all be addressed in the history-info draft, which is just one the proposed building blocks for providing voicemail services.=20 =20 Mary=20 -----Original Message----- From: PROUVOST Sebastien RD-CORE-ISS [mailto:sebastien.prouvost@francetelecom.com]=20 Sent: Wednesday, November 17, 2004 2:36 AM To: Barnes, Mary [NGC:B601:EXCH] Cc: sip@ietf.org Subject: Comments regarding the reason in = draft-ietf-sip-history-info-04 Hi Mary,=20 One comment on the history draft regarding the reason in history-info header. Section 4.3.3.1.2 mentions that for retarget as a result of timeouts of internal events, a Reason MAY be associated with the = hi-targeted-to-uri. I think that 2 specific values of the reason header shall be specified = by the draft as they are necessary to voicemail services (for example in = order to render to the caller an annonce associated with the reason such as = "the user you are calling is not responding" or "the user you are trying to contact is not available (registered) at the moment") :=20 - a value for timeout (reason =3D 'no response' for example)=20 - a value for direct retargeting to a default contact URI or to another AoR (reason =3D 'call forwarding immediate' for example). I am therefore in favour of adding a text looking like this :=20 "=20 As a result of timeouts of internal events, a Reason MAY be associated = with the hi-targeted-to-uri. Although other values may be possible this = draft defines two values for the Reason in such cases :=20 - Reason =3D'no response' when the retargeting occurs after timeout=20 - Reason =3D 'call forwarding immediate' when the proxy directly = retargets to a default contact URI or to another AoR=20 "=20 S=E9bastien=20 ------_=_NextPart_001_01C4CCB5.6DFDA226 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Sebastien,
 
I=20 think the need for these specific reasons depends upon how you = implement your=20 voicemail service.  I think what you perhaps might need in these=20 situations, such as the "call forwarding immediate", is extensions to = the Reason=20 header as discussed in=20 draft-elwell-sipping-redirection-reason-01.
 
I=20 don't think this is something that should at all be addressed in the=20 history-info draft, which is just one the proposed building blocks for = providing=20 voicemail services.
 
Mary
-----Original Message-----
From: = PROUVOST=20 Sebastien RD-CORE-ISS [mailto:sebastien.prouvost@francetelecom.com]=20
Sent: Wednesday, November 17, 2004 2:36 AM
To: = Barnes,=20 Mary [NGC:B601:EXCH]
Cc: sip@ietf.org
Subject: = Comments=20 regarding the reason in = draft-ietf-sip-history-info-04


Hi Mary,

One comment on the history draft = regarding the=20 reason in history-info header.

Section=20 4.3.3.1.2 mentions that for retarget as a result of timeouts of = internal=20 events, a Reason MAY be associated with the = hi-targeted-to-uri.

I think that 2 specific values of the = reason header=20 shall be specified by the draft as they are necessary to voicemail = services=20 (for example in order to render to the caller an annonce associated = with the=20 reason such as "the user you are calling is not responding" or "the = user you=20 are trying to contact is not available (registered) at the moment") : =

        - a=20 value for timeout (reason =3D 'no response' for example)=20
        - a=20 value for direct retargeting to a default contact URI or to another = AoR=20 (reason =3D 'call forwarding immediate' for example).

I am therefore in favour of adding a = text looking=20 like this :
"
As a result of timeouts of internal events, a Reason MAY be = associated=20 with the hi-targeted-to-uri. Although other values may be possible = this draft=20 defines two values for the Reason in such cases :

- Reason =3D'no response' when the = retargeting occurs=20 after timeout
- Reason =3D = 'call forwarding=20 immediate' when the proxy directly retargets to a default contact URI = or to=20 another AoR
"

S=E9bastien =

------_=_NextPart_001_01C4CCB5.6DFDA226-- --===============0113581853== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0113581853==-- From sip-bounces@ietf.org Wed Nov 17 10:42:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10015 for ; Wed, 17 Nov 2004 10:42:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CURzl-0003tS-FQ for sip-web-archive@ietf.org; Wed, 17 Nov 2004 10:45:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CURn3-0003qy-To; Wed, 17 Nov 2004 10:32:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CURil-0002cu-VZ for sip@megatron.ietf.org; Wed, 17 Nov 2004 10:27:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08357 for ; Wed, 17 Nov 2004 10:27:45 -0500 (EST) Received: from natsmtp00.rzone.de ([81.169.145.165]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CURlC-0003VR-LO for sip@ietf.org; Wed, 17 Nov 2004 10:30:19 -0500 Received: from snom.de (pD951647B.dip.t-dialin.net [217.81.100.123]) by post.webmailer.de (8.13.1/8.13.1) with ESMTP id iAHFRLT4009638; Wed, 17 Nov 2004 16:27:33 +0100 (MET) 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] PING/PONG X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 17 Nov 2004 16:31:24 +0100 Message-ID: Thread-Topic: [Sip] PING/PONG thread-index: AcTMFOtiRyKQSpn7RMeR3eSHQfrdZgAmkQSw From: "Christian Stredicke" To: "Jonathan Rosenberg" X-Spam-Score: 0.2 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: quoted-printable So my understanding is: 1. We should use *only* STUN for refreshing bindings (either UDP or TCP, what about TLS) 2. The user agent indicates if it can do it (no negotiation on capabilities) 3. Refreshing must be done from the client Can we agree on that? Christian > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Tuesday, November 16, 2004 2:46 PM > To: Christian Stredicke > Cc: Spencer Dawkins; sip@ietf.org > Subject: Re: [Sip] PING/PONG >=20 > inline. >=20 > Christian Stredicke wrote: >=20 > > Hi Spencer! > >=20 > > You just mentioned another way of keeping TCP connections=20 > alive. Thats > > good!=20 > >=20 > > So far we have: > >=20 > > - CRLF (frequenly used today, but not indicated by user agent) > > - STUN (same as CRLF) >=20 > It is not the same. STUN solicits a response, which allows=20 > the client to=20 > determine if the NAT binding has changed, and if the server=20 > is still alive. >=20 > > - PING/PONG or whatever (tbd, maybe superflous) >=20 > I am very much against SIP-based keepalives. This turns into a huge=20 > scalability nightmare. It ends up being the dominant=20 > processing cost for=20 > proxies along with the dominant percentage of the signaling=20 > bandwidth,=20 > and it buys you nothing. >=20 >=20 > > - OPTIONS (big overhead, but compatible) > > - REGISTER (same as OPTIONS, but even bigger overhead) > > - TCP low-level (how can this be addressed by the application?) > > - No refreshing ("legacy device") > >=20 > > Lets have a way to indicate these options and let the SBC=20 > decide what > > method it likes/supports. >=20 > Generally speaking, having multiple choices reduces=20 > interoperability. I=20 > think we should pick a solution, and only describe multiple ones if=20 > there is a compelling reason why multiple ones need to exist. >=20 > Its worth pointing out that there are several functions these various=20 > keepalvies provide: >=20 > 1. they keep nat bindings fresh > 2. they allow the client to detect if its nat binding as seen by the=20 > server has changed > 3. they allow the client to determine if the server is still=20 > alive and=20 > responding to messages > 4. they allow the client to determine if the nat has dropped=20 > its binding=20 > altogether, so that packets are just going into the ether >=20 > I *think* Bob is proposing another usage: >=20 > 5. they allow the server to determine that the nat binding for the=20 > client has changed, so it can update its registration to=20 > reflect the new=20 > address >=20 >=20 > Using the keepalive to update the binding on the server introduces=20 > security risks. If the keepalive is not authenticated, an=20 > attacker can=20 > inject the keepalives with a falsified source IP address, and as a=20 > result force incoming calls to be directed towards it. This is not=20 > acceptable. Thus, any request which causes the server to=20 > update any kind=20 > of bindings MUST be authenticated. I would rather not require the=20 > keepalives to be authenticated, as this substantially=20 > increases the cost=20 > of processing them. If you use unauthenticated STUN packets,=20 > the client=20 > detects that its nat binding has changed, and then it can re-register=20 > with a proper REGISTER, which can be authenticated and that=20 > can be used=20 > to update the binding, thus avoiding the attack. >=20 > It is possible to use different mechanisms to address each of the 4=20 > different issues above. An empty UDP packet or a CRLF on the TCP=20 > connection can address the binding keepalive issue but not any of the=20 > liveness checks. I strongly prefer a single solution that=20 > addresses all=20 > of these. >=20 > -Jonathan R. >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 17 11:03:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11940 for ; Wed, 17 Nov 2004 11:03:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUSJJ-0004P0-C6 for sip-web-archive@ietf.org; Wed, 17 Nov 2004 11:05:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUS9o-0000xV-TB; Wed, 17 Nov 2004 10:55:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUS7J-00005Q-Ri for sip@megatron.ietf.org; Wed, 17 Nov 2004 10:53:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10988 for ; Wed, 17 Nov 2004 10:53:07 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUS9l-00049j-4P for sip@ietf.org; Wed, 17 Nov 2004 10:55:41 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 17 Nov 2004 08:07:48 -0800 X-BrightmailFiltered: true Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAHFqX3O011710; Wed, 17 Nov 2004 07:52:34 -0800 (PST) Received: from [161.44.55.231] (dhcp-161-44-55-231.cisco.com [161.44.55.231]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFU41558; Wed, 17 Nov 2004 07:52:34 -0800 (PST) Message-ID: <419B73C3.3070208@cisco.com> Date: Wed, 17 Nov 2004 10:52:35 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] RE: Identity after reinvite References: <419A5291.20002@cisco.com> <419A609E.2070406@cisco.com> In-Reply-To: <419A609E.2070406@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: sip , David R Oran X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > By "this" I assume you mean the to-from-change option? > > > only if you assume that the problem lies in the UA; I would > >> be worred about other nasties along the way. > > > For changing on subsequent requests within the dialog, what nasties are > you thinking of? I think only a call stateful proxy would notice, and it > seems there aren't many of those. Of course there are B2BUAs, but they > at least *ought* to be UAs and behave as such. Ought, being the operative word here. I fear that a b2bua would pass the Supported headers unmodified and then things would be bad. >> In any case, I don't see a need for a Supported header field. The >> feature is supposed to work with any rfc3261 client out there. > > > Other than just hoping for the best, why would we expect existing 3261 > clients to work with this change? It is explicitly called out in 12.2.1.1: > The URI in the To field of the request MUST be set to the remote URI > from the dialog state. The tag in the To header field of the request > MUST be set to the remote tag of the dialog ID. The From URI of the > request MUST be set to the local URI from the dialog state. The tag > in the From header field of the request MUST be set to the local tag > of the dialog ID. If the value of the remote or local tags is null, > the tag parameter MUST be omitted from the To or From header fields, > respectively. > > Usage of the URI from the To and From fields in the original > request within subsequent requests is done for backwards > compatibility with RFC 2543, which used the URI for dialog > identification. In this specification, only the tags are used for > dialog identification. It is expected that mandatory reflection > of the original To and From URI in mid-dialog requests will be > deprecated in a subsequent revision of this specification. Only the tags are ever used in any normative processing of dialogs in RFC 3261. The requirement to set the From field *URI* in the reverse direction to the value of the To URI in the original INVITE is *only* for backwards compatibility, and rfc3261 stated that this is likely to change one day. The day appears to be at hand. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 17 11:17:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14464 for ; Wed, 17 Nov 2004 11:17:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUSXZ-0004s1-F4 for sip-web-archive@ietf.org; Wed, 17 Nov 2004 11:20:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUSTO-0005T6-Og; Wed, 17 Nov 2004 11:15:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUSLq-0003t6-7t for sip@megatron.ietf.org; Wed, 17 Nov 2004 11:08:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12788 for ; Wed, 17 Nov 2004 11:08:07 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUSOH-0004Yn-Gv for sip@ietf.org; Wed, 17 Nov 2004 11:10:41 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 17 Nov 2004 08:21:20 -0800 Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAHG823O021528; Wed, 17 Nov 2004 08:08:02 -0800 (PST) Received: from [161.44.55.231] (dhcp-161-44-55-231.cisco.com [161.44.55.231]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFU42519; Wed, 17 Nov 2004 08:08:03 -0800 (PST) Message-ID: <419B7763.30309@cisco.com> Date: Wed, 17 Nov 2004 11:08:03 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] RE: Identity after reinvite References: <7927C67249E4AD43BC05B539AF0D129801AF4377@stntexch04.cis.neustar.com> <419A87CB.3030505@cisco.com> In-Reply-To: <419A87CB.3030505@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , sip@ietf.org, "Peterson, Jon" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Content-Transfer-Encoding: 7bit inline. Paul Kyzivat wrote: >> So it isn't that the auth service will reject the request; it MAY just >> forward the request normally. What will happen in that instance? Well, if >> the auth service role is instantiated by a proxy server, it will >> forward the >> request in accordance with the URI without adding an Identity header; it >> won't challenge the request, or what have you. > > > Good. You confirm what I was assuming. The MAY isn't good enough here. You want to be certain it WONT reject the request just because the From is wrong. > > I agree the basic request identity problem is separable from the others. > But it does seem that connected-party, response-identity, and reverse > direction requests in dialog are all entangled, and that changing > to/from may be a single solution good for all of them. I see a clear line between the various problems, but perhaps its just because I've not thought about it enough ;) One problem, which I am calling the "request identity problem", is how to identify the sender of a request. That problem exists for initial requests and mid-dialog requests alike. indeed, because the identity exists on a request by request basis, the fact that a request is part of a dialog has no bearing. If you buy this argument, it would strongly argue in favor of the approach I suggested - modifying the From for reverse requests in a dialog so that the From properly identifies the sender. A separate problem is how a UAC can securely determine the sequence of events that led to a request being retargeted. This is the much harder problem that I think is out of scope right now. Another problem is how to identify the sender of a response, and it is the exact inverse of the request identity problem. > >> I have a number of arguments about this, but here are just three: >> >> - Identity will succeed in the marketplace if it can be used >> opportunistically. Requiring UAs to change the From header field in this >> fashion forces them to become identity-aware, which is an impediment to >> adoption. Basically, we force UAs to be either backwards-compliant with >> RFC2543 or compliant with Identity. Tough choice, especially given >> that the >> UA might not be aware of its need to be either of those things. > > > Agree. This is a fair point. There is a middle ground though. If a UA doesn't set the From properly, the identity service simply doesn't sign the request. Thus, it is always OK for a client to do nothing to support identity. The consequence is that, in the case of retargeting, their identity won't be delivered to the caller for a mid-dialog request. I think that this is reasonable. However, if a UA wants, it can set the From properly, and then these requests can be signed. > >> - I also question whether or not the callee UA will even know which >> identity >> it needs to stick in the From header of requests in the backwards >> direction: >> after all, if the UA is registered under multiple AoRs, what exactly >> about >> the dialog-forming request will tell it definitively which identity it is >> supposed to use? While in some cases, this could be inferred from the >> Request-URI of the dialog-forming requests, it won't be sufficient in all >> cases, I think. The previous hop (last proxy server to handle the >> request) >> might also be a hint. Now, it could be that there's a good answer to this >> question, but if so, we need to know that answer. > > > There are many reasons why a UA with multiple registrations needs to > know which one was the source of an incoming call. And the UA can easily > achieve this by using distinct contacts in the registrations. I don't > think we need to lose sleep over those that choose not to do so. I don't see the problem. It should be able to use any identity it might otherwise assert in a request outside of the dialog. If the route set doesn't include the identity service for that domain, then there won't be any asserted identity. What this means is that servers that provide the identity service probably should record-route. > >> - Retargeting is inherently insecure, and no amount of wiggling with the >> sip-identity mechanism will repair this. If Alice sent a request to >> Bob, and >> a new request in the backwards direction comes from Edgar, I think >> there is >> -no- circumstance in which Alice should not view this as a potential >> security risk, regardless of the presence or absence of an Identity >> header, >> SIPS, or what have you. Trying to explain this aware flies in the face of >> common sense, and will be incomprehensible to actual users who will >> need to >> make security decisions based on the evidence collected from the >> protocol by >> their user agent. > > > Of course it is a potential security risk, which is why it is good to > report that it happened. (A good UA will hopefully note that the > connected party is not the called party and make a big fuss at its UI.) > But it is still good to know who in fact you ended up talking to. I agree. Indeed, with SIP today you not only don't know its been retargeted, nothing evne identifies who its been retargeted to. This seems even more of a risk. >> Don't forget, for example, that SIPS does not apply after the domain >> indicated by the Request-URI of the request, and so on. SIPS is not a >> powerful mechanism. Until we all acknowledge that we were mistaken in our >> formulation in RFC3261, and that SIPS, when present, signifies >> unambiguously >> that TLS should be used end-to-end, I do not think SIPS can be said to >> solve >> any of our problems. Once we have the connect-reuse mechanism nailed down >> firmly, I think it will be possible to shift to that understanding of >> SIPS, >> if we want to. SIPS is clear that there MUST be a secure channel at each hop - it just doesn't mandate TLS. In hindsight I agree it should have ideally done that, it does imply a security property which does, IMHO, prevent outsiders from launching the attack you describe. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 17 11:37:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16623 for ; Wed, 17 Nov 2004 11:37:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUSr1-0005Ss-8K for sip-web-archive@ietf.org; Wed, 17 Nov 2004 11:40:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUSgt-0000Xh-3j; Wed, 17 Nov 2004 11:29:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUScG-0007s0-2f for sip@megatron.ietf.org; Wed, 17 Nov 2004 11:25:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15345 for ; Wed, 17 Nov 2004 11:25:05 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUSeg-00054c-Df for sip@ietf.org; Wed, 17 Nov 2004 11:27:40 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 17 Nov 2004 08:39:45 -0800 X-BrightmailFiltered: true Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iAHGOGw0023423; Wed, 17 Nov 2004 08:24:17 -0800 (PST) Received: from [161.44.55.231] (dhcp-161-44-55-231.cisco.com [161.44.55.231]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFU43518; Wed, 17 Nov 2004 08:24:32 -0800 (PST) Message-ID: <419B7B40.1@cisco.com> Date: Wed, 17 Nov 2004 11:24:32 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peterson, Jon" Subject: Re: third alternative (was RE: [Sip] RE: Identity after reinvite) References: <7927C67249E4AD43BC05B539AF0D129801AF4382@stntexch04.cis.neustar.com> In-Reply-To: <7927C67249E4AD43BC05B539AF0D129801AF4382@stntexch04.cis.neustar.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7bit Cc: "'Cullen Jennings'" , "'sip@ietf.org'" , "'Paul H Kyzivat'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: 7bit inline. Peterson, Jon wrote: > I would like to suggest a third alternative: > > 3) Change nothing about in To/From. Requests in the backwards direction in a > dialog may go through the authentication service of the domain indicated in > the host portion of the From header of the request. If that is not possible, > do not supply request identity for such messages. This is pretty close to what I had just suggested in a mail I wrote a few minutes ago. I should have read the whole thread before responding I suppose ;) The difference between this and what I had proposed is that I think a UA should be *allowed* to change the From in its outbound request. > > While this seem like a non-starter in retargeting cases, requests get > retargeted for a reason. If the dialog-forming request was appropriately > delivered to the domain indicated in the Request-URI (biloxi.example.com), > and that domain chose to forward the request to another domain > (chicago.example.com), it did so because some entity was authorized to add > the chicago URI as a contact for the biloxi URI. In other words, this > approach views retargeting as if the callee's UA were actually registered at > biloxi "through" chicago, and that when the UA receives a dialog-forming > request, it is the To header that determines who should assert identity for > new requests in the backwards direction. In cases where the user contacted > at chicago does not possess credentials to authenticate themselves to > biloxi, I think it would be fair to say that requests in the backwards > direction should not get an Identity header. I think that it will almost never have such credentials. If it did, this wouldn't be retargeting. > To go any further, I think, > requires us to solve the response identity problem. This approach is, I > think, forward-compatible with any reasonable solution to the response > identity problem, though. > > The primary challenge of this approach is insuring that requests in the > backwards direction will actually go through the authentication service of > biloxi.com, since in many cases they ordinarily might not. I don't think you need to worry about that, since I don't think the client that is contacted at chicago.com will ever really have credentials for biloxi. It is far more likely that it will have a tls connection to chicago.com and its authentication service. If biloxi.com > Record-Routes its auth service in the dialog-forming request, this would > provide the right assurance (and seems plausible from a deployment > perspective); however, if chicago.com also Record-Routes itself, for > example, then the callee will not be able to form a direct TLS connection to > biloxi.com. It is also possible that the callee's UA could force a Route > header to connect to biloxi.com first, but this requires the callee's UA to > be identity-aware, which is undesirable when sip-identity is applied > opportunistically. > > But it isn't immediately clear how this is any different from normal cases > of request identity outside the scope of a dialog. There are any number of > possible reasons why the calling UA might not be able to connect directly > via TLS to its auth service (including interposing intermediaries and/or the > inability of the UA to force a Route through their auth service), and the > draft currently just says that we shouldn't provide Identity when we cannot > get the needed relationship between the UA and auth service. I've gotten a > lot of feedback (from Paul, Kumiko and others) that we should try to weaken > the requirement for direct TLS, and I intend to add some text to the next > version about some specific ways in which it is still acceptable to provide > identity even if a direct TLS connection cannot be formed. Certain forms of > weakness there could be beneficial to this approach. I think that having non-direct connections is a reasonable thing; generally my view has been that it should be possible to disaggregate a monolithic proxy into components in the same network, each of which is a SIP proxy performing parts of the overall processing in a domain. As long as appropriate security and trust relationships are maintained between these component proxies in a domain, I think equivalent security is afforded. As a follow up to my previous note, I tihnk part of the difficulty here is a difference in view about the problem being solved by asserted identities in the reverse direction. In my view, the sips mechanism provides an assurance ot the caller that the call got to the eventual target as a result of authorized forwarding at each hop along the way. Thus, the identity of requests in the reverse direction is not used to *authorize* whether or not the request should be processed. Rather, it serves merely as a reliable identification mechanism, as authorization is provided by sips. -JOnathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 17 11:39:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16818 for ; Wed, 17 Nov 2004 11:39:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUSsb-0005Wv-7G for sip-web-archive@ietf.org; Wed, 17 Nov 2004 11:42:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUSh8-0000hW-DW; Wed, 17 Nov 2004 11:30:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUSdH-00083K-Sh for sip@megatron.ietf.org; Wed, 17 Nov 2004 11:26:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15435 for ; Wed, 17 Nov 2004 11:26:08 -0500 (EST) Received: from firewall.citel.com ([62.190.107.60] helo=ivor.citel.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CUSfi-00055m-Ks for sip@ietf.org; Wed, 17 Nov 2004 11:28:43 -0500 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: [Sip] Boss-Secretary functionalities over SIP Date: Wed, 17 Nov 2004 16:21:26 -0000 Message-ID: Thread-Topic: [Sip] Boss-Secretary functionalities over SIP Thread-Index: AcTMAoqzur8tDBP3QFy3MLW2H3gLSQAuVuKw From: "Paul Pepper" To: "Pianigiani, Jacopo \(Jacopo\)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable Hi, There are various ways of offering a 'Boss-Secretary' feature. The simplest, which we can call shared-line-monitor, would involve using the dialog event package (see http://www.ietf.org/proceedings/04aug/I-D/draft-ietf-sipping-dialog-pack age-04.txt) to show the status of the monitored (the boss's) line. The SIP service examples ID (http://www.ietf.org/internet-drafts/draft-ietf-sipping-service-examples -07.txt) takes this a step further in its 'Single Line Extension' example, by letting another user join a monitored call. A more popular requirement, in my experience, permits shared lines/AORs to be 'seized' by any one of the users that have registered against that AOR. Seizing a line effectively involves obtaining a mutex on the shared line resource so that no other user can make a call out on that instance of the AOR. This has a number of benefits when it comes to managing calls on the shared line. The ID 'Implementing Bridged Line Appearances Using Session Initiation Protocol' makes use of the dialog event package to provide the line seize feature (http://ietfreport.isoc.org/all-ids/draft-anil-sipping-bla-01.txt) - this draft has now expired, but an updated version should be out soon. Paul. -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Pianigiani, Jacopo (Jacopo) Sent: Tuesday, November 16, 2004 5:10 PM To: 'sip@ietf.org' Subject: [Sip] Boss-Secretary functionalities over SIP Hi all, I am looking for an overview on SIP of the classic PABX Boss-Secretary functionality from the high level call flow perspective. Does anyone know where I could find this ?=20 thanks in advance and kind regards _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 17 11:44:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17527 for ; Wed, 17 Nov 2004 11:44:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUSxQ-0005i2-Fv for sip-web-archive@ietf.org; Wed, 17 Nov 2004 11:47:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUSit-0001Of-B1; Wed, 17 Nov 2004 11:31:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUSgb-0000Mj-Gg for sip@megatron.ietf.org; Wed, 17 Nov 2004 11:29:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15775 for ; Wed, 17 Nov 2004 11:29:34 -0500 (EST) Received: from mail.lumenvox.com ([206.169.193.45] helo=lv-svr.lumenvox.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUSj3-0005Bx-47 for sip@ietf.org; Wed, 17 Nov 2004 11:32:09 -0500 Received: from PROGTHOMAS ([10.0.0.141]) by lv-svr.lumenvox.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 17 Nov 2004 08:26:12 -0800 From: "Thomas Gal" To: Subject: RE: [Sip] How to get old messages on archives!! Date: Wed, 17 Nov 2004 08:29:05 -0800 Organization: LumenVox LLC MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <2D0CA64CDC33E14DA7AB043B8CC4D2BB0275873F@svr-exc.domain.com> Thread-Index: AcTMjCfkNqFcIoAHQZ6bOQsuMpt9qgANmMRQ Message-ID: X-OriginalArrivalTime: 17 Nov 2004 16:26:12.0656 (UTC) FILETIME=[27328300:01C4CCC2] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ThomasGal@LumenVox.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit -Tom thomasgal@lumenvox.com > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of vikram bhuskute > Sent: Wednesday, November 17, 2004 1:51 AM > To: sip@ietf.org > Subject: [Sip] How to get old messages on archives!! > > Hello , > I am an active member of this work group. It > so happened that i deleted some old mails. > Earlier i Use to see Old mails on the Archives link. But now > if i open ,it give today's and yesterday's mail. > I am force to go to link > http://www1.ietf.org/mail-archive/web/sip/current/index.html > and there is no other link there :( Please help !! > > > Vikram > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 17 11:52:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18424 for ; Wed, 17 Nov 2004 11:52:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUT4z-0005yP-6H for sip-web-archive@ietf.org; Wed, 17 Nov 2004 11:54:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUSxi-0005bZ-J5; Wed, 17 Nov 2004 11:47:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUSr6-0003b9-KV for sip@megatron.ietf.org; Wed, 17 Nov 2004 11:40:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16954 for ; Wed, 17 Nov 2004 11:40:25 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUStW-0005Xo-CU for sip@ietf.org; Wed, 17 Nov 2004 11:43:00 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 17 Nov 2004 08:55:01 -0800 X-BrightmailFiltered: true Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAHGdg3O012898; Wed, 17 Nov 2004 08:39:42 -0800 (PST) Received: from [161.44.55.231] (dhcp-161-44-55-231.cisco.com [161.44.55.231]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFU44516; Wed, 17 Nov 2004 08:39:43 -0800 (PST) Message-ID: <419B7ECF.1030103@cisco.com> Date: Wed, 17 Nov 2004 11:39:43 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Stredicke Subject: Re: [Sip] PING/PONG References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Christian Stredicke wrote: > So my understanding is: > > 1. We should use *only* STUN for refreshing bindings (either UDP or TCP, > what about TLS) Yes, TLS too. TLS runs ontop of TCP after all. > > 2. The user agent indicates if it can do it (no negotiation on > capabilities) > > 3. Refreshing must be done from the client > > Can we agree on that? Yes. Server originating refreshing is in the wrong direction. It is the client utilizing the service; if it wishes to make use of that service, it has to be responsible for refreshing the connection. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 17 12:31:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22541 for ; Wed, 17 Nov 2004 12:31:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUTgq-00076d-3b for sip-web-archive@ietf.org; Wed, 17 Nov 2004 12:33:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUTWm-0006eE-HN; Wed, 17 Nov 2004 12:23:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUTCV-0000gE-37 for sip@megatron.ietf.org; Wed, 17 Nov 2004 12:02:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19576 for ; Wed, 17 Nov 2004 12:02:32 -0500 (EST) Received: from firewall.citel.com ([62.190.107.60] helo=ivor.citel.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CUTEx-0006HU-1q for sip@ietf.org; Wed, 17 Nov 2004 12:05:07 -0500 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: [Sip] PING/PONG Date: Wed, 17 Nov 2004 16:58:11 -0000 Message-ID: Thread-Topic: [Sip] PING/PONG Thread-Index: AcTMxdvvfCy/R4b+R7CteRr8GeoUkQAALiag From: "Steve Langstaff" To: "Jonathan Rosenberg" , "Christian Stredicke" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Should point 2 read "The user agent server indicates if it can respond = to client refresh requests"? -- Steve Langstaff. -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of Jonathan Rosenberg Sent: 17 November 2004 16:40 To: Christian Stredicke Cc: sip@ietf.org Subject: Re: [Sip] PING/PONG Christian Stredicke wrote: > So my understanding is: >=20 > 1. We should use *only* STUN for refreshing bindings (either UDP or = TCP, > what about TLS) Yes, TLS too. TLS runs ontop of TCP after all. >=20 > 2. The user agent indicates if it can do it (no negotiation on > capabilities) >=20 > 3. Refreshing must be done from the client >=20 > Can we agree on that? Yes. Server originating refreshing is in the wrong direction. It is the=20 client utilizing the service; if it wishes to make use of that service,=20 it has to be responsible for refreshing the connection. -Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 17 12:59:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25126 for ; Wed, 17 Nov 2004 12:59:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUU7v-0007mn-Fa for sip-web-archive@ietf.org; Wed, 17 Nov 2004 13:01:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUTyp-0004f0-BA; Wed, 17 Nov 2004 12:52:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUTxQ-0004NA-Nj for sip@megatron.ietf.org; Wed, 17 Nov 2004 12:51:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24416 for ; Wed, 17 Nov 2004 12:51:01 -0500 (EST) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUTzq-0007a0-LS for sip@ietf.org; Wed, 17 Nov 2004 12:53:37 -0500 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iAHHoQ029295; Wed, 17 Nov 2004 12:50:26 -0500 (EST) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Nov 2004 12:50:27 -0500 Message-ID: From: "Mary Barnes" To: "'PROUVOST Sebastien RD-CORE-ISS'" , GARCIN Sebastien RD-CORE-ISS , "Jesske, R" , sip@ietf.org Subject: RE: [Sip] Privacy statements and History(draft-ietf-sip-history-i nfo-04.txt) Date: Wed, 17 Nov 2004 12:50:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.9 (/) X-Scan-Signature: 3b3709b7fb3320c78bd7b1555081f0fc X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0857168419==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: d49da3f50144c227c0d2fac65d3953e6 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0857168419== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4CCCD.DE1B3B15" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4CCCD.DE1B3B15 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, =20 I've again snipped the thread, but did want to propose the change that = I think will satisfy the concerns raised. =20 The change proposed is to change the last statement in the first = paragraph in section 4.3.3.1.1 from: "...the proxy MUST remove any hi-entry(s) prior to forwarding." to: "...the proxy SHOULD remove any hi-entry(s) prior to forwarding, = depending upon local policy and whether the proxy might know apriori that it can = rely on a downstream privacy service to apply the requested privacy."=20 =20 So, unless further concerns are raised on this proposed change, I'll = plan on incorporating that with any other last call comments in the -05 = version. =20 Mary=20 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of PROUVOST Sebastien RD-CORE-ISS Sent: Thursday, November 11, 2004 8:44 AM To: Barnes, Mary [NGC:B601:EXCH]; GARCIN Sebastien RD-CORE-ISS; Jesske, = R; sip@ietf.org Subject: RE: [Sip] Privacy statements and History(draft-ietf-sip-history-info-04.txt) Mary, Sebastien, Roland,=20 =20 I agree that we should let the possibility for a proxy not to remove = the hi-entry even if privacy is requested and even if the request is = forwarded to a Request-URI associated with a domain for which the proxy is not responsible (if there is an agreement between the domains that ensures = the proxy that privacy will be applied to the request).=20 I suggest a text that would look like (in case privacy is requested): = "the hi-entry SHOULD be removed by the proxy unless it knows that it can = rely on a downstream privacy service to apply the requested privacy ". =20 Sebastien. _____ =20 De : sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] De la part de = Mary Barnes Envoy=E9 : mercredi 10 novembre 2004 19:54 =C0 : GARCIN Sebastien RD-CORE-ISS; Jesske, R; sip@ietf.org Objet : RE: [Sip] Privacy statements and History (draft-ietf-sip-history-info-04.txt) I still contend that the SHOULD is sufficient. SHOULD means that in = general processing, if the hi-entry has a privacy header, then the usual = processing would be that it would be removed (i.e it was added for a specific = reason and in general should be used to remove the entries based on well = defined criteria). If there are reasons, such as local policy, that would = allow the forwarding in specific cases, then it's okay that it is forwarded. I = think the use of MAY results in less precision and I think the value and = critera for associating and removing the privacy header with the hi-entry = becomes much less clear. =20 I'd like to hear more opinions on this topic, prior to agreeing to = making the change (from the MUST to MAY rather than MUST to SHOULD).=20 Regards,=20 Mary=20 -----Original Message-----=20 From: GARCIN Sebastien RD-CORE-ISS [mailto:sebastien.garcin@francetelecom.com ]=20 Sent: Wednesday, November 10, 2004 12:28 PM=20 To: Barnes, Mary [NGC:B601:EXCH]; Jesske, R; sip@ietf.org=20 Cc: VL-T-Com-T-TE332@vli.telekom.de=20 Subject: RE: [Sip] Privacy statements and History (draft-ietf-sip-history-info-04.txt)=20 Mary and roland,=20 Actually, the statement regarding the forwarding of hi-entries beyond = the domain for which the proxy is responsible should rather be a matter of = local policy and thus a MAY should be used instead of SHOULD. We are = potentially dealing with network boundaries where agreements for forwarding such = kind information can be reached.=20 Section 4.3.3.1.1=20 This section should be re-reworded in accordance with the statement = above (I can provide some text is we can agree).=20 Section 4.3.3.1 is ok (apologies for not being explicit)=20 Best regards,=20 s=E9bastien=20 =20 ------Remainder of thread has been = deleted by Mary------------------ ------_=_NextPart_001_01C4CCCD.DE1B3B15 Content-Type: text/html; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by zrtps0kp.nortelnetworks.com id iAHHoQ029295 Content-Transfer-Encoding: quoted-printable Message
Hi=20 all,
 
I've=20 again snipped the thread, but did want to propose the change that I think= will=20 satisfy the concerns raised.
 
The=20 change proposed is to change the last statement in the first paragraph in= =20 section 4.3.3.1.1 from:
"...the proxy MUST remove any hi-entry(s) prior to=20 forwarding."
to:
"...the proxy&n= bsp;SHOULD=20 remove any hi-entry(s) prior to forwarding, depending upon local policy&n= bsp;and=20 whether the proxy might know apriori that it can rely on a downstream pri= vacy=20 service to apply the requested privacy." 
&nb= sp;
So, unless further concerns ar= e raised on=20 this proposed change, I'll plan on incorporating that with any other last= call=20 comments in the -05 version.
&nb= sp;
Mary=20
<= FONT=20 face=3DTahoma size=3D2>-----Original Message-----
From:=20 sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of=20 PROUVOST Sebastien RD-CORE-ISS
Sent: Thursday, November 1= 1, 2004=20 8:44 AM
To: Barnes, Mary [NGC:B601:EXCH]; GARCIN Sebastien=20 RD-CORE-ISS; Jesske, R; sip@ietf.org
Subject: RE: [Sip] Priva= cy=20 statements and=20 History(draft-ietf-sip-history-info-04.txt)

Mary, Sebastien, Roland,
 
I agree that we should let the possibility for= a proxy=20 not to remove the hi-entry even if privacy is requested and even if the= =20 request is forwarded to a Request-URI associated with a domain for whic= h the=20 proxy is not responsible (if there is an agreement betwe= en=20 the domains that ensures the proxy that privacy will be applied to= the=20 request).
I suggest a text that would look like&nbs= p;(in case=20 privacy is requested): "the hi-entry SHOULD be removed by the proxy unl= ess it=20 knows that it can rely on a downstream privacy service to apply the req= uested=20 privacy ".
 
Sebastien.

De : sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] De la part de Mary=20 Barnes
Envoy=E9 : mercredi 10 novembre 2004=20 19:54
=C0 : GARCIN Sebastien RD-CORE-ISS; Jesske, R;=20 sip@ietf.org
Objet : RE: [Sip] Privacy statements and Hi= story=20 (draft-ietf-sip-history-info-04.txt)

I still contend that the SHOULD is sufficient.  = SHOULD=20 means that in general processing, if the hi-entry has a privacy header,= then=20 the usual processing would be that it would be removed (i.e it was adde= d for a=20 specific reason and in general should be used to remove the entries bas= ed on=20 well defined criteria).  If there are reasons, such as local polic= y, that=20 would allow the forwarding in specific cases, then it's okay that it is= =20 forwarded.  I think the use of MAY results in less precision and I= think=20 the value and critera for associating and removing the privacy header w= ith the=20 hi-entry becomes much less clear. 

I'd like to hear more opinions on this topic, prior t= o=20 agreeing to making the change (from the MUST to MAY rather than MUST to= =20 SHOULD).

Regards,
Mary

-----Original Message-----
= From:=20 GARCIN Sebastien RD-CORE-ISS [mailto:sebastien.gar= cin@francetelecom.com]=20
Sent: Wednesday, November 10, 2004 12:28 PM=20
To: Barnes, Mary [NGC:B601:EXCH]; Jesske, R;=20 sip@ietf.org
Cc:=20 VL-T-Com-T-TE332@vli.telekom.de
Subject: RE: = [Sip]=20 Privacy statements and History (draft-ietf-sip-history-info-04.txt)=20


Mary and roland,

Actually, the statement regarding the forwarding of h= i-entries=20 beyond the domain for which the proxy is responsible should rather be a= matter=20 of local policy and thus a MAY should be used instead of SHOULD. We are= =20 potentially dealing with network boundaries where agreements for forwar= ding=20 such kind information can be reached.

Section 4.3.3.1.1
This sect= ion should=20 be re-reworded in accordance with the statement above (I can provide so= me text=20 is we can agree).

Section 4.3.3.1 is ok (apologies for not being=20 explicit)

Best regards,
s=E9bastien

           &n= bsp;           &nb= sp;        

       =20        =20        =20         ------Remaind= er of=20 thread has been deleted by=20 Mary------------------


------_=_NextPart_001_01C4CCCD.DE1B3B15-- --===============0857168419== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0857168419==-- From sip-bounces@ietf.org Wed Nov 17 13:07:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25822 for ; Wed, 17 Nov 2004 13:07:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUUFc-0007yh-95 for sip-web-archive@ietf.org; Wed, 17 Nov 2004 13:09:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUU83-0006j9-Kv; Wed, 17 Nov 2004 13:02:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUU3r-0005WN-2L for sip@megatron.ietf.org; Wed, 17 Nov 2004 12:57:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24992 for ; Wed, 17 Nov 2004 12:57:39 -0500 (EST) Received: from natnoddy.rzone.de ([81.169.145.166]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUU6I-0007kA-U9 for sip@ietf.org; Wed, 17 Nov 2004 13:00:15 -0500 Received: from snom.de (pD951647B.dip.t-dialin.net [217.81.100.123]) by post.webmailer.de (8.13.1/8.13.1) with ESMTP id iAHHvZlE023608; Wed, 17 Nov 2004 18:57:36 +0100 (MET) 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] PING/PONG X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 17 Nov 2004 18:57:35 +0100 Message-ID: Thread-Topic: [Sip] PING/PONG thread-index: AcTMxdvvfCy/R4b+R7CteRr8GeoUkQAALiagAAD4T3A= From: "Christian Stredicke" To: "Steve Langstaff" , "Jonathan Rosenberg" X-Spam-Score: 0.2 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable Well, thats a good question. I think everybody should prepare their server for responding to STUN requests on the SIP port. We do since two years.-) CS=20 > -----Original Message----- > From: Steve Langstaff [mailto:steve.langstaff@citel.com]=20 > Sent: Wednesday, November 17, 2004 12:16 PM > To: Jonathan Rosenberg; Christian Stredicke > Cc: sip@ietf.org > Subject: RE: [Sip] PING/PONG >=20 > Should point 2 read "The user agent server indicates if it=20 > can respond to client refresh requests"? >=20 > -- > Steve Langstaff. >=20 >=20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On=20 > Behalf Of Jonathan Rosenberg > Sent: 17 November 2004 16:40 > To: Christian Stredicke > Cc: sip@ietf.org > Subject: Re: [Sip] PING/PONG >=20 >=20 >=20 >=20 > Christian Stredicke wrote: >=20 > > So my understanding is: > >=20 > > 1. We should use *only* STUN for refreshing bindings (either UDP or=20 > > TCP, what about TLS) >=20 > Yes, TLS too. TLS runs ontop of TCP after all. >=20 > >=20 > > 2. The user agent indicates if it can do it (no negotiation on > > capabilities) > >=20 > > 3. Refreshing must be done from the client > >=20 > > Can we agree on that? >=20 > Yes. >=20 > Server originating refreshing is in the wrong direction. It=20 > is the client utilizing the service; if it wishes to make use=20 > of that service, it has to be responsible for refreshing the=20 > connection. >=20 > -Jonathan R. >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > 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 From sip-bounces@ietf.org Wed Nov 17 16:07:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13648 for ; Wed, 17 Nov 2004 16:07:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUX3m-0003xs-HD for sip-web-archive@ietf.org; Wed, 17 Nov 2004 16:09:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUWfe-0001J6-LX; Wed, 17 Nov 2004 15:44:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUWXp-0005WH-D4 for sip@megatron.ietf.org; Wed, 17 Nov 2004 15:36:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09870 for ; Wed, 17 Nov 2004 15:36:47 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUWaG-0002jd-5v for sip@ietf.org; Wed, 17 Nov 2004 15:39:23 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 17 Nov 2004 12:38:18 -0800 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iAHKaBw0000884; Wed, 17 Nov 2004 12:36:12 -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 MAA02550; Wed, 17 Nov 2004 12:36:09 -0800 (PST) Message-Id: <4.3.2.7.2.20041117141302.03932598@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 17 Nov 2004 14:36:16 -0600 To: Mpierce1@aol.com From: "James M. Polk" Subject: Re: [Sip] -RP-05.txt: section 7.1 and (rough) consensus debate In-Reply-To: <12c.51049647.2ecca63d@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: An.Nguyen@ncs.gov, rohan@ekabal.com, Scott Morrison , jgunn6@csc.com, Dean Willis , sip@ietf.org, oran@cisco.com, Pete Babendreier X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 At 08:03 AM 11/17/2004 -0500, Mpierce1@aol.com wrote: >In a message dated 11/16/2004 7:42:29 PM W. Europe Standard Time, >jmpolk@cisco.com writes: >> >[MAP] Since the document should say that it does not address interworking >> >between namespaces, it should not contain this material. >> >>giving examples to clarify a known area of confusion is a good thing - and >>will stay in the document. > >[MAP] The above results in a serious contradiction. You agree that the >document should not describe dependencies, then include material that >certainly describes dependencies (what combinations are and are not allowed). Mike, pay attention to the ordering of two namespaces in the section - there are ZERO dependencies between namespaces, just that the order within each namespace MUST be maintained regardless of where one value from one namespace is places in relative priority order to one or more from another namespace. Implementors MUST have one order - no matter how many namespaces are supported at a server/endpoint - to relieve confusion of which is prioritized over or under another. This is the same rule that applies within a namespace: there MUST be one order of priority, period (No wildcards) to ensure interoperability. >This will confuse more readers into thinking that there are some >dependencies. Because it is confusing you does not mean it is confusing others. Every single coder I've talked to on this subject understands once they have seen these examples. That makes them worthy for inclusion. >>it will not be deleted, though it might be modified to add or clarify >>meaning >[MAP] It's too bad that you're taking the position that you have the final >say on what is and is not included in the document regardless of the >comments and results of any e-mail discussion. This email discussion is from you, not from a rough consensus of the list. >As far as I'm concerned, you must get the WG consensus The IETF mantra is "rough consensus and running code" You don't represent rough consensus - despite taking over the microphone last week > for anything that you added in -05 in order to retain it in -06. Are you saying I cannot submit a document without getting consensus from the list? >Contrary to what Jon Peterson stated at the meeting Contrary to what an Area Director said to you in a meeting.... was that before or after you threatened the IETF with US Government force if the IETF didn't comply with your demands? remember - about 15 people heard you do this >, RFC2418 defines the responsibilities of the editor as follows: > > Most IETF working groups focus their efforts on a document, or set of > documents, that capture the results of the group's work. A working > group generally designates a person or persons to serve as the Editor > for a particular document. The Document Editor is responsible for > ensuring that the contents of the document accurately reflect the > decisions that have been made by the working group. If you feel this way, you have a right to complain to the WG chairs >Mike 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 sip-bounces@ietf.org Wed Nov 17 16:54:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22920 for ; Wed, 17 Nov 2004 16:54:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUXnf-0006gv-0k for sip-web-archive@ietf.org; Wed, 17 Nov 2004 16:57:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUXPl-0005E5-PR; Wed, 17 Nov 2004 16:32:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUX5b-0007gw-6d for sip@megatron.ietf.org; Wed, 17 Nov 2004 16:11:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14295 for ; Wed, 17 Nov 2004 16:11:41 -0500 (EST) Received: from amer-mta02.csc.com ([20.137.2.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUX84-0004C0-D5 for sip@ietf.org; Wed, 17 Nov 2004 16:14:17 -0500 Received: from csc.com (va-fch34.csc.com [20.6.39.227]) by amer-mta02.csc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id iAHLBbC1011382; Wed, 17 Nov 2004 16:11:37 -0500 (EST) Subject: Re: [Sip] -RP-05.txt: section 7.1 and (rough) consensus debate To: "James M. Polk" X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Janet P Gunn Date: Wed, 17 Nov 2004 16:13:19 -0500 X-MIMETrack: Serialize by Router on VA-FCH34/SRV/CSC(Release 6.0.3|September 26, 2003) at 11/17/2004 04:12:31 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: An.Nguyen@ncs.gov, rohan@ekabal.com, Scott Morrison , Dean Willis , sip@ietf.org, oran@cisco.com, Pete Babendreier , Mpierce1@aol.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Technical question about ordering of the namespaces and values One approach we have used (in WPS) is a) When the resource pool is relatively small (e.g., radio traffic channels) we serve the queue based on priority order first, and time stamp second. b) When the resource pool is large (e.g. landline trunk groups) we serve the queue (amongst all and only the "labeled" calls) by time stamp, without regard for the actual priority level. Does the text in section 7.1 PREVENT me from serving SIP messages WITH regard to BOTH the namespace and value (and timestamp) in some contexts, and with regard to ONLY the namespace (and timestamp), but NOT the value in other contexts? I can foresee work arounds if it does prevent it, but I would be happier if that behavior were NOT prevented. 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. ---------------------------------------------------------------------------------------- "James M. Polk" cc: An.Nguyen@ncs.gov, Janet P Gunn/FED/CSC@CSC, oran@cisco.com, sip@ietf.org, Dean Willis , rohan@ekabal.com, 11/17/2004 03:36 "Pete Babendreier" , "Scott Morrison" PM Subject: Re: [Sip] -RP-05.txt: section 7.1 and (rough) consensus debate At 08:03 AM 11/17/2004 -0500, Mpierce1@aol.com wrote: >In a message dated 11/16/2004 7:42:29 PM W. Europe Standard Time, >jmpolk@cisco.com writes: snip Mike, pay attention to the ordering of two namespaces in the section - there are ZERO dependencies between namespaces, just that the order within each namespace MUST be maintained regardless of where one value from one namespace is places in relative priority order to one or more from another namespace. Implementors MUST have one order - no matter how many namespaces are supported at a server/endpoint - to relieve confusion of which is prioritized over or under another. This is the same rule that applies within a namespace: there MUST be one order of priority, period (No wildcards) to ensure interoperability. snip 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 sip-bounces@ietf.org Wed Nov 17 17:09:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24474 for ; Wed, 17 Nov 2004 17:09:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUY1a-0007Aw-Qo for sip-web-archive@ietf.org; Wed, 17 Nov 2004 17:11:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUXn9-0007kZ-VG; Wed, 17 Nov 2004 16:56:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUXVD-0000Kx-Ic for sip@megatron.ietf.org; Wed, 17 Nov 2004 16:38:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20736 for ; Wed, 17 Nov 2004 16:38:09 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUXXg-00063N-ND for sip@ietf.org; Wed, 17 Nov 2004 16:40:46 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 Nov 2004 13:37:20 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Wed, 17 Nov 2004 13:37:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 17 Nov 2004 13:37:21 -0800 Message-ID: Thread-Topic: RFC 3261: BUG or clarification is needed Thread-Index: AcTM7Z5h5whfV7lnTYS8WMI83PV5uw== From: "Orit Levin" To: X-OriginalArrivalTime: 17 Nov 2004 21:37:37.0015 (UTC) FILETIME=[A7F17070:01C4CCED] X-Spam-Score: 0.5 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Subject: [Sip] RFC 3261: BUG or clarification is needed X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1589178438==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f This is a multi-part message in MIME format. --===============1589178438== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4CCED.A1B95BDF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4CCED.A1B95BDF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Guys, I would like to get a clarification on the properties of the Contact header in requests and responses different from REGISTER. Is there a common understanding, that a Contact header can contain any valid SIP URI that, especially when used outside the original dialog, needs to be resolved according to RFC 3263 (i.e. including the SRV lookup) ? =20 I couldn't find any statement along these lines in any of the relevant RFCs. =20 For example, in Redirect requests, we are reusing the Contact header in order to point to an alternative destination which can have nothing in common with the original domain. =20 Yet another example, the current GRUU draft is silent about the ability of resolving GRUU using RFC 3263 procedures. From the draft: "the GRUU MUST exhibit the following properties: o The domain part of the URI is an IP address present on the public Internet, or, if it is a host name, exists in the global DNS and corresponds to an IP address present on the public Internet." =20 =20 For the interoperability sake, I believe that it is very important to file this clarification against RFC 3261 and also point to RFC 3263 for GRUU properties/location procedures. =20 Thanks, Orit. ------_=_NextPart_001_01C4CCED.A1B95BDF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Guys,
I = would like to=20 get a clarification on the properties of the Contact header in = requests and=20 responses different from REGISTER.
Is = there a common=20 understanding, that a Contact header can contain any valid SIP = URI=20 that, especially when used outside the original dialog, needs to be = resolved according to RFC 3263 = (i.e. including the SRV=20 lookup) ?
 
I = couldn't find any=20 statement along these lines in any of the relevant = RFCs.
 
For = example, in=20 Redirect requests, we are reusing the Contact header in order to point = to an=20 alternative destination which can have nothing in common with the = original=20 domain.
 
Yet=20 another example, the current GRUU draft is silent = about the=20 ability of resolving GRUU using RFC 3263 = procedures.=20 >From the draft:
"the GRUU MUST exhibit the following = properties:

   o  The domain part of the URI is = an IP=20 address present on the public

      = Internet, or, if=20 it is a host name, exists in the global DNS and

      = corresponds to=20 an IP address present on the public Internet."
 
 
For = the=20 interoperability sake, I believe that it is very important to file this=20 clarification against RFC 3261 and also point to RFC = 3263 for=20 GRUU properties/location procedures.
 
Thanks,
Orit.
------_=_NextPart_001_01C4CCED.A1B95BDF-- --===============1589178438== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1589178438==-- From sip-bounces@ietf.org Wed Nov 17 17:22:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25612 for ; Wed, 17 Nov 2004 17:22:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUYEJ-0007Xe-86 for sip-web-archive@ietf.org; Wed, 17 Nov 2004 17:24:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUXvY-0001pw-LM; Wed, 17 Nov 2004 17:05:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUXep-0004SS-E1 for sip@megatron.ietf.org; Wed, 17 Nov 2004 16:48:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22219 for ; Wed, 17 Nov 2004 16:48:05 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUXhJ-0006Rj-Nh for sip@ietf.org; Wed, 17 Nov 2004 16:50:42 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 17 Nov 2004 13:47:37 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id iAHLlXVx022983; Wed, 17 Nov 2004 13:47:33 -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 NAA09622; Wed, 17 Nov 2004 13:47:31 -0800 (PST) Message-Id: <4.3.2.7.2.20041117151711.027d2f00@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 17 Nov 2004 15:47:37 -0600 To: Janet P Gunn From: "James M. Polk" Subject: Re: [Sip] -RP-05.txt: section 7.1 on priority-value interleaving In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: An.Nguyen@ncs.gov, rohan@ekabal.com, Scott Morrison , Dean Willis , sip@ietf.org, oran@cisco.com, Pete Babendreier , Mpierce1@aol.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Section 7.1 is merely to give examples to readers that show the order within a namespace must be maintained regardless of how many other namespaces exist (that are supported) by that SIP element. The section also provides examples of how the orders can be in multiple combinations of groupings, as long as the overall order within each namespace is not changed. Foo.3 Foo.3 Bar.C Foo.2 Bar.C Foo.3 Foo.1 or Foo.2 or Foo.2 Bar.C Bar.B Foo.1 Bar.B Foo.1 Bar.B Bar.A Bar.A Bar.A In each of these examples from section 7.1, the order of Foo.* remains the same (3 then 2 then 1), as does the order for Bar.* (C then B then A). Where each individual priority-value is relative to the other namespace priority-values is NOT specified (i.e where 3 fits into C,B,A, or where B fits into 3,2,1). The interleaved order of multiple namespaces is up to implementations and local policy to decide. The only aspect you are PREVENTED from doing in this regard (to comply with this spec - whenever that is) is reordering priority-values within the same namespace no matter how many namespaces are supported. From a slightly different angle, you can consider two priority-values from two namespaces equivalent. The example given is: Bar.C (highest priority) Foo.3 Bar.B <= these 2 are considered equivalent) Foo.2 Bar.A <= these 2 are considered equivalent) Foo.1 (lowest priority) In this case, you can use some other indication to determine within your network if Foo.3 is to be treated above or below Bar.B - or you can leave them as identical in treatment. other answers below At 04:13 PM 11/17/2004 -0500, Janet P Gunn wrote: >Technical question about ordering of the namespaces and values > >One approach we have used (in WPS) is > >a) When the resource pool is relatively small (e.g., radio traffic >channels) we serve the queue based on priority order first, and time stamp >second. ok >b) When the resource pool is large (e.g. landline trunk groups) we serve >the queue (amongst all and only the "labeled" calls) by time stamp, without >regard for the actual priority level. the order of priority-value cannot change - if you wish to comply with this specification (once it becomes one). I know you plan on primarily using 1 of your 5 priority levels. Within the same level, you can use whatever you want to apply whatever policy/treatment you want and still comply with this spec (once it becomes one). >Does the text in section 7.1 PREVENT me from serving SIP messages WITH >regard to BOTH the namespace and value (and timestamp) in some contexts, >and with regard to ONLY the namespace (and timestamp), but NOT the value in >other contexts? no prevention here >I can foresee work arounds if it does prevent it, it doesn't >but I would be happier if >that behavior were NOT prevented. it's not Are you happier? >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. >---------------------------------------------------------------------------------------- > > > > > > > "James M. > Polk" > > > @cisco.com> cc: > An.Nguyen@ncs.gov, Janet P Gunn/FED/CSC@CSC, oran@cisco.com, > sip@ietf.org, Dean Willis > , rohan@ekabal.com, > 11/17/2004 03:36 "Pete Babendreier" > , "Scott Morrison" > PM > > Subject: Re: [Sip] > -RP-05.txt: section 7.1 and (rough) consensus debate > > > > > > >At 08:03 AM 11/17/2004 -0500, Mpierce1@aol.com wrote: > >In a message dated 11/16/2004 7:42:29 PM W. Europe Standard Time, > >jmpolk@cisco.com writes: > >snip > >Mike, pay attention to the ordering of two namespaces in the section - >there are ZERO dependencies between namespaces, just that the order within >each namespace MUST be maintained regardless of where one value from one >namespace is places in relative priority order to one or more from another >namespace. Implementors MUST have one order - no matter how many namespaces >are supported at a server/endpoint - to relieve confusion of which is >prioritized over or under another. This is the same rule that applies >within a namespace: there MUST be one order of priority, period (No >wildcards) to ensure interoperability. > >snip > >cheers, >James > > ******************* > Truth is not to be argued... it is to be presented 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 sip-bounces@ietf.org Wed Nov 17 17:29:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26521 for ; Wed, 17 Nov 2004 17:29:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUYLD-0007ky-Ot for sip-web-archive@ietf.org; Wed, 17 Nov 2004 17:31:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUY6y-0005YB-Fy; Wed, 17 Nov 2004 17:17:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUXt1-0001CL-A0 for sip@megatron.ietf.org; Wed, 17 Nov 2004 17:02:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23933 for ; Wed, 17 Nov 2004 17:02:44 -0500 (EST) Received: from amer-mta01.csc.com ([20.137.2.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUXvV-000710-01 for sip@ietf.org; Wed, 17 Nov 2004 17:05:22 -0500 Received: from csc.com (va-fch34.csc.com [20.6.39.227]) by amer-mta01.csc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id iAHM2i1F016032; Wed, 17 Nov 2004 17:02:44 -0500 (EST) Subject: Re: [Sip] -RP-05.txt: section 7.1 on priority-value interleaving To: "James M. Polk" X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Janet P Gunn Date: Wed, 17 Nov 2004 17:04:29 -0500 X-MIMETrack: Serialize by Router on VA-FCH34/SRV/CSC(Release 6.0.3|September 26, 2003) at 11/17/2004 05:03:38 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: An.Nguyen@ncs.gov, rohan@ekabal.com, Scott Morrison , Dean Willis , sip@ietf.org, oran@cisco.com, Pete Babendreier , Mpierce1@aol.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Yes, I am happier. 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. ---------------------------------------------------------------------------------------- "James M. Polk" cc: An.Nguyen@ncs.gov, Dean Willis , Mpierce1@aol.com, oran@cisco.com, "Pete Babendreier" , 11/17/2004 04:47 rohan@ekabal.com, "Scott Morrison" , sip@ietf.org PM Subject: Re: [Sip] -RP-05.txt: section 7.1 on priority-value interleaving Are you happier? 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 sip-bounces@ietf.org Wed Nov 17 18:11:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00129 for ; Wed, 17 Nov 2004 18:11:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUZ0O-0000ER-3u for sip-web-archive@ietf.org; Wed, 17 Nov 2004 18:14:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUYjc-0007eU-94; Wed, 17 Nov 2004 17:57:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUYcI-0005r0-Pf for sip@megatron.ietf.org; Wed, 17 Nov 2004 17:49:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28140 for ; Wed, 17 Nov 2004 17:49:31 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUYem-0008DR-Gx for sip@ietf.org; Wed, 17 Nov 2004 17:52:10 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 17 Nov 2004 14:52:55 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iAHMmxPJ019010; Wed, 17 Nov 2004 14:48:59 -0800 (PST) Received: from cisco.com ([161.44.79.125]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ANC82387; Wed, 17 Nov 2004 17:48:58 -0500 (EST) Message-ID: <419BD55B.6060001@cisco.com> Date: Wed, 17 Nov 2004 17:48:59 -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: Orit Levin Subject: Re: [Sip] RFC 3261: BUG or clarification is needed References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Orit Levin wrote: > Guys, > I would like to get a clarification on the properties of the Contact > header in requests and responses different from REGISTER. > Is there a common understanding, that a Contact header can contain any > valid SIP URI that, especially when used outside the original dialog, > needs to be resolved according to RFC 3263 (i.e. including the SRV lookup) ? Yes. > I couldn't find any statement along these lines in any of the relevant RFCs. Why would any special statement be required? The address in the contact gets included in some message, and then the rules for how to resolve it are spelled out. It doesn't matter where it came from. > For example, in Redirect requests, we are reusing the Contact header in > order to point to an alternative destination which can have nothing in > common with the original domain. BTW, in some contexts (such as 3xx) the contact addresses need not even be ones used by sip. You are allowed to redirect to an http uri if you like. > Yet another example, the current GRUU draft is silent about the ability > of resolving GRUU using RFC 3263 procedures. >From the draft: > "the GRUU MUST exhibit the following properties: > > o The domain part of the URI is an IP address present on the public > > Internet, or, if it is a host name, exists in the global DNS and > > corresponds to an IP address present on the public Internet." > > > For the interoperability sake, I believe that it is very important to > file this clarification against RFC 3261 and also point to RFC 3263 for > GRUU properties/location procedures. I think this requirement is implicit. Paul > Thanks, > Orit. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 17 18:54:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03979 for ; Wed, 17 Nov 2004 18:54:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUZg1-0001Ac-2e for sip-web-archive@ietf.org; Wed, 17 Nov 2004 18:57:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUZOo-00070f-KV; Wed, 17 Nov 2004 18:39:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUZEs-0004pl-El for sip@megatron.ietf.org; Wed, 17 Nov 2004 18:29:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01906 for ; Wed, 17 Nov 2004 18:29:23 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUZHL-0000Za-MJ for sip@ietf.org; Wed, 17 Nov 2004 18:32:02 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 Nov 2004 15:28:53 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Wed, 17 Nov 2004 15:28:52 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RFC 3261: BUG or clarification is needed Date: Wed, 17 Nov 2004 15:29:08 -0800 Message-ID: Thread-Topic: [Sip] RFC 3261: BUG or clarification is needed Thread-Index: AcTM95vqoqQ8+1aeTnuBFhdMUB9FrgABKKXg From: "Orit Levin" To: "Paul Kyzivat" X-OriginalArrivalTime: 17 Nov 2004 23:28:52.0839 (UTC) FILETIME=[330B5770:01C4CCFD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: quoted-printable Paul, Thanks! As long as it is accepted by everyone - it definitely works for me. More inline. Orit. > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Wednesday, November 17, 2004 2:49 PM > To: Orit Levin > Cc: sip@ietf.org > Subject: Re: [Sip] RFC 3261: BUG or clarification is needed >=20 >=20 >=20 > Orit Levin wrote: > > Guys, > > I would like to get a clarification on the properties of=20 > the Contact=20 > > header in requests and responses different from REGISTER. > > Is there a common understanding, that a Contact header can=20 > contain any=20 > > valid SIP URI that, especially when used outside the=20 > original dialog,=20 > > needs to be resolved according to RFC 3263 (i.e. including=20 > the SRV lookup) ? >=20 > Yes. Great. >=20 > > I couldn't find any statement along these lines in any of=20 > the relevant RFCs. >=20 > Why would any special statement be required? The address in=20 > the contact gets included in some message, and then the rules=20 > for how to resolve it are spelled out. It doesn't matter=20 > where it came from. Because I am not sure at all that many implementations actually do it today and we need to encourage them to do so. >=20 > > For example, in Redirect requests, we are reusing the=20 > Contact header=20 > > in order to point to an alternative destination which can=20 > have nothing=20 > > in common with the original domain. >=20 > BTW, in some contexts (such as 3xx) the contact addresses=20 > need not even be ones used by sip. You are allowed to=20 > redirect to an http uri if you like. Yes, I know :-) >=20 > > Yet another example, the current GRUU draft is silent about the=20 > > ability of resolving GRUU using RFC 3263 procedures. >From=20 > the draft: > > "the GRUU MUST exhibit the following properties: > >=20 > > o The domain part of the URI is an IP address present on the=20 > > public > >=20 > > Internet, or, if it is a host name, exists in the=20 > global DNS and > >=20 > > corresponds to an IP address present on the public Internet." > > =20 > > =20 > > For the interoperability sake, I believe that it is very=20 > important to=20 > > file this clarification against RFC 3261 and also point to RFC 3263=20 > > for GRUU properties/location procedures. >=20 > I think this requirement is implicit. Yes, most probably, but since this case is left out from the section above - the reader can be mislead by the current text. >=20 > Paul >=20 > > Thanks, > > Orit. > >=20 > >=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=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 17 19:40:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07962 for ; Wed, 17 Nov 2004 19:40:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUaOe-0002Hs-1i for sip-web-archive@ietf.org; Wed, 17 Nov 2004 19:43:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUaJC-0005Xe-7Z; Wed, 17 Nov 2004 19:37:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUaE5-0004J6-Q1 for sip@megatron.ietf.org; Wed, 17 Nov 2004 19:32:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07079 for ; Wed, 17 Nov 2004 19:32:38 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUaGb-00024E-O8 for sip@ietf.org; Wed, 17 Nov 2004 19:35:18 -0500 Received: from [63.110.3.165] ([64.100.183.165]) (authenticated bits=0) by nylon.softarmor.com (8.12.11/8.12.11) with ESMTP id iAI0XAQt003085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Nov 2004 18:33:12 -0600 Message-ID: <419BEDA0.2080709@softarmor.com> Date: Wed, 17 Nov 2004 18:32:32 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peterson, Jon" , sip@ietf.org Subject: Re: [Sip] RE: Identity after reinvite References: <7927C67249E4AD43BC05B539AF0D129801AF4377@stntexch04.cis.neustar.com> In-Reply-To: <7927C67249E4AD43BC05B539AF0D129801AF4377@stntexch04.cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Jon said: >Don't forget, for example, that SIPS does not apply after the domain >indicated by the Request-URI of the request, and so on. SIPS is not a >powerful mechanism. Until we all acknowledge that we were mistaken in our >formulation in RFC3261, and that SIPS, when present, signifies unambiguously >that TLS should be used end-to-end, I do not think SIPS can be said to solve >any of our problems. Once we have the connect-reuse mechanism nailed down >firmly, I think it will be possible to shift to that understanding of SIPS, >if we want to. > > > Even if SIPS was specified to be end-to-end, it would not resolve the issue of a non-compliant (for whatever reason) proxy. This is one of the reasons I argued for the current text in 3261. That which is on "the other side" of the responsible proxy might be SIP, it might be SIPS, or it might be H.323, there's no way to tell using just SIPS from "outside", and no amount of "requiring" otherwise in a specification will change this reality. In SIPS, each proxy is a transitive trust boundary, and that's just the way it is. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 17 20:28:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12482 for ; Wed, 17 Nov 2004 20:28:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUb94-0003LP-Ij for sip-web-archive@ietf.org; Wed, 17 Nov 2004 20:31:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUb3H-0007Vt-VK; Wed, 17 Nov 2004 20:25:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUavQ-0006Eg-VN for sip@megatron.ietf.org; Wed, 17 Nov 2004 20:17:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11695 for ; Wed, 17 Nov 2004 20:17:26 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUaxw-00038o-S3 for sip@ietf.org; Wed, 17 Nov 2004 20:20:05 -0500 Received: from [63.110.3.165] ([64.100.183.165]) (authenticated bits=0) by nylon.softarmor.com (8.12.11/8.12.11) with ESMTP id iAI1HvkG003295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Nov 2004 19:17:58 -0600 Message-ID: <419BF81F.4070504@softarmor.com> Date: Wed, 17 Nov 2004 19:17:19 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com, sip@ietf.org Subject: Re: [Sip] Comments on Resource-priority-05 References: <1ea.2fbc8541.2ecc624e@aol.com> In-Reply-To: <1ea.2fbc8541.2ecc624e@aol.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Content-Transfer-Encoding: 7bit Mpierce1@aol.com wrote: > Based on the contents of previous versions of this draft, and comments > I and others have made, I believe that the following are essential for > the next version of this draft. > > The only normative information included per namespace should be: > > - name of the namespace > - names of the priority levels > - order of the priority values > - default priority level (may be used if the receiving end does not > recognize a valid priority value) > > While the draft could detail various procedures which might be > applied, such as "modes", it should not associate any specific > procedure with any specific namespace. > > There should not be any other normative, mandatory behavior associated > with the use of the Resoure-priority header, such as specific > authorization procedures. > > In general, the draft can be made much shorter by deletion of > irrelevant material. For example, Section 7 describes procedures for > "move to the head of the line" scenarios for processing of messages in > SIP servers or UAs. It has been proposed in > draft-pierce-tsvwg-pref-treat-examples since April 2002 (and never > commented on) that there is no need to do such a thing. In fact, it is > not a good idea to intentionally change the order of messages.. > This is a useful start. I believe we agree that there may be some content in -05 that is not required for publication. Let, me, however, assert requirements for publishing a standards-track SIP extension. These are the kind of things that I expect any such document to meet, above the obvious "must have boilerplate, IANA considerations" and so on. 1) The document must contain, or contain references to, all information that a reasonable developer would need to build an interoperable implementation of the specification. Any referenced specifications must be publicly accessible, under the IETF's general guidelines for such. Examples might include documents from ITU, IEEE, W3C, ANSI, ETSI, and similar public specification authorities. 2) The SIP behavior of the extension and how it influences SIP dialog states, transaction results, etc. must be fully documented within the specification. 3) A system built using the specification can be analyzed and debugged using the non-SIP parts as a "black box". That is, the impact of the non-SIP functions must be apparent at the SIP level. If a request is rejected because of an extension, I want to know which extension, and by whom. 4) The threat model for attacks on this extension is clearly elucidated, and that the usage of available SIP mechanisms such as authentication, identity representation,SIPS, S/MIME, etc. is demonstrated in the text as adequate to mitigate those threats or that additional mechanisms are detailed within the text as needed to mitigate those threats. 5) The requirements for any "extension of the extension" must be clearly spelled out. Now, let's apply that to what has to be in this draft. If the presence of header FOO in a request can cause that request or any other extant request, transaction, or dialog to be treated differently by ANY SIP element, including the terminating and originating UA, then the related SIP messaging must be explicitly detailed. For example, if a resource-priority header field in one request causes another dialog to be preempted, I want to know what SIP messaging is sent to the participant(s) in the terminated dialog. (Example: BYE, with a Reason header, and which specific reason?) If the lack of a resource-priority header field (or a low-value priority) in a request causes that request to be rejected, I want to know what SIP messaging is sent in the rejection. If a request is carrying a resource-priority header field or value that it is not authorized to use, and that causes the request to be rejected, diverted, or otherwise treated differently, I want to know what SIP messaging is sent back indicating the special handling. I do not care WHAT the priority order is in a namespace that is externally documented, as long as that external document defines the priority ordering in a manner sufficient for a SIP implementor to build an interoperable implementation, or for an administrator to be able to determine whether observed system behavior is correct. I do not care what the relative priority between namespaces in a particular node is, as long as there is some way to indicate which namespace held priority in any SIP messaging resulting from a priority comparison. I do care if attackers can, by simply inserting this new header, cause preemption or rejection of other calls. If this is a possible threat, I want it analyzed, and I want to have an explanation of how this relates to the security model and how applications of our security tools can keep this from happening. I do care that fallbacks to "normal" behavior be documented, and that such issues as "What happens when a priority-aware element doesn't recognize a namespace" are properly explained. I do care that the requirements for registering additional namespaces are clearly spelled out, and that it indicates that such namespaces must be defined by a referenceable specification, and that any registration of additional namespaces must include thorough documentation of any new SIP behavior induced by the new namespace. To me, that means a new namespace registration will need at least an informational track RFC, with expert review to make sure it meets these requirements. Obviously, it also requires that any namespaces registered IN THIS DOCUMENT be documented in adequate fashion so as to serve as guides for the documentation of any namespaces to be registered in the future. My position is that we WILL NOT publish a standards-track SIP specification that simply defines a new header and defines a series of namespaces and possible values without explaining the effect on SIP of the presence of that a header, namespace, and values. We wouldn't even publish a non-standard P-header with this level of guidance, and we expect much more from a standards-track document. -- Dean Willis SIP co-chair _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 17 21:14:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17241 for ; Wed, 17 Nov 2004 21:14:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUbrK-0004T4-3t for sip-web-archive@ietf.org; Wed, 17 Nov 2004 21:17:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUbnD-0000JU-PR; Wed, 17 Nov 2004 21:13:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUbl3-0007X0-Dr for sip@megatron.ietf.org; Wed, 17 Nov 2004 21:10:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16965 for ; Wed, 17 Nov 2004 21:10:47 -0500 (EST) Received: from ckmso2.att.com ([209.219.209.75] helo=ckmso2.proxy.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUbnW-0004NU-Mh for sip@ietf.org; Wed, 17 Nov 2004 21:13:26 -0500 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by ckmso2.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id iAI292Ph025712 for ; Wed, 17 Nov 2004 21:10:14 -0500 Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.13) by attrh5i.attrh.att.com (7.1.006) id 4172986300646FA3; Wed, 17 Nov 2004 21:10:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Comments on Resource-priority-05 Date: Wed, 17 Nov 2004 20:10:13 -0600 Message-ID: <28F05913385EAC43AF019413F674A0170A4128D4@OCCLUST04EVS1.ugd.att.com> Thread-Topic: [Sip] Comments on Resource-priority-05 Thread-Index: AcTNDge11JLF3TVRSUOBk5zs3X7DkgABVUUQ From: "Dolly, Martin C, ALABS" To: "Dean Willis" , , X-Spam-Score: 0.2 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Content-Transfer-Encoding: quoted-printable X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Content-Transfer-Encoding: quoted-printable Dean, The SIP behavior needs to be defined in this draft. A SIP stack = developer should be able to read this draft and understand the desired = SIP behavior, without knowledge of the application processing. Cheers, Martin -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of Dean Willis Sent: Wednesday, November 17, 2004 8:17 PM To: Mpierce1@aol.com; sip@ietf.org Subject: Re: [Sip] Comments on Resource-priority-05 Mpierce1@aol.com wrote: > Based on the contents of previous versions of this draft, and comments = > I and others have made, I believe that the following are essential for = > the next version of this draft. > > The only normative information included per namespace should be: > > - name of the namespace > - names of the priority levels > - order of the priority values > - default priority level (may be used if the receiving end does not=20 > recognize a valid priority value) > > While the draft could detail various procedures which might be=20 > applied, such as "modes", it should not associate any specific=20 > procedure with any specific namespace. > > There should not be any other normative, mandatory behavior associated = > with the use of the Resoure-priority header, such as specific=20 > authorization procedures. > > In general, the draft can be made much shorter by deletion of=20 > irrelevant material. For example, Section 7 describes procedures for=20 > "move to the head of the line" scenarios for processing of messages in = > SIP servers or UAs. It has been proposed in=20 > draft-pierce-tsvwg-pref-treat-examples since April 2002 (and never=20 > commented on) that there is no need to do such a thing. In fact, it is = > not a good idea to intentionally change the order of messages.. > This is a useful start. I believe we agree that there may be some=20 content in -05 that is not required for publication. Let, me, however, assert requirements for publishing a standards-track=20 SIP extension. These are the kind of things that I expect any such=20 document to meet, above the obvious "must have boilerplate, IANA=20 considerations" and so on. 1) The document must contain, or contain references to, all information=20 that a reasonable developer would need to build an interoperable=20 implementation of the specification. Any referenced specifications must=20 be publicly accessible, under the IETF's general guidelines for such.=20 Examples might include documents from ITU, IEEE, W3C, ANSI, ETSI, and=20 similar public specification authorities. 2) The SIP behavior of the extension and how it influences SIP dialog=20 states, transaction results, etc. must be fully documented within the=20 specification. 3) A system built using the specification can be analyzed and debugged=20 using the non-SIP parts as a "black box". That is, the impact of the=20 non-SIP functions must be apparent at the SIP level. If a request is=20 rejected because of an extension, I want to know which extension, and by = whom. 4) The threat model for attacks on this extension is clearly elucidated, = and that the usage of available SIP mechanisms such as authentication,=20 identity representation,SIPS, S/MIME, etc. is demonstrated in the text=20 as adequate to mitigate those threats or that additional mechanisms are = detailed within the text as needed to mitigate those threats. 5) The requirements for any "extension of the extension" must be clearly = spelled out. Now, let's apply that to what has to be in this draft. If the presence of header FOO in a request can cause that request or any = other extant request, transaction, or dialog to be treated differently=20 by ANY SIP element, including the terminating and originating UA, then=20 the related SIP messaging must be explicitly detailed. For example, if a resource-priority header field in one request causes=20 another dialog to be preempted, I want to know what SIP messaging is=20 sent to the participant(s) in the terminated dialog. (Example: BYE, with = a Reason header, and which specific reason?) If the lack of a=20 resource-priority header field (or a low-value priority) in a request=20 causes that request to be rejected, I want to know what SIP messaging is = sent in the rejection. If a request is carrying a resource-priority=20 header field or value that it is not authorized to use, and that causes=20 the request to be rejected, diverted, or otherwise treated differently,=20 I want to know what SIP messaging is sent back indicating the special=20 handling. I do not care WHAT the priority order is in a namespace that is=20 externally documented, as long as that external document defines the=20 priority ordering in a manner sufficient for a SIP implementor to build=20 an interoperable implementation, or for an administrator to be able to=20 determine whether observed system behavior is correct. I do not care what the relative priority between namespaces in a=20 particular node is, as long as there is some way to indicate which=20 namespace held priority in any SIP messaging resulting from a priority=20 comparison. I do care if attackers can, by simply inserting this new header, cause=20 preemption or rejection of other calls. If this is a possible threat, I=20 want it analyzed, and I want to have an explanation of how this relates=20 to the security model and how applications of our security tools can=20 keep this from happening. I do care that fallbacks to "normal" behavior be documented, and that=20 such issues as "What happens when a priority-aware element doesn't=20 recognize a namespace" are properly explained. I do care that the requirements for registering additional namespaces=20 are clearly spelled out, and that it indicates that such namespaces must = be defined by a referenceable specification, and that any registration=20 of additional namespaces must include thorough documentation of any new=20 SIP behavior induced by the new namespace. To me, that means a new=20 namespace registration will need at least an informational track RFC,=20 with expert review to make sure it meets these requirements. Obviously,=20 it also requires that any namespaces registered IN THIS DOCUMENT be=20 documented in adequate fashion so as to serve as guides for the=20 documentation of any namespaces to be registered in the future. My position is that we WILL NOT publish a standards-track SIP=20 specification that simply defines a new header and defines a series of=20 namespaces and possible values without explaining the effect on SIP of=20 the presence of that a header, namespace, and values. We wouldn't even=20 publish a non-standard P-header with this level of guidance, and we=20 expect much more from a standards-track document. -- Dean Willis SIP co-chair _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 17 21:34:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18688 for ; Wed, 17 Nov 2004 21:34:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUcAd-0004qo-Ja for sip-web-archive@ietf.org; Wed, 17 Nov 2004 21:37:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUc76-0004L1-Gm; Wed, 17 Nov 2004 21:33:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUc4c-0003jF-L4 for sip@megatron.ietf.org; Wed, 17 Nov 2004 21:31:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18462 for ; Wed, 17 Nov 2004 21:31:00 -0500 (EST) Received: from imo-d02.mx.aol.com ([205.188.157.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUc79-0004ly-7a for sip@ietf.org; Wed, 17 Nov 2004 21:33:39 -0500 Received: from bertculpepper@netscape.net by imo-d02.mx.aol.com (mail_out_v37_r3.8.) id l.e9.f61b2ac (22681); Wed, 17 Nov 2004 21:30:26 -0500 (EST) Received: from [192.168.0.3] (48.144.8.67.cfl.rr.com [67.8.144.48]) by air-in04.mx.aol.com (v103.7) with ESMTP id MAILININ42-5899419c093f13e; Wed, 17 Nov 2004 21:30:25 -0500 Message-ID: <419C0973.9020609@netscape.net> Date: Wed, 17 Nov 2004 21:31:15 -0500 From: Bert Culpepper User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org, Jonathan Rosenberg Subject: Re: [Sip] WGLC for App Interact References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 67.8.144.48 X-Mailer: Unknown (No Version) X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit The last paragraph in section 4.3 discusses what I believe is an approach where a client-remote interface is used to provide context and a client-local interface (KPML) is used to receive input for applications that where some prolonged dialog is needed. The last sentence leads me to this conclusion. But unlike the beginning of the section says, it implies that KPML is inappropriate for applications that need to play a voice prompt and collect a response. Clearly, the approach described in this section is appropriate for a pre-paid application, but this last paragraph seems to contradict this. Some text needs to be added that this paragraph is discussing using the model for applications that require prolonged (say more than one prompt-collect sequence) dialog with the user. Section 9.1 has the following statement in the last paragraph. In the case of KPML, key events are passed to remote user interfaces by encoding them in RFC 2833 [17]. I can't figure out if this is a typo or statement that RFC 2833 is to be used when a user presses a key on their keypad when application focus is a question. For one thing, it may be that the DTMF tones themselves should be present in the media stream, and not just encoded using RFC 2833 for some scenarios. (This would be negotiated using SDP.) Or, if this is a typo, KPML is a markup language that is not based on RFC 2833. I recommend adding "for example" to the end of the sentence or re-wording it to accurately describe how KPML works. Best regards, Bert _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 17 23:53:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27934 for ; Wed, 17 Nov 2004 23:53:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUeKs-0007Tl-Lb for sip-web-archive@ietf.org; Wed, 17 Nov 2004 23:55:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUeGU-0000yQ-9V; Wed, 17 Nov 2004 23:51:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUeBs-0008Nh-Kb for sip@megatron.ietf.org; Wed, 17 Nov 2004 23:46:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27443 for ; Wed, 17 Nov 2004 23:46:37 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUeEP-0007Jz-Gm for sip@ietf.org; Wed, 17 Nov 2004 23:49:18 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 17 Nov 2004 20:48:16 -0800 Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iAI4jvw0001344; Wed, 17 Nov 2004 20:45:57 -0800 (PST) Received: from [192.168.1.100] (sjc-vpn4-1183.cisco.com [10.21.84.158]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFV04222; Wed, 17 Nov 2004 20:46:03 -0800 (PST) Message-ID: <419C290B.2090901@cisco.com> Date: Wed, 17 Nov 2004 23:46:03 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Langstaff Subject: Re: [Sip] PING/PONG References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Christian Stredicke X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit There isn't a UAS involved here; these requests go from the client (UAC) to its proxy. How the proxy indicates to the UAC that it is capable of processing these keepalives is a good question. My first thought is that this would be something in DNS; a new service in the NAPTR record for indicating the sip+stun combination. -Jonathan R. Steve Langstaff wrote: > Should point 2 read "The user agent server indicates if it can respond to client refresh requests"? > > -- > Steve Langstaff. > > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > Jonathan Rosenberg > Sent: 17 November 2004 16:40 > To: Christian Stredicke > Cc: sip@ietf.org > Subject: Re: [Sip] PING/PONG > > > > > Christian Stredicke wrote: > > >>So my understanding is: >> >>1. We should use *only* STUN for refreshing bindings (either UDP or TCP, >>what about TLS) > > > Yes, TLS too. TLS runs ontop of TCP after all. > > >>2. The user agent indicates if it can do it (no negotiation on >>capabilities) >> >>3. Refreshing must be done from the client >> >>Can we agree on that? > > > Yes. > > Server originating refreshing is in the wrong direction. It is the > client utilizing the service; if it wishes to make use of that service, > it has to be responsible for refreshing the connection. > > -Jonathan R. > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 18 00:51:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01850 for ; Thu, 18 Nov 2004 00:51:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUfEo-0000C7-98 for sip-web-archive@ietf.org; Thu, 18 Nov 2004 00:53:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUfAk-0005ll-6Z; Thu, 18 Nov 2004 00:49:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUf6M-0004Wd-CE for sip@megatron.ietf.org; Thu, 18 Nov 2004 00:45:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01459 for ; Thu, 18 Nov 2004 00:44:59 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUf8t-0008WS-3W for sip@ietf.org; Thu, 18 Nov 2004 00:47:41 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 17 Nov 2004 22:35:43 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iAI5V1PJ020942; Wed, 17 Nov 2004 21:31:01 -0800 (PST) Received: from [192.168.1.100] (sjc-vpn4-1183.cisco.com [10.21.84.158]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFV05462; Wed, 17 Nov 2004 21:31:00 -0800 (PST) Message-ID: <419C3395.8070502@cisco.com> Date: Thu, 18 Nov 2004 00:31:01 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Orit Levin Subject: Re: [Sip] RFC 3261: BUG or clarification is needed References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Content-Transfer-Encoding: 7bit I agree with Paul here. -Jonathan R. Orit Levin wrote: > Paul, > Thanks! > As long as it is accepted by everyone - it definitely works for me. > More inline. > > Orit. > > >>-----Original Message----- >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: Wednesday, November 17, 2004 2:49 PM >>To: Orit Levin >>Cc: sip@ietf.org >>Subject: Re: [Sip] RFC 3261: BUG or clarification is needed >> >> >> >>Orit Levin wrote: >> >>>Guys, >>>I would like to get a clarification on the properties of >> >>the Contact >> >>>header in requests and responses different from REGISTER. >>>Is there a common understanding, that a Contact header can >> >>contain any >> >>>valid SIP URI that, especially when used outside the >> >>original dialog, >> >>>needs to be resolved according to RFC 3263 (i.e. including >> >>the SRV lookup) ? >> >>Yes. > > Great. > >>>I couldn't find any statement along these lines in any of >> >>the relevant RFCs. >> >>Why would any special statement be required? The address in >>the contact gets included in some message, and then the rules >>for how to resolve it are spelled out. It doesn't matter >>where it came from. > > Because I am not sure at all that many implementations actually do it > today and we need to encourage them to do so. > >>>For example, in Redirect requests, we are reusing the >> >>Contact header >> >>>in order to point to an alternative destination which can >> >>have nothing >> >>>in common with the original domain. >> >>BTW, in some contexts (such as 3xx) the contact addresses >>need not even be ones used by sip. You are allowed to >>redirect to an http uri if you like. > > Yes, I know :-) > >>>Yet another example, the current GRUU draft is silent about the >>>ability of resolving GRUU using RFC 3263 procedures. >From >> >>the draft: >> >>>"the GRUU MUST exhibit the following properties: >>> >>> o The domain part of the URI is an IP address present on the >>>public >>> >>> Internet, or, if it is a host name, exists in the >> >>global DNS and >> >>> corresponds to an IP address present on the public Internet." >>> >>> >>>For the interoperability sake, I believe that it is very >> >>important to >> >>>file this clarification against RFC 3261 and also point to RFC 3263 >>>for GRUU properties/location procedures. >> >>I think this requirement is implicit. > > Yes, most probably, but since this case is left out from the section > above - the reader can be mislead by the current text. > >> Paul >> >> >>>Thanks, >>>Orit. >>> >>> >>> >> >>---------------------------------------------------------------------- >> >>>-- >>> >>>_______________________________________________ >>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>This list is for NEW development of the core SIP 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 Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 18 02:13:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18232 for ; Thu, 18 Nov 2004 02:13:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUgWQ-0001nS-MM for sip-web-archive@ietf.org; Thu, 18 Nov 2004 02:16:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUgMy-0000eO-KN; Thu, 18 Nov 2004 02:06:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUgLe-0008PR-W5 for sip@megatron.ietf.org; Thu, 18 Nov 2004 02:04:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11422 for ; Thu, 18 Nov 2004 02:04:53 -0500 (EST) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUgOE-0001e0-1G for sip@ietf.org; Thu, 18 Nov 2004 02:07:34 -0500 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id iAI74Mxg008152; Thu, 18 Nov 2004 07:04:22 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Thu, 18 Nov 2004 02:04:21 -0500 Message-ID: <24EAE5D4448B9D4592C6D234CBEBD59708994C@stntexch03.cis.neustar.com> From: "Peterson, Jon" To: "'Jonathan Rosenberg'" Subject: RE: third alternative (was RE: [Sip] RE: Identity after reinvite) Date: Thu, 18 Nov 2004 02:04:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: "'Cullen Jennings'" , "'sip@ietf.org'" , "'Paul H Kyzivat'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d > > 3) Change nothing in To/From. Requests in the backwards direction in a > > dialog may go through the authentication service of the domain indicated in > > the host portion of the From header of the request. If that is not possible, > > do not supply request identity for such messages. > > This is pretty close to what I had just suggested in a mail I wrote a > few minutes ago. I should have read the whole thread before responding I > suppose ;) I'm glad we're on the same page (or at least the same chapter), but from the remainder below, it sounds like we're on the same page for very different reasons. > The difference between this and what I had proposed is that I think a UA > should be *allowed* to change the From in its outbound request. Well, we can't stop the callee UA from changing the From header field value in its backwards-direction requests, yes, but I certainly think that the caller UA should discard such requests. For me, this comes down to a very, very simple case: Alice sends a call to Bob, and then in the middle of the call, she gets a BYE request from Edgar. Does Alice accept the BYE or not? This is perhaps the simplest authorization decision we could ask a client to make, and what I keep hearing people say is that it's okay if the BYE comes from Edgar instead of Bob. I'm really not sure how this could possibly be okay - this is unrelated to whether SIPS is used or any other transitive security is used (see the end of this message); this is the fundamental question of who should be authorized to terminate a call. If that set of authorized parties isn't identical to the first and second parties in the call, then I think we're creating a non-deterministic security environment. Are we really going to tell end users of SIP that it's okay if such a BYE comes from an Edgar? What do I not understand here? > > In cases where the user contacted > > at chicago does not possess credentials to authenticate themselves to > > biloxi, I think it would be fair to say that requests in the backwards > > direction should not get an Identity header. > > I think that it will almost never have such credentials. If it did, this > wouldn't be retargeting. Again, there's something fundamental I don't understand here, then. Alice sends a request to Bob. For some reason, Bob's domain thinks it is appropriate to forward the request to, say, Carol. Why does Bob's domain think that? Because someone, with some relevant permissions, provisioned Bob's domain with a directive that requests for Bob should be forwarded to Carol. Of course, Carol personally does not possess Bob's credentials. If Bob is at Carol's station, though, then Bob will possess Bob's credentials. If the request arrives at Carol's station, and Bob fields the request, then Bob will be capable of providing his credentials to any auth service as necessary. Carol will not. If the user at Carol's station possesses Bob's credentials, then it is reasonable for requests in the backwards direction to receive bear an Identity header stating that this is from Bob; if not, then there shouldn't be an Identity header in the request. This seems very intuitive to me; I'm not sure why this is so radically implausible. I guess this begs the question of why retargeting happens at all; if retargeting happens for some other reason than what I describe above, then it most likely violates RFC3261 as I understand it. > > I've gotten a > > lot of feedback (from Paul, Kumiko and others) that we should try to weaken > > the requirement for direct TLS, and I intend to add some text to the next > > version about some specific ways in which it is still acceptable to provide > > identity even if a direct TLS connection cannot be formed. Certain forms of > > weakness there could be beneficial to this approach. > > I think that having non-direct connections is a reasonable thing; > generally my view has been that it should be possible to disaggregate a > monolithic proxy into components in the same network, each of which is a > SIP proxy performing parts of the overall processing in a domain. As > long as appropriate security and trust relationships are maintained > between these component proxies in a domain, I think equivalent security > is afforded. I'm largely sympathetic to this argument, yes, and thus I agree that the text should be amended. What I think should replace the strong requirement for TLS is something to the effect that the UA must have an association with an auth service that has a certain set of qualities - qualities that would be satisfied by a direct TLS connection, but which hypothetically might be derived through some other means. > As a follow up to my previous note, I tihnk part of the difficulty here > is a difference in view about the problem being solved by asserted > identities in the reverse direction. In my view, the sips mechanism > provides an assurance ot the caller that the call got to the eventual > target as a result of authorized forwarding at each hop along the way. The sufficiency of SIPS for this purpose must depend on the practical efficacy of the mechanism, not its theoretically efficacy. My own reservations about the hops beyond the target administrative domain of a SIPS request, coupled with Dean's valid concern that SIPS is not verifiable by the endpoints, cast considerable doubt on the assurance that SIPS provides. SIPS provides no assurance to the caller whatsoever - SIPS is merely heaved over the wall at the network, and the caller can only hope that the directive is obeyed. Even if the SIPS directive is strictly obeyed by all intermediaries, given the laxity surrouding last-hop delivery, potentials for eavesdropping arise. Eavesdropping alone is sufficient for an attacker to construct a forged BYE request with a valid Identity header. That much said, I do think there would be some value in having an identity mechanism that prevents trivial initial-request impersonation without addressing eavesdropping. But if we so reduce the scope, that would argue for a fourth alternative: something like "in the context of a dialog, request identity is only used for the dialog-forming request". Identity isn't adding any appreciable value to any subsequent requests. > Thus, the identity of requests in the reverse direction is not used to > *authorize* whether or not the request should be processed. Rather, it > serves merely as a reliable identification mechanism, as authorization > is provided by sips. If you trust SIPS far enough to authorize backwards-direction requests and responses reliably, then surely Identity would be superfluous. What additional properties would Identity convey beyond those that can be assumed from SIPS? This may be the crux of our disagreement. I don't believe that SIPS is strong enough to substantiate an authorization decision on the part of the caller. Moreover, I'd like to believe that sip-identity can be used in the absence of SIPS; that is, I don't think that every potential callee must publish a SIPS URI in order for a caller to make reasonable authorization decisions the source of requests in the backwards direction in a dialog. In the long term, when we want to provide a mandatory-to-implement mechanism for ascertaining identity, I don't think this can require SIPS as it is written now, anyway. The authorization decision made by the caller should be based on a cryptographic end-to-end assertion stating that the intended domain vouches for the callee; it should not merely be inferred from a speculation that a directive like SIPS was universally obeyed by an unfathomable set of unknown intermediaries. In summary, this is the ultimate distinction between the "trusted networks" of RFC3325 and the aptly-named "long term cryptographic identity solution" we envisioned years ago. If something like SIPS is genuinely sufficient, then I'd argue that P-Asserted-Identity provided by the first-hop proxy in the request path would be all we'd need, regardless of whether we're talking about dialog-forming requests or requests in the backwards direction in a dialog. Jon Peterson NeuStar, Inc. > -JOnathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 18 02:53:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26549 for ; Thu, 18 Nov 2004 02:53:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUh9U-0002aL-J5 for sip-web-archive@ietf.org; Thu, 18 Nov 2004 02:56:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUh2y-0000yx-Q8; Thu, 18 Nov 2004 02:49:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUh0J-0000MN-9p for sip@megatron.ietf.org; Thu, 18 Nov 2004 02:46:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26009 for ; Thu, 18 Nov 2004 02:46:53 -0500 (EST) Received: from [203.129.224.106] (helo=kr.aftek.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUh2q-0002Rq-FO for sip@ietf.org; Thu, 18 Nov 2004 02:49:35 -0500 Received: from vikram ([10.0.0.145]) by kr.aftek.com (8.11.6/8.11.6) with SMTP id iAI7kdB16176 for ; Thu, 18 Nov 2004 13:16:41 +0530 Message-ID: <01d101c4cd43$f3f2e020$9100000a@vikram> From: "vikram bhuskute" To: Date: Thu, 18 Nov 2004 13:25:18 +0530 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.5 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Subject: [Sip] What if 200 Ok response on Hold-Invite is late X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0551833697==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 This is a multi-part message in MIME format. --===============0551833697== Content-Type: multipart/alternative; boundary="----=_NextPart_000_01CC_01C4CD72.0C3E45B0" This is a multi-part message in MIME format. ------=_NextPart_000_01CC_01C4CD72.0C3E45B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, If dialogue is established between user A and B. and if C = calls then the call between A & B should be put on hold( If multiple active = call is not suppported) Now should A wait for a 200 OK response(for hold-reinvite) from B(whcih = could be late because=20 of n/w problem) or It can assume that Call is on hold and he can = staighaway accept the other call ? =20 I think as soon as I send Hold on invite , I can assume that call is = put on Hold and i can do furhter processing based on this assumption ? Am i right ? regards Vikram Bhuskute ------=_NextPart_000_01CC_01C4CD72.0C3E45B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
          &nbs= p;  =20 If dialogue is established between user A and B. and if C=20 calls
 then the call between A & B = should be put=20 on hold( If multiple active call is not suppported)
 
 Now should A wait for a 200 OK = response(for=20 hold-reinvite) from B(whcih could be late because
 of n/w problem)  = or It can assume that Call is on hold and he can staighaway accept the other call = ?
 
 I think as soon as I send Hold on = invite , I=20 can assume that call is put on Hold and i can do
 furhter processing based on this = assumption ?=20 Am i right ?
 
regards
 
Vikram = Bhuskute
------=_NextPart_000_01CC_01C4CD72.0C3E45B0-- --===============0551833697== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0551833697==-- From sip-bounces@ietf.org Thu Nov 18 02:59:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27239 for ; Thu, 18 Nov 2004 02:59:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUhEf-0002jn-RY for sip-web-archive@ietf.org; Thu, 18 Nov 2004 03:01:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUh3C-0000zw-Ij; Thu, 18 Nov 2004 02:49:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUh1F-0000Us-5y for sip@megatron.ietf.org; Thu, 18 Nov 2004 02:47:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26105 for ; Thu, 18 Nov 2004 02:47:51 -0500 (EST) Received: from [67.15.60.3] (helo=mail.aftek.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUh3n-0002U3-Sv for sip@ietf.org; Thu, 18 Nov 2004 02:50:33 -0500 Received: (qmail 20686 invoked by uid 510); 18 Nov 2004 00:55:16 -0600 Received: from vikramb@aftek.com by plain.ev1servers.net by uid 508 with qmail-scanner-1.22-st-qms (clamdscan: 0.75.1. spamassassin: 2.63. Clear:RC:0(203.129.224.106):SA:0(-104.8/3.0):. Processed in 217.347938 secs); 18 Nov 2004 06:55:16 -0000 X-Spam-Status: No, hits=-104.8 required=3.0 X-Antivirus-MYDOMAIN-Mail-From: vikramb@aftek.com via plain.ev1servers.net X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:0(203.129.224.106):SA:0(-104.8/3.0):. Processed in 217.347938 secs Process 20267) Received: from unknown (HELO vikram) (vikramb@aftek.com@203.129.224.106) by mail.aftek.com with SMTP; 18 Nov 2004 00:51:38 -0600 Message-ID: <019c01c4cd43$97437560$9100000a@vikram> From: "vikram bhuskute" To: Date: Thu, 18 Nov 2004 13:22:35 +0530 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.5 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Subject: [Sip] What if 200 Ok response on Hold-Invite is late X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0114679315==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 This is a multi-part message in MIME format. --===============0114679315== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0197_01C4CD71.AAF04C90" This is a multi-part message in MIME format. ------=_NextPart_000_0197_01C4CD71.AAF04C90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, If dialogue is established between user A and B. and if C = calls then the call between A & B should be put on hold( If multiple active = call is not suppported) =20 Now should A wait for a 200 OK response(for hold-reinvite) from B(whcih = could be late because=20 of n/w problem) or It can assume that Call is on hold and he can = staighaway accept the other call ? =20 I think as soon as I send Hold on invite , I can assume that call is = put on Hold and i can do furhter processing based on this assumption ? Am i right ? regards Vikram Bhuskute ------=_NextPart_000_0197_01C4CD71.AAF04C90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
          &nbs= p;  =20 If dialogue is established between user A and B. and if C=20 calls
 then the call between A & B = should be put=20 on hold( If multiple active call is not suppported)
 
 Now should A wait for a 200 OK = response(for=20 hold-reinvite) from B(whcih could be late because
 of n/w problem)  = or It can assume that Call is on hold and he can staighaway accept the other call = ?
 
 I think as soon as I send Hold on = invite , I=20 can assume that call is put on Hold and i can do
 furhter processing based on this = assumption ?=20 Am i right ?
 
regards
 
Vikram = Bhuskute
------=_NextPart_000_0197_01C4CD71.AAF04C90-- --===============0114679315== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0114679315==-- From sip-bounces@ietf.org Thu Nov 18 03:00:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27411 for ; Thu, 18 Nov 2004 03:00:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUhG7-0002nJ-AU for sip-web-archive@ietf.org; Thu, 18 Nov 2004 03:03:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUh6L-0001gU-Ch; Thu, 18 Nov 2004 02:53:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUh2x-0000yn-Js for sip@megatron.ietf.org; Thu, 18 Nov 2004 02:49:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26197 for ; Thu, 18 Nov 2004 02:49:37 -0500 (EST) Received: from [67.15.60.3] (helo=mail.aftek.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUh5X-0002VQ-Bg for sip@ietf.org; Thu, 18 Nov 2004 02:52:19 -0500 Received: (qmail 20859 invoked by uid 510); 18 Nov 2004 00:56:58 -0600 Received: from vikramb@aftek.com by plain.ev1servers.net by uid 508 with qmail-scanner-1.22-st-qms (clamdscan: 0.75.1. spamassassin: 2.63. Clear:RC:0(203.129.224.106):SA:0(-104.8/3.0):. Processed in 235.888367 secs); 18 Nov 2004 06:56:58 -0000 X-Spam-Status: No, hits=-104.8 required=3.0 X-Antivirus-MYDOMAIN-Mail-From: vikramb@aftek.com via plain.ev1servers.net X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:0(203.129.224.106):SA:0(-104.8/3.0):. Processed in 235.888367 secs Process 20443) Received: from unknown (HELO vikram) (vikramb@aftek.com@203.129.224.106) by mail.aftek.com with SMTP; 18 Nov 2004 00:53:01 -0600 Message-ID: <01b001c4cd43$c88c7e50$9100000a@vikram> From: "vikram bhuskute" To: Date: Thu, 18 Nov 2004 13:22:35 +0530 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.5 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Subject: [Sip] What if 200 Ok response on Hold-Invite is late X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1640857693==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 This is a multi-part message in MIME format. --===============1640857693== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0197_01C4CD71.AAF04C90" This is a multi-part message in MIME format. ------=_NextPart_000_0197_01C4CD71.AAF04C90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, If dialogue is established between user A and B. and if C = calls then the call between A & B should be put on hold( If multiple active = call is not suppported) =20 Now should A wait for a 200 OK response(for hold-reinvite) from B(whcih = could be late because=20 of n/w problem) or It can assume that Call is on hold and he can = staighaway accept the other call ? =20 I think as soon as I send Hold on invite , I can assume that call is = put on Hold and i can do furhter processing based on this assumption ? Am i right ? regards Vikram Bhuskute ------=_NextPart_000_0197_01C4CD71.AAF04C90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
          &nbs= p;  =20 If dialogue is established between user A and B. and if C=20 calls
 then the call between A & B = should be put=20 on hold( If multiple active call is not suppported)
 
 Now should A wait for a 200 OK = response(for=20 hold-reinvite) from B(whcih could be late because
 of n/w problem)  = or It can assume that Call is on hold and he can staighaway accept the other call = ?
 
 I think as soon as I send Hold on = invite , I=20 can assume that call is put on Hold and i can do
 furhter processing based on this = assumption ?=20 Am i right ?
 
regards
 
Vikram = Bhuskute
------=_NextPart_000_0197_01C4CD71.AAF04C90-- --===============1640857693== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1640857693==-- From sip-bounces@ietf.org Thu Nov 18 06:39:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15653 for ; Thu, 18 Nov 2004 06:39:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUkfp-0007IW-U4 for sip-web-archive@ietf.org; Thu, 18 Nov 2004 06:42:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUkXR-0007JR-Cy; Thu, 18 Nov 2004 06:33:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUkWA-00076V-CC for sip@megatron.ietf.org; Thu, 18 Nov 2004 06:32:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15114 for ; Thu, 18 Nov 2004 06:31:59 -0500 (EST) From: Mpierce1@aol.com Received: from imo-m28.mx.aol.com ([64.12.137.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUkYm-0007AW-7A for sip@ietf.org; Thu, 18 Nov 2004 06:34:44 -0500 Received: from Mpierce1@aol.com by imo-m28.mx.aol.com (mail_out_v37_r3.8.) id c.45.1b7c1c6a (4410); Thu, 18 Nov 2004 06:31:15 -0500 (EST) Message-ID: <45.1b7c1c6a.2ecde203@aol.com> Date: Thu, 18 Nov 2004 06:31:15 EST Subject: Re: [Sip] -RP-05.txt: section 7.1 on priority-value interleaving To: jmpolk@cisco.com, jgunn6@csc.com MIME-Version: 1.0 X-Mailer: 6.0 for Windows XP sub 10500 X-Spam-Score: 0.3 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: An.Nguyen@ncs.gov, rohan@ekabal.com, scmorris@cisco.com, dean.willis@softarmor.com, sip@ietf.org, oran@cisco.com, pbabendr@cisco.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0571908988==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 --===============0571908988== Content-Type: multipart/alternative; boundary="part1_45.1b7c1c6a.2ecde203_boundary" --part1_45.1b7c1c6a.2ecde203_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 11/17/2004 11:26:59 PM W. Europe Standard Time, jmpolk@cisco.com writes: > Section 7.1 is merely to give examples to readers that show the order > within a namespace must be maintained regardless of how many other > namespaces exist (that are supported) by that SIP element. > > The section also provides examples of how the orders can be in multiple > combinations of groupings, as long as the overall order within each > namespace is not changed. > > The point in the first paragraph above is important, and needs to be made so by not including it in a section titled "multiple namespaces", since, as you said, it is true "regardless of how many other namespaces exist". Somewhere else in the document there should be a clear statement that the order of priority values within each individual namespace must be maintained. In fact, I believe that the actual requirement should be stated as follows: ----------------------- The order of priority values MUST be maintained. That is, if priority value "A" is specified as being higher than priority value "B" in the IANA registration, then an entity MUST NOT give traffic marked with value "A" a lower level of preferential treatment than traffic marked with priority value "B". An entity MUST NOT reorder the priority values. ----------------------- It needs to be stated this way, since it is permissible for an entity to give two levels the same treatment. For example, in the DSN, Flash and Flash Override may get the same treatment for packet transport at core routers while other entities may treat them different (endpoints or edge routers). The above requirement is too important to "hide" in a section about multiple namespaces. The second paragraph above, and the text that shows relationships between different namespaces remains confusing since there is a clear agreement that there is no relationship between namespaces. This text clearly implies that there is a relationship. If someything needs to be said to explain this to people, then let's work on text to address the problem. I believe that the current text will just further confuse others (not me). I'm not confused by it because I know the truth. Others won't. Mike Pierce --part1_45.1b7c1c6a.2ecde203_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message=20= dated 11/17/2004 11:26:59 PM W. Europe Standard Time, jmpolk@cisco.com write= s:


Section 7.1 is merely to gi= ve examples to readers that show the order=20
within a namespace must be maintained regardless of how many other=20
namespaces exist (that are supported) by that SIP element.

The section also provides examples of how the orders can be in multiple=20
combinations of groupings, as long as the overall order within each=20
namespace is not changed.




The point in the first paragraph above is important, and needs to be mad= e so by not including it in a section titled "multiple namespaces", since, a= s you said, it is true "regardless of how many other namespaces exist". Some= where else in the document there should be a clear statement that the order=20= of priority values within each individual namespace must be maintained. In f= act, I believe that the actual requirement should be stated as follows:

-----------------------
The order of priority values MUST be maintained. That is, if priority va= lue "A" is specified as being higher than priority value "B" in the IANA reg= istration, then an entity MUST NOT give traffic marked with value "A" a lowe= r level of preferential treatment than traffic marked with priority value "B= ". An entity MUST NOT reorder the priority values.
-----------------------

It needs to be stated this way, since it is permissible for an entity to= give two levels the same treatment. For example, in the DSN, Flash and Flas= h Override may get the same treatment for packet transport at core routers w= hile other entities may treat them different (endpoints or edge routers).

The above requirement is too important to "hide" in a section about mult= iple namespaces.

The second paragraph above, and the text that shows relationships betwee= n different namespaces remains confusing since there is a clear agreement th= at there is no relationship between namespaces. This text clearly implies th= at there is a relationship. If someything needs to be said to explain this t= o people, then let's work on text to address the problem. I believe that the= current text will just further confuse others (not me). I'm not confused by= it because I know the truth. Others won't.

Mike Pierce


--part1_45.1b7c1c6a.2ecde203_boundary-- --===============0571908988== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0571908988==-- From sip-bounces@ietf.org Thu Nov 18 06:46:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16186 for ; Thu, 18 Nov 2004 06:46:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUknD-0007Sk-Ix for sip-web-archive@ietf.org; Thu, 18 Nov 2004 06:49:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUkh7-0000ln-3V; Thu, 18 Nov 2004 06:43:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUkZX-0007lW-8l for sip@megatron.ietf.org; Thu, 18 Nov 2004 06:35:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15388 for ; Thu, 18 Nov 2004 06:35:28 -0500 (EST) Received: from firewall.citel.com ([62.190.107.60] helo=ivor.citel.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CUkc9-0007EU-1T for sip@ietf.org; Thu, 18 Nov 2004 06:38:13 -0500 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: [Sip] PING/PONG Date: Thu, 18 Nov 2004 11:14:42 -0000 Message-ID: Thread-Topic: [Sip] PING/PONG Thread-Index: AcTNKYWvD4vdewpKQSyep4WKbocUPgAM9r8w From: "Steve Langstaff" To: "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, Christian Stredicke X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: quoted-printable Sorry, I didn't realise the scope of this discussion was client-to-proxy = - that's where my confusion lay. A further question from my (simplistic) viewpoint... If this issue = is/could be generic to all STUNned traffic (not just sip+stun), would it = not be better to push the problem down into the STUN 'layer' and let the = STUN client and server sort out keeping the NAT bindings alive? I'm = guessing that the SIP client already 'knows' it has to use STUN to reach = the proxy, and so could ask it's STUN client to keep the binding(s) = alive as appropriate. -- Steve Langstaff. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] Sent: 18 November 2004 04:46 To: Steve Langstaff Cc: Christian Stredicke; sip@ietf.org Subject: Re: [Sip] PING/PONG There isn't a UAS involved here; these requests go from the client (UAC) = to its proxy. How the proxy indicates to the UAC that it is capable of processing=20 these keepalives is a good question. My first thought is that this would = be something in DNS; a new service in the NAPTR record for indicating=20 the sip+stun combination. -Jonathan R. Steve Langstaff wrote: > Should point 2 read "The user agent server indicates if it can respond = to client refresh requests"? >=20 > -- > Steve Langstaff. >=20 >=20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > Jonathan Rosenberg > Sent: 17 November 2004 16:40 > To: Christian Stredicke > Cc: sip@ietf.org > Subject: Re: [Sip] PING/PONG >=20 >=20 >=20 >=20 > Christian Stredicke wrote: >=20 >=20 >>So my understanding is: >> >>1. We should use *only* STUN for refreshing bindings (either UDP or = TCP, >>what about TLS) >=20 >=20 > Yes, TLS too. TLS runs ontop of TCP after all. >=20 >=20 >>2. The user agent indicates if it can do it (no negotiation on >>capabilities) >> >>3. Refreshing must be done from the client >> >>Can we agree on that? >=20 >=20 > Yes. >=20 > Server originating refreshing is in the wrong direction. It is the=20 > client utilizing the service; if it wishes to make use of that = service,=20 > it has to be responsible for refreshing the connection. >=20 > -Jonathan R. >=20 --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 18 11:19:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07542 for ; Thu, 18 Nov 2004 11:19:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUp2a-0004wK-3Z for sip-web-archive@ietf.org; Thu, 18 Nov 2004 11:21:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUotr-0006Hz-Mx; Thu, 18 Nov 2004 11:12:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUojO-0003qa-9K; Thu, 18 Nov 2004 11:01:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06321; Thu, 18 Nov 2004 11:01:53 -0500 (EST) Received: from amer-mta02.csc.com ([20.137.2.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUolz-0004YR-TS; Thu, 18 Nov 2004 11:04:40 -0500 Received: from csc.com (va-fch34.csc.com [20.6.39.227]) by amer-mta02.csc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id iAIG1kTu028403; Thu, 18 Nov 2004 11:01:50 -0500 (EST) Subject: Re: [Sip] Comments on Resource-priority-05 To: Dean Willis X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Janet P Gunn Date: Thu, 18 Nov 2004 11:01:44 -0500 X-MIMETrack: Serialize by Router on VA-FCH34/SRV/CSC(Release 6.0.3|September 26, 2003) at 11/18/2004 11:02:45 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.2 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: sip@ietf.org, sip-bounces@ietf.org, Mpierce1@aol.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Those sound like good guidelines to me. 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. ---------------------------------------------------------------------------------------- Dean Willis cc: Sent by: Subject: Re: [Sip] Comments on Resource-priority-05 sip-bounces 11/17/2004 08:17 PM Mpierce1@aol.com wrote: > Based on the contents of previous versions of this draft, and comments > I and others have made, I believe that the following are essential for > the next version of this draft. > > The only normative information included per namespace should be: > > - name of the namespace > - names of the priority levels > - order of the priority values > - default priority level (may be used if the receiving end does not > recognize a valid priority value) > > While the draft could detail various procedures which might be > applied, such as "modes", it should not associate any specific > procedure with any specific namespace. > > There should not be any other normative, mandatory behavior associated > with the use of the Resoure-priority header, such as specific > authorization procedures. > > In general, the draft can be made much shorter by deletion of > irrelevant material. For example, Section 7 describes procedures for > "move to the head of the line" scenarios for processing of messages in > SIP servers or UAs. It has been proposed in > draft-pierce-tsvwg-pref-treat-examples since April 2002 (and never > commented on) that there is no need to do such a thing. In fact, it is > not a good idea to intentionally change the order of messages.. > This is a useful start. I believe we agree that there may be some content in -05 that is not required for publication. Let, me, however, assert requirements for publishing a standards-track SIP extension. These are the kind of things that I expect any such document to meet, above the obvious "must have boilerplate, IANA considerations" and so on. 1) The document must contain, or contain references to, all information that a reasonable developer would need to build an interoperable implementation of the specification. Any referenced specifications must be publicly accessible, under the IETF's general guidelines for such. Examples might include documents from ITU, IEEE, W3C, ANSI, ETSI, and similar public specification authorities. 2) The SIP behavior of the extension and how it influences SIP dialog states, transaction results, etc. must be fully documented within the specification. 3) A system built using the specification can be analyzed and debugged using the non-SIP parts as a "black box". That is, the impact of the non-SIP functions must be apparent at the SIP level. If a request is rejected because of an extension, I want to know which extension, and by whom. 4) The threat model for attacks on this extension is clearly elucidated, and that the usage of available SIP mechanisms such as authentication, identity representation,SIPS, S/MIME, etc. is demonstrated in the text as adequate to mitigate those threats or that additional mechanisms are detailed within the text as needed to mitigate those threats. 5) The requirements for any "extension of the extension" must be clearly spelled out. Now, let's apply that to what has to be in this draft. If the presence of header FOO in a request can cause that request or any other extant request, transaction, or dialog to be treated differently by ANY SIP element, including the terminating and originating UA, then the related SIP messaging must be explicitly detailed. For example, if a resource-priority header field in one request causes another dialog to be preempted, I want to know what SIP messaging is sent to the participant(s) in the terminated dialog. (Example: BYE, with a Reason header, and which specific reason?) If the lack of a resource-priority header field (or a low-value priority) in a request causes that request to be rejected, I want to know what SIP messaging is sent in the rejection. If a request is carrying a resource-priority header field or value that it is not authorized to use, and that causes the request to be rejected, diverted, or otherwise treated differently, I want to know what SIP messaging is sent back indicating the special handling. I do not care WHAT the priority order is in a namespace that is externally documented, as long as that external document defines the priority ordering in a manner sufficient for a SIP implementor to build an interoperable implementation, or for an administrator to be able to determine whether observed system behavior is correct. I do not care what the relative priority between namespaces in a particular node is, as long as there is some way to indicate which namespace held priority in any SIP messaging resulting from a priority comparison. I do care if attackers can, by simply inserting this new header, cause preemption or rejection of other calls. If this is a possible threat, I want it analyzed, and I want to have an explanation of how this relates to the security model and how applications of our security tools can keep this from happening. I do care that fallbacks to "normal" behavior be documented, and that such issues as "What happens when a priority-aware element doesn't recognize a namespace" are properly explained. I do care that the requirements for registering additional namespaces are clearly spelled out, and that it indicates that such namespaces must be defined by a referenceable specification, and that any registration of additional namespaces must include thorough documentation of any new SIP behavior induced by the new namespace. To me, that means a new namespace registration will need at least an informational track RFC, with expert review to make sure it meets these requirements. Obviously, it also requires that any namespaces registered IN THIS DOCUMENT be documented in adequate fashion so as to serve as guides for the documentation of any namespaces to be registered in the future. My position is that we WILL NOT publish a standards-track SIP specification that simply defines a new header and defines a series of namespaces and possible values without explaining the effect on SIP of the presence of that a header, namespace, and values. We wouldn't even publish a non-standard P-header with this level of guidance, and we expect much more from a standards-track document. -- Dean Willis SIP co-chair _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 18 12:46:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15584 for ; Thu, 18 Nov 2004 12:46:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUqOy-00077h-NZ for sip-web-archive@ietf.org; Thu, 18 Nov 2004 12:49:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUq2h-0004CF-IB; Thu, 18 Nov 2004 12:25:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUpwL-0001bd-5f for sip@megatron.ietf.org; Thu, 18 Nov 2004 12:19:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13346 for ; Thu, 18 Nov 2004 12:19:23 -0500 (EST) Received: from mail.lumenvox.com ([206.169.193.45] helo=lv-svr.lumenvox.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUpz1-0006SD-8m for sip@ietf.org; Thu, 18 Nov 2004 12:22:11 -0500 Received: from PROGTHOMAS ([10.0.0.141]) by lv-svr.lumenvox.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 18 Nov 2004 09:15:52 -0800 From: "Thomas Gal" To: "'Patrick Mourot'" Subject: RE: [Sip] meeting minutes from SIP session 2 at IETF 61 Date: Thu, 18 Nov 2004 09:18:43 -0800 Organization: LumenVox LLC MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <1100794860.419ccbec9ab14@imp5-q.free.fr> Thread-Index: AcTNipirtpiktEy2Tk67i0GqwyxwMwAB/mWw Message-ID: X-OriginalArrivalTime: 18 Nov 2004 17:15:52.0500 (UTC) FILETIME=[41BC5F40:01C4CD92] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ThomasGal@LumenVox.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Now......sorry I named the file .doc.html for some reason. Tom > -----Original Message----- > From: Patrick Mourot [mailto:patrick.mourot@online.fr] > Sent: Thursday, November 18, 2004 8:21 AM > To: Thomas Gal > Subject: Re: [Sip] meeting minutes from SIP session 2 at IETF 61 > > Thomas, > > Do you know when ? > > Best Regards, > > Patrick > > Thomas Gal said the following on 11/11/04 11:40 pm: > > >The minutes will be at > http://natural.salk.edu/~tgal/ietf61/index.html shortly. > > > >Tom > > > > > > > >_______________________________________________ > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP Protocol Use > >sip-implementors@cs.columbia.edu for questions on current sip Use > >sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 18 13:58:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21850 for ; Thu, 18 Nov 2004 13:58:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUrWg-0000YK-Gn for sip-web-archive@ietf.org; Thu, 18 Nov 2004 14:01:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUrIC-0000jn-DS; Thu, 18 Nov 2004 13:46:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUr7m-0005fX-Mw for sip@megatron.ietf.org; Thu, 18 Nov 2004 13:35:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19711 for ; Thu, 18 Nov 2004 13:35:17 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUrAQ-0008Oi-6O for sip@ietf.org; Thu, 18 Nov 2004 13:38:04 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 18 Nov 2004 11:39:29 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAIIYZ3O004110; Thu, 18 Nov 2004 10:34:35 -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 KAA27705; Thu, 18 Nov 2004 10:34:38 -0800 (PST) Message-Id: <4.3.2.7.2.20041118122938.03782380@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 18 Nov 2004 12:34:45 -0600 To: Mpierce1@aol.com, jgunn6@csc.com From: "James M. Polk" Subject: Re: [Sip] -RP-05.txt: section 7.1 on priority-value interleaving In-Reply-To: <45.1b7c1c6a.2ecde203@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: An.Nguyen@ncs.gov, rohan@ekabal.com, scmorris@cisco.com, dean.willis@softarmor.com, sip@ietf.org, oran@cisco.com, pbabendr@cisco.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 At 06:31 AM 11/18/2004 -0500, Mpierce1@aol.com wrote: >since it is permissible for an entity to give two levels the same >treatment. For example, in the DSN, Flash and Flash Override may get the >same treatment for packet transport at core routers while other entities >may treat them different (endpoints or edge routers). this is a good point, I will adjust the text to reflect this >The above requirement is too important to "hide" in a section about >multiple namespaces. > >The second paragraph above, and the text that shows relationships between >different namespaces remains confusing since there is a clear agreement >that there is no relationship between namespaces. yet some remained confused until they saw examples of various combinations that didn't violate the rule. >This text clearly implies that there is a relationship. If someything >needs to be said to explain this to people, then let's work on text to >address the problem. I believe that the current text will just further >confuse others (not me). I'm not confused by it because I know the truth. >Others won't. > >Mike Pierce > 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 sip-bounces@ietf.org Thu Nov 18 14:56:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27753 for ; Thu, 18 Nov 2004 14:56:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUsRL-0001tX-F6 for sip-web-archive@ietf.org; Thu, 18 Nov 2004 14:59:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUsHr-0008A5-5d; Thu, 18 Nov 2004 14:49:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUsBv-0006s2-TI for sip@megatron.ietf.org; Thu, 18 Nov 2004 14:43:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25662 for ; Thu, 18 Nov 2004 14:43:38 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUsEX-0001X7-RG for sip@ietf.org; Thu, 18 Nov 2004 14:46:26 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 18 Nov 2004 14:43:04 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAIJh174026977; Thu, 18 Nov 2004 14:43:02 -0500 (EST) Received: from cisco.com ([161.44.79.125]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AND45766; Thu, 18 Nov 2004 14:42:57 -0500 (EST) Message-ID: <419CFB40.1050104@cisco.com> Date: Thu, 18 Nov 2004 14:42:56 -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: "Peterson, Jon" Subject: Re: third alternative (was RE: [Sip] RE: Identity after reinvite) References: <24EAE5D4448B9D4592C6D234CBEBD59708994C@stntexch03.cis.neustar.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit Cc: "'Cullen Jennings'" , "'sip@ietf.org'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: 7bit Trimming the discussion... Peterson, Jon wrote: > I'm glad we're on the same page (or at least the same chapter), but from the > remainder below, it sounds like we're on the same page for very different > reasons. > >>The difference between this and what I had proposed is that I think a UA >>should be *allowed* to change the From in its outbound request. > > Well, we can't stop the callee UA from changing the From header field value > in its backwards-direction requests, yes, but I certainly think that the > caller UA should discard such requests. > > For me, this comes down to a very, very simple case: Alice sends a call to > Bob, and then in the middle of the call, she gets a BYE request from Edgar. > Does Alice accept the BYE or not? This is perhaps the simplest authorization > decision we could ask a client to make, and what I keep hearing people say > is that it's okay if the BYE comes from Edgar instead of Bob. I'm really not > sure how this could possibly be okay - this is unrelated to whether SIPS is > used or any other transitive security is used (see the end of this message); > this is the fundamental question of who should be authorized to terminate a > call. If that set of authorized parties isn't identical to the first and > second parties in the call, then I think we're creating a non-deterministic > security environment. > > Are we really going to tell end users of SIP that it's okay if such a BYE > comes from an Edgar? What do I not understand here? I will admit that this scenario seems pretty broken. However, if the call to bob reached edgar, and he has done as you say, it is futile for alice to reject the BYE. It is an indication that the other party has hung up, and refusing it will not change that. If edgar is just a MITM trying to disrupt a valid call between alice and bob, then maybe rejecting the BYE would accomplish something. But things will still be messed up - for instance CSeq values will be wrong. And if edgar was in a position to do this with his own name, he could just as easily have done it with bob's - aside from the issue of signing. Maybe it makes a little sense in that edgar may be able to get the BYE signed with his own identity, though that will be tricky. I do agree it would be better if we could come up with some explicit way to inform alice that the request has been delegated from bob to edgar. Maybe it is just a matter of choosing among existing mechanisms, rather than inventing something new. >>>In cases where the user contacted >>>at chicago does not possess credentials to authenticate themselves to >>>biloxi, I think it would be fair to say that requests in the backwards >>>direction should not get an Identity header. >> >>I think that it will almost never have such credentials. If it did, this >>wouldn't be retargeting. > > Again, there's something fundamental I don't understand here, then. Alice > sends a request to Bob. For some reason, Bob's domain thinks it is > appropriate to forward the request to, say, Carol. Why does Bob's domain > think that? Because someone, with some relevant permissions, provisioned > Bob's domain with a directive that requests for Bob should be forwarded to > Carol. Of course, Carol personally does not possess Bob's credentials. If > Bob is at Carol's station, though, then Bob will possess Bob's credentials. > If the request arrives at Carol's station, and Bob fields the request, then > Bob will be capable of providing his credentials to any auth service as > necessary. Carol will not. That of course assumes that Carol's phone is capable of prompting for credentials, such as asking for Bob's password. Maybe someday most phones will have that capability, but not today. And what if bob just forwarded to carol because he is away? > If the user at Carol's station possesses Bob's credentials, then it is > reasonable for requests in the backwards direction to receive bear an > Identity header stating that this is from Bob; if not, then there shouldn't > be an Identity header in the request. This seems very intuitive to me; I'm > not sure why this is so radically implausible. I guess this begs the > question of why retargeting happens at all; if retargeting happens for some > other reason than what I describe above, then it most likely violates > RFC3261 as I understand it. In most scenarios I am aware of today, phone is either configured with the credentials, or in a hotelling situation the phone requests credentials to REGISTER somewhere. The hotelling situation is certainly better from a security viewpoint, and it doesn't look like retargetting at all to the caller. But hotelling isn't always going to be possible. Perhaps bob is visiting carol, and can configure his own AOR to retarget to carol, but can't hotel on carol's phone and can't provide credentials for an incoming call that was retargetted from bob to carol. What does this violate in 3261? One solution to this would be for for the biloxi.com server to act as a b2bua, relaying the call to carol. Maybe that is a *model* to consider, with hopes of finding a better implementation. That is also roughly the model when a gateway is being used. We already know that in the gateway case the connected party on the far side of the gateway can change, and there are desires to convey that info. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 18 15:02:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29183 for ; Thu, 18 Nov 2004 15:02:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUsX0-00026s-6b for sip-web-archive@ietf.org; Thu, 18 Nov 2004 15:05:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUsO1-0001fg-BZ; Thu, 18 Nov 2004 14:56:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUsFa-0007p0-N8; Thu, 18 Nov 2004 14:47:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25969; Thu, 18 Nov 2004 14:47:24 -0500 (EST) Received: from amer-mta01.csc.com ([20.137.2.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUsIG-0001c4-NF; Thu, 18 Nov 2004 14:50:13 -0500 Received: from csc.com (va-fch34.csc.com [20.6.39.227]) by amer-mta01.csc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id iAIJlJQR006982; Thu, 18 Nov 2004 14:47:20 -0500 (EST) Subject: Re: [Sip] -RP-05.txt: section 7.1 on priority-value interleaving To: "James M. Polk" X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Janet P Gunn Date: Thu, 18 Nov 2004 14:48:05 -0500 X-MIMETrack: Serialize by Router on VA-FCH34/SRV/CSC(Release 6.0.3|September 26, 2003) at 11/18/2004 02:48:15 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: An.Nguyen@ncs.gov, rohan@ekabal.com, scmorris@cisco.com, dean.willis@softarmor.com, sip@ietf.org, sip-bounces@ietf.org, oran@cisco.com, pbabendr@cisco.com, Mpierce1@aol.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 That would help with one of my concerns too- that for some resources we need to prioritize based on the value and for other resources we only care about the namespace. ---------------------------------------------------------------------------------------- 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. ---------------------------------------------------------------------------------------- "James M. Polk" cc: An.Nguyen@ncs.gov, rohan@ekabal.com, scmorris@cisco.com, Sent by: dean.willis@softarmor.com, sip@ietf.org, oran@cisco.com, pbabendr@cisco.com sip-bounces Subject: Re: [Sip] -RP-05.txt: section 7.1 on priority-value interleaving 11/18/2004 01:34 PM At 06:31 AM 11/18/2004 -0500, Mpierce1@aol.com wrote: >since it is permissible for an entity to give two levels the same >treatment. For example, in the DSN, Flash and Flash Override may get the >same treatment for packet transport at core routers while other entities >may treat them different (endpoints or edge routers). this is a good point, I will adjust the text to reflect this >The above requirement is too important to "hide" in a section about >multiple namespaces. > >The second paragraph above, and the text that shows relationships between >different namespaces remains confusing since there is a clear agreement >that there is no relationship between namespaces. yet some remained confused until they saw examples of various combinations that didn't violate the rule. >This text clearly implies that there is a relationship. If someything >needs to be said to explain this to people, then let's work on text to >address the problem. I believe that the current text will just further >confuse others (not me). I'm not confused by it because I know the truth. >Others won't. > >Mike Pierce > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 18 16:40:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19459 for ; Thu, 18 Nov 2004 16:40:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUu3T-0007hP-DB for sip-web-archive@ietf.org; Thu, 18 Nov 2004 16:43:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUthU-0006VP-Pi; Thu, 18 Nov 2004 16:20:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUtBS-0001bd-GB for sip@megatron.ietf.org; Thu, 18 Nov 2004 15:47:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07156 for ; Thu, 18 Nov 2004 15:47:11 -0500 (EST) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUtE9-0003vp-2f for sip@ietf.org; Thu, 18 Nov 2004 15:50:01 -0500 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id iAIKkgxg007213; Thu, 18 Nov 2004 20:46:42 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Thu, 18 Nov 2004 15:46:41 -0500 Message-ID: <24EAE5D4448B9D4592C6D234CBEBD597089952@stntexch03.cis.neustar.com> From: "Peterson, Jon" To: "'Paul Kyzivat'" Subject: RE: third alternative (was RE: [Sip] RE: Identity after reinvite) Date: Thu, 18 Nov 2004 15:46:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: "'Cullen Jennings'" , "'sip@ietf.org'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 > > Are we really going to tell end users of SIP that it's okay if such a BYE > > comes from an Edgar? What do I not understand here? > > I will admit that this scenario seems pretty broken. > > However, if the call to bob reached edgar, and he has done as you say, > it is futile for alice to reject the BYE. It is an indication that the > other party has hung up, and refusing it will not change that. What I really meant here is that it makes no sense to provide Identity for a request in the backwards direction from Edgar if he is not the intended target of the call. Identity is useful only if it is going to factor into an authorization decision regarding impersonation. If literally any identity in the request must be accepted by Alice, rather than the unique identity of Bob, then Identity is a null op and we should stop trying to engineer for this case. This is the "fourth alternative" I alluded to in my last mail - just say that request identity is not meaningful for any requests in a dialog other than the dialog-forming request. I do think we can do better than that, though, without creating serious problems for ourselves. If we choose the fourth alternative, we will be allowing a certain security hole to remain open, one that I believe we can close without too much trouble. > If edgar is just a MITM trying to disrupt a valid call between alice and > bob, then maybe rejecting the BYE would accomplish something. But things > will still be messed up - for instance CSeq values will be wrong. By "reject" here I mean something more along the lines of "silently discard". A spoofed request should not alter the dialog state in the recipient. > And if > edgar was in a position to do this with his own name, he could just as > easily have done it with bob's - aside from the issue of signing. Maybe > it makes a little sense in that edgar may be able to get the BYE signed > with his own identity, though that will be tricky. This is the rub. If Alice will accept only BYE requests from Bob, then Identity adds value - Edgar cannot impersonate Bob because of Identity. Identity only addresses threats of impersonation. > I do agree it would be better if we could come up with some explicit way > to inform alice that the request has been delegated from bob to edgar. > Maybe it is just a matter of choosing among existing mechanisms, rather > than inventing something new. Totally agreed. sip-identity-02 suggested, albeit without sufficient motivation and argument, that the requirements for such a mechanism are satisfied by simple SIP redirection. I'm trying to keep that whole issue out of the scope of sip-identity-03/04, and one way to do that, I think, is to go along with something roughly like my "third alternative" proposal, which basically works when it can, and is forward-compatible with a future redirection-based responde identity model in which it would work all the time. > > Alice > > sends a request to Bob. For some reason, Bob's domain thinks it is > > appropriate to forward the request to, say, Carol. Why does Bob's domain > > think that? Because someone, with some relevant permissions, provisioned > > Bob's domain with a directive that requests for Bob should be forwarded to > > Carol. Of course, Carol personally does not possess Bob's credentials. If > > Bob is at Carol's station, though, then Bob will possess Bob's credentials. > > If the request arrives at Carol's station, and Bob fields the request, then > > Bob will be capable of providing his credentials to any auth service as > > necessary. Carol will not. > > That of course assumes that Carol's phone is capable of prompting for > credentials, such as asking for Bob's password. Maybe someday most > phones will have that capability, but not today. > > And what if bob just forwarded to carol because he is away? In both of these cases, clearly, Identity should not be provided in the backwards direction. If the responder isn't actually Bob, then it shouldn't claim to be. But claiming to be someone else (Carol, or Edgar, or what have you) doesn't help Alice to make any meaningful authorization decisions, I think, unless Bob's domain has some way to communicate to Alice that the request has been forwarded to that particular someone. This isn't to say that there might not be some counterexamples to that last principle - I mean, it's possible that the identity of the connected party will make it clear how/why the request was retargeted, and that this will seem reasonable from an authorization perspective to a caller with some pre-knowledge of the callee - but the existence of such counterexamples does not, I think, justify leaving this security hole wide open for those cases where we cannot rely on human pre-association and presumption to fill in the gaps of our protocol's authorization story. That is a non-deterministic security environment. Of course, if Bob's domain redirected rather than retargeting, the underlying problem would be solved. > > > If the user at Carol's station possesses Bob's credentials, then it is > > reasonable for requests in the backwards direction to receive bear an > > Identity header stating that this is from Bob; if not, then there shouldn't > > be an Identity header in the request. This seems very intuitive to me; I'm > > not sure why this is so radically implausible. I guess this begs the > > question of why retargeting happens at all; if retargeting happens for some > > other reason than what I describe above, then it most likely violates > > RFC3261 as I understand it. > > In most scenarios I am aware of today, phone is either configured with > the credentials, or in a hotelling situation the phone requests > credentials to REGISTER somewhere. The hotelling situation is certainly > better from a security viewpoint, and it doesn't look like retargetting > at all to the caller. > > But hotelling isn't always going to be possible. Perhaps bob is visiting > carol, and can configure his own AOR to retarget to carol, but can't > hotel on carol's phone and can't provide credentials for an incoming > call that was retargetted from bob to carol. > > What does this violate in 3261? Your two paragraphs above violate nothing about RFC3261. I was referring to the motivations for legitimate retargeting (that is, that Bob's domain is the only one that can retarget a request for Bob, and that Bob has an association with his domain that allows him to control his contact list). While I don't disagree with you that the case described above is possible, I'm just saying that we shouldn't provide an Identity header in that case. > One solution to this would be for for the biloxi.com server to act as a > b2bua, relaying the call to carol. Maybe that is a *model* to consider, > with hopes of finding a better implementation. That is also roughly the > model when a gateway is being used. We already know that in the gateway > case the connected party on the far side of the gateway can change, and > there are desires to convey that info. > (weep) Maybe we could at least consider redirection before we start suggesting that this is a B2BUA problem. I really think that the problem of mid-call changes in connected-party is a very different case, and much more specialized than what we're concerned with here. We're talking here about assuring the identity of the first and second parties to a dialog at the time of dialog establishment. I'd like to think that the ultimate solutions to the mid-call 'identity update' sort of problems are more along the transfer/replaces line of thinking. Jon Peterson NeuStar, Inc. > Paul > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 18 17:25:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25736 for ; Thu, 18 Nov 2004 17:25:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUulA-0000rN-4e for sip-web-archive@ietf.org; Thu, 18 Nov 2004 17:28:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUuZo-0002uI-NF; Thu, 18 Nov 2004 17:16:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUuSq-0008OA-EW for sip@megatron.ietf.org; Thu, 18 Nov 2004 17:09:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23741 for ; Thu, 18 Nov 2004 17:09:13 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUuVX-0000N5-Rd for sip@ietf.org; Thu, 18 Nov 2004 17:12:04 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 18 Nov 2004 17:08:46 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iAIM8eWf021071; Thu, 18 Nov 2004 17:08:41 -0500 (EST) Received: from cisco.com ([161.44.79.125]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AND59425; Thu, 18 Nov 2004 17:08:41 -0500 (EST) Message-ID: <419D1D69.3010300@cisco.com> Date: Thu, 18 Nov 2004 17:08:41 -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: "Peterson, Jon" Subject: Re: third alternative (was RE: [Sip] RE: Identity after reinvite) References: <24EAE5D4448B9D4592C6D234CBEBD597089952@stntexch03.cis.neustar.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af Content-Transfer-Encoding: 7bit Cc: "'Cullen Jennings'" , "'sip@ietf.org'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f Content-Transfer-Encoding: 7bit Peterson, Jon wrote: >>>Are we really going to tell end users of SIP that it's okay if such a >> > BYE > >>>comes from an Edgar? What do I not understand here? >> >>I will admit that this scenario seems pretty broken. >> >>However, if the call to bob reached edgar, and he has done as you say, >>it is futile for alice to reject the BYE. It is an indication that the >>other party has hung up, and refusing it will not change that. > > > What I really meant here is that it makes no sense to provide Identity for a > request in the backwards direction from Edgar if he is not the intended > target of the call. Identity is useful only if it is going to factor into an > authorization decision regarding impersonation. If literally any identity in > the request must be accepted by Alice, rather than the unique identity of > Bob, then Identity is a null op and we should stop trying to engineer for > this case. Providing identity for edgar help with any *automatic* authorization decision by alice's UA. But knowing that it is really edgar may nevertheless be useful to alice. Maybe alice knows that edgar is an associate of Bob's. That would be sigificant compared to getting an unauthenticated identity. You mention this later, but discount its value more than I do. This is the "fourth alternative" I alluded to in my last mail - > just say that request identity is not meaningful for any requests in a > dialog other than the dialog-forming request. Well, it may be another step down the path to someplace better. I do think we can do better > than that, though, without creating serious problems for ourselves. If we > choose the fourth alternative, we will be allowing a certain security hole > to remain open, one that I believe we can close without too much trouble. > > >>If edgar is just a MITM trying to disrupt a valid call between alice and >>bob, then maybe rejecting the BYE would accomplish something. But things >>will still be messed up - for instance CSeq values will be wrong. > > > By "reject" here I mean something more along the lines of "silently > discard". A spoofed request should not alter the dialog state in the > recipient. But what if it was really a BYE from the other participant in my call? Just ignoring it isn't going to be a good thing. I think one would at least want to check it out - maybe send an update or reinvite to see if there is still a dialog up. >>And if >>edgar was in a position to do this with his own name, he could just as >>easily have done it with bob's - aside from the issue of signing. Maybe >>it makes a little sense in that edgar may be able to get the BYE signed >>with his own identity, though that will be tricky. > > This is the rub. If Alice will accept only BYE requests from Bob, then > Identity adds value - Edgar cannot impersonate Bob because of Identity. > Identity only addresses threats of impersonation. But if the far end party really is Edgar rather than Bob (because of retargetting) then the end result of this strategy is that no signalling from Edgar will work. No putting on hold, etc. Essentially the call is broken. Not a great strategy. >>I do agree it would be better if we could come up with some explicit way >>to inform alice that the request has been delegated from bob to edgar. >>Maybe it is just a matter of choosing among existing mechanisms, rather >>than inventing something new. > > Totally agreed. sip-identity-02 suggested, albeit without sufficient > motivation and argument, that the requirements for such a mechanism are > satisfied by simple SIP redirection. I'm trying to keep that whole issue out > of the scope of sip-identity-03/04, and one way to do that, I think, is to > go along with something roughly like my "third alternative" proposal, which > basically works when it can, and is forward-compatible with a future > redirection-based responde identity model in which it would work all the > time. I think most of the things we are discussing are compatible with a future redirection based approach. What you propose is just a minimalist approach among those. >>>Alice >>>sends a request to Bob. For some reason, Bob's domain thinks it is >>>appropriate to forward the request to, say, Carol. Why does Bob's domain >>>think that? Because someone, with some relevant permissions, provisioned >>>Bob's domain with a directive that requests for Bob should be forwarded >> > to > >>>Carol. Of course, Carol personally does not possess Bob's credentials. >> > If > >>>Bob is at Carol's station, though, then Bob will possess Bob's >> > credentials. > >>>If the request arrives at Carol's station, and Bob fields the request, >> > then > >>>Bob will be capable of providing his credentials to any auth service as >>>necessary. Carol will not. >> >>That of course assumes that Carol's phone is capable of prompting for >>credentials, such as asking for Bob's password. Maybe someday most >>phones will have that capability, but not today. >> >>And what if bob just forwarded to carol because he is away? > > > In both of these cases, clearly, Identity should not be provided in the > backwards direction. If the responder isn't actually Bob, then it shouldn't > claim to be. I don't think anybody (except maybe you once in this thread) is suggesting that should be able to claim to be Bob and receive identification as Bob. However, the current rules for dialogs to suggest that within the dialog, Carol or Edgar will have to claim to be Bob. One question is whether to have them do that, or instead change the To/From within the dialog. Unless we simply ban this case altogether (mandating redirect to avoid it), then we must at least answer this question. But claiming to be someone else (Carol, or Edgar, or what have > you) doesn't help Alice to make any meaningful authorization decisions, I > think, unless Bob's domain has some way to communicate to Alice that the > request has been forwarded to that particular someone. > > This isn't to say that there might not be some counterexamples to that last > principle - I mean, it's possible that the identity of the connected party > will make it clear how/why the request was retargeted, and that this will > seem reasonable from an authorization perspective to a caller with some > pre-knowledge of the callee - but the existence of such counterexamples does > not, I think, justify leaving this security hole wide open for those cases > where we cannot rely on human pre-association and presumption to fill in the > gaps of our protocol's authorization story. That is a non-deterministic > security environment. I think it is better to have Carol say she is Carol than say she is Bob. And it is better yet for that assertion to be verifiably signed. Yes, it still leaves a security hole that we can work on filling. > Of course, if Bob's domain redirected rather than retargeting, the > underlying problem would be solved. > > >>>If the user at Carol's station possesses Bob's credentials, then it is >>>reasonable for requests in the backwards direction to receive bear an >>>Identity header stating that this is from Bob; if not, then there >> > shouldn't > >>>be an Identity header in the request. This seems very intuitive to me; >> > I'm > >>>not sure why this is so radically implausible. I guess this begs the >>>question of why retargeting happens at all; if retargeting happens for >> > some > >>>other reason than what I describe above, then it most likely violates >>>RFC3261 as I understand it. >> >>In most scenarios I am aware of today, phone is either configured with >>the credentials, or in a hotelling situation the phone requests >>credentials to REGISTER somewhere. The hotelling situation is certainly >>better from a security viewpoint, and it doesn't look like retargetting >>at all to the caller. >> >>But hotelling isn't always going to be possible. Perhaps bob is visiting >>carol, and can configure his own AOR to retarget to carol, but can't >>hotel on carol's phone and can't provide credentials for an incoming >>call that was retargetted from bob to carol. >> >>What does this violate in 3261? > > > Your two paragraphs above violate nothing about RFC3261. I was referring to > the motivations for legitimate retargeting (that is, that Bob's domain is > the only one that can retarget a request for Bob, and that Bob has an > association with his domain that allows him to control his contact list). > > While I don't disagree with you that the case described above is possible, > I'm just saying that we shouldn't provide an Identity header in that case. > > >>One solution to this would be for for the biloxi.com server to act as a >>b2bua, relaying the call to carol. Maybe that is a *model* to consider, >>with hopes of finding a better implementation. That is also roughly the >>model when a gateway is being used. We already know that in the gateway >>case the connected party on the far side of the gateway can change, and >>there are desires to convey that info. > > (weep) > > Maybe we could at least consider redirection before we start suggesting that > this is a B2BUA problem. Yes, of course. But there are those people who feel in fact that it is important that Alice *not* know the call has been retargetted, or at least *where* it has been retargetted. Those folks won't go for redirection. Of course they also then don't want to report back the connected party id either, so maybe that is out of scope for this discussion. Like most things, we probably need a toolbag of alternatives that can be used according to the policies of the players. > I really think that the problem of mid-call changes in connected-party is a > very different case, and much more specialized than what we're concerned > with here. We're talking here about assuring the identity of the first and > second parties to a dialog at the time of dialog establishment. I'd like to > think that the ultimate solutions to the mid-call 'identity update' sort of > problems are more along the transfer/replaces line of thinking. Depending on your preference for mechanisms, it may or may not be useful to conflate these problems. I guess I agree with you that we can consider them separately. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 19 09:43:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06571 for ; Fri, 19 Nov 2004 09:43:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVA1p-00061E-Fh for sip-web-archive@ietf.org; Fri, 19 Nov 2004 09:46:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CV9vG-0001gV-Ay; Fri, 19 Nov 2004 09:39:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CV9mg-00084q-Lj for sip@megatron.ietf.org; Fri, 19 Nov 2004 09:30:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05470 for ; Fri, 19 Nov 2004 09:30:45 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CV9pV-0005ix-Py for sip@ietf.org; Fri, 19 Nov 2004 09:33:43 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 19 Nov 2004 06:32:38 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAJEU63O006520; Fri, 19 Nov 2004 06:30:06 -0800 (PST) Received: from [10.32.245.156] (stealth-10-32-245-156.cisco.com [10.32.245.156]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id iAJEUNEr000793; Fri, 19 Nov 2004 06:30:23 -0800 In-Reply-To: <24EAE5D4448B9D4592C6D234CBEBD597089952@stntexch03.cis.neustar.com> References: <24EAE5D4448B9D4592C6D234CBEBD597089952@stntexch03.cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8393BB1D-3A37-11D9-8BE3-000A95C73842@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: third alternative (was RE: [Sip] RE: Identity after reinvite) Date: Fri, 19 Nov 2004 09:30:08 -0500 To: "Peterson, Jon" X-Mailer: Apple Mail (2.619) IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1100874624.293188"; x:"432200"; a:"rsa-sha1"; b:"nofws:1504"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"E3GSNOygrtu3kb0kTqeBZIn9qbEWTvmtlTcwcR+Xgoi+n7raOyQFbAlhaBFsa" "ca99NrBOKS2hb3dFI0EAMsUABbNn5emOjQQ7VDOfm6WA9Z6YHin12cnZ0dHL6" "8OiDPXmy/ahgiKNldLM/kg0O+isU0W0trT2SplGsjx6RSxAJM="; c:"From: David R Oran "; c:"Subject: Re: third alternative (was RE: [Sip] RE: Identity after reinv" "ite)"; c:"Date: Fri, 19 Nov 2004 09:30:08 -0500" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: "'Cullen Jennings'" , "'sip@ietf.org'" , "'Paul Kyzivat'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit On Nov 18, 2004, at 3:46 PM, Peterson, Jon wrote: >> One solution to this would be for for the biloxi.com server to act as >> a >> b2bua, relaying the call to carol. Maybe that is a *model* to >> consider, >> with hopes of finding a better implementation. That is also roughly >> the >> model when a gateway is being used. We already know that in the >> gateway >> case the connected party on the far side of the gateway can change, >> and >> there are desires to convey that info. >> > > (weep) > > Maybe we could at least consider redirection before we start > suggesting that > this is a B2BUA problem. > Redirection is generally cleaner than retargeting, but does not satisfy the "Monica property". It may be that a B2BUA is inescapable in those cases anyway. > I really think that the problem of mid-call changes in connected-party > is a > very different case, and much more specialized than what we're > concerned > with here. We're talking here about assuring the identity of the first > and > second parties to a dialog at the time of dialog establishment. I'd > like to > think that the ultimate solutions to the mid-call 'identity update' > sort of > problems are more along the transfer/replaces line of thinking. > I tend to agree. It would be much cleaner if all identity/connected-party changes devolved to a flavor of transfer (except the Monica cases I mention above). Dave. > Jon Peterson > NeuStar, Inc. > >> Paul >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 19 12:20:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22930 for ; Fri, 19 Nov 2004 12:20:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVCTt-0001QH-HY for sip-web-archive@ietf.org; Fri, 19 Nov 2004 12:23:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVCDs-0001of-P1; Fri, 19 Nov 2004 12:07:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVC6y-0007zS-WA for sip@megatron.ietf.org; Fri, 19 Nov 2004 11:59:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21066 for ; Fri, 19 Nov 2004 11:59:50 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVC9q-0000u0-GV for sip@ietf.org; Fri, 19 Nov 2004 12:02:50 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 19 Nov 2004 08:59:41 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from vtg-um-e2k1.sj21ad.cisco.com (vtg-um-e2k1.cisco.com [171.70.93.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id iAJGx8W9029328; Fri, 19 Nov 2004 08:59:17 -0800 (PST) Received: from [128.107.171.115] ([128.107.171.115]) by vtg-um-e2k1.sj21ad.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 19 Nov 2004 08:59:16 -0800 Message-ID: <419E2663.6000409@cisco.com> Date: Fri, 19 Nov 2004 08:59:15 -0800 From: Charles Eckel Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Langstaff Subject: Re: [Sip] PING/PONG References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Nov 2004 16:59:16.0346 (UTC) FILETIME=[1A6515A0:01C4CE59] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Christian Stredicke X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: 7bit The problem is that if you leave it entirely at the STUN level you are just ensuring that STUN server will be able to reach the STUN clients all times. However, what you really need is for the SIP proxy to be able to reach its SIP clients at all times. If the STUN server and proxy server are both listening and sending from the same port, you are fine using STUN by itself; otherwise, you need to do something else. Cheers, Charles Steve Langstaff wrote: > Sorry, I didn't realise the scope of this discussion was client-to-proxy > - that's where my confusion lay. > > A further question from my (simplistic) viewpoint... If this issue > is/could be generic to all STUNned traffic (not just sip+stun), would it > not be better to push the problem down into the STUN 'layer' and let the > STUN client and server sort out keeping the NAT bindings alive? I'm > guessing that the SIP client already 'knows' it has to use STUN to reach > the proxy, and so could ask it's STUN client to keep the binding(s) > alive as appropriate. > > > -- > Steve Langstaff. > > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: 18 November 2004 04:46 > To: Steve Langstaff > Cc: Christian Stredicke; sip@ietf.org > Subject: Re: [Sip] PING/PONG > > > There isn't a UAS involved here; these requests go from the client (UAC) > to its proxy. > > How the proxy indicates to the UAC that it is capable of processing > these keepalives is a good question. My first thought is that this would > be something in DNS; a new service in the NAPTR record for indicating > the sip+stun combination. > > -Jonathan R. > > Steve Langstaff wrote: > > > Should point 2 read "The user agent server indicates if it can > respond to client refresh requests"? > > > > -- > > Steve Langstaff. > > > > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > > Jonathan Rosenberg > > Sent: 17 November 2004 16:40 > > To: Christian Stredicke > > Cc: sip@ietf.org > > Subject: Re: [Sip] PING/PONG > > > > > > > > > > Christian Stredicke wrote: > > > > > >>So my understanding is: > >> > >>1. We should use *only* STUN for refreshing bindings (either UDP or TCP, > >>what about TLS) > > > > > > Yes, TLS too. TLS runs ontop of TCP after all. > > > > > >>2. The user agent indicates if it can do it (no negotiation on > >>capabilities) > >> > >>3. Refreshing must be done from the client > >> > >>Can we agree on that? > > > > > > Yes. > > > > Server originating refreshing is in the wrong direction. It is the > > client utilizing the service; if it wishes to make use of that service, > > it has to be responsible for refreshing the connection. > > > > -Jonathan R. > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 22 02:18:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23942 for ; Mon, 22 Nov 2004 02:18:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CW8We-0006Mg-3u for sip-web-archive@ietf.org; Mon, 22 Nov 2004 02:22:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CW8M9-0003LT-5P; Mon, 22 Nov 2004 02:11:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CW8HD-0001Hm-57 for sip@megatron.ietf.org; Mon, 22 Nov 2004 02:06:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13922 for ; Mon, 22 Nov 2004 02:06:18 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CW8Kb-0006AV-N6 for sip@ietf.org; Mon, 22 Nov 2004 02:09:50 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 21 Nov 2004 23:08:43 -0800 Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iAM75Ww0023086; Sun, 21 Nov 2004 23:05:33 -0800 (PST) Received: from [10.0.0.125] (sjc-vpn2-471.cisco.com [10.21.113.215]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFW79660; Sun, 21 Nov 2004 23:05:35 -0800 (PST) Message-ID: <41A18FBE.2060707@cisco.com> Date: Mon, 22 Nov 2004 02:05:34 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Charles Eckel Subject: Re: [Sip] PING/PONG References: <419E2663.6000409@cisco.com> In-Reply-To: <419E2663.6000409@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Christian Stredicke , Steve Langstaff X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Content-Transfer-Encoding: 7bit I think there may be some confusion here about how this works. The STUN server is a logical function that *must* run on the same IP and port as the SIP server. In other words, if I have a proxy, and it is listening for SIP messages on 1.2.3.4:5060, then it would also be able to process STUN requests on 1.2.3.4:5060. A response to a stun request sent to that IP/port would get sent from that same port. Thus, there is no separate stun server here. The stun functionality is co-resident with the sip proxy; this is necessary to make sure that the proxy knows that the client is still there, to allow the client to know that the proxy is still there, and lastly, to ensure that the keepalives refresh the nat bindings in a way that allow the client to continue to reach the SIP proxy server and vice-a-versa. Since the keepalives are sent to the same place where the signaling traffic goes/comes from, the keepalives work even with symmetric nat. -Jonathan R. Charles Eckel wrote: > The problem is that if you leave it entirely at the STUN level you are > just ensuring that STUN server will be able to reach the STUN clients > all times. However, what you really need is for the SIP proxy to be able > to reach its SIP clients at all times. If the STUN server and proxy > server are both listening and sending from the same port, you are fine > using STUN by itself; otherwise, you need to do something else. > > Cheers, > Charles > > Steve Langstaff wrote: > >> Sorry, I didn't realise the scope of this discussion was >> client-to-proxy - that's where my confusion lay. >> >> A further question from my (simplistic) viewpoint... If this issue >> is/could be generic to all STUNned traffic (not just sip+stun), would >> it not be better to push the problem down into the STUN 'layer' and >> let the STUN client and server sort out keeping the NAT bindings >> alive? I'm guessing that the SIP client already 'knows' it has to use >> STUN to reach the proxy, and so could ask it's STUN client to keep the >> binding(s) alive as appropriate. >> >> >> -- >> Steve Langstaff. >> >> >> -----Original Message----- >> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >> Sent: 18 November 2004 04:46 >> To: Steve Langstaff >> Cc: Christian Stredicke; sip@ietf.org >> Subject: Re: [Sip] PING/PONG >> >> >> There isn't a UAS involved here; these requests go from the client (UAC) >> to its proxy. >> >> How the proxy indicates to the UAC that it is capable of processing >> these keepalives is a good question. My first thought is that this would >> be something in DNS; a new service in the NAPTR record for indicating >> the sip+stun combination. >> >> -Jonathan R. >> >> Steve Langstaff wrote: >> >> > Should point 2 read "The user agent server indicates if it can >> respond to client refresh requests"? >> > >> > -- >> > Steve Langstaff. >> > >> > >> > -----Original Message----- >> > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of >> > Jonathan Rosenberg >> > Sent: 17 November 2004 16:40 >> > To: Christian Stredicke >> > Cc: sip@ietf.org >> > Subject: Re: [Sip] PING/PONG >> > >> > >> > >> > >> > Christian Stredicke wrote: >> > >> > >> >>So my understanding is: >> >> >> >>1. We should use *only* STUN for refreshing bindings (either UDP or >> TCP, >> >>what about TLS) >> > >> > >> > Yes, TLS too. TLS runs ontop of TCP after all. >> > >> > >> >>2. The user agent indicates if it can do it (no negotiation on >> >>capabilities) >> >> >> >>3. Refreshing must be done from the client >> >> >> >>Can we agree on that? >> > >> > >> > Yes. >> > >> > Server originating refreshing is in the wrong direction. It is the >> > client utilizing the service; if it wishes to make use of that >> service, >> > it has to be responsible for refreshing the connection. >> > >> > -Jonathan R. >> > >> >> -- >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 >> Cisco Systems >> jdrosen@cisco.com FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.cisco.com >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 22 03:11:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29764 for ; Mon, 22 Nov 2004 03:11:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CW9M5-0007WC-7t for sip-web-archive@ietf.org; Mon, 22 Nov 2004 03:15:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CW9H4-0000uo-HJ; Mon, 22 Nov 2004 03:10:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CW9AE-0000HM-1v for sip@megatron.ietf.org; Mon, 22 Nov 2004 03:03:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29270 for ; Mon, 22 Nov 2004 03:03:08 -0500 (EST) Received: from [203.129.224.106] (helo=kr.aftek.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CW9DX-0007O8-Tm for sip@ietf.org; Mon, 22 Nov 2004 03:06:41 -0500 Received: from Amit ([10.0.0.169]) by kr.aftek.com (8.11.6/8.11.6) with ESMTP id iAM82ov09716 for ; Mon, 22 Nov 2004 13:32:51 +0530 Content-Type: text/plain; charset="us-ascii" From: Anurag Kabra Organization: Aftek Infosys Ltd. To: sip@ietf.org Date: Mon, 22 Nov 2004 13:39:52 +0530 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200411221339.52711.anuragk@aftek.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: quoted-printable Subject: [Sip] Call Pickup X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Hello Everyone I have a query regarding call pickup, Is there any specific standard for=20 implementing directed call pickup. I need to know the implementation det= ails=20 of it. I could only find an example in SIP service examples. Thank You & Best Regards Anurag. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 22 04:59:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07063 for ; Mon, 22 Nov 2004 04:59:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWB2J-0001Fc-86 for sip-web-archive@ietf.org; Mon, 22 Nov 2004 05:03:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWAuO-0002BV-K7; Mon, 22 Nov 2004 04:54:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWApi-0001Yy-LG for sip@megatron.ietf.org; Mon, 22 Nov 2004 04:50:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06609 for ; Mon, 22 Nov 2004 04:50:04 -0500 (EST) Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWAt8-00015C-CO for sip@ietf.org; Mon, 22 Nov 2004 04:53:39 -0500 Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 22 Nov 2004 10:49:30 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Nov 2004 10:48:04 +0100 Message-Id: From: "Jesske, R" To: mary.barnes@nortelnetworks.com, sebastien.prouvost@francetelecom.com, sebastien.garcin@francetelecom.com, sip@ietf.org Subject: AW: [Sip] Privacy statements and History(draft-ietf-sip-history-i nfo-04.txt) Date: Mon, 22 Nov 2004 10:47:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.9 (/) X-Scan-Signature: a5d64674af3d12893846a18a44c07b83 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1541408640==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 6fc5b1c74c5bed09a3a9da2884900dec This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1541408640== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4D078.44EEDFD8" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4D078.44EEDFD8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mary, that looks good for me. =20 Best Regards =20 Roland -----Urspr=FCngliche Nachricht----- Von: Mary Barnes [mailto:mary.barnes@nortelnetworks.com] Gesendet: Mittwoch, 17. November 2004 18:50 An: 'PROUVOST Sebastien RD-CORE-ISS'; GARCIN Sebastien RD-CORE-ISS; = Jesske, Roland; sip@ietf.org Betreff: RE: [Sip] Privacy statements and = History(draft-ietf-sip-history-i nfo-04.txt) Hi all, =20 I've again snipped the thread, but did want to propose the change that = I think will satisfy the concerns raised. =20 The change proposed is to change the last statement in the first = paragraph in section 4.3.3.1.1 from: "...the proxy MUST remove any hi-entry(s) prior to forwarding." to: "...the proxy SHOULD remove any hi-entry(s) prior to forwarding, = depending upon local policy and whether the proxy might know apriori = that it can rely on a downstream privacy service to apply the requested = privacy."=20 =20 So, unless further concerns are raised on this proposed change, I'll = plan on incorporating that with any other last call comments in the -05 = version. =20 Mary=20 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = PROUVOST Sebastien RD-CORE-ISS Sent: Thursday, November 11, 2004 8:44 AM To: Barnes, Mary [NGC:B601:EXCH]; GARCIN Sebastien RD-CORE-ISS; Jesske, = R; sip@ietf.org Subject: RE: [Sip] Privacy statements and = History(draft-ietf-sip-history-info-04.txt) Mary, Sebastien, Roland,=20 =20 I agree that we should let the possibility for a proxy not to remove = the hi-entry even if privacy is requested and even if the request is = forwarded to a Request-URI associated with a domain for which the proxy = is not responsible (if there is an agreement between the domains that = ensures the proxy that privacy will be applied to the request).=20 I suggest a text that would look like (in case privacy is requested): = "the hi-entry SHOULD be removed by the proxy unless it knows that it = can rely on a downstream privacy service to apply the requested privacy = ". =20 Sebastien. _____ =20 De : sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] De la part de = Mary Barnes Envoy=E9 : mercredi 10 novembre 2004 19:54 =C0 : GARCIN Sebastien RD-CORE-ISS; Jesske, R; sip@ietf.org Objet : RE: [Sip] Privacy statements and History = (draft-ietf-sip-history-info-04.txt) I still contend that the SHOULD is sufficient. SHOULD means that in = general processing, if the hi-entry has a privacy header, then the = usual processing would be that it would be removed (i.e it was added = for a specific reason and in general should be used to remove the = entries based on well defined criteria). If there are reasons, such as = local policy, that would allow the forwarding in specific cases, then = it's okay that it is forwarded. I think the use of MAY results in less = precision and I think the value and critera for associating and = removing the privacy header with the hi-entry becomes much less clear. = I'd like to hear more opinions on this topic, prior to agreeing to = making the change (from the MUST to MAY rather than MUST to SHOULD).=20 Regards,=20 Mary=20 -----Original Message-----=20 From: GARCIN Sebastien RD-CORE-ISS [ = mailto:sebastien.garcin@francetelecom.com = ]=20 Sent: Wednesday, November 10, 2004 12:28 PM=20 To: Barnes, Mary [NGC:B601:EXCH]; Jesske, R; sip@ietf.org=20 Cc: VL-T-Com-T-TE332@vli.telekom.de=20 Subject: RE: [Sip] Privacy statements and History = (draft-ietf-sip-history-info-04.txt)=20 Mary and roland,=20 Actually, the statement regarding the forwarding of hi-entries beyond = the domain for which the proxy is responsible should rather be a matter = of local policy and thus a MAY should be used instead of SHOULD. We are = potentially dealing with network boundaries where agreements for = forwarding such kind information can be reached. Section 4.3.3.1.1=20 This section should be re-reworded in accordance with the statement = above (I can provide some text is we can agree).=20 Section 4.3.3.1 is ok (apologies for not being explicit)=20 Best regards,=20 s=E9bastien=20 =20 ------Remainder of thread has been = deleted by Mary------------------ ------_=_NextPart_001_01C4D078.44EEDFD8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Mary,
that=20 looks good for me.
 
Best=20 Regards
 
Roland
-----Urspr=FCngliche Nachricht-----
Von: Mary = Barnes=20 [mailto:mary.barnes@nortelnetworks.com]
Gesendet: Mittwoch, = 17.=20 November 2004 18:50
An: 'PROUVOST Sebastien RD-CORE-ISS'; = GARCIN=20 Sebastien RD-CORE-ISS; Jesske, Roland; = sip@ietf.org
Betreff: RE:=20 [Sip] Privacy statements and History(draft-ietf-sip-history-i=20 nfo-04.txt)

Hi=20 all,
 
I've=20 again snipped the thread, but did want to propose the change that I = think will=20 satisfy the concerns raised.
 
The=20 change proposed is to change the last statement in the first = paragraph in=20 section 4.3.3.1.1 from:
"...the proxy MUST remove any hi-entry(s) prior to=20 forwarding."
to:
"...the proxy SHOULD remove any hi-entry(s) = prior to=20 forwarding, depending upon local policy and whether the proxy = might know=20 apriori that it can rely on a downstream privacy service to apply the = requested privacy." 
 
So, unless=20 further concerns are raised on this proposed change, I'll plan on=20 incorporating that with any other last call comments in the -05=20 version.
 
Mary=20
-----Original Message-----
From:=20 sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of=20 PROUVOST Sebastien RD-CORE-ISS
Sent: Thursday, = November 11,=20 2004 8:44 AM
To: Barnes, Mary [NGC:B601:EXCH]; GARCIN = Sebastien=20 RD-CORE-ISS; Jesske, R; sip@ietf.org
Subject: RE: [Sip] = Privacy=20 statements and=20 History(draft-ietf-sip-history-info-04.txt)

Mary, Sebastien, Roland, =
 
I agree that we should let the possibility = for a proxy=20 not to remove the hi-entry even if privacy is requested and even if = the=20 request is forwarded to a Request-URI associated with a domain for = which the=20 proxy is not responsible (if there is an = agreement between=20 the domains that ensures the proxy that privacy will be = applied to the=20 request).
I suggest a text that would look = like (in=20 case privacy is requested): "the hi-entry SHOULD be removed by the = proxy=20 unless it knows that it can rely on a downstream privacy service to = apply=20 the requested privacy ".
 
Sebastien.

De : sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] De la part de Mary=20 Barnes
Envoy=E9 : mercredi 10 novembre 2004=20 19:54
=C0 : GARCIN Sebastien RD-CORE-ISS; Jesske, R; = sip@ietf.org
Objet : RE: [Sip] Privacy statements = and History=20 (draft-ietf-sip-history-info-04.txt)

I still contend that the SHOULD is = sufficient.  SHOULD=20 means that in general processing, if the hi-entry has a privacy = header, then=20 the usual processing would be that it would be removed (i.e it was = added for=20 a specific reason and in general should be used to remove the = entries based=20 on well defined criteria).  If there are reasons, such as = local policy,=20 that would allow the forwarding in specific cases, then it's okay = that it is=20 forwarded.  I think the use of MAY results in less precision = and I=20 think the value and critera for associating and removing the = privacy header=20 with the hi-entry becomes much less clear. 

I'd like to hear more opinions on this topic, = prior to=20 agreeing to making the change (from the MUST to MAY rather than = MUST to=20 SHOULD).

Regards,
Mary =


-----Original Message-----
From:=20 GARCIN Sebastien RD-CORE-ISS [mailto:sebastien.garc= in@francetelecom.com]=20
Sent: Wednesday, November 10, 2004 12:28 = PM=20
To: Barnes, Mary [NGC:B601:EXCH]; Jesske, R;=20 sip@ietf.org
Cc:=20 VL-T-Com-T-TE332@vli.telekom.de
Subject: = RE: [Sip]=20 Privacy statements and History = (draft-ietf-sip-history-info-04.txt)=20


Mary and roland,

Actually, the statement regarding the forwarding = of=20 hi-entries beyond the domain for which the proxy is responsible = should=20 rather be a matter of local policy and thus a MAY should be used = instead of=20 SHOULD. We are potentially dealing with network boundaries where = agreements=20 for forwarding such kind information can be reached.

Section 4.3.3.1.1
This = section=20 should be re-reworded in accordance with the statement above (I can = provide=20 some text is we can agree).

Section 4.3.3.1 is ok (apologies for not being=20 explicit)

Best regards,
s=E9bastien

=

           &nb= sp;           &nb= sp;        

       =20        =20        =20         ------Remainder of=20 thread has been deleted by=20 Mary------------------


------_=_NextPart_001_01C4D078.44EEDFD8-- --===============1541408640== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1541408640==-- From sip-bounces@ietf.org Mon Nov 22 20:42:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18187 for ; Mon, 22 Nov 2004 20:42:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWPkL-0000Qm-5H for sip-web-archive@ietf.org; Mon, 22 Nov 2004 20:45:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWPWp-0005X5-3w; Mon, 22 Nov 2004 20:31:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWPUn-00050v-7O for sip@megatron.ietf.org; Mon, 22 Nov 2004 20:29:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17156 for ; Mon, 22 Nov 2004 20:29:27 -0500 (EST) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWPYL-0007Hx-Rf for sip@ietf.org; Mon, 22 Nov 2004 20:33:10 -0500 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id iAN1Svxg006892 for ; Tue, 23 Nov 2004 01:28:57 GMT Received: by stntimc1.neustar.com with Internet Mail Service (5.5.2657.72) id ; Mon, 22 Nov 2004 20:28:57 -0500 Message-ID: <24EAE5D4448B9D4592C6D234CBEBD597089962@stntexch03.cis.neustar.com> From: "Peterson, Jon" To: "'sip@ietf.org'" Subject: concrete proposal (was RE: third alternative (was RE: [Sip] RE: I dentity after reinvite)) Date: Mon, 22 Nov 2004 20:28:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db In the interests of trying to get this thread strictly onto the problems with request identity, let me try to articulate the major point of contention here, and make a concrete proposal that attempts to incorporate the discussion to date. The argument has been put forward that when a request travels in the backwards direction in a dialog, it should be permissable for the remote UA to change the addr-spec element (and potentially anything other than the tag) in the From header field such that the new From header will not correspond with the To header of the dialog-forming request. This seems like an intuitive approach when a request has been retargeted, and consequently the entity identified in the To header field of the dialog-forming request is not the entity sending requests in the backwards direction (the From header field of such requests provides, in this case, the 'connected party'). RFC3261 allows the contents of the To and From headers to be altered by the parties to a dialog, with the caveat that this practice is known not to be compatible with RFC2543. An alternative argument has been made that the notion of an unanticipated 'connected party' is inherently antithetical to security, because the local UA will be forced to accept a request from any party, as the potential set of valid connected parties in unbounded. Clearly, there are a number of possible ways to attack the connected party problem, and not all of them have any impact on the sip-identity solution. The main benefit of changing the From header is that in cases of retargeting, the remote UA can thereby use the From header to provide 'connected party' information (rather than defining some new header or something). The main downside is that the local UA will receive a request within the dialog from a party other than the party to which the dialog-forming request was sent, and that accordingly, attackers can easily gain control of the dialog. In this environment, it is impossible to make any automatic authorization decision about the validity of the request, and the user of the local UA may or may not have some other means to think that the request should be authorized, based on who the connected-party is. Accordingly, the value of providing an Identity header for such requests is questionable, since it isn't clear what impersonation threat might be met by providing identity here. Really, the only possible motivation for using sip-identity in this threat model is a case where a fourth party, Eve, impersonates Edgar, anticipating that Alice knows that Edgar is an associate of Bob, and that thus, when Alice calls Bob, it would be unsurprising if Edgar answered. That begins to make my head hurt. Given that RFC3261 permits UAS's to change the From header field value (irregardless of whether or not the sip-identity mechanism is used), the question here is how should an authentication service, as defined in sip-identity, treat such requests? Should it add an Identity header, proxy them, discard them, etc? Should sip-identity recommend that the From header be changed in this manner when a request has been retargeted? Currently, sip-identity-03 is silent about dialogs and their impact, if any, on signing requests. It does say that an auth service MUST NOT provide an Identity header for the request if it is not responsible for the domain provided in the From header field of the request. Furthermore, the text suggests that if the auth service is not responsible for the domain in the >From header field, it MAY just proxy the request normally. Given all of this, let me make a concrete proposal for sip-identity-04 which attempts, for the most part, to dodge the issue of how we solve connected-party: We add some text about dialogs, and about the use of the Identity header during a dialog. Obviously, the use of identity for dialog-forming requests is a no-brainer (this is the standard 'caller-ID' assurance). Futhermore, point out that if the intended second party is actually the connected party, identity can be supplied normally in requests in the backwards direction. Stipulate that an auth service instantiated in a proxy MUST Record-Route itself in a dialog-forming request, so that the auth service can recognize a mid-dialog request. The Identity header simply would not be provided if the connected party is different from the party to which the local UA sent the request. We keep the MUST NOT for providing the Identity header in cases where the auth service is not responsible for the domain in the From header field, but upgrade the normative strength of the proxying MAY to STRONGLY RECOMMENDED (if the auth service does not proxy in this instance, failures of basic SIP operations can occur). This way, if an auth service in the request path sees a backwards-direction request, and knows that it is mid-dialog, it can just proxy the request normally if it is not responsible for the domain in question. Provide no recommendation that the From header field should be changed to reflect the 'connected party' when the Identity mechanism is used; in fact, RECOMMEND against doing so. Provide a reference to future work on this 'connected-party' problem. Anyone unhappy with that? Jon Peterson NeuStar, Inc. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 22 20:49:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18665 for ; Mon, 22 Nov 2004 20:49:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWPrQ-0001EG-HR for sip-web-archive@ietf.org; Mon, 22 Nov 2004 20:52:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWPWq-0005XD-3t; Mon, 22 Nov 2004 20:31:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWPVq-0005Bf-Fc for sip@megatron.ietf.org; Mon, 22 Nov 2004 20:30:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17221 for ; Mon, 22 Nov 2004 20:30:33 -0500 (EST) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWPZP-0007Il-Hm for sip@ietf.org; Mon, 22 Nov 2004 20:34:15 -0500 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id iAN1Tvxg006917; Tue, 23 Nov 2004 01:29:57 GMT Received: by stntimc1.neustar.com with Internet Mail Service (5.5.2657.72) id ; Mon, 22 Nov 2004 20:29:58 -0500 Message-ID: <24EAE5D4448B9D4592C6D234CBEBD597089963@stntexch03.cis.neustar.com> From: "Peterson, Jon" To: "'David R Oran'" Subject: RE: third alternative (was RE: [Sip] RE: Identity after reinvite) Date: Mon, 22 Nov 2004 20:29:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 1.1 (+) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: "'Cullen Jennings'" , "'sip@ietf.org'" , "'Paul Kyzivat'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 A few notes on the "Monica property": as RFC3323 suggests, I think that some sort of anonymization service, which could be instantiated by a B2BUA, is an appropriate way to conceal the identity of a called or calling party. What scares me a little is the way people suggest that retargeting, as opposed to redirection, can inherently be expected to provide privacy. When I register a contact, I can't always guarantee that the location service in question will be used exclusively for retargeting rather than redirection; moreover, the revelation of the target Request-URI to the caller is not the only way that the caller can learn who the connected-party is: contact headers of new requests in the backwards direction of the dialog, SDP in a 200 OK, and so on, are information leaks that are not addressed at all by retargeting, but would be addressed by an anonymization service. RFC3323 is about due for an update, I think, because the major functions that it provides can be performed without a B2BUA, thanks to new SIP mechanisms like GRUUs and session-policy. So while I agree that an anonymization service is the right approach to this problem, these days I think you can probably build an anonymization service without building a B2BUA. Finally, I think RFC3323 plays well with redirection. In fact, one can redirect to a URI like "sip:anonymous0013@anonymizer.com", and the caller can be satisfied, when they see new requests in the backwards direction, that they are talking to the entity that the original target domain wanted them to talk to. On the other hand, if my request is just retargeted to that anonymous URI without my knowledge, I'll always be left to wonder, when I see new requests in the backwards direction, if this is the person I'm supposed to be talking to... Jon Peterson NeuStar, Inc. > -----Original Message----- > From: David R Oran [mailto:oran@cisco.com] > Sent: Friday, November 19, 2004 6:30 AM > To: Peterson, Jon > Cc: 'Cullen Jennings'; 'Paul Kyzivat'; 'sip@ietf.org' > Subject: Re: third alternative (was RE: [Sip] RE: Identity after > reinvite) > > [snip] > > Redirection is generally cleaner than retargeting, but does not satisfy > the "Monica property". It may be that a B2BUA is inescapable in those > cases anyway. > > > I really think that the problem of mid-call changes in > connected-party > > is a > > very different case, and much more specialized than what we're > > concerned > > with here. We're talking here about assuring the identity > of the first > > and > > second parties to a dialog at the time of dialog establishment. I'd > > like to > > think that the ultimate solutions to the mid-call 'identity update' > > sort of > > problems are more along the transfer/replaces line of thinking. > > > I tend to agree. It would be much cleaner if all > identity/connected-party changes devolved to a flavor of transfer > (except the Monica cases I mention above). > > Dave. > > Jon Peterson > > NeuStar, Inc. > > > >> Paul > >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 23 04:09:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18219 for ; Tue, 23 Nov 2004 04:09:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWWjb-00086H-0v for sip-web-archive@ietf.org; Tue, 23 Nov 2004 04:13:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWWb1-0003Bk-Nv; Tue, 23 Nov 2004 04:04:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWWWf-0002U1-BK for sip@megatron.ietf.org; Tue, 23 Nov 2004 03:59:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16493 for ; Tue, 23 Nov 2004 03:59:51 -0500 (EST) From: kkotha@hssworld.com Received: from [61.16.168.135] (helo=hssworld.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWWaH-0006r6-KT for sip@ietf.org; Tue, 23 Nov 2004 04:03:38 -0500 Received: from pragati.blr.hss.hns.com (pragati.hss.hns.com [172.17.33.22]) by hssworld.com (8.11.6/8.11.6) with ESMTP id iAN8lq612808 for ; Tue, 23 Nov 2004 14:17:52 +0530 To: "'sip@ietf.org'" X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: Date: Tue, 23 Nov 2004 14:31:47 +0530 X-MIMETrack: Serialize by Router on Pragati/BLR/HSS(Release 6.5|September 18, 2003) at 11/23/2004 02:32:08 PM MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Subject: [Sip] openssl for IPv6 & ARES library availability X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1445041526==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e --===============1445041526== Content-type: multipart/alternative; Boundary="0__=EABBE5C6DFA207218f9e8a93df938690918cEABBE5C6DFA20721" Content-Disposition: inline --0__=EABBE5C6DFA207218f9e8a93df938690918cEABBE5C6DFA20721 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi All, Is there is any TLS version which will support IPv6 ?? [ TLS (SSL) version 9.8 which supports Ipv6, is anybody knows wher= e we can download the same ] Is there is any ARES Library (C / C++) which supports IPv6 ?? With Regards, K.Kalyana Chakravarthy, Software Engineer, Hughes Software Systems, Ph : +91 - 80 - 51067085. *********************** HSS-Unclassified *********************** "DISCLAIMER: This message is proprietary to Hughes Software Systems Lim= ited (HSS) and is intended solely for the use of the individual to whom it i= s addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it= is intended. If you have received this message in error, please notify the= originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering= , or disclosing the contents of this message. HSS accepts no responsibility = for loss or damage arising from the use of the information transmitted by t= his email including damage from virus."= --0__=EABBE5C6DFA207218f9e8a93df938690918cEABBE5C6DFA20721 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

Hi All,

Is there is any TLS version which will support IPv6 ??
[ TLS (SSL) version 9.8 which supports Ipv6, is anybody knows wher= e we can download the same ]

Is there is any ARES Library (C / C++) which supports IPv6 ??
=
With Regards,
K.Kalyana Chakravarthy,
Software Engineer,
Hughes Software Systems,
Ph : +91 - 80 - 51067085.


*********************** HSS-Unclassified ***********************
= "DISCLAIMER: This message is proprietary to Hughes Software System= s Limited (HSS) and is intended solely for the use of the individual to= whom it is addressed. It may contain privileged or confidential infor= mation and should not be circulated or used for any purpose other than = for what it is intended. If you have received this message in error, pl= ease notify the originator immediately. If you are not the intended rec= ipient, you are notified that you are strictly prohibited from using, c= opying, altering, or disclosing the contents of this message. HSS accep= ts no responsibility for loss or damage arising from the use of the inf= ormation transmitted by this email including damage from virus."= --0__=EABBE5C6DFA207218f9e8a93df938690918cEABBE5C6DFA20721-- --===============1445041526== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1445041526==-- From sip-bounces@ietf.org Tue Nov 23 10:31:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21433 for ; Tue, 23 Nov 2004 10:31:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWchF-00088o-HV for sip-web-archive@ietf.org; Tue, 23 Nov 2004 10:35:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWcRb-0007uK-9z; Tue, 23 Nov 2004 10:19:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWcJ6-000414-GM for sip@megatron.ietf.org; Tue, 23 Nov 2004 10:10:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18904 for ; Tue, 23 Nov 2004 10:10:14 -0500 (EST) Received: from sierra.rtfm.com ([198.144.203.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWcMl-0005KZ-NM for sip@ietf.org; Tue, 23 Nov 2004 10:14:05 -0500 Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by sierra.rtfm.com (Postfix) with ESMTP id B027F7415; Tue, 23 Nov 2004 07:29:09 -0800 (PST) Received: by romeo.rtfm.com (Postfix, from userid 556) id D5DF144ACF; Tue, 23 Nov 2004 07:09:43 -0800 (PST) To: kkotha@hssworld.com Subject: Re: [Sip] openssl for IPv6 & ARES library availability References: From: Eric Rescorla Date: Tue, 23 Nov 2004 07:09:43 -0800 In-Reply-To: (kkotha@hssworld.com's message of "Tue, 23 Nov 2004 14:31:47 +0530") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: "'sip@ietf.org'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 kkotha@hssworld.com writes: > Is there is any TLS version which will support IPv6 ?? TLS doesn't care which version of IP it runs on, and most implementations of TLS let you form your own socket and just hand it to the TLS engine. -Ekr _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 23 11:08:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25408 for ; Tue, 23 Nov 2004 11:08:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWdH5-0004zd-9a for sip-web-archive@ietf.org; Tue, 23 Nov 2004 11:12:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWcyx-0008Ji-Sm; Tue, 23 Nov 2004 10:53:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWcrq-00065m-80 for sip@megatron.ietf.org; Tue, 23 Nov 2004 10:46:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23266 for ; Tue, 23 Nov 2004 10:46:07 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWcvW-0001iT-HG for sip@ietf.org; Tue, 23 Nov 2004 10:49:59 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 23 Nov 2004 08:51:18 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iANFjU9N013280; Tue, 23 Nov 2004 07:45:31 -0800 (PST) Received: from [10.32.245.156] (stealth-10-32-245-156.cisco.com [10.32.245.156]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id iANFjC2i027317; Tue, 23 Nov 2004 07:45:25 -0800 In-Reply-To: <24EAE5D4448B9D4592C6D234CBEBD597089962@stntexch03.cis.neustar.com> References: <24EAE5D4448B9D4592C6D234CBEBD597089962@stntexch03.cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v619) Message-Id: From: David R Oran Subject: Re: concrete proposal (was RE: third alternative (was RE: [Sip] RE: I dentity after reinvite)) Date: Tue, 23 Nov 2004 10:45:10 -0500 To: "Peterson, Jon" X-Pgp-Agent: GPGMail 1.0.2 X-Mailer: Apple Mail (2.619) IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1101224730.807405"; x:"432200"; a:"rsa-sha1"; b:"nofws:8938"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"dsnVkl9YLyP6o4sKjC5aM/IESdZmys9Hr3/PI+AZ7hqU+bqQjoQnnoPplaJQN" "i+QtqAxZrL2yQPmFQI8nGkFY0fjVbCvroncqs2LCIJrnq5T+k1/DQl64fgZ2k" "Nwd2G89kDcDZG/quXlrhR6TOLwoXyxYl+qEvIdEDm/x+FpDu4="; c:"From: David R Oran "; c:"Subject: Re: concrete proposal (was RE: third alternative (was RE: [Si" "p] RE: I dentity after reinvite))"; c:"Date: Tue, 23 Nov 2004 10:45:10 -0500" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Cc: "'sip@ietf.org'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0740539674==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 --===============0740539674== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-3-510942898" --Apple-Mail-3-510942898 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Nov 22, 2004, at 8:28 PM, Peterson, Jon wrote: > > In the interests of trying to get this thread strictly onto the > problems > with request identity, let me try to articulate the major point of > contention here, and make a concrete proposal that attempts to > incorporate > the discussion to date. > Thanks, this is a useful and cogent description/context for figuring out what the options are. > The argument has been put forward that when a request travels in the > backwards direction in a dialog, it should be permissable for the > remote UA > to change the addr-spec element (and potentially anything other than > the > tag) in the From header field such that the new From header will not > correspond with the To header of the dialog-forming request. This > seems like > an intuitive approach when a request has been retargeted, and > consequently > the entity identified in the To header field of the dialog-forming > request > is not the entity sending requests in the backwards direction (the From > header field of such requests provides, in this case, the 'connected > party'). RFC3261 allows the contents of the To and From headers to be > altered by the parties to a dialog, with the caveat that this practice > is > known not to be compatible with RFC2543. > > An alternative argument has been made that the notion of an > unanticipated > 'connected party' is inherently antithetical to security, because the > local > UA will be forced to accept a request from any party, as the potential > set > of valid connected parties in unbounded. > This is true only in the absence of explicit delegation. At the risk of skipping ahead of your well-done chain of logic here, I think that we have in SIP a large number of scenarios (retargeting, REFER, Third-party control) where in the absence of explicit delegation we either (a) have no security, (b) force cooperating parties to use impersonation, or (c) in some cases, can rely on transitivity properties. Despite the complexity, we may be better off tackling the delegation problem now rather than allowing half-assed things to use/abuse the identity stuff because it solves a part of the problem (albeit a large part), but not enough. > Clearly, there are a number of possible ways to attack the connected > party > problem, and not all of them have any impact on the sip-identity > solution. > The main benefit of changing the From header is that in cases of > retargeting, the remote UA can thereby use the From header to provide > 'connected party' information (rather than defining some new header or > something). The main downside is that the local UA will receive a > request > within the dialog from a party other than the party to which the > dialog-forming request was sent, and that accordingly, attackers can > easily > gain control of the dialog. Unless the retarget is explicitly delegated... > In this environment, it is impossible to make > any automatic authorization decision about the validity of the > request, and > the user of the local UA may or may not have some other means to think > that > the request should be authorized, based on who the connected-party is. Impossible is a bit too strong, but the general case of retargeting does have this problem. > Accordingly, the value of providing an Identity header for such > requests is > questionable, since it isn't clear what impersonation threat might be > met by > providing identity here. Questionable only if it is not extended to allow SAML or some other explicit means of delegation. > Really, the only possible motivation for using > sip-identity in this threat model is a case where a fourth party, Eve, > impersonates Edgar, anticipating that Alice knows that Edgar is an > associate > of Bob, and that thus, when Alice calls Bob, it would be unsurprising > if > Edgar answered. That begins to make my head hurt. > For the 1-degree transitive closure of buddy-lists this does not make my head hurt and in fact might be quite natural in many IM and push-to-talk style-applications. For arbitrary n-degrees-of-separation scenarios I agree with you completely. > Given that RFC3261 permits UAS's to change the From header field value > (irregardless of whether or not the sip-identity mechanism is used), > the > question here is how should an authentication service, as defined in > sip-identity, treat such requests? Should it add an Identity header, > proxy > them, discard them, etc? Should sip-identity recommend that the From > header > be changed in this manner when a request has been retargeted? > It would be nice if the identity service did not have to be context aware and just signed identity headers for any request from a source it was authoritative for. Unless I misunderstand you I think you are contemplating the identity service being authz policy aware, and my intuition tells me that's a bad idea. > Currently, sip-identity-03 is silent about dialogs and their impact, > if any, > on signing requests. It does say that an auth service MUST NOT provide > an > Identity header for the request if it is not responsible for the domain > provided in the From header field of the request. Furthermore, the text > suggests that if the auth service is not responsible for the domain in > the >> From header field, it MAY just proxy the request normally. > This seems simple and keep the identity service out of authz policy. > Given all of this, let me make a concrete proposal for sip-identity-04 > which > attempts, for the most part, to dodge the issue of how we solve > connected-party: > > We add some text about dialogs, and about the use of the Identity > header > during a dialog. Obviously, the use of identity for dialog-forming > requests > is a no-brainer (this is the standard 'caller-ID' assurance). > Futhermore, > point out that if the intended second party is actually the connected > party, > identity can be supplied normally in requests in the backwards > direction. > Stipulate that an auth service instantiated in a proxy MUST > Record-Route > itself in a dialog-forming request, so that the auth service can > recognize a > mid-dialog request. > I think I understand what you mean here, but the words could be better. I think you are saying that "if a sip server acts as an auth service and proxies a request that it auth'ed itself, it MUST record route". > The Identity header simply would not be provided if the connected > party is > different from the party to which the local UA sent the request. Why? If the auth service can authenticate the From in the request, why should it refuse to do so? > We keep the > MUST NOT for providing the Identity header in cases where the auth > service > is not responsible for the domain in the From header field, but > upgrade the > normative strength of the proxying MAY to STRONGLY RECOMMENDED (if the > auth > service does not proxy in this instance, failures of basic SIP > operations > can occur). This way, if an auth service in the request path sees a > backwards-direction request, and knows that it is mid-dialog, it can > just > proxy the request normally if it is not responsible for the domain in > question. > > Provide no recommendation that the From header field should be changed > to > reflect the 'connected party' when the Identity mechanism is used; in > fact, > RECOMMEND against doing so. Provide a reference to future work on this > 'connected-party' problem. > > Anyone unhappy with that? > Modulo my one issue above, I'm ok with the identity part, but as I mentioned, doing just this doesn't actually solve anything other than getting identity done (which is laudable and necessary). I don't want to slow identity down UNLESS there's reason to believe we will have backward compatibility problems when we introduce delegation, OR we think that identity will get abused or ignored because too many real-world situations really need delegation. Dave. David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran@cisco.com > Jon Peterson > NeuStar, Inc. --Apple-Mail-3-510942898 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFBo1sHjWaEtlTdKuYRArPRAJ9BVHpoTsrljOOFpzLbG41x8IAjjgCfVBTr NJmqgtafto2tV1wRZtw50NI= =StL3 -----END PGP SIGNATURE----- --Apple-Mail-3-510942898-- --===============0740539674== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0740539674==-- From sip-bounces@ietf.org Tue Nov 23 13:17:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05390 for ; Tue, 23 Nov 2004 13:17:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWfIN-0005Md-05 for sip-web-archive@ietf.org; Tue, 23 Nov 2004 13:21:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWfB9-0003PH-OV; Tue, 23 Nov 2004 13:14:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWf4E-0001fL-A3 for sip@megatron.ietf.org; Tue, 23 Nov 2004 13:07:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04730 for ; Tue, 23 Nov 2004 13:07:02 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWf7w-0003pG-2D for sip@ietf.org; Tue, 23 Nov 2004 13:10:56 -0500 Received: from [63.110.3.165] ([64.100.183.165]) (authenticated bits=0) by nylon.softarmor.com (8.12.11/8.12.11) with ESMTP id iANI7Tqq030564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 23 Nov 2004 12:07:37 -0600 Message-ID: <41A37C24.8030006@softarmor.com> Date: Tue, 23 Nov 2004 12:06:28 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'sip@ietf.org'" References: <24EAE5D4448B9D4592C6D234CBEBD597089962@stntexch03.cis.neustar.com> In-Reply-To: <24EAE5D4448B9D4592C6D234CBEBD597089962@stntexch03.cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Subject: [Sip] Does retargeting belong on the list of Evil SIP Ideas? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit I try to keep a running list of things that turned out to be a royal pain that needs (or needed) fixing. Some of these things sounded cool at first, and I championed them. Others I never did like. Some of these things I'm not allowed to suggest deprecating anymore -- we took a hum on forking a few meetings back. One of these days I'm going to get this list better organized and post it someplace more persistent in the hope that it may assist in avoiding repeptition of mistakes. And someday, perhaps we can do something about some of these quirks. To-date, I believe the Evil List includes: 1) Replacing the Request-URI at each hop while routing was Evil. We fixed this with Loose Routing mode, which is still slightly Evil. 2) Abusing To and From to indicate branches is Evil. We should have left these as real endpoint identifiers. 3) Forking is Evil. 4) Allowing (and requiring) responses to carry a payload with more meaning than "I acknowledge having received that request" is Evil. Since we can't reject a response, we can't deal with big responses and can't negotiate what they carry. Acknowledgement and response are different beasties -- one is transport, the other is application, and we need to understand the difference. 5) The three-message INVITE transaction model and its dependence on payload in the response is Evil. 6) The two-message non-INVITE transaction model and its interaction with retransmission and hop-by-hop cascade (See Sparks' non-invite analysis) is Evil. 7) Building transport state and reliability into the application state and requiring a transport protocol extension for every new application semantic is Evil. 8) Using z9hG4bK on via fields rather than a negotiated mechanism (like maybe a version) is Evil. 9) Jon argues that not requiring SIPS to be end-to-end is Evil. I think the jury is still out on this one, but we're still deliberating. 10) Provisional responses, as currently constructed, whether reliable or non-relaible, are Evil. This may be redundant with the NIT discussion. 11) I believe I'm coming to believe that "retargeting", i.e. changing a request in a proxy such that the entity to which it is delivered has a different assertable identity than the identity to which the request was originally addressed, is Evil. Perhaps it could be mitigated by a assertion of transitivity: "I, the proxy identified herein, do assert that I have altered the target of this request according to local policy, and you can either deal with it or go away." Oh wait, that's the 302 response . . . Perhaps this is redundant with "Forking is evil" as forking is just a special case of retargeting. Or perhaps forking and retargeting are both special cases of "exploders" and could both be dealt with using the consent framework . . . Sometimes I wonder if the use of UDP was fundamentally Evil. If I've missed something blatantly Evil, please comment back, and I may add it to the list I hope to post someplace. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 23 16:39:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06886 for ; Tue, 23 Nov 2004 16:39:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWiR9-0002EZ-4u for sip-web-archive@ietf.org; Tue, 23 Nov 2004 16:43:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWiAR-0005Ux-Lv; Tue, 23 Nov 2004 16:25:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWhgH-0002y9-Cg for sip@megatron.ietf.org; Tue, 23 Nov 2004 15:54:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26659 for ; Tue, 23 Nov 2004 15:54:31 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWhjz-0002HS-FU for sip@ietf.org; Tue, 23 Nov 2004 15:58:25 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 23 Nov 2004 14:00:16 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iANKsP9N016056; Tue, 23 Nov 2004 12:54:26 -0800 (PST) Received: from cisco.com ([161.44.79.125]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ANG26155; Tue, 23 Nov 2004 15:54:26 -0500 (EST) Message-ID: <41A3A382.8070107@cisco.com> Date: Tue, 23 Nov 2004 15:54:26 -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: David R Oran Subject: Re: concrete proposal (was RE: third alternative (was RE: [Sip] RE: I dentity after reinvite)) References: <24EAE5D4448B9D4592C6D234CBEBD597089962@stntexch03.cis.neustar.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: "'sip@ietf.org'" , "Peterson, Jon" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit I generally agree with Jon and Dave. I've snipped to something I want to comment on. Paul David R Oran wrote: > > On Nov 22, 2004, at 8:28 PM, Peterson, Jon wrote: > >> We add some text about dialogs, and about the use of the Identity header >> during a dialog. Obviously, the use of identity for dialog-forming >> requests >> is a no-brainer (this is the standard 'caller-ID' assurance). Futhermore, >> point out that if the intended second party is actually the connected >> party, >> identity can be supplied normally in requests in the backwards direction. >> Stipulate that an auth service instantiated in a proxy MUST Record-Route >> itself in a dialog-forming request, so that the auth service can >> recognize a >> mid-dialog request. >> > I think I understand what you mean here, but the words could be better. > I think you are saying that "if a sip server acts as an auth service and > proxies a request that it auth'ed itself, it MUST record route". In the general case the two ends of the call are in different domains, and so there need to be two auth servers. The initial call setup (from Alice to Bob) presumably transits Alice's auth server so that it can be signed. Jon's requirement above would require *it* to record route. That might be a good thing, so that subsequent requests from Alice can also be signed. But that does nothing for requests from Bob to Alice. There is no guarantee that Bob's auth server is in the path for incoming requests from Alict to Bob. Based on the needs of Identity-03 there is no need for it to be. If it happened to be, then the requirement that it record-route might be helpful in giving it the opportunity to sign future outbound requests in the dialog. If it wasn't in the path initially, then Bob will have to add a Route header, in addition to what is received in Record-Route, to involve it when sending subsequent requests within the dialog. It seems to me that depending on how the network components are constructed, either the auth server will be collocated with a component that is naturally on the path, or else each end will have to manipulate the Route headers to ensure it is. (It would naturally be on the path if it was collocated with teh proxy managing the user's AOR and the user uses a GRUU managed by the same proxy for contacts.) Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 23 16:45:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07853 for ; Tue, 23 Nov 2004 16:45:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWiXU-00036K-9p for sip-web-archive@ietf.org; Tue, 23 Nov 2004 16:49:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWiMo-0007Bd-HS; Tue, 23 Nov 2004 16:38:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWi9l-0004q5-5k for sip@megatron.ietf.org; Tue, 23 Nov 2004 16:25:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04642 for ; Tue, 23 Nov 2004 16:24:58 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWiDU-0008Qh-EI for sip@ietf.org; Tue, 23 Nov 2004 16:28:53 -0500 Received: from [192.168.1.216] (c-24-1-66-77.client.comcast.net [24.1.66.77]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iANLOcgs053095 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 23 Nov 2004 15:24:38 -0600 (CST) (envelope-from rjsparks@nostrum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <13719E43-3D96-11D9-93B0-000D93326732@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] PING/PONG Date: Tue, 23 Nov 2004 15:24:36 -0600 To: "Steve Langstaff" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.1 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Christian Stredicke X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: 7bit This conversation just got too loose with its terminology for me. 3261 proxies have a UAS core. Endpoints behind the things we are wanting to do this refresh things to can be signaling directly with endpoints that aren't (a service provider could let people talk to voice-mail or conference servers directly). While the long-lived client-to-service-provider-proxy connection is a good example to use for motivation, I would prefer that we ensure we build something that works in general. The DNS solution would work for those the services I call out above. I'm not yet sure if its the right way to go. I can see a use for being able to signal (or at least detect) support for this kind of keep-alive between ephemeral endpoints too. RjS On Nov 18, 2004, at 5:14 AM, Steve Langstaff wrote: > Sorry, I didn't realise the scope of this discussion was > client-to-proxy - that's where my confusion lay. > > A further question from my (simplistic) viewpoint... If this issue > is/could be generic to all STUNned traffic (not just sip+stun), would > it not be better to push the problem down into the STUN 'layer' and > let the STUN client and server sort out keeping the NAT bindings > alive? I'm guessing that the SIP client already 'knows' it has to use > STUN to reach the proxy, and so could ask it's STUN client to keep the > binding(s) alive as appropriate. > > > -- > Steve Langstaff. > > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: 18 November 2004 04:46 > To: Steve Langstaff > Cc: Christian Stredicke; sip@ietf.org > Subject: Re: [Sip] PING/PONG > > > There isn't a UAS involved here; these requests go from the client > (UAC) > to its proxy. > > How the proxy indicates to the UAC that it is capable of processing > these keepalives is a good question. My first thought is that this > would > be something in DNS; a new service in the NAPTR record for indicating > the sip+stun combination. > > -Jonathan R. > > Steve Langstaff wrote: > >> Should point 2 read "The user agent server indicates if it can >> respond to client refresh requests"? >> >> -- >> Steve Langstaff. >> >> >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of >> Jonathan Rosenberg >> Sent: 17 November 2004 16:40 >> To: Christian Stredicke >> Cc: sip@ietf.org >> Subject: Re: [Sip] PING/PONG >> >> >> >> >> Christian Stredicke wrote: >> >> >>> So my understanding is: >>> >>> 1. We should use *only* STUN for refreshing bindings (either UDP or >>> TCP, >>> what about TLS) >> >> >> Yes, TLS too. TLS runs ontop of TCP after all. >> >> >>> 2. The user agent indicates if it can do it (no negotiation on >>> capabilities) >>> >>> 3. Refreshing must be done from the client >>> >>> Can we agree on that? >> >> >> Yes. >> >> Server originating refreshing is in the wrong direction. It is the >> client utilizing the service; if it wishes to make use of that >> service, >> it has to be responsible for refreshing the connection. >> >> -Jonathan R. >> > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 23 17:02:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11214 for ; Tue, 23 Nov 2004 17:02:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWinL-0005ap-S9 for sip-web-archive@ietf.org; Tue, 23 Nov 2004 17:05:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWiRZ-0001fO-N8; Tue, 23 Nov 2004 16:43:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWiGy-0001hO-Ec for sip@megatron.ietf.org; Tue, 23 Nov 2004 16:32:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05472 for ; Tue, 23 Nov 2004 16:32:25 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWiKi-0001Ej-0N for sip@ietf.org; Tue, 23 Nov 2004 16:36:20 -0500 Received: from [192.168.1.216] (c-24-1-66-77.client.comcast.net [24.1.66.77]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iANLWF6O053796 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 23 Nov 2004 15:32:16 -0600 (CST) (envelope-from rjsparks@nostrum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <246703B6-3D97-11D9-93B0-000D93326732@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] openssl for IPv6 & ARES library availability Date: Tue, 23 Nov 2004 15:32:14 -0600 To: kkotha@hssworld.com X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: "'sip@ietf.org'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Work has been done on ARES in resiprocate/contrib to support v6 DNS servers (and AAAA records from both v4 and v6 servers). See http://www.sipfoundry.org/reSIProcate/index.html RjS On Nov 23, 2004, at 3:01 AM, kkotha@hssworld.com wrote: > Hi All, > > Is there is any TLS version which will support IPv6 ?? > [ TLS (SSL) version 9.8 which supports Ipv6, is anybody knows where > we can download the same ] > > Is there is any ARES Library (C / C++) which supports IPv6 ?? > > With Regards, > K.Kalyana Chakravarthy, > Software Engineer, > Hughes Software Systems, > Ph : +91 - 80 - 51067085. > > > *********************** HSS-Unclassified *********************** > "DISCLAIMER: This message is proprietary to Hughes Software Systems > Limited (HSS) and is intended solely for the use of the individual to > whom it is addressed. It may contain privileged or confidential > information and should not be circulated or used for any purpose other > than for what it is intended. If you have received this message in > error, please notify the originator immediately. If you are not the > intended recipient, you are notified that you are strictly prohibited > from using, copying, altering, or disclosing the contents of this > message. HSS accepts no responsibility for loss or damage arising from > the use of the information transmitted by this email including damage > from virus." > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 23 17:03:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11408 for ; Tue, 23 Nov 2004 17:03:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWiob-0005e7-4m for sip-web-archive@ietf.org; Tue, 23 Nov 2004 17:07:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWiTM-0002ag-Ew; Tue, 23 Nov 2004 16:45:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWiJV-0004uQ-01 for sip@megatron.ietf.org; Tue, 23 Nov 2004 16:35:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06208 for ; Tue, 23 Nov 2004 16:35:02 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWiNE-0001Pn-Q3 for sip@ietf.org; Tue, 23 Nov 2004 16:38:57 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 23 Nov 2004 16:34:34 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iANLYVgl029506; Tue, 23 Nov 2004 16:34:32 -0500 (EST) Received: from cisco.com ([161.44.79.125]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ANG29925; Tue, 23 Nov 2004 16:34:31 -0500 (EST) Message-ID: <41A3ACE7.5000102@cisco.com> Date: Tue, 23 Nov 2004 16:34:31 -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: Dean Willis Subject: Re: [Sip] Does retargeting belong on the list of Evil SIP Ideas? References: <24EAE5D4448B9D4592C6D234CBEBD597089962@stntexch03.cis.neustar.com> <41A37C24.8030006@softarmor.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Cc: "'sip@ietf.org'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit Dean, Rather that the "list of Evil SIP Ideas", I propose this be called the "axis of Evil SIP Ideas". Paul Dean Willis wrote: > > I try to keep a running list of things that turned out to be a royal > pain that needs (or needed) fixing. Some of these things sounded cool at > first, and I championed them. Others I never did like. Some of these > things I'm not allowed to suggest deprecating anymore -- we took a hum > on forking a few meetings back. One of these days I'm going to get this > list better organized and post it someplace more persistent in the hope > that it may assist in avoiding repeptition of mistakes. And someday, > perhaps we can do something about some of these quirks. > > To-date, I believe the Evil List includes: > > 1) Replacing the Request-URI at each hop while routing was Evil. We > fixed this with Loose Routing mode, which is still slightly Evil. > > 2) Abusing To and From to indicate branches is Evil. We should have left > these as real endpoint identifiers. > > 3) Forking is Evil. > > 4) Allowing (and requiring) responses to carry a payload with more > meaning than "I acknowledge having received that request" is Evil. Since > we can't reject a response, we can't deal with big responses and can't > negotiate what they carry. Acknowledgement and response are different > beasties -- one is transport, the other is application, and we need to > understand the difference. > > 5) The three-message INVITE transaction model and its dependence on > payload in the response is Evil. > > 6) The two-message non-INVITE transaction model and its interaction with > retransmission and hop-by-hop cascade (See Sparks' non-invite analysis) > is Evil. > > 7) Building transport state and reliability into the application state > and requiring a transport protocol extension for every new application > semantic is Evil. > > 8) Using z9hG4bK on via fields rather than a negotiated mechanism (like > maybe a version) is Evil. > > 9) Jon argues that not requiring SIPS to be end-to-end is Evil. I think > the jury is still out on this one, but we're still deliberating. > > 10) Provisional responses, as currently constructed, whether reliable or > non-relaible, are Evil. This may be redundant with the NIT discussion. > > 11) I believe I'm coming to believe that "retargeting", i.e. changing > a request in a proxy such that the entity to which it is delivered has > a different assertable identity than the identity to which the request > was originally addressed, is Evil. Perhaps it could be mitigated by a > assertion of transitivity: "I, the proxy identified herein, do assert > that I have altered the target of this request according to local > policy, and you can either deal with it or go away." Oh wait, that's the > 302 response . . . Perhaps this is redundant with "Forking is evil" as > forking is just a special case of retargeting. Or perhaps forking and > retargeting are both special cases of "exploders" and could both be > dealt with using the consent framework . . . > > Sometimes I wonder if the use of UDP was fundamentally Evil. > > If I've missed something blatantly Evil, please comment back, and I may > add it to the list I hope to post someplace. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 23 17:46:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15396 for ; Tue, 23 Nov 2004 17:46:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWjUG-0003CH-JU for sip-web-archive@ietf.org; Tue, 23 Nov 2004 17:50:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWjNX-0000Ma-Eg; Tue, 23 Nov 2004 17:43:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWjA8-0004e8-JX for sip@megatron.ietf.org; Tue, 23 Nov 2004 17:29:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13766 for ; Tue, 23 Nov 2004 17:29:25 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWjDs-00019q-Jz for sip@ietf.org; Tue, 23 Nov 2004 17:33:21 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 23 Nov 2004 14:32:13 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iANMSs9h015583; Tue, 23 Nov 2004 14:28:55 -0800 (PST) Received: from [10.32.245.156] (stealth-10-32-245-156.cisco.com [10.32.245.156]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id iANMSd3Z030588; Tue, 23 Nov 2004 14:28:45 -0800 In-Reply-To: <41A3ACE7.5000102@cisco.com> References: <24EAE5D4448B9D4592C6D234CBEBD597089962@stntexch03.cis.neustar.com> <41A37C24.8030006@softarmor.com> <41A3ACE7.5000102@cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <033E41F4-3D9F-11D9-8CD3-000A95C73842@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [Sip] Does retargeting belong on the list of Evil SIP Ideas? Date: Tue, 23 Nov 2004 17:28:34 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.619) IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1101248932.23649"; x:"432200"; a:"rsa-sha1"; b:"nofws:4236"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"aemMB06Ts70HnvtgruAsQ2cq36IcTQzWyHxGC3K4CxjlX2M4lQHXXBdPh6icD" "+0b7jbrUKTF72XTv+YFwmWxgN1qp4Srwz2cGmcHl+MsY5DOagr03uUB+Nw5jM" "WjklDhJrvln75ytCCJK6Xq7qlcwM+0xm+lHN7l84asv3h+IdU="; c:"From: David R Oran "; c:"Subject: Re: [Sip] Does retargeting belong on the list of Evil SIP Ide" "as?"; c:"Date: Tue, 23 Nov 2004 17:28:34 -0500" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit Cc: "'sip@ietf.org'" , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit Boy do you guys ever have axis to grind! On Nov 23, 2004, at 4:34 PM, Paul Kyzivat wrote: > Dean, > > Rather that the "list of Evil SIP Ideas", I propose this be called the > "axis of Evil SIP Ideas". > > Paul > > Dean Willis wrote: >> I try to keep a running list of things that turned out to be a royal >> pain that needs (or needed) fixing. Some of these things sounded cool >> at first, and I championed them. Others I never did like. Some of >> these things I'm not allowed to suggest deprecating anymore -- we >> took a hum on forking a few meetings back. One of these days I'm >> going to get this list better organized and post it someplace more >> persistent in the hope that it may assist in avoiding repeptition of >> mistakes. And someday, perhaps we can do something about some of >> these quirks. >> To-date, I believe the Evil List includes: >> 1) Replacing the Request-URI at each hop while routing was Evil. We >> fixed this with Loose Routing mode, which is still slightly Evil. >> 2) Abusing To and From to indicate branches is Evil. We should have >> left these as real endpoint identifiers. >> 3) Forking is Evil. >> 4) Allowing (and requiring) responses to carry a payload with more >> meaning than "I acknowledge having received that request" is Evil. >> Since we can't reject a response, we can't deal with big responses >> and can't negotiate what they carry. Acknowledgement and response are >> different beasties -- one is transport, the other is application, and >> we need to understand the difference. >> 5) The three-message INVITE transaction model and its dependence on >> payload in the response is Evil. >> 6) The two-message non-INVITE transaction model and its interaction >> with retransmission and hop-by-hop cascade (See Sparks' non-invite >> analysis) is Evil. >> 7) Building transport state and reliability into the application >> state and requiring a transport protocol extension for every new >> application semantic is Evil. >> 8) Using z9hG4bK on via fields rather than a negotiated mechanism >> (like maybe a version) is Evil. >> 9) Jon argues that not requiring SIPS to be end-to-end is Evil. I >> think the jury is still out on this one, but we're still >> deliberating. >> 10) Provisional responses, as currently constructed, whether reliable >> or non-relaible, are Evil. This may be redundant with the NIT >> discussion. >> 11) I believe I'm coming to believe that "retargeting", i.e. >> changing a request in a proxy such that the entity to which it is >> delivered has a different assertable identity than the identity to >> which the request was originally addressed, is Evil. Perhaps it >> could be mitigated by a assertion of transitivity: "I, the proxy >> identified herein, do assert that I have altered the target of this >> request according to local policy, and you can either deal with it or >> go away." Oh wait, that's the 302 response . . . Perhaps this is >> redundant with "Forking is evil" as forking is just a special case of >> retargeting. Or perhaps forking and retargeting are both special >> cases of "exploders" and could both be dealt with using the consent >> framework . . . >> Sometimes I wonder if the use of UDP was fundamentally Evil. >> If I've missed something blatantly Evil, please comment back, and I >> may add it to the list I hope to post someplace. >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP 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 > David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran@cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 23 21:09:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02463 for ; Tue, 23 Nov 2004 21:09:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWmel-0004Yx-J5 for sip-web-archive@ietf.org; Tue, 23 Nov 2004 21:13:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWmX0-0007m4-3u; Tue, 23 Nov 2004 21:05:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWmV5-0007Jx-Em for sip@megatron.ietf.org; Tue, 23 Nov 2004 21:03:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01987 for ; Tue, 23 Nov 2004 21:03:17 -0500 (EST) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWmYr-0003mG-Ic for sip@ietf.org; Tue, 23 Nov 2004 21:07:13 -0500 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id iAO22lxg029886; Wed, 24 Nov 2004 02:02:47 GMT Received: by stntimc1.neustar.com with Internet Mail Service (5.5.2657.72) id ; Tue, 23 Nov 2004 21:02:46 -0500 Message-ID: <24EAE5D4448B9D4592C6D234CBEBD597089967@stntexch03.cis.neustar.com> From: "Peterson, Jon" To: "'David R Oran'" Subject: RE: concrete proposal (was RE: third alternative (was RE: [Sip] R E: I dentity after reinvite)) Date: Tue, 23 Nov 2004 21:02:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: "'sip@ietf.org'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 > > An alternative argument has been made that the notion of an unanticipated > > 'connected party' is inherently antithetical to security, because the local > > UA will be forced to accept a request from any party, as the potential set > > of valid connected parties in unbounded. > > > This is true only in the absence of explicit delegation. Of course, and the only reason the text above does not say so is because I was intentionally trying to phrase this in a way that is silent about the whole 'connected party' issue. As an aside, I think "explicit delegation" is a very good term for what we need here, when we get around to addressing the 'connected party' problem. > At the risk of > skipping ahead of your well-done chain of logic here, I think that we > have in SIP a large number of scenarios (retargeting, REFER, > Third-party control) where in the absence of explicit delegation we > either (a) have no security, (b) force cooperating parties to use > impersonation, or (c) in some cases, can rely on transitivity > properties. Despite the complexity, we may be better off tackling the > delegation problem now rather than allowing half-assed things to > use/abuse the identity stuff because it solves a part of the problem > (albeit a large part), but not enough. Well... that really depends on your value of "now". I think we can do request identity, frankly, without solving the explicit delegation problem. When explicit delegation is resolved, then we can describe its relevance to identity. In the interim, we can just say that the Identity header isn't supplied for requests in the backwards direction during a dialog when retargeting has occurred. Perhaps I only think this language makes sense because I believe that when we get through with the explicit delegation problem, we won't be doing "retargeting" any more as such. > > Given that RFC3261 permits UAS's to change the From header field value > > (irregardless of whether or not the sip-identity mechanism is used), the > > question here is how should an authentication service, as defined in > > sip-identity, treat such requests? Should it add an Identity header, proxy > > them, discard them, etc? Should sip-identity recommend that the From header > > be changed in this manner when a request has been retargeted? > > It would be nice if the identity service did not have to be context > aware and just signed identity headers for any request from a source it > was authoritative for. Unless I misunderstand you I think you are > contemplating the identity service being authz policy aware, and my > intuition tells me that's a bad idea. At this point in the note, anyway, I'm just contemplating the sort of questions that seem to have been asked in the thread, not endorsing any solutions. I agree with you that ideally, the auth service should just sign the requests that it can, and not sign the requests that it can't. > > > > We add some text about dialogs, and about the use of the Identity header > > during a dialog. Obviously, the use of identity for dialog-forming requests > > is a no-brainer (this is the standard 'caller-ID' assurance). Futhermore, > > point out that if the intended second party is actually the connected party, > > identity can be supplied normally in requests in the backwards direction. > > Stipulate that an auth service instantiated in a proxy MUST Record-Route > > itself in a dialog-forming request, so that the auth service can recognize a > > mid-dialog request. > > > I think I understand what you mean here, but the words could be better. > I think you are saying that "if a sip server acts as an auth service > and proxies a request that it auth'ed itself, it MUST record route". > Yes. > > The Identity header simply would not be provided if the connected party is > > different from the party to which the local UA sent the request. > Why? If the auth service can authenticate the From in the request, why > should it refuse to do so? > My language here is imprecise, yes, I mean something more like "the Identity header simply would not be provided if the auth service is not responsible for the domain of the From header field of the request." If we couple this with the further notion that changing the From header field of requests in the backwards direction within a dialog is NOT RECOMMENDED because it may surprising to the originator of the dialog, I'm cool with that. > > Anyone unhappy with that? > > > Modulo my one issue above, I'm ok with the identity part, but as I > mentioned, doing just this doesn't actually solve anything other than > getting identity done (which is laudable and necessary). Right, my ambitions are no greater than that at the moment. Once we're all on the same page here, we can start diving into the explicit delegation issue in more detail as a prelude to tackling response identity. > I don't want > to slow identity down UNLESS there's reason to believe we will have > backward compatibility problems when we introduce delegation, OR we > think that identity will get abused or ignored because too many > real-world situations really need delegation. > I'm not sure there's much potential for abuse here, and as long as we don't rule out any important use cases, it faces no more than the usual probability of being ignored. The most essential problem that people want to solve is the dialog-forming request identity problem - essentially, the "caller-ID" problem. That has immediate pay-off in the marketplace. As long as we can tackle this in a way that doesn't damage our prospects of doing more work on corner cases in the future, I think we'll be okay. Jon Peterson NeuStar, Inc. > Dave. > > David R. Oran > Cisco Fellow > Cisco Systems > 7 Ladyslipper Lane > Acton, MA 01720 USA > Tel: +1 978 264 2048 > Email: oran@cisco.com > > > Jon Peterson > > NeuStar, Inc. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 23 23:43:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12832 for ; Tue, 23 Nov 2004 23:43:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWp4C-0007p0-GO for sip-web-archive@ietf.org; Tue, 23 Nov 2004 23:47:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWowV-0003NB-4z; Tue, 23 Nov 2004 23:39:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWovA-0002yz-NY for sip@megatron.ietf.org; Tue, 23 Nov 2004 23:38:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12616 for ; Tue, 23 Nov 2004 23:38:21 -0500 (EST) From: gautam.chaudhry@wipro.com Received: from wip-ec-wd.wipro.com ([203.101.113.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWoy2-0006iv-Aa for sip@ietf.org; Tue, 23 Nov 2004 23:42:20 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 66990205BF for ; Wed, 24 Nov 2004 10:02:24 +0530 (IST) Received: from blr-ec-bh1.wipro.com (unknown [10.200.50.91]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 4D00920580 for ; Wed, 24 Nov 2004 10:02:24 +0530 (IST) Received: from blr-ec-msg04.wipro.com ([10.200.53.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 Nov 2004 10:06:49 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 24 Nov 2004 10:06:49 +0530 Message-ID: <72001BBBF6CB124BA1C40E415914E213CAE687@blr-ec-msg04.wipro.com> Thread-Topic: Please Help Thread-Index: AcTR3vDRTBRstZu7TDemyhab0Cq0xg== To: X-OriginalArrivalTime: 24 Nov 2004 04:36:49.0190 (UTC) FILETIME=[36494460:01C4D1DF] X-Spam-Score: 0.7 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Subject: [Sip] Please Help X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0648832707==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a This is a multi-part message in MIME format. --===============0648832707== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4D1DF.3639FBD4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4D1DF.3639FBD4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 let me know if a following scenario is correct. =20 Caller-A Proxy-A Proxy-B Callee-B1 Callee-B2 --INVITE--> --INVITE--> --INVITE--> (1) <--180 with To-tag1 <--180 with To-tag1 <--180 with To-tag1 (2) <--302 with Contact : Callee-B2 -----INVITE-------> =20 (3) <--180 with To-tag2-------------------=20 <--180 with To-tag2 =20 (1) Callee-B1's phone is ringing. (2) Callee-B1 decides to forward this call to Callee-B2 without accepting call. and send a 302 response with a Contact: Callee-B2 (3) Callee-B2's phone is ringing. =20 As you see, at the above flow, Proxy-A and Caller-A receive two 180 responses with a different To-tag. Caller-A created a early-dialog when it received the first 180 response and then, it received the second 180 response with a difference To-tag from the first one. at that case, what happens? should a early-dialog be updated with new To-tag? or can't Callee-B1 send a 302 response after sending a 180 response? =20 Regards Gautam Chaudhry =20 ------_=_NextPart_001_01C4D1DF.3639FBD4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,
 
let me know if a following scenario is = correct.
 
Caller-A        = Proxy-A      Proxy-B    =20 Callee-B1         =20 Callee-B2
      =20 --INVITE-->
         &= nbsp;           =20 --INVITE-->
         &= nbsp;           &n= bsp;           &nb= sp;=20 --INVITE-->
         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;        =20 (1)
           =             &= nbsp;           &n= bsp;         =20 <--180 with=20 To-tag1
          &n= bsp;           &nb= sp;    =20 <--180 with To-tag1
    <--180 with=20 To-tag1
          &n= bsp;           &nb= sp;           &nbs= p;            = ;       =20 (2)
           =             &= nbsp;           &n= bsp;         =20 <--302 with Contact :=20 Callee-B2
          =             &= nbsp;           &n= bsp;           &nb= sp; =20 -----INVITE------->
        = ;    =20
           &nb= sp;           &nbs= p;            = ;   =20 (3)
           =             &= nbsp;     =20 <--180 with To-tag2------------------- =
     =20 <--180 with To-tag2
 
(1) Callee-B1's phone is = ringing.
(2)=20 Callee-B1 decides to forward this call to Callee-B2 without accepting = call. and=20 send a 302 response with a Contact: Callee-B2
(3) Callee-B2's phone = is=20 ringing.
 
As you see, at the above flow, Proxy-A and = Caller-A=20 receive two 180 responses with a different To-tag.  Caller-A = created a=20 early-dialog when it received the first 180 response and then, it = received the=20 second 180 response with a difference To-tag from the first one. at that = case,=20 what happens? should a early-dialog be updated with new To-tag?  or = can't=20 Callee-B1 send a 302 response after sending a 180=20 response?
 

Regards

Gautam=20 Chaudhry

=
 
------_=_NextPart_001_01C4D1DF.3639FBD4-- --===============0648832707== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0648832707==-- From sip-bounces@ietf.org Wed Nov 24 01:48:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21027 for ; Wed, 24 Nov 2004 01:48:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWr0T-0006hv-Oi for sip-web-archive@ietf.org; Wed, 24 Nov 2004 01:52:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWqrP-0002cL-1j; Wed, 24 Nov 2004 01:42:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWqmw-00016J-2I for sip@megatron.ietf.org; Wed, 24 Nov 2004 01:38:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20418 for ; Wed, 24 Nov 2004 01:38:00 -0500 (EST) Received: from [203.200.4.5] (helo=serversmb.kodiaknetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWqqi-0005Ce-Ce for sip@ietf.org; Wed, 24 Nov 2004 01:41:58 -0500 Received: from Nataraju ([192.168.2.115]) by serversmb.kodiaknetworks.com (8.11.6/8.11.6) with ESMTP id iAO6ajj16677; Wed, 24 Nov 2004 12:06:46 +0530 From: "Nataraju A B" To: , Subject: RE: [Sip] Please Help Date: Wed, 24 Nov 2004 12:01:51 +0530 Message-ID: <006301c4d1ef$4906ae20$7302a8c0@Nataraju> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <72001BBBF6CB124BA1C40E415914E213CAE687@blr-ec-msg04.wipro.com> Importance: Normal X-Spam-Score: 0.3 (/) X-Scan-Signature: 22e211536bda974b2dcf811522dc525d X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0877302736==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: b612707e1a3f67df80ae89cdab1ba981 This is a multi-part message in MIME format. --===============0877302736== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0064_01C4D21D.62C13410" This is a multi-part message in MIME format. ------=_NextPart_000_0064_01C4D21D.62C13410 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Best Regards, Nataraju A.B. -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of gautam.chaudhry@wipro.com Sent: Wednesday, November 24, 2004 10:07 AM To: sip@ietf.org Subject: [Sip] Please Help Hi, let me know if a following scenario is correct. Caller-A Proxy-A Proxy-B Callee-B1 Callee-B2 --INVITE--> --INVITE--> --INVITE--> (1) <--180 with To-tag1 <--180 with To-tag1 <--180 with To-tag1 (2) <--302 with Contact : Callee-B2 -----INVITE-------> (3) <--180 with To-tag2------------------- <--180 with To-tag2 (1) Callee-B1's phone is ringing. (2) Callee-B1 decides to forward this call to Callee-B2 without accepting call. and send a 302 response with a Contact: Callee-B2 (3) Callee-B2's phone is ringing. As you see, at the above flow, Proxy-A and Caller-A receive two 180 responses with a different To-tag. Caller-A created a early-dialog when it received the first 180 response and then, it received the second 180 response with a difference To-tag from the first one. at that case, what happens? should a early-dialog be updated with new To-tag? or can't Callee-B1 send a 302 response after sending a 180 response? [ABN] if callee-B1 is retrying on 302 then 302 must not be sent to the caller. Only the response for the retried invite will be sent to caller. Caller must be prepared to receive responses with diff to-tags which lead to multiple early dialogs as part of the session. Then its SIP application logic to retain one of the confirmed dialogs. This is one of the major change from 2543 to 3261 implementation. Regards Gautam Chaudhry ------=_NextPart_000_0064_01C4D21D.62C13410 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Best Regards,

Nataraju A.B.

-----Original = Message-----
From: = sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On = Behalf Of gautam.chaudhry@wipro.com
Sent: = Wednesday, November 24, = 2004 10:07 AM
To: sip@ietf.org
Subject: [Sip] Please = Help

 

Hi,

 

let me know if a following scenario is correct.
 
Caller-A        Proxy-A      Proxy-B     Callee-B1          = Callee-B2
       --INVITE-->
            &= nbsp;         --INVITE-->
            &= nbsp;           &n= bsp;          --INVITE-->
            &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;      (1)
            &= nbsp;           &n= bsp;           &nb= sp;         <--180 with To-tag1
            &= nbsp;           &n= bsp;   <--180 with To-tag1
    <--180 with To-tag1
            &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;      (2)
            &= nbsp;           &n= bsp;           &nb= sp;         <--302 with Contact : Callee-B2
            &= nbsp;           &n= bsp;           &nb= sp;            -----INVITE------->
             =
            &= nbsp;           &n= bsp;           &nb= sp;   (3)
            &= nbsp;           &n= bsp;     <--180 with To-tag2-------------------
      <--180 with To-tag2
 
(1) Callee-B1's phone is ringing.
(2) Callee-B1 decides to forward this call to Callee-B2 without = accepting call. and send a 302 response with a Contact: Callee-B2
(3) Callee-B2's phone is ringing.
 
As you see, at the above flow, Proxy-A and Caller-A receive two 180 = responses with a different To-tag.  Caller-A created a early-dialog when it = received the first 180 response and then, it received the second 180 response = with a difference To-tag from the first one. at that case, what happens? should = a early-dialog be updated with new To-tag?  or can't Callee-B1 send a = 302 response after sending a 180 response?

 

=

 [ABN] if callee-B1 is retrying on 302 then 302 must not be sent to the caller. = Only the response for the retried invite will be sent to = caller.

Caller must be prepared to receive responses with diff to-tags which lead to multiple = early dialogs as part of the session. Then its SIP application = logic to retain one of the confirmed dialogs. This is one of the major = change from 2543 to 3261 = implementation…

 

 =

Regards

Gautam = Chaudhry

 

------=_NextPart_000_0064_01C4D21D.62C13410-- --===============0877302736== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0877302736==-- From sip-bounces@ietf.org Wed Nov 24 02:59:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24475 for ; Wed, 24 Nov 2004 02:59:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWs7M-0007Z6-6W for sip-web-archive@ietf.org; Wed, 24 Nov 2004 03:03:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWs1w-0004mH-Rb; Wed, 24 Nov 2004 02:57:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWrzv-0004Jg-NH for sip@megatron.ietf.org; Wed, 24 Nov 2004 02:55:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24177 for ; Wed, 24 Nov 2004 02:55:30 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWs3j-0006nL-Sk for sip@ietf.org; Wed, 24 Nov 2004 02:59:29 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 23 Nov 2004 23:58:19 -0800 Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iAO7sHAC005465; Tue, 23 Nov 2004 23:54:17 -0800 (PST) Received: from [192.168.1.100] (sjc-vpn1-542.cisco.com [10.21.98.30]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFY18711; Tue, 23 Nov 2004 23:54:54 -0800 (PST) Message-ID: <41A43E4D.8020102@cisco.com> Date: Wed, 24 Nov 2004 02:54:53 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks Subject: Re: [Sip] PING/PONG References: <13719E43-3D96-11D9-93B0-000D93326732@nostrum.com> In-Reply-To: <13719E43-3D96-11D9-93B0-000D93326732@nostrum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Christian Stredicke , Steve Langstaff X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Robert Sparks wrote: > This conversation just got too loose with its terminology for me. > > 3261 proxies have a UAS core. I don't think so; the term for that is "proxy core" and is quite distinct from the UAS and UAC cores. Note the definition of TU: Transaction User (TU): The layer of protocol processing that resides above the transaction layer. Transaction users include the UAC core, UAS core, and proxy core. 3261 proxies have a server transaction (per figure 4) but thats not the same thing. > > Endpoints behind the things we are wanting to do this refresh things to > can be signaling > directly with endpoints that aren't (a service provider could let people > talk to voice-mail > or conference servers directly). I don't see how that practically works in the presence of nat. If you are using tcp/tls, the thing to which you have a connection open is the only place from which you can get subsequent requests. Thus, if I make a call that lands on a voicemail server, the proxy holding my tcp/tls connection has to be on the signaling path, or it just won't work. > > While the long-lived client-to-service-provider-proxy connection is a > good example > to use for motivation, I would prefer that we ensure we build something > that works > in general. I disagree here. The original connect-reuse draft tried to address both the client-to-proxy and proxy-to-proxy problems and ended up doing neither well. We found we needed to split it because these were sufficiently different problems. It seems like you are suggsting that they are not, and that we need a single mechanism for both? > > The DNS solution would work for those the services I call out above. > I'm not yet sure > if its the right way to go. The other alternative I suppose is to use a URI parameter ala draft-ietf-sip-compression. Something like keepalive=stun. Thus, a preloaded route header for a proxy that supports it would look like: sip:outbound.proxy.com;keepalive=stun This is arguably superior for exactly the same reasons we shied away from putting sigcomp into dns - you get this combinatorial explosion of records, since sigcomp and stun as well could both be used in any transport. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 24 03:15:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25865 for ; Wed, 24 Nov 2004 03:15:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWsNW-00017u-K5 for sip-web-archive@ietf.org; Wed, 24 Nov 2004 03:19:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWs9C-0006fT-13; Wed, 24 Nov 2004 03:05:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWs7G-00068V-TI for sip@megatron.ietf.org; Wed, 24 Nov 2004 03:03:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24896 for ; Wed, 24 Nov 2004 03:03:05 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWsB4-0007ym-VS for sip@ietf.org; Wed, 24 Nov 2004 03:07:04 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 24 Nov 2004 00:03:57 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iAO82W9h001100; Wed, 24 Nov 2004 00:02:32 -0800 (PST) Received: from [192.168.1.100] (sjc-vpn1-542.cisco.com [10.21.98.30]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFY18985; Wed, 24 Nov 2004 00:02:30 -0800 (PST) Message-ID: <41A44016.9060502@cisco.com> Date: Wed, 24 Nov 2004 03:02:30 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] Does retargeting belong on the list of Evil SIP Ideas? References: <24EAE5D4448B9D4592C6D234CBEBD597089962@stntexch03.cis.neustar.com> <41A37C24.8030006@softarmor.com> <41A3ACE7.5000102@cisco.com> In-Reply-To: <41A3ACE7.5000102@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit Cc: "'sip@ietf.org'" , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: 7bit Actually, Dean's list of evils is sufficiently large, and covers enough of sip itself, that I think he has more or less concluded that "sip is evil"? :) -Jonathan R Paul Kyzivat wrote: > Dean, > > Rather that the "list of Evil SIP Ideas", I propose this be called the > "axis of Evil SIP Ideas". > > Paul > > Dean Willis wrote: > >> >> I try to keep a running list of things that turned out to be a royal >> pain that needs (or needed) fixing. Some of these things sounded cool >> at first, and I championed them. Others I never did like. Some of >> these things I'm not allowed to suggest deprecating anymore -- we took >> a hum on forking a few meetings back. One of these days I'm going to >> get this list better organized and post it someplace more persistent >> in the hope that it may assist in avoiding repeptition of mistakes. >> And someday, perhaps we can do something about some of these quirks. >> >> To-date, I believe the Evil List includes: >> >> 1) Replacing the Request-URI at each hop while routing was Evil. We >> fixed this with Loose Routing mode, which is still slightly Evil. >> >> 2) Abusing To and From to indicate branches is Evil. We should have >> left these as real endpoint identifiers. >> >> 3) Forking is Evil. >> >> 4) Allowing (and requiring) responses to carry a payload with more >> meaning than "I acknowledge having received that request" is Evil. >> Since we can't reject a response, we can't deal with big responses and >> can't negotiate what they carry. Acknowledgement and response are >> different beasties -- one is transport, the other is application, and >> we need to understand the difference. >> >> 5) The three-message INVITE transaction model and its dependence on >> payload in the response is Evil. >> >> 6) The two-message non-INVITE transaction model and its interaction >> with retransmission and hop-by-hop cascade (See Sparks' non-invite >> analysis) is Evil. >> >> 7) Building transport state and reliability into the application state >> and requiring a transport protocol extension for every new application >> semantic is Evil. >> >> 8) Using z9hG4bK on via fields rather than a negotiated mechanism >> (like maybe a version) is Evil. >> >> 9) Jon argues that not requiring SIPS to be end-to-end is Evil. I >> think the jury is still out on this one, but we're still deliberating. >> >> 10) Provisional responses, as currently constructed, whether reliable >> or non-relaible, are Evil. This may be redundant with the NIT discussion. >> >> 11) I believe I'm coming to believe that "retargeting", i.e. >> changing a request in a proxy such that the entity to which it is >> delivered has a different assertable identity than the identity to >> which the request was originally addressed, is Evil. Perhaps it could >> be mitigated by a assertion of transitivity: "I, the proxy identified >> herein, do assert that I have altered the target of this request >> according to local policy, and you can either deal with it or go >> away." Oh wait, that's the 302 response . . . Perhaps this is >> redundant with "Forking is evil" as forking is just a special case of >> retargeting. Or perhaps forking and retargeting are both special cases >> of "exploders" and could both be dealt with using the consent >> framework . . . >> >> Sometimes I wonder if the use of UDP was fundamentally Evil. >> >> If I've missed something blatantly Evil, please comment back, and I >> may add it to the list I hope to post someplace. >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP 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 Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 24 03:22:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26794 for ; Wed, 24 Nov 2004 03:22:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWsUG-0002Lz-W0 for sip-web-archive@ietf.org; Wed, 24 Nov 2004 03:26:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWsKq-0001Ow-KU; Wed, 24 Nov 2004 03:17:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWsH7-0008Ef-P5 for sip@megatron.ietf.org; Wed, 24 Nov 2004 03:13:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25747 for ; Wed, 24 Nov 2004 03:13:16 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWsKw-0000kw-Rv for sip@ietf.org; Wed, 24 Nov 2004 03:17:15 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 24 Nov 2004 00:13:13 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id iAO8ChYr010424; Wed, 24 Nov 2004 00:12:43 -0800 (PST) Received: from [192.168.1.100] (sjc-vpn1-542.cisco.com [10.21.98.30]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFY19349; Wed, 24 Nov 2004 00:12:42 -0800 (PST) Message-ID: <41A44279.2020700@cisco.com> Date: Wed, 24 Nov 2004 03:12:41 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peterson, Jon" Subject: Re: concrete proposal (was RE: third alternative (was RE: [Sip] R E: I dentity after reinvite)) References: <24EAE5D4448B9D4592C6D234CBEBD597089967@stntexch03.cis.neustar.com> In-Reply-To: <24EAE5D4448B9D4592C6D234CBEBD597089967@stntexch03.cis.neustar.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Content-Transfer-Encoding: 7bit Cc: "'sip@ietf.org'" , "'David R Oran'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Content-Transfer-Encoding: 7bit Firstly, I support Jon's modified proposal. I'm now convinced that providing authenticated identity in the reverse direction doesn't mitigate against any attacks that can't be prevented by other, better means. Indeed, I am less sour on sips than Jon, and using sips fully prevents the impersonation attacks which Jon and Dave were discussing. I also must say that I shudder when someone says "we'll solve the delegation problem" to solve response identity. That problem, in its most general sense, is incredibly hard. I think our only hope is to focus on the very specific cases we need to worry about. In fact, I suspect the solutions for our various cases will differ. I really don't see the response identity and transfer/REFER problems as similar delegation ones, primarily because the authorization logic is different. But, perhaps I am missing a commonality that is more apparent to others... -Jonathan R. Peterson, Jon wrote: >>>An alternative argument has been made that the notion of an > > unanticipated > >>>'connected party' is inherently antithetical to security, because the > > local > >>>UA will be forced to accept a request from any party, as the potential > > set > >>>of valid connected parties in unbounded. >>> >> >>This is true only in the absence of explicit delegation. > > > Of course, and the only reason the text above does not say so is because I > was intentionally trying to phrase this in a way that is silent about the > whole 'connected party' issue. > > As an aside, I think "explicit delegation" is a very good term for what we > need here, when we get around to addressing the 'connected party' problem. > > >>At the risk of >>skipping ahead of your well-done chain of logic here, I think that we >>have in SIP a large number of scenarios (retargeting, REFER, >>Third-party control) where in the absence of explicit delegation we >>either (a) have no security, (b) force cooperating parties to use >>impersonation, or (c) in some cases, can rely on transitivity >>properties. Despite the complexity, we may be better off tackling the >>delegation problem now rather than allowing half-assed things to >>use/abuse the identity stuff because it solves a part of the problem >>(albeit a large part), but not enough. > > > Well... that really depends on your value of "now". I think we can do > request identity, frankly, without solving the explicit delegation problem. > When explicit delegation is resolved, then we can describe its relevance to > identity. In the interim, we can just say that the Identity header isn't > supplied for requests in the backwards direction during a dialog when > retargeting has occurred. Perhaps I only think this language makes sense > because I believe that when we get through with the explicit delegation > problem, we won't be doing "retargeting" any more as such. > > >>>Given that RFC3261 permits UAS's to change the From header field value >>>(irregardless of whether or not the sip-identity mechanism is used), the >>>question here is how should an authentication service, as defined in >>>sip-identity, treat such requests? Should it add an Identity header, > > proxy > >>>them, discard them, etc? Should sip-identity recommend that the From > > header > >>>be changed in this manner when a request has been retargeted? >> >>It would be nice if the identity service did not have to be context >>aware and just signed identity headers for any request from a source it >>was authoritative for. Unless I misunderstand you I think you are >>contemplating the identity service being authz policy aware, and my >>intuition tells me that's a bad idea. > > > At this point in the note, anyway, I'm just contemplating the sort of > questions that seem to have been asked in the thread, not endorsing any > solutions. I agree with you that ideally, the auth service should just sign > the requests that it can, and not sign the requests that it can't. > > >>>We add some text about dialogs, and about the use of the Identity header >>>during a dialog. Obviously, the use of identity for dialog-forming > > requests > >>>is a no-brainer (this is the standard 'caller-ID' assurance). > > Futhermore, > >>>point out that if the intended second party is actually the connected > > party, > >>>identity can be supplied normally in requests in the backwards > > direction. > >>>Stipulate that an auth service instantiated in a proxy MUST Record-Route >>>itself in a dialog-forming request, so that the auth service can > > recognize a > >>>mid-dialog request. >>> >> >>I think I understand what you mean here, but the words could be better. >>I think you are saying that "if a sip server acts as an auth service >>and proxies a request that it auth'ed itself, it MUST record route". >> > > > Yes. > > >>>The Identity header simply would not be provided if the connected party > > is > >>>different from the party to which the local UA sent the request. >> >>Why? If the auth service can authenticate the From in the request, why >>should it refuse to do so? >> > > > My language here is imprecise, yes, I mean something more like "the Identity > header simply would not be provided if the auth service is not responsible > for the domain of the From header field of the request." If we couple this > with the further notion that changing the From header field of requests in > the backwards direction within a dialog is NOT RECOMMENDED because it may > surprising to the originator of the dialog, I'm cool with that. > > >>>Anyone unhappy with that? >>> >> >>Modulo my one issue above, I'm ok with the identity part, but as I >>mentioned, doing just this doesn't actually solve anything other than >>getting identity done (which is laudable and necessary). > > > Right, my ambitions are no greater than that at the moment. Once we're all > on the same page here, we can start diving into the explicit delegation > issue in more detail as a prelude to tackling response identity. > > >>I don't want >>to slow identity down UNLESS there's reason to believe we will have >>backward compatibility problems when we introduce delegation, OR we >>think that identity will get abused or ignored because too many >>real-world situations really need delegation. >> > > > I'm not sure there's much potential for abuse here, and as long as we don't > rule out any important use cases, it faces no more than the usual > probability of being ignored. The most essential problem that people want to > solve is the dialog-forming request identity problem - essentially, the > "caller-ID" problem. That has immediate pay-off in the marketplace. As long > as we can tackle this in a way that doesn't damage our prospects of doing > more work on corner cases in the future, I think we'll be okay. > > Jon Peterson > NeuStar, Inc. > > >>Dave. >> >>David R. Oran >>Cisco Fellow >>Cisco Systems >>7 Ladyslipper Lane >>Acton, MA 01720 USA >>Tel: +1 978 264 2048 >>Email: oran@cisco.com >> >> >>>Jon Peterson >>>NeuStar, Inc. >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 24 03:34:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27808 for ; Wed, 24 Nov 2004 03:34:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWsff-0003vD-7T for sip-web-archive@ietf.org; Wed, 24 Nov 2004 03:38:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWsYq-000541-EU; Wed, 24 Nov 2004 03:31:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWsSA-0003Et-VX for sip@megatron.ietf.org; Wed, 24 Nov 2004 03:24:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26995 for ; Wed, 24 Nov 2004 03:24:41 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWsW0-0002Nv-Ey for sip@ietf.org; Wed, 24 Nov 2004 03:28:40 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 24 Nov 2004 00:25:33 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id iAO8O9ft029179; Wed, 24 Nov 2004 00:24:09 -0800 (PST) Received: from [192.168.1.100] (sjc-vpn1-542.cisco.com [10.21.98.30]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFY19641; Wed, 24 Nov 2004 00:24:07 -0800 (PST) Message-ID: <41A44526.3080703@cisco.com> Date: Wed, 24 Nov 2004 03:24:06 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peterson, Jon" Subject: privacy without b2bua, was: Re: third alternative (was RE: [Sip] RE: Identity after reinvite) References: <24EAE5D4448B9D4592C6D234CBEBD597089963@stntexch03.cis.neustar.com> In-Reply-To: <24EAE5D4448B9D4592C6D234CBEBD597089963@stntexch03.cis.neustar.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: "'Cullen Jennings'" , "'sip@ietf.org'" , "'Paul Kyzivat'" , "'David R Oran'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Peterson, Jon wrote: > A few notes on the "Monica property": as RFC3323 suggests, I think that some > sort of anonymization service, which could be instantiated by a B2BUA, is an > appropriate way to conceal the identity of a called or calling party. What > scares me a little is the way people suggest that retargeting, as opposed to > redirection, can inherently be expected to provide privacy. When I register > a contact, I can't always guarantee that the location service in question > will be used exclusively for retargeting rather than redirection; moreover, > the revelation of the target Request-URI to the caller is not the only way > that the caller can learn who the connected-party is: contact headers of new > requests in the backwards direction of the dialog, SDP in a 200 OK, and so > on, are information leaks that are not addressed at all by retargeting, but > would be addressed by an anonymization service. > > RFC3323 is about due for an update, I think, because the major functions > that it provides can be performed without a B2BUA, thanks to new SIP > mechanisms like GRUUs and session-policy. So while I agree that an > anonymization service is the right approach to this problem, these days I > think you can probably build an anonymization service without building a > B2BUA. I believe this is probably true. Here's how I think it'd work: A client that wants to make an anonymous call contacts a TURN server providing anonymization services. That server provides the client with IP addresses and ports that it can use in its Via, contact, and SDP. The From field is anonymized. A privacy header is inserted. The request is sent via the TURN server to the user's outbound proxy. That proxy can still authenticate the client, and even insert an identity header that at least vouches that the client is a legit client that is just anonymous. The provider of the anonymization server (turn in this case) can be completely decoupled from the sip provider. That provides an excellent level of anonymity compared to even a b2bua. The b2bua approach would still allow the recipient to trace the IP address in the SDP and Contact to the particular provider; this might not be sufficient (I don't recall off hand if rfc3323 discusses this problme). It also means that there is no need to signal things like header or media level privacy. The client simply chooses to obfuscate (using the learned turn addresses) whatever fields it wishes to anonymize. This has the impact of simplifying the privacy spec significantly. Indeed, it would seem that it is hardly needed at all... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 24 09:37:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27911 for ; Wed, 24 Nov 2004 09:37:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWyKs-000147-DJ for sip-web-archive@ietf.org; Wed, 24 Nov 2004 09:41:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWyEi-0006W5-Qb; Wed, 24 Nov 2004 09:35:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWyDn-0006EL-Jr for sip@megatron.ietf.org; Wed, 24 Nov 2004 09:34:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27738 for ; Wed, 24 Nov 2004 09:34:13 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWyHg-0000Ua-Cp for sip@ietf.org; Wed, 24 Nov 2004 09:38:16 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 24 Nov 2004 06:37:07 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iAOEXeAC014943; Wed, 24 Nov 2004 06:33:41 -0800 (PST) Received: from cisco.com (che-vpn-cluster-2-194.cisco.com [10.86.242.194]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ANG68930; Wed, 24 Nov 2004 09:33:39 -0500 (EST) Message-ID: <41A49BC2.4020908@cisco.com> Date: Wed, 24 Nov 2004 09:33:38 -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 Subject: Re: privacy without b2bua, was: Re: third alternative (was RE: [Sip] RE: Identity after reinvite) References: <24EAE5D4448B9D4592C6D234CBEBD597089963@stntexch03.cis.neustar.com> <41A44526.3080703@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: "'Cullen Jennings'" , "'sip@ietf.org'" , "'David R Oran'" , "Peterson, Jon" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Jonathan - inline. Paul Jonathan Rosenberg wrote: > >> RFC3323 is about due for an update, I think, because the major functions >> that it provides can be performed without a B2BUA, thanks to new SIP >> mechanisms like GRUUs and session-policy. So while I agree that an >> anonymization service is the right approach to this problem, these days I >> think you can probably build an anonymization service without building a >> B2BUA. > > I believe this is probably true. Here's how I think it'd work: > > A client that wants to make an anonymous call contacts a TURN server > providing anonymization services. That server provides the client with > IP addresses and ports that it can use in its Via, contact, and SDP. The > From field is anonymized. A privacy header is inserted. The request is > sent via the TURN server to the user's outbound proxy. That proxy can > still authenticate the client, and even insert an identity header that > at least vouches that the client is a legit client that is just anonymous. While I buy the approach, I don't think what you are describing is a TURN server. It is a combination of a TURN server and a SIP anonymization server. And I don't even see how this can be viewed as one thing. The client has to contact a TURN server from the address/port it intends to use for media. For multiple media streams it needs to do this multiple times from different source ports. It also has to contact the sip anonymization server to set up the sip anonymization. Then it can proceed as you describe. Still seems like a good approach - but it requires additional servers / protocols, and extra work on the part of the client. I can see how some might find it easier to just send a sip request to a server that does all the work by magic. Paul > The provider of the anonymization server (turn in this case) can be > completely decoupled from the sip provider. That provides an excellent > level of anonymity compared to even a b2bua. The b2bua approach would > still allow the recipient to trace the IP address in the SDP and Contact > to the particular provider; this might not be sufficient (I don't recall > off hand if rfc3323 discusses this problme). > > It also means that there is no need to signal things like header or > media level privacy. The client simply chooses to obfuscate (using the > learned turn addresses) whatever fields it wishes to anonymize. This has > the impact of simplifying the privacy spec significantly. Indeed, it > would seem that it is hardly needed at all... _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 24 09:49:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29190 for ; Wed, 24 Nov 2004 09:49:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWyWW-0002LN-Lh for sip-web-archive@ietf.org; Wed, 24 Nov 2004 09:53:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWyKb-00085m-Eh; Wed, 24 Nov 2004 09:41:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWyIv-0007ZG-U0 for sip@megatron.ietf.org; Wed, 24 Nov 2004 09:39:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27971 for ; Wed, 24 Nov 2004 09:39:31 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWyMo-00015g-Dc for sip@ietf.org; Wed, 24 Nov 2004 09:43:35 -0500 Received: from [192.168.1.216] (c-24-1-66-77.client.comcast.net [24.1.66.77]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iAOEbNdA033921 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 24 Nov 2004 08:37:24 -0600 (CST) (envelope-from rjsparks@nostrum.com) In-Reply-To: <41A43E4D.8020102@cisco.com> References: <13719E43-3D96-11D9-93B0-000D93326732@nostrum.com> <41A43E4D.8020102@cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <59BC20AE-3E26-11D9-93B0-000D93326732@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] PING/PONG Date: Wed, 24 Nov 2004 08:37:21 -0600 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.1 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Christian Stredicke , Steve Langstaff X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit On Nov 24, 2004, at 1:54 AM, Jonathan Rosenberg wrote: > > > Robert Sparks wrote: > >> This conversation just got too loose with its terminology for me. >> 3261 proxies have a UAS core. > > I don't think so; the term for that is "proxy core" and is quite > distinct from the UAS and UAC cores. Note the definition of TU: > > Transaction User (TU): The layer of protocol processing that > resides above the transaction layer. Transaction users > include > the UAC core, UAS core, and proxy core. > > 3261 proxies have a server transaction (per figure 4) but thats not > the same thing. Fair enough - I was thinking of the role-switch proxies take on error responses, but I'll withdraw the complaint. > > > >> Endpoints behind the things we are wanting to do this refresh things >> to can be signaling >> directly with endpoints that aren't (a service provider could let >> people talk to voice-mail >> or conference servers directly). > > I don't see how that practically works in the presence of nat. If you > are using tcp/tls, the thing to which you have a connection open is > the only place from which you can get subsequent requests. Thus, if I > make a call that lands on a voicemail server, the proxy holding my > tcp/tls connection has to be on the signaling path, or it just won't > work. If I can establish a tcp/tls connection to that voicemail server, then subsequent requests from it can come back down that connection assuming we can keep it alive. > >> While the long-lived client-to-service-provider-proxy connection is a >> good example >> to use for motivation, I would prefer that we ensure we build >> something that works >> in general. > > I disagree here. The original connect-reuse draft tried to address > both the client-to-proxy and proxy-to-proxy problems and ended up > doing neither well. We found we needed to split it because these were > sufficiently different problems. It seems like you are suggsting that > they are not, and that we need a single mechanism for both? No, I'm not trying to push this back to arbitrary node to arbitrary node. I am trying to push it closer to UAC to arbitrary node. And I'm only talking about keeping the connection alive, which is a different problem than figuring out what SIP thing is on each end so you can affect routing choices (which is a big part of what's been making connection-reuse hard). > >> The DNS solution would work for those the services I call out above. >> I'm not yet sure >> if its the right way to go. > > The other alternative I suppose is to use a URI parameter ala > draft-ietf-sip-compression. Something like keepalive=stun. Thus, a > preloaded route header for a proxy that supports it would look like: > > sip:outbound.proxy.com;keepalive=stun > > This is arguably superior for exactly the same reasons we shied away > from putting sigcomp into dns - you get this combinatorial explosion > of records, since sigcomp and stun as well could both be used in any > transport. Agreed. > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 24 22:18:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02640 for ; Wed, 24 Nov 2004 22:18:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXADs-0005wm-U0 for sip-web-archive@ietf.org; Wed, 24 Nov 2004 22:23:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXA6A-0006DQ-VX; Wed, 24 Nov 2004 22:15:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX9zY-0004j9-Uq for sip@megatron.ietf.org; Wed, 24 Nov 2004 22:08:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01956 for ; Wed, 24 Nov 2004 22:08:18 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXA3Y-0005k0-6Y for sip@ietf.org; Wed, 24 Nov 2004 22:12:28 -0500 Received: from [192.168.0.108] (adsl-209-30-33-13.dsl.rcsntx.swbell.net [209.30.33.13]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iAP38EcT094522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 24 Nov 2004 21:08:15 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <41A54C97.9000807@nostrum.com> Date: Wed, 24 Nov 2004 21:08:07 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Subject: [Sip] Event List Changes X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit I'm revising the event list draft currently. In DC, we discussed at length the authentication model for situations in which the RLS and subscriber are in the same domain; I believe I've captured this pretty well (but encourage interested parties to double check my interpretation of consensus). When I went to update the document, however, I found that there was still something of a hole for the other case -- the one we described as a corner case. I know that we agreed that (1) additional mechanism could be developed to solve this case, and (2) we didn't want to wait for these mechanisms before publishing the event list document. However, I don't remember discussing what RLS implementors can do when they receive a request for a list resource from a user outside their domain. So, I came up with what seemed like the most logical solution, given the other discussions we had. Before I submit -07 of the document, I'd like to have a few people look over my proposed text; if you think this is the wrong direction to take it, speak up now. If I get no comments before the end of next week, I'll submit the draft with the following language. > 7.1 Authentication > > If back-end subscriptions are required to retrieve resource state > information, the end user is no longer the direct subscriber to the > state of the resource. This means that direct authentication of the > user is no longer possible. > > 7.1.1 RLS and Subscriber in the Same Domain > > It is expected that the most common deployment of RLSes entails the > subscribers to the RLS being in the same domain as the RLS. When > this is the case, the RLS then has the ability to act as an > authenication service. The role of authentication service is defined > in "Enhancements for Authenticated Identity Management in the Session > Initiation Protocol (SIP)" [7]. > > At a high level, under this system, the RLS authenticates the > subscriber, and then includes an "Identity" header field in all of > the back-end subscriptions performed on behalf of that authenticated > user; this "Identity" header field cryptographically asserts that the > request has been authorized to be made on behalf of the user > indicated in the "From" header field. > > Because the ability to authenticate requests is central to the proper > functioning of the network, any RLS which uses SIP back-end > subscriptions to acquire information about the resources in a > resource list MUST be able to act as an authentication service as > defined in [7]. > > 7.1.2 RLS and Subscriber in Different Domains > > In the general case, the SIP Authenticated Identity extensions do not > provide a means for the RLS to securely assert that subscriptions are > being performed on the end user's behalf. Specifically, when the > subscriber and the RLS are in different domains, the RLS will have no > means by which it can vouch for the user's identity. Mechanisms by > which back-end subscriptions in such circumstances can be > authenticated are left for future study. > > Until such general solutions are developed, RLSes which are in a > different domain than the subscriber on whose behalf they are > creating back-end susbcriptions SHOULD subscribe to the resources > using their own identity. By doing so, the RLS will generally obtain > only the resource information which is made publicly available. > > Absent such general solutions, implemenations of subscriber user > agents MAY attempt direct subscriptions to resources in the resouce > list when subscribing to an RLS outside of their domain (either > directly or by way of another resource list subscription). The > resouces to be subscribed to will be those indicated in the the "uri" > attribute of the elements present in the RLMI document > returned by the RLS. Directly subscribing to the resources allows > proper authentication of the user to take place, which will generally > authorize them to receive more complete state information. > Implementations which choose to perform such direct subscriptions > SHOULD use the data retrieved directly to the exclusion of any > information about the resource obtained via the list subscription. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 24 22:25:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03548 for ; Wed, 24 Nov 2004 22:25:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXAKU-00068j-93 for sip-web-archive@ietf.org; Wed, 24 Nov 2004 22:29:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXAFJ-0008Qr-E0; Wed, 24 Nov 2004 22:24:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXA8d-0006pY-58 for sip@megatron.ietf.org; Wed, 24 Nov 2004 22:17:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02529 for ; Wed, 24 Nov 2004 22:17:40 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXACc-0005v2-Ls for sip@ietf.org; Wed, 24 Nov 2004 22:21:51 -0500 Received: from [192.168.0.108] (adsl-209-30-33-13.dsl.rcsntx.swbell.net [209.30.33.13]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iAP3Hd1k095123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Nov 2004 21:17:40 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <41A54ECC.2060201@nostrum.com> Date: Wed, 24 Nov 2004 21:17:32 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach Subject: Re: [Sip] Re: RLS and identity References: <4193DAAC.3020609@nokia.com> <4193E902.7010206@nostrum.com> In-Reply-To: <4193E902.7010206@nostrum.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: SIP WG , Aki Niemi X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Adam Roach wrote: > Based on Rohan's suggestion, the text will effectively say: > > - Jon's Identity draft will be mandatory to implement, optional to use. > > - Other mechanisms that have properties such that they can adequately > convey the identity of the subscriber and the permission of the RLS > to subscribe on the user's behalf can also be used. As a clarification, I have received specific guidance from the area directors that the draft cannot contain anything about such alternate mechanisms, even if they are not specifically mentioned by name. The use of e.g. P-Asserted-Identity will need to be a modification that 3GPP specifically calls out relative to the draft. Of course, since the identity work is basically done and works so much better than P-Asserted-Identity, there could be a very valid argument made that 3GPP R6 should abandon the inherently insecure P-Asserted-Identity mechanism in favor of the cryptographically secure SIP Identity mechanism. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 25 03:17:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13258 for ; Thu, 25 Nov 2004 03:17:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXEsg-0004Qp-Ly for sip-web-archive@ietf.org; Thu, 25 Nov 2004 03:21:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXEgi-0004vt-QW; Thu, 25 Nov 2004 03:09:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXEce-0003iI-NI for sip@megatron.ietf.org; Thu, 25 Nov 2004 03:05:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11814 for ; Thu, 25 Nov 2004 03:04:58 -0500 (EST) Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXEgg-00046W-As for sip@ietf.org; Thu, 25 Nov 2004 03:09:10 -0500 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id iAP84wRt030760; Thu, 25 Nov 2004 09:04:58 +0100 Received: from mchh247e.mchh.siemens.de (mchh247e.mchh.siemens.de [139.21.200.57]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id iAP84wts031280; Thu, 25 Nov 2004 09:04:58 +0100 Received: by mchh247e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Thu, 25 Nov 2004 09:03:24 +0100 Message-ID: <79D5F4B2D775204D9C7852EE41C5477305D0AF6F@mchh2a1e.mchh.siemens.de> From: Milinski Alexander To: "'Adam Roach'" Subject: RE: [Sip] Re: RLS and identity Date: Thu, 25 Nov 2004 09:04:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: SIP WG , Aki Niemi X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Dear Adam, 3GPP Rel-6 is close to freezing, thus I would not expect any more major changes. Also, it seems that backward compatibility would need to be addressed. In other words: I believe your proposal is not realistic. Regards, Alexander P.S. Once Dean has cleaned up all SIP evils, there will certainly be the opportunity to consider also other major changes ... :-) -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Adam Roach Sent: Thursday, November 25, 2004 4:18 AM To: Adam Roach Cc: SIP WG; Aki Niemi Subject: Re: [Sip] Re: RLS and identity Adam Roach wrote: > Based on Rohan's suggestion, the text will effectively say: > > - Jon's Identity draft will be mandatory to implement, optional to use. > > - Other mechanisms that have properties such that they can adequately > convey the identity of the subscriber and the permission of the RLS > to subscribe on the user's behalf can also be used. As a clarification, I have received specific guidance from the area directors that the draft cannot contain anything about such alternate mechanisms, even if they are not specifically mentioned by name. The use of e.g. P-Asserted-Identity will need to be a modification that 3GPP specifically calls out relative to the draft. Of course, since the identity work is basically done and works so much better than P-Asserted-Identity, there could be a very valid argument made that 3GPP R6 should abandon the inherently insecure P-Asserted-Identity mechanism in favor of the cryptographically secure SIP Identity mechanism. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 25 13:28:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05819 for ; Thu, 25 Nov 2004 13:28:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXOQ9-00027F-ED for sip-web-archive@ietf.org; Thu, 25 Nov 2004 13:32:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXOHw-0002v2-Pg; Thu, 25 Nov 2004 13:24:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXOH2-0002dX-Ay for sip@megatron.ietf.org; Thu, 25 Nov 2004 13:23:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05608 for ; Thu, 25 Nov 2004 13:23:17 -0500 (EST) Received: from voyager.coretrek.no ([212.33.142.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXOKz-00020k-2k for sip@ietf.org; Thu, 25 Nov 2004 13:27:36 -0500 Received: from localhost (localhost [127.0.0.1]) by voyager.coretrek.no (Postfix) with ESMTP id 36EE5A9457; Thu, 25 Nov 2004 19:22:35 +0100 (CET) Received: from [192.168.1.50] (unknown [82.196.203.62]) by voyager.coretrek.no (Postfix) with ESMTP id 888B4A9441; Thu, 25 Nov 2004 19:22:31 +0100 (CET) In-Reply-To: <41A54C97.9000807@nostrum.com> References: <41A54C97.9000807@nostrum.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] Event List Changes Date: Thu, 25 Nov 2004 19:22:28 +0100 To: Adam Roach X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by AMaViS perl-11 (CoreTrek clamav patch 1) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: 7bit What should an RLS do when it receives a list subscription from a different domain it has no trust relationship with, and that subscription has an identity-header? I think it should remove that header. Is this an identity draft issue or should the event list draft also mention it? Regards, Hisham On Nov 25, 2004, at 4:08 AM, Adam Roach wrote: > I'm revising the event list draft currently. In DC, we discussed at > length the authentication model for situations in which the RLS and > subscriber are in the same domain; I believe I've captured this pretty > well (but encourage interested parties to double check my > interpretation of consensus). > > When I went to update the document, however, I found that there was > still something of a hole for the other case -- the one we described > as a corner case. I know that we agreed that (1) additional mechanism > could be developed to solve this case, and (2) we didn't want to wait > for these mechanisms before publishing the event list document. > However, I don't remember discussing what RLS implementors can do when > they receive a request for a list resource from a user outside their > domain. > > So, I came up with what seemed like the most logical solution, given > the other discussions we had. Before I submit -07 of the document, I'd > like to have a few people look over my proposed text; if you think > this is the wrong direction to take it, speak up now. If I get no > comments before the end of next week, I'll submit the draft with the > following language. > >> 7.1 Authentication >> >> If back-end subscriptions are required to retrieve resource state >> information, the end user is no longer the direct subscriber to the >> state of the resource. This means that direct authentication of >> the >> user is no longer possible. >> >> 7.1.1 RLS and Subscriber in the Same Domain >> >> It is expected that the most common deployment of RLSes entails the >> subscribers to the RLS being in the same domain as the RLS. When >> this is the case, the RLS then has the ability to act as an >> authenication service. The role of authentication service is >> defined >> in "Enhancements for Authenticated Identity Management in the >> Session >> Initiation Protocol (SIP)" [7]. >> >> At a high level, under this system, the RLS authenticates the >> subscriber, and then includes an "Identity" header field in all of >> the back-end subscriptions performed on behalf of that >> authenticated >> user; this "Identity" header field cryptographically asserts that >> the >> request has been authorized to be made on behalf of the user >> indicated in the "From" header field. >> >> Because the ability to authenticate requests is central to the >> proper >> functioning of the network, any RLS which uses SIP back-end >> subscriptions to acquire information about the resources in a >> resource list MUST be able to act as an authentication service as >> defined in [7]. >> >> 7.1.2 RLS and Subscriber in Different Domains >> >> In the general case, the SIP Authenticated Identity extensions do >> not >> provide a means for the RLS to securely assert that subscriptions >> are >> being performed on the end user's behalf. Specifically, when the >> subscriber and the RLS are in different domains, the RLS will have >> no >> means by which it can vouch for the user's identity. Mechanisms by >> which back-end subscriptions in such circumstances can be >> authenticated are left for future study. >> >> Until such general solutions are developed, RLSes which are in a >> different domain than the subscriber on whose behalf they are >> creating back-end susbcriptions SHOULD subscribe to the resources >> using their own identity. By doing so, the RLS will generally >> obtain >> only the resource information which is made publicly available. >> >> Absent such general solutions, implemenations of subscriber user >> agents MAY attempt direct subscriptions to resources in the resouce >> list when subscribing to an RLS outside of their domain (either >> directly or by way of another resource list subscription). The >> resouces to be subscribed to will be those indicated in the the >> "uri" >> attribute of the elements present in the RLMI document >> returned by the RLS. Directly subscribing to the resources allows >> proper authentication of the user to take place, which will >> generally >> authorize them to receive more complete state information. >> Implementations which choose to perform such direct subscriptions >> SHOULD use the data retrieved directly to the exclusion of any >> information about the resource obtained via the list subscription. > > > /a > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 26 00:05:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21241 for ; Fri, 26 Nov 2004 00:05:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXYNE-0006lg-2T for sip-web-archive@ietf.org; Fri, 26 Nov 2004 00:10:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXYBX-0006Dg-O1; Thu, 25 Nov 2004 23:58:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXYAQ-0005tY-OS for sip@megatron.ietf.org; Thu, 25 Nov 2004 23:57:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20853 for ; Thu, 25 Nov 2004 23:57:07 -0500 (EST) Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXYEd-0006aa-Rt for sip@ietf.org; Fri, 26 Nov 2004 00:01:32 -0500 Received: from axws72 (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with SMTP id iAQ4ua3c013416 for ; Thu, 25 Nov 2004 22:56:37 -0600 (CST) Message-ID: <075a01c4d375$6d4eed60$9c01ff0a@axws72> From: "Srinivasa Rao" To: Subject: [SIP] RFC 3725, clarification Date: Fri, 26 Nov 2004 10:34:32 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Hi, Anybody please clarify me about the difference of point 1 : "Offers and answers that contain a connection line with an address of 0.0.0.0." point 7 : "SDP Connection address of zero" of section 11, in RFC 3725 (3pcc). Are both really mean the same? I tried the answer in mail archive, but no luck :( . Thanks Srinivasa Rao _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 26 10:17:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15392 for ; Fri, 26 Nov 2004 10:17:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXhul-00032f-Tw for sip-web-archive@ietf.org; Fri, 26 Nov 2004 10:21:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXhla-0005jA-D9; Fri, 26 Nov 2004 10:12:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXhWP-0006TI-8R for sip@megatron.ietf.org; Fri, 26 Nov 2004 09:56:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19894 for ; Fri, 26 Nov 2004 04:00:17 -0500 (EST) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXc1u-0003Bz-Us for sip@ietf.org; Fri, 26 Nov 2004 04:04:42 -0500 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iAQ90BR2018110 for ; Fri, 26 Nov 2004 10:00:11 +0100 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 Nov 2004 10:00:11 +0100 Received: from ericsson.com (EFO9N000L5C7100 [153.88.40.79]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id WHLS0XK2; Fri, 26 Nov 2004 10:00:10 +0100 Message-ID: <41A6F09A.9040800@ericsson.com> Date: Fri, 26 Nov 2004 11:00:10 +0200 X-Sybari-Trust: cbe5d1ef a5e9b67f 4c710f86 00000139 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: Srinivasa Rao Subject: Re: [SIP] RFC 3725, clarification References: <20041126082127.40168.qmail@web54206.mail.yahoo.com> <07f801c4d396$80a10d50$9c01ff0a@axws72> In-Reply-To: <07f801c4d396$80a10d50$9c01ff0a@axws72> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Nov 2004 09:00:11.0067 (UTC) FILETIME=[55C3D8B0:01C4D396] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, jdrosen@dynamicsoft.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Yes, they are the same thing and have been listed separately by mistake. Gonzalo Srinivasa Rao wrote: > If it is YES, > Why it has been listed separately? > If anyone feels if it is not same, please let me know. > I want authors also need to give their comments on this. > > Thanks > Srinivasa Rao > > ----- Original Message ----- > From: "Rayees Khan" > To: "Srinivasa Rao" ; > Sent: Friday, November 26, 2004 1:51 PM > Subject: Re: [SIP] RFC 3725, clarification > > > >>Yes, >> >>I guess both of them mean the same. >> >> >>regards >>Rayees >> >>--- Srinivasa Rao wrote: >> >> >>>Hi, >>> Anybody please clarify me about the difference of >>> point 1 : "Offers and answers that contain a >>>connection line >>> with an address of 0.0.0.0." >>> >>> point 7 : "SDP Connection address of zero" of >>>section 11, in RFC 3725 >>>(3pcc). >>> >>> Are both really mean the same? >>> I tried the answer in mail archive, but no luck >>>:( . >>> >>> Thanks >>> Srinivasa Rao >>> >>> >>> >>> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 26 10:18:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15572 for ; Fri, 26 Nov 2004 10:18:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXhw0-00035f-Tl for sip-web-archive@ietf.org; Fri, 26 Nov 2004 10:22:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXhlb-0005kW-Nj; Fri, 26 Nov 2004 10:12:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXhWR-0006TI-MO for sip@megatron.ietf.org; Fri, 26 Nov 2004 09:56:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19441 for ; Fri, 26 Nov 2004 03:54:08 -0500 (EST) Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXbw0-0002t1-Bu for sip@ietf.org; Fri, 26 Nov 2004 03:58:33 -0500 Received: from axws72 (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with SMTP id iAQ8rN3c013278; Fri, 26 Nov 2004 02:53:24 -0600 (CST) Message-ID: <07f801c4d396$80a10d50$9c01ff0a@axws72> From: "Srinivasa Rao" To: References: <20041126082127.40168.qmail@web54206.mail.yahoo.com> Subject: Re: [SIP] RFC 3725, clarification Date: Fri, 26 Nov 2004 14:30:59 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Cc: jdrosen@dynamicsoft.com, Gonzalo.Camarillo@ericsson.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit If it is YES, Why it has been listed separately? If anyone feels if it is not same, please let me know. I want authors also need to give their comments on this. Thanks Srinivasa Rao ----- Original Message ----- From: "Rayees Khan" To: "Srinivasa Rao" ; Sent: Friday, November 26, 2004 1:51 PM Subject: Re: [SIP] RFC 3725, clarification > > Yes, > > I guess both of them mean the same. > > > regards > Rayees > > --- Srinivasa Rao wrote: > > > Hi, > > Anybody please clarify me about the difference of > > point 1 : "Offers and answers that contain a > > connection line > > with an address of 0.0.0.0." > > > > point 7 : "SDP Connection address of zero" of > > section 11, in RFC 3725 > > (3pcc). > > > > Are both really mean the same? > > I tried the answer in mail archive, but no luck > > :( . > > > > Thanks > > Srinivasa Rao > > > > > > > > > > _______________________________________________ > > Sip mailing list > > https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP > > Protocol > > Use sip-implementors@cs.columbia.edu for questions > > on current sip > > Use sipping@ietf.org for new developments on the > > application of sip > > > > > > > __________________________________ > Do you Yahoo!? > Yahoo! Mail - Helps protect you from nasty viruses. > http://promotions.yahoo.com/new_mail _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 26 17:16:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28207 for ; Fri, 26 Nov 2004 17:16:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXoSY-00017p-Nm for sip-web-archive@ietf.org; Fri, 26 Nov 2004 17:20:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXoMI-0007nH-U1; Fri, 26 Nov 2004 17:14:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXoGo-00072c-Rq for sip@megatron.ietf.org; Fri, 26 Nov 2004 17:08:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27726 for ; Fri, 26 Nov 2004 17:08:48 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXoLB-0000ou-AI for sip@ietf.org; Fri, 26 Nov 2004 17:13:21 -0500 Received: from [192.168.0.108] (adsl-209-30-33-13.dsl.rcsntx.swbell.net [209.30.33.13]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iAQM8kXT074366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Nov 2004 16:08:48 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <41A7A966.7010505@nostrum.com> Date: Fri, 26 Nov 2004 16:08:38 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hisham Khartabil Subject: Re: [Sip] Event List Changes References: <41A54C97.9000807@nostrum.com> In-Reply-To: X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Hisham Khartabil wrote: > What should an RLS do when it receives a list subscription from a > different domain it has no trust relationship with, and that > subscription has an identity-header? I think it should remove that > header. Is this an identity draft issue or should the event list draft > also mention it? Yes, this is very much an identity issue, but I think you're misunderstanding a couple of different things here. First -- and this is why it's useful in the first place -- the "Identity" header has the means to assert identity across domains that have no trust relationship (except for by way of a certificate authority). That is its purpose. Second, when an RLS forms a back-end subscription, it is doing exactly that: starting up a brand new subscription. The subscription is between the RLS and where it sends its SUBSCRIBE message, not the end-user's client and the resource. It is not passing through headers from the original request. It might very well generate outgoing header fields based on the incoming header fields, but it would be foolish to do so blindly. To be clear: an RLS, when forming SUBSCRIBE requests, is acting as a back-to-back user agent, not as a proxy. It has an obligation to understand everything it sends in a back-end subscription request. So, to answer the question, "What should an RLS do when it receives a list subscription from a different domain it has no trust relationship with, and that subscription has an identity-header:" it verifies that the identity header is valid for the request (after retrieving the relevant certificate, if necessary); and, if it is, accepts that the requestor is authorized to assert the identity in the "From" header. From a practical perspective, this means that it would be safe to feed that identity into policy rules associated with the subscription. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Nov 28 23:40:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22592 for ; Sun, 28 Nov 2004 23:40:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYdQ2-0006QJ-BG for sip-web-archive@ietf.org; Sun, 28 Nov 2004 23:45:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYdIW-0000eY-AQ; Sun, 28 Nov 2004 23:38:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYdDK-0007pc-7N for sip@megatron.ietf.org; Sun, 28 Nov 2004 23:32:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21743 for ; Sun, 28 Nov 2004 23:32:35 -0500 (EST) Received: from web52310.mail.yahoo.com ([206.190.39.105]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CYdHz-0006DD-7v for sip@ietf.org; Sun, 28 Nov 2004 23:37:38 -0500 Received: (qmail 90128 invoked by uid 60001); 29 Nov 2004 04:31:56 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=JJz5+Mcdf18YjMMi6lC8xqnmTIW/6Fnt/6TWaKL1PkSEUsGTenM5daNKgc53+IeUJYK0no+d/r6Rbs984prZCE2cutHky1fFX4ZkLe9p8Iox579Mdo3Xd86HFkQbs588TqN8cSt9xaS852FYcsd2H2rFlRhO5jZ7f9SxKi3XJpM= ; Message-ID: <20041129043156.90126.qmail@web52310.mail.yahoo.com> Received: from [217.10.50.85] by web52310.mail.yahoo.com via HTTP; Sun, 28 Nov 2004 20:31:56 PST Date: Sun, 28 Nov 2004 20:31:56 -0800 (PST) From: murali foru To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.9 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Subject: [Sip] branch parameter in CANCEL X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1021252240==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 --===============1021252240== Content-Type: multipart/alternative; boundary="0-1478940448-1101702716=:87941" --0-1478940448-1101702716=:87941 Content-Type: text/plain; charset=us-ascii Hi, I wanted some clarification on the branch parameter in CANCEL. From what I Understand the branch parameter should be the same in the INVITE and the CANCEL(especially when using the magic cookie) so as to match the transaction being cancelled. >From RFC 3261 The following procedures are used to construct a CANCEL request. The Request-URI, Call-ID, To, the numeric part of CSeq, and From header fields in the CANCEL request MUST be identical to those in the request being cancelled, including tags. A CANCEL constructed by a client MUST have only a single Via header field value matching the top Via value in the request being cancelled. Using the same values for these header fields allows the CANCEL to be matched with the request it cancels (Section 9.2 indicates how such matching occurs). However, the method part of the CSeq header field MUST have a value of CANCEL. This allows it to be identified and processed as a transaction in its own right (See Section 17). The branch parameter in the topmost Via header field of the request is examined. If it is present and begins with the magic cookie "z9hG4bK", the request was generated by a client transaction compliant to this specification. Therefore, the branch parameter will be unique across all transactions sent by that client. The request matches a transaction if: 1. the branch parameter in the request is equal to the one in the top Via header field of the request that created the transaction, and 2. the sent-by value in the top Via of the request is equal to the one in the request that created the transaction, and 3. the method of the request matches the one that created the transaction, except for ACK, where the method of the request that created the transaction is INVITE. This matching rule applies to both INVITE and non-INVITE transactions alike. I would like to know if this is a correct CANCEL for the INVITE sent INVITE sip:1@172.20.22.33 SIP/2.0 Max-Forwards: 10 Record-Route: Via: SIP/2.0/UDP 172.20.22.102;branch=z9hG4bK6ee8.484c8882.0 Via: SIP/2.0/UDP 172.20.22.75:5060;branch=z9hG4bK39e838b9 From: "55" ;tag=001201544d1a001b1f8360ea-1cbce160 To: Call-ID: 00120154-4d1a001b-54ba3444-4e6b98f1@172.20.22.75 CSeq: 101 INVITE User-Agent: CSCO/6 Contact: Expires: 180 Content-Type: application/sdp Content-Length: 247 Accept: application/sdp v=0 o=Cisco-SIPUA 14494 13084 IN IP4 172.20.22.75 s=SIP Call c=IN IP4 172.20.22.75 t=0 0 m=audio 18990 RTP/AVP 0 8 18 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 SIP/2.0 180 Ringing Via: SIP/2.0/UDP 172.20.22.102;branch= z9hG4bK6ee8.484c8882.0, SIP/2.0/UDP 172.20.22.75:5060;branch= z9hG4bK39e838b9 Record-Route: To: ; tag= 3e7ca296 From: "55" ; tag= 001201544d1a001b1f8360ea-1cbce160 Call-ID: 00120154-4d1a001b-54ba3444-4e6b98f1@172.20.22.75 CSeq: 101 INVITE Contact: Content-Length: 0 CANCEL sip:1@172.20.22.33 SIP/2.0 Max-Forwards: 10 Record-Route: Via: SIP/2.0/UDP 172.20.22.102;branch=z9hG4bK6ee8.584c8882.0 Via: SIP/2.0/UDP 172.20.22.75:5060;branch=z9hG4bK6a729507 From: "55" ;tag=001201544d1a001b1f8360ea-1cbce160 To: Call-ID: 00120154-4d1a001b-54ba3444-4e6b98f1@172.20.22.75 CSeq: 101 CANCEL User-Agent: CSCO/6 Content-Length: 0 In the above case the branch parameter matching fails. Regards, Murali __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --0-1478940448-1101702716=:87941 Content-Type: text/html; charset=us-ascii
Hi,

I wanted some clarification on the branch parameter in CANCEL. From what I Understand the branch parameter should be the same in the INVITE and the CANCEL(especially when using the magic cookie) so as to match the transaction being cancelled.

From RFC 3261

The following procedures are used to construct a CANCEL request. The Request-URI, Call-ID, To, the numeric part of CSeq, and From header fields in the CANCEL request MUST be identical to those in the request being cancelled, including tags. A CANCEL constructed by a client MUST have only a single Via header field value matching the top Via value in the request being cancelled. Using the same values for these header fields allows the CANCEL to be matched with the request it cancels (Section 9.2 indicates how such matching occurs). However, the method part of the CSeq header field MUST have a value of CANCEL. This allows it to be identified and processed as a transaction! in its own right (See Section 17).


The branch parameter in the topmost Via header field of the request is examined. If it is present and begins with the magic cookie "z9hG4bK", the request was generated by a client transaction compliant to this specification. Therefore, the branch parameter will be unique across all transactions sent by that client. The request matches a transaction if:

1. the branch parameter in the request is equal to the one in the top Via header field of the request that created the transaction, and
2. the sent-by value in the top Via of the request is equal to the one in the request that created the transaction, and
3. the method of the request matches the one that created the transaction, except for ACK, where the method of the request that created the transaction is INVITE.

This matching rule applies to both INVITE and non-INVITE transactions alike.


I would like to know if this is a correct CA! NCEL for the INVITE sent

INVITE sip:1@172.20.22.33 SIP/2.0
Max-Forwards: 10
Record-Route: <sip:1@172.20.22.102;ftag=001201544d1a001b1f8360ea-1cbce160;lr=on>
Via: SIP/2.0/UDP 172.20.22.102;branch=z9hG4bK6ee8.484c8882.0
Via: SIP/2.0/UDP 172.20.22.75:5060;branch=z9hG4bK39e838b9
From: "55" <sip:55@172.20.22.102>;tag=001201544d1a001b1f8360ea-1cbce160
To: <sip:1@172.20.22.33>
Call-ID: 00120154-4d1a001b-54ba3444-4e6b98f1@172.20.22.75
CSeq: 101 INVITE
User-Agent: CSCO/6
Contact: <sip:55@172.20.22.75:5060>
Expires: 180
Content-Type: application/sdp
Content-Length: 247
Accept: application/sdp

v=0
o=Cisco-SIPUA 14494 13084 IN IP4 172.20.22.75
s=SIP Call
c=IN IP4 172.20.22.75
t=0 0
m=audio 18990 RTP/AVP 0 8 18 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15


SIP/2.! 0 180 Ringing
Via: SIP/2.0/UDP 172.20.22.102;branch= z9hG4bK6ee8.484c8882.0, SIP/2.0/UDP 172.20.22.75:5060;branch= z9hG4bK39e838b9
Record-Route: <sip:1@172.20.22.102;ftag=001201544d1a001b1f8360ea-1cbce160;lr=on>
To: <sip:1@172.20.22.33>; tag= 3e7ca296
From: "55" <sip:55@172.20.22.102>; tag= 001201544d1a001b1f8360ea-1cbce160
Call-ID: 00120154-4d1a001b-54ba3444-4e6b98f1@172.20.22.75
CSeq: 101 INVITE
Contact: <sip:1@172.20.22.33;transport=UDP>
Content-Length: 0


CANCEL sip:1@172.20.22.33 SIP/2.0
Max-Forwards: 10
Record-Route: <sip:1@172.20.22.102;ftag=001201544d1a001b1f8360ea-1cbce160;lr=on>
Via: SIP/2.0/UDP 172.20.22.102;branch=z9hG4bK6ee8.584c8882.0
Via: SIP/2.0/UDP 172.20.22.75:5060;branch=z9hG4bK6a729507
From: "55" <sip:55@172.20.22.102>;tag=001201544d1a001b1f8360ea-1cbce160
To: <sip:1@172.20.22.33>
Call-ID: 00120154-4d1a001b-54ba3444-4e6b98f1@172.20.! 22.75
CSeq: 101 CANCEL
User-Agent: CSCO/6
Content-Length: 0

In the above case the branch parameter matching fails.

Regards,
Murali

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com --0-1478940448-1101702716=:87941-- --===============1021252240== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1021252240==-- From sip-bounces@ietf.org Mon Nov 29 07:22:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12234 for ; Mon, 29 Nov 2004 07:22:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYkdO-0007XI-SI for sip-web-archive@ietf.org; Mon, 29 Nov 2004 07:28:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYkUY-00072a-CB; Mon, 29 Nov 2004 07:18:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYkLZ-000564-Tx for sip@megatron.ietf.org; Mon, 29 Nov 2004 07:09:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11061 for ; Mon, 29 Nov 2004 07:09:35 -0500 (EST) Received: from [80.74.106.125] (helo=rvil-mail.RADVISION.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYkQT-0007Bj-Lx for sip@ietf.org; Mon, 29 Nov 2004 07:14:42 -0500 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="windows-1255" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Nov 2004 14:09:07 +0200 Message-ID: <10DA2C035FE3BC4FA8D73EC55FC43D9B044E59@rvil-mail.radvision.com> Thread-Topic: Mistake in PRES-URI BNF Thread-Index: AcTWCaDjM4FIQsWjTuS7Fjes8AVjBwAAo34Q From: "Tamar Barzuza" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable Subject: [Sip] Mistake in PRES-URI BNF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable > Hi, >=20 > I found a problem in the BNF of PRES-URI. >=20 > RFC 2396 defined the generic syntax of URI. It explicitly says that = the following (delims) characters are disallowed within URI: > delims=3D "<" | ">" | "#" | "%" | <">=20 >=20 > However, in RFCs 3859 and 2822 the definition for PRES-URI is: > PRES URI =3D "pres:" [ to ] [ headers ]=20 > to =3D mailbox=20 > mailbox =3D name-addr / addr-spec=20 > name-addr =3D [display-name] angle-addr=20 > angle-addr =3D [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr=20 > addr-spec =3D local-part "@" domain=20 > display-name =3D phrase=20 > Which means that pres addresses can look like pres:"name", = hence may contain " and <>. >=20 > Therefore I believe that the PRES-URI BNF is mistaken.=20 >=20 > Thanks, > Tamar. >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 29 07:32:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13016 for ; Mon, 29 Nov 2004 07:32:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYkmJ-0007hp-Uu for sip-web-archive@ietf.org; Mon, 29 Nov 2004 07:37:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYkfQ-0000hi-IS; Mon, 29 Nov 2004 07:30:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYkXn-0007bp-No for sip@megatron.ietf.org; Mon, 29 Nov 2004 07:22:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12214 for ; Mon, 29 Nov 2004 07:22:15 -0500 (EST) Received: from [80.74.106.125] (helo=rvil-mail.RADVISION.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYkcg-0007Vv-D8 for sip@ietf.org; Mon, 29 Nov 2004 07:27:19 -0500 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="windows-1255" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Nov 2004 14:21:43 +0200 Message-ID: <10DA2C035FE3BC4FA8D73EC55FC43D9B044E5A@rvil-mail.radvision.com> Thread-Topic: Mistake in PRES-URI BNF Thread-Index: AcTWCaDjM4FIQsWjTuS7Fjes8AVjBwABFfLQ From: "Tamar Barzuza" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable Subject: [Sip] Mistake in PRES-URI BNF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable > Hi, >=20 > I found a problem in the BNF of PRES-URI. >=20 > RFC 2396 defined the generic syntax of URI. It explicitly says that = the following (delims) characters are disallowed within URI: > delims=3D "<" | ">" | "#" | "%" | <">=20 >=20 > However, in RFCs 3859 and 2822 the definition for PRES-URI is: > PRES URI =3D "pres:" [ to ] [ headers ]=20 > to =3D mailbox=20 > mailbox =3D name-addr / addr-spec=20 > name-addr =3D [display-name] angle-addr=20 > angle-addr =3D [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr=20 > addr-spec =3D local-part "@" domain=20 > display-name =3D phrase=20 > Which means that pres addresses can look like pres:"name", = hence may contain " and <>. >=20 > Therefore I believe that the PRES-URI BNF is mistaken.=20 >=20 > Thanks, > Tamar. >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 29 07:50:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14686 for ; Mon, 29 Nov 2004 07:50:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYl45-0008BA-SL for sip-web-archive@ietf.org; Mon, 29 Nov 2004 07:55:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYkge-0001Mw-FQ; Mon, 29 Nov 2004 07:31:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYkeS-0000WM-1K for sip@megatron.ietf.org; Mon, 29 Nov 2004 07:29:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27807 for ; Mon, 29 Nov 2004 03:49:57 -0500 (EST) Received: from sand1.gxn.net ([195.147.249.207]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYhJE-0003EF-6N for sip@ietf.org; Mon, 29 Nov 2004 03:55:01 -0500 Received: from ip02.corenetltd.adsl.gxn.net ([195.147.83.74] helo=gblons002.Streamdoor.local) by sand1.gxn.net with esmtp (Exim 4.33) id 1CYhFO-0004v0-Ua; Mon, 29 Nov 2004 08:51:03 +0000 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] branch parameter in CANCEL Date: Mon, 29 Nov 2004 08:43:30 -0000 Message-ID: Thread-Topic: [Sip] branch parameter in CANCEL Thread-Index: AcTVzLw6eNrWoKbFQY2mEljj5ddGAgAIXLTg From: "Ben Gatewood" To: "murali foru" , X-Spam-Score: 1.1 (+) X-Scan-Signature: c6c6a408c8e09c950064e70d807ac007 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1511483125==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 5655aae64318292c42757ebeb53e54ce This is a multi-part message in MIME format. --===============1511483125== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4D5EF.80A4DD2A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4D5EF.80A4DD2A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Murali, =20 You are correct in your interpretation. The branch parameter for a CANCEL does need to be the same as the request it is canceling. In fact, it appears you are using a particular version of Cisco SIP firmware that has already been the subject of a TAC case I logged for exactly this problem. I suggest that if you upgrade the firmware on that phone the issue will be resolved. Also, this type of post probably belongs on SIP-IMPLEMENTORS rather than the IETF list. =20 HTH, =20 B =20 Ben Gatewood Lead Architect - IP Telephony Streamdoor Ltd. 114b Power Rd London=20 W4 5PY +44 20 7422 0439 +44 7835 136 187 bgatewood@streamdoor.net =20 =20 =20 ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of murali foru Sent: 29 November 2004 04:32 To: sip@ietf.org Subject: [Sip] branch parameter in CANCEL =20 Hi,=20 I wanted some clarification on the branch parameter in CANCEL. From what I Understand the branch parameter should be the same in the INVITE and the CANCEL(especially when using the magic cookie) so as to match the transaction being cancelled.=20 >From RFC 3261=20 The following procedures are used to construct a CANCEL request. The Request-URI, Call-ID, To, the numeric part of CSeq, and From header fields in the CANCEL request MUST be identical to those in the request being cancelled, including tags. A CANCEL constructed by a client MUST have only a single Via header field value matching the top Via value in the request being cancelled. Using the same values for these header fields allows the CANCEL to be matched with the request it cancels (Section 9.2 indicates how such matching occurs). However, the method part of the CSeq header field MUST have a value of CANCEL. This allows it to be identified and processed as a transaction! in its own right (See Section 17).=20 The branch parameter in the topmost Via header field of the request is examined. If it is present and begins with the magic cookie "z9hG4bK", the request was generated by a client transaction compliant to this specification. Therefore, the branch parameter will be unique across all transactions sent by that client. The request matches a transaction if:=20= 1. the branch parameter in the request is equal to the one in the top Via header field of the request that created the transaction, and=20 2. the sent-by value in the top Via of the request is equal to the one in the request that created the transaction, and=20 3. the method of the request matches the one that created the transaction, except for ACK, where the method of the request that created the transaction is INVITE.=20 This matching rule applies to both INVITE and non-INVITE transactions alike.=20 I would like to know if this is a correct CA! NCEL for the INVITE sent=20= INVITE sip:1@172.20.22.33 SIP/2.0=20 Max-Forwards: 10=20 Record-Route: =20= Via: SIP/2.0/UDP 172.20.22.102;branch=3Dz9hG4bK6ee8.484c8882.0=20 Via: SIP/2.0/UDP 172.20.22.75:5060;branch=3Dz9hG4bK39e838b9=20 From: "55" ;tag=3D001201544d1a001b1f8360ea-1cbce160= =20 To: =20 Call-ID: 00120154-4d1a001b-54ba3444-4e6b98f1@172.20.22.75=20 CSeq: 101 INVITE=20 User-Agent: CSCO/6=20 Contact: =20 Expires: 180=20 Content-Type: application/sdp=20 Content-Length: 247=20 Accept: application/sdp=20 v=3D0=20 o=3DCisco-SIPUA 14494 13084 IN IP4 172.20.22.75=20 s=3DSIP Call=20 c=3DIN IP4 172.20.22.75=20 t=3D0 0=20 m=3Daudio 18990 RTP/AVP 0 8 18 101=20 a=3Drtpmap:0 PCMU/8000=20 a=3Drtpmap:8 PCMA/8000=20 a=3Drtpmap:18 G729/8000=20 a=3Drtpmap:101 telephone-event/8000=20 a=3Dfmtp:101 0-15=20 SIP/2.! 0 180 Ringing=20 Via: SIP/2.0/UDP 172.20.22.102;branch=3D z9hG4bK6ee8.484c8882.0, SIP/2.0/UDP 172.20.22.75:5060;branch=3D z9hG4bK39e838b9=20 Record-Route: =20= To: ; tag=3D 3e7ca296=20 From: "55" ; tag=3D 001201544d1a001b1f8360ea-1cbce160=20 Call-ID: 00120154-4d1a001b-54ba3444-4e6b98f1@172.20.22.75=20 CSeq: 101 INVITE=20 Contact: =20 Content-Length: 0=20 CANCEL sip:1@172.20.22.33 SIP/2.0=20 Max-Forwards: 10=20 Record-Route: =20= Via: SIP/2.0/UDP 172.20.22.102;branch=3Dz9hG4bK6ee8.584c8882.0=20 Via: SIP/2.0/UDP 172.20.22.75:5060;branch=3Dz9hG4bK6a729507=20 From: "55" ;tag=3D001201544d1a001b1f8360ea-1cbce160= =20 To: =20 Call-ID: 00120154-4d1a001b-54ba3444-4e6b98f1@172.20.! 22.75=20 CSeq: 101 CANCEL=20 User-Agent: CSCO/6=20 Content-Length: 0=20 In the above case the branch parameter matching fails.=20 Regards,=20 Murali __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around=20 http://mail.yahoo.com ************************************************************************ ************** Disclaimer: This electronic message may contain privileged or confidential information. If you are not the intended recipient, be advised that any disclosure, copying, distribution or use of this information is strictly prohibited. If you are not the intended recipient, please notify the sender and delete this message. Views expressed in this message are those of the individual sender, and are not necessarily the views of the Streamdoor Limited, unless otherwise stated. Although Streamdoor Limited has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachement Employees of Streamdoor Limited and its affiliates are expressly required not to make defamatory statements and not to infringe or authorise any infringements of copyrights or any other legal right by email communications. Any such communication is contrary to company policy and outside the scope of the employment of the individual concerned. For further assistance on email policy, or if you have received this email in error, please contact Streamdoor Group IT&C Helpdesk by email at it&c_helpdesk@streamdoor.net or write to Streamdoor Ltd , Head of IT&C Department , 114 Power Road , Chiswick, London , W4 5PY. www.streamdoor.com ************************************************************************ **************=20 *************************************************************************= ************* Disclaimer: This electronic message may contain privileged or confidential informatio= n. If you are not the intended recipient, be advised that any disclosure,= copying, distribution or use of this information is strictly prohibited.= If you are not the intended recipient, please notify the sender and dele= te this message. Views expressed in this message are those of the individ= ual sender, and are not necessarily the views of the Streamdoor Limited, = unless otherwise stated. Although Streamdoor Limited has taken reasonable precautions to ensure no= viruses are present in this email, the company cannot accept responsibil= ity for any loss or damage arising from the use of this email or attachem= ent Employees of Streamdoor Limited and its affiliates are expressly required= not to make defamatory statements and not to infringe or authorise any i= nfringements of copyrights or any other legal right by email communicatio= ns. Any such communication is contrary to company policy and outside the = scope of the employment of the individual concerned. For further assistance on email policy, or if you have received this emai= l in error, please contact Streamdoor Group IT&C Helpdesk by email at it= &c_helpdesk@streamdoor.net or write to Streamdoor Ltd , Head of IT&C Dep= artment , 114 Power Road , Chiswick, London , W4 5PY. www.streamdoor.com *************************************************************************= ************* ------_=_NextPart_001_01C4D5EF.80A4DD2A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Murali,

=

 

You are correct in your interpretati= on. The branch parameter for a CANCEL does need to be the same as the request= it is canceling. In fact, it appears you are using a particular version of Cisc= o SIP firmware that has already been the subject of a TAC case I logged for exactly this= problem.

I suggest that if you upgrade the fi= rmware on that phone the issue will be resolved.

Also, this type of post probably bel= ongs on SIP-IMPLEMENTORS rather than the IETF list.

 

HTH,

 

B

 

Ben Gatewood

Lead Architect – IP Telephony<= o:p>

Streamdoor Ltd.

114b Power Rd=

London

W4 5PY

+44 20 7422 0439

+44 7835 136 187

bgatewood@streamdoor.net<= /span>

 

 

 

From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of murali foru
Sent: 29 November 2004 04:= 32
To: sip@ietf.org
Subject: [Sip] branch para= meter in CANCEL

 

Hi,

I wanted some clarification on the branch parameter in CANCEL. From what = I Understand the branch parameter should be the same in the INVITE and the CANCEL(especially when using the magic cookie) so as to match the transaction being cancelled.

>From RFC 3261

The following procedures are used to construct a CANCEL request. The Request-URI, Call-ID, To, the numeric part of CSeq, and From header field= s in the CANCEL request MUST be identical to those in the request being cancel= led, including tags. A CANCEL constr= ucted by a client MUST have only a single Via header field value matching the top = Via value in the request being cancelled. Using the same values for these hea= der fields allows the CANCEL to be matched with the request it cancels= (Section 9.2 indicates how such matching occurs). However, the method par= t of the CSeq header field MUST have a value of CANCEL. This allows it to be i= dentified and processed as a transaction! in its own right (See Section 17).


The branch parameter in the topmost Via header field of the request is examined. If it is present and begins with the magic cookie "z9hG4bK", the request was generated by a client transaction compliant to this specification. Therefore, the branch parameter will be = unique across all transactions sent by that client. The request matches a transa= ction if:

1. the branch parameter in the = request is equal to the one in the top Via header field of the request that creat= ed the transaction, and
2. the sent-by value in the top Via of the request is equal to the one in= the request that created the transaction, and
3. the method of the request matches the one that created the transaction= , except for ACK, where the method of the request that created the transaction is INVITE.

This matching rule applies to both INVITE and non-INVITE transactions ali= ke.


I would like to know if this is a correct CA! NCEL for the INVITE sent
INVITE sip:1@172.20.22.33 SIP/2.0
Max-Forwards: 10
Record-Route: <sip:1@172.20.22.102;ftag=3D001201544d1a001b1f8360ea-1cbce160;lr=3Don&= gt;
Via: SIP/2.0/UDP 172.20.22.102;branch=3Dz9hG4bK6ee8.484c8882.0
Via: SIP/2.0/UDP 172.20.22.75:5060;branch=3Dz9hG4bK39e838b9
From: "55" <sip:55@172.20.22.102>;tag=3D001201= 544d1a001b1f8360ea-1cbce160
To: <sip:1@172.20.22.33>
Call-ID: 00120154-4d1a001b-54ba3444-4e6b98f1@172.20.22.75
CSeq: 101 INVITE
User-Agent: CSCO/6
Contact: <sip:55@172.20.22.75:5060>
Expires: 180
Content-Type: application/sdp
Content-Length: 247
Accept: application/sdp

v=3D0
o=3DCisco-SIPUA 14494 13084 IN IP4 172.20.22.75
s=3DSIP Call
c=3DIN IP4 172.20.22.75
t=3D0 0
m=3Daudio 18990 RTP/AVP 0 8 18 101
a=3Drtpmap:0 PCMU/8000
a=3Drtpmap:8 PCMA/8000
a=3Drtpmap:18 G729/8000
a=3Drtpmap:101 telephone-event/8000
a=3Dfmtp:101 0-15


SIP/2.! 0 180 Ringing
Via: SIP/2.0/UDP 172.20.22.102;branch=3D z9hG4bK6ee8.484c8882.0, SIP/2.0/= UDP 172.20.22.75:5060;branch=3D z9hG4bK39e838b9
Record-Route: <sip:1@172.20.22.102;ftag=3D001201544d1a001b1f8360ea-1cb= ce160;lr=3Don>
To: <sip:1@172.20.22.33>; tag=3D 3e7ca296
From: "55" <sip:55@172.20.22.102>; tag=3D 001201544d1a001b1f8360ea-1cbce160
Call-ID: 00120154-4d1a001b-54ba3444-4e6b98f1@172.20.22.75
CSeq: 101 INVITE
Contact: <sip:1@172.20.22.33;transport=3DUDP>
Content-Length: 0


CANCEL sip:1@172.20.22.33 SIP/2.0
Max-Forwards: 10
Record-Route: <sip:1@172.20.22.102;ftag=3D001201544d1a001b1f8360ea-1cbce160;lr=3Don&= gt;
Via: SIP/2.0/UDP 172.20.22.102;branch=3Dz9hG4bK6ee8.584c8882.0
Via: SIP/2.0/UDP 172.20.22.75:5060;branch=3Dz9hG4bK6a729507
From: "55" <sip:55@172.20.22.102>;tag=3D001201544d1a001b1f8360ea-1cbce160
= To: <sip:1@172.20.22.33>
Call-ID: 00120154-4d1a001b-54ba3444-4e6b98f1@172.20.! 22.75
CSeq: 101 CANCEL
User-Agent: CSCO/6
Content-Length: 0

In the above case the branch parameter matching fails.

Regards,
Murali

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com ***************************************************= *********************************** Disclaimer: This electronic message may contain privileged or confidentia= l information. If you are not the intended recipient, be advised that any disclosure, copying, distribution or use of this information is strictly prohibited. If you are not the intended recipient, please notify the send= er and delete this message. Views expressed in this message are those of the individual sender, and are not necessarily the views of the Streamdoor Li= mited, unless otherwise stated. Although Streamdoor Limited has taken reasonable= precautions to ensure no viruses are present in this email, the company c= annot accept responsibility for any loss or damage arising from the use of this= email or attachement Employees of Streamdoor Limited and its affiliates are exp= ressly required not to make defamatory statements and not to infringe or authori= se any infringements of copyrights or any other legal right by email communicati= ons. Any such communication is contrary to company policy and outside the scop= e of the employment of the individual concerned. For further assistance on ema= il policy, or if you have received this email in error, please contact Strea= mdoor Group IT&C Helpdesk by email at it&c_helpdesk@streamdoor.net or w= rite to Streamdoor Ltd , Head of IT&C Department , 114 Power Road , Chiswi= ck, London , W4 5PY. www.streamdoor.com *************************************************************************= *************

*************************************************************************= *************
Disclaimer:

This electronic message may contain p= rivileged or confidential information. If you are not the intended recipi= ent, be advised that any disclosure, copying, distribution or use of this= information is strictly prohibited. If you are not the intended recipien= t, please notify the sender and delete this message. Views expressed in t= his message are those of the individual sender, and are not necessarily t= he views of the Streamdoor Limited, unless otherwise stated.

Altho= ugh Streamdoor Limited has taken reasonable precautions to ensure no viru= ses are present in this email, the company cannot accept responsibility f= or any loss or damage arising from the use of this email or attachement
Employees of Streamdoor Limited and its affiliates are expressly re= quired not to make defamatory statements and not to infringe or authorise= any infringements of copyrights or any other legal right by email commun= ications. Any such communication is contrary to company policy and outsid= e the scope of the employment of the individual concerned.

For fur= ther assistance on email policy, or if you have received this email in er= ror, please contact Streamdoor Group IT&C Helpdesk by email at it&c_helpd= esk@streamdoor.net or write to Streamdoor Ltd , Head of IT&C Department ,= 114 Power Road , Chiswick, London , W4 5PY.

www.streamdoor.com************************************************************************= ************** ------_=_NextPart_001_01C4D5EF.80A4DD2A-- --===============1511483125== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1511483125==-- From sip-bounces@ietf.org Mon Nov 29 16:48:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14166 for ; Mon, 29 Nov 2004 16:48:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYtT4-0007PQ-3t for sip-web-archive@ietf.org; Mon, 29 Nov 2004 16:53:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYs29-00014L-M3; Mon, 29 Nov 2004 15:22:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYrxP-0006fh-MR; Mon, 29 Nov 2004 15:17:11 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27162; Mon, 29 Nov 2004 15:17:10 -0500 (EST) Message-Id: <200411292017.PAA27162@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 29 Nov 2004 15:17:09 -0500 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-sctp-05.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : The Stream Control Transmission Protocol as a Transport for for the Session Initiation Protocol Author(s) : J. Rosenberg, et al. Filename : draft-ietf-sip-sctp-05.txt Pages : 9 Date : 2004-11-29 This document specifies a mechanism for usage of SCTP (the Stream Control Transmission Protocol) as the transport between SIP (Session Initiation Protocol) entities. SCTP is a new protocol which provides several features that may prove beneficial for transport between SIP entities which exchange a large amount of messages, including gateways and proxies. As SIP is transport independent, support of SCTP is a relatively straightforward process, nearly identical to support for TCP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-sctp-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-sctp-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-sctp-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-11-29152339.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-sctp-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-sctp-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-11-29152339.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Tue Nov 30 01:05:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26257 for ; Tue, 30 Nov 2004 01:05:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ1Dm-0002Jv-AE for sip-web-archive@ietf.org; Tue, 30 Nov 2004 01:10:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ13x-0008NF-8L; Tue, 30 Nov 2004 01:00:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ0xO-0006q5-Bx; Tue, 30 Nov 2004 00:53:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25625; Tue, 30 Nov 2004 00:53:43 -0500 (EST) Received: from mail4.telekom.de ([195.243.210.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ12O-00027G-CK; Tue, 30 Nov 2004 00:58:59 -0500 Received: from g8pbq.blf01.telekom.de by mail2.dmz.telekom.de with ESMTP; Tue, 30 Nov 2004 06:52:49 +0100 Received: by G8PBQ.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Nov 2004 06:52:59 +0100 Message-Id: From: "Jesske, R" To: iptel@ietf.org, sip@ietf.org Date: Tue, 30 Nov 2004 06:52:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Sip] Calling Party's Category X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Dear all, in the past there was a discussion regarding the specification of a Calling Party's Category for SIP. (draft-mahy-iptel-cpc-00.txt) What is the actual status of this activity. We are still interested in such kind of originating indication if the call/communication is coming from a normal SIP user or a SIP -Payphone or SIP-Hotelphone. Is there a interest from other parties in this issue? Best Regards Roland Deutsche Telekom AG T-Com Zentrale Roland Jesske, TE332-2 Section TE33; 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 sip-bounces@ietf.org Tue Nov 30 02:55:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18007 for ; Tue, 30 Nov 2004 02:55:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ2wG-0004Hv-RZ for sip-web-archive@ietf.org; Tue, 30 Nov 2004 03:00:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ2lA-0002GH-Dr; Tue, 30 Nov 2004 02:49:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ2eR-0008GW-IZ for sip@megatron.ietf.org; Tue, 30 Nov 2004 02:42:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17033 for ; Tue, 30 Nov 2004 02:42:18 -0500 (EST) Received: from [80.74.106.125] (helo=rvil-mail.RADVISION.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ2jR-000403-QI for sip@ietf.org; Tue, 30 Nov 2004 02:47:34 -0500 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="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Mistake in PRES-URI BNF Date: Tue, 30 Nov 2004 09:41:42 +0200 Message-ID: <10DA2C035FE3BC4FA8D73EC55FC43D9B5A3A71@rvil-mail.radvision.com> Thread-Topic: Mistake in PRES-URI BNF Thread-Index: AcTWCaDjM4FIQsWjTuS7Fjes8AVjBwAAo34QACjqB0A= From: "Sarit Galanos" To: "Tamar Barzuza" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Hi, I also think that there is a critical problem with the BNF. According to the BNF the following From header is valid: From: Bob> This means that the pres address has the "<" in it (and not around it). This is not valid according the generic URI syntax. How should such and address be parsed??? Basically, I think that the problem is the fact that the pres URI = contains a mailbox and not an addr-spec in it. Thanks, Sarit. -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of Tamar Barzuza Sent: Monday, November 29, 2004 2:09 PM To: sip@ietf.org Subject: [Sip] Mistake in PRES-URI BNF > Hi, >=20 > I found a problem in the BNF of PRES-URI. >=20 > RFC 2396 defined the generic syntax of URI. It explicitly says that = the following (delims) characters are disallowed within URI: > delims=3D "<" | ">" | "#" | "%" | <">=20 >=20 > However, in RFCs 3859 and 2822 the definition for PRES-URI is: > PRES URI =3D "pres:" [ to ] [ headers ]=20 > to =3D mailbox=20 > mailbox =3D name-addr / addr-spec=20 > name-addr =3D [display-name] angle-addr=20 > angle-addr =3D [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr=20 > addr-spec =3D local-part "@" domain=20 > display-name =3D phrase=20 > Which means that pres addresses can look like pres:"name", = hence may contain " and <>. >=20 > Therefore I believe that the PRES-URI BNF is mistaken.=20 >=20 > Thanks, > Tamar. >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 30 05:47:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03918 for ; Tue, 30 Nov 2004 05:47:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ5d0-00087X-Bl for sip-web-archive@ietf.org; Tue, 30 Nov 2004 05:53:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ5UJ-0002mu-89; Tue, 30 Nov 2004 05:44:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXhoV-0007i0-Jp for sip@megatron.ietf.org; Fri, 26 Nov 2004 10:15:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17848 for ; Fri, 26 Nov 2004 03:21:58 -0500 (EST) Received: from web54206.mail.yahoo.com ([206.190.39.248]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CXbQr-0002Gy-Gv for sip@ietf.org; Fri, 26 Nov 2004 03:26:22 -0500 Received: (qmail 40171 invoked by uid 60001); 26 Nov 2004 08:21:27 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=MpB0qTfArezSmsxwxxl5I6OxzZdPw9DxxStyMwjiFyZlUfFTvDgm99J3DFHrfksf8o99eXYdvf/nKaGjcZ+B60rAN5DGjjxf8r2OSmQhowi9WclwS9EVEXJhxbrjujdKuTGD40vw2YPSgmoXi8Lxv4i/g6d9A0pJoqxfdD5gPXo= ; Message-ID: <20041126082127.40168.qmail@web54206.mail.yahoo.com> Received: from [217.45.197.113] by web54206.mail.yahoo.com via HTTP; Fri, 26 Nov 2004 00:21:27 PST Date: Fri, 26 Nov 2004 00:21:27 -0800 (PST) From: Rayees Khan Subject: Re: [SIP] RFC 3725, clarification To: Srinivasa Rao , sip@ietf.org In-Reply-To: <075a01c4d375$6d4eed60$9c01ff0a@axws72> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-Mailman-Approved-At: Tue, 30 Nov 2004 05:44:01 -0500 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rakhan@hssworld.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Yes, I guess both of them mean the same. regards Rayees --- Srinivasa Rao wrote: > Hi, > Anybody please clarify me about the difference of > point 1 : "Offers and answers that contain a > connection line > with an address of 0.0.0.0." > > point 7 : "SDP Connection address of zero" of > section 11, in RFC 3725 > (3pcc). > > Are both really mean the same? > I tried the answer in mail archive, but no luck > :( . > > Thanks > Srinivasa Rao > > > > > _______________________________________________ > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP > Protocol > Use sip-implementors@cs.columbia.edu for questions > on current sip > Use sipping@ietf.org for new developments on the > application of sip > __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 30 09:55:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24469 for ; Tue, 30 Nov 2004 09:55:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ9V3-0005bb-4T for sip-web-archive@ietf.org; Tue, 30 Nov 2004 10:01:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ9LS-0006Rn-66; Tue, 30 Nov 2004 09:51:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ9HE-0004nR-HG for sip@megatron.ietf.org; Tue, 30 Nov 2004 09:46:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23426 for ; Tue, 30 Nov 2004 09:46:46 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ9MJ-0005Ho-Al for sip@ietf.org; Tue, 30 Nov 2004 09:52:06 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 30 Nov 2004 06:52:23 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iAUEkBAC015739; Tue, 30 Nov 2004 06:46:11 -0800 (PST) Received: from cisco.com ([64.101.172.112]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ANI79335; Tue, 30 Nov 2004 09:46:08 -0500 (EST) Message-ID: <41AC87AE.5040208@cisco.com> Date: Tue, 30 Nov 2004 09:46:06 -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: Adam Roach Subject: Re: [Sip] Event List Changes References: <41A54C97.9000807@nostrum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: 7bit Adam, In general I think this is a reasonable compromise in order to make progress in the near term. However, I think you have been a bit heavy handed in the restrictions. You say: "any RLS which uses SIP back-end subscriptions to acquire information about the resources in a resource list MUST be able to act as an authentication service" This means that any RLS implementation that does back-end subscriptions MUST be a privileged member of the domain, so that it may act as an authentication service. While this may be a reasonable strategy in many cases, it still ought to be possible for someone to build an RLS that isn't so priviliged. One that isn't just won't be about to use the original subscriber's identity in the back-end subscriptions, and instead will have to either generate subscriptions with no identity, or with its own identity - same as when handling subscribers from outside its domain. Paul Adam Roach wrote: > I'm revising the event list draft currently. In DC, we discussed at > length the authentication model for situations in which the RLS and > subscriber are in the same domain; I believe I've captured this pretty > well (but encourage interested parties to double check my interpretation > of consensus). > > When I went to update the document, however, I found that there was > still something of a hole for the other case -- the one we described as > a corner case. I know that we agreed that (1) additional mechanism could > be developed to solve this case, and (2) we didn't want to wait for > these mechanisms before publishing the event list document. However, I > don't remember discussing what RLS implementors can do when they receive > a request for a list resource from a user outside their domain. > > So, I came up with what seemed like the most logical solution, given the > other discussions we had. Before I submit -07 of the document, I'd like > to have a few people look over my proposed text; if you think this is > the wrong direction to take it, speak up now. If I get no comments > before the end of next week, I'll submit the draft with the following > language. > >> 7.1 Authentication >> >> If back-end subscriptions are required to retrieve resource state >> information, the end user is no longer the direct subscriber to the >> state of the resource. This means that direct authentication of the >> user is no longer possible. >> >> 7.1.1 RLS and Subscriber in the Same Domain >> >> It is expected that the most common deployment of RLSes entails the >> subscribers to the RLS being in the same domain as the RLS. When >> this is the case, the RLS then has the ability to act as an >> authenication service. The role of authentication service is defined >> in "Enhancements for Authenticated Identity Management in the Session >> Initiation Protocol (SIP)" [7]. >> >> At a high level, under this system, the RLS authenticates the >> subscriber, and then includes an "Identity" header field in all of >> the back-end subscriptions performed on behalf of that authenticated >> user; this "Identity" header field cryptographically asserts that the >> request has been authorized to be made on behalf of the user >> indicated in the "From" header field. >> >> Because the ability to authenticate requests is central to the proper >> functioning of the network, any RLS which uses SIP back-end >> subscriptions to acquire information about the resources in a >> resource list MUST be able to act as an authentication service as >> defined in [7]. >> >> 7.1.2 RLS and Subscriber in Different Domains >> >> In the general case, the SIP Authenticated Identity extensions do not >> provide a means for the RLS to securely assert that subscriptions are >> being performed on the end user's behalf. Specifically, when the >> subscriber and the RLS are in different domains, the RLS will have no >> means by which it can vouch for the user's identity. Mechanisms by >> which back-end subscriptions in such circumstances can be >> authenticated are left for future study. >> >> Until such general solutions are developed, RLSes which are in a >> different domain than the subscriber on whose behalf they are >> creating back-end susbcriptions SHOULD subscribe to the resources >> using their own identity. By doing so, the RLS will generally obtain >> only the resource information which is made publicly available. >> >> Absent such general solutions, implemenations of subscriber user >> agents MAY attempt direct subscriptions to resources in the resouce >> list when subscribing to an RLS outside of their domain (either >> directly or by way of another resource list subscription). The >> resouces to be subscribed to will be those indicated in the the "uri" >> attribute of the elements present in the RLMI document >> returned by the RLS. Directly subscribing to the resources allows >> proper authentication of the user to take place, which will generally >> authorize them to receive more complete state information. >> Implementations which choose to perform such direct subscriptions >> SHOULD use the data retrieved directly to the exclusion of any >> information about the resource obtained via the list subscription. > > > > /a > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 30 10:19:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27252 for ; Tue, 30 Nov 2004 10:19:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ9s5-0006B6-PX for sip-web-archive@ietf.org; Tue, 30 Nov 2004 10:24:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ9e8-0007U6-8F; Tue, 30 Nov 2004 10:10:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ9bh-0006B0-C5; Tue, 30 Nov 2004 10:07:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25721; Tue, 30 Nov 2004 10:07:55 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ9go-0005uZ-E2; Tue, 30 Nov 2004 10:13:15 -0500 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iAUF7Ff16089; Tue, 30 Nov 2004 10:07:16 -0500 (EST) Received: from [47.130.24.149] (acart16j.ca.nortel.com [47.130.24.149]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id W14FSKSS; Tue, 30 Nov 2004 10:07:16 -0500 Message-ID: <41AC8CA2.8060509@nortelnetworks.com> Date: Tue, 30 Nov 2004 10:07:14 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Jesske, R" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: iptel@ietf.org, sip@ietf.org Subject: [Sip] Re: [Iptel] Calling Party's Category X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit The question was what the requirement is for this sort of indication. How is it used? Jesske, R wrote: > Dear all, > in the past there was a discussion regarding the specification of a Calling Party's Category for SIP. (draft-mahy-iptel-cpc-00.txt) > What is the actual status of this activity. > We are still interested in such kind of originating indication if the call/communication is coming from a normal SIP user or a SIP -Payphone or SIP-Hotelphone. > Is there a interest from other parties in this issue? > > Best Regards > > Roland > > Deutsche Telekom AG > T-Com Zentrale > Roland Jesske, TE332-2 > Section TE33; 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 > > > > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel > > -- Tom Taylor Carrier VoIP Standards Development Nortel Networks Phone +1 613 763 1496 (ESN 393-1496) E-mail: taylor@nortelnetworks.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 30 10:58:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00942 for ; Tue, 30 Nov 2004 10:58:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZAUD-00075J-Th for sip-web-archive@ietf.org; Tue, 30 Nov 2004 11:04:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZACF-0001D4-VQ; Tue, 30 Nov 2004 10:45:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZA9R-0000Hx-Me; Tue, 30 Nov 2004 10:42:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29529; Tue, 30 Nov 2004 10:42:46 -0500 (EST) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZAEZ-0006gv-96; Tue, 30 Nov 2004 10:48:07 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 30 Nov 2004 16:42:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Nov 2004 16:42:07 +0100 Message-ID: <49E7012A614B024B80A7D175CB9A64ECB0491A@ftrdmel1.rd.francetelecom.fr> Thread-Topic: [Iptel] Calling Party's Category Thread-Index: AcTW79aHtvI/2vXjS22xVk51c/AvHwAAyh6w From: "GARCIN Sebastien RD-CORE-ISS" To: "Tom Taylor" , "Jesske, R" X-OriginalArrivalTime: 30 Nov 2004 15:42:45.0328 (UTC) FILETIME=[3C7A9500:01C4D6F3] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: quoted-printable Cc: iptel@ietf.org, sip@ietf.org Subject: [Sip] RE: [Iptel] Calling Party's Category X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable Hi, As an fixed line operator we also are interested in this feature and = would be happy that the IETF finally moves forward with this draft. This = type of parameter is widely signalled in ISDN/PSTN networks. In SIP (for = example) it is required in context of both: - pure SIP networks (e.g. in case of a SIP payphone), and - interworking with legacy networks=20 I think the uses case for this parameter will depend on the operator = service portfolio. For example, in France, the calling party's category = parameter is used for the Call Return service. Best regards, sebastien=20 -----Message d'origine----- De : iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] De la part = de Tom Taylor Envoy=E9 : mardi 30 novembre 2004 16:07 =C0 : Jesske, R Cc : iptel@ietf.org; sip@ietf.org Objet : Re: [Iptel] Calling Party's Category The question was what the requirement is for this sort of indication. = How is it used? Jesske, R wrote: > Dear all, > in the past there was a discussion regarding the specification of a=20 > Calling Party's Category for SIP. (draft-mahy-iptel-cpc-00.txt) What = is the actual status of this activity. > We are still interested in such kind of originating indication if the = call/communication is coming from a normal SIP user or a SIP -Payphone = or SIP-Hotelphone.=20 > Is there a interest from other parties in this issue? >=20 > Best Regards >=20 > Roland >=20 > Deutsche Telekom AG > T-Com Zentrale > Roland Jesske, TE332-2 > Section TE33; Signalling, Gateways and Switching Systems Am=20 > Kavalleriesand 3, 64295 Darmstadt, Germany > Phone: +49 6151 83-5940=20 > Fax: +49 6151 83-4577=20 > email: r.jesske@t-com.net >=20 >=20 >=20 >=20 > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel >=20 >=20 -- Tom Taylor Carrier VoIP Standards Development Nortel Networks Phone +1 613 763 1496 (ESN 393-1496) E-mail: taylor@nortelnetworks.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 30 11:32:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04119 for ; Tue, 30 Nov 2004 11:32:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZB0F-00081f-4V for sip-web-archive@ietf.org; Tue, 30 Nov 2004 11:37:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZAie-0001ub-S8; Tue, 30 Nov 2004 11:19:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZAW8-00077X-EY for sip@megatron.ietf.org; Tue, 30 Nov 2004 11:06:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01527 for ; Tue, 30 Nov 2004 11:06:13 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZAbG-0007Gw-Uv for sip@ietf.org; Tue, 30 Nov 2004 11:11:35 -0500 Received: from [192.168.0.108] (adsl-209-30-33-13.dsl.rcsntx.swbell.net [209.30.33.13]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iAUG69BU013461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Nov 2004 10:06:10 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <41AC9A68.9020303@nostrum.com> Date: Tue, 30 Nov 2004 10:06:00 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] Event List Changes References: <41A54C97.9000807@nostrum.com> <41AC87AE.5040208@cisco.com> In-Reply-To: <41AC87AE.5040208@cisco.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > In general I think this is a reasonable compromise in order to make > progress in the near term. However, I think you have been a bit heavy > handed in the restrictions. You say: > > "any RLS which uses SIP back-end > subscriptions to acquire information about the resources in a > resource list MUST be able to act as an authentication service" > > This means that any RLS implementation that does back-end > subscriptions MUST be a privileged member of the domain, so that it > may act as an authentication service. Good point. I was trying to capture the apparent consensus in DC that the SIP Identity draft is mandatory to implement (optional to use) in RLSes. As you point out, I have probably gone too far, since my phrasing implies certain administrative details instead of stopping at implementation details. I'll re-work the language so that it applies only to implementation, and not to deployment. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 30 11:44:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05521 for ; Tue, 30 Nov 2004 11:44:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZBCR-0008Ni-3m for sip-web-archive@ietf.org; Tue, 30 Nov 2004 11:49:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZB09-0006qe-5a; Tue, 30 Nov 2004 11:37:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZAnD-0003PX-3E; Tue, 30 Nov 2004 11:23:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03537; Tue, 30 Nov 2004 11:23:52 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZAsK-0007oD-Uo; Tue, 30 Nov 2004 11:29:14 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 30 Nov 2004 08:27:57 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iAUGNKdG013497; Tue, 30 Nov 2004 08:23:21 -0800 (PST) Received: from [10.32.245.156] (stealth-10-32-245-156.cisco.com [10.32.245.156]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id iAUGMpvl001146; Tue, 30 Nov 2004 08:22:51 -0800 In-Reply-To: <49E7012A614B024B80A7D175CB9A64ECB0491A@ftrdmel1.rd.francetelecom.fr> References: <49E7012A614B024B80A7D175CB9A64ECB0491A@ftrdmel1.rd.francetelecom.fr> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <23EA088E-42EC-11D9-8CD3-000A95C73842@cisco.com> Content-Transfer-Encoding: quoted-printable From: David R Oran Subject: Re: [Sip] RE: [Iptel] Calling Party's Category Date: Tue, 30 Nov 2004 11:23:16 -0500 To: "GARCIN Sebastien RD-CORE-ISS" X-Mailer: Apple Mail (2.619) IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1101831772.374646"; x:"432200"; a:"rsa-sha1"; b:"nofws:3380"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"j29HsIm21RWrcGAEqmZ5oaMbr0XzETWpeBQnoA1nFs6igf7/UVxxIhRulvNVh" "jGKCaP84NHQaCN5uKkMyvC/tAM49JNU31aLMJ00+H+etfqPnqX7HGt3XpxqWR" "iX0NRh5/c8SlhS1FgZOhhc3zVrcMYXNdmGPJb2S4jz5rnEGQw="; c:"From: David R Oran "; c:"Subject: Re: [Sip] RE: [Iptel] Calling Party's Category"; c:"Date: Tue, 30 Nov 2004 11:23:16 -0500" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: quoted-printable Cc: "Jesske, R" , iptel@ietf.org, Tom Taylor , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: quoted-printable On Nov 30, 2004, at 10:42 AM, GARCIN Sebastien RD-CORE-ISS wrote: > Hi, > > As an fixed line operator we also are interested in this feature and=20= > would be happy that the IETF finally moves forward with this draft.=20 > This type of parameter is widely signalled in ISDN/PSTN networks. In=20= > SIP (for example) it is required in context of both: > > - pure SIP networks (e.g. in case of a SIP payphone), and > - interworking with legacy networks > > I think the uses case for this parameter will depend on the operator=20= > service portfolio. For example, in France, the calling party's=20 > category parameter is used for the Call Return service. > Could you explain a bit about how this is used? I, for one would find=20 it helpful and possibly a motivating use case. Also note that if this information is used for any security or=20 billing-sensitive operations, we have to deal with the issue of how to=20= secure it against spoofing (SIP UAs are generally not trusted). Would=20 you believe a call made by Robert Mitnick from a prison phone would=20 actually have a prison CPC in it's SIP headers :-) ? (Mitnick is a widely known phone freak and network hacker who served a=20= number of years in US prisons). > Best regards, > sebastien > > -----Message d'origine----- > De : iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] De la part=20= > de Tom Taylor > Envoy=E9 : mardi 30 novembre 2004 16:07 > =C0 : Jesske, R > Cc : iptel@ietf.org; sip@ietf.org > Objet : Re: [Iptel] Calling Party's Category > > The question was what the requirement is for this sort of indication. =20= > How is it used? > > Jesske, R wrote: >> Dear all, >> in the past there was a discussion regarding the specification of a >> Calling Party's Category for SIP. (draft-mahy-iptel-cpc-00.txt) What=20= >> is the actual status of this activity. >> We are still interested in such kind of originating indication if the=20= >> call/communication is coming from a normal SIP user or a SIP=20 >> -Payphone or SIP-Hotelphone. >> Is there a interest from other parties in this issue? >> >> Best Regards >> >> Roland >> >> Deutsche Telekom AG >> T-Com Zentrale >> Roland Jesske, TE332-2 >> Section TE33; 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 >> >> >> >> >> _______________________________________________ >> Iptel mailing list >> Iptel@ietf.org >> https://www1.ietf.org/mailman/listinfo/iptel >> >> > > -- > Tom Taylor > Carrier VoIP Standards Development > Nortel Networks > Phone +1 613 763 1496 (ESN 393-1496) > E-mail: taylor@nortelnetworks.com > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran@cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 30 12:06:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07615 for ; Tue, 30 Nov 2004 12:06:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZBXX-0000Vk-Gh for sip-web-archive@ietf.org; Tue, 30 Nov 2004 12:11:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZBHl-0003Kr-U0; Tue, 30 Nov 2004 11:55:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZBEd-0002H2-ME; Tue, 30 Nov 2004 11:52:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06172; Tue, 30 Nov 2004 11:52:12 -0500 (EST) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZBJm-00008K-Nd; Tue, 30 Nov 2004 11:57:35 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 30 Nov 2004 17:52:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: [Iptel] Calling Party's Category Date: Tue, 30 Nov 2004 17:51:33 +0100 Message-ID: <49E7012A614B024B80A7D175CB9A64ECB049CD@ftrdmel1.rd.francetelecom.fr> Thread-Topic: [Sip] RE: [Iptel] Calling Party's Category Thread-Index: AcTW+OnWQZTKFAeiT9uHpwiKSO9fTAAAt84w From: "GARCIN Sebastien RD-CORE-ISS" To: "David R Oran" X-OriginalArrivalTime: 30 Nov 2004 16:52:11.0734 (UTC) FILETIME=[EFD9AF60:01C4D6FC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: quoted-printable Cc: "Jesske, R" , iptel@ietf.org, Tom Taylor , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: quoted-printable In the Call Return service, a destination exchange memories an incoming = call which failed due to non-reply. If the call was orginated by a = payphone then the destination exchange does not memories the number = since it makes no sense in calling back a payphone.=20 BR, sebastien =20 -----Message d'origine----- De : David R Oran [mailto:oran@cisco.com]=20 Envoy=E9 : mardi 30 novembre 2004 17:23 =C0 : GARCIN Sebastien RD-CORE-ISS Cc : Jesske, R; Tom Taylor; iptel@ietf.org; sip@ietf.org Objet : Re: [Sip] RE: [Iptel] Calling Party's Category On Nov 30, 2004, at 10:42 AM, GARCIN Sebastien RD-CORE-ISS wrote: > Hi, > > As an fixed line operator we also are interested in this feature and=20 > would be happy that the IETF finally moves forward with this draft. > This type of parameter is widely signalled in ISDN/PSTN networks. In=20 > SIP (for example) it is required in context of both: > > - pure SIP networks (e.g. in case of a SIP payphone), and > - interworking with legacy networks > > I think the uses case for this parameter will depend on the operator=20 > service portfolio. For example, in France, the calling party's=20 > category parameter is used for the Call Return service. > Could you explain a bit about how this is used? I, for one would find it = helpful and possibly a motivating use case. Also note that if this information is used for any security or = billing-sensitive operations, we have to deal with the issue of how to = secure it against spoofing (SIP UAs are generally not trusted). Would = you believe a call made by Robert Mitnick from a prison phone would = actually have a prison CPC in it's SIP headers :-) ? (Mitnick is a widely known phone freak and network hacker who served a = number of years in US prisons). > Best regards, > sebastien > > -----Message d'origine----- > De : iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] De la part = > de Tom Taylor Envoy=E9 : mardi 30 novembre 2004 16:07 =C0 : Jesske, R = Cc :=20 > iptel@ietf.org; sip@ietf.org Objet : Re: [Iptel] Calling Party's=20 > Category > > The question was what the requirement is for this sort of indication. = > How is it used? > > Jesske, R wrote: >> Dear all, >> in the past there was a discussion regarding the specification of a=20 >> Calling Party's Category for SIP. (draft-mahy-iptel-cpc-00.txt) What=20 >> is the actual status of this activity. >> We are still interested in such kind of originating indication if the = >> call/communication is coming from a normal SIP user or a SIP=20 >> -Payphone or SIP-Hotelphone. >> Is there a interest from other parties in this issue? >> >> Best Regards >> >> Roland >> >> Deutsche Telekom AG >> T-Com Zentrale >> Roland Jesske, TE332-2 >> Section TE33; Signalling, Gateways and Switching Systems Am=20 >> Kavalleriesand 3, 64295 Darmstadt, Germany >> Phone: +49 6151 83-5940 >> Fax: +49 6151 83-4577 >> email: r.jesske@t-com.net >> >> >> >> >> _______________________________________________ >> Iptel mailing list >> Iptel@ietf.org >> https://www1.ietf.org/mailman/listinfo/iptel >> >> > > -- > Tom Taylor > Carrier VoIP Standards Development > Nortel Networks > Phone +1 613 763 1496 (ESN 393-1496) > E-mail: taylor@nortelnetworks.com > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > sipping@ietf.org for new developments on the application of sip > David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran@cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 30 12:27:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09328 for ; Tue, 30 Nov 2004 12:27:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZBrT-00013m-0E for sip-web-archive@ietf.org; Tue, 30 Nov 2004 12:32:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZBOq-0005Y4-PT; Tue, 30 Nov 2004 12:02:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZBGW-0002tC-Kq; Tue, 30 Nov 2004 11:54:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06403; Tue, 30 Nov 2004 11:54:09 -0500 (EST) Received: from sand2.gxn.net ([195.147.249.208]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZBLc-0000Az-FY; Tue, 30 Nov 2004 11:59:31 -0500 Received: from ip02.corenetltd.adsl.gxn.net ([195.147.83.74] helo=gblons002.Streamdoor.local) by sand2.gxn.net with esmtp (Exim 4.33) id 1CZBH2-0007Q5-3A; Tue, 30 Nov 2004 16:54:45 +0000 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] RE: [Iptel] Calling Party's Category Date: Tue, 30 Nov 2004 16:47:00 -0000 Message-ID: Thread-Topic: [Sip] RE: [Iptel] Calling Party's Category Thread-Index: AcTW+ukGCjEsBDmhRFaneh+gjU+kpgAAFGsj From: "Ben Gatewood" To: "David R Oran" , "GARCIN Sebastien RD-CORE-ISS" X-Spam-Score: 0.2 (/) X-Scan-Signature: 231d7929942febf3be8fd5be2903302f Cc: "Jesske, R" , iptel@ietf.org, Tom Taylor , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1756058855==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 94902b99ee6852833c9a2b680a1de4d3 This is a multi-part message in MIME format. --===============1756058855== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4D6FC.361BFF68" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4D6FC.361BFF68 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable His name is Kevin. Other than that I agree with you. I'm interested in this area as well as I might be able to make use of thi= s type of functionality in a hospitality industry scenario.=20 Regards, B http://www.freekevin.com/ Ben Gatewood Streamdoor Ltd 114b Power Rd London W4 5PY +44 20 7422 0439 +44 7835 136 187 bgatewood@streamdoor.net -----Original Message----- From: sip-bounces@ietf.org on behalf of David R Oran Sent: Tue 11/30/2004 4:23 PM To: GARCIN Sebastien RD-CORE-ISS Cc: Jesske, R; iptel@ietf.org; Tom Taylor; sip@ietf.org Subject: Re: [Sip] RE: [Iptel] Calling Party's Category =20 On Nov 30, 2004, at 10:42 AM, GARCIN Sebastien RD-CORE-ISS wrote: > Hi, > > As an fixed line operator we also are interested in this feature and=20= > would be happy that the IETF finally moves forward with this draft.=20 > This type of parameter is widely signalled in ISDN/PSTN networks. In=20= > SIP (for example) it is required in context of both: > > - pure SIP networks (e.g. in case of a SIP payphone), and > - interworking with legacy networks > > I think the uses case for this parameter will depend on the operator=20= > service portfolio. For example, in France, the calling party's=20 > category parameter is used for the Call Return service. > Could you explain a bit about how this is used? I, for one would find=20 it helpful and possibly a motivating use case. Also note that if this information is used for any security or=20 billing-sensitive operations, we have to deal with the issue of how to=20= secure it against spoofing (SIP UAs are generally not trusted). Would=20 you believe a call made by Robert Mitnick from a prison phone would=20 actually have a prison CPC in it's SIP headers :-) ? (Mitnick is a widely known phone freak and network hacker who served a=20= number of years in US prisons). > Best regards, > sebastien > > -----Message d'origine----- > De : iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] De la part=20= > de Tom Taylor > Envoy=E9 : mardi 30 novembre 2004 16:07 > =C0 : Jesske, R > Cc : iptel@ietf.org; sip@ietf.org > Objet : Re: [Iptel] Calling Party's Category > > The question was what the requirement is for this sort of indication. =20= > How is it used? > > Jesske, R wrote: >> Dear all, >> in the past there was a discussion regarding the specification of a >> Calling Party's Category for SIP. (draft-mahy-iptel-cpc-00.txt) What=20= >> is the actual status of this activity. >> We are still interested in such kind of originating indication if the=20= >> call/communication is coming from a normal SIP user or a SIP=20 >> -Payphone or SIP-Hotelphone. >> Is there a interest from other parties in this issue? >> >> Best Regards >> >> Roland >> >> Deutsche Telekom AG >> T-Com Zentrale >> Roland Jesske, TE332-2 >> Section TE33; 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 >> >> >> >> >> _______________________________________________ >> Iptel mailing list >> Iptel@ietf.org >> https://www1.ietf.org/mailman/listinfo/iptel >> >> > > -- > Tom Taylor > Carrier VoIP Standards Development > Nortel Networks > Phone +1 613 763 1496 (ESN 393-1496) > E-mail: taylor@nortelnetworks.com > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran@cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip *************************************************************************= ************* Disclaimer: This electronic message may contain privileged or confidential informatio= n. If you are not the intended recipient, be advised that any disclosure,= copying, distribution or use of this information is strictly prohibited.= If you are not the intended recipient, please notify the sender and dele= te this message. Views expressed in this message are those of the individ= ual sender, and are not necessarily the views of the Streamdoor Limited, = unless otherwise stated. Although Streamdoor Limited has taken reasonable precautions to ensure no= viruses are present in this email, the company cannot accept responsibil= ity for any loss or damage arising from the use of this email or attachem= ent Employees of Streamdoor Limited and its affiliates are expressly required= not to make defamatory statements and not to infringe or authorise any i= nfringements of copyrights or any other legal right by email communicatio= ns. Any such communication is contrary to company policy and outside the = scope of the employment of the individual concerned. For further assistance on email policy, or if you have received this emai= l in error, please contact Streamdoor Group IT&C Helpdesk by email at it= &c_helpdesk@streamdoor.net or write to Streamdoor Ltd , Head of IT&C Dep= artment , 114 Power Road , Chiswick, London , W4 5PY. www.streamdoor.com *************************************************************************= ************* *************************************************************************= ************* Disclaimer: This electronic message may contain privileged or confidential informatio= n. If you are not the intended recipient, be advised that any disclosure,= copying, distribution or use of this information is strictly prohibited.= If you are not the intended recipient, please notify the sender and dele= te this message. Views expressed in this message are those of the individ= ual sender, and are not necessarily the views of the Streamdoor Limited, = unless otherwise stated. Although Streamdoor Limited has taken reasonable precautions to ensure no= viruses are present in this email, the company cannot accept responsibil= ity for any loss or damage arising from the use of this email or attachem= ent Employees of Streamdoor Limited and its affiliates are expressly required= not to make defamatory statements and not to infringe or authorise any i= nfringements of copyrights or any other legal right by email communicatio= ns. Any such communication is contrary to company policy and outside the = scope of the employment of the individual concerned. For further assistance on email policy, or if you have received this emai= l in error, please contact Streamdoor Group IT&C Helpdesk by email at it= &c_helpdesk@streamdoor.net or write to Streamdoor Ltd , Head of IT&C Dep= artment , 114 Power Road , Chiswick, London , W4 5PY. www.streamdoor.com *************************************************************************= ************* ------_=_NextPart_001_01C4D6FC.361BFF68 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.freekevin.com/

Ben Gatewood
Streamdoor Ltd
114b Power Rd
London
W4 5PY
+44 20 7422 0439
+44 7835 136 187
bgatewood@streamdoor.net



-----Original Message-----
From: sip-bounces@ietf.org on behalf of David R Oran
Sent: Tue 11/30/2004 4:23 PM
To: GARCIN Sebastien RD-CORE-ISS
Cc: Jesske, R; iptel@ietf.org; Tom Taylor; sip@ietf.org
Subject: Re: [Sip] RE: [Iptel] Calling Party's Category


On Nov 30, 2004, at 10:42 AM, GARCIN Sebastien RD-CORE-ISS wrote:

> Hi,
>
> As an fixed line operator we also are interested in this feature and=
> would be happy that the IETF finally moves forward with this draft.<= BR> > This type of parameter is widely signalled in ISDN/PSTN networks. In=
> SIP (for example) it is required in context of both:
>
> - pure SIP networks (e.g. in case of a SIP payphone), and
> - interworking with legacy networks
>
> I think the uses case for this parameter will depend on the operator=
> service portfolio. For example, in France, the calling party's
> category parameter is used for the Call Return service.
>
Could you explain a bit about how this is used? I, for one would find
= it helpful and possibly a motivating use case.

Also note that if this information is used for any security or
billing-sensitive operations, we have to deal with the issue of how to secure it against spoofing (SIP UAs are generally not trusted). Would
= you believe a call made by Robert Mitnick from a prison phone would
actually have a prison CPC in it's SIP headers :-) ?

(Mitnick is a widely known phone freak and network hacker who served a number of years in US prisons).

> Best regards,
> sebastien
>
> -----Message d'origine-----
> De : iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] De la part
> de Tom Taylor
> Envoy=E9 : mardi 30 novembre 2004 16:07
> =C0 : Jesske, R
> Cc : iptel@ietf.org; sip@ietf.org
> Objet : Re: [Iptel] Calling Party's Category
>
> The question was what the requirement is for this sort of indication= =2E 
> How is it used?
>
> Jesske, R wrote:
>> Dear all,
>> in the past there was a discussion regarding the specification o= f a
>> Calling Party's Category for SIP. (draft-mahy-iptel-cpc-00.txt) = What
>> is the actual status of this activity.
>> We are still interested in such kind of originating indication i= f the
>> call/communication is coming from a normal SIP user or a SIP
= >> -Payphone or SIP-Hotelphone.
>> Is there a interest from other parties in this issue?
>>
>> Best Regards
>>
>> Roland
>>
>> Deutsche Telekom AG
>> T-Com Zentrale
>> Roland Jesske, TE332-2
>> Section TE33; 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
>>
>>
>>
>>
>> _______________________________________________
>> Iptel mailing list
>> Iptel@ietf.org
>> https:/= /www1.ietf.org/mailman/listinfo/iptel
>>
>>
>
> --
> Tom Taylor
> Carrier VoIP Standards Development
> Nortel Networks
> Phone +1 613 763 1496  (ESN 393-1496)
> E-mail: taylor@nortelnetworks.com
>
> _______________________________________________
> Iptel mailing list
> Iptel@ietf.org
> https://www= 1.ietf.org/mailman/listinfo/iptel
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip<= BR> >
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: oran@cisco.com


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

This electronic message may contain privileged or confidential informatio= n. If you are not the intended recipient, be advised that any disclosure,= copying, distribution or use of this information is strictly prohibited.= If you are not the intended recipient, please notify the sender and dele= te this message. Views expressed in this message are those of the individ= ual sender, and are not necessarily the views of the Streamdoor Limited, = unless otherwise stated.

Although Streamdoor Limited has taken reasonable precautions to ensure no= viruses are present in this email, the company cannot accept responsibil= ity for any loss or damage arising from the use of this email or attachem= ent

Employees of Streamdoor Limited and its affiliates are expressly required= not to make defamatory statements and not to infringe or authorise any i= nfringements of copyrights or any other legal right by email communicatio= ns. Any such communication is contrary to company policy and outside the = scope of the employment of the individual concerned.

For further assistance on email policy, or if you have received this emai= l in error, please contact  Streamdoor Group IT&C Helpdesk by em= ail at it&c_helpdesk@streamdoor.net or write to  Streamdoor Ltd = , Head of IT&C Department , 114 Power Road , Chiswick, London , W4 5P= Y.

www.streamdoor.com
*************************************************************************= *************

*************************************************************************= *************
Disclaimer:

This electronic message may contain p= rivileged or confidential information. If you are not the intended recipi= ent, be advised that any disclosure, copying, distribution or use of this= information is strictly prohibited. If you are not the intended recipien= t, please notify the sender and delete this message. Views expressed in t= his message are those of the individual sender, and are not necessarily t= he views of the Streamdoor Limited, unless otherwise stated.

Altho= ugh Streamdoor Limited has taken reasonable precautions to ensure no viru= ses are present in this email, the company cannot accept responsibility f= or any loss or damage arising from the use of this email or attachement
Employees of Streamdoor Limited and its affiliates are expressly re= quired not to make defamatory statements and not to infringe or authorise= any infringements of copyrights or any other legal right by email commun= ications. Any such communication is contrary to company policy and outsid= e the scope of the employment of the individual concerned.

For fur= ther assistance on email policy, or if you have received this email in er= ror, please contact Streamdoor Group IT&C Helpdesk by email at it&c_helpd= esk@streamdoor.net or write to Streamdoor Ltd , Head of IT&C Department ,= 114 Power Road , Chiswick, London , W4 5PY.

www.streamdoor.com************************************************************************= ************** = ------_=_NextPart_001_01C4D6FC.361BFF68-- --===============1756058855== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1756058855==-- From sip-bounces@ietf.org Tue Nov 30 13:31:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17113 for ; Tue, 30 Nov 2004 13:31:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZCrz-00030p-Ff for sip-web-archive@ietf.org; Tue, 30 Nov 2004 13:37:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZCIE-0006Xe-DR; Tue, 30 Nov 2004 13:00:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZCBy-0004rH-KM for sip@megatron.ietf.org; Tue, 30 Nov 2004 12:53:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13630 for ; Tue, 30 Nov 2004 12:53:31 -0500 (EST) Received: from omzesmtp02.mci.com ([199.249.17.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZCH3-0001zZ-Kc for sip@ietf.org; Tue, 30 Nov 2004 12:58:54 -0500 Received: from pmismtp06.wcomnet.com ([166.38.62.54]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0I8000E9Q6W8X4@firewall.mci.com> for sip@ietf.org; Tue, 30 Nov 2004 17:50:33 +0000 (GMT) Received: from pmismtp06.wcomnet.com by pmismtp06.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0I8000K016W4DV@pmismtp06.mcilink.com> for sip@ietf.org; Tue, 30 Nov 2004 17:50:32 +0000 (GMT) Received: from dgexch50.wcomnet.com ([166.38.58.238]) by pmismtp06.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0I8000JGF6W75P@pmismtp06.mcilink.com> for sip@ietf.org; Tue, 30 Nov 2004 17:50:31 +0000 (GMT) Received: by DGEXCH50.mcilink.com with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Nov 2004 17:50:31 +0000 Content-return: allowed Date: Tue, 30 Nov 2004 17:50:26 +0000 From: "Johnston, Alan" To: "'sip@ietf.org'" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain; CHARSET=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [Sip] FW: XCON Interim Attendance Poll - please respond X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b FYI -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Johnston, Alan Sent: Tuesday, November 23, 2004 2:21 PM To: xcon@ietf.org Cc: 'Adam@nostrum.com' Subject: [XCON] XCON Interim Attendance Poll - please respond All, The XCON working group interim meeting is being planned for January 5 and January 6, 2005 in Boston, MA. The exact location and agenda with hotel information will be posted in about a week, as will the official announcement on the IETF Announce list. For the moment, if you plan to attend, or know of people in your organization who plan to attend, please send an email directly to me (mailto:alan.johnston@mci.com) (do *not* send to the list) so we can get an accurate count to finalize the planning. Please respond in the next week, by November 30. Thanks, Alan Johnston co-chair XCON _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 30 13:38:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18047 for ; Tue, 30 Nov 2004 13:38:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZCyR-0003F7-KF for sip-web-archive@ietf.org; Tue, 30 Nov 2004 13:43:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZCo4-0001dq-Du; Tue, 30 Nov 2004 13:32:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZCNH-0008WE-Vc for sip@megatron.ietf.org; Tue, 30 Nov 2004 13:05:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15079 for ; Tue, 30 Nov 2004 13:05:12 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZCSQ-0002Oa-Ab for sip@ietf.org; Tue, 30 Nov 2004 13:10:35 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id iAUI4esO001651 for ; Tue, 30 Nov 2004 12:04:41 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id <4MZWK1AQ>; Tue, 30 Nov 2004 18:04:39 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00C290256@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Adam Roach'" Subject: RE: [Sip] Re: RLS and identity Date: Tue, 30 Nov 2004 18:04:33 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: SIP WG X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 This creates a number of problems for 3GPP which I think need to be discussed further. I also think the current IESG diktat needs fleshing out with more words on the issues they have with a wider specification of available methods, as I don't believe I have seen that on the list yet. Adam is also making generalisations when he states "inherently insecure P-Asserted-Identity mechanism". Noone has made any justification of this statement. I accept that P-Asserted-Identity has a restricted applicability, in that it needs a trust domain, and needs to fulfil a number of criteria, as listed by the template at the back of RFC 3325, but that does not make it insecure. Any mechanism is insecure if you do not follow the rules. Back to the problems. Identity is not ready yet. Yet 3GPP needs RLS in release 6. Creating a normative dependency on identity means that RLS cannot get out in due time. Moreover, to use identity in 3GPP, we need to examine the interdependence of P-Asserted-Identity and the identity draft, as they need to coexist. We are not in a position to just rip one out and replace it with another, and any suggestion that this should be done is an expression of bad faith on behalf of IETF from when RFC 3325 was created. Identity still only solves half the issues that 3GPP use P-Asserted-Identity to solve. The author of the identity draft appears to have accepted the need to study and document this interdependency, as it is one of the identified open issues for completion of that draft. Once we have done that, I am perfectly prepared to look at specifying use of identity in 3GPP release 7, but we need to solve the problem of allowing release 6 implementations to have an RLS and that are conformant with IETF RFCs. I do not want to have to get to the position of 3GPP having to specify something that is not IETF compliant, but that seems to be where they are being driven at the moment. regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > Adam Roach > Sent: 25 November 2004 03:18 > To: Adam Roach > Cc: SIP WG; Aki Niemi > Subject: Re: [Sip] Re: RLS and identity > > > Adam Roach wrote: > > > Based on Rohan's suggestion, the text will effectively say: > > > > - Jon's Identity draft will be mandatory to implement, > optional to use. > > > > - Other mechanisms that have properties such that they can > adequately > > convey the identity of the subscriber and the permission > of the RLS > > to subscribe on the user's behalf can also be used. > > As a clarification, I have received specific guidance from the area > directors that the draft cannot contain anything about such alternate > mechanisms, even if they are not specifically mentioned by > name. The use > of e.g. P-Asserted-Identity will need to be a modification that 3GPP > specifically calls out relative to the draft. > > Of course, since the identity work is basically done and > works so much > better than P-Asserted-Identity, there could be a very valid argument > made that 3GPP R6 should abandon the inherently insecure > P-Asserted-Identity mechanism in favor of the > cryptographically secure > SIP Identity mechanism. > > /a > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 30 14:29:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23342 for ; Tue, 30 Nov 2004 14:29:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZDls-0004qL-6A for sip-web-archive@ietf.org; Tue, 30 Nov 2004 14:34:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZDTy-0006jQ-7A; Tue, 30 Nov 2004 14:16:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZDKn-0003dE-4n for sip@megatron.ietf.org; Tue, 30 Nov 2004 14:06:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21247 for ; Tue, 30 Nov 2004 14:06:43 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZDPx-0004Av-Ap for sip@ietf.org; Tue, 30 Nov 2004 14:12:05 -0500 Received: from [10.1.11.198] (inetgate.teknekron.com [192.138.162.245] (may be forged)) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iAUJ6eWg028635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Nov 2004 13:06:42 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <41ACC4C0.8050907@nostrum.com> Date: Tue, 30 Nov 2004 13:06:40 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith (Keith)" Subject: Re: [Sip] Re: RLS and identity References: <475FF955A05DD411980D00508B6D5FB00C290256@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB00C290256@en0033exch001u.uk.lucent.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: SIP WG X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Drage, Keith (Keith) wrote: >Adam is also making generalisations when he states "inherently insecure P-Asserted-Identity mechanism". Noone has made any justification of this statement. I accept that P-Asserted-Identity has a restricted applicability, in that it needs a trust domain, and needs to fulfil a number of criteria, as listed by the template at the back of RFC 3325, but that does not make it insecure. Any mechanism is insecure if you do not follow the rules. > > I consider any network that has security properties of "crunchy security shell with soft, easily compromised filling" to be inherently insecure -- a single compromise anywhere in the system can be used to exploit the entire system; in 3GPP, this weakness can even be exploited across domains. Any network architecture with such a design guarantees that the security of any node in the system is no better than the security of the least secure node in the system. For sufficiently large systems, this degenerates to the same properties as little or no security, since the probability of at least one node being compromisable goes up geometrically with the number of nodes in the system [1]. Since P-Asserted-Identity works only in the framework of such systems, and relies exclusively on the crunchy shell for protection, I consider it inherently insecure. /a [1] For example, if you have a system with 2,000 nodes, each of which has a 99.9% chance of having been designed and configured to have appropriate security properties, there is still an 86.5% chance that at least one of those nodes will be exploitable, meaning that there is an 86.5% chance that the entire system can be exploited. (99.9% ^ 2000 = 13.5%) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 30 14:49:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26380 for ; Tue, 30 Nov 2004 14:49:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZE5L-0005Sf-3P for sip-web-archive@ietf.org; Tue, 30 Nov 2004 14:54:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZDlF-0002w8-3X; Tue, 30 Nov 2004 14:34:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZDat-0007yD-2e; Tue, 30 Nov 2004 14:23:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22593; Tue, 30 Nov 2004 14:23:21 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZDg2-0004cy-Kk; Tue, 30 Nov 2004 14:28:44 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 30 Nov 2004 12:29:57 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iAUJMKAC013433; Tue, 30 Nov 2004 11:22:21 -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 LAA22216; Tue, 30 Nov 2004 11:22:43 -0800 (PST) Message-Id: <4.3.2.7.2.20041130132024.03056f00@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 30 Nov 2004 13:22:53 -0600 To: sip@ietf.org, sipping@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Sip] Any talk of an Interim for SIP or SIPPING? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Hey Is there any serious talk about having an interim meeting for SIP or SIPPING? Just trying to plan travel schedules in advance, and say the XCON announcement (knowing it,SIP, SIPPING and SIMPLE were thrown in together for one super meeting last May). 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 sip-bounces@ietf.org Tue Nov 30 14:53:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26755 for ; Tue, 30 Nov 2004 14:53:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZE8k-0005ai-1y for sip-web-archive@ietf.org; Tue, 30 Nov 2004 14:58:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZDtL-0005Wv-5c; Tue, 30 Nov 2004 14:42:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZDfr-0001Vc-2P; Tue, 30 Nov 2004 14:28:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23257; Tue, 30 Nov 2004 14:28:29 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZDl0-0004p7-G2; Tue, 30 Nov 2004 14:33:52 -0500 Received: from [10.1.11.198] (inetgate.teknekron.com [192.138.162.245] (may be forged)) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iAUJRJtw030247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Nov 2004 13:27:20 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <41ACC997.40206@nostrum.com> Date: Tue, 30 Nov 2004 13:27:19 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David R Oran Subject: Re: [Sip] RE: [Iptel] Calling Party's Category References: <49E7012A614B024B80A7D175CB9A64ECB0491A@ftrdmel1.rd.francetelecom.fr> <23EA088E-42EC-11D9-8CD3-000A95C73842@cisco.com> In-Reply-To: <23EA088E-42EC-11D9-8CD3-000A95C73842@cisco.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: "Jesske, R" , iptel@ietf.org, Tom Taylor , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit David R Oran wrote: > > On Nov 30, 2004, at 10:42 AM, GARCIN Sebastien RD-CORE-ISS wrote: > >> As an fixed line operator we also are interested in this feature and >> would be happy that the IETF finally moves forward with this draft. >> This type of parameter is widely signalled in ISDN/PSTN networks. In >> SIP (for example) it is required in context of both: >> >> - pure SIP networks (e.g. in case of a SIP payphone), and >> - interworking with legacy networks >> >> I think the uses case for this parameter will depend on the operator >> service portfolio. For example, in France, the calling party's >> category parameter is used for the Call Return service. >> > Could you explain a bit about how this is used? I, for one would find > it helpful and possibly a motivating use case. I'm equally confused. I'm familiar with the calling party category in ISUP, which works only because of the walled-garden nature of the SS7 network. Without that, there are really two major factors around this which need to be characterized: 1. Who is authorized to assert a particular calling party category? This is much trickier than the identity problem; with identity, we can trust that a domain is the authority for the use of user names in that domain. For calling party category, there is no such relationship. For example, it would probably not be valid for a domain of "adamroach.com" to assert a calling party category of "priority," "operator," or "police." 2. Under which circumstances is the calling party category required to be present? Is there some architectural mechanism that can be used to enforce this? (We don't need to define it, but there should at least be some idea about whether it's possible). If not, then there is no purpose in coming up with a protocol mechanism for conveying such information. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 30 17:34:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23808 for ; Tue, 30 Nov 2004 17:34:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZGf8-0005NR-V1 for sip-web-archive@ietf.org; Tue, 30 Nov 2004 17:40:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZGDa-00073X-0z; Tue, 30 Nov 2004 17:11:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZFE5-0006tR-3R; Tue, 30 Nov 2004 16:07:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06904; Tue, 30 Nov 2004 16:07:54 -0500 (EST) From: Mpierce1@aol.com Received: from imo-m15.mx.aol.com ([64.12.138.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZFJF-0008Lj-8U; Tue, 30 Nov 2004 16:13:18 -0500 Received: from Mpierce1@aol.com by imo-m15.mx.aol.com (mail_out_v37_r3.8.) id c.74.47df70e2 (3980); Tue, 30 Nov 2004 16:06:13 -0500 (EST) Message-ID: <74.47df70e2.2ede3ac5@aol.com> Date: Tue, 30 Nov 2004 16:06:13 EST Subject: Re: [Sip] RE: [Iptel] Calling Party's Category To: oran@cisco.com, sebastien.garcin@francetelecom.com MIME-Version: 1.0 X-Mailer: 6.0 for Windows XP sub 10500 X-Spam-Score: 0.3 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: R.Jesske@t-com.net, iptel@ietf.org, taylor@nortelnetworks.com, sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0436617494==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db --===============0436617494== Content-Type: multipart/alternative; boundary="part1_74.47df70e2.2ede3ac5_boundary" --part1_74.47df70e2.2ede3ac5_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 11/30/2004 11:49:18 AM Eastern Standard Time, oran@cisco.com writes: > Also note that if this information is used for any security or > billing-sensitive operations, we have to deal with the issue of how to > secure it against spoofing (SIP UAs are generally not trusted). Would > you believe a call made by Robert Mitnick from a prison phone would > actually have a prison CPC in it's SIP headers :-) ? > Of course, this shows a basic difference in the way this capability is handled in SIP vs today's telephone network. It's an important thing to deal with, since many of these things are mandated by law. For example, I believe the requirement to identify calls from a prison as such is mandated. In today's network, in order to provide assurance that the call is properly marked, not just for CPC but calling party ID as well, the phone in the prison is rnot esponsible for the marking. The switch outside the prison marks any call that comes over that pair of wires. Robert Mitnick had no opportunity to change that marking. The issue for SIP is to provide the same level of assurance for such functions. I'm sure anxious to hear a resolution to this problem, since it keeps coming back. CPC is not unique in this regard, so a general solution is needed. Mike Pierce Artel --part1_74.47df70e2.2ede3ac5_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message=20= dated 11/30/2004 11:49:18 AM Eastern Standard Time, oran@cisco.com writes:


Also note that if this info= rmation is used for any security or=20
billing-sensitive operations, we have to deal with the issue of how to=20
secure it against spoofing (SIP UAs are generally not trusted). Would=20
you believe a call made by Robert Mitnick from a prison phone would=20
actually have a prison CPC in it's SIP headers :-) ?


Of course, this shows a basic difference in the way this capability is h= andled in SIP vs today's telephone network. It's an important thing to deal=20= with, since many of these things are mandated by law. For example, I believe= the requirement to identify calls from a prison as such is mandated.

In today's network, in order to provide assurance that the call is prope= rly marked, not just for CPC but calling party ID as well, the phone in the=20= prison is rnot esponsible for the marking. The switch outside the prison mar= ks any call that comes over that pair of wires. Robert Mitnick had no opport= unity to change that marking.

The issue for SIP is to provide the same level of assurance for such fun= ctions. I'm sure anxious to hear a resolution to this problem, since it keep= s coming back. CPC is not unique in this regard, so a general solution is ne= eded.

Mike Pierce
Artel
--part1_74.47df70e2.2ede3ac5_boundary-- --===============0436617494== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0436617494==-- From sip-bounces@ietf.org Tue Nov 30 18:13:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28423 for ; Tue, 30 Nov 2004 18:13:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZHGV-0006cm-AZ for sip-web-archive@ietf.org; Tue, 30 Nov 2004 18:18:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZH8v-00084m-8m; Tue, 30 Nov 2004 18:10:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZH82-0007O2-Bg for sip@megatron.ietf.org; Tue, 30 Nov 2004 18:09:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28043 for ; Tue, 30 Nov 2004 18:09:47 -0500 (EST) Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZHDE-0006XH-0o for sip@ietf.org; Tue, 30 Nov 2004 18:15:13 -0500 Received: from unknown (HELO gamma.jnpr.net) (172.24.245.25) by kremlin.juniper.net with ESMTP; 30 Nov 2004 15:09:18 -0800 X-BrightmailFiltered: true X-Ironport-AV: i="3.87,118,1099296000"; d="scan'217,208"; a="40794711:sNHT32555788" Received: from hadron.jnpr.net ([172.24.15.25]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 30 Nov 2004 15:09:17 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 30 Nov 2004 15:09:17 -0800 Message-ID: Thread-Topic: OPTIONS outside dialog Thread-Index: AcTXMZ3IJ8axKuJiR9qIqYma8CV3LA== From: "Anil Bollineni" To: , X-OriginalArrivalTime: 30 Nov 2004 23:09:17.0823 (UTC) FILETIME=[9E0CE0F0:01C4D731] X-Spam-Score: 0.1 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Subject: [Sip] OPTIONS outside dialog X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1478162784==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 This is a multi-part message in MIME format. --===============1478162784== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4D731.9DAC997C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4D731.9DAC997C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Assume OPTIONS comes outside dialog, what are the possible responses that are for OPTIONS, assume these are the same responses for any request as defined in RFC 3261. Please clarify. =20 Thanks in advance, Anil =20 ------_=_NextPart_001_01C4D731.9DAC997C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

    Assume OPTIONS comes outside = dialog, what are the possible responses that are for OPTIONS, assume these are the = same responses for any request as defined in RFC 3261. Please = clarify.

 

Thanks in advance,

Anil

 

=00 ------_=_NextPart_001_01C4D731.9DAC997C-- --===============1478162784== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1478162784==-- From sip-bounces@ietf.org Tue Nov 30 19:56:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07116 for ; Tue, 30 Nov 2004 19:56:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZIs5-0000Qi-7v for sip-web-archive@ietf.org; Tue, 30 Nov 2004 20:01:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZIax-0000em-58; Tue, 30 Nov 2004 19:43:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZIXl-0007a4-2j; Tue, 30 Nov 2004 19:40:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05339; Tue, 30 Nov 2004 19:40:25 -0500 (EST) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZIcy-0008Q8-S2; Tue, 30 Nov 2004 19:45:53 -0500 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id iB10dtxg003341; Wed, 1 Dec 2004 00:39:55 GMT Received: by stntimc1.neustar.com with Internet Mail Service (5.5.2657.72) id ; Tue, 30 Nov 2004 19:39:55 -0500 Message-ID: <24EAE5D4448B9D4592C6D234CBEBD597089985@stntexch03.cis.neustar.com> From: "Peterson, Jon" To: "'Adam Roach'" , David R Oran Subject: RE: [Sip] RE: [Iptel] Calling Party's Category Date: Tue, 30 Nov 2004 19:39:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: "Jesske, R" , iptel@ietf.org, Tom Taylor , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 I view these sorts of security attributes as elements of trait-based authorization. The calling party's category requires the sort of pre-arrangement and federation to which something like SAML naturally lends itself. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Tuesday, November 30, 2004 9:27 PM > To: David R Oran > Cc: Jesske, R; iptel@ietf.org; Tom Taylor; sip@ietf.org > Subject: Re: [Sip] RE: [Iptel] Calling Party's Category > > > David R Oran wrote: > > > > > On Nov 30, 2004, at 10:42 AM, GARCIN Sebastien RD-CORE-ISS wrote: > > > >> As an fixed line operator we also are interested in this > feature and > >> would be happy that the IETF finally moves forward with > this draft. > >> This type of parameter is widely signalled in ISDN/PSTN > networks. In > >> SIP (for example) it is required in context of both: > >> > >> - pure SIP networks (e.g. in case of a SIP payphone), and > >> - interworking with legacy networks > >> > >> I think the uses case for this parameter will depend on > the operator > >> service portfolio. For example, in France, the calling party's > >> category parameter is used for the Call Return service. > >> > > Could you explain a bit about how this is used? I, for one > would find > > it helpful and possibly a motivating use case. > > > I'm equally confused. I'm familiar with the calling party category in > ISUP, which works only because of the walled-garden nature of the SS7 > network. Without that, there are really two major factors around this > which need to be characterized: > > 1. Who is authorized to assert a particular calling party category? > This is much trickier than the identity problem; with > identity, we > can trust that a domain is the authority for the use of > user names > in that domain. For calling party category, there is no such > relationship. For example, it would probably not be valid for a > domain of "adamroach.com" to assert a calling party category of > "priority," "operator," or "police." > 2. Under which circumstances is the calling party category required > to be present? Is there some architectural mechanism that can be > used to enforce this? (We don't need to define it, but there > should at least be some idea about whether it's > possible). If not, > then there is no purpose in coming up with a protocol mechanism > for conveying such information. > > /a > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip